编程 Superpowers 深度实战：让 AI 编程助手从"写代码"到"能交付"——2026 年完全指南

2026-05-26 13:35:13 +0800 CST views 27

Superpowers 深度实战：让 AI 编程助手从"写代码"到"能交付"——2026 年完全指南

当你让 Claude Code 帮你"写一个用户登录功能"时，它是直接开写，还是先问你：用 session 还是 JWT？密码怎么存？需不需要验证码？SUPERPSOWERS 做的就是这件事——把工程纪律"固化"进 AI 的工作流。

一、背景介绍：AI 编程的"最后一公里"问题

1.1 现状：AI 能写代码，但交付不了

2026 年，AI 编程工具已经能够熟练地生成代码片段。你打开 Claude Code、Cursor 或 GitHub Copilot，输入"帮我写一个 RESTful API"，几秒钟内就能得到一段看起来不错的代码。

但问题来了：这段代码能直接用于生产环境吗？

答案往往是否定的。原因不在于 AI 的编码能力不足，而在于它缺少工程化的工作流：

需求模糊直接开干 —— 你说了个粗略想法，AI 立刻开始写代码，写到一半发现理解错了
没有设计阶段 —— 直接写代码，缺少架构设计、模块划分、技术选型
无测试驱动 —— 代码能跑就行，没有测试用例，重构时心里没底
方向漂移 —— 写着写着偏离了原始需求，加了不必要的功能或改了设计
无代码审查 —— 提交前没有系统性的检查，潜在 bug 直接进主分支

这不是 AI 的错，而是缺少工程化流程约束。

1.2 为什么需要 Superpowers？

Superpowers 的作者 obra（Will Blankenship）在开发过程中发现：AI 编程助手最大的问题不是"写不出代码"，而是"写出来的代码不可控"。

他的解决方案是：不追求更聪明的模型，而是给 AI 装上工程化流程护栏。

Superpowers 不是一个新的 AI 模型，而是一套可组合的工程化技能库（Skills），它把资深工程师的工作习惯固化成 Markdown 指令文件，让 AI 编程助手在每次任务中自动遵循：

先澄清需求，再动手写代码
先写计划，再执行
先写测试（TDD），再实现功能
独立工作区（Git worktrees），避免污染主分支
两阶段代码审查：先验证是否符合规格，再检查代码质量

1.3 核心数据

GitHub Stars：199,943（截至 2026 年 5 月，日增约 1.7k）
支持平台：Claude Code、Codex、Cursor、OpenCode、Windsurf、通义灵码等 17 款 AI 编程工具
技能数量：20+ 个精心设计的工程化技能
主要语言：Shell（76.2%）、JavaScript（12.3%）、Python（5.7%）、TypeScript（4.3%）
项目地址：https://github.com/obra/superpowers

二、核心概念：Superpowers 的设计哲学

2.1 什么是"Skill"？

在 Superpowers 中，一个 Skill 是一个 Markdown 文件（如 brainstorming.md、writing-plans.md），里面包含：

触发条件 —— 什么时候激活这个技能
工作流程 —— 分步骤的指令，AI 必须严格遵循
输出规范 —— 每个步骤应该产生什么交付物
验证标准 —— 怎么判断这一步做得够不够好

举个例子，brainstorming 技能的流程是：

# Brainstorming Skill

## 触发条件
- 用户提供了一个粗略的功能想法
- 尚未明确技术方案

## 工作流程
1. 列出理解到的需求（用你自己的话复述）
2. 提出至少 3 个需要澄清的问题（技术选型、边界条件、性能指标）
3. 给出 2-3 个备选方案，说明各自优劣
4. 等待用户确认后，将设计方案保存到 `docs/design.md`
5. 只有用户明确说"开始实现"后，才能进入下一阶段

## 禁止行为
- 在未澄清需求前，不要写任何实现代码
- 不要假设用户的技术栈，一定要问

当你在 Claude Code 中输入 /superpowers:brainstorm 我想做一个用户认证功能，AI 就会严格按照这个流程执行，而不是立刻生成代码。

2.2 核心工作流程：从想法到可验证交付

Superpowers 定义了一条强制性的开发流水线：

brainstorm（头脑风暴）
    ↓
writing-plans（编写可执行计划）
    ↓
using-git-worktrees（创建独立工作区）
    ↓
execute-plan / subagent-driven-development（执行计划）
    ↓
test-driven-development（测试驱动开发）
    ↓
