Superpowers 深度解析：如何用「工程纪律」管住 AI 编程的混沌——从 TDD 到自我审查的七门必修课

2026 年 GitHub Star 突破 14 万、日增 783 颗，超越 Claude Code 内置能力的「外挂级」技能框架。

作者：程序员茄子 | 发布时间：2026-04-12

一、背景：AI 编程的繁荣与混乱

2026 年，Claude Code、Cursor、Copilot 等工具已经把 AI 编程推到了前所未有的高度。写一个 API，丢给 AI，30 秒出代码；搭一个项目结构，AI 一口气搞定；甚至整个后端服务，AI 也能给你肝出来。

但繁荣背后，问题也在积累。

「AI 写得很快，但质量一言难尽」——这是过去一年社区里出现频率最高的抱怨之一。代码能跑，但测试覆盖率感人；功能实现了，但边界条件全崩；改了一个 bug，引出三个新 bug。问题的根源不在 AI 模型不够强，而在于 整个开发过程缺乏结构性约束。

大多数 AI 编程工具的工作模式是这样的：你给一个 prompt，AI 返回一段代码，完成。这个过程里没有需求澄清、没有测试先行、没有代码审查、没有分支隔离——所有软件工程里沉淀了几十年的最佳实践，在 AI 时代被一股脑丢掉了。

Superpowers 就是在这样的背景下诞生的。

它的核心思路非常清晰：不是让 AI 写得更快，而是让 AI 写得更对。 通过强制性的结构化工作流，把 AI 从「随心所欲的代码生成器」升级为「遵循工业级开发规范的职业工程师」。

二、Superpowers 是什么：从「写代码」到「做工程」

2.1 基本定位

Superpowers（GitHub: obra/superpowers，2026 年初正式开源）是一套专为 AI 编程助手设计的技能框架（Skills Framework）。它不是又一个 AI 编程工具，而是一套叠加在现有 AI 编程工具之上的「工程 SOP」。

说得更直白一点：Superpowers 给 Claude Code（或其他兼容 Agent）装上了一组「强制门禁」——在 AI 真正开始写代码之前，它必须先过掉这些门禁，否则代码不会被接受。

这套框架由开发者 Jesse Vincent（obra）创建，最初是为了解决自己在实际项目中使用 Claude Code 时遇到的混乱——AI 生成的代码质量参差不齐、返工率高、后期维护困难。经过几个月的迭代，这套个人工具逐渐演变成了一个拥有 14 万 Stars 的开源项目。

2.2 核心指标

2.3 核心理念：「流程胜于猜测」

Superpowers 的核心哲学只有一句话：「流程胜于猜测」（Process Over Guessing）。

它的设计者 Jesse Vincent 在项目文档里写过一段话，大意是：大多数 AI 编程失败的根本原因，不是模型不够聪明，而是 AI 在没有充分理解需求的情况下就开始「猜测」代码。需求不清、边界不明、测试缺失——这些问题在传统的 AI 编程流程里被完全忽略了。

Superpowers 通过强制性的门禁步骤，确保 AI 在动手之前先把事情想清楚。

三、七门必修课：Superpowers 的技能体系全解析

Superpowers 的技能体系由七个核心技能（Skills）组成，每个技能对应开发流程中的一个特定阶段。这七个技能像门禁一样串联起来，形成一个完整的工程化开发流程。

3.1 brainstorm——先把需求问清楚再给方案

功能：AI 像产品经理一样，主动向用户提问，把模糊的想法转化为清晰的技术方案。

这是整个流程的第一步，也是最重要的一步。大多数 AI 编程失败，根源在于需求不清晰——用户说「帮我写一个用户登录功能」，AI 直接开始写代码，结果用户实际需要的是「支持 OAuth2 + 短信验证码 + 设备管理」。

brainstorm 技能的prompt会强制 AI 执行以下行为：

1. 需求澄清：主动提问，确认功能范围、边界条件、成功标准
2. 方案设计：在给出代码之前，先给出设计文档（design.md）
3. 风险识别：指出可能的技术风险和依赖项

一个典型的 brainstorm 交互示例：

