企业官网建设流程全解析

如果你整天泡在 AI 编程助手里，一定遇到过这种挫败感：明明同一个模型，有时候回答得像资深架构师，有时候又像一个刚入行三天的新手。区别往往不在模型本身，而在你有没有给 AI 一套“干活的方法论”。我最近重度使用的superpowers，就是专门解决这个问题的一个技能框架——它给 Claude Code 装上几十个可复用的skills，让 AI 按资深工程师的套路去思考、调试、写计划、写测试、做代码审查。这篇文章我会说清楚它到底是什么、里面有哪些技能、怎么安装和引入这些技能，以及我实际用下来踩过的坑。

先给还不了解的朋友一个定位：superpowers 不是独立应用，而是 Claude Code 的一个插件（plugin），准确说是一个 skills 集合和技能管理框架。它把“如何引导 AI 完成复杂任务”这件事做成了标准化文件，AI 会在合适的时机自动加载对应技能，按固定流程输出结果。听起来有点抽象，但用顺手之后，你会发现 AI 的工作方式从“你说一句它写一段”变成了“它先拆解问题、再给方案、按计划执行、最后自查”，整个链路专业得多。

1. superpowers 到底是什么：把“经验”变成 AI 能读的说明书

1.1 为什么需要技能（skills），而不是靠对话碰运气

先讲一个可能被很多人忽略的事实：Claude Code 这类工具的底层模型非常强，但模型本身不知道“你的团队怎么约定代码规范”“你希望它先写测试还是先写实现”“你习惯怎么拆解需求”。这些知识散落在你的脑子里，每次对话都要现教，教完它就忘，换个项目又得重新教。

superpowers 解决的就是这个问题。它将“资深工程师接到任务后是怎么想的、怎么做的”拆解成一整套指令文件，每个技能对应一个场景，比如调试、写计划、写提交信息、做代码审查。AI 读到这些文件，就像新人入职拿到了一本《工作操作手册》，不用再靠临场发挥。你可以把它理解成给 AI 灌入一套“SOP”，从此它的行为模式稳定且可复现，而不是每次看心情。

还有一个关键点：这些技能不是死板的提示词模板。superpowers 里的技能是有层级、会协作的。比如test-driven-development这个技能，内部会调用brainstorming、debugging、writing-plans等一系列子技能，形成一个完整的质量闭环。AI 执行任务时不是线性地“读完就做”，而是按技能指令去搜索、规划、验证、复盘。

1.2 superpowers 的底层机制：Markdown 技能文件 + 自动触发

很多人第一次听到“skills”以为是什么高深的东西，其实机制特别朴素。在 Claude Code 的约定里，一个技能就是一个目录，目录里放一个SKILL.md文件。这个文件有固定的格式：头部是 YAML 格式的 frontmatter，声明技能的名称和描述；正文是具体的操作指令，告诉 AI 遇到这种情况应该按哪些步骤走。

Claude Code 每次开启会话时会扫描技能目录，把每个SKILL.md的描述注入到系统提示里。当用户的指令命中描述中的场景时，AI 就会自动加载该技能的完整指令并执行。这意味着技能文件本质上就是“可被 AI 动态读取的说明书”。superpowers 做的，是替你把一整套经过验证的说明书打包好，通过插件市场一键装进 Claude Code，省去你自己到处找模板、拼凑流程的麻烦。

1.3 为什么叫 superpowers 而不是“claude-skills”

这个项目最初由 Jesse Vincent（obra）发起，后来并入了 opendream 组织。名字叫 superpowers，玩的就是“给 AI 超级能力”这个梗——它把几十个单点能力组合在一起，让 AI 涌现出接近一个成熟开发者的综合素养。实际体验下来，这个名字不算夸张：它对 AI 工作方式的改变，确实像从“徒手搬砖”升级到“拿着一整套工具箱干活”。

另外，这个框架并不绑定某个特定模型。只要底层的 Claude Code 支持插件机制，理论上你可以在不同项目、不同模型配置下复用同一套技能。这意味着你沉淀下来的工作流可以随身携带，而不是锁死在某一次对话里。

2. 有哪些现成的 skills 可以直接用

2.1 开发核心链路：从想法到上线的一整套技能

我装好 superpowers 后第一件事就是把技能列表翻了一遍。仓库里维护了一批高质量的预置技能，覆盖了软件开发的主要环节。我最常用的几个：

