核心一句话：Superpowers 不是让 AI 变聪明，而是让 AI 变靠谱——它把软件工程最佳实践强制注入 AI 行为，从"聪明的实习生"变成"严谨的资深搭档"。

---

目录

1. 痛点：AI 写代码为什么总让人不放心
2. Superpowers 是什么——一句话讲透本质
3. 14 个 Skill 全览——不是工具箱，是流水线
4. 四大设计哲学——为什么这套流程值得信
5. 全平台安装指南——11 个 Agent 怎么装
6. 自动触发机制——你不需要记任何命令
7. 三大核心命令——手动控制流程的入口
8. 完整实战走读——从模糊需求到代码合入
9. 每个 Skill 深度拆解——触发时机、做什么、输出什么
10. 进阶用法——并行、调试、审查的黄金法则
11. 与其他 Skill 的对比——Superpowers vs planning-with-files vs everything
12. 什么时候不需要 Superpowers
13. 常见误区与避坑
14. 三条铁律——记住就够了

---

一、痛点：AI 写代码为什么总让人不放心

用过 Claude Code、Cursor 这类 AI 编程工具的人，大概率遇到过这些情况：

你刚说一句"做个登录功能" → 它立刻闷头开写 → 做出来根本不是你想要的
它写得飞快 → 但没有测试 → 你也不知道到底对不对
一个项目做到一半 → 它忘了前面的约定 → 风格结构全乱了
它信誓旦旦说"已经搞定了" → 你一跑 → 报错

这些问题的本质：AI 会写代码，但不一定按"专业的流程"写代码。

资深工程师不会一上来就敲键盘。他们会先理需求、写计划、写测试、做 review。而这套"工作习惯"，恰恰是默认状态下 AI 最欠缺的。

Superpowers 要解决的，就是这件事。

---

二、Superpowers 是什么——一句话讲透本质

Superpowers 是由 Jesse Vincent（GitHub ID: obra）开发并开源的 AI 编程技能包（MIT 协议），2025 年 10 月首次发布，2026 年初进入 Anthropic 官方插件市场后迅速爆发，GitHub 星数突破 123,000，一度成为 GitHub Trending 榜首。

但很多人搞混了一件事：Superpowers 不是代码生成工具，它也不能把 AI 变得更聪明。

它的本质是——

一套完整的 AI 开发方法论 + 可组合的技能库。

通俗来说：它把软件工程最佳实践（TDD、Code Review、Spec-Driven、Git Worktree、子 Agent 协作）全部封装成 AI 可自动执行的 Skills，让大模型从"代码生成器"变成"真正懂工程的 Junior Engineer"。

装上后最核心的改变：

没装 Superpowers：
  你："做个登录功能" → AI 立刻开始写代码 → 500 行 → 不对 → 返工

装了 Superpowers：
  你："做个登录功能" → AI 先停下来问你到底想做什么
  → 聊清需求 → 给你看设计方案 → 你确认
  → 写实现计划 → 拆成小任务 → 每个任务先写测试再写实现
  → 代码审查 → 验证 → 完成

它不是让 AI 写得更快，而是让 AI 做得更稳、更靠谱。

---

三、14 个 Skill 全览——不是工具箱，是流水线

很多人把 Superpowers 当成瑞士军刀——14 个工具，需要哪个切哪个。其实理解错了。Superpowers 是一套有严格先后顺序的开发流水线。上一个 Skill 的输出，是下一个 Skill 的输入。

按开发阶段排列的七梯队：

入口层：using-superpowers —— 交警，判断该走哪条道
设计层：brainstorming —— 不急着写代码，先问清楚需求
规划层：writing-plans —— 把需求拆解成 2-5 分钟小任务
隔离层：using-git-worktrees —— 创建隔离的手术台，不在主分支动刀
执行层：subagent-driven-development / executing-plans —— 派代理干活
测试层：test-driven-development —— 铁律：没失败测试不写代码
调试层：systematic-debugging —— 先找根因再修 bug
审查层：requesting-code-review + receiving-code-review —— 双重审查
并行层：dispatching-parallel-agents —— 独立任务同时派多组人马
验证层：verification-before-completion —— 没跑命令不能说"搞定了"
收尾层：finishing-a-development-branch —— 验证、合并、清理战场
元技能：writing-skills —— 用 TDD 方法写新 Skill

