最近我在研究 OpenAI Plugins 里的一个项目：Superpowers。
它的名字很容易让人误会。
看起来像是又一个给 Coding Agent 加能力的插件：让它更会写代码，更会拆任务，更会调用子代理。
但我读完它的 README、插件清单和一组核心技能文件之后，越来越确定一件事：Superpowers 真正增加的，不是模型的某个知识点，也不是一个新的代码生成器。
它增加的是一套工作纪律。
这套纪律要求 Agent 在写代码之前先理解问题，在执行之前先让人确认，在实现过程中遵循测试，在结束之前拿出证据。它甚至会把“我已经完成了”这句话本身也变成一个需要验证的结论。
我觉得这件事很重要。
因为 AI 编程正在从“帮我写一段代码”，进入“帮我推进一个真实项目”。当 Agent 开始接触真实仓库、真实依赖、真实部署和真实用户时，最危险的问题往往不再是它不会写某个函数，而是它会不会在没有理解目标的情况下，快速写出一大堆看起来合理的东西。
这篇文章不是 Superpowers 的安装教程。
我更想分享我为什么认为它值得研究，以及我从它身上看到的 AI 工作流地图。
先给结论：Superpowers 把 Agent 从“代码生成器”推向“流程执行者”
如果只用一句话解释 Superpowers，我会这样说：
Superpowers 不是一个让 Agent 更快写代码的插件，而是一套让 Agent 更难跳过关键步骤的软件开发方法。
它目前作为 OpenAI Plugins 里的开发者工具插件发布，插件清单中的版本是
5.1.3，作者是 Jesse Vincent，许可证是 MIT。它的能力描述也很直接：规划、TDD、调试、协作和交付工作流。
它的主流程大致是：
- 先通过 brainstorming 把模糊想法变成经过确认的设计。
- 设计通过后，创建隔离的 Git worktree，并确认项目基线正常。
- 把设计拆成足够小的实施计划，每一步都写清文件、代码和验证方式。
- 按任务推进，可以让新的子代理逐个实现，并经过规格审查和代码质量审查。
- 实现过程遵循 RED-GREEN-REFACTOR 的测试驱动开发。
- 遇到异常先做根因调查，不允许直接凭感觉打补丁。
- 结束时重新运行验证，把合并、PR、保留或丢弃分支的选择交还给人。
这不是一个聊天提示词，而是一条有闸门的生产线。
我为什么开始关注 Agent 的工作纪律
我以前使用 AI 编程工具时，最关心的问题通常是：
- 它能不能读懂这个项目？
- 它能不能生成可运行的代码？
- 它能不能少犯一点低级错误？
- 它能不能帮我节省时间？
这些问题当然重要，但它们默认了一个前提：只要 Agent 写出的代码大致正确，事情就会顺利完成。
真实项目不是这样。
很多失败并不是因为某一行代码写错，而是因为一开始就没有把问题定义清楚；不是因为测试不会写，而是因为没有先确定什么行为值得测试；不是因为 Agent 没有能力修复，而是因为它把症状当成了根因；不是因为代码没有运行，而是因为它把一次局部成功误报成了整个任务完成。
人类工程师也会犯这些错误。
但人类团队经过很长时间，已经把很多经验固化成了流程：需求评审、技术方案、分支隔离、测试、代码审查、发布检查和复盘。
Superpowers 做的事情，是尝试把这些工程经验写成 Agent 能读懂、能触发、能执行的
SKILL.md 文件。这也是我觉得它有意思的地方：它不是把 Agent 当成一个只需要更强模型就能解决的问题，而是把 Agent 放进一套组织方法里。
它最重要的设计：技能不是知识卡片，而是行为约束
很多人理解 Skill，可能会把它想成一篇教程：告诉 Agent 某个工具怎么用，某个框架有哪些 API。
Superpowers 里的 Skill 更像一份工作规程。
它不仅告诉 Agent“应该知道什么”，还告诉 Agent“在什么情况下必须停下来、先做什么、完成后如何证明”。
例如 brainstorming 技能的核心不是教 Agent 如何提出点子，而是规定：在开始实现之前，先理解上下文、一次问一个关键问题、提出设计、获得用户批准。
test-driven-development 技能也不只是说“要写测试”。它把过程压缩成一个严格循环：先写一个失败的测试，确认它确实因为功能缺失而失败；再写最小代码让测试通过；最后才重构。
verification-before-completion 则把“完成”从一句自然语言变成一个证据问题：你要声明测试通过，就必须在当前工作中运行测试并看到没有失败；你要声明构建成功，就必须拿到构建命令的退出结果。
这些规则听起来有些严格，但正是这种严格，让它们不再只是建议。
我越来越愿意把 Skill 理解成 Agent 的“组织记忆”。
代码解决的是系统如何运行，Skill 解决的是 Agent 在工作时如何行动。
从一个模糊想法开始，而不是从编辑器开始
Superpowers 的第一道闸门是 brainstorming。
这一步很像我在真实项目里最容易被忽略的需求讨论。
用户说：“帮我加一个功能。”
普通 Agent 可能马上开始搜索文件、创建组件、修改接口。
Superpowers 会先追问：你真正想解决什么问题？现有项目的上下文是什么？有哪些边界？成功标准是什么？有没有替代方案？
它甚至明确要求，在设计被用户批准之前，不要开始实现。
我认为这不是拖慢速度，而是在提前消除返工。
因为很多所谓“开发效率低”，其实不是写代码太慢，而是用很快的速度走错了方向。Agent 如果五分钟内生成了几百行代码，但最后发现目标理解错了，这五分钟并没有创造效率。
真正高效的 Agent，应该知道什么时候先停下来。
这也是我在自己的工作里越来越重视任务文档的原因。任务文档不是管理形式，而是把聊天里的愿望变成可以验收的对象：目标是什么，范围是什么，不能做什么，产物在哪里，怎样算完成。
把设计、计划和实现拆开，Agent 才不会把所有事情混在一起
设计确认之后，Superpowers 还不会立刻让 Agent 自由发挥。
它会进入 writing-plans，把工作拆成很小的任务。每一步都要求写清楚准确的文件路径、需要修改的内容和验证命令，甚至假设执行者是一个没有项目上下文、判断力一般、又不太愿意测试的初级工程师。
这个描述很有意思。
它不是在侮辱工程师，而是在提醒计划作者：如果一个计划只有熟悉项目的人才能执行，它就还不够清楚。
这和我对 AI 协作的理解很接近。
一个好的计划，不应该依赖“Agent 应该能猜到我的意思”。
它应该让任务拥有清晰的边界：
- 这一步只改哪几个文件？
- 这一步不负责什么？
- 先写哪个测试？
- 用什么命令验证？
- 验证失败后，下一步回到哪里？
当这些问题被写出来，Agent 的自由度会下降，但可控性会上升。
我现在更愿意把 Agent 想成一个执行能力很强、但需要上下文和边界的初级工程师。它不应该被要求“自己想清楚一切”，而应该被放进一条能持续反馈、持续校验的工作链。
子代理不是越多越好，而是让每个任务重新获得注意力
Superpowers 还有一个很有代表性的设计：subagent-driven-development。
它会为每个工程任务分派一个新的子代理，让这个子代理实现、测试和自我检查；然后再经过两轮审查：一轮看是否符合计划和规格，另一轮看代码质量。
我不认为这里最重要的是“多 Agent”三个字。
更重要的是，每个任务都重新获得了一个相对干净的上下文和明确的责任边界。
在一个很长的对话里，Agent 很容易被早期错误假设绑架。它可能记得自己刚才写过什么，却忘了最初为什么要做这件事。上下文越长，惯性越强，修正方向反而越难。
新的子代理并不天然更聪明，但它可以带着任务说明、相关文件和验收标准重新开始。再加上规格审查和质量审查，流程就不再完全依赖同一个 Agent 的自我判断。
这有点像软件团队里的分工：实现者负责做，审查者负责问“这是不是我们要的”，另一个审查者负责问“这样做是否足够可靠”。
当然，多代理也会带来上下文准备、调度和复核成本。它并不适合每一个两分钟能完成的小改动。它真正适合的是那些会跨文件、跨模块、需要多轮验证的任务。
TDD 的意义，不只是多写几个测试
Superpowers 对 TDD 的要求非常激进：没有先看到失败测试，就不能写生产代码。
我过去也会写测试，但很多时候测试只是实现完成后的验收附件。代码先写出来，再补几条测试，测试当然容易通过，但这并不能证明测试真的捕获了需求。
Superpowers 把顺序倒过来。
先写一个描述真实行为的测试，让它因为功能还不存在而失败；然后只写足够让这个测试通过的代码；最后再考虑重构和抽象。
这个顺序带来了三个变化。
第一，需求必须先变成可观察的行为。不能只说“增加缓存能力”，而要说“同一个请求在某种条件下应该返回什么”。
第二，Agent 不能一开始就过度设计。因为它要先让一个具体失败变成成功，而不是提前搭建一套可能永远用不到的框架。
第三，测试不再只是代码的附属品，而是实现过程中的方向盘。
对我来说，这和 AI 时代的“最小可用”很接近：先让一个可以验证的小行为成立，再逐步扩展，而不是让 Agent 一次性把想象中的完整系统全部生成出来。
调试时，先查根因，而不是先改最像问题的那一行
Superpowers 的 systematic-debugging 技能把调试分成四个阶段：根因调查、模式分析、提出假设、实施修复和验证。
它还明确写下一条铁律：没有完成根因调查之前，不要提出修复方案。
这条规则很反直觉。
因为很多时候，我们已经看到一行可疑代码，马上改掉它似乎是最快的办法。但如果错误只是表面症状，快速修改通常只会让系统进入下一种更难理解的状态。
对 Agent 来说，这个风险更大。它可以在很短时间里提出十个“看起来合理”的修复，但如果没有先重现问题、读取完整错误、检查最近变更和确认组件边界，这些修复只是猜测。
我很喜欢它把“在压力下也不能跳过根因调查”写进技能的方式。
生产系统出故障时，时间当然重要。但真正省时间的方式通常不是让 Agent 更快地猜，而是让它更快地建立证据。
“完成”必须有证据，这可能是最值得带走的一条规则
AI 工作流里最危险的一句话，可能不是“我不知道”，而是“已经完成了”。
因为 Agent 很容易把以下几件事混在一起：
- 文件已经修改。
- 局部命令没有报错。
- 某个测试通过。
- 整个任务符合需求。
- 线上结果已经可用。
它们完全不是一回事。
Superpowers 的 verification-before-completion 技能要求 Agent 在作出完成声明之前，重新识别这个声明需要什么证据，然后实际运行验证命令，读取完整输出，再决定能不能这样说。
这套思路也适用于我自己的博客、部署和运营工作。
部署钩子返回 200，不等于公开页面已经可访问；Notion 里出现一条记录，不等于网站已经刷新；文章本地写完，也不等于文章适合公开发布。
每一个“完成”，都应该对应一个具体的验收边界。
我觉得这才是证据优先在 AI 时代真正的含义：不是让 Agent 变得不自信，而是让它把自信建立在可复查的结果上。
Superpowers 解决了什么，又没有解决什么
我对 Superpowers 的评价是积极的，但它不是魔法。
它解决的是工作过程中的几个结构性问题：
- 目标还没澄清就开始写代码。
- 复杂任务没有拆成可检查的步骤。
- Agent 在长上下文里不断沿着错误方向前进。
- 测试和实现顺序颠倒，导致测试只是事后装饰。
- 调试靠猜，修复靠惯性。
- 局部成功被夸大成整体完成。
但它没有解决几个更根本的问题：
第一，流程纪律不能替代领域判断。Superpowers 可以要求 Agent 询问目标，却不能替你决定哪个商业问题值得做。
第二，验证命令本身也可能不完整。如果项目没有覆盖关键路径的测试，测试全绿也不能证明产品没有问题。
第三，严格流程会增加时间和上下文成本。对于一行文案、一个只读查询或一个非常局部的配置修正，我不会强行套用完整的软件开发仪式。
第四，子代理并不等于自动拥有可靠的团队。它们仍然需要清晰的输入、可执行的任务和真实的审查标准。
所以我不会把 Superpowers 理解成“以后所有工作都必须按同一套流程执行”。
我更愿意把它理解成一个可靠性工具箱：任务越复杂、代价越高、越需要交付证据，就越值得打开更多闸门。
我会怎样把这套方法放进自己的 AI 工作流
如果让我把 Superpowers 转化成自己的实践地图，我会分成四层。
第一层：先判断这是不是一个值得设计的任务
如果只是查一个文件、改一个明显的拼写错误，我会直接做。
如果涉及新功能、跨文件修改、外部接口、数据迁移、发布或真实用户，我会先回答：目标是什么，边界是什么，成功标准是什么。
第二层：把聊天变成可交付的任务
我会尽量留下一个短任务文档，而不是只依赖聊天上下文。里面至少写清楚目标、范围、预期文件、验收标准和当前阻塞点。
这样下一次继续工作时，Agent 不必重新猜测我们上次到底达成了什么共识。
第三层：让每一个变化都有一个观察点
新功能对应测试，修复对应复现步骤，部署对应公开 URL，内容发布对应页面状态和渲染检查。
如果一个变化没有观察点，我会先问自己：我到底准备怎样知道它真的生效了？
第四层：把完成声明拆成几个更小的结论
我不会只说“做完了”。
我会分别说明：哪些文件发生了变化，哪些测试通过，哪些边界没有验证，哪些外部链路还需要人工确认。
这听起来不像最有魔力的 AI 体验，但它更接近真实工作的可靠性。
我真正想要的，不是一个更会迎合我的 Agent
过去我们使用工具，常常希望工具不要打断我们，最好一句话就把事情完成。
但当工具从“执行命令”变成“推进项目”，完全顺滑也许不是最好的体验。
有时候，我需要它反问我。
有时候，我需要它要求我确认设计。
有时候，我需要它告诉我当前证据不足，不能把局部成功说成完成。
这会让工作多几个停顿，却也让每个重要决定更容易被看见。
我越来越相信，真正成熟的 AI Agent 不应该只是一个永远说“可以”的助手。它应该像一个有工作纪律的合作伙伴：理解目标，提出疑问，按计划推进，遇到问题先找根因，完成之后拿证据说话。
Superpowers 最有价值的地方，也许就在这里。
它没有把人的判断从流程里拿走，反而把人的批准、复核和取舍放到了更清楚的位置。
结尾：AI 编程的下一阶段，是把能力组织起来
我以前以为，AI 编程的竞争主要是模型能力的竞争。
谁的模型更强，谁就能写出更复杂的代码；谁的上下文更长，谁就能处理更大的项目。
现在我的判断正在发生变化。
模型能力当然仍然重要，但当多个模型都已经能够写出可运行的代码之后，真正拉开差距的，可能是它们有没有被放进一套能持续理解、持续验证、持续复盘的系统里。
Superpowers 给我的启发，不是“安装这个插件，你就会拥有超能力”。
它更像是在提醒我：AI 的能力不会自动变成生产力。能力需要被组织，任务需要被拆开，判断需要被确认，结果需要被验证，经验需要被写成下一次可以复用的规则。
未来每个人都可能拥有自己的 Agent 团队。
但真正重要的，不是拥有多少个 Agent，而是你能不能给它们一张清晰的地图，给每一步设置可靠的检查点，并且在关键地方保留自己的判断。
我想要搭建的，也正是这样的个人工作系统。
不是让 AI 替我跳过思考，而是让 AI 帮我把思考、执行、验证和复盘组织成一条可以长期运行的路。
研究资料与源码
Loading...
