Superpowers 深度实战：当 AI 编程助手学会「工程纪律」——从 TDD 闭环到子 Agent 驱动开发的完全指南（2026）

前言：AI 写代码，为什么还是一团糟？

2026 年的今天，你让 Claude Code 写一个登录功能，它 10 秒给你吐出 300 行代码。你让它修一个 Bug，它顺手把三个不相关的文件格式全改了。你问它"测试跑过了吗？"，它说"应该没问题"。你一看，测试覆盖率 3%。

这不是 AI 能力不够。这是没有人告诉 AI 应该在什么时候、怎么做。

就像一个新入职的应届生：聪明、有能力、热情，但没有工作流程，想到哪做到哪。你给他布置任务，他先写代码、后来才想起看需求，代码写完了才发现设计有问题，测试永远是最后补的。

程序员茄子在实际项目中深度使用了 Superpowers（obra/superpowers），这是 GitHub 上 Star 数突破 22.3 万、日均增长接近 1000 颗星的 AI 编程方法论框架，由 Jesse Vincent（GitHub 前 CTO、GitHub CEO、DBI-Services 创始人）历时数年打造。本文将从架构原理、核心技能解析、代码级实现细节、与传统开发模式对比、以及生产落地实战五个维度，彻底拆解这个正在重塑 AI 编程工作流的系统性框架。

一、背景：为什么 AI 编程需要一个「纪律手册」？

1.1 从「提示词工程」到「代理技能框架」

过去两年，我们对 AI 编程的使用模式基本是：

你: "帮我写个排序函数"
AI:  → 吐出一段代码
你: "这段不对，应该改成..."
AI:  → 改掉
你: "加个边界情况处理"
AI:  → 加上

这个模式叫提示词工程（Prompt Engineering）——把 AI 当成一个高级的代码补全工具。它有效果，但不可扩展。当你有一个 5 万行代码的生产系统，让 AI 去"帮我加个功能"，它往往：

• 不理解上下文：不知道现有代码的架构设计，不知道为什么要用某个模式
• 不理解工程纪律：上来就写实现，不先分析需求；不写测试；改完就跑
• 不理解验收标准：给什么就做什么，做完就算，不自测，不验证

Superpowers 的出现，彻底改变了这个局面。它认为 AI 编程助手不应该是一个"被动的代码生成器"，而应该是一个主动遵循工程纪律的代理（Agent）。这个区别是关键所在——

被动模式：你给指令 → AI 执行 → 结果交付
主动纪律模式：你给目标 → AI 主动触发工程流程 → 需求澄清 → 设计确认 → 计划制定 → 分步执行 → 持续验证 → 代码审查 → 交付

这正是 Superpowers 设计的核心理念：把人类软件工程几十年积累的最佳实践，固化成 AI 可执行的技能（Skills），让 AI 在任何任务中自动遵循这些纪律。

1.2 创始人与项目背景

Superpowers 由 Jesse Vincent 创建。Jesse 不是一个普通的开源作者：

• GitHub 前 CTO：深度参与 GitHub 早期架构
• DBI-Services 创始人：其公司是全球最大的 GitHub 官方服务合作伙伴之一
• 30 年软件开发老兵：经历了从 Perl 到 Ruby 到 Go 的技术变迁，深知工程纪律的价值

2025 年 10 月，Superpowers 以 MIT 协议正式开源，在短短 5 个月内冲到 GitHub Star 榜前列，到 2026 年中已突破 22.3 万 Star，日均增长接近 1000 颗，成为 2026 年 AI 编程工具链中增长最快的项目之一。

支持的 AI 编程工具：Claude Code、Codex CLI、Codex App、Factory Droid、 Gemini CLI、OpenCode、Cursor、GitHub Copilot CLI——基本上覆盖了所有主流 AI 编程代理。

1.3 核心哲学：四个工程原则

Superpowers 不是一套随意的规则，它的每个设计决策都围绕以下四个核心原则展开：

1. TDD（测试驱动开发）——Write tests first, always

没有测试的代码就是没有验收标准的代码。Superpowers 强制 AI 在写任何实现代码之前，先写出会失败的测试。这不仅是方法论，更是一种认知约束——迫使开发者（和 AI）先想清楚"这段代码要做什么，才算正确"。

