你有没有这种感觉——让 AI 写代码，它动不动就跑偏，写完一堆自己也没验证过。你让它加个登录功能，它三分钟给你蹦出来 500 行代码，既没测试也没验证，你还得一行行看它写的对不对。

其实问题不是 AI 不够聪明，是它太急了——拿到需求就开干，从不先想清楚。

Superpowers 就是来解决这个问题的。说白了，它是 Claude Code 的一个插件，装上之后 AI 就有了”先想再动手”的习惯。不是建议，是强制——不按流程走，它连一行代码都写不了。

一分钟装好 Superpowers

在 Claude Code 里执行一条命令就行：

/plugin install superpowers@claude-plugins-official

装完之后怎么确认生效了？下次你提个开发需求，AI 不会直接写代码，而是先跟你说：

I'm using the brainstorming skill to explore your requirements before implementation.

看到这句话，就说明 Superpowers 已经接管了。

顺便提一句，它不只能用在 Claude Code 上——GitHub Copilot CLI、Gemini CLI、Cursor 都支持，安装方式略有不同，感兴趣的可以去项目 README 里查。

先看全貌：Superpowers 到底干了什么

你提一个需求，Superpowers 会带着 AI 走完这样一个流程：

你提需求
  → brainstorming（AI 先不写代码，问清楚你要什么）
  → writing-plans（把需求拆成 2-5 分钟的微型任务）
  → using-git-worktrees（开一个隔离的分支干活，不污染主代码）
  → subagent/execute（AI 按计划干活）
  → test-driven-development（先写测试，再写代码）
  → systematic-debugging（遇到 bug 系统排查，不瞎猜）
  → verification + finishing（跑一遍验证，确认做完了再交付）

这里有几个关键点要说清楚：

第一，这不是你手动切换的模式。 Superpowers 的每个阶段是一个 skill，AI 会自动判断当前该用哪个，不需要你操心。

第二，这不是”建议”。 它是铁律。比如 TDD skill 里写着：”没有失败的测试就不许写产品代码。”AI 想跳过？不行。

第三，核心哲学就三条：

• TDD（测试驱动开发）
• Systematic over Ad-hoc（系统化优于拍脑袋）
• Evidence over claims（拿证据说话，别光嘴上说完成了）

阶段一：brainstorming——AI 学会了”先问再做”

装了 Superpowers 之后，你跟 AI 说”帮我做一个登录页面”，它不会直接甩代码给你。

它会问你：

“这个登录页面是给什么产品用的？Web 端还是移动端？”

你回答了，它接着问：

“登录方式是账号密码，还是需要支持第三方登录（比如微信、GitHub）？”

你再回答，它继续：

“密码需要做强规则校验吗？比如必须包含大小写和特殊字符？”

看出来了吗？这就是苏格拉底式对话——一次只问一个问题，逐步把你的模糊想法变成明确的设计方案。

这个过程不是随便聊聊就完了。AI 会做这些事：

1. 先看看你的项目现状（文件结构、最近的提交）
2. 一个问题一个问题地问，搞清楚目的、约束和成功标准
3. 提出 2-3 个方案，说明各自的利弊，给出推荐
4. 分段展示设计，每段都等你确认
5. 确认完了，把设计文档存下来

而且有一个硬规矩：不管多简单的任务都要走这个流程。 Superpowers 里专门写了一个反模式叫 “This Is Too Simple To Need A Design”——再简单的任务也得先想清楚，因为越”简单”的任务，藏着越多的假设和盲区。

说白了就是——AI 被禁止”想到哪写到哪”，它必须先想清楚你要什么，再动手。

阶段二：writing-plans——拆成微任务

设计方案敲定了，下一步不是写代码，是写计划。

Superpowers 的计划不是那种”第一步做前端、第二步做后端”的模糊描述。它把每个任务拆到 2-5 分钟 就能完成的粒度。

你看一个真实的计划片段长什么样：

### Task 1: 密码校验模块

**Files:**
- Create: `src/validators/password.ts`
- Test: `tests/validators/password.test.ts`

- [ ] Step 1: 写一个会失败的测试