用户：帮我做一个文件上传功能
AI（启动 brainstorm）：
  1. 文件大小限制是多少？是否有文件类型限制？
  2. 上传是同步还是异步？大文件是否需要分片上传？
  3. 存储后端用什么？本地磁盘、S3、还是云存储？
  4. 权限控制？是否需要审核流程？
  5. 上传进度是否需要实时反馈？

  [等待用户回答后，生成 design.md]

design.md 的内容包括：

• 功能范围定义
• API 设计（端点、请求/响应格式）
• 数据模型设计
• 技术选型与替代方案
• 风险评估与缓解措施
• 验收标准（可测试的条目）

这一步的意义在于：把「写代码前的思考」变成强制步骤，而不是可选步骤。

3.2 using-git-worktrees——用环境隔离控制复杂度

功能：自动为每个任务创建独立的 git worktree，避免多任务之间的代码冲突。

这是 Superpowers 里最「看不见」但最关键的技能之一。在实际开发中，你经常需要同时处理多个任务——比如在做一个功能的同时，还要修一个 bug。如果所有代码都在同一个分支上，改动很容易互相踩踏。

git worktree 是 Git 2.5+ 引入的功能，允许你在同一个仓库的不同目录同时checkout 不同分支，而不需要 clone 多次仓库。Superpowers 自动利用这个特性，为每个任务创建独立的工作目录。

工作原理：

# Superpowers 自动执行（用户不可见）
git worktree add ../feature-payment-billing feature/payment-billing
cd ../feature-payment-billing

# 每个任务在独立目录，互不干扰
# 完成后，通过 git worktree remove 清理

为什么这很重要？

在传统 AI 编程流程里，AI 可能会在同一个文件里同时处理多个任务，导致代码碎片化、相互覆盖。git worktree 隔离确保每个任务有自己独立的代码空间，不会相互影响。

实际开发中的价值：当你让 AI 同时做三件事——「登录模块」「支付模块」「报表模块」——如果不用 worktree，三个模块的代码可能混乱地交织在一起。用 worktree，AI 会为每个模块创建独立的开发目录，最后通过 PR 流程合并到主分支。

3.3 write-plan——把大任务打碎成 2-5 分钟可执行的小步

功能：在开始写代码之前，先把实现计划拆成若干个可以在 2-5 分钟内完成的小任务。

这是 Superpowers 最具特色的设计之一：强制小步快跑。

大多数 AI 编程工具的工作模式是「一次性生成」——你让 AI 写一个功能，它直接给你出一大段代码。问题在于，大段代码很难验证、很难调试、也很难审查。

write-plan 技能强制 AI 在写代码之前，先输出一个实施计划，格式如下：

# Superpowers Plan: 用户认证模块
## 任务 1: 数据模型设计
- 文件: src/models/user.ts
- 变更: 新建
- 验证命令: npx tsc --noEmit
- 预计时间: 2 分钟

## 任务 2: 数据库迁移
- 文件: src/db/migrations/001_create_users.sql
- 变更: 新建
- 验证命令: psql -d app_dev -f src/db/migrations/001_create_users.sql
- 预计时间: 3 分钟

## 任务 3: 基础 CRUD API
- 文件: src/routes/auth.ts
- 变更: 新建
- 验证命令: curl http://localhost:3000/api/users | jq
- 预计时间: 4 分钟

## 任务 4: JWT 认证中间件
- 文件: src/middleware/auth.ts
- 变更: 新建
- 验证命令: npm test
- 预计时间: 5 分钟

每个任务都有：

• 精确的文件路径：AI 知道该改哪个文件
• 明确的变更描述：AI 知道自己要做什么
• 验证命令：任务完成后立即验证
• 预计时间：2-5 分钟，确保任务足够小

这样做有几个好处：

1. 降低认知负担：AI 每次只需要处理一个小问题，不需要在脑子里同时维护「整个功能」的复杂度
2. 即时反馈：每完成一个小任务，立即验证，发现问题立即修正
3. 可审查：用户可以在每个任务完成后检查 AI 的思路，及时纠偏
4. 可中断：任务被打断也没关系，已经完成的任务是稳定可用的

3.4 test-driven-development——严格走 RED-GREEN-REFACTOR

功能：强制执行 TDD（测试驱动开发）流程：先写测试（RED），再写代码（GREEN），最后重构（REFACTOR）。

TDD 对人类程序员来说是「知道但懒得做」的事情，对 AI 来说更是如此——AI 倾向于直接写实现代码，测试往往被忽略或者作为事后补充。

