Superpowers 学习指南：让 AI 编程代理开始按工程流程做事

最近我认真看了一遍 obra/superpowers 这个仓库。

如果你最近正好在重度使用 Claude Code、Codex、Cursor Agent 这类工具，你大概见过一种很熟悉的体验：

• 你刚说完“做个功能”

• Agent 已经开始改文件

• 代码看起来写得很快

• 但需求没问清、设计没定、测试没补、review 也没过

Superpowers 想解决的，恰恰就是这类“动手太快、流程太薄”的问题。

第一眼看过去，你很容易把它误解成又一个“AI 编程助手增强包”：

• 帮 Claude Code 更强一点

• 给 Codex 多装一些 skill

• 给 Cursor 多加几条 prompt

但如果你真的把 README 和里面几份关键 skill 看下去，就会发现它的野心完全不是“再补几个能力”。

它真正想做的，是另一件事：

把 AI 编程代理从“会写代码”，改造成“会按工程流程做事”。

这也是为什么我觉得，这个仓库很值得单独写一篇讲解文章。

因为今天很多人讨论 AI Coding Agent，讨论的重点通常还是：

• 哪个模型更强

• 哪个 IDE 集成更顺

• 哪个 Agent 会调更多工具

• 哪个多代理框架更炫

但 Superpowers 把问题换了一个方向。

它问的不是：

Agent 能不能写代码？

而是：

Agent 有没有像一个靠谱工程团队那样，先澄清需求，再做设计，再拆计划，再执行，再测试，再评审，再收尾？

这两个问题看起来很像，其实差得非常远。

它到底是什么

用仓库自己的话说，Superpowers 是一套完整的软件开发工作流，构建在一组可组合的 skills 和一些初始化指令之上，目标是让你的 coding agent 自动进入正确流程。

这句话如果翻译成人话，大概可以理解成：

它不是一个单点能力插件，而是一套给 Agent 装上的“开发方法论操作系统”。

这里面最关键的不是某一个 skill，而是整套系统的组织方式：

• 什么时候先别急着写代码

• 什么时候必须先做设计

• 什么时候该拆计划

• 什么时候该上子代理

• 什么时候必须做 TDD

• 什么时候必须停下来做 code review

• 什么时候才算一个开发分支真正收尾

也就是说，它想控制的不是“生成哪段代码”，而是“整条开发链路该怎么走”。

Superpowers 不是让 Agent 多写一点代码，而是改掉它默认的做事顺序

如果你第一次接触它，先记住一件事

Superpowers 首先是一个仓库化的 workflow 系统，不是一个独立运行的 Agent 产品。

它本质上提供的是：

• 一组可以被宿主发现和触发的 skills

• 一套围绕软件开发流程组织起来的默认规则

• 一些针对不同宿主的接入方式

所以你在看这个仓库时，最好的理解方式不是：

“它能替我多写多少代码？”

而是：

“它能不能把我的 Agent 训练成一个更像工程团队成员的执行者？”

为什么这个仓库值得认真看

我觉得最重要的原因只有一个：

它把 AI 编程从“能力问题”，往“流程问题”推进了一步。

很多 AI 编程产品今天的问题，不是它们完全不会写，而是它们太容易直接写。

用户说一句“帮我做个功能”，它们就开始：

• 猜需求

• 直接改文件

• 顺手写一堆没有验证的实现

• 最后告诉你“已经完成”

这类体验第一次看很爽，但做稍微复杂一点的真实项目时，问题就会非常集中地冒出来：

• 需求根本没讲清楚

• 设计还没定就开始堆实现

• 计划没有粒度

• 改动彼此耦合

• 测试和验证滞后

• 代码 review 变成最后才做的补救

Superpowers 的切入点，正好就是这些问题。

它不是在说“让模型更聪明一点”，而是在说：

先别让模型乱动。先让它学会按流程动。

这套系统是怎么组织工作的

Superpowers README 里列了一条非常完整的基础工作流，我觉得这是整仓库最值得看的部分。

它的大致顺序是这样的：

1. brainstorming

2. using-git-worktrees

3. writing-plans

4. subagent-driven-development 或 executing-plans

5. test-driven-development

6. requesting-code-review

7. finishing-a-development-branch

如果只看名字，你可能会觉得这不就是常见的软件工程步骤吗？

对，恰恰因为它看起来像常识，才说明这个仓库真正高明的地方，不在“发明了新概念”，而在于：

