Superpowers 深度使用指南

一句话：Superpowers 是运行在编码 Agent 之上的一组可组合 Skill，把「先问清、先计划、先写测试、再实现、再验证」固化成 Agent 会主动执行的流程；它不提升模型能力，换来的是过程可重复，代价是流程开销和工具绑定。

来源说明：Superpowers 是 Jesse Vincent（GitHub: obra）发起的开源项目，官方仓库为 github.com/obra/superpowers，主要以 Claude Code 插件形式分发。本文写作于 2026-10，安装命令、Skill 名称与支持的工具以官方 README 为准。社区分支、中文增强版和个人移植不属于官方能力。

为什么需要

Agent 的默认策略是「尽快给出代码」。这会带来四类问题：

• 跳过设计：直接改文件，方案在实现过程中临时决定，事后说不清为什么。
• 跳过测试：代码看起来对，语法正确、命名规范，但逻辑没人验证。
• 上下文漂移：长会话里早期约束被逐渐稀释，后面越写越偏。
• 范围蔓延：顺手重构、顺手加功能，偏离最初需求。

这些不是某个模型的 bug，是「以生成为中心」的默认行为。Superpowers 的思路是把软件工程纪律写成 Agent 可加载的 Skill，让流程在正确的时机被触发，而不是靠人每次口头提醒。

核心机制

1. Skill 是流程包，不是模型能力

每个 Skill 是一份带触发条件的操作说明（SKILL.md），Agent 读取后按步骤执行。官方仓库提供的 Skill 包括头脑风暴、写计划、执行计划、测试驱动开发、系统化调试、请求代码审查、完成前验证、子 Agent 驱动开发等。

网上常见的「七阶段」是二次归纳；官方以 Skill 为单位组织，阶段数量随组合变化，不要当成固定产品结构。

2. 先设计，后实现

• 头脑风暴：通过追问把需求问清，重点问异常、边界、非功能约束。
• 写计划：产出可执行计划，包含文件路径、步骤、验证方式。计划落盘，不留在对话里。

计划落盘的价值在于：它是人和 Agent 共同的检查点。计划错了，改计划比改代码便宜。

3. 用独立子 Agent 执行任务

子 Agent 驱动开发把计划中的任务分给独立子 Agent，每个子 Agent 只拿当前任务和必要上下文。这样做的目的不是「更聪明」，而是减少长会话中早期约束被稀释。任务之间有文件依赖时应串行，否则并行会放大冲突。

4. TDD 作为门

测试驱动开发 Skill 要求：先写失败测试（RED），再写最小实现（GREEN），最后重构。完成前验证 Skill 要求跑命令并贴出输出，而不是口头声称「已完成」。

关键取舍：Skill 是「流程建议 + 检查清单」，不是沙箱强制。Agent 仍可能跳过步骤。可靠性来自你检查产物（计划文件、失败测试、验证输出），不是来自装上插件。

最小上手

以 Claude Code 为例，安装命令以官方 README 为准：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

然后选一个小功能走一遍：

1. 说「用 brainstorming skill 帮我把这个需求问清楚」，认真回答它的问题。
2. 让它用 writing-plans 产出计划，检查计划里是否有文件路径、步骤和验证命令。
3. 让它按计划执行，要求每个任务先写失败测试。
4. 结束前要求执行 verification-before-completion，贴出命令和输出。

跑通的标志：计划文件存在；测试先红后绿；验证命令有输出；git 历史能看出任务边界。四项缺一项，说明流程只走了一半。

生产动作

• 锁版本。 插件和仓库会变，团队统一版本并记录在 README，升级前在分支验证。
• 按代价分级。 认证、支付、数据迁移走完整流程；CRUD、文案、样式改动用小流程。
• 审查产物而不是只审 diff。 计划、测试、验证输出都应是交付物的一部分。
• 控制子 Agent 数量。 并行会放大 token 消耗和文件冲突；有依赖就串行。
• 审计第三方 Skill。 读源码，确认它执行的命令、写入范围和网络访问；不要因为名字里有「superpowers」就默认可信。

边界

• 官方主要面向 Claude Code。 其他工具的适配多为社区移植，能力和行为不一致，不能当成官方保证。
• 它管「怎么做对」，不管「做什么」。 需求规范仍需单独写，Superpowers 不替代 SDD 的规范环节。
• 流程有开销。 小改动、一次性脚本、探索性原型用全套流程通常不划算。
• 不能替代人的 Review。 Skill 能要求审查，但不能保证审查质量。
• 不要把第三方分支、个人仓的「增强版」写成官方能力。 安装前确认仓库归属、维护状态和许可证。

讲清楚

Superpowers 的本质是把软件工程纪律打包成 Agent 能加载的 Skill。它解决的是 Agent 默认「先出代码」带来的问题：不设计、不测试、长会话跑偏、顺手改范围。机制上有四步：先把需求问清并写成计划，再用独立子 Agent 执行，执行时强制先写失败测试，最后用验证命令和独立审查收口。它不提升模型能力，也不保证 Agent 一定遵守；可靠性来自你检查计划、测试和验证输出。它主要面向 Claude Code，其他工具的支持要看官方文档。小改动不值得上全套，改错代价高的核心路径才值得。

---

初稿 2026-07 | 最后修订 2026-10 | 事实核查：移除无出处的工具数量、Star 数与模型路由；区分官方能力与社区实践