Superpowers 拓展阅读：6 个能回源码验证的真实场景，它到底怎么增强 Agent

前一篇我已经讲过，obra/superpowers 不是提示词包，而是一套给 AI 编程代理装上的流程系统。

但如果只讲“流程系统”，读起来还是容易抽象。

真正让人信服的，不是它喊了多少口号，而是你能不能在仓库、技能文档和作者 Jesse 的官方博客里，看到一批足够具体、足够可验证的使用场景。

所以这篇我不再泛讲 Superpowers 是什么，而是只挑那些你可以回到源码和官方材料里逐条核验的案例，看看它到底是怎么增强 Agent 的。

我会重点讲 6 个场景：

• 一个简单任务，为什么它也不让 Agent 直接开写

• 为什么它一定要把实现放进 worktree

• 为什么它要把计划拆到 2 到 5 分钟级别

• 为什么它宁可上子代理和双重 review，也不让主代理一把梭

• 为什么它会强行阻止 Agent 用“猜测式修复”去处理故障

• 在 Codex 里，哪些增强是真的，哪些前提你必须打开

如果你最近正好在用 Claude Code、Codex 或 Cursor 做开发，我建议你把这篇当成一份“验证清单”来看。

因为 Superpowers 真正厉害的地方，不是它会帮你写一段多漂亮的代码，而是它在试图把 Agent 从“会写”推进到“会按流程做事”。

如果你想亲手验证，先装起来

先说结论：

• 如果你只是想核对这篇文章写得对不对，其实不用安装，直接看仓库和技能文档就够了

• 如果你想真的复现“它会不会先 brainstorming、会不会建 worktree、会不会派子代理”这些动态场景，那就得先装

对 Codex 来说，官方给的最小安装路径很直接：

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

mkdir -p ~/.agents/skills

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

然后：

1. 重启 Codex

2. 开一个新会话

3. 直接给它一个应该触发 skill 的任务

比如你可以直接丢一句：

Let's make a react todo list.

如果安装和发现机制都正常，Codex 不应该直接开始写代码，而应该先进入 brainstorming。

这里还有一个很重要的前提：

如果你想验证的是 dispatching-parallel-agents、subagent-driven-development 这类真正依赖子代理的增强，还要去改 Codex 的配置文件：

~/.codex/config.toml

把下面这段放进 [features] 里；如果你本来没有 [features] 这一节，就直接整段加上去：

[features]

multi_agent = true

改完之后，最好重启一次 Codex，再开新会话验证。

不打开这个选项，你还是可以验证：

• brainstorming

• writing-plans

• systematic-debugging

• TDD / review 这些流程约束

但你看不到“一个主控调度多个子代理”的那部分效果。

场景一：一句“做个 todo app”，它先不写代码，而是先拉你进 brainstorming

这是 Superpowers 最经典、也最容易验证的场景。

在 Superpowers 5 这篇官方博文里，Jesse 直接给出了自己的默认 smoke test。做法很简单：打开一个 coding agent，然后输入一句：

Let's make a react todo list.

判断 Superpowers 有没有生效，不是看 Agent 有没有马上开始写代码，而是看它会不会先触发 brainstorming。

文章里给出的判断标准也很直接：

如果 Agent 一上来就开始 coding，说明 Superpowers 没有真正接管流程；如果它先进入 brainstorming，才说明这套流程开始正常工作。

下面这张就是第一个例子的实际执行效果。

你可以看到，用户只是丢了一句 Let's make a react todo list.，Agent 并没有立刻开始搭 React 项目，而是先明确声明要启用 using-superpowers、brainstorming，甚至已经预判后面可能要走 test-driven-development。这正是 Superpowers 想强行插入的第一层流程约束。

如果你前面在 Codex 里也跑过类似 smoke test，这张图就很好理解：Superpowers 最先接管的不是“怎么写”，而是“先别急着写”。

Superpowers 第一个例子的执行效果

