夜雨聆风核心一句话：Superpowers 不是让 AI 变聪明，而是让 AI 变靠谱——它把软件工程最佳实践强制注入 AI 行为，从"聪明的实习生"变成"严谨的资深搭档"。
目录
痛点：AI 写代码为什么总让人不放心 Superpowers 是什么——一句话讲透本质 14 个 Skill 全览——不是工具箱，是流水线 四大设计哲学——为什么这套流程值得信 全平台安装指南——11 个 Agent 怎么装 自动触发机制——你不需要记任何命令 三大核心命令——手动控制流程的入口 完整实战走读——从模糊需求到代码合入 每个 Skill 深度拆解——触发时机、做什么、输出什么 进阶用法——并行、调试、审查的黄金法则 与其他 Skill 的对比——Superpowers vs planning-with-files vs everything 什么时候不需要 Superpowers 常见误区与避坑 三条铁律——记住就够了
一、痛点：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完整技能表：
| 测试 | |||
| 调试 | |||
| 调试 | |||
| 协作 | /superpowers:brainstorm | ||
| 协作 | /superpowers:write-plan | ||
| 协作 | /superpowers:execute-plan | ||
| 协作 | |||
| 协作 | |||
| 协作 | /superpowers:requesting-code-review | ||
| 协作 | |||
| 协作 | |||
| 协作 | |||
| 元技能 | |||
| 元技能 |
⚠️ 重要：代理在任何任务前都会先检查有没有相关技能可用。这些是强制的工作流，不是建议。
四、四大设计哲学——为什么这套流程值得信
Superpowers 背后有 4 条很朴素但很关键的原则：
| 测试优先 | ||
| 系统化胜过随手做 | ||
| 降低复杂度 | ||
| 用证据而非声称 |
这几条原则，正好是对抗 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（图形界面）
打开 Codex 应用 → 侧边栏点击 Plugins 在 Coding 区找到 Superpowers点击 +→ 按提示操作
5.3 Codex CLI
/plugins # 打开插件搜索界面# 输入 superpowers → 搜索# 选择 Install Plugin5.4 Cursor
/add-plugin superpowers# 或在插件市场搜索 "superpowers"5.5 Gemini CLI
gemini extensions install https://github.com/obra/superpowers# 更新gemini extensions update superpowers5.6 GitHub Copilot CLI
copilot plugin marketplace add obra/superpowers-marketplacecopilot plugin install superpowers@superpowers-marketplace5.7 Kimi Code
/plugins # 打开插件管理器# 进入 Marketplace → Superpowers → 安装# 或直接从仓库安装/plugins install https://github.com/obra/superpowers5.8 OpenCode
# 按照官方文档安装# https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md5.9 Antigravity
agy plugin install https://github.com/obra/superpowersAntigravity 运行插件的 session-start hook，Superpowers 从第一条消息即激活。
5.10 Factory Droid
droid plugin marketplace add https://github.com/obra/superpowersdroid plugin install superpowers@superpowers5.11 Pi
pi install git:github.com/obra/superpowersPi 原生支持 skills，无需兼容 Skill 工具。子代理和任务列表工具为可选的 Pi 伴随包。
验证安装是否成功
安装后在对应工具中输入：
/superpowers你应该能看到三个核心命令： - /superpowers:brainstorm—— 交互式设计细化 - /superpowers:write-plan—— 创建实现计划 - /superpowers:execute-plan—— 使用子代理执行计划
看到这三个命令就说明安装成功了。
六、自动触发机制——你不需要记任何命令
这是 Superpowers 最容易被忽视的特性：大部分 Skill 是自动触发的。
你照常说话，Superpowers 会在合适的时机自动激活：
你不需要说"请用 Superpowers"，正常提需求就行。
这是和很多其他 Skill 的关键区别：Superpowers 不是你要手动调用的工具，它更像是一个后台守护进程，在你需要的时候自动介入。
七、三大核心命令——手动控制流程的入口
虽然大部分自动触发，但三个关键节点需要你手动确认：
/superpowers:brainstorm
触发时机：任何超过 50 行代码的功能开发前
它做什么：不写代码，先变成产品经理对你进行"灵魂拷问"
你："帮我做个登录功能"Claude（使用 brainstorming）："我先用 brainstorming 技能来探索这个功能。让我问几个澄清问题：1. 这个登录功能加到哪个项目？还是全新项目？2. 技术栈？ → 前端 React，后端 Node.js3. 认证方式？ → 账密 + OAuth4. 数据库？ → 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-synccd .worktrees/inventory-syncnpm installnpm 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（子代理驱动开发）
触发：自动触发（当有可并行拆分的任务时）
做什么： - 为每个任务派发全新子代理 - 子代理只看到自己那一个任务的描述 - 两阶段审查：规格合规 + 代码质量 - 审查通过才标记完成
效果对比：
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：修复 → 改根因，而不是包一层 catchPhase4：验证 → 跑测试确认修复，检查没有引入新问题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-namecd .worktrees/feature-namenpm 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 reviewAI 会严格按工程标准执行。
技巧三：复杂项目必开 Git Worktrees
开发前主动要求：
用 git worktrees 隔离开发，避免影响主线安全试错，改崩直接丢弃，零风险。
技巧四：团队统一 AI 开发规范
全团队统一安装 Superpowers，实现： - 统一开发流程 - 统一代码规范 - 统一审查标准 - 降低沟通成本，提升交付质量
技巧五：长项目会话管理
即使有了 Superpowers，超长期项目（数周）仍可能积累上下文债务：
解决方案：1. 定期 /compact → 压缩历史对话，保留关键决策2. 文档化架构决策 → 让 Superpowers 在 Plan 阶段输出 ARCHITECTURE.md3. 使用 Git Worktree 隔离 → 每个大功能独立分支抹技巧六：与 VS Code 集成
1. 安装 Claude Code Extension2. VS Code 终端运行 claude 命令3. 查看 Superpowers 生成的代码和测试文件4. VS Code Git 面板管理 Superpowers 创建的 worktree 分支十一、与其他 Skill 的对比
Superpowers vs planning-with-files
| 定位 | ||
| 核心理念 | ||
| 解决的问题 | ||
| 技能数量 | ||
| 触发方式 | ||
| 含 TDD | ||
| 含 Code Review | ||
| 含 Git Worktree | ||
| 含子代理 | ||
| 最佳搭配 | 两者一起用 |
结论：两者互补不冲突。Superpowers 管流程，planning-with-files 管记忆。一起用效果最好。
Superpowers vs everything-claude-code
| 定位 | ||
| 包含内容 | ||
| 侧重点 | ||
| 适合谁 |
结论：两者也可以一起用。Superpowers 管流程纪律，everything-claude-code 提供工具能力。
Superpowers vs andrej-karpathy-skills
| 定位 | ||
| 核心理念 | ||
| 重叠 |
结论：karpathy-skills 更轻量更哲学，Superpowers 更系统更强制。轻度用户选 karpathy，重度开发选 Superpowers。
十二、什么时候不需要 Superpowers
任何工具都有边界。以下场景不建议使用：
| 一次性脚本 | ||
| 探索性原型 | ||
| 紧急Hotfix | ||
| 改一行CSS/修typo | ||
| 学习/实验 |
最适合的场景：长期维护的、团队协作的、复杂度较高的业务项目。
十三、常见误区与避坑
误区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 强制结果导向。安装一行命令，技能自动触发，你什么都不用记。从"聪明的实习生"到"严谨的资深搭档"，差的就是这一套流程。