```ts
test('rejects empty password', () => {
  const result = validatePassword('');
  expect(result.valid).toBe(false);
  expect(result.error).toBe('Password required');
});

• [ ] Step 2: 跑测试，确认它失败

Run: npm test tests/validators/password.test.tsExpected: FAIL

• [ ] Step 3: 写最少的代码让测试通过

exportfunctionvalidatePassword(pwd:string) {
if (!pwd) return { valid:false, error:'Password required' };
return { valid:true };
}

• [ ] Step 4: 跑测试，确认通过
• [ ] Step 5: 提交

注意几个关键点：

- 每一步都是**一个动作**，不是"把登录功能做完"
- 每一步都写了**具体文件路径**和**完整代码**
- 每一步都有**验证命令**和**预期结果**
- 计划假设执行者对项目**一无所知**

> 本质上就是把"做一个登录系统"拆成"写一个测试 → 跑一下 → 写三行代码 → 再跑一下"这种微型任务。

---

## 阶段三：using-git-worktrees——开个平行宇宙

计划写好了，开干之前还有一步：创建隔离的工作环境。

Superpowers 会自动帮你创建一个 git worktree。worktree 是什么？简单说就是同一个仓库的另一个目录，可以同时在不同分支上工作。

为什么需要这个？

你正在 main 分支上干活，突然要加个新功能。传统的做法是 `git stash` 存起来、切分支、干完再切回来——中间要是忘了 stash 或者有冲突就很烦。

worktree 不一样。它在另一个目录里创建了一个独立的工作空间，你主目录的代码完全不受影响。干完了，合并回来就行。

Superpowers 做的事更细致：

1. 自动选好目录位置（`.worktrees/` 或全局目录）
2. 确认目录在 `.gitignore` 里（防止误提交）
3. 创建 worktree 和新分支
4. 自动检测项目类型，跑依赖安装
5. 跑一遍测试，确认基线是干净的

> worktree 就像给项目开了个平行宇宙——主宇宙照常运转，新功能在平行宇宙里搞，搞完了再合并回来。

---

## 阶段四：subagent/execute——两种干活模式

计划有了，环境也准备好了，开始执行。这里有两种模式可以选：

### 模式一：subagent-driven（推荐）

AI 给每个任务派一个子代理去干活，干完自动做两轮 review——先检查是否符合设计文档，再检查代码质量。

你: 我要用 subagent-driven 模式执行这个计划

[读取计划文件，提取所有任务]

Task 1: 密码校验模块 [派子代理去实现] 子代理: “实现完成，5 个测试全部通过，已提交”

[派 spec reviewer 检查] Spec reviewer: ✅ 符合设计文档，没有遗漏，没有多余

[派 code reviewer 检查] Code reviewer: ✅ 代码质量合格

[Task 1 完成，进入 Task 2…]

整个过程你不用盯着，AI 自己干自己查。

### 模式二：executing-plans

AI 自己按步骤执行，但每做一步都会暂停等你确认。

你: 我用 executing 模式

[读取计划文件]

“开始执行 Task 1，Step 1: 写失败的测试” [写完测试] “Step 2: 跑测试看失败” [跑完] “继续 Step 3: 写实现代码吗？”

你: 继续 [写实现] …

### 怎么选？看这张表就够了：

| 对比项 | subagent-driven | executing-plans |
| ------ | --------------- | --------------- |
| 谁干活 | AI 派子代理干活 | AI 自己按步骤执行 |
| Review | 自动两阶段 review | 每步暂停等你确认 |
| 速度 | 快，可以自动跑几小时 | 慢，每一步都要人工 |
| 适合 | 信任 AI，想快速推进 | 想每一步都把关 |

> 一个是放手让 AI 干、它自己检查；一个是 AI 每做一步都问你。看你自己的风格。

---

## 阶段五：TDD——先写测试，再写代码

说到 Superpowers 最"硬"的规矩，就是 TDD 这条。

铁律只有一句话：

没有失败的测试，就不许写产品代码

流程是这样的，叫做 Red-Green-Refactor 循环：

RED（写一个会失败的测试） → 确认它确实失败了 → GREEN（写最少的代码让测试通过） → 确认它确实通过了 → REFACTOR（清理代码，保持测试通过） → 重复下一个测试

来个真实例子。假设你要修一个 bug：空邮箱被提交了没报错。

**RED —— 先写测试：**

```typescript
test('rejects empty email', async () => {
  const result = await submitForm({ email: '' });
  expect(result.error).toBe('Email required');
});

