Superpowers：把 AI 编程从提示词技巧升级成工程流程

先说结论

Superpowers 火起来，表面原因是数字好看：截至 2026-06-28 核对，GitHub API 显示 obra/superpowers 约 24 万 stars、2.1 万 forks；Claude 官方插件市场也把它作为 Claude Code 插件展示，安装量已经达到很高量级。

但它真正值得技术团队关注的地方，不是“又多了一个 AI 插件”，而是它把 AI 编程里最容易失控的部分变成了流程：先澄清需求，再写计划，再做验证，遇到问题再系统调试。也就是说，它不是让 AI 获得某个神秘能力，而是给 AI 套上一组工作规范。

如果你是新手，不需要一开始就把十几个 skill 全部研究透。更实际的路径是先掌握 4 个核心工作流：

• brainstorming：写代码前先澄清目标、约束和验收标准。
• writing-plans：把需求拆成小任务，明确改哪些文件、怎么验证。
• test-driven-development：先写验证，再写实现，让每一步都有反馈。
• systematic-debugging：遇到 bug 先复现、取证、假设、验证，而不是凭感觉改。

这 4 个 skill 覆盖了 AI 编程最核心的闭环：需求、计划、验证、修复。

为什么 AI 编程需要“工作规范”

很多人第一次用代码 Agent，会经历一个典型阶段：你给它一个需求，它很快开始改文件、写代码、跑命令，看起来效率很高。但问题也在这里，AI 的执行速度越快，方向错的时候损失越大。

常见翻车点有四类：

1. 需求还没讲清楚，AI 已经开始动手。
2. 任务拆得太大，中途改了很多文件，但没有阶段性检查。
3. 没有先定义验证方式，最后只能靠肉眼看代码“像不像对”。
4. 出 bug 后凭猜测修改，改一处又引出另一处。

Superpowers 解决的不是“模型智商不够”的问题，而是“工程过程缺少约束”的问题。它的思路很像把资深工程师的工作习惯写成 AI 可执行的规则：什么时候该问问题，什么时候该写计划，什么时候必须先造失败测试，什么时候必须停下来收集证据。

这就是它和普通提示词模板最大的区别。提示词模板通常只影响某一次回答；skill 则更像一段可复用的工作协议，会改变 AI 完成任务的顺序和检查点。

Superpowers 本质上是什么

准确地说，Superpowers 不是单个 skill，而是一组面向 AI coding agent 的 skills。它覆盖的不是某一种语言或框架，而是软件开发过程里的通用动作：头脑风暴、计划、测试驱动开发、系统性调试、代码审查、并行代理、工作树隔离、分支收尾等。

所以它适合的场景不是“帮我写一个函数”这种一次性小活，而是这些更容易出错的工作：

• 新功能从模糊想法进入实现。
• 老项目里要改一段有上下游影响的逻辑。
• Bug 现象复杂，不能靠直觉猜原因。
• 团队希望 AI 产出的代码有验证证据。
• 多个 Agent 或多轮会话需要保持一致的工程习惯。

视频里把它类比成“严格监工”是有道理的。更工程化的说法是：它把 AI 的自由发挥压进一个可检查的流水线里。

新手为什么先抓这 4 个

1. Brainstorming：防止 AI 过早动手

brainstorming 的核心价值是把“需求不清”这个风险提前暴露出来。很多 AI 代码问题不是写法问题，而是目标理解错了：用户想要的是修一个边界条件，AI 却顺手重构了模块；用户只想改一个页面，AI 却引入了新状态管理。

一个好的 brainstorming 过程至少要问清楚三件事：

• 目标：这次到底要解决什么问题？
• 边界：哪些东西不能动，哪些兼容性必须保留？
• 验收：怎样证明任务完成了？

它不是为了让 AI 无休止提问，而是让 AI 在动手前知道“什么叫做做对”。

2. Writing Plans：把大需求切成可检查的小步骤

writing-plans 的价值是降低任务跨度。AI 最容易失控的任务，往往是“帮我把这个功能做完”这种大块需求。看起来一句话很简单，实际可能涉及接口、状态、页面、权限、测试、构建和文档。

计划 skill 会把任务拆成小步骤，并写清楚：

• 每一步要改哪些文件。
• 为什么按这个顺序改。
• 每一步完成后如何验证。
• 哪些地方需要人工确认。