verification-before-completion（完成前验证）
    ↓
requesting-code-review（请求代码审查）
    ↓
ship（交付）

每一步都有明确的入口条件和出口标准，AI 不能跳步。

对比：没有 Superpowers vs. 有 Superpowers

阶段	没有 Superpowers	有 Superpowers
需求理解	AI 凭猜测理解，可能理解错	强制提问澄清，输出设计文档让用户确认
任务规划	直接写代码，做到哪算哪	拆分 2-5 分钟可完成的小任务，每个任务有验证步骤
执行环境	直接在当前分支修改	每个任务独立 Git worktree，隔离并行开发
代码质量	能跑就行	强制 TDD（红-绿-重构），先写测试再写实现
完成标准	AI 说"完成了"就提交	必须有验证证据（测试通过、手动验证截图等）才能说"完成"
代码审查	无	两阶段审查：先验证是否符合规格，再检查代码质量

2.3 为什么是"可组合"的？

Superpowers 的精髓在于：每个 Skill 是独立的，但可以组合使用。

比如你在做一个复杂功能时，可能同时激活：

brainstorming —— 澄清需求
writing-plans —— 生成任务清单
test-driven-development —— 每个任务都先写测试
systematic-debugging —— 遇到 bug 时不盲猜，先提出假设再验证
verification-before-completion —— 每个任务完成后，必须有证据才能标记完成

这种组合是动态的，根据任务类型自动激活对应的 Skill，不需要你手动指定。

三、架构分析：Superpowers 的技术实现

3.1 项目结构

superpowers/
├── skills/                      # 核心技能库
│   ├── brainstorming.md         # 需求澄清与设计
│   ├── writing-plans.md        # 生成可执行计划
│   ├── using-git-worktrees.md # Git 工作区隔离
│   ├── executing-plans.md      # 批量执行任务
│   ├── subagent-driven-development.md  # 子代理并行开发
│   ├── test-driven-development.md      # TDD 流程
│   ├── systematic-debugging.md        # 系统化调试
│   ├── verification-before-completion.md  # 完成前验证
│   ├── requesting-code-review.md      # 代码审查
│   └── ...
├── plugins/                     # 各平台插件适配
│   ├── claude-code/            # Claude Code 插件
│   ├── cursor/                 # Cursor 适配
│   └── opencode/               # OpenCode 适配
├── scripts/                     # 安装和配置脚本
└── README.md

3.2 Skill 文件的格式规范

每个 Skill 文件都遵循统一的格式，确保 AI 能准确理解和执行：

# Skill Name

## Metadata
- Author: obra
- Version: 1.0
- Created: 2026-01-15

## When to Activate
（触发条件：明确什么情况下应该激活这个技能）

## Workflow
（分步骤指令，使用明确的动作动词：列出、提问、生成、验证、保存...）

### Step 1: ...
### Step 2: ...

## Output Format
（每个步骤的输出应该是什么格式）

## Validation Criteria
（怎么判断这一步是否完成得好）

## Anti-Patterns
（常见错误，明确告诉 AI 不要做什么）

3.3 与 AI 编程工具的集成机制

Superpowers 支持两种集成方式：

方式一：Claude Code 插件市场（推荐）

Claude Code 有内置的插件系统，安装 Superpowers 只需两条命令：

# 在 Claude Code 会话中执行
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# 验证安装
/help

成功安装后，你会看到一系列新命令：

/superpowers:brainstorm —— 启动需求澄清
/superpowers:write-plan —— 生成实现计划
/superpowers:execute-plan —— 执行计划（批量或逐个任务）
/superpowers:tdd —— 强制 TDD 模式
/superpowers:debug —— 系统化调试模式

方式二：直接克隆仓库（适用于所有工具）

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

# 在 AI 工具配置中指向技能目录
# Claude Code: 在 .claude/settings.json 中添加
{
  "skillsDirectories": ["~/.superpowers/skills"]
}

# Cursor: 在 .cursorrules 中添加
# 将 ~/.superpowers/skills/*.md 的内容作为上下文注入

方式三：npx 一键安装（通用）

# 自动检测当前 AI 工具，安装对应插件
npx superpowers-zh

这是社区维护的中文版 Superpowers（superpowers-zh）提供的功能，支持 17 款 AI 编程工具。

3.4 核心技能详解

Skill 1：Brainstorming（头脑风暴）

目的：在写代码前，先确保需求被准确理解。