它试图把这些原本靠人类自觉维持的工程纪律，变成 Agent 的默认行为。

下面我按学习价值最大的角度，简单拆一下这 7 步。

Superpowers 的七段开发工作流

第一阶段：先把需求和设计讲清楚

brainstorming

这个 skill 的核心思想很简单：

不要一上来写代码，先把用户真正想做的事情问清楚。

从 README 的描述看，它会做几件事：

• 把模糊想法往清晰规格里逼

• 讨论备选方案

• 分块展示设计，让用户逐段确认

• 最后保存设计文档

这一步对人类工程师来说很熟悉，但对很多 AI 编程体验来说其实非常反直觉。

因为它意味着：

用户说“做 X”，Agent 不应该立刻开始做 X。

它应该先停下来，把“X 到底是什么”问清楚。

这也是我觉得 Superpowers 最像“工程负责人思路”的地方。

第二阶段：不要在主工作区里直接乱改

using-git-worktrees

这是另一个我很喜欢的设计。

很多 AI 编程代理的问题，不只是代码质量，而是上下文污染和工作区污染。

Superpowers 的做法是：

• 设计通过后

• 新建隔离 workspace

• 切新分支

• 跑项目 setup

• 先确认测试基线是干净的

这其实是在帮 Agent 养成一种习惯：

不是在当前目录“试试看”，而是在隔离环境里负责任地动手。

为什么这一步重要？

因为一旦开始引入子代理、批量任务和并行执行，工作区边界就会变得非常关键。没有 worktree 这种隔离层，后面的流程纪律很容易被上下文和文件状态打穿。

第三阶段：把工作拆成“可以交给低配执行者”的计划

writing-plans

README 里有一句话我印象很深：

它会把计划写得足够清楚，让一个“热情但判断力差、没有项目上下文、还不喜欢测试的初级工程师”也能照着做。

这句话其实很毒，但也非常精准。

因为今天很多 Agent 失败，不是因为它们完全不会编码，而是因为任务说明太模糊。

Superpowers 在这里强调的不是“大方向计划”，而是：

• 任务要拆得足够小

• 一般是 2 到 5 分钟级别

• 每个任务要给精确文件路径

• 要给完整代码要求

• 要给验证步骤

这其实是在把计划从“人类读得懂”推进到“低上下文执行者也能不跑偏”。

而今天的 Agent，本质上就很像这种执行者。

第四阶段：不是你自己做，而是组织子代理做

subagent-driven-development

这个仓库真正有“时代感”的地方，在这里。

它并不满足于“主代理自己把活干完”，而是明确把执行阶段做成：

子代理驱动开发。

从 skill 的设计看，它的基本模式是：

• 每个任务派一个新的子代理

• 子代理先实现

• 然后派一个 spec reviewer 审是否符合规格

• 再派一个 code quality reviewer 审代码质量

• 通过后再进入下一个任务

这套东西听起来很重，但它解决的是一个真实问题：

当 Agent 开始能长时间自主工作时，最怕的不是它不干活，而是它一路偏航，还没人拦它。

Superpowers 的做法，本质上是在给子代理流水线加两层质检：

• 第一层看“做没做对”

• 第二层看“做得好不好”

这比“让一个大模型从头做到尾然后相信它”要稳得多。

第五阶段：它对 TDD 的态度非常强硬

test-driven-development

如果你只看 README，有一个点会非常明显：

Superpowers 不是“建议你最好测一下”，而是很强势地要求 RED-GREEN-REFACTOR。

也就是：

1. 先写失败测试

2. 看到它真的失败

3. 再写最小实现

4. 看到它通过

5. 再重构

它甚至强调，会删掉那些“先写代码、后补测试”的内容。

这件事很多人会觉得过于理想主义，但我反而觉得这正是它最值得学习的地方。

因为对 AI 来说，TDD 的价值可能比对人还大。

原因是 AI 最擅长的事情之一，就是非常流畅地写出看起来合理、但没有被验证过的代码。

所以如果你不给它一个严格的外部约束，它会天然滑向“先实现再说”的路径。

而 Superpowers 很明显是在试图用流程把这种滑坡扳回来。

第六阶段：Code Review 不是可选项

requesting-code-review

很多团队的评审流程之所以失效，是因为 code review 发生得太晚。

Superpowers 这里的思路是把 review 插到任务之间，而不是最后统一做。

它要求：

• 按严重程度报告问题

• 严重问题阻塞后续推进

