Superpowers：AI 智能体如何学会像真正的团队那样协作

Superpowers 让 Claude Code 像一个小团队那样工作：先设计，再计划，然后隔离实施，最后由不是作者本人的一方来评审。这篇文章讲这些技能实际做什么、这套模式在一次真实发布中发现了什么，以及什么时候它是大材小用。

编码智能体犯的大多数错误是流程错误，而不是智力错误。目标还没弄清楚，它就开始写代码；它在构建代码的同一个上下文里检查自己的工作；它什么都没运行，就报告“完成”。团队用角色分工来拦住这些问题：有人澄清需求，有人做计划，有人动手构建，另有人负责评审。

Jesse Vincent 的开源框架 Superpowers 把这些角色带进了 Claude Code。它已收录于官方 Claude 插件市场，插件页面显示安装量超过一百万次（截至 2026 年 10 月）。我从 2026 年 2 月开始使用它，目前是 6.4.1 版。

这些技能实际做什么

Superpowers 由技能组成：一些 Markdown 文件，Claude 会在情境匹配时自动加载。其中五个构成核心工作流，下面按它们 SKILL.md 文件里的写法来介绍：

一次真实运行：waiser.dev 的 SEO 发布

2026 年 10 月 6 日，我在自己的网站上完整跑了一遍这套模式。起因是 Google Search Console：已编入索引的页面从 60 个降到 40 个，“已抓取 - 尚未编入索引”从 9 个升到 29 个，另外还出现了一些指向奇怪 /blog/blog/ 网址的 404 错误。

先说明一点：我运行的不是 Superpowers 插件本身，而是 Claude Code 的工作流编排，也就是我之前在多次并行智能体运行中用过的那套。但模式是一样的：做计划、评审计划、隔离实施、评审改动。一共 13 次智能体运行：

1. 计划团队（3 + 1）：技术 SEO、页面优化与站点卫生、静态站点工程三位专家共提出 22 个任务，并对照代码、在浏览器里核实了各自的判断。一个主导智能体把它们整合成一次发布，分为两个工作包、十个任务。
2. 计划评审（2）：一位负责工程风险，一位扮演 SEO 怀疑者。两人的结论都是“approve with changes”。
3. 修订（1）：16 条评审意见中，主导者采纳了 13 条，部分采纳 1 条，另有 2 条附理由驳回。
4. 实施（2）：两位实施者处理严格分开的文件，因此没有冲突。
5. 改动评审（3）：计划符合度、SEO 验证、浏览器中的功能。
6. 修复（1）：一位修复者处理成立的问题。

最终，所有改动作为一个发布提交上线。

评审者发现了什么（节选）

• 一个会留下半截工作的生成器。一个新脚本把文章链接以静态方式写进三个博客索引页。两位计划评审者各自独立复现了问题：如果其中一个文件缺少标记，脚本仍会写入另外两个文件，然后才报告错误。现在它要么全部写入，要么一个都不写。这个问题在脚本进入代码仓库之前就被发现了。
• 一个顺序错误的发布脚本。生成器要等到一篇文章已被标记为“已发布”之后才运行。一旦它失败，发布就会停在半完成状态。现在顺序已调换，失败场景也测试过了。
• 一个不完整的修复。/blog/blog/ 404 的根源是中文页面缺少一个基础路径分支，这是我和 Claude 在主会话里找到的；两位计划者也同时得出了同样的原因。计划评审者随后指出，嵌套路径下的 404 页面仍然链接到 /blog/blog/。<base href="/"> 堵上了这个缺口。
• 一个陈年的移动端 bug。在 390 px 宽度下，页脚链接一直延伸到 x = 626 px。GitHub、LinkedIn 和邮箱都被截断，根本点不到。这个 bug 早在这次发布之前就存在，直到功能评审者才发现它。
• 一个被遗忘的副作用。发布脚本会重新生成索引页，却从未更新它们在站点地图中的 lastmod。已修复，并遵循“永不回退”的规则。

最有价值的发现，恰恰最让人不舒服。SEO 怀疑者反驳了计划的核心假设：静态链接并不能让索引恢复。28 个未编入索引的文章网址里，有 18 个早已有三个或更多静态链接；规律跟着文章的发布时间走，而不是跟着链接走。它认为真正的杠杆是对那些单薄的旧文章做一次内容审查。这篇文章也在它的清单上，当时大约只有 500 词。主导者接受了这一纠正，但拒绝把内容审查作为智能体任务：一篇文章是重写还是下线，属于编辑决策。这个问题被交到了我手上。这次重写就是我的回答。

