Superpowers：从想法到交付，AI Agent 的工业化开发流水线

卖兔子的小男孩

485人浏览 · 2026-06-14 12:40:05

卖兔子的小男孩 · 2026-06-14 12:40:05 发布

Superpowers：从想法到交付，AI Agent 的工业化开发流水线

你的 AI 编程 Agent 能写代码，但它能交付软件吗？

一、AI 写代码很快，但然后呢？

如果你用过 AI 编程助手，大概率遇到过这种情况：

你说"帮我做一个登录功能"。Agent 二话不说开始写代码——login.js、表单验证、API 调用——五分钟甩给你 300 行。你一看，密码明文存储，没有 session 管理，错误处理是 console.log('error')，所有逻辑堆在一个文件里。

然后你开始漫长的修修补补。第二轮让它加错误处理，它改了三处漏了两处。第三轮让它写测试，它先补了代码再贴测试，测试质量约等于没写。

Agent 不是不会写代码。它缺的是在正确的时间做正确的事——先搞清楚你到底要什么，再做设计，再写测试，再写代码，再审查，最后验证。这套流程在真正的工程团队里是基本功，但 AI Agent 默认不会这么做。

Superpowers 做的事情就是把这套工业流程焊在 Agent 身上——不是"建议"，是"强制执行"。下面走一遍完整流程，你就能看到它和普通 Agent 的差距在哪。

二、四大核心理念

Superpowers 的一切设计都围绕四个原则展开：

🔴🟢 测试驱动开发 (TDD)

先写失败的测试 → 写最少的代码让测试通过 → 重构。 不是"建议"，是强制。任何在测试之前写的代码都会被删除。这不是迂腐——它确保每一行代码都在解决一个被明确定义的问题。

🧩 系统性优先

流程打败猜测。 遇到 Bug？不是先加几个 console.log 碰运气，而是走四阶段根因分析（现象复现 → 调用链追溯 → 最小复现 → 修复验证）。做新功能？不是直接写代码，而是先出设计文档 → 实施计划 → 分解任务。

🔬 证据优先

验证通过才算完成。 "看起来可以了"不算。"我觉得修复了"不算。Superpowers 要求 Agent 在声称完成之前实际运行验证命令并确认输出。没有证据，就没有完成。

🪶 极简主义 (YAGNI)

你不会用到它的。 不写任何没被要求的功能。不为"未来可能需要"做抽象。代码越少，Bug 越少。Superpowers 的设计审查环节会主动砍掉过度设计。

三、实战：从一个想法开始

让我们用一个具体的例子来看看 Superpowers 的完整流水线。假设你对 AI Agent 说：

“我想做一个 TODO 应用。”

如果是一个普通的 AI 编程助手，它可能已经开始写 index.html 了。

但开启了 Superpowers 的 Agent，会走下面这条路：

🧠 第一步：Brainstorming（头脑风暴）

Agent 不会写一行代码。它会开始问你问题——而且每次只问一个。真正的对话大概是这样的：

Agent: 在开始之前我想先搞清楚——这个 TODO 应用是给谁用的？个人随手记，还是团队协作？

我: 个人用的，简单就好。

Agent: 明白了。那数据你希望怎么存？

A) 浏览器 localStorage（最简单，但换设备就没了）

B) 后端服务 + 数据库（可以跨设备同步）

C) 还没想好

我: A 吧，先简单点。

Agent: 好的。需要的功能你过一下——添加、删除、标记完成，这三项够吗？还是也需要编辑文字、拖拽排序、设置截止日期这些？

我: 编辑文字要的，拖拽排序也要。截止日期不用。

Agent: 清楚了。那筛选呢？全部 / 进行中 / 已完成这三种视图要不要？

我: 要的。

注意到了吗——每次一个问题，每个问题都有选项。 不是"你想要什么功能？"这种开放式问题让你想半天，而是把决策空间缩小到几个具体选项里。

问完之后也不是直接开干。Agent 会把你确认过的所有内容写成一份设计文档，然后逐节念给你听，问你这部分对不对。你觉得 OK 了它才继续下一节。