Superpowers 的 TDD 技能强制要求：

第一步（RED）：AI 先写测试用例，确认测试是失败的（因为代码还没写）
第二步（GREEN）：AI 再写最少的代码让测试通过
第三步（REFACTOR）：在测试保护下优化代码

一个实际的例子——实现一个字符串反转函数：

// === RED 阶段 ===
// src/utils/string.test.ts

import { describe, it, expect } from 'vitest';
import { reverseString } from './string';

describe('reverseString', () => {
  it('应该反转基本字符串', () => {
    expect(reverseString('hello')).toBe('olleh');
  });

  it('应该处理空字符串', () => {
    expect(reverseString('')).toBe('');
  });

  it('应该处理单字符', () => {
    expect(reverseString('a')).toBe('a');
  });

  it('应该处理包含空格的字符串', () => {
    expect(reverseString('hello world')).toBe('dlrow olleh');
  });

  it('应该处理中文字符', () => {
    expect(reverseString('你好世界')).toBe('界世好你');
  });
});

// === GREEN 阶段 ===
// src/utils/string.ts

export function reverseString(input: string): string {
  return input.split('').reverse().join('');
}

// === REFACTOR 阶段 ===
// （此时测试全部通过，可以安全重构）
// 例如：优化为更高效的实现
export function reverseString(input: string): string {
  let result = '';
  for (let i = input.length - 1; i >= 0; i--) {
    result += input[i];
  }
  return result;
}

这个 TDD 流程的意义不在于「测试本身」，而在于它强制 AI 在写实现代码之前先想清楚「什么是正确的」——测试用例就是「正确」的定义。

3.5 subagent-driven-development——子代理驱动开发

功能：为每个小任务启动独立的子代理执行，配合两阶段审查机制。

当 write-plan 把整个功能拆成多个小任务后，subagent-driven-development 技能负责把这些任务分配给独立的子代理执行。

为什么需要子代理？

因为大任务让一个 AI agent 去做，容易出现「上下文膨胀」——随着代码量增加，AI 的注意力分散，容易忽略细节、忘记早期的设计决策。

子代理的工作模式：

主代理（规划者）
├── 子代理 1 → 任务 1（数据模型设计）
│   ├── 执行
│   ├── 单元测试
│   └── 提交
├── 子代理 2 → 任务 2（数据库迁移）
│   ├── 执行
│   ├── 集成测试
│   └── 提交
└── 子代理 3 → 任务 3（API 开发）
    ├── 执行
    ├── 端到端测试
    └── 提交

每个子代理在执行任务时，都受到 两阶段审查：

• 阶段一：功能审查——代码是否完整实现了需求？边界条件处理了吗？
• 阶段二：质量审查——代码是否符合规范？有没有重复代码？命名是否清晰？

两阶段审查的好处是让不同层面的检查解耦。功能审查确保「做了对的事」，质量审查确保「把事做对」。

3.6 requesting-code-review——每个阶段都做复核

功能：在关键节点强制引入人工或 AI 复核，确保代码质量。

Superpowers 的 code review 不是在代码写完之后才做，而是在每个关键节点都做。这是一个渐进式的审查机制，而不是传统的「一次性大批量审查」。

复核节点包括：

1. 设计文档复核：在 design.md 完成后，AI 暂停等待用户确认
2. 实施计划复核：在 plan.yaml 完成后，AI 暂停等待用户确认
3. 每个任务完成后：运行验证命令，结果发给用户
4. 最终合并前：完整的 PR 审查

这是一个典型的 Superpowers 审查节点输出：

✅ 任务 1 完成：数据模型设计
   验证命令输出：TypeScript 编译通过（0 errors）
   创建文件：src/models/user.ts
   代码行数：45 行

⏸️ 等待审查... 
   [用户可以在这里说「继续」或者「有问题，需要修改」]

这种机制把传统的「写完再review」变成了「边写边review」，极大地降低了返工成本。

3.7 finishing-a-development-branch——完成与合并

功能：所有任务完成后，AI 自动运行测试、清理分支，等待用户决定合并还是发 PR。

最后一步，AI 执行以下操作：