这件事为什么重要？

因为今天很多 Agent 最大的问题，不是不会写，而是太早开始写。

用户只说了一句“做个功能”，它就默认：

• 需求已经清楚了

• 交互已经定了

• 技术路线已经定了

• 范围已经定了

可真实项目里，恰恰这些前提最容易错。

Superpowers 在这里做的增强，不是让模型更会生成代码，而是让它先踩刹车。

它把“先问清楚再动手”从一种人类工程师的经验，变成 Agent 的默认动作。

这也是为什么我觉得，brainstorming 才是整个仓库的总闸门。

如果这个总闸门没触发，后面那些 plan、worktree、subagent、review，其实都很难真正落地。

场景二：设计一旦通过，Agent 不是直接改当前目录，而是先建 worktree

第二个非常值得注意的场景，是 using-git-worktrees。

在 Jesse 那篇介绍 Superpowers 的官方文章里，他明确写到：

brainstorming 结束后，如果你在一个 git 仓库里，系统会自动创建一个 worktree，然后把工作目录切过去。

这不是一个“顺手加上的 Git 技巧”，而是整套方法论的基础设施。

为什么？

因为一旦你开始让 Agent 长时间干活，它很容易出现三种污染：

• 污染当前分支

• 污染当前工作区

• 污染下一轮任务的上下文

而 using-git-worktrees 这个 skill 的要求非常具体，几乎可以看成一个工程操作 SOP：

1. 先检查项目里有没有 .worktrees/ 或 worktrees/

2. 如果没有，再去看 CLAUDE.md 有没有指定目录

3. 还没有，才问用户

4. 如果用项目内目录，必须先用 git check-ignore 验证这个目录是否被忽略

5. 没忽略，就先修 .gitignore

6. 然后才执行 git worktree add

7. 进到新目录跑项目 setup

8. 最后跑一次 baseline test，确认当前基线是干净的

注意这里最狠的一点：

它不是“建了个 worktree 就算完成”，而是要求先把依赖装好，再把测试基线跑通。

下面这张图对应的是第二个用例的实际执行效果。

重点不在“它会不会切分支”，而在它会不会先检查当前仓库适不适合直接切分支。你可以看到，它先判断当前工作区不干净、本地 main 落后于 origin/main、仓库里也没有现成的 .worktrees/ / worktrees/ 目录，然后才给出“从最新 origin/main 起分支，并优先放进隔离 worktree”的建议。

Superpowers 第二个例子的执行效果

这是非常工程化的增强。

因为很多 Agent 工具只教会模型“怎么改”，却没有教会它“在哪里改、在什么状态下改”。

而 Superpowers 在这一层的目标，是先把施工场地搭好，再让 Agent 动手。

场景三：计划不是写给人看的，而是写给“低上下文执行者”看的

第三个场景，出现在 writing-plans。

这里如果不把顺序讲全，读者很容易断档。Superpowers 在这一段的完整链路其实是：

1. 先在 brainstorming 里把需求和设计聊清楚

2. 把设计写成 spec 文档，并提交到 git

3. 进入 spec review loop，由 spec-document-reviewer 先做一轮内部审查

4. 内部 spec review 通过后，再让用户确认这份 spec

5. 到这一步，设计才算进入 approved design

6. 然后才会进入 writing-plans

所以，spec review 不是写 plan 之后做的，也不是用户先看完才做的，而是发生在 spec 写完之后、用户最终 approve 之前。

README 里把 writing-plans 写成 Activates with approved design；而 brainstorming 的 skill 又把这个 “approved design” 拆得更细：必须先过 spec review loop，再过用户确认。也就是说，真正触发 writing-plans 的不是一句模糊的“去做吧”，而是“spec 已经过审，我也确认了，现在开始写 implementation plan”。

如果你只看 README，会看到一个很醒目的要求：

任务要拆成 2-5 分钟 级别的小任务，而且每个任务必须有：