这个过程大约持续几分钟，最终输出是一份保存在 docs/superpowers/specs/ 下的设计规范文档。这份文档就是你后面所有开发工作的唯一真相来源。

设计文档写完后，Agent 还会自己做一轮"自我审查"——检查有没有矛盾的地方、有没有模糊的表述、需求范围是不是太大了应该拆成多个子项目。这些检查大概半分钟，但经常能揪出一些你我都没想到的问题。在浪费代码之前把隐患消灭在文档里，这笔账怎么算都是赚的。

🌿 第二步：Worktree 隔离

设计通过后，Agent 不会直接在你的主分支上动手。它会先问你：“要创建独立分支来开发吗？”

你同意之后，Agent 会自动创建一个 Git Worktree——一个和主分支完全隔离的工作目录。然后在新分支上跑项目初始化、安装依赖、验证现有测试全部通过。

这时候你主分支上的代码纹丝不动。如果你同时在修另一个 Bug，两个工作区互不影响。开发过程中随时可以切回主分支看原来的代码，不必担心被改得面目全非。

我以前经常在主分支上直接开发，写到一半发现方向错了，回滚也麻烦。有强制隔离流程逼着，其实省了后面擦屁股的时间。

📋 第三步：Writing Plans（编写实施计划）

Agent 把设计文档拆解成一系列 2-5 分钟的小任务。每个任务精确到：

具体修改哪个文件的哪些行
需要写什么测试
验证标准是什么
依赖哪些前置任务

一份典型的计划长这样：

- [ ] Task 1: 创建 TodoItem 数据模型和单元测试
- [ ] Task 2: 实现 TodoList 存储逻辑（localStorage）
- [ ] Task 3: 编写添加/删除/切换完成的集成测试
- [ ] Task 4: 实现 TodoInput 组件
- [ ] Task 5: 实现 TodoList 渲染组件
- [ ] Task 6: 实现过滤功能（全部/进行中/已完成）
- [ ] Task 7: 端到端测试

每个任务都小到可以一口气完成，大到有意义。

💡 计划写完后同样会做自我审查：有没有遗漏的需求？有没有不明确的描述？文件结构是否合理？

🔨 第四步：Subagent-Driven Development（子代理驱动开发）

这是 Superpowers 最强大的部分。Agent 将每个任务派发给一个全新的、独立的子 Agent：

主 Agent:"Task 3: 实现 TodoList 存储逻辑，文件路径 src/storage.js"
  │
  ├── 子 Agent A: 接到任务 → 读取上下文 → 写测试（红）
  │                  → 测试失败 ✅ → 写实现（绿）
  │                  → 测试通过 ✅ → 自检 → 报告: DONE
  │
  ├── 审查 Agent B: 对照设计规范逐条核对
  │                  → 通过✅
  │
  └── 审查 Agent C: 检查代码质量
                     → 通过✅
                     → 任务 3 完成，继续任务 4

每一个子 Agent 都带着干净的上下文——只看到和它手头任务相关的信息，不受前一个任务的历史包袱影响。

而且这些子 Agent 之间可以并行工作。如果任务 5 和任务 6 没有依赖关系，就同时执行。

💡 在理想情况下，Claude 可以在这种模式下自主工作 1-2 小时，不需要人工干预。它就像一支微型的工程团队。

👀 第五步：Code Review

每个任务完成后，Superpowers 会派两个独立的子 Agent 来审查——不是一个 Agent 看两次，是两个不同的视角。

第一个只审一件事：代码有没有严格按设计文档来做。 这个审查 Agent 被刻意写成"怀疑论者"——它不相信实现者的自述，自己去读代码对照设计文档。常见发现：

“设计文档说只做邮箱密码登录，你怎么把手机验证码登录也写了？删掉。”
“规范里要求密码最少 8 位，你这里没校验。补上。”
“设计文档没提记住密码功能，但你实现了。这是多余的——用户没要求。”

第二个审代码质量——命名是否清晰、测试覆盖是否充分、有没有潜在的性能问题或安全漏洞。

两个审查都过了才算完成。有一个没过，实现者就得回去改，改完再审，循环到通过为止。

