【摘要】
第一，obra/superpowers 由 Jesse Vincent 开发，把完整软件开发方法论固化为一个可安装的 skill，先问“你到底想做什么”，再拆成 spec、写 TDD 实施计划、跑子 Agent 驱动的开发流程，可装到 Claude Code、Codex、Cursor、Gemini CLI 等 8 个以上的 harness。
第二，它不发明新方法论，而是把 spec-first 和 test-driven development 封装成可复用的 prompt 链，降低团队采纳规格驱动开发的执行成本；283k 星说明社区对这种“先想清楚再动手”的 AI 编程方式有强烈需求。
第三，superpowers 适合有明确业务需求的中大型模块，不适合纯探索性原型或单行脚本；过度 rigid 的流程在快速试错场景反而拖慢速度，团队应根据项目阶段选择是否启用完整流程。
一、superpowers 不是什么新工具，而是可安装的 skill
superpowers 不是一个独立的 IDE 或 CLI 工具，而是一套可被多种 AI 编程工具加载的 skill。它定义了一个对话框架：当你在 Claude Code、Codex、Cursor 或 Gemini CLI 中激活这个 skill，Agent 会先停下来问你“你到底想做什么”，然后按照固定的方法论推进。整个流程包括意图澄清、规格编写、TDD 计划、子 Agent 分解执行，每一步都有明确的输出产物。
这种设计的好处是方法论可移植。今天用 Claude Code 写后端，明天换 Codex 写前端，只要装上同一个 skill，行为一致。团队不用再靠口头约定或 wiki 文档来对齐开发流程，skill 本身就是可执行的规范。
| 特性 | 纯 vibe coding | 手工规格+AI | superpowers skill |
|---|---|---|---|
| 启动方式 | 直接写提示 | 先写文档再喂AI | 激活 skill，AI 自动引导 |
| 需求确认 | 隐式在对话中 | 靠人工 review | Agent 主动追问意图 |
| 测试策略 | 事后补或省略 | 人工指定 | TDD 计划自动生成 |
| 多工具一致性 | 依赖个人习惯 | 依赖文档 | 同一 skill 跨工具 |
| 学习成本 | 低 | 中等 | 中等（需接受流程） |
表：三种 AI 编程方式的对比
二、核心流程：先问意图，再写 spec，再 TDD 计划，再子 agent 执行
superpowers 的工作流大致分为四步，每一步都有明确的输出物。
第一步是意图澄清。Agent 不会直接写代码，而是先问一系列问题：你要解决什么问题？用户是谁？核心功能是什么？有哪些边界条件和例外？这些问题写在 skill 的 prompt 里，不是随机的，而是经过设计的，目的是把模糊的需求转化为可操作的描述。
第二步是规格编写。基于澄清的结果，Agent 生成一份 spec 文档，通常包含功能列表、数据流、接口约定和验收标准。这份 spec 不是写给 AI 看的，而是给人审阅的。用户可以在这一步修改，确认后再进入下一步。
第三步是 TDD 实施计划。Agent 根据 spec 拆解出具体的测试用例，按优先级排列，并为每个测试用例制定实现策略。测试用例本身就是可执行的代码（比如 pytest 或 Jest），实现计划则描述了如何通过测试。这一步的核心是把“先写测试再写代码”的原则固化到流程里。
第四步是子 Agent 驱动的开发。superpowers 会把实现任务分配给多个子 Agent 并行或串行执行，每个子 Agent 负责一个测试用例或一个小模块，完成后自动回归。父 Agent 负责协调和整合，确保最终产出符合 spec。
superpowers 工作流产出定性意图澄清阶段 ████████ 产出需求问答记录，减少误解规格编写阶段 ██████████ 产出 spec.md，供人工审阅TDD 计划阶段 ████████ 产出测试清单和实现策略子 Agent 执行 ██████████ 产出代码和测试结果说明：前三个阶段花的时间越多，最后一个阶段的返工越少。
三、为什么 283k 星：降低方法论执行成本
283k 星在 GitHub 上是非常高的数字，说明社区对这个项目的认可。原因不在于 superpowers 提出了多么革命性的理论，而在于它把一套已经被证明有效的工程实践（spec-first + TDD）变成了一个“一键安装”的东西。
过去，团队要想推行规格驱动开发，需要写文档、做培训、在 code review 中反复强调。现在，只要在 Claude Code 里装一个 skill，AI 就会自动引导开发者走完整个流程。对于个人开发者来说，这也是一种自我约束：当你面对一个复杂模块时，superpowers 强迫你先想清楚再动手，避免写到一半发现方向错了。
另外，superpowers 的许可证是 MIT，完全开源，任何人都可以 fork 修改。Jesse Vincent 本人也是知名开发者（Keyboardio 创始人），他的信誉也为项目增加了信任度。
四、与 Spec Kit 的异同：都是规格驱动，但 superpowers 更轻、更强调 TDD
GitHub 官方不久前发布了 Spec Kit，同样是规格驱动开发，但两者有明显的侧重差异。
Spec Kit 更像一个完整的工程框架，定义了六个阶段（constitution、specify、clarify、plan、tasks、implement），并且有自己的 CLI 和目录结构。它适合大型团队和长期项目，强调产物可审计、可追溯。
superpowers 则更轻量，它不强制特定的目录结构，也不依赖额外的 CLI。它只是一个 skill，安装后就能用，卸载后也不留下文件。它的核心是 TDD 计划，而 Spec Kit 的 tasks 阶段更偏向任务拆分而非测试优先。
| 对比维度 | GitHub Spec Kit | obra/superpowers |
|---|---|---|
| 形态 | CLI + 目录结构 | 可安装 skill |
| 安装复杂度 | uv install | 复制 prompt 或通过包管理器 |
| 核心强调 | 规格文档化、门禁 | 意图澄清 + TDD |
| 适用规模 | 中大型团队 | 个人到中型团队 |
| 工具支持 | 30+ 智能体 | 8+ harness |
| 许可证 | 开源 | MIT |
表：Spec Kit 与 superpowers 的异同
五、适用边界：别把 superpowers 当银弹
superpowers 最大的价值在于把混乱的 AI 编程变得有序，但它并不适合所有场景。
适合的场景：新功能开发，尤其是涉及多个文件、需要明确接口的业务逻辑；重构已有模块，先写 spec 和测试可以防止回归；团队协作，当多个开发者用不同的 AI 工具时，superpowers 提供了统一的流程。
不适合的场景：快速原型验证，比如做一个 demo 给投资人看，这时候速度比流程重要；单行脚本或一次性任务，写 spec 的时间比写代码还长；纯创意探索，比如写一首诗或生成一张图片，不需要 TDD。
另外，superpowers 的效果高度依赖于用户自己的需求澄清能力。如果你连自己想要什么都不清楚，Agent 追问再多问题也没用。所以它更适合有一定产品思维的开发者，而不是完全的新手。
企业落地建议：先在内部选择一个中等复杂度的模块做试点，让团队体验一下完整的流程。如果觉得太 rigid，可以只使用前两步（意图澄清和规格编写），跳过 TDD 计划，或者只对核心模块启用全流程。superpowers 的设计允许按需裁剪，不是非要全盘接受。