• 明确的文件路径

• 完整的代码要求

• 验证步骤

这个要求非常重要，因为它直接定义了 Superpowers 对“好计划”的理解。

它不是那种“先写一个大纲，后面边做边补”的计划，而是要把计划写到一种程度：

即使执行者上下文很薄、判断力一般，也不会轻易跑偏。

你可以把它理解成：

Superpowers 不是在教 Agent 写“项目规划”，而是在教 Agent 写“可交付给另一个 Agent 执行的任务单”。

这也是为什么它和一般的“先列一个 todo list”很不一样。

一般的 todo list 更像提醒事项。

而 writing-plans 产出的东西，更像一份可以直接拿去发包的小规格文档。

这背后的增强逻辑其实很清楚：

如果主代理后面要把任务派给子代理，计划就不能再是含糊语言。

它必须足够细，细到下游执行者不需要再猜。

换句话说，writing-plans 并不是为了让文档更漂亮，而是为了给后续的多代理执行打地基。

场景四：真正执行时，不是一位主代理单干，而是“实现 + 两层 review”流水线

如果说前面三步还可以被理解成“比较讲究的单代理流程”，那第四个场景就真正体现出 Superpowers 的代理编排思路了。

这一段的触发条件同样不是模糊的“开始干活”，而是 plan 已经写好。README 里对它的定义就是 Activates with plan。也就是说，链路到这里已经变成：

brainstorming -> spec review -> user approve -> writing-plans -> plan 完成 -> subagent-driven-development

在 subagent-driven-development 的 skill 文档里，官方给了一个非常完整的例子。

这不是抽象说明，而是接近一段真实执行脚本：

• 主控制器先读一次 plan

• 把所有 task 的全文和上下文抽出来

• 建立 todo 列表

• 给某个 implementer 子代理发完整任务文本

• 子代理如果有歧义，会先提问

• 实现完成后，先做 self-review

• 然后进入第一层 reviewer：检查 spec compliance

• 再进入第二层 reviewer：检查 code quality

• 有问题就回退修

• 两层都通过，主控才标记这个 task 完成

文档里举的例子很具体。

比如 Task 1 是做 hook 安装脚本。实现子代理会先确认：

应该安装在 user level 还是 system level？

然后做完后会汇报：

• 功能完成了

• 测试通过了

• self-review 时发现漏了 --force，已经补上

• 已提交

到了 Task 2，spec reviewer 还会直接打回实现，说它少了“每 100 项输出一次进度”，并且多做了一个没被要求的 --json 参数。

也就是说，在这套流程里，子代理不是只要“写完就行”，而是要连续过三道关：

• 自审

• 是否符合规格

• 代码质量是否过线

这才是 Superpowers 真正让我觉得有东西的地方。

它不是在炫耀“多代理”这个词，而是在给多代理加质量门禁。

很多系统一说多代理，重点都在“怎么同时跑更多工人”。

而这里更重要的是：

工人干完之后，谁来拦住偏航。

场景五：Agent 想靠经验猜 bug，它会被 systematic-debugging 拉回来

第五个场景，是我觉得最能体现 Superpowers 价值的一条：systematic-debugging。

很多 AI coding 工具在调 bug 时都有一个共性问题：

它们太容易看到一个报错，就立刻把“最像的修法”扔上去。

看起来反应很快，但本质上是在猜。

而 systematic-debugging 的整套设计，就是用来对抗这个倾向的。

官方 skill 的哲学很明确：

• 先找 root cause，再提 fix

• 先做证据采集，再做解释

• 如果一个假设没证据，就不能算假设成立

• 如果连续几轮修复失败，就该重新怀疑你的模型，而不是继续瞎试

最能说明问题的，不是 README，而是这个 skill 自带的压力测试。

案例 A：线上支付挂了，每分钟损失 1.5 万美元

在 test-pressure-1.md 里，场景被写得非常真实：

• 你是 on-call engineer