2. YAGNI——You Aren't Gonna Need It

你不需要它。不要为未来可能的需求提前设计。Superpowers 的规划阶段（writing-plans）明确要求每个任务都是"2-5 分钟可完成"的最小粒度，每一步都要有具体的验证命令和预期结果。不允许出现"TODO"、"以后再优化"这样的模糊地带。

3. DRY——Don't Repeat Yourself

每个设计决策只出现一次。文件结构要清晰分离，代码逻辑不要重复。Superpowers 的 writing-plans 技能要求 AI 在规划阶段就画出文件结构图（File Structure），明确每个文件的职责边界。

4. 系统化优于临时化——Systematic over ad-hoc

不要靠猜测，不要靠感觉。遇到 Bug，用 4 阶段根因分析法；完成任务，用验证-检查清单流程。Superpowers 为 AI 内置了一整套可重复执行的"套路"，让 AI 的行为变得可预测、可审计。

二、架构解析：Superpowers 是如何工作的？

2.1 技能触发机制（Skills Trigger System）

Superpowers 的核心不是一个大一统的提示词，而是一组可组合的技能（Skills）。每个 Skill 是一个独立的 .md 文件，包含：

• name：技能名称（如 test-driven-development）
• description：触发条件描述（AI 用这个判断何时激活该技能）
• 工作流程：具体的执行步骤
• 反模式参考：常见的错误做法

当 AI 编程代理（以 Claude Code 为例）收到用户指令时，它的内部流程是：

用户指令 → Agent 扫描所有可用 Skills → 
匹配触发条件的 Skills 被激活 → 
按技能要求执行工作流 → 
完成后返回结果

关键在于：这些技能是强制的，不是建议的。传统意义上的 AI 编程助手的"建议"可以被忽略，但 Superpowers 的技能一旦被触发，AI 必须遵循其流程执行，否则系统会报错。

这是 Superpowers 和普通提示词工程最本质的区别——它不是告诉 AI "你可以这样"，而是告诉 AI "你必须这样做"。

2.2 技能目录与分类

Superpowers 官方内置了以下技能，覆盖了完整的开发周期：

2.3 工作流程全貌：从需求到交付

Superpowers 的完整工作流程如下：

阶段 1: Brainstorming（需求澄清）
  用户: "帮我做一个用户权限系统"
           ↓
  AI（触发 brainstorming 技能）:
    - 通过 Socratic 追问明确需求细节
    - 探索替代方案
    - 分节展示设计方案
    - 用户逐节确认
           ↓
  输出: docs/superpowers/designs/YYYY-MM-DD-<feature-name>.md

阶段 2: Git Worktrees（隔离工作区）
  AI（触发 using-git-worktrees 技能）:
    - 用 git worktree 创建隔离分支
    - 运行项目初始化
    - 验证干净的测试基线
           ↓
  输出: 干净的独立开发环境

阶段 3: Writing Plans（制定实施计划）
  AI（触发 writing-plans 技能）:
    - 画出文件结构图
    - 拆解为 2-5 分钟粒度的任务
    - 每个任务包含：文件路径、测试代码、验证命令
           ↓
  输出: docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md

阶段 4: 子 Agent 驱动开发（执行计划）
  AI（触发 subagent-driven-development 技能）:
    - 每个任务派发一个子 Agent
    - 子 Agent 执行 RED-GREEN-REFACTOR 循环
    - 父 Agent 执行两阶段审查（规格合规 + 代码质量）
           ↓
  输出: 逐步推进的代码变更

阶段 5: Code Review（代码审查）
  AI（触发 requesting-code-review 技能）:
    - 获取 diff 范围
    - 派发子 Agent 执行审查
    - 按严重性分类问题
    - 关键问题阻塞，重要问题记录，次要问题可选处理

阶段 6: Finishing（完成分支）
  AI（触发 finishing-a-development-branch 技能）:
    - 验证所有测试通过
    - 提供合并/PR/保留/丢弃选项
    - 清理工作区

这个流程看起来复杂，但实际上 AI 可以在无人干预的情况下自主运行数小时。这正是 Superpowers 的魅力所在——把工程纪律自动化。

三、核心技能深度解析

3.1 brainstorming：Socratic 需求追问