1. 运行完整测试套件：确保没有引入回归
2. 生成变更摘要：总结本次改动涉及哪些文件、改了什么
3. 清理工作目录：如果用了 git worktree，自动清理临时分支
4. 等待用户决策：合并到主分支 / 发 PR / 保留分支继续开发

# Superpowers 自动执行（示例）
git add -A
git commit -m "feat: 实现用户认证模块

- 添加用户数据模型（含邮箱、密码哈希、设备列表）
- 实现 JWT 认证中间件
- 添加注册/登录/登出 API
- 测试覆盖率: 94%

Closes: #42"

# 运行最终测试
npm test
# ✓ 42 tests passed, 0 failed

# 推送分支
git push -u origin feature/user-auth

# 等待合并
echo "分支已推送，等待合并到 main"

四、技术架构：Superpowers 是如何工作的

4.1 技能文件结构

Superpowers 的核心是一组 Prompt 文件，存放在 ~/.claude/skills/ 目录下（Claude Code 的 skills 目录）。每个技能是一个独立的 Markdown 或 YAML 文件，包含：

• Instructions：AI 在什么时机应该执行这个技能
• Rules：执行这个技能时的强制规则
• Examples：技能的输入/输出示例
• Validation：如何验证技能执行的结果

~/.claude/skills/
├── brainstorm.md          # 头脑风暴技能
├── write-plan.md          # 实施计划技能
├── test-driven-development.md  # TDD 技能
├── subagent-driven-development.md  # 子代理技能
├── requesting-code-review.md    # 代码审查技能
├── using-git-worktrees.md      # Git Worktree 技能
└── finishing-a-development-branch.md  # 完成技能

4.2 与 Claude Code 的集成机制

Superpowers 通过 Claude Code 的 Skills API 工作。Claude Code 在 2026 年初开放了 Skills 扩展接口，允许用户注册自定义技能，这些技能在 AI 的决策流程中作为「工具」被调用。

// Claude Code Skills API（概念示例）
// 用户在 ~/.claude/skills/superpowers/ 目录下放置技能文件
// Claude Code 在合适的时机自动触发这些技能

interface Skill {
  id: string;
  name: string;
  trigger: 'always' | 'once' | 'manual' | 'on-file-change';
  instructions: string;
  examples?: Example[];
}

// 触发时机示例
// brainstorm → 每次收到新的功能需求时触发
// write-plan → brainstorm 完成后立即触发
// TDD → 每次开始写实现代码前触发
// code-review → 每个文件修改后触发

4.3 与 git worktree 的集成

Superpowers 通过在 system prompt 中注入指令，让 Claude Code 在处理多任务时自动使用 git worktree：

# Superpowers 在初始化时注入的系统提示
You are working on a multi-task project.
When starting a new significant task, use: git worktree add ../{task-name} {branch-name}
When a task is complete, use: git worktree remove ../{task-name}
Never work on the main branch directly.

这段提示看起来简单，但它解决了一个非常实际的痛点——在 Claude Code 中，AI 经常「忘记」自己在哪个分支上工作，导致代码混乱。强制使用 worktree 把每个任务隔离到独立目录，物理上消除了这种混乱。

五、工程哲学：Superpowers 为什么有效

5.1 把工程纪律从「人」转移到「AI」

传统的软件工程最佳实践（TDD、代码审查、小步快跑）依赖人类程序员的纪律性。但人的纪律性是不稳定的——赶工期的时候会跳过测试，紧急修复的时候会跳过审查。

Superpowers 的聪明之处在于：它把这些纪律性要求编码成了 AI 的行为约束。AI 不会因为赶工期就跳过测试，不会因为疲惫就忽略代码审查——只要这些步骤被编码为技能，AI 就会无条件执行。

这是一个很有趣的思路转变：从「让人类遵守纪律」到「让 AI 强制执行纪律」。

5.2 需求先行：把「想清楚」变成强制步骤

大多数 AI 编程失败案例的本质是：prompt 质量决定代码质量，但用户往往给不出高质量的 prompt。

Superpowers 通过 brainstorm 技能，把「需求澄清」变成 AI 和用户的协作对话。AI 主动提问，用户逐步回答，最终生成一份结构化的 design.md。这份文档既是需求的最终确认，也是后续开发的设计依据。