工作流程：

复述需求 —— AI 用自己的话复述用户的需求，让用户确认理解是否正确
提出澄清问题 —— 至少 3 个，覆盖：
- 技术选型（用什么框架/库？）
- 边界条件（异常处理、并发安全、数据一致性）
- 性能指标（响应时间、吞吐量、存储容量）
提供备选方案 —— 给出 2-3 个技术方案，说明各自优劣
保存设计文档 —— 将最终确认的设计方案保存到 docs/design.md
等待明确指令 —— 只有用户说"开始实现"后，才能进入下一阶段

示例对话：

用户：帮我做一个用户认证功能

AI（激活 brainstorming）：
好的，在我开始之前，让我确认一下需求：

【需求理解】
你想为你的 Web 应用添加用户认证功能，包括注册、登录、登出。
我理解的对吗？

【澄清问题】
1. 技术选型：你打算用 session-based 还是 JWT？
2. 密码存储：用 bcrypt 还是 Argon2？
3. 需要支持第三方登录（OAuth）吗？
4. 需不需要邮箱验证？
5. 密码重置功能需要吗？

【备选方案】
方案 A：Session-based + Redis（适合单体应用，简单易用）
方案 B：JWT + 短期 access token + 长期 refresh token（适合微服务，无状态）
方案 C：使用 Auth0 / Clerk 等第三方服务（快速上线，但成本高）

你倾向哪个方案？

Skill 2：Writing Plans（编写计划）

目的：将确认后的设计，拆分成 2-5 分钟可完成的小任务。

工作流程：

读取设计文档 —— 从 docs/design.md 读取确认后的设计方案
任务拆分 —— 将功能拆分成独立、可验证的小任务
每个任务包含：
- 任务描述（一句话说明要做什么）
- 精确文件路径（哪个文件的哪一部分需要修改）
- 完整代码示例（不只是描述，直接给出参考实现）
- 验证步骤（怎么证明这个任务完成了）
保存计划 —— 输出到 plans/implement-{feature}.md

任务拆分示例：

# Implementation Plan: User Authentication

## Task 1: Set up database schema (estimated: 3 min)
**File**: `prisma/schema.prisma`
**Action**: Add User model with fields: id, email, passwordHash, createdAt
**Verification**: `npx prisma db push` runs without error

## Task 2: Implement password hashing utility (estimated: 4 min)
**File**: `src/lib/auth/password.ts`
**Code**:
```typescript
import bcrypt from 'bcrypt';
export async function hashPassword(password: string): Promise<string> {
  return bcrypt.hash(password, 10);
}

Verification: Unit test passes: npm test -- password.test.ts

Task 3: Create registration API endpoint (estimated: 5 min)

...


#### Skill 3：Using Git Worktrees（Git 工作区隔离）

**目的**：每个任务在独立分支和工作区中开发，避免相互污染。

**工作流程**：

1. **基于主分支创建 worktree**：
   ```bash
   git worktree add ../worktrees/task-1 -b feature/auth-task-1

在 worktree 中工作 —— 切换到 worktree 目录，独立开发
完成任务后合并 —— 测试通过 → 合并到主分支 → 删除 worktree
并行开发 —— 多个 task 可以在不同 worktree 中并行（适合用子代理）

为什么要用 worktree？

传统的 git checkout -b 切换分支，工作区文件会跟着变，IDE 索引需要重建。而 git worktree 让多个分支同时存在于不同目录，互不干扰：

project/
├── main/          # 主工作区（main 分支）
└── worktrees/
    ├── task-1/    # feature/auth-task-1 分支
    ├── task-2/    # feature/auth-task-2 分支
    └── task-3/    # feature/auth-task-3 分支

Skill 4：Test-Driven Development（测试驱动开发）

目的：强制遵循"红-绿-重构"循环，确保每一行代码都有测试覆盖。

工作流程：

红 —— 先写一个失败的测试用例（编译或运行失败）
绿 —— 写最少的代码让测试通过（不追求完美，只求通过）
重构 —— 在测试通过的前提下，优化代码结构
重复 —— 为下一个功能写测试，继续循环

禁止行为：

不要先写实现代码，再补测试
不要写"永远通过"的假测试
不要在一次提交中混合"实现"和"重构"

代码示例：

// Step 1: 红 —— 先写测试（此时还没有 hashPassword 函数）
import { describe, it, expect } from 'vitest';
import { hashPassword, verifyPassword } from './password';