完整技能表：

分类	Skill	触发方式	核心作用
测试	test-driven-development	自动触发	红→绿→重构循环（含测试反模式参考）
调试	systematic-debugging	自动触发	4阶段定位根因：复现→定位→修复→验证
调试	verification-before-completion	自动触发	完成前必须跑验证，不能"我觉得没问题"
协作	brainstorming	/superpowers:brainstorm 或自动触发	苏格拉底式需求细化
协作	writing-plans	/superpowers:write-plan	输出详细实现计划
协作	executing-plans	/superpowers:execute-plan	带检查点的批量执行
协作	dispatching-parallel-agents	自动触发	并发子代理工作流
协作	subagent-driven-development	自动触发	子代理驱动开发+两阶段审查
协作	requesting-code-review	/superpowers:requesting-code-review	提交审查前的检查清单
协作	receiving-code-review	自动触发	如何回应审查反馈
协作	using-git-worktrees	自动触发	并行开发分支管理
协作	finishing-a-development-branch	自动触发	合并/PR决策流程
元技能	writing-skills	手动触发	按最佳实践创建自己的技能
元技能	using-superpowers	自动触发	技能系统入门介绍

⚠️ 重要：代理在任何任务前都会先检查有没有相关技能可用。这些是强制的工作流，不是建议。

---

四、四大设计哲学——为什么这套流程值得信

Superpowers 背后有 4 条很朴素但很关键的原则：

原则	说明	对抗什么问题
测试优先	永远先写测试	AI 自信地说"搞定了"但没验证
系统化胜过随手做	用流程，不是靠猜	AI 随机尝试修复 bug，没有根因分析
降低复杂度	把"简单"当首要目标	AI 过度设计，写了 300 行其实 10 行就够了
用证据而非声称	验证后再宣布成功	AI 说"应该没问题"但没跑过任何测试

这几条原则，正好是对抗 AI 幻觉的解药。AI 最大的问题就是"自信地说错、没验证就声称搞定"，而 Superpowers 用"先写测试、用证据验证"从流程上把这个问题摁住了。

---

五、全平台安装指南——11 个 Agent 怎么装

Superpowers 支持 11 个主流 AI 编码工具。如果你同时用多个工具，需要为每个工具分别安装一次。

5.1 Claude Code（推荐平台）

# 方式一：Anthropic 官方市场（推荐，最简单）
/plugin install superpowers@claude-plugins-official

# 方式二：Superpowers 自有市场（额外包含一些相关插件）
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

装完重启 Claude Code，输入 /superpowers 验证安装是否成功。

5.2 Codex App（图形界面）

1. 打开 Codex 应用 → 侧边栏点击 Plugins
2. 在 Coding 区找到 Superpowers
3. 点击 + → 按提示操作

5.3 Codex CLI

/plugins              # 打开插件搜索界面
# 输入 superpowers → 搜索
# 选择 Install Plugin

5.4 Cursor

/add-plugin superpowers
# 或在插件市场搜索 "superpowers"

5.5 Gemini CLI

gemini extensions install https://github.com/obra/superpowers

# 更新
gemini extensions update superpowers

5.6 GitHub Copilot CLI

copilot plugin marketplace add obra/superpowers-marketplace
copilot plugin install superpowers@superpowers-marketplace

5.7 Kimi Code

/plugins                                    # 打开插件管理器
# 进入 Marketplace → Superpowers → 安装

# 或直接从仓库安装
/plugins install https://github.com/obra/superpowers

5.8 OpenCode

# 按照官方文档安装
# https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md

5.9 Antigravity

agy plugin install https://github.com/obra/superpowers

Antigravity 运行插件的 session-start hook，Superpowers 从第一条消息即激活。

5.10 Factory Droid

droid plugin marketplace add https://github.com/obra/superpowers
droid plugin install superpowers@superpowers

