Superpowers 为什么好用：它不是让 AI 更聪明，而是让 AI 更守规矩

好的 AI workflow，不是让模型更自由，而是让模型在关键节点不能犯低级错误。

上一篇讲到，AI 编程真正拉开差距的，不是工具，而是工作流。

同样使用 Codex、Claude Code、Cursor，有的人能把 AI 变成稳定的交付加速器，有的人只是让 AI 更快地制造不可 review、不可验证、不可维护的代码。

所以很自然会有下一个问题：

一个好的 AI workflow 到底长什么样？

Superpowers 是一个很好的观察样本。

它没有发明什么玄学能力，也不是给模型塞一段万能提示词。它做的事情更朴素，也更工程化：

• 需求不清楚时，不准直接写代码。
• 没有设计确认时，不准进入实现。
• 遇到 bug 时，不准靠猜乱修。
• 没有跑验证时，不准说完成。
• 准备做复杂任务时，不准只靠一句 prompt 开干。

这就是我觉得 Superpowers 好用的地方。

它不是让 AI 更聪明，而是让 AI 更守规矩。

Superpowers 真正厉害的地方，是它知道 AI 最容易在哪些地方偷懒、越界和乱承诺，并且提前把这些地方设成了流程门禁。

Superpowers 好用，不是因为 prompt 更长

很多人以为 Superpowers 是一套高级提示词，但它真正提供的是一套工程纪律。

Prompt 解决的是这一轮对话怎么说得更清楚。

Workflow 解决的是每一类任务都必须经过哪些步骤。

这两者差别很大。

如果你只是在 prompt 里写：

请你认真分析需求，谨慎修改代码，并在完成后验证。

这当然有用，但它本质上还是建议。

模型可能遵守，也可能在任务复杂、上下文变长、用户催促时跳过去。尤其当用户说“直接改吧”“快点修一下”时，AI 很容易顺着用户的短期意图往下走。

Superpowers 的思路不一样。

它不是只告诉 AI 要认真，而是告诉 AI：

• 什么情况下必须先停下来。
• 什么情况下必须问问题。
• 什么情况下必须写计划。
• 什么情况下必须先验证。
• 什么情况下不能宣称完成。

比如 using-superpowers 的价值，不是多写几句“请你使用技能”，而是在执行前先检查有没有适用的 skill。

这一步看起来很小，但它改变了 AI 的默认行为。

普通 AI 的默认行为是：用户给任务，我直接回答。

加入 workflow 后，默认行为变成：用户给任务，我先判断这类任务是否有既定流程。如果有，就必须走流程。

这就是从建议变成规则。

很多 AI 编程里的 bad case，本质都不是模型不会写代码，而是模型太愿意往前冲。

用户说“帮我改这个功能”，AI 直接开干。

用户说“修这个 bug”，AI 没有复现就猜原因。

用户问“做完了吗”，AI 根据自己改了代码就说完成。

这些行为对一次聊天来说很自然，但对工程交付来说很危险。

Superpowers 的防线是：

• 有适用 skill，就必须使用。
• 有 hard gate，就不能跳过。
• 有 checklist，就按步骤推进。
• 有 verification，就必须拿证据说话。

所以它好用的本质不是 prompt 更长，而是把优秀工程师本来就应该有的工作习惯，做成了可执行的流程约束。

Prompt 是建议，workflow 是约束。

Superpowers 好用，是因为它把建议变成了约束。

从 Superpowers 学到的不是工具，而是 skill 设计方法

Superpowers 最值得学的不是某一个 skill，而是它设计 skill 的方式。

如果只把 Superpowers 当成一组现成技能，那它的价值会被低估。

它真正值得学习的是背后的设计方法：

先找到 AI 最容易犯错的地方，再把这些地方做成流程门禁。

这才是我觉得这篇文章最重要的地方。

我们当然可以直接使用 Superpowers 里的 skill。比如遇到需求不清时用 brainstorming，遇到复杂任务时用 writing-plan，遇到 bug 时用 systematic-debugging，准备收尾时用 verification-before-completion。

但如果只停留在“这些 skill 很好用”，就还没有真正抓住重点。

真正值得带走的，不是某一个现成 skill，而是它背后的设计方式。