• brainstorming：正式动手前先结构化梳理需求和思路，强迫 AI 列出问题、证据、假设，而不是直接甩代码。
• writing-plans：把一个模糊目标拆解成可执行的分步实施计划，附带取舍说明和风险点。
• implementing-plans：拿到计划后按部就班实现，每一步对应验证，防止跑偏。
• test-driven-development：驱动 AI 先写失败测试，再写实现代码，最后重构。这是我最喜欢的一个技能，因为不用你反复强调“先写测试”。
• test-driven-debugging：调试时先写一个能复现问题的测试，再开始定位根因，避免瞎猜。
• debugging：系统化排查 bug，按照“复现—假设—排查—验证”的路径走，而不是东一榔头西一棒子。
• reviewing-code：对已有代码做多轮审查，关注正确性、安全性、可维护性，能提出具体修改建议。
• creating-pr/writing-pr-descriptions：生成 PR 描述和提交信息，省去每次手写 commit message 的琐碎。

这些技能的价值不仅仅是“AI 会按照步骤走”，而是步骤本身是经过大量实战验证的。比如debugging会要求 AI 先复现问题、寻找根因、再修复，并且验证修复是否引入新问题——这套流程看起来是常识，但如果不显式写进技能文件，AI 往往会直接给你一个“看起来对”的补丁，根本没有做回归验证。

2.2 文档与流程管理：容易被忽略的“软技能”

除了写代码，superpowers 还带了一批面向文档和流程的技能：

• creating-and-reviewing-design-docs：起草和评审设计文档，推动团队在写代码之前对齐方案。
• polishing-markdown：润色 Markdown 文档，规范标题层级、表格、列表，常用于 README 和内部文档。
• writing-commit-messages：根据 diff 和上下文生成规范、有信息量的提交信息，这个可以做到近乎自动触发。
• creating-slides：把内容整理成幻灯片大纲，适合做技术分享和汇报。
• updating-specification：实现完成后反向更新规格说明，保证文档不腐化。
• solving-errors：处理报错信息，整理错误上下文、尝试路径、最终解法。
• systematic-approaches：面对复杂问题时，强制使用结构化的系统性方法拆解。
• web-development：网页开发场景的专用工作流，整合了设计、实现、验证环节。

另外还有root-cause-update、verifying-implementations这类偏工程质量的小技能。不同版本和分支下技能清单会有些差异，以仓库 README 为准，但上面列出的是我自己用过的、确认能正常工作的核心项。

2.3 技能之间如何协作：它不是一箱散装工具

我之前用过不少“提示词合集”，特点是每个模板独立，互相之间没有关联。superpowers 不太一样，技能之间有明显的调用关系。举个实际例子：你扔给它一个模糊需求，brainstorming会先引导你把问题问清楚，产出明确的需求描述；接着writing-plans把这个描述变成实施计划；计划确定后test-driven-development入场，让你先写测试再写实现；最后reviewing-code对结果做体检。

这个过程就像一条流水线：每个技能是流水线上的工位，AI 自动判断当前该让哪个工位工作。这样带来的直接好处是输出质量的方差变小了。以前同一个问题跑十次能得到七八种风格迥异的答案，用了 superpowers 之后，答案的思考路径基本一致，细节会根据上下文变化，但骨架非常稳定。这种稳定性在团队协作里尤其重要，因为代码审查和维护最怕的就是“这个代码不像同一个人写的”。

3. 想要安装 superpowers：从 marketplace 到项目生效

3.1 安装前的环境准备

superpowers 依赖 Claude Code 的插件能力，所以第一步是确认你的 Claude Code 版本。插件机制在 0.2.21 左右开始支持，后续版本迭代很快，功能变化也大，我的建议是直接把 Claude Code 升级到当前最新稳定版，省得因为版本太老导致插件装不上或者命令缺失。

检查版本用命令行就行：

claude --version

如果版本偏旧，就先更新：

npm update -g @anthropic-ai/claude-code

这里提醒一句：尽量用官方推荐的方式安装和更新，不要用乱七八糟的修改版，否则后续排错会很痛苦。

3.2 三步装好：marketplace 地址 + 安装命令

superpowers 的安装非常标准，走的是 Claude Code 的插件市场机制。在 Claude Code 对话窗口里依次输入两个斜杠命令：

/plugin marketplace add opendream/superpowers /plugin install superpowers@superpowers

第一条命令把 superpowers 的 marketplace 添加到你的插件源列表里。第二条命令从该 marketplace 安装名为 superpowers 的插件。执行完之后，你可以输入：

/plugin

确认列表中已经出现 superpowers。如果出现，说明安装成功。

我个人的习惯是安装完立刻重启一次 Claude Code 会话，因为技能文件的扫描和注入发生在会话初始化阶段，不重启的话可能不会自动加载新技能。

3.3 初始化配置：onboarding 和技能生成