5.11 Pi

pi install git:github.com/obra/superpowers

Pi 原生支持 skills，无需兼容 Skill 工具。子代理和任务列表工具为可选的 Pi 伴随包。

验证安装是否成功

安装后在对应工具中输入：

/superpowers

你应该能看到三个核心命令：

• /superpowers:brainstorm —— 交互式设计细化
• /superpowers:write-plan —— 创建实现计划
• /superpowers:execute-plan —— 使用子代理执行计划

看到这三个命令就说明安装成功了。

---

六、自动触发机制——你不需要记任何命令

这是 Superpowers 最容易被忽视的特性：大部分 Skill 是自动触发的。

你照常说话，Superpowers 会在合适的时机自动激活：

你说的话	自动触发的 Skill
“帮我做个登录功能”	brainstorming → 先问你到底想做什么
“这个报错帮我定位”	systematic-debugging → 4阶段根因分析
“帮我重构这个模块”	writing-plans → 先写计划再动手
“开始实现”	subagent-driven-development → 派子代理干活
代码写完	requesting-code-review → 自动审查
审查反馈来了	receiving-code-review → 按严重度处理
任务完成	verification-before-completion → 必须跑验证
分支做完	finishing-a-development-branch → 合并/PR决策

你不需要说"请用 Superpowers"，正常提需求就行。

这是和很多其他 Skill 的关键区别：Superpowers 不是你要手动调用的工具，它更像是一个后台守护进程，在你需要的时候自动介入。

---

七、三大核心命令——手动控制流程的入口

虽然大部分自动触发，但三个关键节点需要你手动确认：

/superpowers:brainstorm

触发时机：任何超过 50 行代码的功能开发前

它做什么：不写代码，先变成产品经理对你进行"灵魂拷问"

你："帮我做个登录功能"

Claude（使用 brainstorming）：
"我先用 brainstorming 技能来探索这个功能。

让我问几个澄清问题：
1. 这个登录功能加到哪个项目？还是全新项目？
2. 技术栈？ → 前端 React，后端 Node.js
3. 认证方式？ → 账密 + OAuth
4. 数据库？ → SQLite 还是 PostgreSQL？
5. 需要记住登录状态吗？ → JWT Token
..."

你回答完后 → 生成设计摘要 → 等你确认 → 才进入实现阶段

为什么重要：AI 最贵的 Bug 不是语法错误，而是方向错误。Brainstorming 消耗的 token 不多（3000-5000），但能避免方向性返工。投入产出比极高。

/superpowers:write-plan

触发时机：设计确认后，动手前

它做什么：把大需求拆成 2-5 分钟可完成的小任务

输出格式：
- 任务1：实现 ERP 接口鉴权模块
  [ ] 写失败测试：错误 Token 应抛 401
  [ ] 实现 getAuthToken 函数
  [ ] 运行测试确认通过
  [ ] 提交代码

- 任务2：实现库存数据拉取
  [ ] 写失败测试：接口返回空数组时处理
  [ ] 实现 fetchInventory 函数，处理分页
  [ ] 运行测试确认通过
  [ ] 提交代码

- 任务3：...

关键细节：计划是写给"一个技术很强但对你的项目一无所知的陌生人"看的。所以不能写"添加验证"，必须写"在 src/services/inventory.ts 第45行添加 if (!token) throw new Error()"。

/superpowers:execute-plan

触发时机：你审阅完计划并确认后

它做什么：按计划用子代理执行，每个任务遵循 TDD，任务间自动 Code Review

执行机制：
1. 为每个任务创建全新 Claude 实例（携带最小必要上下文）
2. 子代理必须先写测试 → 看测试失败 → 再写实现
3. 任务完成后两阶段审查（规格合规 + 代码质量）
4. 关键问题阻止继续推进
5. 全部完成后 verification-before-completion 自动跑验证

---

八、完整实战走读——从模糊需求到代码合入

用一个真实场景把整套流程跑一遍。

场景：给电商后台系统开发「商品库存实时同步服务」——定时从上游 ERP 拉库存数据、更新本地数据库、库存低于阈值自动发钉钉报警。

