企业官网建设流程全解析

最近后台收到好几条留言，都在问同一个东西："superpowers 到底怎么装？有哪些 skills？怎么用？" 也难怪，这名字在 AI 编程助手圈子里确实火了一阵。我直接说结论：superpowers 是一套开源的"AI 助手技能包"，主要配合 Claude Code 使用，把资深工程师的工作方法——头脑风暴、测试驱动开发、系统化调试——变成 AI 能自动遵循的流程。它解决的是目前最让人头疼的问题：AI 明明能力很强，但发挥极不稳定，每次写代码都像开盲盒。如果你属于"天天用 AI 写代码但总嫌它不够靠谱"的群体，或者想给团队统一一套 AI 工作方法，这篇文章应该能帮到你。下面我会把它的技能清单、安装步骤、实际使用技巧一次讲清楚。

1. superpowers 到底是什么：它解决的不是"聪明不聪明"，而是"工作方法"问题

1.1 为什么 AI 总是"很强但不可控"

我用了挺长一段时间 AI 编程助手，最大的体感就是两个字：方差。同一个需求，状态好的时候它能把测试、边界情况、代码重构全都考虑进去；状态不好，或者上下文稍微乱一点，它就上来直接改代码，测试也不写，边界也不问，改完还不自知。

这不是模型不够聪明，而是它缺一套"标准作业流程"。我们人写代码之所以相对稳定，是因为有多年养成的肌肉记忆：先想清楚再动手、写测试验证行为、定位问题先复现再说。AI 没有这种肌肉记忆，除非你把流程显式地写给它。

superpowers 做的正是这件事。它不改变底层的模型能力，而是改变模型"做事的方式"。这也是它名字的由来——给 AI 装上资深工程师的"超能力"。

1.2 "技能"在这里到底是什么：一份给 AI 的标准作业手册

superpowers 的核心是一组 Markdown 文件，每个文件叫一个 skill，遵循 Anthropic 的 Agent Skills 规范。每个 skill 文件里包含两个关键部分：一个是 description，告诉 AI"什么时候该用这个技能"；另一个是 instructions，把该技能的执行步骤一条条写清楚。

可以把它理解成给 AI 发了一本"标准作业手册"。当对话中出现匹配场景时，AI 会自动读取并执行对应步骤，而不是每次都靠现场发挥。

用带新人来类比最贴切。你带过一个新工程师就会懂：光说"你把这个 bug 查一下"，他大概率东翻西找，最后瞎改一通；但如果你给他一张排查清单——先复现，再收集日志，再列假设，逐个验证——他就能干得有模有样。superpowers 就是给 AI 发了一整套这样的清单。

1.3 它不是什么，以及和同类工具的边界

先澄清几个容易混淆的点。superpowers 不是新模型，不是 IDE 插件，也不是像 MCP（Model Context Protocol）那样给 AI 接外部工具的服务。它更像是"行为规范层"。

MCP 解决的是"AI 能调用什么"——数据库、浏览器、第三方 API，相当于给 AI 配了一整套工具箱。superpowers 解决的是"AI 应该按什么步骤做事"——相当于教 AI 怎么按规范使用工具箱。这两者不冲突，反而经常搭配使用。

所以，如果你问"装了 superpowers 是不是 AI 就能自己连数据库了"，那不能。它还做不到这一点。它的本职工作只有一个：让 AI 写代码和解决问题时，更像一个训练有素的工程师，而不是一个热情但混乱的实习生。

2. 自带技能清单：核心 skills 分别管什么

看仓库的默认配置，superpowers 会带一组 skills 进来。我挑几个最常用、也最影响日常体验的展开讲，每个我都会说明触发时机和实际效果。

2.1 Brainstorming：需求不清晰时，先别急着写代码

这个技能的触发时机是：需求描述模糊、有多种实现路径、或者用户还没想清楚自己要什么。

它要求 AI 不直接写代码，而是先围绕目标提问、列出可能的方案、标注各自的风险和成本。我实际体验过之后觉得，这个技能几乎是"最容易被低估"的一个。

以前你丢一个"给下载模块加个断点续传"这种需求，AI 二话不说就开写。有了 brainstorming 之后，它会先反问："断点续传的范围是单文件还是也包含批量任务？服务端是否支持 Range 请求？是否需要考虑存储成本？"——这些恰恰是资深工程师拿到需求后脑子里最先转的问题。省掉了这些前置问题，后面十有八九要返工。

2.2 TDD：测试驱动开发，先写失败测试，再写实现

这个技能把 red-green-refactor 流程拆成了明确指令：先为需求写一个会失败的测试，再写最少量的实现让测试通过，然后做重构，全程保持测试是绿的。

它强制 AI 在动手前想清楚"这个功能到底该怎么验证"。我观察到一个细节：执行 TDD 技能时，AI 会主动说"我先写一个失败测试来锁定预期行为，再开始实现"。这句话在 code review 里价值很高——说明行为边界是先定义好的，而不是实现完之后再回头补测试。

