Jesse Vincent（GitHub 上的 obra）是一个在开源社区深耕二十多年的开发者。他写过键盘固件（Keyboardio 的 Kaleidoscope）、做过邮件客户端（K9-Mail 的核心维护者）、如今在 Prime Radiant 专注于 Agent 开发工具。他在 2025 年 10 月发布了 Superpowers——一个面向 AI Coding Agent 的完整软件开发方法论，以 skills 集合的形式提供，短短时间就冲到 196K stars。
如果你看过我之前写的 mattpocock/skills 那篇文章，你大概已经理解了"skill 文件"这个概念——YAML frontmatter + Markdown 指令集，Agent 读取后按指令执行。mattpocock/skills 提供的是离散的工具（盘问、TDD、架构审查），你需要自己决定什么时候用什么。Superpowers 的思路完全不同：它是一套自动触发的完整开发流程，从你打开 Agent 说出需求的那一刻起，到代码合入主分支为止，每个阶段都有对应的 skill 接管，而且 skills 之间会自动串联。
Vincent 管它叫"让你的 Agent 拥有超能力"。读完你会发现这个比喻不算夸张——它本质上是用一套指令模板，把一个散漫的 Agent 变成了一个遵循完整工程纪律的协作者。
如果说前面的章节是在讲 Superpowers 能做什么，这一节我们要问一个更尖锐的问题：它没有缺点吗？
设计的代价：当流程变成负担
Superpowers 对"先设计再实现"的坚持，在软件工程教科书里能找到完美的理论支撑。但实际开发中，很多有价值的东西是通过"先做出来看看"发现的。你没办法在 brainstorming 阶段预料到用户会怎么用这个功能，因为你自己也没用过它。
Vincent 在设计文档中提到"简单的项目可以写几句话"，试图给敏捷留出空间。但实践中，Agent 并不擅长判断"什么叫简单"——它倾向于把一切需求都展开成完整的 brainstorming 流程，因为 skill 告诉它"不要跳过设计"。一个五分钟能写完的 bug 修复，可能要花三分钟回答 Agent 的盘问、两分钟确认设计文档、然后才轮到你期待的那五分钟。对于熟练的开发者而言，这种体验可能更像是"终于教会了 Agent 怎么做事"而非"Agent 帮我把事做了"。
这不是反对设计。这是提醒你：Superpowers 的设计纪律是有摩擦成本的。它最适合的场景是那种"需要多人协作、多天开发、多轮审查"的中大型功能——这种场景下，前期设计投入被后期返工避免所抵消。但对于个人开发者的快速迭代、原型探索、或者"先做个 MVP 看看反响"的项目，Superpowers 的全程流程可能是一种过度工程。
谁在为这套方法论买单？
Superpowers 的 token 消耗模型值得算一笔账。以 subagent-driven-development 模式为例，每个任务触发至少三次 Agent 调用（实现 + spec 审查 + 代码审查），如果有问题还要走审查修复循环。对于一个 10 个任务的中等功能，保守估计 30-50 次 Agent 调用。用小模型跑机械任务可以降低成本，但小模型在 spec 理解和代码生成上的质量下降会反过来增加修复循环的次数——成本可能只是从 token 账单转移到了你的等待时间上。
这引出了一个更根本的问题：Superpowers 的受众到底是谁？ 是那些已经熟练掌握传统软件工程方法、现在想让 Agent 替代自己执行重复性工作的资深开发者？还是那些缺乏工程经验、需要一套自动化流程来弥补纪律缺失的新手？Vincent 在 README 中说这套流程让 Agent "像一个有热情但品味差、缺乏判断力、不熟悉项目上下文、还讨厌写测试的初级工程师"。问题是——如果你自己都不知道怎么带一个初级工程师，你有多大把握带好一群 AI 初级工程师？
这不是怀疑 Superpowers 的价值。196K 的认可不可能全是盲目的。这是说，Superpowers 在"降低门槛"这件事上可能做了一个错误的承诺。它降低的是 Agent 写代码的组织门槛——不用手动组织 subagent、不用人工审查每个任务的 spec 合规性。但它并没有降低——甚至可能提高了——对使用者的工程判断力要求。你需要判断 Agent 的设计方案是否合理、需要决定哪些审查意见是有效的、需要在 subagent 报 BLOCKED 时诊断根因。这些能力恰恰是传统软件工程中最难培养的部分。
Superpowers 是一个值得认真对待的工程实验。但对待它的最好方式，也许不是把它当作答案，而是把它当作一个起点——理解它的设计意图，然后根据自己的项目和能力，裁剪出一套属于你自己的流程。就像 Vincent 在文档末尾写的那样，这不是宗教。这是一套工具。工具的意义不在于被信仰，而在于被使用、被修改、被超越。
六、FAQ
Q1：Superpowers 的 brainstorming 是不是太"重"了？给一个 todo list 也要走完整流程？
Superpowers 的立场很明确：简单的需求恰恰是最容易因为未检验假设而翻车的地方。"加一个 todo list"——存储在哪？本地还是云端？需要同步吗？排序规则是什么？这些假设如果在实现中途才发现不对，返工成本远超 brainstorming 那几分钟。但设计文档的长度可以按复杂度缩放——简单的需求写几句话就行，不需要长篇大论。
Q2：子 Agent 的两级审查（spec + code quality）会不会太费 token？成本怎么控制？
这是 Superpowers 最明显的成本来源——每个任务要派 1 个实现 agent + 2 个审查 agent。但它采用了"用最便宜的模型做最简单的事"的策略：机械性实现任务用小模型，审查任务用标准或强模型。而且 Vincent 的核心理念是"早发现比晚修复便宜"——在子 Agent 阶段拦截问题，比合并后 debug 省 token。实际使用中，只要任务拆得够细（2-5 分钟一个），单任务的审查成本是可控的。
Q3：Agent 在 subagent-driven-development 模式下真的能自主跑一两个小时？会不会跑偏？
会跑偏，但有机制防范。第一道防线是 spec——每个任务都对照 spec 验证合规。第二道防线是两级审查——如果实现 subagent 的理解有偏差，审查 subagent 会挡下来。第三道防线是实现 subagent 有四种状态报告（DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED），遇到问题会主动升级而不是硬撑。Vincent 提到"一两个小时"是比较顺利的情况，实际使用中还是会时不时需要你介入回答 subagent 的问题。
Q4：TDD 的"事先写的代码必须删除"这条铁律是不是太极端了？
这不是道德洁癖，是一个实用的工程判断。测试后写的代码有一个根本问题：你永远不知道测试是否真正捕捉到了正确的行为——因为测试一写就通过。只有先看到测试因为"功能缺失"而失败（不是语法错误），你才能确认这个测试确实在测你要实现的东西。如果保留了先写的代码再做测试，你实际上是在"对着实现写测试"而非"对着需求写测试"，很容易测的是实现细节而非行为。
Q5：Superpowers 适合老项目还是新项目？
都适合，但老项目需要注意一点：brainstorming 的"探索项目上下文"阶段会读取现有文件、文档和最近提交来理解代码库。如果老项目的代码结构混乱、缺乏模式，Agent 可能需要更长的探索时间，提出的方案也可能不够精准。建议在老项目中先用一次 brainstorming 走完整流程，看看 Agent 对代码库的理解程度，再决定是否全面采用。
Q6：多个 Agent 平台都支持，实际体验有差异吗？
有。Superpowers 的 skills 是通用的 Markdown 指令，但不同 Agent 对 skill 的"理解深度"和"执行纪律"不同。Claude Code 对 subagent 的支持最成熟（Superpowers 最早就是为 Claude Code 设计的），Codex CLI 的执行速度更快但 TDD 纪律偶尔会松动。实际使用中建议用 Claude Code 做主 Agent、Codex 做实现 subagent 的混合模式。
Q7：我可以只装部分 skill 吗？比如只用 brainstorming 和 TDD，不用子 Agent 编排？
技术上可行——skills 是独立的 .md 文件，你可以选择性安装。但 Superpowers 的很多 skill 之间有硬依赖：subagent-driven-development 依赖 writing-plans 产出的计划格式，writing-plans 依赖 brainstorming 产出的 spec 路径约定。拆开用的结果可能是 skill 之间的衔接断裂，导致流程中断。如果你只需要部分功能，更推荐用 mattpocock/skills 那种独立组合式的 skill 集合。
Q8：和 mattpocock/skills 能共存吗？
可以，但需要留意冲突点。两者的 TDD skill 都会在你写代码时被触发，可能产生竞争。建议的做法是：用 Superpowers 作为主要工作流（覆盖 brainstorming → 实现 → 合入的完整链路），把 mattpocock/skills 中的 /diagnose、/improve-codebase-architecture、/prototype 等 Superpowers 没有覆盖的 skill 作为补充工具。两者用的都是 skill 文件格式，在同一个项目中安装不会相互覆盖。
参考资料
- [1] Superpowers GitHub: https://github.com/obra/superpowers
- [2] 原始发布公告: https://blog.fsck.com/2025/10/09/superpowers/
- [3] Jesse Vincent GitHub: https://github.com/obra
- [4] Prime Radiant: https://primeradiant.com/
- [5] Superpowers Discord: https://discord.gg/35wsABTejz
- [6] mattpocock/skills（参考对比）: https://github.com/mattpocock/skills