brainstorming 技能是整个流程的起点。它的设计哲学来自苏格拉底式问答——不直接给出答案，而是通过追问让需求自己变得清晰。

传统 AI 编程：

你: "做个用户登录"
AI: → 直接写代码

Superpowers AI：

你: "做个用户登录"
AI: "我在使用 brainstorming 技能。在开始之前，我需要澄清几个关键问题："
1. 用户用邮箱还是手机号登录？是否两者都支持？
2. 需要"记住我"功能吗？Token 有效期多长？
3. 密码强度要求是什么？需要特殊字符吗？
4. 登录失败几次后触发锁定？锁定多长时间？
5. 是否需要 MFA（多因素认证）？
6. 用户 Session 如何管理？服务端还是 JWT？
7. 错误信息是否区分"用户不存在"和"密码错误"？（安全考量）
8. 登录日志需要记录哪些信息？

这个追问模式逼迫 AI 和用户在写代码之前就把需求想清楚。每一个问题背后都是一个工程决策——Session vs JWT、MFA 的引入、错误信息的模糊化处理——这些问题如果在代码写完后才发现，改动成本往往是 10 倍以上。

用户确认后，AI 会将设计分节展示：

## 设计文档：用户认证模块

### 1. 核心实体
...

### 2. API 接口
...

### 3. 安全策略
...

### 4. 存储设计
...

[请确认每个章节，回复"确认"继续]

用户逐节确认后，设计文档才最终保存。这种用户参与式设计是 Superpowers 区别于纯自动化的关键——它把 AI 的能力锁在工程纪律的框架里，同时保留了人类决策权。

3.2 using-git-worktrees：隔离即纪律

using-git-worktrees 解决了一个让无数开发者头疼的问题：AI 在主分支上乱改，导致污染和难以回滚。

Git Worktree 是 Git 的一个少为人知但极其强大的功能——它允许你在同一个仓库的多个目录中同时 checkout 不同的分支，彼此完全隔离。

Superpowers 的 AI 在设计被批准后，会自动执行：

# 1. 基于主分支创建新的 worktree（隔离工作区）
git worktree add ../feature-auth-jwt -b feature/auth-jwt

# 2. 进入工作区
cd ../feature-auth-jwt

# 3. 验证干净的测试基线
npm test   # 所有测试应该通过
git status # 应该是干净的
echo $?    # 0

# 4. 如果测试不干净，先修复基线再继续

这样做的好处是：

• 主分支绝对干净：即使 AI 把隔离分支改得一塌糊涂，主分支不受影响
• 可以并行开发：同时在多个 worktree 中处理不同特性，彼此独立
• 回滚成本为零：直接删除 worktree 目录即可，不影响任何其他分支
• 适合子 Agent 并行：可以同时派发多个子 Agent 到不同的 worktree

这是一个程序员茄子在实际项目中使用频率最高的特性——过去让 AI 重构核心模块时最怕的是"AI 改错了主分支"，现在完全不用担心了。

3.3 writing-plans：把任务剁碎到 2-5 分钟

writing-plans 是 Superpowers 中最体现工程素养的技能。它的核心要求是：每个任务步骤，必须在 2-5 分钟内完成，每个步骤都要有具体的代码、文件路径和验证命令。

一个真实的计划文档结构如下：

# JWT 认证模块实施计划

> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development

**Goal:** 实现基于 JWT 的用户认证模块

**Architecture:** 
使用 HS256 对称签名算法，Token 有效期 24 小时，
Refresh Token 有效期 7 天，存储在 HttpOnly Cookie 中。

**Tech Stack:** Node.js + jsonwebtoken + bcrypt

---

### Task 1: 用户密码哈希存储

**Files:**
- Create: src/models/user.ts
- Modify: src/db/schema.sql
- Test: tests/unit/models/user.test.ts

- [ ] **Step 1: 写失败的测试**