它的意义不只是「让 AI 理解需求」，而是创造了一个用户和 AI 共同澄清需求的中间层。这个中间层让人类用户在代码生成之前就有了「审核权」，而不是等到代码写完了才发现「这不是我想要的」。

5.3 小步快跑：对抗复杂度的终极武器

软件工程中最古老的真理之一：大系统比小系统更难理解和维护。

Superpowers 的 write-plan 技能强制要求把任务拆成 2-5 分钟的小步。这个时间限制看起来随意，实际上非常有讲究：

• 小于 2 分钟：步子太小，任务切换成本超过收益
• 大于 5 分钟：步子太大，单个任务复杂度超出 AI 的注意力范围

这是一个经过大量实践验证的「甜蜜区」——足够小以至于可以快速验证，又足够大以至于有实际意义。

5.4 与 OpenClaw 的核心差异

看到这里，你可能会想：Superpowers 和 OpenClaw 看起来功能有重叠，都是 AI Agent 框架？

实际上，它们解决的问题域完全不同：

用一个不精确的比喻：Superpowers 是给 AI 编程的「质量审计员」，OpenClaw 是给 AI 助手的「操作系统」。两者解决的是不同层面的问题。

六、实战：从零搭建一个 API 项目

6.1 场景

我们用 Superpowers 来实现一个 Todo API（Node.js + Express + SQLite），演示完整的工作流程。

6.2 第一步：发起任务

$ claude
You: 帮我做一个 Todo API，支持创建、查询、更新、删除 todo

[AI 启动 brainstorm 技能]

6.3 Brainstorm 阶段

AI:
好的，开始需求澄清。

在开始之前，我需要确认以下几点：

1. **CRUD 范围**
   - Create: 创建新的 todo
   - Read: 查询单个 / 列表所有
   - Update: 更新 title、completed 状态
   - Delete: 单个删除 / 批量删除？

2. **数据结构**
   - Todo 需要包含哪些字段？
   - id、title、completed、created_at 是标配，还需要什么？
   - 例如：priority（优先级）、due_date（截止日期）、tags（标签）？

3. **持久化**
   - 用什么存储？内存 / SQLite / PostgreSQL / MongoDB？
   - 需要考虑数据迁移吗？

4. **API 风格**
   - RESTful？GraphQL？
   - 认证方式？JWT？API Key？

5. **边界条件**
   - Todo 标题的最大长度？
   - 是否需要分页？
   - 软删除还是硬删除？

请回答以上问题，我会生成一份 design.md。

6.4 生成 Design.md

AI（收到回答后）:
好的，我生成的设计文档如下：

# Todo API 设计文档

## 数据模型

| 字段 | 类型 | 说明 |
|------|------|------|
| id | UUID | 主键 |
| title | VARCHAR(200) | Todo 标题 |
| completed | BOOLEAN | 完成状态 |
| priority | INT | 优先级（1-5） |
| created_at | TIMESTAMP | 创建时间 |
| updated_at | TIMESTAMP | 更新时间 |

## API 端点

| 方法 | 端点 | 说明 |
|------|------|------|
| POST | /api/todos | 创建 Todo |
| GET | /api/todos | 获取列表（支持分页、过滤）|
| GET | /api/todos/:id | 获取单个 Todo |
| PATCH | /api/todos/:id | 更新 Todo |
| DELETE | /api/todos/:id | 删除 Todo |

## 技术选型

- **Runtime**: Node.js 20+
- **Framework**: Express.js
- **ORM**: Better-SQLite3（轻量、快速）
- **Validation**: Zod
- **Testing**: Vitest

## 验收标准

- [ ] 所有 CRUD 端点返回正确 HTTP 状态码
- [ ] Zod schema 验证请求数据
- [ ] 单元测试覆盖率 > 90%
- [ ] SQLite 数据库文件自动创建
- [ ] API 响应时间 < 100ms（单条查询）

6.5 Write-Plan 阶段

AI（生成实施计划）:

## Superpowers 实施计划

### 任务 1: 项目初始化
- 操作: npm init + 安装依赖
- 文件: package.json, package-lock.json
- 验证: node --version && npm --version
- 预计: 2 分钟

### 任务 2: 数据库层
- 操作: 创建 SQLite 表、初始化脚本
- 文件: src/db/index.ts, migrations/001_create_todos.sql
- 验证: sqlite3 todos.db < migrations/001_create_todos.sql
- 预计: 3 分钟