第 1 步：brainstorming — 别急着动手

你："帮我写一个库存同步服务"

没有 Superpowers 的 Claude → 直接甩一段带 while(true) 的代码

有 Superpowers 的 Claude → 触发 brainstorming：
  "让我先理清需求：
   1. 上游 ERP 接口的鉴权方式？Token 还是 API Key？
   2. 全量同步还是增量同步？数据量大概多少？
   3. 同步失败的重试策略？指数退避？
   4. 报警发给谁？钉钉群 Webhook 地址有吗？
   5. 同步频率？每5分钟？每小时？"

  提出两个方案：
   方案A：独立 Node.js 服务 + Cron Job
   方案B：集成到主程序 + Bull 队列

  你选了方案A → 生成 docs/superpowers/inventory-sync-spec.md

第 2 步：writing-plans — 拆到 2 分钟一个任务

生成计划：

任务1：实现 ERP 接口鉴权模块
  [ ] 写失败测试 → 实现 → 测试通过 → 提交

任务2：实现库存数据拉取
  [ ] 写失败测试 → 实现 → 测试通过 → 提交

任务3：实现本地数据库更新
  [ ] 写失败测试 → 实现 → 测试通过 → 提交

任务4：实现库存阈值检测
  [ ] 写失败测试 → 实现 → 测试通过 → 提交

任务5：实现钉钉报警通知
  [ ] 写失败测试 → 实现 → 测试通过 → 提交

任务6：集成测试 + 收尾
  [ ] 写集成测试 → 全部通过 → 合并分支

第 3 步：using-git-worktrees — 隔离工作空间

# 自动执行
git worktree add .worktrees/inventory-sync feature/inventory-sync
cd .worktrees/inventory-sync
npm install
npm test  # 确保基线是健康的

为什么这么麻烦？ 如果代码写炸了，直接删掉 .worktrees/inventory-sync 目录就行，主分支干干净净不受影响。就像医生做手术前消毒，不消毒大概率没事，但一旦感染就是医疗事故。

第 4 步：subagent-driven-development — 代理流水线

对每个小任务，启动全新 AI 代理处理：

  派代理A → 实现鉴权模块（只看任务1描述）
  派代理B → 审查规格（代码是否符合需求？）
  派代理C → 审查质量（代码风格、安全性、潜在bug？）
  两个审查通过 → 任务1标记完成 → 开始任务2

  鉴权模块的代理和钉钉报警的代理完全隔离，互不干扰

为什么是"新代理"？ AI 的上下文窗口有限。在一个窗口连续聊 10 个任务，到第5个任务时已经忘了第1个的命名规范。新代理 = 全新上下文 = 极高专注度 = 更少错误。

第 5 步：test-driven-development — 代理内部的铁律

每个代理必须遵循：

RED → 先写必定失败的测试 → 运行 → 看红灯
GREEN → 写最少的代码让测试通过 → 运行 → 看绿灯
REFACTOR → 重构代码 → 保持绿灯
重复

Superpowers 对这步极其严格：
  "这个逻辑太简单不用测吧？" → 不行
  "先写个实现看看效果回头补测试" → 不行
  "只是试一下API怎么调用" → 不行，去看文档别写代码

为什么？因为 AI 是最擅长走捷径的。
一旦允许先写实现，它绝对不会回头写测试。

第 6 步：requesting-code-review + receiving-code-review — 双重审查

第一轮：请求审查
  派独立审查代理，只看代码变更，不看聊天记录
  按严重度分级：
    Critical：SQL注入风险、硬编码密码 → 必须修
    Important：变量命名不清、逻辑冗余 → 应该修
    Minor：注释格式、尾随空格 → 记下来

第二轮：接收审查
  不是审查说什么你就改什么！
  审查建议"加个缓存" → 但数据实时性要求极高 → 反驳
  审查建议用递归 → 但数据量大可能栈溢出 → 反驳
  黄金法则：技术正确性 > 社交舒适度

第 7 步：verification-before-completion — 拿证据说话

错误示范：
  AI："改完了，应该没问题。"（没跑但感觉是对的）