```typescript
// tests/unit/models/user.test.ts
import { hashPassword, verifyPassword } from '@/models/user';

describe('Password Hashing', () => {
  it('should hash password with bcrypt', async () => {
    const password = 'SecureP@ssw0rd!';
    const hash = await hashPassword(password);
    expect(hash).not.toBe(password);
    expect(hash.length).toBe(60); // bcrypt hash length
  });

  it('should verify correct password', async () => {
    const password = 'SecureP@ssw0rd!';
    const hash = await hashPassword(password);
    const isValid = await verifyPassword(password, hash);
    expect(isValid).toBe(true);
  });

  it('should reject incorrect password', async () => {
    const password = 'SecureP@ssw0rd!';
    const hash = await hashPassword(password);
    const isValid = await verifyPassword('WrongPassword', hash);
    expect(isValid).toBe(false);
  });
});

Run: npm test -- tests/unit/models/user.test.ts
Expected: FAIL — "hashPassword is not defined"

• Step 2: 运行测试验证失败

• Step 3: 写最小实现

// src/models/user.ts
import bcrypt from 'bcrypt';

const SALT_ROUNDS = 12;

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

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

• Step 4: 运行测试验证通过

Run: npm test -- tests/unit/models/user.test.ts
Expected: PASS

• Step 5: 提交

git add src/models/user.ts tests/unit/models/user.test.ts
git commit -m "feat(auth): add password hashing with bcrypt"

这个计划文档的每个步骤都是**具体、可执行、可验证**的：

- 失败测试的具体代码：AI 看到 `hashPassword is not defined` 就知道要从哪里开始
- 验证命令：`npm test -- tests/unit/models/user.test.ts` + 预期结果
- 提交信息：包含类型的提交信息（feat/auth）
- 不允许任何 placeholder：没有 TBD、没有 TODO、没有"以后再优化"

这就是 Superpowers 对 YAGNI 原则的强制执行——**你不能跳过任何步骤，不能留下任何未完成的地方**。

### 3.4 test-driven-development：强制 RED-GREEN-REFACTOR

`test-driven-development` 技能是 Superpowers 中执行最严格的技能。它的核心是**强制循环**：

循环：

1. RED 阶段：写一个会失败的测试
2. GREEN 阶段：写最小代码让测试通过
3. REFACTOR 阶段：清理代码（不引入新功能）
4. 提交

Superpowers 的 TDD 技能还内置了**反模式参考**，告诉 AI 常见的 TDD 错误：

```markdown
# TDD Anti-Patterns（禁止行为）

1. **光说不练（Test After）**：在实现代码写完后才写测试。
   → TDD 的核心价值在于"测试先行"，它强迫你先想清楚预期行为。

2. **一步登天（Big Bang Test）**：一个测试覆盖太多场景。
   → 正确的做法是：一个测试 = 一个断言 = 一个具体行为。

3. **跳过失败（Ignored Test）**：测试失败了不修，直接 ignore。
   → 这是技术债务的来源之一，RED 阶段必须 GREEN。

4. **过度实现（Gold Plating）**：测试通过后继续加功能。
   → YAGNI：你不需要它。GREEN 之后立即 REFACTOR，然后提交。

5. **不做边界测试**：只测试 happy path，不测空值、异常、边界条件。
   → 每个函数至少有一个边界测试。

这个反模式列表是 AI 的"纪律红线"——违反任何一条，父 Agent 在审查时就会发现并要求修正。

3.5 subagent-driven-development：并发与审查的协同

这是 Superpowers 最具野心的技能——用子 Agent 驱动开发，用两阶段审查保证质量。

它的执行流程是：

1. 取计划中的下一个任务
2. 派发子 Agent 执行该任务（RED-GREEN-REFACTOR）
3. 子 Agent 完成后，进入两阶段审查：
   阶段一：规格合规审查（Subagent Spec Compliance Reviewer）
     - 这个实现是否符合计划要求？
     - 测试覆盖是否完整？
     - 有没有偏离规格？
   阶段二：代码质量审查（Code Quality Reviewer）
     - 代码可读性如何？
     - 命名是否清晰？
     - 是否有明显的性能问题？
4. 根据审查结果：
   - 关键问题 → 阻塞，要求子 Agent 修复
   - 重要问题 → 记录，继续执行
   - 次要问题 → 可选修复
5. 验证测试全部通过
6. 继续下一个任务（或提交人工检查点）

**人工检查点（Human Checkpoint）**是这个技能的一个关键设计：当连续执行多个任务后，AI 会主动暂停，向用户报告进度，并等待确认：