实际用下来，这个机制拦住最多的问题是 Agent 过度实现——你让它做 A，它顺手把 B、C、D 也"预埋"了，代码量翻倍但一半用不上。没有审查环节，这些多余代码就悄悄留在项目里了。

🔴🟢 全程 TDD

在整个实现过程中，TDD 不是"推荐做法"而是硬性要求：

写失败的测试 → 运行测试 → 确认失败（红色）
写最少代码让测试通过 → 运行测试 → 确认通过（绿色）
提交
重构改进 → 运行测试 → 确认仍然通过 → 提交

在测试通过之前写的任何实现代码都会被删除。 这听起来极端，但这就是工业级软件工程的标准。

✅ 第六步：Verification & Finish

所有任务跑完之后，Superpowers 会做最后一轮验证——跑全部测试、确认 lint 通过、列出所有改动的文件摘要。

然后问你要怎么处理：合并到主分支、提交 PR、留在分支上、还是直接丢弃。

这里有一个细节值得单独说：Superpowers 的 verification-before-completion 技能强制 Agent 在说"完成了"之前必须贴出实际运行的验证输出。它不会接受"测试应该通过了"这种表述——你必须跑给我看。这条规则简单粗暴，但堵住了 AI Agent 最常见的毛病：自信地宣布完成，实际上测试都没跑过。

四、技能全景：14 项能力覆盖完整生命周期

上面走完的流程里涉及了大部分技能，但还有一些没提到。下面这张表列出了 Superpowers 全部 14 项技能——什么时候触发、解决什么问题、不用它会怎样。

技能	什么时候触发	解决什么问题	没有它的话…
brainstorming	你提出任何新功能 / 改动需求时	Agent 不问清楚就写代码，方向偏了推倒重来	写了 500 行发现不是你要的
writing-plans	设计文档确认通过后	把模糊的"做这个功能"变成精确的任务清单	Agent 写到一半不知道下一步该干嘛
using-git-worktrees	开始写代码之前	在主分支上直接开发，改乱了回不去	切不回原来的代码，只能 `git stash` 救火
test-driven-development	每个任务写代码时	先写代码再补测试，测试质量差、覆盖率低	测试是装饰品，重构时心里完全没底
subagent-driven-development	有子 Agent 能力的平台上执行计划时	每个任务用独立 Agent，干净上下文 + 自动审查	Agent 被前面任务的错误假设带偏
executing-plans	没有子 Agent 能力的平台上（Gemini CLI 等）	在受限平台上也能按计划批量执行	没有子 Agent 的平台用不了 subagent 模式
dispatching-parallel-agents	多个任务之间没有依赖关系时	任务串行执行太慢，明明可以同时做	一个任务等另一个，时间白白浪费
requesting-code-review	每个任务实现完成后	代码没有经过审查就合并——过度实现、漏需求、埋 Bug	多余的代码留在项目里慢慢腐烂
receiving-code-review	你或者同事对 Agent 的代码提了 review 意见	Agent 盲目接受所有意见，不加判断就改	改了一个问题引入三个新问题
systematic-debugging	遇到 Bug 时	四阶段根因分析：复现 → 追溯调用链 → 最小复现 → 修复验证	`console.log` 猜谜，修 A 坏 B
verification-before-completion	Agent 准备说"完成了"的时候	只是觉得修好了不算，跑出结果才算	Agent 自信地说 Done，实际测试全红
finishing-a-development-branch	所有任务完成、测试全绿后	做完了不知道该合并还是提 PR，分支越堆越多	代码写完了但卡在"怎么合进去"这一步
writing-skills	你想自定义或创建新技能时	帮你按照最佳实践写技能、测试技能	自己写的 skill Agent 不认，触发不了
using-superpowers	会话启动时	引导 Agent 发现和使用整个技能体系	Agent 不知道有这些技能可以用

上面流程里重点展示了前 8 个（brainstorming 到 code review），但后面几个同样关键。说两个容易被忽视的：

receiving-code-review — 这个技能解决的是"Agent 太听话"的问题。你提了一条 review 意见，普通 Agent 会直接照改，哪怕你的意见在技术上不对。这个技能要求 Agent 先做技术判断，确认意见合理再改，不合理要有理有据地讨论。不是抬杠，是工程师之间的正常代码审查对话。