Superpowers 要求：
  AI："我运行了 npm test，42个测试全部通过，0失败。
       另外手动触发了一次同步，日志显示正常。"

  必须是当前消息里刚刚运行的命令结果
  不能拿上个月的测试报告糊弄人

---

九、每个 Skill 深度拆解

9.1 brainstorming（头脑风暴）

触发：/superpowers:brainstorm 或你说"帮我做XXX功能"时自动触发

做什么：

• 读取项目配置文件，了解现有架构
• 逐个提问，澄清模糊需求
• 提出多个方案供你选择
• 生成结构化设计摘要，等你确认

输出：docs/superpowers/xxx-spec.md 设计文档

消耗：约 3000-5000 tokens

什么时候跳过：改一行 CSS、修一个 typo 不需要 brainstorm

9.2 writing-plans（编写计划）

触发：/superpowers:write-plan 或设计确认后自动进入

做什么：

• 把大需求拆成 2-5 分钟可完成的小任务
• 每个任务标注精确文件路径
• 显示任务依赖关系图
• 预估时间和风险点

输出：详细的任务清单，每个任务包含 [ ] 格式的检查项

关键细节：计划是给"陌生人"看的，越细越好。不能写"添加验证"，必须写"在 src/services/inventory.ts 第45行添加 if (!token) throw new Error()"

9.3 executing-plans（执行计划）

触发：/superpowers:execute-plan

做什么：

• 逐个执行计划中的任务
• 每个任务完成后显示检查点让你确认
• 不自动跳到下一个任务除非你同意

适合：没有子代理功能时使用，人工控制节奏

9.4 subagent-driven-development（子代理驱动开发）

触发：自动触发（当有可并行拆分的任务时）

做什么：

• 为每个任务派发全新子代理
• 子代理只看到自己那一个任务的描述
• 两阶段审查：规格合规 + 代码质量
• 审查通过才标记完成

效果对比：

方式	6个接口处理时间	Token消耗
串行（无Superpowers）	~15分钟	~80k
并行（Superpowers）	~6分钟	~90k

Token 略多（子代理有独立上下文），但时间节省 60%。

9.5 test-driven-development（测试驱动开发）

触发：实现代码时自动触发

做什么：

• 强制 RED → GREEN → REFACTOR 循环
• 会删除先于测试写的代码——如果你让 AI 先写实现再补测试，Superpowers 会删掉实现，强制先写测试
• 包含测试反模式参考（避免"按照实现写测试"的陷阱）

为什么先写测试再写实现更好？

先写代码再补测试：
  AI 按照实现来写测试 → 知道代码怎么跑 → 测试永远通过
  → 但不测边界情况 → 隐藏的bug没被捕获

先写测试再写代码：
  AI 按照需求来写测试 → 还不知道实现细节
  → 测试覆盖各种预期行为（包括异常情况）
  → 实现必须通过所有测试才算完成

9.6 systematic-debugging（系统性调试）

触发：你说"这个报错帮我定位"或遇到 bug 时自动触发

做什么：4 阶段根因分析

Phase1：复现 → 写一个能稳定触发 bug 的测试用例
Phase2：定位 → 追踪调用链，找根因（不是症状）
Phase3：修复 → 改根因，而不是包一层 catch
Phase4：验证 → 跑测试确认修复，检查没有引入新问题

3次规则：连续 3 次修复尝试都失败 → 问题可能在架构层面 → 建议停下来找人讨论，不再死磕

对比：

没有 Superpowers：
  报错了 → 加个 try-catch → 不报错了 → "修好了！"
  （根因没解决，只是把报错藏起来了）

有 Superpowers：
  报错了 → 先写能复现的测试 → 追踪到根因 → 修根因 → 测试通过

9.7 verification-before-completion（完成前验证）

触发：任务完成时自动触发

做什么：

• 要求提供"新鲜证据"——必须是当前消息里刚刚运行的命令结果
• 不能说"刚才跑过了"——代码可能在你验证之后又被改了
• 不能说"应该没问题"——必须跑命令确认

9.8 requesting-code-review + receiving-code-review

