90%的人只用了Superpowers 10%的能力，实战案例带你走通全流程

装了Superpowers还是不会用？这套完整工作流，让你的AI从“工具”变“搭档”

你可能已经在 GitHub 上给 Superpowers 点过 Star 了，甚至在本地环境里跑了一遍安装流程。

但说实话，你大概率只触发了其中一两个 Skill——写代码时偶尔触发 TDD，调试时偶尔触发 systematic-debugging，剩下 90% 的时间，你还是在用最原始的方式：“直接让 AI 干活”。

这不是你的问题，也不是 Superpowers 不好用。

Superpowers 包含 14 个 Skill，每个都写得非常详尽，但很多教程只告诉你“它是什么”，却没告诉你“怎么把它们串成一条完整的开发流水线”。

今天这篇文章，我想从实战视角，完整讲清楚一件事：从你提出一个模糊需求，到代码顺利合入主分支，Superpowers 的 14 个 Skill 是如何一步步接管你的开发流程的。

看完这篇，你会明白为什么有人说“Superpowers 让 AI 像资深工程师一样自主工作”——这不是玄学，是一套严密的工程逻辑。

01

先看全貌：这不是工具箱，是流水线

很多人把 Superpowers 当成了一个瑞士军刀，里面装了 14 个工具，需要哪个切哪个。

其实理解错了。Superpowers 是一套有严格先后顺序的开发流水线。

这 14 个 Skill 不是并列关系，而是接力关系。上一个 Skill 的输出，必须是下一个 Skill 的输入。

为了让你有个直观印象，我把这 14 个 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）

你不需要死记硬背这 14 个名字，你只需要记住：这是一条防止 AI 偷懒走捷径的流水线。

02

完整实战：从需求到上线的 7 步走

光说概念太虚，我们换个更贴近真实业务的场景，把这套流程跑一遍。

假设我们要给一个电商后台系统开发一个新功能：「商品库存实时同步服务」。

需求背景：系统需要定时从上游 ERP 接口拉取库存数据，更新本地数据库，如果库存低于阈值，自动发送钉钉报警。

看看 Superpowers 怎么带着我们把这件事做漂亮。

第 1 步：brainstorming — 别急着动手

如果你直接跟 Claude 说：“帮我写一个库存同步服务”，它大概率会直接甩给你一段带 while(true) 循环的代码，看着能用，但全是坑。

Superpowers 会先触发 brainstorming。它不会写一行代码，而是先变成产品经理对你进行“灵魂拷问”：

1. 探索上下文：它会读取你项目里的 config.ts，看现在的数据库连接方式，看有没有现成的 HTTP 请求封装。
2. 逐个提问：
   • “上游 ERP 接口的鉴权方式是 Token 还是 API Key？”
   • “全量同步还是增量同步？数据量大概多少？”
   • “同步失败的重试策略是什么？指数退避？”
   • “报警是发给谁？钉钉群 Webhook 地址有吗？”
3. 提出方案：
   • 方案 A：写一个独立的 Node.js 服务，用 Cron Job 触发。
   • 方案 B：集成到现有的主程序里，用 Bull 队列处理。
4. 输出设计文档：等你确认了方案 A，它会生成一份 docs/superpowers/inventory-sync-spec.md。

这一步的价值：防止方向性错误。哪怕是一个 5 分钟能写完的脚本，设计阶段可能只需要 3 句话——但这 3 句话能让你少返 3 次工。

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

设计定稿后，自动进入 writing-plans。

这一步的目标是：把“库存同步”这个大需求，拆解成一个 AI 代理在 2-5 分钟内绝对能搞定的小任务。

它会生成这样的计划：

• 任务 1：实现 ERP 接口鉴权模块
  • [ ] 写失败测试：错误的 Token 应该抛出 401 错误
  • [ ] 实现 getAuthToken 函数
  • [ ] 运行测试确认通过
  • [ ] 提交代码
• 任务 2：实现库存数据拉取
  • [ ] 写失败测试：接口返回空数组时处理逻辑
  • [ ] 实现 fetchInventory 函数，处理分页
  • [ ] 运行测试确认通过
  • [ ] 提交代码
• 任务 3：实现本地数据库更新
  • [ ] 写失败测试：并发更新时的锁机制
  • [ ] 实现 updateLocalStock 函数
  • [ ] ...

注意细节：这个计划是写给“一个技术很强、但对你的项目一无所知的陌生人”看的。

所以计划里不能写“添加验证”，必须写“在 src/services/inventory.ts 第 45 行添加 if (!token) throw new Error()”。

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

执行计划前，Superpowers 会先触发 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 — 代理流水线

这是 Superpowers 最核心的“黑魔法”。

对于上面拆解的每一个小任务，它会启动一个全新的 AI 代理来处理。

为什么是“新代理”？因为 AI 的上下文窗口是有限的。如果你在一个聊天窗口里连续聊 10 个任务，到第 5 个任务时，AI 已经“忘了”你第 1 个任务里定的变量命名规范了。

新代理 = 全新的上下文 = 极高的专注度 = 更少的错误。

每个任务的执行流程是一个闭环：

1. 派代理 A 去实现（只给它看任务 1 的描述）
2. 派代理 B 去审查规格（代码实现是否符合需求？）
3. 派代理 C 去审查质量（代码风格、安全性、潜在 bug？）
4. 两个审查都通过，任务标记为完成
5. 开始下一个任务

在“库存同步”这个场景里，负责“鉴权模块”的代理和负责“钉钉报警”的代理是完全隔离的，互不干扰。

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

每个代理在干活时，必须遵循严格的 TDD 循环：