### 任务 3: Todo 模型（Repository 层）
- 操作: 实现 CRUD 操作函数
- 文件: src/repositories/todo.ts
- 验证: npm test（运行 todo repository 测试）
- 预计: 4 分钟

### 任务 4: 路由层
- 操作: 实现 Express 路由
- 文件: src/routes/todos.ts
- 验证: curl 测试各端点
- 预计: 5 分钟

### 任务 5: 主入口
- 操作: 整合 Express app，启动服务
- 文件: src/index.ts
- 验证: curl http://localhost:3000/api/todos
- 预计: 2 分钟

### 任务 6: 端到端测试
- 操作: Vitest 集成测试
- 文件: tests/e2e.test.ts
- 验证: npm test -- --run
- 预计: 3 分钟

是否开始执行？

6.6 TDD + 子代理执行

AI 开始按任务顺序执行，每个任务都遵循 TDD 流程（RED → GREEN → REFACTOR）。

以任务 3（Repository 层）为例：

// === RED: 先写测试 ===
// src/repositories/todo.test.ts

import { describe, it, expect, beforeEach } from 'vitest';
import { TodoRepository } from './todo';
import Database from 'better-sqlite3';

describe('TodoRepository', () => {
  let db: Database.Database;
  let repo: TodoRepository;

  beforeEach(() => {
    db = new Database(':memory:');
    db.exec(`
      CREATE TABLE todos (
        id TEXT PRIMARY KEY,
        title TEXT NOT NULL,
        completed INTEGER DEFAULT 0,
        priority INTEGER DEFAULT 3,
        created_at TEXT,
        updated_at TEXT
      )
    `);
    repo = new TodoRepository(db);
  });

  it('应该创建一个新的 todo', () => {
    const todo = repo.create({ title: '测试 Todo', priority: 1 });
    expect(todo.id).toBeDefined();
    expect(todo.title).toBe('测试 Todo');
    expect(todo.completed).toBe(false);
    expect(todo.priority).toBe(1);
  });

  it('应该找到已创建的 todo', () => {
    const created = repo.create({ title: '查找测试' });
    const found = repo.findById(created.id);
    expect(found).not.toBeNull();
    expect(found!.title).toBe('查找测试');
  });

  it('应该更新 todo 的完成状态', () => {
    const todo = repo.create({ title: '更新测试' });
    const updated = repo.update(todo.id, { completed: true });
    expect(updated.completed).toBe(true);
  });

  it('应该删除 todo', () => {
    const todo = repo.create({ title: '删除测试' });
    const result = repo.delete(todo.id);
    expect(result).toBe(true);
    expect(repo.findById(todo.id)).toBeNull();
  });
});

// === GREEN: 最少代码让测试通过 ===
// src/repositories/todo.ts

import { randomUUID } from 'crypto';
import type Database from 'better-sqlite3';

export interface Todo {
  id: string;
  title: string;
  completed: boolean;
  priority: number;
  created_at: string;
  updated_at: string;
}

export interface CreateTodoInput {
  title: string;
  priority?: number;
}

export interface UpdateTodoInput {
  title?: string;
  completed?: boolean;
  priority?: number;
}

export class TodoRepository {
  constructor(private db: Database.Database) {}

  create(input: CreateTodoInput): Todo {
    const id = randomUUID();
    const now = new Date().toISOString();
    this.db.prepare(`
      INSERT INTO todos (id, title, completed, priority, created_at, updated_at)
      VALUES (?, ?, 0, ?, ?, ?)
    `).run(id, input.title, input.priority ?? 3, now, now);
    return this.findById(id)!;
  }

  findById(id: string): Todo | null {
    const row = this.db.prepare('SELECT * FROM todos WHERE id = ?').get(id) as any;
    if (!row) return null;
    return { ...row, completed: Boolean(row.completed) };
  }

  findAll(): Todo[] {
    return this.db.prepare('SELECT * FROM todos ORDER BY created_at DESC')
      .all()
      .map((row: any) => ({ ...row, completed: Boolean(row.completed) }));
  }