修复者同样清楚自己的边界。它有意没有处理两条成立的意见：一条是对另一篇文章正文的修改，而已批准的计划把这类修改排除在外；另一条是修改项目中给智能体的指令文件，这只有我能批准。两条都附上理由交给了我。

真正改变了什么

1. 独立的上下文才是真正的第二意见。一位从没见过实施者思路的评审者，也不会有同样的盲点。
2. 在写代码之前评审，成本最低。上面五个 bug 中，有三个是在计划和一份参考脚本里发现的，而不是在生产代码里。
3. 角色胜过人数。风险评审者、怀疑者和功能测试者发现的是不同的问题。这和用 CrewAI 构建多智能体团队是同一个思路。
4. 用证据代替成功报告。实施者、评审者和修复者都附上了他们运行的验证命令：退出码、校验和、浏览器里的测量结果。
5. 目标和措辞的主人始终是人。智能体提供发现和选项，发布什么由我决定。

“Evidence before claims, always.”——verification-before-completion 的核心原则

代价是什么

根据 Claude Code 文档，每个子智能体（fork 除外）都从全新的上下文开始，需要时间来收集上下文，而且它发出的请求与主会话计入同一套用量限额。13 次智能体运行，意味着把代码重新读 13 遍。Superpowers 自己也说得很直白：子智能体驱动的方式每个任务、每次评审都要付出一个全新上下文的代价；原生方式更便宜、更快。

此外还有评审噪音。有两条意见被驳回，还有好几条只是细枝末节。必须有人评估每一条发现，而不是盲目照做。receiving-code-review 这个技能正是为此而设：先对照代码核实，再动手实施；有不同意见时给出技术理由，而不是客气地附和。还有，评审者主要只会发现被指派去找的东西。页脚 bug 只被那位在浏览器里按移动端宽度做了测量的评审者发现。

什么时候值得，什么时候不值得

值得的情况是：一旦出错代价高昂，而且会公开暴露。我的网站直接从 main 上线；一个只写了一半的脚本会立刻影响到每一位访客。同样值得的还有之后会无人值守运行的脚本，以及跨越许多文件的改动。

大材小用的情况：

• 只改一个文件的修复，或者一处文字修改。Superpowers 自己就为此准备了 Bounded 路径：在对话里给出简短设计，不写规格，也不写计划。
• 可行性问题。Spike 路径交付的是一个答案，而不是要保留下来的代码。
• 高度耦合的任务。这个技能只建议在任务基本相互独立时使用子智能体。
• 延迟很关键的时候。如果只是快速问一句，主会话更合适。
• 编辑决策。这类决定属于人。

我是怎么用的

# 从官方 Claude 插件市场安装
/plugin install superpowers@claude-plugins-official

# 或者：使用 Superpowers 自己的插件市场
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

1. 检查分类。一开始，Claude 会说明它把任务看作 Spike、Bounded 还是 Architectural。如果不对，立刻纠正。
2. 真的去读规格和计划。审批关卡是我贡献最大的地方。随手放行，你得到的就是被干净利落地实现出来的错误需求。
3. 有意识地选择执行方式。任务多、彼此独立、出错代价高：用子智能体驱动。任务少、彼此耦合：用原生方式，最后做一次评审。
4. 给评审者分配不同的角色。至少要有一位可以去挑战核心假设。
5. 要求提供验证命令。这类完成条件该怎么写，我在《用循环取代提示》一文里结合 /goal 讲过。

如今我在其他项目里也在用这套模式。

编写自己的技能

writing-skills 把编写新技能当作测试驱动开发来做：先让一个子智能体在没有该技能的情况下工作，并记下它用来绕过规则的借口；然后专门针对这些借口写出技能，再测试一次。技能的结构我在《Anthropic 关于 Claude Skills 的 33 页蓝图》里介绍过。

结语

Superpowers 并不会让模型变得更聪明。它拿走的是模型的捷径：设计之前不写代码，不在自己的上下文里评审，没有证据就不说“完成”。在我的 SEO 发布中，分工明确的角色发现了上面那五个 bug，其中三个早在计划阶段就被发现，还揭穿了一个错误的核心假设。代价是时间、token，以及亲自评估每一条发现的责任。为一个错别字这么做不值得；但凡是会无人值守运行、或者直接上线的东西，都值得。

用到的工具：

想为你的团队引入 AI 驱动的开发工作流？联系我。我可以帮你落地量身定制的解决方案。