大家好，今天我们来看一个很适合拿来讲清楚“Agent 到底该怎么做工程”的项目：Superpowers。
我先把结论放前面。Superpowers 不是那种“给 agent 加几个技巧”的小玩意儿，它更像是一整套coding agent 的开发纪律。就是说，它关心的不是“能不能让模型多会一点”，而是“怎么让模型按工程流程把事情做完”。
这个差别很关键。很多人现在用 Agent，基本就是一通乱喂：给它一个大 prompt，扔一堆工具，再让它自己想办法。短一点的活儿还能凑合，任务一复杂，问题就都出来了：需求没收敛、方案没拆开、代码一把梭、测试没补、最后还不知道哪里坏了。
Superpowers 想解决的，就是这套失控的过程。
它到底在做什么？
好，我们先把这个东西说清楚。
Superpowers 是一个开源的 skills framework，再加上一套围绕 skills 组织起来的开发方法论。它的核心思路很简单：把人类工程师做事的顺序，拆成 agent 能自动触发、自动执行、自动收口的步骤。
所以你会看到它不是先谈“模型多强”，而是先谈流程：
- 先搞清楚你到底要做什么
- 再把设计写清楚
- 再把实现拆成小步
- 再让 agent 分批执行
- 再用测试和 review 收口
这个顺序不是装饰，它就是这套系统的骨架。
如果你把它和一般的 prompt 工程放一起看，差别就很明显了。一般的 prompt 工程，重点在“怎么说”；Superpowers 的重点在“先做什么，后做什么，谁来做，做到什么程度停下来”。
这就是方法论和技巧的区别。技巧是“怎么说得更像样”，方法论是“怎么不把项目做崩”。
这套流程为什么有效？
因为它把 agent 最容易犯错的地方，一个一个卡住了。
第一关：先别写，先想清楚
Superpowers 的 brainstorming 不是让 agent 立刻开写，而是先通过提问把需求掰开。README 里说得很明确：它会先探索上下文、提出不同方案、把设计分成几个小块，再让你确认。
这个地方很像什么呢？很像我们自己做需求评审。你不会一上来就说“我先把代码写了”，你会先问：
- 这个功能到底要解决什么问题？
- 有几种做法？
- 哪个方案最稳？
- 成本和收益怎么权衡？
人类工程师本来就该这么做，只不过很多 agent 直接跳过了这一步。
Superpowers 的第一刀，就是把“先想”变成强制动作。
第二关：把设计写成文档，而不是只存在脑子里
brainstorming 之后，它会把设计落成文档。这个动作很朴素，但很重要。
为什么？因为一旦设计只存在聊天记录里，后面就很容易漂。你和 agent 讨论了半天，三十分钟后它就开始忘细节，开始用它自己的理解补洞。最后你会发现，写出来的东西跟最初那版想法不是一回事。
设计文档的价值，不是“文雅”，而是让约束变成可引用的东西。后面不管是写计划、切任务，还是做 review，都可以回头对照。
第三关：把大任务拆成 2 到 5 分钟的小任务
接下来就是 writing-plans。
这个技能的定位很明确：把已经确认过的设计，拆成一个一个能执行的小任务，而且每个任务都要有明确文件路径、具体改动、验证方式。
这个地方我觉得特别像一个靠谱的 junior 该有的工作方式。你给他一个大目标，他不会跟你说“我懂了，我直接开干”，而是先拆成几步：
- 先改哪个文件
- 先补哪个测试
- 先验证哪条路径
- 哪一步做完就停
这一步的意义不是增加流程，而是降低失控概率。Agent 最大的问题之一，就是它太容易一口气跑远。拆小之后，错误就会更早暴露，回滚成本也更低。
第四关：让 Agent 先分工，再并行
Superpowers 里还有 subagent-driven-development 和 executing-plans 这一层。
这层的思路也很直接：主 Agent 不要什么都自己吞。可以把独立子任务交给新的 subagent 去做，然后再做两轮检查，一轮看是否符合 spec，一轮看代码质量。
就是说，它不是“你写完我信你”，而是“你写完我先看是不是按设计做的，再看代码本身有没有问题”。
这个设计非常实在。因为 Agent 做复杂项目时，最怕的是一个上下文里塞太多东西，最后所有问题都搅在一起。拆成 subagent 后，单个任务上下文更干净，主线更清楚，出错也更好定位。
第五关：测试不是附加项，是收口手段
然后是 test-driven-development。
Superpowers 这里不是把 TDD 当成口号，而是当成流程的一部分：先写会失败的测试，看到它失败，再写最小实现让它过，最后再整理。
这个顺序很重要。因为如果你先把代码堆出来，再补测试，很多时候你测试的其实不是设计，而是给现成代码找理由。反过来，先写测试，就能把“这件事应该怎么工作”先说清楚。
对 agent 来说，这一步尤其关键。模型很会生成代码，但不一定会判断边界。测试可以把边界钉住。
第六关：做完要有退出条件
最后是 requesting-code-review 和 finishing-a-development-branch。
很多人忽略这一段，但这其实是整套方法论里最像工程的部分。因为项目不是写完代码就结束了，真正的结束是：
- review 过了
- 测试过了
- 分支收口了
- worktree 清理了
Superpowers 把这个收尾也纳进流程里，等于告诉你：Agent 不是在“产出代码”，而是在“完成一个可交付的开发循环”。
这就是它比普通 prompt 更像方法论的地方。
它的底层不是魔法，是约束
好，讲到这里，我们再往下一层看。
Superpowers 真正厉害的地方，不是某个技能有多神，而是它把很多约束都做成了默认行为。
1. 技能是可组合的
它不是把所有能力塞进一个巨大的 prompt，而是拆成一个个技能文件。每个技能都有清晰触发条件，到了对应场景才出来。
这样做的好处很明显：上下文不会一上来就膨胀得太厉害，Agent 也更容易知道“现在轮到谁出场”。
2. 触发是自动的
README 里有一句话意思很明确：skills 会自动触发，不需要你手工去记一堆步骤。
这点很重要。因为如果方法论要靠人“记得想起来”，那它大概率落不了地。真正有用的流程，应该是能在合适的时候自己跳出来。
3. 平台接入方式尽量薄
Superpowers 对不同 agent 平台的接入方式也很克制。Codex 这边是通过本地 skills 发现；Claude Code、OpenCode、Cursor、Gemini CLI 都有各自的接入方式。
你可以把它理解成：它不是在造一个新的 IDE，而是在给现有 agent 加一层统一的工作纪律。
这个思路我觉得是对的。因为工程问题本来就不是“再发明一个工具”能解决的，很多时候，真正缺的是执行秩序。
这套方法论适合谁？
我直接说结论。
如果你只是让 agent 改个小文件、补个文案、写一个一次性的脚本，那 Superpowers 可能有点重。它的价值不在“立刻快一点”，而在“复杂任务不容易跑偏”。
它最适合这些场景：
- 需求不清楚，但你又必须先做出设计
- 一个任务要拆成很多步
- 你希望 agent 能和你一起做工程，而不是只会吐代码
- 你在意测试、review、收尾这些硬动作
说白了，Superpowers 解决的不是“能不能让 agent 写代码”，而是“能不能让 agent 像一个有流程意识的开发者一样做事”。
这差别非常大。
总结一下
好，最后我们把这件事收一下。
Superpowers 这套东西，本质上不是一个技能仓库，而是一套给 coding agent 用的工程方法论。它做了几件很明确的事：
- 先通过 brainstorming 把需求问清楚
- 再把设计写成能复核的文档
- 再把实现拆成小任务和子任务
- 再用测试和 review 把结果钉住
- 最后把分支和工作流收干净
所以说，Superpowers 真正卖的不是“更聪明”，而是“更可控”。
这个方向我觉得很有价值。因为未来 agent 真正比拼的，不只是模型本身，而是谁能把模型放进一套靠谱的工程流程里，让它稳定地把事做完。
这就是 Superpowers 的核心。