describe('Password Hashing', () => {
  it('should hash a password', async () => {
    const hash = await hashPassword('mySecret123');
    expect(hash).not.toBe('mySecret123'); // 哈希后不应是原密码
    expect(hash).toMatch(/^\$2b\$10\$/);   // bcrypt 哈希的特征前缀
  });

  it('should verify a password against hash', async () => {
    const hash = await hashPassword('mySecret123');
    const result = await verifyPassword('mySecret123', hash);
    expect(result).toBe(true);
  });
});

// Step 2: 绿 —— 写最少代码让测试通过
import bcrypt from 'bcrypt';

export async function hashPassword(password: string): Promise<string> {
  return bcrypt.hash(password, 10);
}

export async function verifyPassword(password: string, hash: string): Promise<boolean> {
  return bcrypt.compare(password, hash);
}

// Step 3: 重构 —— 添加输入校验、错误处理的逻辑

Skill 5：Systematic Debugging（系统化调试）

目的：遇到 bug 时不盲猜，遵循科学方法：提出假设 → 设计实验 → 验证假设。

工作流程：

复现 bug —— 找到稳定的复现路径
收集证据 —— 看日志、加断点、检查输入输出
提出假设 —— 列出至少 3 个可能的原因
设计验证实验 —— 为每个假设设计一个"能证伪"的测试
执行实验 —— 逐个排除，找到根因
修复并验证 —— 修复后，确认原 bug 消失，且没有引入新 bug

反模式（AI 容易犯的错）：

// ❌ 错误：猜修复（AI 最喜欢的"随机试"）
// 用户报告：偶尔登录失败
// AI 猜测：可能是 race condition，加个 Math.random() 重试...
// 结果：问题没解决，代码更乱了

// ✅ 正确：系统化调试
// 1. 复现：在什么条件下失败？频率多少？
// 2. 看日志：失败的请求有什么共同特征？
// 3. 假设 A：数据库连接池耗尽 → 实验：检查 pool 配置
// 4. 假设 B：JWT 签名验证失败 → 实验：打印 secret 是否一致
// 5. 假设 C：某个边缘输入导致异常 → 实验：fuzzing test

四、代码实战：用 Superpowers 开发一个完整功能

4.1 场景设定

我们要为程序员茄子网站添加一个文章阅读量统计功能：

每篇文章有独立的阅读计数
防止同一用户短时间内的重复计数（去重）
提供 API 接口供前端查询阅读量
数据存储在 Redis（高性能计数器）

4.2 完整实战流程

Step 1：Brainstorming（需求澄清）

在 Claude Code 中：

/superpowers:brainstorm 我想给文章添加阅读量统计功能，需要防刷，用 Redis

AI 的回应（严格按照 brainstorming 技能）：

好的，让我先澄清需求细节。

【需求理解】

功能：统计每篇文章的阅读量
防刷机制：同一用户短时间内重复访问不重复计数
存储：Redis
我理解的对吗？还有什么需要补充的？

【澄清问题】

用户识别方式：
- 方案 A：基于 Cookie（最简单，但用户可以清除 cookie 刷量）
- 方案 B：基于 IP + User-Agent 哈希（无需登录，但有 IPv6 旋转的问题）
- 方案 C：登录用户用 user_id，匿名用户用 IP（混合方案，推荐）
你倾向哪个？
去重时间窗口：
- 15 分钟？1 小时？24 小时？
- 也就是：同一用户在这个时间窗口内多次访问，只计数一次
Redis 数据结构：
- 方案 A：用 String + INCR（简单计数器）
```
Key: article:{articleId}:views
Value: 数字
```
- 方案 B：用 Set 存储访问过的用户 ID/IP（能去重，但占内存）
```
Key: article:{articleId}:viewers
Value: Set<userId 或 IP>
```
- 方案 C：用 HyperLogLog（占用内存极小，但有 0.81% 误差）
你更看重精确性还是内存占用？
API 接口设计：
- POST /api/articles/:id/view —— 记录一次阅读
- GET /api/articles/:id/views —— 查询阅读量
- 需要鉴权吗？还是公开接口？
性能要求：
- 预期 QPS 多少？
- 需不需要异步写入（先返回，再更新 Redis）？

【我的建议】

用户识别：方案 C（混合）
去重窗口：1 小时（平衡体验和防刷）
Redis 结构：方案 B（Set）+ 定期同步到数据库持久化
接口：公开，限制频率（rate limiting）