2.3 Systematic Debugging：把调 bug 变成有步骤的排查

这是我自己最常用的技能，没有之一。它的核心思想是：禁止猜测。

执行流程大致是：先复现问题，再收集证据（日志、数据、调用栈），基于证据提出假设，用最小实验验证假设，定位根因后修复，最后补充回归测试防止复发。

这个技能治好了 AI 的"打地鼠式修 bug"毛病。以前遇到报错，AI 会直接猜一个原因然后改掉，运气好解决了，运气不好引入一个新问题。现在它会先让我提供复现步骤，再一步步缩小范围。说实话，这比我带过的不少初级工程师都稳。

2.4 Writing Plans 与 Implementing Changes：大型改动的"先计划后执行"

当改动跨多个文件、影响面较大时，Writing Plans 会先让 AI 产出一份实施计划：列出涉及模块、改动顺序、风险点、回滚方案。计划经确认后，再由 Implementing Changes 技能执行，执行时严格对照计划，不跑偏。

这两个技能配合起来，特别适合重构类任务。以前让 AI 重构一个模块，它经常顺手把不相关的代码也改了，review 起来极其痛苦。有了计划约束之后，改动范围清晰很多，review 效率明显提升。

2.5 快速对照表

3. 安装与引入：完整步骤和避坑记录

3.1 前置条件：先确认你的环境

superpowers 官方主要面向 Claude Code 的插件系统。安装之前先确认三件事：

1. 已安装 Claude Code 且能正常对话。
2. 命令行里能看到插件相关命令，一般是/plugin。
3. Claude Code 版本别太老，建议更新到较新版本。

可以用claude --version快速检查版本号。如果版本太老、没有插件命令，需要先升级。这里多说一句：它不等同于 Claude 网页版或手机 App，网页版没法装插件，必须在命令行环境里操作。

3.2 标准安装方式：直接在会话里装

最省事的办法是在 Claude Code 会话中直接执行：

/plugin install obra/superpowers

这条命令会从 GitHub 拉取仓库并注册为插件。装完之后输入/plugin，应该能在插件列表里看到 superpowers 已启用。

我自己更推荐这种方式，因为后续更新也方便。直接在插件面板里操作即可，不用手工拉代码。

3.3 手动安装方式

如果因为网络环境或自定义需求，不能直接用命令安装，也可以手动操作。思路就两步：

1. 把仓库 clone 到本地插件目录，一般是~/.claude/plugins/marketplaces/。
2. 重启 Claude Code，在插件面板里把它加入启用列表。

命令大概是这样的：

git clone https://github.com/obra/superpowers ~/.claude/plugins/marketplaces/superpowers

具体路径以官方文档为准，但核心逻辑不变：仓库放到插件目录，然后在面板里启用。

3.4 验证安装是否生效

装完别急着干活，先花三十秒确认加载成功。我常用的验证方式是在对话里直接问一句：

你现在能使用 superpowers 提供的哪些技能？

如果 AI 能罗列出 brainstorming、test-driven-development、systematic-debugging 等技能，说明加载成功。如果它一脸茫然，大概率没装好。

也可以直接看文件系统。进入插件目录，确认里面存在.claude-plugin/plugin.json和skills子目录，每个技能文件都在。看到这些文件，基本就稳了。

3.5 我踩过的几个坑

这里分享几个我实际遇到过的问题，按排查思路写，方便你对照。

坑一：装完不重启会话，AI 一直说"未找到该插件"。

插件列表确实变了，但当前会话的上下文没有重新加载。这个问题最容易忽略。解决方式：退出当前会话，新开一个会话。不是清除上下文那么简单，直接重开最稳妥。

坑二：插件命令被其他命令遮住，找不到入口。

如果你同时配了很多工具，/命令补全列表可能很长。处理思路是：先输入/plugin看是否有自动补全提示，如果命令不存在，再检查版本。不要凭记忆去猜命令名，用补全列表最可靠。

坑三：本地手工改过插件目录，更新时拉取冲突。

我一开始手动 clone 的时候，手贱改过里面的文件，后来更新就报冲突。处理思路是：不要手工改插件目录里的内容。真要自定义，先 fork 一份再改，别动原仓库。这个习惯能避免后续大量痛苦。

坑四：装了多个 marketplace，同名 skill 冲突。

如果你同时装了不止一个插件源，可能遇到同名 skill。点名提到哪个技能时，AI 可能复用错版本。处理思路：在插件面板里只保留需要的那一份，把其他同名的从启用列表里取消，而不是去删文件。删文件容易把整个插件弄坏。

4. 日常使用：技能不是咒语，而是自动触发的工作流

4.1 不用背咒语，AI 会自动按场景触发

superpowers 设计的目标之一就是"无感使用"。你正常用自然语言提需求就行，AI 会根据技能文件里的 description 自动判断是否触发。