也就是说，Superpowers 给我们的启发不是：

你应该照着它的 skill 列表全部用一遍。

而是：

你应该学会把自己的工程经验，设计成一套能约束 AI 的 skill。

这件事比安装一个工具更重要。

因为工具会变，模型会变，命令行产品会变，IDE 插件也会变。但只要 AI 仍然参与真实工程交付，需求澄清、任务边界、debug 证据、验证结果、经验沉淀这些问题就不会消失。

所以我们真正要学的是：如何把这些长期有效的工程判断，固化成 AI 每次都必须遵守的工作流程。

不要从能力清单开始，而要从失败模式开始

很多人写 prompt 的方式，是从“我希望 AI 做什么”开始的。

很多人写 prompt 的起点是：

我希望 AI 做什么？

于是 prompt 里会出现很多类似的话：

• 请你认真分析。
• 请你遵守最佳实践。
• 请你保持代码简洁。
• 请你注意异常场景。
• 请你完成后自查。

这些话都没有错。

但它们的问题是太像建议。

建议不能保证行为稳定。尤其是在任务复杂、上下文很长、用户不断追问、模型急着给答案的时候，这些建议很容易被冲掉。

但一个好 skill 的起点应该是：

我最怕 AI 在哪里犯错？

比如：

• 我怕它需求没澄清就开工。
• 我怕它一次改太多文件。
• 我怕它修 bug 靠猜。
• 我怕它为了测试通过改断言。
• 我怕它没验证就说完成。
• 我怕它每次都临场发挥，经验无法复用。

这就是从失败模式开始设计 skill。

优秀工程师的经验，很多时候不是“知道正确答案”，而是见过足够多的错误模式，知道哪些地方一旦放开就会出事。

AI skill 也应该这样设计。

不要先问“我要让 AI 多做什么”，而要先问：

• 哪些错误最常发生？
• 哪些错误一旦发生代价最高？
• 哪些错误 AI 特别容易犯？
• 哪些错误人类 review 时最难发现？
• 哪些错误可以提前通过流程拦住？

当这些问题想清楚后，skill 就不再是一段泛泛的提示词，而是一套针对高频失败模式的防线。

把 bad case 翻译成 hard gate

好 skill 的关键，不是把原则写得更完整，而是把原则翻译成不能跳过的门禁。

比如“要先理解需求”这句话太软。

更硬的写法是：

在没有输出需求理解、影响范围、未决问题之前，不允许进入实现。

“要谨慎 debug”也太软。

更硬的写法是：

在没有复现步骤、失败证据和假设验证之前，不允许修改代码。

“要完成后验证”还是太软。

更硬的写法是：

没有新鲜的验证命令输出和退出码，不允许声明完成。

这就是 hard gate 的价值。

它把“最好这么做”，变成“不到这个条件不能往下走”。

可以把这个转换过程整理成一张表：

我们害怕的 bad case	对应的 hard gate
需求没澄清就开始写代码	没有需求理解、边界和影响范围，不能实现
AI 一次性改太多文件	没有任务拆分和文件清单，不能大范围修改
Debug 靠猜	没有复现、证据和假设验证，不能改代码
为了测试通过改断言	不能在未确认测试语义错误前修改断言
只覆盖 happy path	没有边界和异常路径清单，不能说测试充分
没验证就说完成	没有验证命令输出，不能声明完成
同样的坑反复踩	新 bad case 必须回填到 skill 反模式里

这张表其实就是 skill 设计的核心。

先列出怕什么，再设计门禁拦什么。

如果一个 skill 没有 hard gate，它很容易退化成一份建议清单。AI 看到了，可能会参考，但不一定会遵守。

如果一个 skill 有 hard gate，它就开始像流程，而不是像提示词。

一个好 skill 至少要拆成 6 个组件

当我们从 Superpowers 反推 skill 设计方法时，可以把一个好 skill 拆成 6 个组件。

第一，触发条件。

它回答的是：什么时候必须使用这个 skill？

比如：

• 用户说“修 bug”时，触发 debugging skill。
• 用户说“开始开发”时，触发 dev-code skill。
• 用户准备说“完成”时，触发 verification skill。
• 用户给出 PRD 时，触发 requirement analysis skill。

