executing-plans 实战：AI 编程助手按计划逐任务执行，测试不绿不记账

设计做完、实现计划也写好了，最后一步「照着做」反而最容易烂尾：AI 编程助手做到第三个任务就开始自由发挥，跳过它觉得多余的测试，改了计划里没让改的代码，做完也不说哪些地方偏离了原案。obra/superpowers 仓库给这最后一步配了个纪律技能：executing-plans（执行计划）。它的核心原则一句话讲完——计划已经替你思考过了，执行就照着做，每一步用一个你亲眼看过失败、然后转绿的测试来证明，并留下一份能扛住你自己遗忘的记录。这篇教程按官方 SKILL.md 拆解：什么时候选内联执行、任务环怎么转、台账怎么记、终审怎么收，最后附一段本机实测——官方脚本在测试没转绿时真的会拒绝记账。

前置阅读可以看 brainstorming 技能实战（设计怎么磨出来）与 dispatching-parallel-agents（并行派发怎么用），三者同出 obra/superpowers（GitHub 29.6 万 star，MIT 协议，数字以 官方页面为准）。步骤与配图依据官方 SKILL.md 与技能自带脚本整理。

为什么要有「内联执行」这个选项

superpowers 的完整流水线是设计→计划→逐任务实现。逐任务实现有两种跑法：一种是 subagent-driven-development，每个任务派一个全新上下文的实现代理加一个审查代理；另一种就是本技能的内联执行——不派实现代理，你自己在当前会话里一个任务一个任务做完全部，只在最后安排一次整个分支的终审。

官方把这笔账算得很直白：子代理模式下，每个任务都要付一个全新实现者加一个全新审查者的钱，两者都得从零把代码库读一遍；内联执行只付一份上下文（你自己的）加最后一次审查。代价是丢掉了「每个任务的全新视角」和「每个任务的第二双眼睛」，而技能用四样东西把这两样买回来：简报当规格、台账当记忆、TDD 当每任务的闸、终审当第二双眼睛。所以官方明确建议：一份写得足够细的计划，内联执行就是「誊写加测试」，中档模型就跑得动；最该花钱的终审环节，再单独派最强模型。

什么时候不该选内联？SKILL.md 给了两个条件：合作者想要每个任务都有审查关卡，或者计划长到后半段任务会在被压缩过的上下文上跑。前者直接用 subagent-driven-development；后者硬跑也能跑——台账就是为恢复现场准备的——但官方提醒「最后几个任务拿到的是最差状态的你」。

全流程：Setup、任务环、终审、收尾

整个技能的流程图是四段式的，先把骨架立起来，后面逐段展开。

四阶段的官方规定动作与四条硬线，整理自 SKILL.md 的 The Process 一节

Setup 阶段干四件事：用 git worktree 隔离工作区（官方红线：没有合作者明确同意，不许在 main/master 分支上开工）；建台账；把计划和规格通读一遍，每个任务建一条 todo；做任务间接口冲突的预扫描。这里有个容易忽略的背景：会话被压缩后对话记忆会消失，一个忘了自己做到哪的内联执行者会重做已经提交过的任务——所以进度必须记在台账文件里，todos 只是实时视图，台账才是记录。

台账的路径有讲究：每个计划独占一个工作区，由 subagent-driven-development/scripts/sdd-workspace PLAN_FILE 脚本给出，落在仓库根的 .superpowers/sdd/<计划名>/ 下，台账文件是其中的 progress.md，首行写计划文件的路径作为身份标识。恢复现场时的判定规则也写在文档里：首行对得上本计划，凡有 Task <N>: complete 行的任务就是已完成的，从第一个没有完成行的任务接着做；首行是别的计划名，那是别人的进度，别动，自己另起。工作区与 subagent-driven-development 共用同一目录同一格式，所以一份计划跑到一半可以换执行者，新执行者从同一份台账续跑。

任务环阶段每个任务转一圈：取任务简报和 BASE 提交点，按计划的步骤顺序做（测试先写先跑，亲眼看它失败），每步的输出与计划里的 Expected: 行逐条比对，计划有错就地裁决并记台账，到计划的提交点就提交，任务收尾跑全任务测试。终审阶段把整个分支打包，派最强模型做全新上下文审查（没有子代理工具就自己按审查清单查，但要如实写「这是自查」）。收尾阶段把所有裁决和挂起项汇总给合作者，终审干净后删掉本计划的工作区——git 历史从现在起就是记录。

四条硬线：只有这些事能让你停下来问人

技能对「中途请示」态度极其克制，官方原话列了四条会停下的情形，四条之外一律连续执行：不可逆或破坏性操作；安全敏感动作；工作区之外按规范要先问的副作用（合并、推共享分支、发布）；计划烂到每条前路都是猜。