跑一下：

$ npm test
FAIL: expected 'Email required', got undefined

确认它失败了，失败原因是对的（功能缺失，不是拼写错误）。

GREEN —— 写最少的代码：

functionsubmitForm(data:FormData) {
if (!data.email?.trim()) {
return { error:'Email required' };
  }
// ...
}

跑一下：

$ npm test
PASS

REFACTOR —— 如果需要，清理一下代码，但别加新功能。

如果你说”这太简单了不需要 TDD 吧”——Superpowers 里专门有个常见借口对照表：

先写测试看它失败，再写代码看它通过。别问为什么，试一次你就知道了。

阶段六：systematic-debugging——系统排查 bug

遇到 bug，大多数人（包括大多数 AI）的第一反应是”我猜问题在这，改一下试试”。Superpowers 不允许这么干。

它的铁律是：

没找到根因，不许修 bug

排查分四个阶段，必须按顺序来：

Phase 1: 根因排查——读错误信息、稳定复现、查最近的变更、追踪数据流

Phase 2: 模式分析——找类似但正常工作的代码，对比差异

Phase 3: 假设验证——”我觉得是 X 导致的，因为 Y”，然后做最小的改动来验证

Phase 4: 实现修复——写一个会失败的测试复现 bug，然后修

举个例子对比一下：

❌ 错误做法：

看到 NullPointerException → 直接加 if (x != null) 打补丁

这是治标不治本。null 从哪来的？下次换个地方还是 NPE。

✅ 正确做法：

看到 NullPointerException
  → 追踪这个 null 是从哪传进来的
  → 发现是数据库查询返回了 null
  → 为什么返回 null？因为查询条件拼错了
  → 修查询条件，这才是根因
  → 写个测试复现这个 bug
  → 确认测试失败了
  → 修复查询条件
  → 确认测试通过了

Superpowers 里还有个硬规定：如果同一个 bug 你试了 3 次修复都没好，停下来质疑架构——大概率不是代码的问题，是设计有问题。

遇到 bug，先找到病根再开药方，而不是头痛医头脚痛医脚。

阶段七：交付收尾——AI 说了不算

代码写完了，测试也过了，就可以交差了吗？不行。

Superpowers 还有两道关卡。

第一关：verification-before-completion

AI 想说”我做完了”，必须先跑验证命令，拿到真实输出。

❌ "应该没问题了"
❌ "我很有信心"
❌ "看起来是对的"

✅ [跑 npm test] [看到 34/34 pass] "所有测试通过"
✅ [跑 npm run build] [看到 exit 0] "构建成功"

核心原则就四个字：拿证据说话。

任何没有跑过验证就声称完成的行为，在 Superpowers 里都算违规。

第二关：finishing-a-development-branch

验证通过后，AI 会给你 4 个选项：

实现完成。你想怎么处理？

1. 合并回 main 分支
2. 推送并创建 Pull Request
3. 保留分支，我稍后自己处理
4. 丢弃这些工作

选哪个？

注意第 4 个选项——如果你选了丢弃，AI 会让你手动输入 “discard” 来确认，防止误操作。

完成不是 AI 说了算——它必须拿证据证明自己做完了，然后让你决定怎么收场。

Skill 速查表（建议收藏）

Superpowers 一共十几个 skill，按使用频率分成三类：

常用 skill（几乎每次开发都会触发）

协作流程 skill（开发过程中按需触发）

按需使用 skill（特定场景）

收尾

所以 Superpowers 本质上就是给 AI 编程助手装了一套纪律系统——先想清楚再动手、先写测试再写代码、先找到根因再修 bug、先验证再说完成。

它不是让 AI 变得更聪明，而是让 AI 变得更靠谱。聪明但不靠谱的助手，比笨但靠谱的助手更危险——因为你容易信任它。

装上试试，用一次你就回不去了。