systematic-debugging — 包含了三个子技能：root-cause-tracing（沿调用链追溯根因）、defense-in-depth（多层防御式修复）、condition-based-waiting（用条件轮询替代盲目等 timeout）。这套东西来自真实调试场景的总结，不是空泛的"先分析再修复"。

writing-skills — 元技能。Superpowers 的技能体系是开放的，你可以用这个技能来创建自己的技能。它自己吃自己的狗粮——创建新技能的过程本身就走 TDD + 审查流程。

五、九大平台，一套技能

Superpowers 的技能只写一次，到处运行。目前支持的平台：

平台	安装方式	特点
Claude Code	`/plugin install superpowers@claude-plugins-official`	完整子代理支持，体验最佳
Codex CLI	`/plugins` 搜索 superpowers	OpenAI 官方 CLI
Codex App	插件市场一键安装	桌面端完整体验
Gemini CLI	`gemini extensions install`	Google 生态
OpenCode	npm 包 + 配置	开源选择
Cursor	`/add-plugin superpowers`	IDE 内集成
GitHub Copilot CLI	`copilot plugin install`	微软生态
Factory Droid	`droid plugin install`	新兴平台

技能会自动检测当前平台，适配可用的工具和能力。比如在没有子 Agent 支持的平台上，自动降级到批量执行模式。

六、深入：Subagent 引擎如何工作

Superpowers 真正的"超能力"来自它的 Subagent 驱动引擎。这里稍微深入一点：

为什么需要独立子 Agent？

普通 AI 编程助手在长对话中会"中毒"——早期的错误假设、妥协决策、技术债务会污染后续每一个决策。上下文窗口越塞越满，Agent 越来越"累"。

Superpowers 的做法是：每个任务派给一个全新的子 Agent。干净的上下文，只包含当前任务需要的设计规范和文件路径。

实现者状态协议

每个子 Agent 完成任务后必须报告状态：

状态	含义	主 Agent 的处理
`DONE`	完成，测试通过	进入审查阶段
`DONE_WITH_CONCERNS`	完成了但有顾虑	审查时重点关注疑虑点
`BLOCKED`	被阻塞	分析原因，可能需要拆分任务或升级模型
`NEEDS_CONTEXT`	需要更多上下文	补充信息后重新派发

这不是简单的"成功/失败"——它是一个工程团队的协作协议。

并行处理

当计划中的任务没有相互依赖时，Superpowers 会同时派出多个子 Agent 并行工作。一个在写后端 API，一个在做前端组件，一个在写数据库迁移——同时进行，互不等待。

审查不是走过场

审查 Agent 被刻意设计成怀疑论者：

“规范说你只改 3 个文件，你改了 5 个——为什么？”
“这段逻辑的边界条件你测了吗？”
“你引入了未使用的依赖——删掉。”

审查不合格就回去重做。这不是形式主义——这是在模拟一个有经验的 Tech Lead 的 Code Review。

七、装上试试

Claude Code 里一行命令：

/plugin install superpowers@claude-plugins-official

其他平台去 github.com/obra/superpowers 看对应说明，支持 Claude Code、Codex CLI / App、Gemini CLI、OpenCode、Cursor、GitHub Copilot CLI、Factory Droid 八个平台。

装好之后验证：开一个干净会话，说"帮我做一个 React 待办列表"。如果 Agent 没有直接写代码，而是开始反问你需求——Superpowers 已经生效了。

最后说一句实在的。Superpowers 不会让你的 Agent 变聪明，它只是让你的 Agent 变得有纪律。就像你不会因为有了 Git 就写出更好的代码，但 Git 让你不会弄丢代码、不会覆盖别人的改动、不会在错误的方向上越走越远。Superpowers 对 AI 编程做的事情，和 Git 对代码管理做的事情差不多——把那些你知道该做但经常跳过的事情，变成默认选项。

Superpowers 由 Jesse Vincent 和 Prime Radiant 团队开发维护
GitHub: github.com/obra/superpowers
Discord: discord.gg/35wsABTejz
更新通知: primeradiant.com/superpowers