  update(id: string, input: UpdateTodoInput): Todo | null {
    const current = this.findById(id);
    if (!current) return null;
    const now = new Date().toISOString();
    this.db.prepare(`
      UPDATE todos SET
        title = ?, completed = ?, priority = ?, updated_at = ?
      WHERE id = ?
    `).run(
      input.title ?? current.title,
      input.completed !== undefined ? (input.completed ? 1 : 0) : (current.completed ? 1 : 0),
      input.priority ?? current.priority,
      now,
      id
    );
    return this.findById(id);
  }

  delete(id: string): boolean {
    const result = this.db.prepare('DELETE FROM todos WHERE id = ?').run(id);
    return result.changes > 0;
  }
}

6.7 验证与合并

所有任务完成后，AI 输出最终报告：

✅ 6/6 任务全部完成

测试结果:
  ✓ 42 tests passed
  ✓ 0 failed
  ✓ Coverage: 94.3%

变更摘要:
  新增文件: 12
  修改文件: 0
  删除文件: 0
  总代码行数: 487 行

API 端点已部署到: http://localhost:3000

请决定：
  [1] 合并到 main 分支
  [2] 创建 Pull Request
  [3] 保留分支，稍后处理

七、性能数据：Superpowers 真的有效果吗？

根据社区反馈和实际测试数据，使用 Superpowers 的开发团队报告了以下改进：

这些数据来自多个社区团队的经验分享，并非严格控制的实验数据。但从定性角度看，Superpowers 的价值主要体现在：

1. 需求澄清阶段的前移：把「需求不对」的发现时机从「开发后期」移到「开发前期」
2. 测试先行的强制执行：消灭了「因为赶工期跳过测试」的情况
3. 小步验证的成本降低：每个小任务的验证成本 < 5 分钟，发现问题立即修正

八、局限性：Superpowers 不是银弹

说了这么多 Superpowers 的优点，也需要客观谈谈它的局限性。

8.1 学习曲线不容忽视

Superpowers 本身就需要学习成本——你得理解它的工作流程、配置技能文件、知道什么时候该「继续」什么时候该「干预」。对于一个 AI 编程新手来说，这个框架本身的复杂度可能超过收益。

8.2 适合复杂任务，不适合简单查询

对于「帮我写一个 hello world」这种简单任务，Superpowers 的七步流程完全是杀鸡用牛刀。经验法则：任务预计超过 30 分钟，Superpowers 的价值才能体现出来。

8.3 依赖 Claude Code 的 Skills API

Superpowers 的技能机制依赖 Claude Code 的 Skills API。目前这个 API 还没有完全开放给所有 Agent（如 Codex、Copilot Chat 等）。如果你的主力工具不是 Claude Code，Superpowers 的体验会大打折扣。

8.4 技能文件需要持续维护

Superpowers 的技能文件本质上是一组 Prompt。随着模型能力的提升和业务场景的变化，这些 Prompt 需要不断调优。维护成本不容忽视。

8.5 对创意探索类任务帮助有限

Superpowers 的核心是「规范化」，这与创意探索类任务天然存在张力。如果你是在做技术调研、白帽研究、快速原型，Superpowers 的强制性流程反而会成为束缚。

九、与其他框架的对比

9.1 vs. OpenSpec

OpenSpec 是另一个 AI 编程框架，与 Superpowers 走了不同的路线：

• Superpowers：技能封装型——把工程实践固化为可复用的技能模块
• OpenSpec：规范驱动型——把「规范」作为开发的核心，AI 通过理解规范来生成代码

OpenSpec 更适合「规范明确」的场景（如合规性要求高的企业项目），Superpowers 更适合「方法论明确」的场景（如 TDD 驱动的敏捷团队）。

9.2 vs. 内置的 Claude Code 工作流

Claude Code 从 2026 年初开始内置了一套类似的工作流机制（CLAUDE.md、Auto-debug、Code Review 等），但与 Superpowers 相比，这些内置机制的强制性不足——它们只是「建议」，AI 可以忽略。

Superpowers 通过 skills 机制把这些「建议」变成了「强制门禁」，这是两者最核心的差异。

9.3 vs. 传统 CI/CD 流程

Superpowers 本质上是把 CI/CD 中的质量门禁前移到了开发阶段。与传统 CI/CD 相比：

• 传统 CI/CD：代码写完后，由 CI 服务器验证（反馈慢）
• Superpowers：每个任务完成后立即验证（反馈快）