已执行任务: 4/12
通过测试: 42 个
失败测试: 0 个
覆盖率: 67%

当前进度符合计划。继续执行还是暂停审查？
- [继续执行] [暂停检查] [修改计划]

这种渐进式确认机制，让 AI 在保持自主性的同时，不会走得太远而无法挽回。这是 Superpowers 的工程智慧——完全自动化是目标，但人类监督是保险。

3.6 requesting-code-review：结构化代码审查

requesting-code-review 技能将代码审查也系统化了：

# 代码审查流程

## Step 1: 获取 Diff 范围
BASE_SHA=$(git rev-parse HEAD~1)  # 或 origin/main
HEAD_SHA=$(git rev-parse HEAD)

## Step 2: 派发 Code Reviewer 子 Agent
使用 Task 工具，类型为 superpowers:code-reviewer

模板占位符：
{WHAT_WAS_IMPLEMENTED} - 你刚刚构建的内容
{PLAN_OR_REQUIREMENTS}  - 它应该做什么
{BASE_SHA}              - 开始提交
{HEAD_SHA}              - 结束提交
{DESCRIPTION}           - 简要摘要

## Step 3: 按严重性分类问题

### 关键问题（CRITICAL）
- 安全漏洞
- 数据丢失风险
- 严重的性能问题
→ 必须修复后才能合并

### 重要问题（IMPORTANT）
- 代码可读性问题
- 测试覆盖不足
- 错误处理不完善
→ 应该修复，但不阻塞合并

### 次要问题（MINOR）
- 格式问题
- 小的代码重复
- 注释不够详细
→ 可选择性修复

## Step 4: 技术反驳机制
如果审查者的判断有误，被审查的 Agent 可以用推理进行反驳。
但反驳必须基于证据，不能基于"我认为没问题"。

这个技能解决了 AI 代码审查中最常见的问题——不知道什么该重视、什么可以放过。通过明确的严重性分类，AI 的审查意见变得可操作，而不是"看起来都对"或"感觉有点问题"这种模糊判断。

四、安装与配置：5 分钟让你的 AI 拥有 Superpowers

4.1 Claude Code（推荐方式）

# 1. 注册官方插件市场
/claude /plugin marketplace add obra/superpowers-marketplace

# 2. 安装 Superpowers 插件
/claude /plugin install superpowers@superpowers-marketplace

# 3. 验证安装
/superpowers using-superpowers

# 4. 创建第一个设计文档目录
mkdir -p docs/superpowers/designs docs/superpowers/plans

4.2 Cursor

# 在 Cursor Agent 聊天中执行：
/add-plugin superpowers

# 或者在插件市场中搜索 "superpowers"

4.3 OpenCode

# 告诉 OpenCode 获取安装指令：
"Fetch and follow instructions from 
https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md"

4.4 自定义配置

Superpowers 支持项目级配置。在 .superpowers/config.json 中可以自定义：

{
  "planDirectory": "docs/superpowers/plans",
  "designDirectory": "docs/superpowers/designs",
  "commitMessageStyle": "conventional",
  "maxConcurrentSubagents": 4,
  "checkpointInterval": 5,
  "requireHumanCheckpoint": true
}

其中 checkpointInterval 表示每执行 N 个任务后触发一次人工检查点，requireHumanCheckpoint 控制是否强制人工确认。

五、生产实战：用一个完整案例看 Superpowers 的威力

5.1 项目背景

让我们用一个真实的场景来展示 Superpowers 的工作方式。假设你有一个 Node.js + Express 的 REST API 项目，现在需要添加一个缓存层——使用 Redis 缓存热点数据，降低数据库压力。

5.2 阶段一：Brainstorming

# 你在 Claude Code 中输入：
"给我们的 REST API 加上 Redis 缓存层"

# AI 触发 brainstorming 技能，开始追问：
"我在使用 brainstorming 技能。在开始设计之前，需要澄清几个关键问题："

1. 缓存哪些数据？用户数据？配置数据？查询结果？
   → 建议优先缓存查询结果，因为数据库压力主要来自复杂查询

2. 缓存策略：Cache-Aside 还是 Write-Through？
   → Cache-Aside（旁路缓存）：读时先查缓存，miss 时查 DB 并写入缓存
   → Write-Through（写穿透）：写时同时写 DB 和缓存
   → 建议用 Cache-Aside，复杂度更低