你怎么看？确认后我生成实现计划。

用户回复：

用方案 C（混合识别），去重窗口 1 小时，Redis 用 Set 存储，
接口公开但加频率限制（每 IP 每秒 5 次请求），
QPS 预计 100-500，可以异步写入。
开始写计划吧。

Step 2：Writing Plans（生成实现计划）

/superpowers:write-plan

AI 生成的计划（plans/implement-view-counter.md）：

# Implementation Plan: Article View Counter

## 前提条件
- Redis 已配置并可连接
- 文章数据存储在 MySQL（通过 Prisma ORM）

## Task 1: Redis 连接配置 (3 min)
**File**: `src/lib/redis.ts`
**Action**: 创建 Redis 客户端单例，处理连接错误
**代码**:
```typescript
import { createClient } from 'redis';

const client = createClient({ url: process.env.REDIS_URL });

client.on('error', (err) => console.error('Redis Client Error', err));

export async function getRedisClient() {
  if (!client.isOpen) await client.connect();
  return client;
}

验证: npm run test:redis 连接成功

Task 2: 视图计数核心逻辑 (5 min)

File: src/lib/viewCounter.ts
Action: 实现 recordView(articleId, userId?) 函数
逻辑:

生成用户标识：登录用户用 userId，匿名用户用 ip:userAgent 哈希
Redis Key: article:{articleId}:viewers:{date}（按天分桶，自动过期）
使用 SADD 添加用户标识到 Set
如果 SADD 返回 1（首次访问），则 INCR article:{articleId}:views
设置 Key 过期时间 48 小时
代码: [完整代码省略，实际计划中会包含]
验证: Unit test: 同一用户 1 小时内访问 10 次，计数只增加 1

Task 3: API 路由 (4 min)

File: src/routes/articles.ts
Action: 添加两个路由

POST /api/articles/:id/view —— 调用 recordView，返回 200
GET /api/articles/:id/views —— 返回 { views: number }
中间件:
Rate limit: express-rate-limit（每 IP 每秒 5 次）
异步处理：fire-and-forget，不阻塞响应
验证: curl -X POST localhost:3000/api/articles/123/view 返回 200

Task 4: 定时同步到数据库 (6 min)

File: src/jobs/syncViews.ts
Action: 每 10 分钟执行一次
逻辑:

扫描所有 article:*:views 键
更新 MySQL 对应文章的 views 字段
可选：写入历史趋势表 article_views_daily
验证: 手动执行 npm run job:sync-views，数据库 views 字段更新

Task 5: 前端集成 (4 min)

File: src/components/Article.tsx
Action: 组件挂载时发送 POST 请求记录阅读
细节:

使用 useEffect，只在首次渲染时发送
错误处理：失败不影响用户阅读
验证: 打开文章页面，Network 面板看到 POST 请求

风险与注意事项

Redis 内存占用：Set 可能很大，需要监控
如果 Redis 宕机：降级为直接写 MySQL（牺牲去重精度）
爬虫/ bot：考虑用 Cloudflare Bot Management 或添加 CAPTCHA


#### Step 3：Execute Plan（执行计划）

使用 `executing-plans` 或 `subagent-driven-development` 技能：

```bash
/superpowers:execute-plan plans/implement-view-counter.md

AI 的行为：

逐个任务执行，每完成一个任务：
- 运行对应的验证步骤
- 如果验证失败，自动进入 systematic-debugging 模式
- 如果验证通过，git commit（消息格式：feat(view-counter): complete task N - ...）

可选：子代理并行开发

如果任务之间无依赖，AI 可以启动多个子代理并行执行：

# 子代理 1：在 worktree-1 中执行 Task 1 + Task 2
# 子代理 2：在 worktree-2 中执行 Task 3
# 子代理 3：在 worktree-3 中执行 Task 4
# 主代理：等待所有子代理完成后，合并代码，执行集成测试

Step 4：Verification Before Completion（完成前验证）

在每个任务标记为"完成"之前，AI 必须提供验证证据：

## Task 2 验证证据

✅ Unit Test 通过：

npm test -- viewCounter.test.ts

12 tests passed, 0 failed


✅ 手动验证：
- 首次访问：Redis `GET article:123:views` → "1"
- 再次访问（同一用户）：值仍为 "1"（未重复计数）
- 不同用户访问：值增加到 "2"