但这并不意味着 Superpowers 可以替代 CI/CD——Superpowers 管的是开发阶段的质量，CI/CD 管的是集成和部署阶段的质量。两者互补。

十、安装与快速上手

10.1 前置条件

• Node.js 18+
• Claude Code 最新版（2026.03+）
• Git 2.5+

10.2 安装步骤

# 1. 克隆 Superpowers 仓库
git clone https://github.com/obra/superpowers.git ~/superpowers

# 2. 安装到 Claude Code 的 skills 目录
mkdir -p ~/.claude/skills
cp -r ~/superpowers/skills/* ~/.claude/skills/

# 3. 验证安装
claude
> /skills list
# 应该看到 brainstorm, write-plan, tdd 等技能

# 4. 开始使用
claude
> 你好，我正在用 Superpowers
> 帮我做一个图片压缩工具

10.3 自定义配置

# ~/.claude/skills/superpowers/config.yaml

superpowers:
  # 每个任务的最大时间限制（分钟）
  task_timeout: 5
  
  # 是否强制 TDD（true = 必须先写测试）
  force_tdd: true
  
  # 小步任务的最大拆分数
  max_plan_items: 10
  
  # worktree 清理策略
  worktree_cleanup: auto  # auto | manual | never
  
  # 审查模式
  review_mode: incremental  # incremental | batch

十一、展望：AI 编程的工程化未来

11.1 从「工具」到「平台」

Superpowers 目前还是一个相对轻量的技能框架，但它的设计思路指向了一个更大的方向：AI 编程的工程化平台。未来，我们可能会看到：

• 技能市场：类似 npm 的 AI 技能交易市场，不同团队分享自己沉淀的最佳实践
• 跨框架兼容：Superpowers 的技能格式成为行业标准，被 Cursor、Copilot 等工具原生支持
• 智能技能推荐：AI 根据当前项目的特点，自动推荐最合适的技能组合

11.2 工程纪律的下一步：形式化验证？

Superpowers 用测试来验证正确性，但测试永远无法证明「没有 bug」。未来的 AI 编程框架可能会引入更强的保证机制，比如：

• 形式化规约语言：用 TLA+ 或 Liquid Haskell 等工具，在代码层面证明正确性
• AI 代码审计：用专门的代码审计 Agent，在每次提交前自动执行安全审计
• 可验证的构建过程：从需求到代码到测试，全链路可追溯、可验证

11.3 人机协作的新范式

Superpowers 最深刻的启示可能不是它本身的技术价值，而是它揭示了一个方向：AI 编程的最佳实践，可能不是让 AI 更强，而是给 AI 加上更好的约束。

人类程序员在几十年的实践中积累了大量的工程纪律，但这些纪律在 AI 时代一度被忽视。Superpowers 把这些纪律重新捡回来，并且用 AI 可以执行的方式编码出来。

这可能才是 AI 编程的未来：不是更聪明的 AI，而是更有纪律的 AI。

总结

Superpowers 是一套解决 AI 编程「质量困境」的技能框架。它通过七门必修课（brainstorm、git worktree、write-plan、TDD、子代理驱动、代码审查、完成合并）把软件工程的最佳实践强制嵌入到 AI 编程的每个环节。

适合使用 Superpowers 的场景：

• 长期项目、复杂功能（预计开发时间 > 30 分钟）
• 需要高测试覆盖率的团队
• 对代码质量有明确要求的项目
• Claude Code 作为主力工具的开发者

不太适合的场景：

• 简单快速的任务（hello world、简单脚本）
• 探索性、实验性编程
• 非 Claude Code 用户（功能受限）

2026 年是 AI 编程的爆发年，也是 AI 编程质量意识觉醒的元年。Superpowers 代表了一种非常重要的趋势：从「让 AI 写得更快」到「让 AI 写得更好」。如果你还在用 AI 批量生成代码但苦于质量不可控，Superpowers 值得一试。

参考来源：

• GitHub: obra/superpowers
• CSDN: 《Vibe Coding - 让AI像资深工程师一样工作：Superpowers深度实战指南》
• 今日头条: 《Superpowers:让AI从代码生成器升级为专业工程师》
• apframework.com: 《From Vibe Coding to Viable Coding》

标签：AI编程|Superpowers|Claude Code|TDD|工程实践|开源框架|AI Agent|2026