Superpowers：为编程 AI Agent 设计的开发方法论与技能框架
Superpowers：为编程 AI Agent 设计的开发方法论与技能框架
Superpowers 是一个为编程 AI Agent 设计的”开发方法论 + 技能框架”。
它的核心理念是：不让 Agent 一上来就写代码，而是强制它先搞清楚你要做什么、出方案、拆分任务、用 TDD 方式逐步实现，并通过子 Agent 并行推进。整个流程像一个”严格遵守工程纪律的初级工程师”那样工作。
下面从实际项目中的应用流程和各场景具体用法两个维度来拆解。
目录
1. 完整开发流程（从想法到合入主干）
Superpowers 定义了一条不可跳过的流水线，每一步都对应一个技能（skill），Agent 会自动检测上下文并按需激活。
1.1 头脑风暴与需求澄清 —— brainstorming
触发时机： 你跟 Agent 说”我想做一个XXX功能”，Agent 不会直接写代码。
实际用法： Agent 会通过苏格拉底式的提问帮你把模糊想法变成可落地的设计文档。它会：
- 追问你真正想解决的问题
- 探索备选方案和权衡
- 把设计拆成小块，逐块展示让你确认
- 最终将设计文档保存下来
适用场景： 需求模糊时的概念探索、技术方案选型、重构前的设计确认。
1.2 Git Worktree 隔离环境 —— using-git-worktrees
触发时机： 设计方案被批准后。
实际用法： Agent 不会直接在当前分支上动手，而是：
- 创建新的 Git Worktree 作为隔离工作区
- 在新分支上操作
- 运行项目初始化，确保测试基线是干净的
适用场景： 避免污染主工作区、并行开发多个功能、安全尝试高风险改动。
1.3 实施计划拆分 —— writing-plans
触发时机： 有了批准的设计文档之后。
实际用法： Agent 会把整个工作拆成每个 2-5 分钟的原子任务。每个任务包含：
- 精确的文件路径
- 完整的代码片段
- 验证步骤
适用场景： 中大型功能开发、多人协作的任务分配、保证实施过程不跑偏。
1.4 执行实施 —— 两种模式
模式 A：subagent-driven-development（子 Agent 驱动开发）
每个任务派遣一个全新的子 Agent 去执行，执行完后经过两阶段审查：
- 第一轮：检查是否符合设计规格
- 第二轮：检查代码质量
通过后才进入下一个任务。一个任务一个子 Agent，上下文干净，不会”越写越偏”。官方说 Claude 可以在无人干预的情况下自主工作数小时而不偏离计划。
模式 B：executing-plans（批量执行 + 人工检查点）
按照计划批量执行每项任务，每个阶段设有人工确认点，适合需要更多控制权的场景。
1.5 严格 TDD —— test-driven-development
触发时机： 进入任何代码实现时。
实际用法： 强制执行 RED → GREEN → REFACTOR 循环：
- 先写一个会失败的测试
- 跑测试确认它真的失败
- 写最少量的代码让测试通过
- 跑测试确认通过
- 提交
- 如果在测试之前写了任何代码，会被删掉重来
内置了测试反模式参考，防止写出无效测试。
1.6 代码审查 —— requesting-code-review
触发时机： 任务之间。
实际用法： 对照原始计划逐项审查，按严重性分级报告问题，严重问题会阻止继续前进。
1.7 收尾合入 —— finishing-a-development-branch
触发时机： 所有任务完成。
实际用法： 再次验证所有测试通过，然后给出选项：直接合入 / 发 PR / 保留分支 / 丢弃。最后清理 Worktree。
2. 各场景详细应用
| 场景 | 涉及的技能 | 实际效果 |
|---|---|---|
| 接手遗留代码加新功能 | brainstorming → writing-plans → subagent-driven-development → TDD | 先理解上下文再动手，每个改动有测试保护，不会破坏已有功能 |
| 修 Bug | systematic-debugging → verification-before-completion → TDD | 四阶段根因分析：不是改了就好，必须验证确实修了 |
| 重构大模块 | brainstorming → using-git-worktrees → writing-plans → executing-plans | 隔离环境操作，拆分小块逐步重构，设人工检查点 |
| 多人并发开发 | dispatching-parallel-agents → using-git-worktrees | 多个子 Agent 在不同 Worktree 上并行推进不同任务 |
| 代码评审与反馈响应 | requesting-code-review / receiving-code-review | 自动对照计划做审查，收到他人反馈后有标准化的响应流程 |
| 创建自定义技能 | writing-skills | 按最佳实践创建新技能（含测试方法），扩展框架本身 |
3. 哲学原则（贯穿所有场景）
Superpowers 的设计始终遵循以下原则，你在实际使用中会反复感受到：
- TDD 至上： 永远先写测试，不写测试的代码是不可接受的。
- 系统化 > 即兴发挥： 遵循流程而不是靠”感觉”。
- 化繁为简： 简单性是首要目标——YAGNI（你不需要它）、DRY（不要重复自己）。
- 证据 > 宣称： 验证通过才算数，不要说自己做完了。
4. 实际项目中的关键价值
回到你的问题——怎么在实际项目中使用，最核心的价值在于：
- 防止 Agent “自作聪明”：没有 Superpowers 时，Agent 往往直接写代码，很容易偏离意图。Brainstorming 阶段强制对齐理解。
- 上下文管理：子 Agent 模式让每个任务都在干净的上下文中执行，避免了长对话中 Agent “忘记初衷”的问题。
- 质量门禁自动化：TDD + 两阶段审查 + 验证步骤，形成了一套自动化的质量保障链。
- 支持多工具链：同一个方法论在 Claude Code、Codex CLI、Cursor、Gemini CLI、GitHub Copilot CLI 等不同平台上都能用，项目里混用工具也不影响一致性。
简单说，Superpowers 就是把优秀工程师的开发纪律——先想清楚、拆分任务、写测试、小步提交、每个改动都审查——固化成了 Agent 的”本能反应”。