✅ 性能测试：
- `ab -n 1000 -c 10 http://localhost:3000/api/articles/123/view`
- 平均响应时间：12ms（满足 < 50ms 要求）

Step 5：Requesting Code Review（代码审查）

所有任务完成后，AI 自动进行两阶段审查：

阶段一：规格符合性审查

实现的功能是否完全覆盖设计文档中的需求？
有没有遗漏的边界条件？
错误处理是否完备？

阶段二：代码质量审查

命名是否清晰？
有没有重复代码可以抽取？
性能有没有明显问题（N+1 查询、大 O 复杂度）？
测试覆盖率是否足够？

审查报告示例：

# Code Review: Article View Counter

## 规格符合性
✅ 用户识别：混合方案已实现（登录用户用 ID，匿名用 IP:UA 哈希）
✅ 去重窗口：1 小时（通过 Redis Key 按天分桶 + SET 去重实现）
✅ 频率限制：已添加，每 IP 每秒 5 次
⚠️ 缺少：异步写入的降级逻辑（Redis 宕机时写 MySQL）

## 代码质量
✅ 命名清晰：函数名 `recordView`、`getViewCount` 直观
✅ 测试覆盖：12 个单元测试，覆盖核心逻辑
⚠️ 建议：`viewCounter.ts` 中 Redis 操作可以抽取为独立类，便于 mock 测试
⚠️ 性能：同步写入 Redis 可能阻塞（建议改为 fire-and-forget + 队列）

## 需要修改后才能合并
1. 添加 Redis 宕机降级逻辑
2. 将 Redis 操作抽取为可注入的接口（便于测试）

五、性能优化与最佳实践

5.1 性能优化技巧

优化点 1：Redis 操作异步化

问题：每次记录阅读都要等待 Redis 写入，增加响应时间。

解决方案：Fire-and-forget + 队列

// ❌ 同步写入（阻塞响应）
export async function recordView(articleId: string, userKey: string) {
  const redis = await getRedisClient();
  const added = await redis.sAdd(`article:${articleId}:viewers`, userKey);
  if (added) await redis.incr(`article:${articleId}:views`);
  // 上面两个 await 会阻塞响应！
}

// ✅ 异步写入（fire-and-forget）
export async function recordView(articleId: string, userKey: string) {
  // 先返回成功，再异步写入 Redis
  setImmediate(async () => {
    try {
      const redis = await getRedisClient();
      const added = await redis.sAdd(`article:${articleId}:viewers`, userKey);
      if (added) await redis.incr(`article:${articleId}:views`);
    } catch (err) {
      console.error('Failed to record view', err);
      // 可选：写入失败队列，稍后重试
    }
  });
  return { success: true }; // 立即返回
}

优化点 2：Redis 内存优化

问题：每个文章的 viewer Set 会越来越大，占用大量内存。

解决方案：HyperLogLog + 定期清理

// 方案 A：如果可以接受 0.81% 误差，用 HyperLogLog（每个 key 只占用 12KB）
await redis.pfAdd(`article:${articleId}:viewers`, userKey);
const uniqueViews = await redis.pfCount(`article:${articleId}:viewers`);

// 方案 B：保留 Set，但定期清理过期数据
// 每天凌晨 2 点删除 7 天前的 viewer Set
await redis.expire(`article:${articleId}:viewers:${oldDate}`, 0);

优化点 3：数据库同步优化

问题：每 10 分钟全量扫描 Redis keys，影响性能。

解决方案：增量同步 + 消息队列

// 每次 INCR 后，发布一个消息到 Redis Stream
await redis.xAdd('view-sync-queue', '*', {
  articleId,
  timestamp: Date.now().toString(),
});

// 独立的 worker 消费 Stream，批量更新数据库
async function syncWorker() {
  while (true) {
    const entries = await redis.xRead('view-sync-queue', '$', { COUNT: 100 });
    // 批量更新数据库：INSERT ... ON DUPLICATE KEY UPDATE
    await db.articleViews.bulkUpsert(entries);
  }
}

5.2 常见陷阱与规避方法

陷阱 1：AI 跳过 Planning 直接写代码

症状：你说"帮我做 X"，AI 立刻生成大段代码。

原因：没有激活 writing-plans 技能。

解决：明确说"先写计划，再实现"或使用 /superpowers:write-plan。

陷阱 2：TDD 变成"写完后补测试"

症状：AI 先写实现，然后说"现在写测试"。