• 支付 API 100% 报错

• 每分钟损失 1.5 万美元

• 日志里看到的是超时

• 你想起上周另一个服务也遇到超时，最后加 retry 就修好了

这里诱惑非常大。

因为“加 retry”看起来只要 5 分钟，而按系统化调试流程去做复现、查最近变更、找 working example，可能要 35 分钟以上。

这个测试的目的，不是告诉你永远不要做止血，而是逼 Agent 正视一个现实：

‘看起来像上次的问题’ 不等于 ‘这次真的是同一个问题’。

也就是说，Superpowers 在训练 Agent 抵抗一种特别危险的工程错觉：

我见过类似报错，所以我知道怎么修。

案例 B：你已经花了 4 小时调 test，不想推翻 timeout 补丁

另一个更贴近日常开发的例子，在 test-pressure-2.md。

场景是：

• 你从下午 4 点调到晚上 8 点

• 一个支付测试一直 flaky

• 你已经从 sleep(100) 加到 sleep(5000)

• 看起来差不多能过了

• 你已经很累，还约了晚饭

这个测试真正针对的是 sunk cost。

也就是：

人和 Agent 都很容易因为“已经投入很多”，就不愿意承认方向错了。

这个压力测试真正检查的，不是 Agent 会不会继续堆 timeout，而是它愿不愿意承认前面几个小时走偏了，然后回到 Phase 1 重新找根因。

这类规则在短期里会让 Agent 显得慢。

但从长期工程质量看，它是在抑制一种很常见的退化路径：

先用 timeout 糊过去，后面再说。

很多系统的问题，不是不会修，而是太擅长制造“暂时能跑”的错误稳定态。

场景六：在 Codex 里，真正有用的增强不只是安装成功，而是把前提打开

最后一个场景，专门讲 Codex。

因为很多人第一次看 Superpowers for Codex 的时候，会以为：

我 clone 一下、做个 symlink、重启 Codex，就算装好了。

其实只对了一半。

在 docs/README.codex.md 里，官方写得很清楚：

如果你想用到 dispatching-parallel-agents 和 subagent-driven-development 这类真正增强执行力的技能，你还得打开：

[features]

multi_agent = true

这个细节很重要，因为它决定了你拿到的是哪一层增强。

如果没有 multi_agent = true，你装上的更多是：

• brainstorming

• writing-plans

• debugging discipline

• TDD / review 这些流程约束

但如果你把 multi_agent 打开，Superpowers 才能真正把任务派给多个子代理去跑。

前面第一个用例，其实已经把 Codex 上最容易观察到的 smoke test 展示出来了：一句 todo list 需求，先触发 brainstorming，而不是直接开写。

所以到了 Codex 这一节，真正新增的信息就不是“它会不会先问清楚”，而是：你有没有把 multi_agent 打开。

不开 multi_agent，你验证到的主要还是流程纪律接管成功；打开 multi_agent，你才会真正看到 dispatching-parallel-agents、subagent-driven-development 这类编排能力开始生效。

也就是说，Superpowers 装在 Codex 上时，最值得期待的不是某个单一 skill，而是两层增强一起出现：

• 第一层是流程纪律更严格

• 第二层才是多子代理协作真正跑起来

这 6 个场景串起来，你会发现它真正增强的是三件事

看完这些官方案例之后，我觉得 Superpowers 真正增强 Agent 的，不是某一个局部能力，而是三件更底层的东西。

1. 增强“什么时候不要开始写”

这是 brainstorming、writing-plans、systematic-debugging 共同在做的事。

很多 Agent 今天最缺的不是行动力，而是延迟行动的能力。

而 Superpowers 一直在教它：

• 需求没清楚，不要写

• 计划没拆好，不要写

• 根因没找到，不要修

2. 增强“怎么把复杂任务交给低上下文执行者”

这是 writing-plans、subagent-driven-development、dispatching-parallel-agents 在做的事。

