Superpowers：给你的 Agent 装上一套可靠的研发流程
我用 Superpowers 一段时间了，现在天天都再用，感觉非常棒！之前各种跑偏、失控，现在通过这个工具都实实在在的优化了工作流程。最直观的感受不是“代码写得更快”，而是 Agent 不再一接到需求就冲去改文件。它会先问清楚目标，给出设计，写计划，再进入实现、测试和审查。
这件事听起来有点慢，却恰好解决了 AI 编程里最常见的返工来源：需求还没说透，方案还没选定，代码已经写了一半。模型的生成能力一直在进步，但研发里的问题并不只有生成。边界条件、旧逻辑兼容、测试证据和交付验收，都需要有人守住。
这也是我建议每个使用 Coding Agent 的开发者都装上 Superpowers 的原因。即使你不打算把代码直接交给 Agent 生成，也可以让它负责需求澄清、方案设计、实施计划和代码审查。它不是替代工程师，而是把工程师本来就该走的流程，变成 Agent 不容易跳过的动作。
本文基于 obra/superpowers 官方仓库 与其 README 编写。安装入口和 skill 行为会随版本演进，实际操作时以官方文档为准。
它不是一个提示词，而是一套开发方法论
官方对 Superpowers 的定义很准确：它是一套面向 Coding Agent 的完整软件开发方法论，由一组可以组合的 skills，以及确保 Agent 使用这些 skills 的启动指令构成。
这里有两个容易混淆的点。
第一，Superpowers 不是模型。它不替换 Claude、Codex、Cursor 或 Gemini 背后的模型能力；它解决的是模型接到任务后按什么顺序工作。
第二，它也不是某一个名为 superpowers 的万能 skill。更准确地说，Superpowers 是一个技能包，里面有 brainstorming、writing-plans、test-driven-development、systematic-debugging 等具体 skill。它们各自约束一段流程，组合起来才构成完整方法。
flowchart LR
A[提出需求] --> B[brainstorming<br/>澄清需求与设计]
B --> C[writing-plans<br/>形成实施计划]
C --> D[实现任务<br/>人或 Agent 执行]
D --> E[测试与代码审查]
E --> F[完成前验证与收尾]官方 README 的核心流程还包含 Git worktree、TDD、任务审查与开发分支收尾。它的中心思想不是“让 Agent 多干一点”，而是让每一阶段都留下下一阶段能检查的产物。
为什么 AI 编程容易跑偏
设想一个很常见的需求：给现有 Go 服务增加支付回调的幂等保护。
如果只给 Agent 一句“把支付回调做成幂等”，它很可能立刻搜索 handler，新增一个 Redis key，然后告诉你完成了。可一个真正能上线的改动至少还要回答：幂等键由谁生成？重复请求该返回成功还是冲突？锁的过期时间怎么定？数据库已成功、消息还没发出时怎么办？已有回调会不会被改坏？测试覆盖了哪些重试和并发路径？
这些问题不是模型不会写代码，而是它们在“直接开始实现”的路径上太容易被省略。
Superpowers 的做法是把这条路径拆开：先在设计阶段把假设摆出来，再把每个决定落为可执行计划，最后用测试、审查和验证去检查结果。这样一来，Agent 不是依赖上下文里模糊的记忆完成任务，而是依赖一串明确的约束和证据推进任务。
核心 skills 怎样接力
Superpowers 的 skill 很多，但第一次接触不需要逐一背名称。先抓住下面几组职责就够了。
| 阶段 | 代表 skill | 它留下什么产物 |
|---|---|---|
| 理解问题 | using-superpowers、brainstorming | 明确的目标、边界、备选方案和已确认设计 |
| 规划实现 | writing-plans | 按任务拆分的文件、接口、测试与验证命令 |
| 执行开发 | executing-plans、subagent-driven-development | 可追踪的任务进度、实现结果和审查记录 |
| 保证正确 | test-driven-development、systematic-debugging、verification-before-completion | 失败测试、通过测试、根因与验证证据 |
| 交付收尾 | requesting-code-review、finishing-a-development-branch | 审查结论、分支处理和交付选择 |
using-superpowers：先判断流程，再动手
这是元 skill。它要求 Agent 在回应或行动前先检查当前任务适合哪些 skill。它的意义很朴素：别把“快速答一句”当成可以跳过流程的理由。
例如，发现缺陷时应该进入系统化排障；新增功能时先做设计；有设计后再写实施计划。不同任务走不同路径，而不是套同一段万能提示词。
brainstorming：把模糊需求变成可确认的设计
官方流程里，新增功能不会直接编码。brainstorming 会先了解项目上下文，一次问一个关键问题，比较方案，分段展示设计并等待确认；确认后的设计会被保存为文档。
这一层尤其适合需求仍带着“我大概想要”的阶段。真正重要的不是多问几个问题，而是把取舍提前：范围是什么，不做什么，哪种方案为什么被选中，验收时看什么。
writing-plans：把“方案正确”变成“能被执行”
设计确定后，writing-plans 负责产出实施计划。官方规范要求计划精确到文件路径、接口、测试代码、运行命令和预期结果，并把每个任务切成短小、可独立验证的步骤。
这份计划不是项目管理文档，而是给实现者的操作说明。它把“加一下重试机制”改写成“在哪个文件写哪个失败测试、以什么输入复现、最小实现是什么、运行什么命令确认通过”。计划写得足够具体，后面的实现、审查和协作才有共同依据。
执行模式：自己写，还是交给子代理
计划完成后，官方提供两条执行路径。
executing-plans：在当前会话中分批执行，设置人工检查点。subagent-driven-development：按任务派发新的实现子代理，并在任务后做规格符合性与代码质量两阶段审查。
两种路径不是高低之分。一个改动范围小、上下文强耦合的任务，当前会话直接执行通常更自然；任务多且可拆分、需要严格复核时，子代理驱动开发能让每个任务拥有更集中的上下文和审查门槛。
TDD、调试与验证：不让“看起来完成”混进交付
官方把 test-driven-development、systematic-debugging 和 verification-before-completion 单独列为核心能力，说明它并不把测试当作收尾动作。
其中，TDD 强调先看到失败，再写最小实现，再看到通过；系统化调试要求先找根因而不是直接打补丁；完成前验证则要求在宣布修复或完成之前拿到证据。它们共同解决的是同一个问题：Agent 的自然语言结论不能代替测试和实际检查。
即使不让 Agent 写代码，也值得使用
Superpowers 运行在支持 skills 的 Coding Agent 中，因此完全不用 AI Agent 的开发者无法直接使用它。但“使用 Agent”不等于“把代码生成外包给 Agent”。
我更推荐把它分成两种使用姿势：
| 你的工作方式 | Superpowers 可以承担的工作 |
|---|---|
| 代码主要自己写 | 梳理需求、比较方案、生成实施计划、补测试清单、做代码审查与交付检查 |
| Agent 参与实现 | 在上述基础上，按计划拆任务、执行实现、运行测试、进行阶段审查 |
前一种方式对传统开发者尤其友好。你仍然掌握代码和决策，只是让 Agent 在最容易遗漏的地方充当一个不嫌麻烦的流程执行者。后一种方式则更适合范围清晰、可测试、可以逐步验收的开发任务。
老墨说： 我不会把“让 Agent 写更多代码”当作首要目标。先让它把设计、计划和验证做扎实，代码生成才不会变成后期返工的放大器。
在 Codex 中安装
Superpowers 的安装取决于你使用的 Agent 容器。同一个人同时使用多个容器时，官方要求分别安装。
对于 Codex，官方 README 当前给出的路径是：
| 使用环境 | 官方安装方式 |
|---|---|
| Codex App | 在侧边栏打开 Plugins，在 Coding 分类找到 Superpowers，点击 + 并按提示完成安装。 |
| Codex CLI | 输入 /plugins，搜索 superpowers，选择 Install Plugin。 |
Claude Code、Cursor、Gemini CLI、GitHub Copilot CLI、OpenCode、Pi 等容器也有各自的安装入口，命令不要混用，直接查阅 官方安装章节 最稳。
Superpowers 目前已经纳入Codex官方插件目录，因此在 /plugins 中搜索并安装即可。
装好后，不需要专门背一长串触发命令。官方设计是让 Agent 自动检查和使用适合当前任务的 skill。第一次可以挑一个边界适中的真实需求，例如“给一个已有 API 增加分页参数、输入校验和回归测试”，然后正常描述目标。
一个健康的首次体验通常会看到这些信号：
- Agent 没有立刻开始修改文件，而是先确认范围和已有约束。
- 它会提出方案并等待设计确认。
- 设计通过后会产出可执行计划，而不是一句“我开始做了”。
- 实现过程中会围绕测试、审查和验证推进，而不是只给出改动摘要。
如果你只是想先试水，可以让 Agent 只完成设计和实施计划，代码仍由自己写。等你熟悉产物质量和节奏，再考虑把实现任务交给 Agent。
让它适配你的项目，而不是反过来
Superpowers 提供的是方法论，不是你项目的全部规范。项目的语言、目录、提交方式、测试命令、接口兼容要求，仍应写在项目自己的 AGENTS.md、CLAUDE.md 或等价规则文件中。
我会把“所有设计、计划、进度报告和代码注释使用简体中文；命令、代码标识符与协议名称保留英文”这类约束明确写下来。这样可以避免英文模板标题与中文项目说明混在一起。类似地，如果团队要求聚合提交，也应写进项目规则或实施计划的全局约束，而不是默认接受某个 skill 的提交节奏。
这些不是 Superpowers 的缺陷，而是所有通用工作流工具都会遇到的边界：通用方法负责把事情做稳，项目规则负责告诉它“稳”在这个仓库里具体是什么意思。
还有一点要特别说明，superpower会按照约定工作流程帮你逐步实现目标，而不是一上来就开始写代码，所以你可能会觉得比较繁琐，与之前相比很不习惯，但是这需要一点时间去适应，熟悉了之后，你会发现越用越顺手。
从一个中等任务开始
不要一上来就拿它重构整个系统，也别用改一行配置来判断它是否值得。找一个包含需求判断、代码实现和测试验证的中等任务，完整走一次“设计 - 计划 - 实现 - 验证”。
你会很快分辨出它适合解决什么：它不会替你做产品决策，也不会让模型永远正确；但它能把很多本来依赖个人记忆和临场发挥的工程动作，变成可讨论、可检查、可复用的过程。
对我来说，这已经足够构成安装理由。AI 编程真正稀缺的不是再多一个会补全代码的工具，而是一套能让速度不把质量甩在身后的工作方式。
参考资料
关注公众号：极客老墨
更多 AI 应用开发、工程实践和效率工具分享，欢迎扫码关注。