背后的逻辑不难理解：合作者选内联就是为了少花钱，如果每完一个任务都要回答一次「要继续吗」，省下的钱又变成了人的时间。反过来，遇到冲突、含糊、计划缺陷怎么办？技能的答案是「裁决，而不是卡住」——规格是最高权威，计划是它的论证，两者都没说清的，你的判断来定，但每个裁决都要按固定格式记进台账：Ruling: <决定了什么> — <为什么> — <错了的代价>。官方有句很重的话：没有记账的偏离，等于背着人做的决定。

本机实测：官方脚本真的「不绿不记账」

「A failing run records nothing」（失败的运行什么都不记）听起来像口号，但它其实是技能自带脚本的硬行为。技能目录下有两个脚本：task-start 负责取任务简报并记录 BASE 提交点，task-done 负责收尾记账。在一个演示 git 仓里装上这两个官方脚本、写一个两步的小计划，实际跑一遍。

实测全程：task-start 自动建工作区；测试未绿时 task-done 拒记账；转绿后完成行落进 progress.md

先跑 task-start plan.md 1：一条命令拿到两样东西——任务简报的文件路径和 BASE 提交点（评审查范围的起点），工作区目录 .superpowers/sdd/plan/ 由脚本自动创建，简报单独成文件，不占对话上下文。接着故意在测试还是红的状态下调 task-done：脚本报出测试错误后明确输出 task-done: test command exited 1; Task 1 NOT recorded——台账没写，完成行没落。把测试修绿再调一次，这次输出 2/2 pass，台账里多出一行：

# SDD ledger — plan: plan.md
Task 1: complete (commits 1531e9f..93d6f5c, tests: node fizzbuzz.test.js → 2/2 pass)

两行字就是台账的全部：首行是计划身份，第二行记录了任务号、提交区间、测试命令和结果。会话哪怕之后被压缩到什么都不记得，重读这两行就知道 Task 1 已完成、提交从哪到哪、用什么命令验证过。这正是官方说的「留下一份能扛住你自己遗忘的记录」——纪律不长在人身上，长在脚本里。

借口对照表：官方把偷懒的路都堵了

技能里最有性格的一节叫 Common Rationalizations，一张「借口 vs 现实」的对照表把执行者可能的每种偷懒都预先驳了一遍。挑几条常见的：

六条借口对照与三种台账行的官方格式

「我记得 Task N 写了什么」——你记的是摘要，简报里才有精确的值，去读简报。「最后跑一次全量测试就行」——逐步跑才知道是哪一步弄坏的，任务末的跑是交付契约不是替代品。「计划这里错了，我直接改对它」——可以做对的事，但要记裁决。「攒几个任务再一起记账」——压缩不会挑你方便的时刻发生，一任务一行，跟提交同一次调用写完。

最后一条也值得抄：测试应该过、改动又很小，就不用先写失败测试了吧？官方的回答是「应该」不是证据，交付契约要的是命令和它的输出。没有先失败过的测试，证明不了问题真的存在过、也证明不了它真的被修掉了——你手里只有一段 diff 和一个愿望。

终审：唯一的新眼睛，不许省

内联执行从头到尾只有一个人的视角，终审是整个流程唯一买到的「新眼睛」，所以官方把话说得很死：不许跳过，也不许拿自己再读一遍 diff 来顶替——同一个作者，同一批盲点。有子代理工具的，用 review-package 脚本打包整个分支，派给可用的最强模型，并且要显式指定模型（不指定就继承会话模型，可能不是最强的）；没有子代理工具的，读一遍审查技能的清单自己查，但要在台账里写明「自查」，并在最终消息里如实告知——自查比新视角弱，够不够由合作者定。

审查回来的发现要过一道「重估」再动手：审查者标的严重度只是建议，门槛是你自己定的。判断标准不是规格里有没有写，而是「普通用户拿到这个软件会得到什么」。重估之后，Critical 和 Important 进唯一一轮修复，每个修复都要先写复现测试、看它失败、修到通过、再跑全量；Minor 永不进修复轮，记进台账挂起，由合作者决定要不要处理。不修的发现也是裁决，照 Final: Ruling: 的格式记账。没有第二轮修复——每个修复都有失败测试和绿色套件背书，再派一次审查只是重读已被测试回答过的问题。

装好就能用

executing-plans 随 superpowers 技能库一起安装：Claude Code 用 /plugin install superpowers@claude-plugins-official，Gemini CLI 用 gemini extensions install https://github.com/obra/superpowers，Hermes Agent 用 hermes plugins install obra/superpowers --enable。技能在「合作者选定内联执行」或「运行环境没有子代理工具」时触发，前者的入口在 writing-plans 技能的交付环节，后者看平台参考清单。

一个已知限制值得提前知道：Hermes Agent 官方 README 里写明自家没有压缩后钩子，超长会话如果在第一轮就被压缩，引导会丢失，技能可能不再自动触发——遇到这种情况开个新会话即可。另外技能文档明确要求：动手前必须先加载 test-driven-development 技能，计划步骤里已经写了「先写失败测试」也不能豁免这一步。

本文步骤与配图依据 obra/superpowers 官方 executing-plans SKILL.md 及其自带脚本整理，实测部分来自本机演示仓与 Node 20 环境，版权归原作者所有。