主代理不再试图一口气吃掉整个项目，而是：

• 先拆成小任务

• 再按任务派发

• 再用 reviewer 把关

这是把“AI 编程”从单线程写代码，推进到一种更像工程组织的模式。

3. 增强“如何避免假成功”

这是 TDD、review、systematic debugging、verification 这几类 skill 在做的事。

它们不是让 Agent 更快地说“搞定了”，而是让它更难在没有证据的时候说“搞定了”。

这对真实项目非常关键。

因为 AI Coding 真正的坑，很多时候不是明显失败，而是：

它看起来像成功了。

如果你想自己验证这篇文章，可以先看哪几份材料

如果你想把这篇里讲的场景都自己核一遍，我建议从这几份材料开始：

第一组：总流程

• README.md

• 重点看 The Basic Workflow

第二组：Codex 接入

• docs/README.codex.md

• 重点看安装步骤和 multi_agent = true

第三组：具体 skill

• skills/using-git-worktrees/SKILL.md

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

• skills/systematic-debugging/SKILL.md

第四组：压力测试与官方博客

• 压力测试 1：test-pressure-1.md

• 压力测试 2：test-pressure-2.md

• 这两个文件都在 skills/systematic-debugging/ 目录下

• Jesse 的三篇官方博文：

• Superpowers: How I'm using coding agents in October 2025

• Porting Skills (and Superpowers) to OpenAI Codex

• Superpowers 5

这几份材料加起来，已经足够把上面这 6 个场景逐条核下来。

如果你想快速对照验证，可以直接搜这些关键词

如果你已经把仓库 clone 到本地，下面这几条命令是最快的核验路径：

先看 README 主流程：

rg -n "The Basic Workflow" README.md

rg -n "2-5 minutes each" README.md

rg -n "two-stage review" README.md

rg -n "RED-GREEN-REFACTOR" README.md

再看 Codex 接入：

rg -n "multi_agent = true" docs/README.codex.md

再看 worktree 和执行编排：

rg -n "git check-ignore" skills/using-git-worktrees/SKILL.md

rg -n "git worktree add" skills/using-git-worktrees/SKILL.md

rg -n "Verify Clean Baseline" skills/using-git-worktrees/SKILL.md

rg -n "Task 1: Hook installation script" skills/subagent-driven-development/SKILL.md

rg -n "Missing: Progress reporting" skills/subagent-driven-development/SKILL.md

rg -n "Added --json flag" skills/subagent-driven-development/SKILL.md

最后看两组压力测试：

rg -n "Revenue loss: \\$15,000/minute" skills/systematic-debugging/test-pressure-1.md

rg -n "Add retry logic" skills/systematic-debugging/test-pressure-1.md

rg -n "Choose A, B, or C" skills/systematic-debugging/test-pressure-1.md

rg -n "await sleep\\(5000\\)" skills/systematic-debugging/test-pressure-2.md

rg -n "Sunk Cost" skills/systematic-debugging/test-pressure-2.md

rg -n "Choose A, B, or C" skills/systematic-debugging/test-pressure-2.md

至于文中提到的 Let's make a react todo list. 和 Please make me a react todo list app，它们不是仓库里的 README 文案，而是 Jesse 官方博客里拿来做 smoke test 的提示词，应该去对应博文里核验。

最后

如果只把 Superpowers 看成“又一组给 Agent 用的 skill”，你很容易低估它。

它真正有价值的地方，不是让 Agent 多会一个动作，而是试图把一套原本靠资深工程师经验维持的开发纪律，外接成一层默认流程。

所以我现在会把它理解成：

它不是给 Agent 加外挂，而是在给 Agent 装团队流程。

这也是为什么，越是已经重度使用 AI Coding Agent 的人，越应该认真看它。

因为当模型能力越来越像“够用了”，下一阶段真正拉开差距的，往往不再是“它还能不能写”，而是：

它是不是已经学会什么时候先别乱写。