视频里提到“每个任务 2 到 5 分钟”，可以理解成一种理想粒度：任务越小，越容易检查；检查越频繁，越不容易在最后才发现方向错了。

3. Test Driven Development：先定义证据，再写代码

test-driven-development 听起来很技术，但对 AI 编程尤其实用。原因很简单：AI 很擅长写“看起来合理”的代码，却不一定知道这段代码有没有真的覆盖目标行为。

TDD 的顺序是：

1. 先写一个会失败的验证。
2. 再写最小实现让验证通过。
3. 最后在验证保护下整理代码。

这里的“测试”不一定永远是单元测试。对不同项目来说，它可以是接口用例、类型检查、脚本断言、端到端流程、甚至是一个能稳定复现问题的最小命令。关键不是测试形式，而是先有可重复的证据。

4. Systematic Debugging：不要猜，先取证

AI 修 bug 最大的问题是“行动太快”。它经常看到一个报错，就立刻改最像问题的地方。但复杂 bug 往往不是第一个报错点导致的。

systematic-debugging 会强迫流程慢下来：

• 先复现问题。
• 再收集日志、输入、输出和环境信息。
• 提出多个可能原因。
• 一次只验证一个假设。
• 找到根因后再改代码。

这套流程看似慢，但比连续猜错三次更快。尤其在老项目、生产事故、依赖版本问题、权限问题和并发问题上，它能显著减少“越修越乱”。

它对团队的真正价值

如果只把 Superpowers 当作个人效率工具，你会觉得它只是让 AI 多问几句、多写几段计划。但对团队来说，它更重要的价值是形成统一的 AI 协作标准。

团队可以把它落成三条简单规则：

1. 新功能必须先经过 brainstorming 和 writing-plans。
2. 行为变更必须给出验证方式，能 TDD 就优先 TDD。
3. Bug 修复必须先复现和定位根因，再提交补丁。

这三条规则能解决一个现实问题：不同成员使用 AI 的习惯差异很大。有的人让 AI 一次改十几个文件，有的人让 AI 不跑测试直接总结完成，有的人遇到 bug 让 AI 连续猜。Superpowers 的作用，就是把这些差异压缩到同一条工程流水线里。

常见误区

误区一：装了 Superpowers，AI 就会自动变强。
不会。它增强的是流程，不是模型能力。模型如果不了解你的代码库，仍然需要读代码、跑测试、看日志。

误区二：新手只需要“安装 4 个”。
更准确的说法是：新手先练熟这 4 个核心流程。实际安装方式会随不同 Agent 和插件市场变化，有的平台是安装整套插件，再在使用时触发对应 skill。

误区三：Brainstorming 就是一直问问题。
不是。好的需求澄清要服务于实现，问到目标、边界和验收足够清楚就应该停下。

误区四：TDD 只适合大团队。
恰好相反，个人使用 AI 时更需要 TDD，因为你没有同事帮你随时审查 AI 生成的代码。最小验证就是你的第二双眼睛。

推荐落地路径

个人用户可以按这个顺序练：

1. 先在新功能里使用 brainstorming，训练 AI 不要立刻写代码。
2. 再使用 writing-plans，让 AI 把任务拆到你能逐步检查的粒度。
3. 对核心逻辑启用 test-driven-development，把验收标准变成自动验证。
4. 遇到 bug 时固定使用 systematic-debugging，禁止 AI 凭第一感觉改代码。

团队用户可以再往前走一步：把这套流程写进项目的 AI 协作规范里，比如 AGENTS.md、CLAUDE.md 或仓库文档。这样每个人调用 AI 时，都不是从零开始解释团队习惯，而是复用同一套工程规则。

最后

Superpowers 的爆火说明了一件事：AI 编程的竞争已经不只是“谁的模型更强”，也包括“谁能把模型放进更可靠的工程流程”。

对新手来说，先不要纠结十几个 skill 要不要全部掌握。真正应该先养成的是四个习惯：写代码前问清楚、动手前写计划、实现前有验证、修 bug 时先找根因。

当这四件事变成默认动作，AI 就不再只是一个会写代码的聊天窗口，而更像一个能被流程约束、能被证据检查、能参与工程协作的开发伙伴。

参考资料

• GitHub：obra/superpowers
• GitHub API：repos/obra/superpowers
• Claude 插件市场：Superpowers plugin
• Anthropic 文档：Claude Code plugins