没有触发条件，skill 就只是一段躺在文件里的文档。

第二，输入上下文。

它回答的是：执行前必须读什么？

修 bug 要读报错、日志、复现步骤、最近变更和失败测试。

做需求要读 PRD、历史设计、领域模型、接口契约和相关代码。

做代码评审要读 diff、设计文档、测试结果和风险点。

如果不规定输入上下文，AI 很容易凭空补全。

第三，执行步骤。

它回答的是：这类任务必须按什么顺序推进？

比如需求分析不能先写代码，debug 不能先改实现，完成前不能先写总结。

步骤不是为了形式感，而是为了防止 AI 在关键节点跳步。

第四，硬门禁。

它回答的是：哪些条件不满足时，必须停下来？

这是 skill 最重要的部分。

因为 AI 很擅长“继续往下走”。用户给一点信息，它就能补全；测试失败，它就能尝试；上下文不清，它也能给答案。

hard gate 的作用，就是让 AI 在本来最容易往前冲的地方停住。

第五，验证方式。

它回答的是：怎么证明这次执行真的有效？

不同 skill 的验证方式不一样：

• 代码实现要有测试、构建或人工验收点。
• bug 修复要验证原始问题消失。
• 需求分析要验证边界、未决问题和验收标准是否清楚。
• 代码评审要验证风险点是否覆盖。
• 提测交付要验证测试范围、结果和回滚方案。

没有验证方式的 skill，很难证明它真的提升了质量。

第六，反模式样本。

它回答的是：哪些行为明确不能做？

比如：

• 不要在没有边界确认时重构公共方法。
• 不要为了通过测试修改断言。
• 不要只覆盖 happy path。
• 不要把 AI 总结当成验收结果。
• 不要把一次性修复扩展成大范围架构调整。

这些反模式不是附属内容，而是 skill 的核心资产。

因为真正可复用的工程经验，往往就藏在这些“不要再这样做”的失败案例里。

skill 也要被测试

很多人写完一个 skill 后，会默认它已经生效。

但这其实很危险。

因为 skill 写在文件里，不等于 AI 执行时真的会改变行为。

一个 skill 是否有用，不能只看它写得多完整，而要看它能不能通过 bad case 验证。

比如你写了一个 debugging skill，就应该拿几个故意设计的场景去测：

• 用户只说“修一下这个 bug”，AI 会不会先追问复现路径？
• 用户贴了一段报错，AI 会不会先读上下文再判断？
• 用户要求“先让测试过”，AI 会不会拒绝直接改断言？
• 测试通过后，AI 会不会验证原始问题？

如果这些场景下 AI 仍然乱修，那这个 skill 就还不够硬。

同样，一个需求分析 skill 也可以这样测：

• 只有一句模糊需求时，AI 会不会直接实现？
• 影响范围不清时，AI 会不会明确列出假设？
• 方案存在多个路径时，AI 会不会给 trade-off？
• 用户没确认设计时，AI 会不会进入编码？

skill 的验证方式，本质上和代码测试很像。

代码测试验证的是：这段代码在指定输入下是否产生预期输出。

skill 测试验证的是：AI 在指定场景下是否触发预期流程，并避免错误行为。

所以 skill 不是写完就结束。

它应该像代码一样，根据真实使用反馈持续迭代。

每当 AI 在某个任务里翻车，就应该问一句：

这个 bad case 能不能补回 skill？

如果能，就把它变成新的触发条件、门禁、检查项或反模式。

这才是 skill 真正变强的方式。

从工具使用者，变成 workflow 设计者

这套方法比“写一个更长的 prompt”更有价值。

因为它改变的是我们和 AI 协作的角色。

只会写 prompt 的人，本质上是在向 AI 提要求。

会设计 skill 的人，是在给 AI 设计工作系统。

前者依赖每一次临场表达，后者沉淀可复用流程。

前者关注“这次怎么让 AI 回答得更好”，后者关注“这类任务以后怎么稳定交付”。

前者更像使用工具，后者更像设计系统。

这也是 Superpowers 最值得学的地方。

它不是告诉我们某一个任务应该怎么提示 AI，而是示范了如何把工程师的经验转成 AI 的运行规则。