比如你说"帮我查一下这个报错"，它更可能自动进入 systematic-debugging 流程；你说"我有个新功能想法，但还没想太清楚"，它可能自动进入 brainstorming。你不需要说"请使用技能"这种话。

这点很关键。很多人以为装完插件要输入特殊指令才能激活，其实完全不需要。它的工作方式是后台判断，就像你带了个懂规矩的助手，不需要每次都提醒。

4.2 主动引导的几种说法

自动触发虽然方便，但主动点名效果更好，尤其是你有明确偏好时。我常用的几种说法：

• "先不要写代码，帮我 brainstorm 一下这个需求。"
• "这个功能用 TDD 的方式来做。"
• "现在开始系统化调试，先定位根因再动手改。"
• "先写一个实施计划，我确认之后你再改。"

这些说法会给 AI 更强烈的执行信号，效果比"认真点""仔细点"这类模糊要求强得多。注意，这里的核心不是命令的口气，而是明确指定流程。

4.3 一个真实对比：有和没有 superpowers 的差别

我拿一个小需求做过对比测试。需求很简单：给一个内部工具函数加个内存缓存，避免重复计算。

没有 superpowers 时，AI 的行为是：直接给函数套了个字典缓存，没有考虑并发调用，没有补测试，只改了一个调用点就宣布完成。

有 superpowers 时，它的流程变成了：先问"这个函数会被并发调用吗？需要缓存失效策略吗？"，然后说"我按 TDD 来，先写一个验证缓存生效的测试"，再实现，最后主动补了缓存失效逻辑和回归测试。

同样一个需求，工作量其实差不多，但质量可维护性完全不同。后者几乎可以直接合入主干，前者大概率还得返工。

4.4 和 MCP、项目文档的分工

很多朋友容易把 superpowers 和 MCP 混在一起。这里统一说清楚，它们不冲突，但角色不同：

• MCP 提供"能力"：读数据库、操作浏览器、调第三方 API，相当于手和工具。
• superpowers 提供"流程"：先测后写、先复现再修，相当于大脑里的方法论。
• CLAUDE.md / AGENTS.md 提供"项目约束"：不要改哪个目录、遵循哪种代码风格，相当于公司规章制度。

三者的分工可以这样记：项目文档说"什么不能做"，MCP 解决"能做到什么"，superpowers 告诉你"该按什么步骤做"。配合使用时，稳定性会有明显提升。

5. 我用了一个月之后的观察和心得

5.1 最明显的变化：AI 的"发挥下限"被抬高了

用之前和用之后，最核心的区别不是 AI 变聪明了，而是"稳定"。

它不一定让 AI 的上限提高多少——真正难的架构设计，它还是要靠模型本身的能力——但它的下限被抬得很高：该问边界时会问，说写测试就写测试，修 bug 不瞎猜。这种稳定性对团队协作尤其重要，因为多人协作时最怕的就是不可预测。

5.2 什么场景不用硬套

技能不是越多越好，有几种场景我会选择忽略或绕开：

• 一次性小脚本、临时调试代码：走完整 TDD 反而拖慢。写个脚本清理一下日志，没必要先写测试。
• 纯探索性问题（"这个库怎么用"）：不需要 brainstorm，直接看文档更快。
• AI 本身已经在按合理流程做的小改动：不必重复触发，反而打断节奏。

要记住，它是方法论，不是仪式。该灵活的时候要灵活。

5.3 我的几条实操建议

建议一：从两个技能开始体验。

第一次用，推荐只关注 brainstorming 和 systematic-debugging。前者能立刻改变你和 AI 的对话质量，后者能显著减少"AI 修完又坏了"的循环。其他技能等熟悉了再加。

建议二：有条件就团队统一版本。

如果团队多人都在用，尽量让所有人用同一个版本。不然会出现"A 的 AI 会先写测试，B 的不回"，写出来的代码风格不一致，review 的时候会很别扭。

建议三：周期性更新。

插件更新不算频繁，但也不建议装上就不管。隔一两周在插件面板里看一眼有没有新版本，有就更新。

建议四：可以尝试写团队专属 skill。

superpowers 的 skill 本质是 Markdown，格式也不复杂。你们团队如果有固定的发布检查清单、固定的 code review 标准，完全可以照着它的格式写成一个私有 skill。门槛比想象中低，收益却直接。

最后聊一点个人感受。我在两个中型项目里用了大概一个多月，最大的体会是：它把我从"给 AI 当监工"的状态里解放出来了。以前我每次都要在 prompt 里写一大段"你先分析需求、写测试、注意边界"之类的话，现在这些流程内化到了工具层，我只管提需求和 review 结果。如果你最近也在为 AI 写代码"时灵时不灵"头疼，建议直接装一个，从一个小需求开始，用两周，再决定要不要留下来。我自己是回不去了。