原因：没有严格遵循 TDD 流程，或者测试用例太简单（永远通过）。

解决：在 test-driven-development 技能中，明确要求：

第一次运行测试必须失败（红）
提交的 commit 必须包含测试和实现的完整变化

陷阱 3：任务拆分太粗，AI 一次改太多文件

症状：AI 说"我完成了"，但改了 15 个文件，无法 review。

原因：计划中的任务粒度太大（"实现整个认证系统"）。

解决：任务拆分时遵循"2-5 分钟原则"，每个任务只改 1-3 个文件。

陷阱 4：验证步骤不明确，AI 说"完成了"但没验证

症状：AI 说任务完成，但你手动测试发现根本跑不通。

原因：计划中没有明确的验证步骤，或者验证步骤太模糊（"测试通过"）。

解决：验证步骤必须可操作、可自动化：

✅ 好的验证：npm test -- password.test.ts 通过，且 curl -X POST localhost:3000/api/login 返回 200
❌ 差的验证：功能正常工作

六、与其他方案的对比

6.1 Superpowers vs. 纯 Prompt 工程

维度	纯 Prompt	Superpowers
流程约束	靠 Prompt 文字描述，AI 容易忽略	固化成 Skill 文件，强制执行
可复用性	每次对话都要重新说明流程	一次安装，所有项目通用
团队协作	每个人写的 Prompt 不一致	统一技能库，团队共享工程规范
适用场景	简单任务、一次性脚本	复杂功能、生产级代码

6.2 Superpowers vs. Cursor / GitHub Copilot 内置流程

维度	Cursor / Copilot	Superpowers
流程定制	固定的"接受/拒绝"模式	完全可定制的技能库
多步骤任务	单轮对话，容易漂移	强制多阶段流水线
测试驱动	无内置支持	专门的 TDD 技能
Git 集成	基本的 diff/commit	Worktree 隔离、两阶段审查

6.3 Superpowers vs. 类似项目（OpenSpec、Aider）

维度	Superpowers	OpenSpec	Aider
定位	工程化技能库	规格驱动开发	命令行 AI 编程工具
学习曲线	中等（需要理解每个 Skill）	低（自动生成规格）	低（直接对话）
适用场景	复杂、多文件重构	新功能开发	快速原型、脚本
平台支持	17+ 款工具	主要为 Claude Code	主要为终端

七、总结与展望

7.1 核心收获

AI 编程助手的问题不是"能力不足"，而是"缺少工程纪律"
- Superpowers 不追求更聪明的模型，而是把资深工程师的工作习惯固化成可复用的技能
结构化工作流 > 聪明的 Prompt
- 明确的阶段划分（brainstorm → plan → implement → verify → review）
- 每个阶段有入口/出口标准，AI 不能跳步
可验证的交付 > "看起来完成了"
- 每个任务必须有明确的验证证据（测试通过、手动验证截图）
- AI 说"完成了"不算数，必须通过验证才能标记完成
隔离开发 > 直接在主线修改
- Git worktrees 让每个任务在独立工作区开发
- 支持子代理并行开发，大幅提升复杂任务效率

7.2 Superpowers 的适用场景

强烈推荐：

生产级功能开发（用户认证、支付集成、API 设计）
复杂重构（跨多个文件的架构调整）
团队协作（统一工程规范，code review 更容易）

不推荐：

一次性脚本、简单 CRUD（用 Cursor 直接生成更快）
你对 AI 编程工具还不熟悉（先掌握基础用法）

7.3 未来展望

更多平台支持
- 目前支持 17 款工具，未来可能覆盖所有主流 AI 编程助手
技能市场
- 类似 VS Code 插件市场，开发者可以发布和分享自己的 Skill
- 针对特定领域（前端、后端、DevOps、数据科学）的专用技能包
与 MCP（Model Context Protocol）集成
- Skill 可以调用外部工具（数据库、API、云服务）
- 实现更复杂的自动化流程（如：自动部署、自动生成文档）
多代理协作
- 一个 Superpowers 实例协调多个 AI 代理（每个代理负责一个子任务）
- 类似 MetaGPT，但更轻量、更实用

7.4 行动建议

如果你还没用过 Superpowers：

安装试试 —— 15 分钟搞定（见第三节安装指南）
从一个小功能开始 —— 比如给网站加一个联系表单
对比体验 —— 用 Superpowers 做一次，不用做一次，感受差异
定制自己的 Skill —— 把你的工程经验写成 Markdown，让它成为 AI 的"肌肉记忆"