也就是说，这套系统并不允许“先一路写完，再最后一起补锅”。

这和很多 AI Coding Demo 很不一样。

很多演示视频里，Agent 看起来一路高歌猛进，很少有人展示：

• 它在哪里被 review 挡下来了

• 它在哪里因为 spec 不一致返工

• 它在哪里因为质量问题被打回

但真实工程里，恰恰是这些摩擦决定了最后结果是不是可用。

第七阶段：完成开发不是“代码写完”，而是“分支正确收尾”

finishing-a-development-branch

这一层很容易被忽略，但非常体现仓库作者的工程思维。

很多 Agent 在“做完”之后就停了。

但真正的软件开发收尾通常还包括：

• 最终测试确认

• 分支处理

• 合并或提 PR 的选择

• 保留还是丢弃工作区

• worktree 清理

这说明 Superpowers 想覆盖的并不是“编码片段”，而是一个完整的开发闭环。

它最特别的一点：技能不是可选提示词，而是强制流程

这个仓库里还有一个很值得注意的 skill，叫 using-superpowers。

如果你只把它看成“使用说明”，你会低估它。

它真正扮演的角色，更像是整个系统的守门员。

从这个 skill 的描述可以看出来，它的态度非常强硬：

• 任何对话一开始都要先检查 skill

• 即使只有 1% 的可能适用，也必须调用 skill

• 先检查 skill，再做任何事，包括澄清问题

这背后其实是在解决一个现实问题：

就算你给 Agent 装了一堆好 skill，如果它不主动用，最后也会退回成默认那种“想到什么先做什么”的行为。

所以 using-superpowers 做的，不是增加新能力，而是给整套系统装了一个“流程调度器”。

这也是我觉得 Superpowers 和普通 prompt 集合最大不同的地方：

它不是把知识堆给 Agent，而是在试图接管 Agent 的行为顺序。

它为什么会同时支持 Claude、Cursor、Codex、OpenCode、Gemini

从仓库结构就能看出来，作者在认真做跨平台适配。

它顶层就有这些目录：

• .claude-plugin

• .codex

• .cursor-plugin

• .opencode

• skills

• agents

• commands

• hooks

这说明它并不是写死给某一个宿主用的。

它更像是在维护同一套“开发流程内核”，然后针对不同 Agent 平台做接入层适配。

对 Codex 来说，README 给出的安装方式尤其有意思。

它不是靠神秘 bootstrap，而是直接利用 Codex 的原生 skill discovery：

• clone 仓库到 ~/.codex/superpowers

• 再把 skills 目录通过 symlink 暴露到 ~/.agents/skills/superpowers

• 重启 Codex

也就是说，它并没有试图绕开平台机制，而是顺着平台原生的 skill 加载方式去接。

这也是一个很值得学的思路：

如果你想做一个跨平台 Agent workflow 项目，真正可持续的做法通常不是 hack 宿主，而是：

让同一套方法论核心，去适配多个宿主的原生扩展点。

如果你想亲手装一遍，最短路径是什么

如果你只是想快速理解 Superpowers 到底怎么工作，我建议直接从 Codex 这条路径看，因为它最容易把机制讲清楚。

仓库给出的 Codex 最短安装路径其实非常朴素：

1. clone 仓库到 ~/.codex/superpowers

2. 把 ~/.codex/superpowers/skills symlink 到 ~/.agents/skills/superpowers

3. 重启 Codex，让它在启动时重新发现 skills

如果你准备真的体验一遍，最关键的命令就是：

git clone https://github.com/obra/superpowers.git ~/.codex/superpowers

mkdir -p ~/.agents/skills

ln -s ~/.codex/superpowers/skills ~/.agents/skills/superpowers

然后重启 Codex。

如果你还想体验它的子代理工作流，仓库文档里还专门提醒了一件事：

[features]

multi_agent = true

也就是说，像 subagent-driven-development 这类技能，不只是“仓库里有就能用”，它还依赖宿主本身已经打开 multi-agent 能力。

这段安装说明很值得读，因为它把 Superpowers 的定位讲得很清楚：

• 它不是替代宿主

• 它不是自带一个新运行时

• 它是顺着宿主已经存在的 skill discovery 机制接进去

这也是为什么我会说，它最值得学习的不是某条 prompt，而是“怎么把方法论塞进宿主的原生扩展点”。

第一次体验 Superpowers，最适合从 Codex 这条路径入手

如果你想学它，最值得先学哪几件事

