AI 写功能总返工？31.5 万 Star 的 Superpowers 先把顺序排好了

让 Coding Agent 写一个新功能，最让人心累的往往不是它写不出来。

而是它写得很快，你也点头点得很快，等跑到第二轮，才发现两边默认的「成功」根本不是一件事。于是补需求、改接口、加分支、删测试，再把那段越来越像遗迹的提示词续上。

GitHub 上有个叫 Superpowers 的 Skill 集合，2026 年 11 月 10 日查看时已经有 315,345 Star。它干的不是给 Agent 再塞一套「更聪明的提示词」，而是给写功能这件事规定一个顺序：先把要做什么讲明白，确认设计，再拆成能验证的任务，最后才写代码、跑测试和做复核。

它看起来有点像把一个靠谱工程师的工作习惯写成了触发器。

这篇不替它背书成万能流程，也不假装已经替你实测过。我们只把它最值得借的那条顺序翻成能立刻拿走的版本：什么时候该让 Agent 停下来想，什么时候才该让它动手。

图：依据 Superpowers 官方 README 整理的工作顺序，不是独立实测结果。

它先拦住的，是「一句需求就开干」

Superpowers 的第一段叫 brainstorming。名字听着像开会，实际很务实：面对一个非小改动，先弄清用户要什么、为什么现在要做、怎样算成功，以及哪些答案会改变实现路线。

它有个特别值得抄的判断：如果需求已经非常明确，像「把图标换成矢车菊蓝」，就直接做；如果还有会影响结果的空白，就不要让 Agent 靠概率补完。先提出几种可行方案，写一页短设计，确认之后再进入计划。

这一步的价值，不在于把对话拉长，而在于把返工最贵的判断提前。一个 Agent 能在五分钟里搭出页面，也能在五分钟里把错误的页面搭得像模像样。后者更难处理，因为它会诱惑你继续往上补。

你不需要完整照搬它的问答流程。给 Agent 一个新功能时，先补齐下面这段就已经很有用：

我要新增：[功能一句话]

给谁用：[具体用户]
成功时，用户能完成：[可观察动作]
这次不做：[明确非目标]
现有约束：[技术栈、已有接口、时间或兼容性]

请先给 2—3 个实现方向，说明取舍并推荐一个。
在我确认设计前，不要开始改代码。

这不是官方原文，是把它的思路压成了一段适合日常使用的提示。最关键的一行其实是「这次不做什么」。很多功能不是死在没想清楚，而是死在 Agent 很勤快地把你没要的东西也顺手做了。

设计确认之后，计划要具体到文件和验证

第二段 writing-plans 很适合解决另一个常见场面：你说「做吧」，Agent 给出一串看起来没毛病的步骤，真正执行时才发现文件、接口、测试都得自己猜。

它要求计划里明确写出会创建或修改哪些文件、每个任务产生什么接口、测试叫什么、验证命令是什么。重点不在文档排得多工整，而是让后面接手的人——包括下一轮上下文里的 Agent——不用重新猜一次关键决定。

把它缩成小团队能用的版本，一项计划至少回答四件事：

• 改哪里：文件或模块的准确位置。
• 改什么：接口、数据结构或用户行为会怎样变。
• 怎么证明：先写哪个失败用例，成功后跑什么命令。
• 什么不碰：这次不顺手重构、不扩展哪些边界。

这四项写不出来，通常不是 Agent 不够强，而是设计还没落到能开工的粒度。此时继续要代码，只会把不确定性搬进 diff 里。

图：计划的价值是把决定和验证连起来，而不是生成更长的待办清单。

真正硬的一条：先看测试失败，再让代码通过

Superpowers 的 TDD Skill 写得很直接：新功能、修 Bug、重构和行为变更，先写一个会失败的测试；确认它是因为功能还不存在而失败；再写刚好够通过的代码；最后跑完整项目测试。

这和「让 Agent 先写一版，再让它补测试」的差别很大。

后者里的测试，很容易变成替现有实现盖章。前者先把预期写出来，代码才有一个不能轻易滑过去的边界。尤其是改 API、重试逻辑、权限判断这类事，先看红灯比事后看一大坨绿色代码更省心。

不过，别把 TDD 变成新的表演。官方规则也把一次性原型、生成代码和配置文件列为需要另行判断的例外。一个用于验证想法的 throwaway demo，重点是快点知道方向对不对；此时拿完整生产流程去套，成本可能比 demo 本身还高。

我的判断是：当改动会留下来、会被别人依赖、或者一旦错了会影响真实用户，就让 Agent 走一次「失败测试 → 最小实现 → 全量验证」；其余时候，先把探索和交付分开。

它不是一个「装上就放心」按钮

这类 Skill 最容易被误用成管理学皮肤：每个小改动都先写设计文档，每个任务都拆成十个子任务，每一轮都启动一群 Agent，最后代码不多，流程已经很壮观了。

Superpowers 自己其实留了出口。它在需求明确且改动很小的场景下允许直接做；在需要试水时，也允许先做一个不追求完备的 spike。值得借的是它的分流，不是仪式感。

还有一点得说清：它的 README 展示的是方法和约束，不是「装了以后所有 Agent 都会自动变可靠」的证据。模型会不会遵守、你的仓库有没有可运行的测试、需求负责人能不能及时确认设计，仍然决定了最后效果。

所以更合适的用法不是一次性把整套流程压给所有任务，而是按风险拿其中一段：

你正在做的事	借哪一段就够了
一个模糊的新功能	先用需求澄清和短设计
跨多个文件的改动	再加精确的实施计划
容易回归的逻辑	把失败测试和全量验证加上
准备合并的重要改动	加一次独立代码复核
一次性探索或 demo	只做目标和时间边界，不强上全流程

怎么装，怎么从最小一段开始

Superpowers 的官方 README 提供了多个 Agent 环境的入口。若你在 Codex App 里使用，到插件页搜索 Superpowers 即可；在 Codex CLI 中输入：

/plugins

然后搜索 superpowers，按插件市场的提示安装。它的工作方式是让不同 Skill 在相应阶段触发，而不是每次都要求你手动记一长串命令。

第一次别急着把它当接管整个仓库的总指挥。挑一个下周一定会做、但还没有被写成十行需求的功能，先只借两步：让 Agent 给出方案和短设计；确认后，再让它把文件、测试和验证命令写成计划。

如果这两步能让你少开一次「等等，这不是我要的」的返工会，它就已经值回安装时间了。

至于后面的 TDD、子任务执行和评审，等你确认团队真的需要，再一段段接上。流程这东西和依赖一样，能少装就少装，但该装的那一层，最好别等线上出事才想起来。

你现在让 Coding Agent 开工前，最常漏掉的是需求、设计、计划、测试，还是最后那一次复核？

—— 小岛AI

官方资料：Superpowers GitHub 仓库、brainstorming Skill、TDD Skill。