本文面向已经在用或准备用 coding agent 做工程的开发者。不吹AI 写代码很厉害只讲一件事Superpowers 到底是怎么把软件工程方法论编译成技能、让 Agent 从会写码变成有纪律以及它留给我们的那个没人填的坑——串行执行。开场AI 编码不缺会写代码的 Agent缺工程纪律过去一年coding agent 的进步让人误以为给 Agent 一个需求它就会像资深工程师一样干活。真实情况是裸 Agent 写代码没有章法。它会在你还没想清楚需求时就开始写它不写测试它不读现有代码结构它声称完成但从不验证一个改动可能破坏三个模块。这不是能力问题是纪律问题。就像让一个绝顶聪明但从不守规矩的程序员直接上生产代码库——他写得出漂亮代码也埋得下漂亮的雷。Superpowers由 Jesse Vincent 和 Prime Radiant 团队维护github.com/obra/superpowers要解决的正是让 Agent 有工程纪律这件事。它不教 Agent 写代码——它给 Agent 装上了一套完整的软件开发方法论并且用技术手段强制Agent 遵守。一、架构三层引导层、技能层、工具层Superpowers 的架构可以拆成三层理解这三层就理解了它为什么有效。1. 引导层using-superpowers —— 让技能自动触发的 bootstrap这是整套体系最容易被忽略、却最关键的一环。Superpowers 不是一个技能文件夹它是一套在会话启动时注入的引导程序。它的作用机制harness 在 SessionStart 注入using-superpowersskill这段引导指令做了一件事——告诉 Agent任何时候只要有一个技能可能适用于你正在做的事你就必须先调用它没有例外。这意味着技能不是给用户用的工具而是Agent 运行时自动加载的行为约束。Superpowers 官方在贡献指南里说得很直白没有这个 bootstrap技能就只是磁盘上的死文件——存在但永远不会被调用。你可以把它理解成代码中的__init__它定义了 Agent 处理一切任务的默认行为协议。2. 技能层14 个技能四族分工Superpowers 的核心是 14 个技能v6.2.0按职责分四族族技能职责测试test-driven-developmentRED-GREEN-REFACTOR 纪律调试systematic-debugging、verification-before-completion根因定位 验证真的修好了协作brainstorming、writing-plans、executing-plans、dispatching-parallel-agents、requesting-code-review、receiving-code-review、using-git-worktrees、finishing-a-development-branch、subagent-driven-development需求→计划→执行→审查→收尾 全链路元writing-skills、using-superpowers如何写技能、如何用技能注意协作族占了 9 个——Superpowers 的真正重点不在写代码而在把软件的协作过程流程化。3. 工具层worktree 隔离、子代理隔离、ledger 记忆技能只是指令真正让指令落地的是三个配套机制git worktree 隔离每次功能开发都在独立的 worktree 分支上进行主分支永远干净。子代理上下文隔离每个任务派发一个干净的子代理它只拿到自己任务所需的上下文不继承主会话的历史——既防止上下文污染也保护主会话的上下文预算。ledgerprogress.md持久化SDD 用.superpowers/sdd/plan/progress.md记录每个任务的完成状态。这不是给用户看的是给 Agent 自己看的——会话压缩后Agent 靠 ledger 而不是记忆恢复进度。二、实战一个需求从想法到合入Superpowers 是怎么管的架构讲完看真实的执行链路。Superpowers 官方 README 定义的标准流程是 7 步Step 1brainstorming —— 先想清楚再动手你抛出一个想法Agent不会立刻写代码。它会像苏格拉底对话一样一个问题一个问题地问你把模糊想法磨成明确需求。设计确认后才写成设计文档。它强制了什么HARD-GATE—— 在用户批准设计之前禁止调用任何实现技能、禁止写任何代码。这条铁律挡掉了 Agent 最常见的毛病抢跑。Step 2using-git-worktrees —— 隔离工作区设计批准后先建隔离的 worktree 和分支跑项目 setup验证测试基线是绿的。脏基线会让之后所有失败都变得不可归因所以必须先确认起点干净。Step 3writing-plans —— 把设计翻译成可执行的步骤这是把设计文档变成实现计划。要求极端具体每个任务 2-5 分钟粒度每个步骤包含精确文件路径、完整代码、验证步骤。计划是为一个热情的初级工程师写的——他对代码库一无所知、审美可疑、厌恶测试。计划文档有严格格式Header目标/架构/技术栈/全局约束 任务列表Files / Interfaces / 逐步 TDD 步骤。Step 4subagent-driven-development —— 子代理逐任务执行SDD 是这个体系的核心执行机制。每个任务派一个全新子代理上下文隔离实现 自测 提交然后派一个任务审查者同样是独立子代理做双段审查规格符合性 代码质量。发现问题进修复循环最多 5 轮。这里有一句原文值得记住后面会反复用到Never dispatch multiple implementation subagents in parallel (conflicts). ——subagent-driven-development 明令禁止并行派发实现子代理。Step 5test-driven-development —— 先写测试实现阶段强制 RED-GREEN-REFACTOR先写失败的测试 → 看着它失败 → 写最小实现 → 看着它通过 → 提交。测试先行不是最佳实践是纪律——先于测试写的代码会被删除。Step 6requesting-code-review —— 任务间审查每个任务完成后审查按严重度分级。Critical 阻塞进度。Step 7finishing-a-development-branch —— 收尾全部任务完成最终全分支审查用最强模型跑测试然后给你三个选项合并 / 开 PR / 保留分支。收尾后清理 worktree。三、它到底强在哪三个支撑机制抛开具体流程Superpowers 的有效性来自三个底层机制① 上下文隔离每个子代理只拿到它该知道的。执行任务的子代理看不到主会话的历史审查者看到的只是 diff 包。这防止了两件事上下文污染Agent 把不相干的历史带进决策和主会话上下文爆炸主会话只管协调不装实现细节。② 证据驱动验证通过才算完成不是口号。TDD 要求先看测试失败再看它通过verification-before-completion 要求你演示证据最终审查要过审查者。Agent 无法靠我认为没问题过关——必须拿出可复现的证据。③ 过程可恢复ledger git 历史让 Agent 在会话压缩、甚至崩溃后都能从progress.md恢复进度而不是靠记忆重来。这是为长周期自主工作设计的。四、问题一台优秀的单需求执行引擎却不是多需求调度系统现在到了本文的重点。Superpowers 把一个需求从想法到交付做到了极致但它有一个结构性的、被大多数教程忽略的缺陷Superpowers 是单需求执行引擎不是多需求调度系统。翻译成人话它一次只能老老实实跑完一个需求你没法在它跑 A 需求的同时讨论 B 需求。问题 1需求与实现强耦合Superpowers 的流程是需求 A 进来 → brainstorm → 设计 → 计划 → 实现 → 验收 → 结束 → 才能开需求 B。整个生命周期里主会话被需求 A 占住。你想趁它实现 A 的时候讨论 B做不到——因为流程模型里没有 B 的位置。这就是用户最真实、最痛的体感每次只能等着当前迭代完成然后再进入下一轮需求讨论。问题 2SDD 明令禁止并行SDD 的规则原文已经写明了Never dispatch multiple implementation subagents in parallel (conflicts). 这不是疏忽是刻意的设计取舍——多个实现子代理同时改代码会互相踩踏、制造冲突、让审查失去意义。为了避免踩踏Superpowers 选择了串行。但这是有代价的串行意味着吞吐上限 单需求的完成时间。需求越多等待越久。问题 3dispatching-parallel-agents 只覆盖调试场景有人会说Superpowers 不是有 dispatching-parallel-agents 吗。对但它解决的问题域完全不同。看它的触发条件Use when facing 2 independent tasks that can be worked on without shared state or sequential dependencies它针对的是调试场景——多个独立的测试文件同时挂了各派一个子代理去修修 A 不影响修 B。它解决的是多个独立故障不是多个独立需求。需求的实现往往共享代码库、共享模块、有依赖关系——这正是它明确说Dont use when的场景。所以Superpowers 有并行修 bug的能力但没有并行开发多个需求的能力。问题 4缺一整套调度层能力具体列一下Superpowers 缺什么❌没有需求 backlog——需求不能先存起来再说必须当下做完。❌没有跨需求依赖分析——需求 A 依赖需求 B 没人管反正一个个来。❌没有冲突检测——需求 A 和需求 C 语义冲突同样没人管。❌没有并发上限管理——不是上限 0串行而是根本没有并发这个概念。❌没有调度视角的报告——你永远看不到哪些需求现在能并行跑、哪些在等谁、哪些有冲突。定性串行不是 bug是取舍——但它就是吞吐瓶颈必须公平地说串行是 Superpowers主动选择的取舍。它优先保证正确性不踩踏、可审查、可回滚牺牲了吞吐。对一个小团队、一个小需求这完全正确。但当需求积累到两位数、当你想一边跑 A 一边聊 B、当你希望多个独立需求并行推进时——取舍就变成了瓶颈。而解决问题的方向也很清晰Superpowers 已经把执行引擎做到位了问题不在执行在调度。缺的是一层多需求调度器叠在它上面。结语给执行引擎装一个调度器Superpowers 是好东西——它把 Agent 从会写码变成了有纪律地写码。但它的纪律是单线程的纪律。真实研发不是单线程的需求有优先级、有依赖、有冲突、可以并行。下一篇我会讲我们在这台执行引擎上叠的一层调度器——wdp-prd。它不做 Superpowers 已经做好的事只做它没做的事把需求变成持久化卡片用依赖/冲突算法算出现在谁能并行、谁在等谁、谁有冲突然后交给 Superpowers 去执行。下一篇给 Superpowers 套一层调度器wdp-prd
本文面向已经在用或准备用 coding agent 做工程的开发者。不吹AI 写代码很厉害只讲一件事Superpowers 到底是怎么把软件工程方法论编译成技能、让 Agent 从会写码变成有纪律以及它留给我们的那个没人填的坑——串行执行。开场AI 编码不缺会写代码的 Agent缺工程纪律过去一年coding agent 的进步让人误以为给 Agent 一个需求它就会像资深工程师一样干活。真实情况是裸 Agent 写代码没有章法。它会在你还没想清楚需求时就开始写它不写测试它不读现有代码结构它声称完成但从不验证一个改动可能破坏三个模块。这不是能力问题是纪律问题。就像让一个绝顶聪明但从不守规矩的程序员直接上生产代码库——他写得出漂亮代码也埋得下漂亮的雷。Superpowers由 Jesse Vincent 和 Prime Radiant 团队维护github.com/obra/superpowers要解决的正是让 Agent 有工程纪律这件事。它不教 Agent 写代码——它给 Agent 装上了一套完整的软件开发方法论并且用技术手段强制Agent 遵守。一、架构三层引导层、技能层、工具层Superpowers 的架构可以拆成三层理解这三层就理解了它为什么有效。1. 引导层using-superpowers —— 让技能自动触发的 bootstrap这是整套体系最容易被忽略、却最关键的一环。Superpowers 不是一个技能文件夹它是一套在会话启动时注入的引导程序。它的作用机制harness 在 SessionStart 注入using-superpowersskill这段引导指令做了一件事——告诉 Agent任何时候只要有一个技能可能适用于你正在做的事你就必须先调用它没有例外。这意味着技能不是给用户用的工具而是Agent 运行时自动加载的行为约束。Superpowers 官方在贡献指南里说得很直白没有这个 bootstrap技能就只是磁盘上的死文件——存在但永远不会被调用。你可以把它理解成代码中的__init__它定义了 Agent 处理一切任务的默认行为协议。2. 技能层14 个技能四族分工Superpowers 的核心是 14 个技能v6.2.0按职责分四族族技能职责测试test-driven-developmentRED-GREEN-REFACTOR 纪律调试systematic-debugging、verification-before-completion根因定位 验证真的修好了协作brainstorming、writing-plans、executing-plans、dispatching-parallel-agents、requesting-code-review、receiving-code-review、using-git-worktrees、finishing-a-development-branch、subagent-driven-development需求→计划→执行→审查→收尾 全链路元writing-skills、using-superpowers如何写技能、如何用技能注意协作族占了 9 个——Superpowers 的真正重点不在写代码而在把软件的协作过程流程化。3. 工具层worktree 隔离、子代理隔离、ledger 记忆技能只是指令真正让指令落地的是三个配套机制git worktree 隔离每次功能开发都在独立的 worktree 分支上进行主分支永远干净。子代理上下文隔离每个任务派发一个干净的子代理它只拿到自己任务所需的上下文不继承主会话的历史——既防止上下文污染也保护主会话的上下文预算。ledgerprogress.md持久化SDD 用.superpowers/sdd/plan/progress.md记录每个任务的完成状态。这不是给用户看的是给 Agent 自己看的——会话压缩后Agent 靠 ledger 而不是记忆恢复进度。二、实战一个需求从想法到合入Superpowers 是怎么管的架构讲完看真实的执行链路。Superpowers 官方 README 定义的标准流程是 7 步Step 1brainstorming —— 先想清楚再动手你抛出一个想法Agent不会立刻写代码。它会像苏格拉底对话一样一个问题一个问题地问你把模糊想法磨成明确需求。设计确认后才写成设计文档。它强制了什么HARD-GATE—— 在用户批准设计之前禁止调用任何实现技能、禁止写任何代码。这条铁律挡掉了 Agent 最常见的毛病抢跑。Step 2using-git-worktrees —— 隔离工作区设计批准后先建隔离的 worktree 和分支跑项目 setup验证测试基线是绿的。脏基线会让之后所有失败都变得不可归因所以必须先确认起点干净。Step 3writing-plans —— 把设计翻译成可执行的步骤这是把设计文档变成实现计划。要求极端具体每个任务 2-5 分钟粒度每个步骤包含精确文件路径、完整代码、验证步骤。计划是为一个热情的初级工程师写的——他对代码库一无所知、审美可疑、厌恶测试。计划文档有严格格式Header目标/架构/技术栈/全局约束 任务列表Files / Interfaces / 逐步 TDD 步骤。Step 4subagent-driven-development —— 子代理逐任务执行SDD 是这个体系的核心执行机制。每个任务派一个全新子代理上下文隔离实现 自测 提交然后派一个任务审查者同样是独立子代理做双段审查规格符合性 代码质量。发现问题进修复循环最多 5 轮。这里有一句原文值得记住后面会反复用到Never dispatch multiple implementation subagents in parallel (conflicts). ——subagent-driven-development 明令禁止并行派发实现子代理。Step 5test-driven-development —— 先写测试实现阶段强制 RED-GREEN-REFACTOR先写失败的测试 → 看着它失败 → 写最小实现 → 看着它通过 → 提交。测试先行不是最佳实践是纪律——先于测试写的代码会被删除。Step 6requesting-code-review —— 任务间审查每个任务完成后审查按严重度分级。Critical 阻塞进度。Step 7finishing-a-development-branch —— 收尾全部任务完成最终全分支审查用最强模型跑测试然后给你三个选项合并 / 开 PR / 保留分支。收尾后清理 worktree。三、它到底强在哪三个支撑机制抛开具体流程Superpowers 的有效性来自三个底层机制① 上下文隔离每个子代理只拿到它该知道的。执行任务的子代理看不到主会话的历史审查者看到的只是 diff 包。这防止了两件事上下文污染Agent 把不相干的历史带进决策和主会话上下文爆炸主会话只管协调不装实现细节。② 证据驱动验证通过才算完成不是口号。TDD 要求先看测试失败再看它通过verification-before-completion 要求你演示证据最终审查要过审查者。Agent 无法靠我认为没问题过关——必须拿出可复现的证据。③ 过程可恢复ledger git 历史让 Agent 在会话压缩、甚至崩溃后都能从progress.md恢复进度而不是靠记忆重来。这是为长周期自主工作设计的。四、问题一台优秀的单需求执行引擎却不是多需求调度系统现在到了本文的重点。Superpowers 把一个需求从想法到交付做到了极致但它有一个结构性的、被大多数教程忽略的缺陷Superpowers 是单需求执行引擎不是多需求调度系统。翻译成人话它一次只能老老实实跑完一个需求你没法在它跑 A 需求的同时讨论 B 需求。问题 1需求与实现强耦合Superpowers 的流程是需求 A 进来 → brainstorm → 设计 → 计划 → 实现 → 验收 → 结束 → 才能开需求 B。整个生命周期里主会话被需求 A 占住。你想趁它实现 A 的时候讨论 B做不到——因为流程模型里没有 B 的位置。这就是用户最真实、最痛的体感每次只能等着当前迭代完成然后再进入下一轮需求讨论。问题 2SDD 明令禁止并行SDD 的规则原文已经写明了Never dispatch multiple implementation subagents in parallel (conflicts). 这不是疏忽是刻意的设计取舍——多个实现子代理同时改代码会互相踩踏、制造冲突、让审查失去意义。为了避免踩踏Superpowers 选择了串行。但这是有代价的串行意味着吞吐上限 单需求的完成时间。需求越多等待越久。问题 3dispatching-parallel-agents 只覆盖调试场景有人会说Superpowers 不是有 dispatching-parallel-agents 吗。对但它解决的问题域完全不同。看它的触发条件Use when facing 2 independent tasks that can be worked on without shared state or sequential dependencies它针对的是调试场景——多个独立的测试文件同时挂了各派一个子代理去修修 A 不影响修 B。它解决的是多个独立故障不是多个独立需求。需求的实现往往共享代码库、共享模块、有依赖关系——这正是它明确说Dont use when的场景。所以Superpowers 有并行修 bug的能力但没有并行开发多个需求的能力。问题 4缺一整套调度层能力具体列一下Superpowers 缺什么❌没有需求 backlog——需求不能先存起来再说必须当下做完。❌没有跨需求依赖分析——需求 A 依赖需求 B 没人管反正一个个来。❌没有冲突检测——需求 A 和需求 C 语义冲突同样没人管。❌没有并发上限管理——不是上限 0串行而是根本没有并发这个概念。❌没有调度视角的报告——你永远看不到哪些需求现在能并行跑、哪些在等谁、哪些有冲突。定性串行不是 bug是取舍——但它就是吞吐瓶颈必须公平地说串行是 Superpowers主动选择的取舍。它优先保证正确性不踩踏、可审查、可回滚牺牲了吞吐。对一个小团队、一个小需求这完全正确。但当需求积累到两位数、当你想一边跑 A 一边聊 B、当你希望多个独立需求并行推进时——取舍就变成了瓶颈。而解决问题的方向也很清晰Superpowers 已经把执行引擎做到位了问题不在执行在调度。缺的是一层多需求调度器叠在它上面。结语给执行引擎装一个调度器Superpowers 是好东西——它把 Agent 从会写码变成了有纪律地写码。但它的纪律是单线程的纪律。真实研发不是单线程的需求有优先级、有依赖、有冲突、可以并行。下一篇我会讲我们在这台执行引擎上叠的一层调度器——wdp-prd。它不做 Superpowers 已经做好的事只做它没做的事把需求变成持久化卡片用依赖/冲突算法算出现在谁能并行、谁在等谁、谁有冲突然后交给 Superpowers 去执行。下一篇给 Superpowers 套一层调度器wdp-prd