触发：代码写完后自动触发审查，审查反馈来了自动触发回应

审查分级：

• Critical → 必须修（SQL注入、硬编码密码）
• Important → 应该修（命名不清、逻辑冗余）
• Minor → 记下来（注释格式、尾随空格）

回应原则：不是审查说什么你就改什么。如果你知道审查建议会引入 bug，大胆反驳。Superpowers 希望培养的是有主见的工程师，不是唯唯诺诺的实习生。

9.9 using-git-worktrees（Git Worktree 隔离）

触发：开发开始时自动触发

做什么：

• 创建隔离的 Git worktree
• 在新分支上工作，不影响 main
• 代码写炸了直接删目录，零风险

git worktree add .worktrees/feature-name feature/feature-name
cd .worktrees/feature-name
npm install && npm test  # 确保基线健康

9.10 dispatching-parallel-agents（并行代理分发）

触发：多个互不依赖的任务时自动触发

适合并行的场景：

• 写"ERP接口适配器"和"钉钉报警模块"，互不干扰
• 修复3个完全不相关的 bug

绝对不能并行的场景：

• 两个代理可能修改同一个文件
• 一个任务的依赖是另一个任务的输出

9.11 finishing-a-development-branch（分支收尾）

触发：所有任务完成后自动触发

做什么：

• 验证全部测试通过
• 提供选择：合并 / 提 PR / 保留 / 丢弃
• 清理 worktree

9.12 writing-skills（元技能）

触发：手动触发

做什么：按最佳实践创建自己的 Skill（含 TDD 方法论）

适合：当你对默认流程有了自己的想法，想写贴合个人工作流的定制技能

---

十、进阶用法

技巧一：自然语言驱动，不用记命令

直接描述任务，插件自动匹配技能：

"帮我重构这个模块" → 触发计划 + 审查
"这个报错帮我定位" → 触发系统化调试
"帮我做代码评审" → 触发审查技能
"帮我规划一个功能" → 触发 brainstorming

技巧二：强制高质量输出

在需求前加一句：

按 Superpowers 完整流程，先 brainstorm，再 write-plan，最后 execute-plan，
必须做 TDD 和 code review

AI 会严格按工程标准执行。

技巧三：复杂项目必开 Git Worktrees

开发前主动要求：

用 git worktrees 隔离开发，避免影响主线

安全试错，改崩直接丢弃，零风险。

技巧四：团队统一 AI 开发规范

全团队统一安装 Superpowers，实现：

• 统一开发流程
• 统一代码规范
• 统一审查标准
• 降低沟通成本，提升交付质量

技巧五：长项目会话管理

即使有了 Superpowers，超长期项目（数周）仍可能积累上下文债务：

解决方案：
1. 定期 /compact → 压缩历史对话，保留关键决策
2. 文档化架构决策 → 让 Superpowers 在 Plan 阶段输出 ARCHITECTURE.md
3. 使用 Git Worktree 隔离 → 每个大功能独立分支

抹技巧六：与 VS Code 集成

1. 安装 Claude Code Extension
2. VS Code 终端运行 claude 命令
3. 查看 Superpowers 生成的代码和测试文件
4. VS Code Git 面板管理 Superpowers 创建的 worktree 分支

---

十一、与其他 Skill 的对比

Superpowers vs planning-with-files

维度	Superpowers	planning-with-files
定位	完整开发方法论框架	跨会话上下文持久化
核心理念	流程大于提示词	记忆大于重新推理
解决的问题	AI 不按专业流程开发	AI 忘了上次的约定
技能数量	14 个	1 个（但覆盖持久化全流程）
触发方式	大部分自动 + 3个手动命令	自动触发
含 TDD	✅ 强制	❌ 不含
含 Code Review	✅ 双重审查	❌ 不含
含 Git Worktree	✅ 自动隔离	❌ 不含
含子代理	✅ 并行开发	❌ 不含
最佳搭配	两者一起用	与 Superpowers 互补

结论：两者互补不冲突。Superpowers 管流程，planning-with-files 管记忆。一起用效果最好。

Superpowers vs everything-claude-code