我不建议第一次就把整个仓库从头读到尾。

更有效的学习顺序其实是：

1. 先看 using-superpowers

先看它怎么定义“skill 必须先于行动”。

这一步能帮你理解：这个项目的目标不是给 Agent 补知识，而是先改它的行为顺序。

2. 再看 brainstorming 和 writing-plans

这两步决定了：

• 需求是不是被说清楚

• 计划是不是细到能交给低上下文执行者

你会很快看出来，Superpowers 最不信任的，其实不是模型能力，而是“模糊任务说明”。

3. 再看 subagent-driven-development

这一步最能体现它的时代感。

因为它不是让一个主代理硬着头皮从头做到尾，而是让主代理像一个协调者，去派发、验收、复审。

4. 最后再看 TDD、code review 和 branch finishing

这三步是在告诉你：

真正的工程纪律，不是“能把功能写出来”，而是“能不能在测试、评审和收尾里不失控”。

这个仓库最适合谁读

我觉得至少有三类人很适合认真看这个仓库。

1. 正在重度使用 AI 编程代理的人

如果你已经开始用 Claude Code、Codex、Cursor Agent 之类工具做真实开发，你会越来越意识到一个问题：

能力已经不是第一瓶颈了，流程才是。

这时候 Superpowers 提供的，不是“多一把锤子”，而是“怎么组织整套施工现场”。

2. 想给团队沉淀 AI 开发规范的人

很多团队今天的问题不是没人会用 AI，而是每个人用法都不一样：

• 有人直接让 AI 改生产代码

• 有人先写 spec

• 有人测了

• 有人完全不测

Superpowers 值得看的地方，就是它试图把这些分散习惯，收束成一套可复用流程。

3. 想做 Agent workflow 产品或插件的人

如果你在思考怎么设计自己的 Agent skill system、workflow framework、code review loop，这个仓库是一个很好的参考样本。

因为它不是只讲理念，而是真的把：

• skill 触发机制

• 平台接入

• 规划与执行

• review 关卡

• 分支收尾

这些东西串成了一个整体。

它也有很明确的边界

当然，这个仓库也不是银弹。

我觉得它至少有三条很明确的边界。

1. 它更像方法论框架，不是“装上就无脑变强”

Superpowers 的强项不是给你某个单点能力暴涨，而是给你整套开发流程加纪律。

这意味着它的收益，往往来自：

• 你愿不愿意接受前置设计

• 你愿不愿意让计划更细

• 你愿不愿意真的走测试和 review

如果用户只想“给我立刻写完”，那这套东西反而会显得偏重。

2. 它对宿主能力有依赖

比如：

• 子代理机制是不是可用

• skill discovery 是不是稳定

• 插件市场和命令系统是不是成熟

README 里其实也写得很直白，像 Codex 的某些 subagent skill，就依赖 multi-agent feature。

也就是说，这套方法论再完整，也要看宿主平台的可执行度。

3. 它解决的是流程失控，不直接解决产品判断

流程更好，不代表需求就一定对。

Superpowers 能显著降低“乱写、漏测、跑偏、少 review”这类问题，但它并不能替你做产品判断本身。

所以它最适合的，不是完全替代人的决策，而是把 Agent 从“散兵游勇”训练成“受流程约束的执行者”。

最后

如果你让我用一句话总结 obra/superpowers，我会这么说：

它不是在给 AI 编程代理加超能力，而是在给它加工程纪律。

这可能没有“自动写完整个项目”那么抓眼球，但从长期看，我反而觉得这类仓库更重要。

因为当大家都在拼模型、拼工具数、拼多代理炫技的时候，真正决定 AI 编程能不能走进真实团队的，最后很可能还是这些看起来不够 flashy 的问题：

• 有没有规范的设计前置

• 有没有可执行的计划

• 有没有测试纪律

• 有没有 review 关卡

• 有没有靠谱的收尾流程

而 Superpowers 做的，正是试图把这些东西从“团队文化”变成“Agent 默认行为”。

这就是为什么我觉得，这个仓库非常值得读。

它提供的不是一个新奇技巧，而是一整套关于“怎么让 AI 像工程团队一样工作”的答案。

参考信息

本文主要基于 2026 年 3 月 20 日可公开访问的官方仓库内容整理，重点包括：

• obra/superpowers 仓库 README

• docs/README.codex.md

• .codex/INSTALL.md

• skills/using-superpowers/SKILL.md

• skills/subagent-driven-development/SKILL.md