到这里再回看 Superpowers，它的价值就更清楚了。

Superpowers 好用，不是因为它知道更多业务细节。

它好用，是因为它把 AI 容易犯错的地方变成流程门禁。

它让 AI 在需求、计划、实现、debug、验证这些关键节点不能轻易跳过。

而我们写自己的 skill，也应该沿着这个思路走：

• 先找高频 bad case。
• 再设计触发条件。
• 再写执行步骤。
• 再加 hard gate。
• 再定义验证方式。
• 最后持续复盘和更新。

到最后，AI 编程拼的不是谁能写出更长的提示词。

拼的是谁能把需求、边界、验证和经验，变成一套稳定运转的工程流程。

一个好 skill 的起点，不是“我希望 AI 做什么”，而是“我最怕 AI 在哪里犯错”。

常见工作流坑：第一个坑：需求没想清楚，AI 已经开始写代码

AI 最常见的问题不是不会实现，而是在问题还没定义清楚时就急着实现。

真实开发里，很多需求一开始都不是清楚的。

用户说“这里加一个状态”“帮我支持一下这个场景”“这个逻辑优化一下”，背后可能牵涉数据库字段、接口契约、状态流转、权限控制、历史数据、测试用例和兼容逻辑。

如果开发者自己写代码，他通常会先停下来想一想：

• 这个需求到底解决什么问题？
• 哪些模块会被影响？
• 哪些已有行为不能被破坏？
• 有没有不同实现方案？
• 做到什么程度才算完成？

但 AI 很容易跳过这一步。

它看到一句需求，就会尝试补全上下文，然后开始修改代码。它会很快给出一个“看起来合理”的实现，但这个实现未必是用户真正想要的。

典型 bad case 是这样的：

需求只有一句话，AI 就开始改代码。

业务边界不清，AI 自己补假设。

用户还没有确认方案，AI 已经完成了一个版本。

最后功能确实能跑，但方向错了，范围大了，或者把本来不该动的链路也动了。

Superpowers 里的 brainstorming 正是为了解决这个问题。

它要求先探索上下文，再问澄清问题，再提出 2 到 3 个方案和 trade-off，然后展示设计并获得确认。

更重要的是，它有一个 hard gate：

没有设计确认，不能进入实现。

这句话看起来有点硬，但它正好拦住了 AI 编程里最常见的低级错误：需求没澄清就开始写代码。

很多人担心这样会慢。

但在真实工程里，需求理解错导致的返工，比多问几个问题贵得多。

尤其是 AI 写代码很快时，方向错的成本反而会被放大。因为它可以在几分钟内改很多文件，制造出一个巨大但方向不对的 diff。

这也是我们写自己 skill 时最值得吸收的能力。

在需求分析类任务里，可以明确加入这些门禁：

• 需求不清不能写代码。
• 必须先输出问题理解、边界和影响范围。
• 必须区分已知事实和模型推测。
• 需求复杂时，必须先给方案对比，而不是直接给实现。

对 AI 来说，最危险的不是不会做，而是在不该做的时候看起来做得很快。

第二个坑：任务没有拆开，AI 一次改太多

AI 一次改得越多，看起来越强，实际上越难 review、越难验证、越难回滚。

很多人第一次被 AI 编程震到，是因为它能一次性改很多文件。

你给它一个需求，它读完代码后，改接口、改服务、改 DTO、改测试、改配置，最后给你一个完整实现。

这很爽。

但这也是风险最大的地方。

因为一个大 diff 里，可能同时混着几类东西：

• 必须改的业务逻辑。
• 顺手补的字段或转换。
• 为了通过测试临时调整的断言。
• 模型认为更优雅的重构。
• 和当前需求关系不大的格式化或重排。

每个单独看都“有点道理”，但合在一起就很难 review。

一旦后续测试失败，也很难判断问题来自哪一步。

这类问题的本质，是任务没有被拆开。

Superpowers 里的 writing-plans 解决的是这个问题。

它不是为了写一份漂亮计划，而是为了把 AI 的行动拆成可理解、可验证的小步骤。

一个好的 plan 至少要说明：

