Superpowers 的真正作用：让 AI 编程慢在正确的地方

AI 编程最危险的时刻，往往不是模型写不出代码，而是它在错误方向上写得太快。

需求里一句含糊的“支持批量处理”，可以被实现成三个不同产品；没有先确认边界，Agent 可能在十分钟内改完数据库、接口和页面，然后用一组自洽的测试证明自己做对了。产出速度越快，错误决定扩散得越快。

obra/superpowers 试图解决的就是这个问题。它不是一个让模型获得新 API 的工具包，而是一套由可组合 skills 约束的软件开发方法：在动手之前形成设计，在执行之前写出可检查的计划，在完成之前拿出新鲜证据。

它优化的不是代码生成，而是决策顺序

根据项目当前公开工作流，一项完整任务大致会经过：

单看每一步都不新鲜。它真正激进的地方是把这些步骤写成 Agent 必须遵循的运行规则，而不是 README 里“建议最好这样做”的团队愿景。

人类工程师面对模糊需求时会追问：谁使用、失败时怎样、现有行为能否复用、什么不在范围内。语言模型则天然倾向于补全空白。补全在写文案时很高效，在修改生产系统时可能制造隐含需求。

Brainstorming skill 把澄清和方案比较放在写代码之前，并要求形成可审阅的设计。它增加了前置对话，却降低了后面大范围返工的概率。

这类“慢”不是流程损耗，而是把成本放在修改最便宜的阶段。设计文档里的错误改一段文字即可，迁移脚本执行后的错误可能要恢复数据。

“实现登录功能”不是计划。“修改哪个文件、先写哪条失败测试、预期看到什么错误、实现后跑什么命令”才是可执行计划。

Superpowers 强调小颗粒任务、明确路径和验证步骤。好处不是让 Agent 机械服从清单，而是迫使设计提前回答接口、边界和完成标准。一个步骤如果无法写清楚，通常说明任务仍然没有想清楚。

计划也让评审有参照物。Reviewer 不只看代码是否漂亮，还能比较实现有没有偏离已经确认的行为。

模型很擅长生成看起来合理的实现，也很擅长在实现之后写出“刚好证明它正确”的测试。先看见失败测试，可以确认测试确实覆盖了尚未存在的行为。

RED-GREEN-REFACTOR 为每次改动建立一个小闭环：

text
写失败测试 -> 确认失败原因 -> 最小实现 -> 确认通过 -> 整理代码

它不能保证需求本身正确，也不能替代集成和视觉测试，但能显著减少“实现和测试一起自我欺骗”的空间。

Agent 常用“应该可以”“看起来没问题”作为完成信号。Superpowers 把 verification-before-completion 单独定义为技能，要求完成声明基于刚运行的测试、构建或检查，而不是基于代码阅读和记忆。

这条规则简单，却直指 Agent 协作的信任问题：结论必须附带可复现证据。它把“我做完了”改成“这是刚才运行的结果，所以我判断做完了”。

Superpowers 不是所有任务的默认最优解。

一次性数据脚本、探索性原型或两行配置修改，若完整走设计、worktree、TDD 和多轮评审，流程成本可能高于实现风险。视觉探索也不适合把所有价值都压缩成先写单元测试。

更深的风险是仪式化：Agent 可以生成一份看似详细的计划、写很多低价值测试，再逐项打勾。如果团队只检查“有没有走流程”，不检查设计判断和测试质量，约束会变成新的表演。

因此，流程强度应该跟风险变化，而不是跟任务名称变化。

不必一次引入完整方法。先保留最能改变结果的三条：

然后按风险增加 worktree、独立评审、子 Agent 和更细计划。这样团队获得的是工程纪律，而不是对某套 skill 名称的依赖。

Superpowers 没有让模型更聪明。它做的是把资深工程师习惯中的隐性停顿显式化：什么时候先别写，什么时候需要证据，什么时候应该让另一个视角来审查。

AI 编程的竞争正在从“谁第一轮生成更多代码”转向“谁能以更少返工交付正确改动”。在这个问题上，速度不是越快越好；关键是让系统快在执行，慢在不可逆的决定。