3. TTL（生存时间）如何设置？统一 TTL 还是分级 TTL？
   → 建议：热门数据 5 分钟，一般数据 30 分钟，配置数据 1 小时

4. 缓存击穿怎么办？热点 key 过期瞬间大量请求打穿 DB？
   → 建议使用互斥锁（Redis SETNX）或 "永不过期 + 异步更新" 策略

5. 如何处理缓存和 DB 的数据一致性？
   → 写操作时：先更新 DB，再删除缓存（而非更新缓存）
   → 这样可以避免并发场景下的数据不一致

6. 是否需要缓存预热（Cache Warmup）？
   → 上线新服务时，是否需要主动加载热点数据到缓存

用户逐节确认后，AI 生成设计文档并保存。

5.3 阶段二：Writing Plans（部分示例）

# Redis 缓存层实施计划

**Goal:** 实现 Cache-Aside 策略的 Redis 缓存层

**Architecture:** 
使用 ioredis 作为 Redis 客户端，Cache-Aside 读策略，
Write-Through 写策略（先写 DB，后删缓存），
支持分级 TTL，集成互斥锁防止缓存击穿。

**Tech Stack:** Node.js + ioredis + TypeScript

---

### Task 1: Redis 连接管理

**Files:**
- Create: src/cache/redis.ts
- Test: tests/unit/cache/redis.test.ts

- [ ] Step 1: 写失败的测试
- [ ] Step 2: 写最小 Redis 连接实现
- [ ] Step 3: 写连接池管理代码
- [ ] Step 4: 验证测试通过
- [ ] Step 5: 提交

### Task 2: 缓存基础操作（get/set/del）

**Files:**
- Create: src/cache/client.ts
- Test: tests/unit/cache/client.test.ts

- [ ] Step 1: 写失败的测试
- [ ] Step 2: 写 get/set/del 实现
- [ ] Step 3: 验证测试通过
- [ ] Step 4: 提交

### Task 3: Cache-Aside 读策略

**Files:**
- Modify: src/services/user.service.ts
- Test: tests/unit/services/user.service.test.ts

- [ ] Step 1: 写失败的测试（测缓存未命中时查 DB）
- [ ] Step 2: 写缓存命中时直接返回
- [ ] Step 3: 写缓存未命中时查 DB 并回填缓存
- [ ] Step 4: 验证测试通过
- [ ] Step 5: 提交

### Task 4: 互斥锁防止缓存击穿

**Files:**
- Create: src/cache/lock.ts
- Test: tests/unit/cache/lock.test.ts

- [ ] Step 1: 写失败的测试
- [ ] Step 2: 用 SETNX 实现分布式锁
- [ ] Step 3: 验证测试通过
- [ ] Step 4: 提交

...

5.4 实际效果对比

程序员茄子在同一个项目中，分别用传统方式和 Superpowers 方式实现相同功能，对比如下：

结论：Superpowers 方式多花 40% 的时间，换来了 0 Bug 率和 3 倍的测试覆盖率。对于生产级项目，这绝对是划算的交易。

六、横向对比：Superpowers vs 其他 AI 编程方法

6.1 与普通提示词（Plain Prompts）的对比

6.2 与 MCP（Model Context Protocol）的对比

MCP 是 Anthropic 推出的上下文协议，让 AI 可以调用外部工具（数据库查询、API 调用等）。Superpowers 和 MCP 是互补关系，不是竞争关系：

• MCP：解决"AI 能做什么工具"的问题
• Superpowers：解决"AI 怎么用工具做事"的问题

一个完整的 AI 编程工作流应该是：Superpowers（方法论框架）+ MCP（工具扩展）。Superpowers 官方已经支持与 MCP 工具集成，可以在 brainstorming 和 code review 阶段调用外部工具获取上下文信息。

6.3 与 Cursor Rules、Claude Rules 的对比

Cursor Rules 和 Claude Rules 是针对特定工具的配置规则，告诉你"在这个项目中，AI 应该这样做"。Superpowers 是跨工具的方法论框架——你在 Cursor 里安装 Superpowers，Rules 也依然生效。两者是正交关系，可以叠加使用。