• 哪些文件会被修改。
• 每一步要解决什么问题。
• 每一步的边界在哪里。
• 每一步完成后怎么验证。
• 哪些事情不属于当前步骤。

这样做以后，AI 不再是“一口气把需求做完”，而是按照一组 bite-sized steps 逐步推进。

这对工程交付很重要。

因为小步骤意味着小 diff，小 diff 意味着更容易 review，更容易定位问题，也更容易回滚。

可以把两种用法对比一下：

坏用法	更好的 workflow
直接让 AI 做完整需求	先拆任务，再逐步实现
一次性改全链路	每步只改一个职责边界
只看最终结果	每个任务后都验证
review 一个巨大 diff	review 一组可解释的小 diff

如果要把这个能力沉淀到自己的 skill 里，可以这样设计：

• 研发任务开始前，先让 AI 输出影响文件清单。
• 每个任务限制在一个明确职责范围内。
• 大任务必须拆成可独立验证的小任务。
• 每个小任务都要有验证命令或人工验收点。
• 如果某一步需要改公共方法、基础模型或核心流程，必须单独标记风险。

好的 plan 不是为了形式感，而是为了让 AI 的每一步都能被理解、验证和回滚。

第三个坑：遇到 bug 就开始猜

Debug 最怕的不是慢，而是没有证据就开始修。

AI 修 bug 很快。

你把报错贴给它，它能马上给出原因分析；你把失败测试丢给它，它能马上改代码；你让它“修到通过”，它会不断尝试。

但这里面有一个很大的风险：

AI 很容易把“让错误消失”误认为“把问题修好”。

测试失败后，它可能直接改实现。

日志没看，复现路径没确认，它可能先猜一个原因。

如果测试断言不符合它当前理解，它甚至可能为了让测试变绿去改断言。

这在 AI 编程里非常危险。

因为很多测试失败，本来就是在暴露真实问题。AI 如果为了通过测试而绕过问题，反而会把风险藏起来。

Superpowers 里的 systematic-debugging，核心就是阻止这种行为。

它要求先复现问题，再收集证据，再定位最小失败点，再提出假设，用验证结果确认假设，最后才做最小修复。

这套流程的价值，不是让 AI 慢下来，而是让 AI 不要在没有证据时乱动。

一个好的 debug workflow，至少要逼 AI 回答清楚几件事：

• 现象是什么？
• 能不能稳定复现？
• 已经看过哪些日志、报错、测试输出或最近变更？
• 当前假设是什么？
• 哪个证据支持这个假设？
• 修复后如何证明原始问题消失？

如果这些问题没有答案，直接改代码就是在赌。

把这个思路沉淀成自己的 bug 修复 skill，可以加几条硬门禁：

• 没有复现步骤，不能开始修复。
• 没有读取报错、日志、失败测试和最近变更，不能下结论。
• 必须区分“现象”“假设”“证据”“修复”。
• 没有验证假设，不能改代码。
• 修复完成后，必须验证原始问题消失，而不只是新测试通过。

一个好的 debug skill，核心不是让 AI 快点修，而是阻止 AI 在没有证据时修。

第四个坑：没验证就说完成

AI 最容易让人误判的地方，是它很擅长用确定的语气描述未验证的结果。

“已完成。”

“问题已修复。”

“现在应该可以正常工作。”

这些话看起来很可靠，但如果后面没有验证命令、测试输出和退出码，它们就只是模型的自我描述。

真实工程里，完成不是一句总结，而是一组证据。

至少要回答：

• 相关测试有没有跑？
• 构建有没有通过？
• 原始问题有没有复现并验证修复？
• 边界条件有没有覆盖？
• 已有行为有没有被破坏？
• 如果验证失败，失败原因是什么？

很多 AI 编程事故，都是从“看起来完成了”开始的。

AI 修改了代码，但没有重新跑相关用例。

AI 根据静态阅读判断 bug 修好了，但没有验证原始场景。

AI 说“应该可以”，但没有任何命令输出。

这就是 verification-before-completion 的价值。

它把“完成”从主观判断，变成必须经过验证的状态。

完成前必须识别验证命令。

必须运行验证。

必须读取输出和退出码。

只有验证通过，才能声明完成。

如果验证失败，就必须说真实状态，而不是包装成成功。