安装只是第一步，真正让技能在你项目里生效还需要一个初始化动作。装完后 Claude Code 通常会引导你运行一次 onboarding（不同版本触发位置可能不同，一般在插件命令列表里能找到/superpowers:onboarding）。

这个初始化过程会询问你一些项目偏好，比如是不是要在当前项目启用技能、要不要生成团队共用的技能说明文件之类。确认后它会在项目里生成对应的技能配置目录，通常是在.claude/skills/下。这个目录就是技能的“家”，Claude Code 每次启动都会扫描它。

如果你的项目里原本没有.claude/skills/目录，初始化完成后应该能看到一排技能子目录，每个子目录里都有一个SKILL.md。可以随手打开一个看看，里面的 frontmatter 和正文结构都很清晰，理解成本极低。

3.4 手动引入和离线安装方式

Claude Code 的plugin marketplace add不仅支持远程仓库，也支持本地路径。如果你在的网络环境下访问 GitHub 不太顺畅（这里不展开，懂的都懂），可以考虑先把仓库 clone 到本地，再通过本地路径添加 marketplace：

git clone https://github.com/opendream/superpowers.git

然后进入 Claude Code，执行：

/plugin marketplace add /本地路径/superpowers /plugin install superpowers@superpowers

效果和远程安装完全一样，而且后续你本地改了技能文件会立刻生效，调试自定义技能时会方便很多。我个人在刚开始接触 superpowers 时就是用的本地 clone 方式，改完文件不用重新装插件，对学习这个框架的运作机制帮助很大。

还有更“裸”的引入方式：直接复制技能目录。比如你只想用debugging这一个技能，不需要装整个插件，那就把仓库里对应的技能目录复制到项目.claude/skills/下。Claude Code 只认目录，不认来源。这种方式适合只想取其中某几个技能、不想引入整套体系的场景。

4. superpowers 的具体使用：从触发到落地的完整路径

4.1 触发方式：斜杠命令和自动触发各管一摊

superpowers 里的技能有两种触发路径。一种是显式调用，比如你输入/superpowers:brainstorm，AI 会强行进入头脑风暴模式，不管你给它的任务有多具体——这种适合在需求模糊、自己还没想清楚的时候用。另一种是自动触发，AI 根据你的描述和技能文件里的 description 匹配，发现自己正在处理的任务命中了某个技能场景，就会自动加载指令。

实际使用中我总结的规律是：命令触发适合“主动干预流程”，自动触发适合“让 AI 按默认经验干活”。比如我会在接到一个新需求时主动敲/superpowers:brainstorm，逼自己把需求整理清楚；但 commit message 这种我就完全不管，writing-commit-messages会在 git commit 场景自动接管。

有一个细节值得注意：自动触发依赖技能文件里的 description 写得好不好。superpowers 预置技能的描述都经过打磨，基本不需要你操心；但如果你自己写自定义技能，description 一定要写清楚触发场景，否则 AI 不知道什么时候该用这个技能，装了也白装。

4.2 实操案例：用一整套技能走完一个小需求

举个我自己跑过的例子。任务是“给一个 Python 项目增加按用户角色过滤列表数据的接口”。如果没有 superpowers，我直接描述需求，AI 大概率会生成一个接口然后加个 if 判断，完事。但有了技能流之后，流程变成了这样：

1. 我先调用/superpowers:brainstorm。AI 没有立刻写代码，而是反问我：“这个接口是给内部管理系统用还是给外部客户端用？用户角色从哪里获取？过滤是发生在 SQL 层还是应用层？”这些问题逼我把需求边界重新想了一遍，最后确认了过滤应该发生在 SQL 层，并且角色信息从登录态里取。
2. 需求明确后调用writing-plans，AI 输出一份实施计划，包括数据库查询改动、接口签名、测试用例设计、兼容性影响，每一条都标了优先级。
3. 计划确认后，我切到test-driven-development模式。AI 先根据计划写了三个失败测试：管理员能看到全部数据、普通用户只能看到自己部门的数据、未登录用户返回 401。然后才写实现代码。
4. 代码写完后我做了一个小改动，要求加一个额外的排序参数，这时候发现原来的测试没覆盖这个分支。我调用了/superpowers:test-driven-debugging，AI 先补了一个复现该场景的测试，确认失败，接着定位到排序逻辑写死在 SQL 里，修改为动态参数后重新跑全量测试，全部通过。

整个过程我几乎没有说“你先写测试”“你注意边界情况”这种话，全是技能在背后驱动。输出质量和人工引导时的差距不大，但省下的口舌非常多。