• RED：先写一个必定失败的测试，运行，看到红灯。
• GREEN：写最少的代码让测试通过，运行，看到绿灯。
• REFACTOR：重构代码，保持绿灯。
• 重复。

Superpowers 对这一步非常严格，甚至有点“强迫症”：

• 你说：“这个逻辑太简单了，不用测了吧？” -> 不行。
• 你说：“我先写个实现看看效果，回头补测试。” -> 不行。
• 你说：“我只是想试一下 API 怎么调用。” -> 不行，去看文档，别写代码。

为什么？因为 AI 是最擅长“走捷径”的。一旦你允许它先写实现，它绝对不会回头写测试。这套铁律不是限制你，是限制 AI 的惰性。

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

代码写完了，并不算完。Superpowers 会安排两轮“过堂”。

第一轮：请求审查

派一个独立的审查代理，只看代码变更，不看你的聊天记录。它会按严重度分级：

• Critical：比如 SQL 注入风险、硬编码的密码。必须修。
• Important：比如变量命名不清、逻辑冗余。应该修。
• Minor：比如注释格式、尾随空格。记下来。

第二轮：接收审查

这一步最反直觉，也最重要：不是审查说什么你就改什么。

Superpowers 会要求你验证每一条意见。

• 如果审查建议“加个缓存”，但你知道这个数据实时性要求极高，你要反驳。
• 如果审查建议用“递归”，但数据量大可能栈溢出，你要反驳。

审查的黄金法则：技术正确性 > 社交舒适度。不要为了迎合审查者而引入 bug。

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

最后一步，是很多开发者容易翻车的地方。

错误示范：

★用户：“代码改完了吗？” AI：“改完了，应该没问题。”（潜台词：我没跑，但我感觉是对的）

Superpowers 的要求是：

★用户：“代码改完了吗？” AI：“我运行了 npm test，42 个测试全部通过，0 失败。另外手动触发了一次同步，日志显示正常。”

它要求提供“新鲜证据”——必须是当前消息里刚刚运行的命令结果，不能拿上个月的测试报告来糊弄人。

03

3 条铁律，记住就够了

14 个 Skill 看着晕？其实你只要守住这 3 条铁律，就能覆盖 80% 的场景。

铁律 1：没设计不写代码不管需求多简单，哪怕是“改个按钮颜色”，AI 也应该先确认改哪个文件、改哪个类。

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

铁律 2：没测试不写代码先写失败测试，再写实现。

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

铁律 3：没验证不说完成声称完成前，必须跑一遍验证命令。

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

04

调试：拒绝“盲人摸象”

开发过程中难免遇到 Bug。这时候 systematic-debugging 就该上场了。

最常见的反模式是“猜”：

★“报错了？那我试试把这里改一下……不行？那再改一下那里……”

Superpowers 的调试流程是：

1. 根因调查：读取错误堆栈、复现问题、查看最近的 Git 提交、追踪数据流。
2. 模式分析：找一段正常的代码，对比当前的差异。
3. 假设验证：提出一个假设（“是不是数据库连接超时了？”），用最小改动去验证。
4. 实施修复：先写一个能复现该 bug 的测试，修复根因，看着测试变绿。

它有一个“3 次规则”：如果你连续 3 次修复尝试都失败了，说明问题可能出在架构层面。这时候 Superpowers 会建议你停下来，去找人讨论，而不是继续死磕。

05

并行：什么时候该多管齐下？

dispatching-parallel-agents 这个技能很酷，但不是什么时候都能用。

适合并行的场景：

• “库存同步”服务里，你需要同时写“ERP 接口适配器”和“钉钉报警模块”，这两个互不干扰。
• 修复 3 个完全不相关的 Bug。

绝对不能并行的场景：

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

记住：并行是为了效率，不是为了制造冲突。

06

那些不为人知的细节

最后，分享几个只有长期使用者才会发现的细节：

细节 1：计划是给“陌生人”看的在 writing-plans 阶段，一定要写得越细越好。因为执行计划的代理对你的项目一无所知，它不知道你的 utils/db.js 在哪，你必须告诉它“在 src/database/connection.ts 第 10 行导入”。

细节 2：鼓励反驳在 receiving-code-review 阶段，如果你发现审查意见违反了 YAGNI（You Aren't Gonna Need It）原则，大胆反驳。Superpowers 希望培养的是有主见的工程师，不是唯唯诺诺的实习生。

细节 3：新鲜证据verification-before-completion 非常严格。你不能说“刚才跑过了”，必须在当前回复里贴出运行日志。因为代码可能在你验证之后又被谁改了。

07

什么时候不需要 Superpowers？

任何工具都有边界。为了不浪费你的时间，我不建议在以下场景使用它：

• 一次性脚本：比如写个 Python 脚本批量重命名文件，写完就扔，TDD 反而是负担。
• 探索性原型：你还在尝试技术选型，不确定能不能做出来，brainstorming 会让你觉得卡顿。
• 紧急 Hotfix：线上的火着了，先止血，回头再补流程。

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

08

如何开始？

如果你想在本地试一试，配置其实很简单：

# Claude Code 安装
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

重启后，试着对 Claude 说：“帮我规划一个功能”。

如果它开始问你问题，而不是直接生成代码，恭喜你，你的 AI 已经开始进化了。

总结一下

Superpowers 的本质，不是 14 个神奇的提示词，而是一套把软件工程最佳实践强制注入 AI 行为的约束系统。

它用 brainstorming 强制需求澄清，用 TDD 强制质量底线，用 code-review 强制第二双眼睛，用 verification 强制结果导向。

它让 AI 从一个“聪明的实习生”，变成了一个“严谨的资深搭档”。