这个思路非常值得沉淀到自己的研发流程里。

每个阶段都应该有 completion gate：

• 需求分析完成，要有明确边界和未决问题。
• 技术设计完成，要有影响范围和风险点。
• 编码完成，要有测试或人工验证证据。
• 代码评审完成，要有 diff 风险检查。
• 提测完成，要有测试范围、验证结果和回滚点。

没有证据的“完成”，在 AI 编程里不是效率，而是风险。

第五个坑：skill 自己也没有被验证

很多人会写 prompt，但很少有人验证自己的 prompt 或 skill 是否真的改变了行为。

这是一个容易被忽略的问题。

当我们开始写自己的 skill 时，很容易写成一份很长的原则清单：

• 要认真分析需求。
• 要保持代码质量。
• 要关注异常场景。
• 要补充测试。
• 要遵守项目规范。

这些话都对，但它们未必能改变 AI 的行为。

一个 skill 真正有用，不是因为它写得长，而是因为它能在关键时刻触发正确流程，并阻止错误行为。

典型 bad case 是：

写了一个很长的 skill，但 AI 实际执行时还是跳步骤。

skill 写了很多原则，但没有触发条件。

skill 说要验证，但没有规定验证方式。

skill 用了一段时间后没有复盘，也没有吸收新的失败案例。

Superpowers 给我的启发是，skill 本身也需要测试。

我们不能只问：

这个 skill 写得完不完整？

更应该问：

这个 skill 能不能稳定拦住我最担心的 bad case？

比如你写了一个 bug 修复 skill，就应该拿几个坏场景去测它：

• 用户只说“修一下这个 bug”，没有复现步骤，AI 会不会先追问？
• 用户贴了一个测试失败，AI 会不会直接改断言？
• 用户要求“先让测试过”，AI 会不会绕过业务校验？

如果 skill 在这些场景下仍然让 AI 乱修，那它就没有真正生效。

一个可验证的 skill，至少要有几类内容：

• 明确触发条件：什么时候必须使用它。
• 输入上下文要求：执行前必须读什么。
• checklist：必须按哪些步骤推进。
• hard gate：哪些事情不能跳过。
• verification：最后怎么证明结果有效。
• bad case：哪些反模式必须避免。

这也是为什么我越来越觉得，skill 不是提示词资产，而是工程经验的测试化表达。

Skill 不是写完就有用。

只有能稳定改变 AI 行为的 skill，才是真正有用的 skill。

我们可以在哪些研发环节加入自己的 skill

自定义 skill 不应该只写给“编码”阶段，而应该覆盖那些最容易依赖经验、最容易出错的研发节点。

很多人一提到 AI skill，就想到“让 AI 更会写代码”。

但真实研发里，出问题最多的地方，往往不只是编码。

需求理解会出问题。

技术设计会出问题。

任务拆分会出问题。

Debug 会出问题。

测试设计会出问题。

提测交付会出问题。

知识沉淀也会出问题。

这些地方都适合沉淀成 skill。

研发环节	适合沉淀的 skill	主要防什么坑
需求理解	PRD 分析 skill	需求没澄清就开发
技术设计	design review skill	方案边界不清、影响范围遗漏
任务拆分	task split skill	大任务一次性改太多
编码实现	coding skill	偏离现有模式、过度重构
Bug 修复	debugging skill	没复现就猜、乱修
单测补充	test design skill	只覆盖 happy path
代码评审	code review skill	只看语法，不看业务语义
提测交付	submit skill	没有验证证据、测试范围不清
知识沉淀	learn skill	同样的坑反复踩

如果放到后端业务开发里，需求理解 skill 可以要求 AI 先读 PRD、领域模型、接口、状态机和历史文档。

如果放到金融系统开发里，coding skill 可以强制检查状态、资金、账务、幂等、对账和异常补偿。

如果放到 AI 编程协作里，code review skill 可以要求检查 diff 是否服务当前需求、是否过度修改、是否漏测、是否有未验证假设。

如果放到团队研发流程里，提测、发布、复盘、知识沉淀都可以变成 skill。

越是依赖经验判断的环节，越值得沉淀成 skill。

因为这些地方，正是 AI 最容易“看起来懂了”的地方。