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-reviewreceiving-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。它不会写一行代码而是先变成产品经理对你进行“灵魂拷问”探索上下文它会读取你项目里的config.ts看现在的数据库连接方式看有没有现成的 HTTP 请求封装。逐个提问“上游 ERP 接口的鉴权方式是 Token 还是 API Key”“全量同步还是增量同步数据量大概多少”“同步失败的重试策略是什么指数退避”“报警是发给谁钉钉群 Webhook 地址有吗”提出方案方案 A写一个独立的 Node.js 服务用 Cron Job 触发。方案 B集成到现有的主程序里用 Bull 队列处理。输出设计文档等你确认了方案 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 个任务里定的变量命名规范了。新代理 全新的上下文 极高的专注度 更少的错误。每个任务的执行流程是一个闭环派代理 A 去实现只给它看任务 1 的描述派代理 B 去审查规格代码实现是否符合需求派代理 C 去审查质量代码风格、安全性、潜在 bug两个审查都通过任务标记为完成开始下一个任务在“库存同步”这个场景里负责“鉴权模块”的代理和负责“钉钉报警”的代理是完全隔离的互不干扰。第 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 test42 个测试全部通过0 失败。另外手动触发了一次同步日志显示正常。”它要求提供“新鲜证据”——必须是当前消息里刚刚运行的命令结果不能拿上个月的测试报告来糊弄人。033 条铁律记住就够了14 个 Skill 看着晕其实你只要守住这 3 条铁律就能覆盖 80% 的场景。铁律 1没设计不写代码不管需求多简单哪怕是“改个按钮颜色”AI 也应该先确认改哪个文件、改哪个类。违反后果改了半天发现改的是编译后的文件或者改错了组件。铁律 2没测试不写代码先写失败测试再写实现。违反后果写了一堆代码逻辑一复杂完全不知道哪里出了问题不敢动。铁律 3没验证不说完成声称完成前必须跑一遍验证命令。违反后果本地环境跑不通或者上线后才发现少了个依赖。04调试拒绝“盲人摸象”开发过程中难免遇到 Bug。这时候systematic-debugging就该上场了。最常见的反模式是“猜”★“报错了那我试试把这里改一下……不行那再改一下那里……”Superpowers 的调试流程是根因调查读取错误堆栈、复现问题、查看最近的 Git 提交、追踪数据流。模式分析找一段正常的代码对比当前的差异。假设验证提出一个假设“是不是数据库连接超时了”用最小改动去验证。实施修复先写一个能复现该 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阶段如果你发现审查意见违反了 YAGNIYou Arent 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 superpowerssuperpowers-marketplace重启后试着对 Claude 说“帮我规划一个功能”。如果它开始问你问题而不是直接生成代码恭喜你你的 AI 已经开始进化了。总结一下Superpowers 的本质不是 14 个神奇的提示词而是一套把软件工程最佳实践强制注入 AI 行为的约束系统。它用brainstorming强制需求澄清用TDD强制质量底线用code-review强制第二双眼睛用verification强制结果导向。它让 AI 从一个“聪明的实习生”变成了一个“严谨的资深搭档”。