4.3 自定义技能的最简模板：把团队规范固化下来

如果你不想完全依赖预置技能，可以动手写自己的。最简模板长这样，放在.claude/skills/<技能名>/SKILL.md：

--- name: my-custom-skill description: 当用户要求处理日志脱敏或涉及敏感信息时使用 --- # My Custom Skill 1. 识别输入中所有疑似敏感字段（手机号、身份证、token）。 2. 按项目 `.env.example` 中的字段清单核对。 3. 对匹配字段统一替换为 `***`，保留前三位和后四位。 4. 输出处理结果并提醒用户人工复核。

写完后重启会话，问 AI 一个会命中该场景的问题，它就会自动按这套流程走。这个模板看起来简单，但实际价值很大：你可以把团队的代码规范、安全策略、文档风格全部技能化，让任何接入项目的 AI 都遵循同一套标准。

5. 常见问题与排查技巧实录

5.1 技能文件没有生效，怎么回事

这是问得最多的一个问题。装完 superpowers，技能目录也生成了，但 AI 的表现和之前一模一样，完全看不出技能在起作用。排查思路按顺序来：

1. 确认 Claude Code 版本足够新，旧版本根本不支持插件机制。
2. 确认.claude/skills/目录位置正确。注意项目级技能放在项目根目录的.claude/skills/，全局技能放在用户目录的~/.claude/skills/，放错地方 AI 看不到。
3. 确认SKILL.md文件名和目录名一致，frontmatter 格式正确（必须有name和description两行）。
4. 重启会话。技能扫描发生在会话初始化阶段，修改技能文件后必须重启才能加载。
5. 在对话里直接问 AI：“你现在加载了哪些技能？”它能列出来说明生效，列不出来就是没读取到。

我遇到过最隐蔽的问题是 frontmatter 里description写得太笼统，AI 无法判断什么时候该触发。比如“当用户需要帮助时使用”这种描述，基本等于没写。具体一点，命中率会高很多。

5.2 插件命令找不到或者安装失败

如果你在 Claude Code 里输入/plugin提示命令不存在，多半就是版本问题。升级到最新版再试，基本都能解决。安装失败的情况，常见原因有两个：网络原因导致拉取仓库超时，或者 marketplace 地址拼写错误。注意地址是opendream/superpowers，不是obra/superpowers（旧地址虽然还能访问，但推荐以官方 README 为准）。如果是本地路径方式，确认路径写的是仓库根目录，而不是仓库里的某个子文件夹。

另外，/plugin install后面跟的superpowers@superpowers是“插件名@marketplace 名”的格式，不要少打后半段。装完后输入/plugin检查是否出现在已安装列表里。

5.3 技能冲突：多个来源定义了同名技能

这个问题我在同时使用多个插件时碰到过。两个 marketplace 都提供了debugging技能，Claude Code 加载时后安装的会覆盖先安装的，最后生效的行为和你预期的不一样。排查方法是查看两个插件各自技能目录里的SKILL.md文件，对比内容，确认哪个是你要的版本。最干净的办法是只保留一个来源，把另一个插件移除，不要心存侥幸，同名技能迟早会出问题。

5.4 我踩过的几个不是坑的坑

最后分享几个经验性的教训。第一，不要一股脑把全部技能都复制到全局~/.claude/skills/。技能描述会占用上下文空间，技能装得越多，留给对话和代码的 token 越少，反而影响效果。按需安装，用哪个装哪个，这才是正确姿势。

第二，第一次引入 superpowers 时我会建议你在一个试验项目里跑一遍，而不是直接在核心生产项目上实践。因为它的工作流和 AI 默认行为差异很大，你需要先适应“AI 先问一堆问题再动手写代码”这个节奏，否则会觉得它变啰嗦了。用几次之后你会发现，这顿啰嗦换来的是返工率大幅下降。

第三，技能不是银弹。它就是一套流程说明书，如果你的指令本身模糊、需求本身矛盾，再好的技能也救不回来。我自己从一开始的“甩一个需求等结果”，慢慢变成了“先花两分钟把目标和约束说清楚，然后让技能去执行”。配合得当之后，superpowers 才能真正发挥出那种“给 AI 装上超能力”的效果。

我个人现在的习惯是：所有新项目第一时间装好插件并初始化技能目录，日常工作完全依赖自动触发，只有需求特别模糊或复杂时手动调出brainstorming和writing-plans。这套工作流跑通之后，我再也没回到“裸奔”状态。你要是也在用 Claude Code，强烈建议花十分钟把它装起来试一圈，尤其是test-driven-development和debugging这两个技能，我敢说你很难再退回原来的用法。