维度	Superpowers	everything-claude-code
定位	开发方法论框架	综合工具集（183k Stars）
包含内容	14个工程流程技能	更多功能：代码审查+文档+搜索+安全等
侧重点	流程纪律	功能覆盖面
适合谁	想让AI按专业流程干活的人	想给AI加更多工具的人

结论：两者也可以一起用。Superpowers 管流程纪律，everything-claude-code 提供工具能力。

Superpowers vs andrej-karpathy-skills

维度	Superpowers	karpathy-skills
定位	强制工程流程	解决AI"过度热情"问题
核心理念	先规划后执行	简单优先，别过度设计
重叠	brainstorming 阶段有相似的"简化需求"思路	更偏方法论指导

结论：karpathy-skills 更轻量更哲学，Superpowers 更系统更强制。轻度用户选 karpathy，重度开发选 Superpowers。

---

十二、什么时候不需要 Superpowers

任何工具都有边界。以下场景不建议使用：

场景	为什么不适合	怎么做更好
一次性脚本	写完就扔，TDD是负担	直接让AI写，跑一次验证
探索性原型	还在试技术选型，brainstorming觉得卡顿	先快速出原型，确认可行后再开Superpowers
紧急Hotfix	线上着火，先止血	先修bug，回头补流程
改一行CSS/修typo	走完整流程太重	直接改，不用Superpowers
学习/实验	还在了解AI能力边界	跑通基础用法再上Superpowers

最适合的场景：长期维护的、团队协作的、复杂度较高的业务项目。

---

十三、常见误区与避坑

误区1：“每个小任务都要走完整流程”

不需要。 改一行 CSS、修一个 typo，直接告诉 Claude 就行。Superpowers 的完整工作流适合50 行以上的功能开发和 Bug 修复。

误区2：“Superpowers 会消耗更多 Token”

短期看是的，长期看不是。 Brainstorming + TDD 多消耗 10-20% Token，但减少了 60-70% 的返工。算总账，Token 消耗反而降低。

误区3：“TDD 太慢了，我就想快速出个原型”

Superpowers 不是铁板一块。你可以只用 Brainstorming 和 Plan，跳过 TDD。

但建议：原型阶段跳过 TDD 没问题，正式开发一定要开。 原型的 bug 可以容忍，上线的 bug 容忍不了。

误区4：“装了 Superpowers AI 就变聪明了”

不会。 Superpowers 不改变 AI 的能力，只改变 AI 的行为方式。它让 AI 从"随机发挥"变成"按流程执行"。同样的模型，同样的能力，只是行为更规范。

误区5：“审查说什么我就改什么”

错误。 receiving-code-review 阶段鼓励你反驳不合理的审查建议。审查的黄金法则：技术正确性 > 社交舒适度。如果审查建议违反 YAGNI 原则，大胆反驳。

误区6：“用了多个平台，装一次就行”

不行。 每个编码工具需要单独安装一次。Claude Code 装了不代表 Cursor 也装了。

---

十四、三条铁律——记住就够了

14 个 Skill 看着晕？守住这 3 条铁律就能覆盖 80% 场景：

铁律1：没设计不写代码

不管需求多简单，哪怕"改个按钮颜色"，AI 也应该先确认改哪个文件、改哪个类。

违反后果：改了半天发现改的是编译后的文件，或改错了组件。

铁律2：没测试不写代码

先写失败测试，再写实现。

违反后果：写了一堆代码，逻辑复杂后完全不知道哪里出了问题，不敢动。

铁律3：没验证不说完成

声称完成前，必须跑一遍验证命令。

违反后果：本地跑不通，或上线后发现少了个依赖。

---

一句话总结：Superpowers 不是 14 个神奇的提示词，而是一套把软件工程最佳实践强制注入 AI 行为的约束系统。它用 brainstorming 强制需求澄清，用 TDD 强制质量底线，用 code-review 强制第二双眼睛，用 verification 强制结果导向。安装一行命令，技能自动触发，你什么都不用记。从"聪明的实习生"到"严谨的资深搭档"，差的就是这一套流程。