七、局限性与边界：Superpowers 不是银弹

7.1 什么场景不适合 Superpowers？

不适合的场景：

1. 一次性脚本和工具：写一个文件转换脚本还要走完整 TDD 流程，是过度工程
2. 极度紧急的 Hotfix：时间敏感的生产故障，需要快速止血，TDD 循环可能拖慢速度
3. 探索性实验：不知道要做什么，只是随便试试，brainstorming 可能反而制造噪音
4. 极小的改动：改一行配置、写一个接口文档，不需要完整流程

7.2 当前局限性

1. 学习曲线：需要理解每个技能的触发时机和执行要求，对新手不友好
2. 不是全自动：仍然需要人类阶段性确认，无法完全"设置后不管"
3. 跨工具一致性：虽然支持 8 种 AI 编程工具，但不同工具的行为模式有差异，部分技能的触发精度不一致
4. 中文资料较少：目前主流文档和社区讨论以英文为主

7.3 最佳使用姿势

程序员茄子的建议是渐进式采用：

第一阶段（第 1-2 周）：
  只开启 brainstorming + TDD
  感受 Socratic 追问带来的需求澄清价值
  习惯"测试先行"的节奏

第二阶段（第 3-4 周）：
  加入 writing-plans
  体验"2-5 分钟任务粒度"带来的可控性
  开始习惯提交记录

第三阶段（持续）：
  开启 subagent-driven-development
  体验 AI 自主开发数小时的乐趣
  逐步放开人工检查点间隔

八、总结与展望

8.1 核心价值

Superpowers 的核心价值，用一句话总结就是：它把「工程纪律」从人的脑子里，搬到了 AI 的工作流里。

过去，我们靠团队规范、Code Review、流程制度来保证工程质量。现在，AI 编程助手本身就可以自动遵循这些纪律——不依赖人类的监督，不依赖提醒和唠叨。

这意味着：

• 单人开发者也能做大事：一个人 + Superpowers，可以有过去整个团队才有的工程纪律
• AI 编程从"玩具"变成"生产力"：有了纪律的 AI，不再是只能写脚本的玩具，而是真正可以信任的生产力工具
• 知识可以被编码和复用： Jesse Vincent 30 年的工程经验，现在可以被任何一个安装 Superpowers 的开发者使用

8.2 未来趋势

2026 年，AI 编程工具链正在经历从"提示词工程"到"代理技能框架"的范式转换。Superpowers 站在了这个转换的前沿。它的影响力已经开始向更广泛的生态扩散：

• Skills 框架的标准化：Superpowers 的 Skills 格式正在成为 AI 编程领域的"事实标准"
• 企业级采用：越来越多的工程团队开始将 Superpowers 作为 AI 编程的团队规范
• Skills 市场：未来可能出现类似 npm 的 Skills 市场，开发者可以发布、分享和复用技能包

8.3 行动建议

如果你是一个认真对待 AI 编程的开发者，现在就是接入 Superpowers 的最佳时机：

1. 今天就安装：选一个你常用的 AI 编程工具，安装 Superpowers，体验 10 分钟
2. 从小任务开始：用一个小的功能需求，完整走一遍 brainstorming → TDD → 提交的流程
3. 记录你的观察：Superpowers 改变了什么？哪些环节最有价值？哪些不适应？
4. 逐步扩展：当你习惯了这套流程，再逐步引入 writing-plans、subagent-driven 等进阶技能

AI 编程助手不是魔法，它是一个能力很强但缺乏纪律的实习生。Superpowers 就是给这个实习生上的那门"工程纪律课"。

当你给它装上 Superpowers，你会发现：你的 AI 不再只是帮你写代码，它在帮你成为一个更好的工程师。

附录：资源链接

• GitHub 仓库：https://github.com/obra/superpowers
• 官方文档：https://github.com/obra/superpowers/blob/main/docs/
• 发布公告：https://blog.fsck.com/2025/10/09/superpowers/
• Discord 社区：https://discord.gg/35wsABTejz
• Claude 插件市场：搜索 "superpowers" 或 obra/superpowers-marketplace

本文作者：程序员茄子 · 首发于 chenxutan.com · 2026 年 6 月 14 日