附录：完整 Skill 列表（v1.0）

Skill 名称	作用	适用场景
`brainstorming`	需求澄清与设计	所有新功能开发
`writing-plans`	生成可执行计划	复杂任务（> 3 个文件）
`using-git-worktrees`	Git 工作区隔离	并行开发多个任务
`executing-plans`	批量执行任务	按计划逐个完成任务
`subagent-driven-development`	子代理并行开发	任务之间无依赖
`test-driven-development`	TDD 流程	所有功能开发
`systematic-debugging`	系统化调试	遇到 bug 时
`verification-before-completion`	完成前验证	每个任务完成后
`requesting-code-review`	代码审查	所有任务完成后
`collaborative-planning`	团队协作规划	多人协作项目
`refactoring-safely`	安全重构	大规模代码重构
`adding-logging`	添加日志	调试和监控
`writing-documentation`	编写文档	功能完成后
`optimizing-performance`	性能优化	性能瓶颈分析
`security-review`	安全审查	涉及用户数据的功能
`api-design`	API 设计	设计 RESTful / GraphQL API
`database-migration`	数据库迁移	Schema 变更
`deployment-pipeline`	部署流水线	CI/CD 配置

参考资源

GitHub 仓库：https://github.com/obra/superpowers
中文版（superpowers-zh）：https://github.com/yourusername/superpowers-zh
Claude Code 官方文档：https://docs.anthropic.com/claude-code
安装视频教程：[YouTube 链接]

作者：程序员茄子 | 发布于 2026-05-26 | 字数：约 8500 字

如果你觉得这篇文章对你有帮助，欢迎在 GitHub 上给 Superpowers 点个 Star ⭐

编程 Superpowers 深度实战：让 AI 编程助手从"写代码"到"能交付"——2026 年完全指南

Superpowers 深度实战：让 AI 编程助手从"写代码"到"能交付"——2026 年完全指南

一、背景介绍：AI 编程的"最后一公里"问题

1.1 现状：AI 能写代码，但交付不了

1.2 为什么需要 Superpowers？

1.3 核心数据

二、核心概念：Superpowers 的设计哲学

2.1 什么是"Skill"？

2.2 核心工作流程：从想法到可验证交付

对比：没有 Superpowers vs. 有 Superpowers

2.3 为什么是"可组合"的？

三、架构分析：Superpowers 的技术实现

3.1 项目结构

3.2 Skill 文件的格式规范

3.3 与 AI 编程工具的集成机制

方式一：Claude Code 插件市场（推荐）

方式二：直接克隆仓库（适用于所有工具）

方式三：npx 一键安装（通用）

3.4 核心技能详解

Skill 1：Brainstorming（头脑风暴）

Skill 2：Writing Plans（编写计划）

Task 3: Create registration API endpoint (estimated: 5 min)

Skill 4：Test-Driven Development（测试驱动开发）

Skill 5：Systematic Debugging（系统化调试）

四、代码实战：用 Superpowers 开发一个完整功能

4.1 场景设定

4.2 完整实战流程

Step 1：Brainstorming（需求澄清）

Step 2：Writing Plans（生成实现计划）

Task 2: 视图计数核心逻辑 (5 min)

Task 3: API 路由 (4 min)

Task 4: 定时同步到数据库 (6 min)

Task 5: 前端集成 (4 min)

风险与注意事项

Step 4：Verification Before Completion（完成前验证）

Step 5：Requesting Code Review（代码审查）

五、性能优化与最佳实践

5.1 性能优化技巧

优化点 1：Redis 操作异步化

优化点 2：Redis 内存优化

优化点 3：数据库同步优化

5.2 常见陷阱与规避方法

陷阱 1：AI 跳过 Planning 直接写代码

陷阱 2：TDD 变成"写完后补测试"

陷阱 3：任务拆分太粗，AI 一次改太多文件

陷阱 4：验证步骤不明确，AI 说"完成了"但没验证

六、与其他方案的对比

6.1 Superpowers vs. 纯 Prompt 工程

6.2 Superpowers vs. Cursor / GitHub Copilot 内置流程

6.3 Superpowers vs. 类似项目（OpenSpec、Aider）

七、总结与展望

7.1 核心收获

7.2 Superpowers 的适用场景

7.3 未来展望

7.4 行动建议

附录：完整 Skill 列表（v1.0）

推荐文章