Superpowers - 11 从计划到落地：深入解析 Superpowers 的「内联执行计划」工作流

文章目录

Pre
一、内联执行计划的定位：慢一点，但要"稳"
- [1.1 与 Subagent 驱动开发：一张表看清差异](#1.1 与 Subagent 驱动开发：一张表看清差异)
[二、三步走：审查 → 执行 → 完成](#二、三步走：审查 → 执行 → 完成)
- [2.1 阶段一：加载并审查计划------先别急着写代码](#2.1 阶段一：加载并审查计划——先别急着写代码)
- [2.2 阶段二：按序执行任务------计划即契约](#2.2 阶段二：按序执行任务——计划即契约)
- [2.3 阶段三：完成开发------从"能跑"到"准备好被审查"](#2.3 阶段三：完成开发——从“能跑”到“准备好被审查”)
三、遇阻时停下：请求澄清，而不是硬猜
四、在整条开发流水线中的位置：三大必选集成点
- [4.1 从计划到执行：如何"交接"](#4.1 从计划到执行：如何“交接”)
[五、真实案例：执行一份 1096 行的大型计划](#五、真实案例：执行一份 1096 行的大型计划)
六、从命令到技能：执行方式的演进
七、实践建议：如何在你的团队中落地内联执行计划
总结

Pre

Superpowers - 01 让 AI 真正"懂工程"：Superpowers 软件开发工作流深度解析

Superpowers - 02 用 15 个技能给你的 AI 装上「工程大脑」：Superpowers 快速开始深度解析

Superpowers - 03 一文搞懂 Superpowers：面向多平台 AI 编码助手的安装与实践指南

Superpowers - 04 从"会写代码"到"会做工程"：Superpowers 工作流引擎架构深度剖析

Superpowers - 05 构建一个"会自己找插件用"的 Agent：深入解析 Superpowers 的技能发现与激活机制

Superpowers - 06 从文档到"结构契约"：Superpowers 技能剖析与 Frontmatter 深度解读

Superpowers - 07 从 SessionStart Hook 看 Superpowers：把「技能库」变成「行为操作系统」

Superpowers - 08 在 AI 时代重写「需求评审会」：深入解读 Superpowers 的头脑风暴与设计规范机制

Superpowers - 09 从构思到落地：如何用「计划编写与任务粒度」驾驭 AI 时代的软件开发

Superpowers - 10 用 Subagent 驱动开发，把「AI 写代码」变成一条严谨的生产流水线

面向读者：有一定实践经验的开发者、架构师、技术负责人，以及正在尝试用 AI 辅助完整软件开发流程的研究者。

软件工程里，"写计划"比"执行计划"容易得多 。

当你开始让 AI 帮你写设计文档、拆分任务、生成代码时，这个落差会被无限放大：一份看起来很漂亮的计划，真正执行起来却问题百出------步骤含糊、依赖缺失、测试不通过、上下文混乱。

Superpowers 提出的 executing-plans 技能，就是为了解决这个落差：它不是一个"写计划"的工具，而是一个把计划稳稳落地的执行引擎，在单一会话里，按任务顺序、严格验证、透明可审查地把一份书面计划变成可运行、可合并的代码。

本文将围绕这篇文档展开，系统解析：

为什么需要"内联执行计划"而不是一味追求自动化的 Subagent 驱动开发
executing-plans 的三阶段执行模型：审查 → 执行 → 完成
阻碍处理与"请求澄清，而非靠猜测"的工程哲学
它在 Superpowers 整体开发流水线中的位置与集成点
一个真实计划的执行示例，以及从命令式到"技能化"的演进趋势

一、内联执行计划的定位：慢一点，但要"稳"

Superpowers 在计划完成后提供两条执行路径：

Subagent 驱动开发：每个任务交给新的 subagent，自动审查、快速迭代，是"默认推荐"的生产路径；
内联执行计划 (executing-plans)：在单个会话中顺序执行任务，强调人工可见、可控、可审查，是刻意保留的一条"慢而稳"的路径。

文档对 executing-plans 的定位非常明确：

当 平台没有 subagent 能力、
当你 刻意希望人工紧密监督每个任务、
当 执行计划的会话与编写计划的会话不同，需要完整再理解与复核时，

内联执行就是正确选择。

同时，文档也直言不讳：

当 subagent 可用时，推荐使用 Subagent-Driven Development，且"代码质量将显著更高"。

这意味着：内联执行不是性能退而求其次的"阉割版"，而是为特定场景设计的"守正"方案------在一些需要高可控性、强监督的环境里，它反而是更安全的选项。

1.1 与 Subagent 驱动开发：一张表看清差异

一张对比表，从上下文模型、审查机制、平台要求等维度解释两者的权衡：

维度	内联执行 (`executing-plans`)	Subagent 驱动 (`subagent-driven-development`)
上下文模型	单一连续会话	每个任务启用全新 subagent
审查机制	依赖人工在检查点审查	自动化两阶段审查（规范 + 质量）
平台要求	任意兼容 Claude 的平台即可	需要 subagent 支持（Claude Code、Codex 等）
迭代速度	较慢（任务间需要人工批准）	较快（由自动化审查循环驱动）
错误隔离	上下文在任务间持续累积，错误可能随上下文扩散	按任务隔离，每个任务独立上下文
适用场景	学习场景、教学演示、受控实验、平台能力受限的环境	正式生产开发、复杂或大型计划实施

从工程实践角度看，你可以简单理解为：

Subagent 驱动开发 更像是"流水线式 CI/CD + 多工位合作"的自动化工厂；
内联执行计划 更像是"资深工程师亲自按 checklist 一步步带徒弟做"的工作模式。

内联执行的价值，在于它让你可以看见每一步，并在关键节点停下来问"这一步真的对吗？"------对学习、调试、规范建设极其有利。

二、三步走：审查 → 执行 → 完成

executing-plans 将一个"从计划到代码"的过程拆成了三大阶段：加载并审查计划 → 按序执行任务 → 完成开发 。

每个阶段都有明确的进入条件和退出条件，目的就是防止常见的失败模式：带病执行、跳过验证、遇阻硬顶等。

2.1 阶段一：加载并审查计划------先别急着写代码

在接触任何代码之前，Agent 必须做的第一件事，是从 docs/superpowers/plans/ 中读取完整的计划文档，并进行严格审查。

这个审查并不是"走个过场"，而是第一道防线：

是否有歧义描述？
是否有步骤缺失？
任务结构是否完整、统一？
验证步骤是否明确、可操作？

如果审查通过：

Agent 会创建一个 TodoWrite 对象，记录所有任务，并以此为执行清单。
然后才真正进入执行阶段。

如果审查不通过：

Agent 必须暂停执行，把疑问抛给人工伙伴，直到问题被修正或澄清。

这一步与 writing-plans 技能中的自审规范呼应："计划写完后先自查一遍，再交给执行者。"

而在 executing-plans 这边，执行者变成了第二道审查者，再次审视计划是否可执行。

这背后有个很重要的观念："计划是可执行文档，而不是展示用幻灯片。"

它必须写到"可以让一个没有上下文的新 Agent 按图索骥完成实现"，否则就不是好计划。

2.2 阶段二：按序执行任务------计划即契约

进入执行阶段后，每个任务都必须遵循一个四步协议：

标记任务为 in_progress ：

明确告诉人工伙伴"我正在做这个任务"。这既是状态同步，也是为后续审计提供线索。
严格按照步骤执行 ：

计划中的每个步骤被刻意拆成 2--5 分钟可完成的小块，是有明确设计意图的：
- 方便人工理解与审查
- 方便在出错时快速回溯到具体步骤
- 强制避免"我大致懂了，直接跳着干"的习惯
按规范执行验证命令 ：

每个任务都携带明确的验证命令与预期输出，例如：
- 运行：pytest tests/path/test.py::test_name -v
- 预期：PASS
  Agent 必须：
- 真正执行这些命令
- 对比实际输出与预期
- 如果不匹配，任务视为未完成，不得进入下一步
验证通过后才标记任务完成 ：

没有验证，就没有"完成"两个字。

文档用一句很强硬的话概括这一点：

计划即契约。

也就是说：

执行者不能随意决定"这个验证没必要跑"。
不能凭主观感觉判定"看起来没问题，就算完成"。
更不能跳过计划里的某一步，即便你是人类工程师。"聪明的偷懒"在这个模型里会被视作违反契约。

另外，writing-plans 在设计任务结构时，就要求步骤具有 "零上下文可执行性"：

每步要写清：要改哪些文件、写什么逻辑、运行哪些命令、预期输出如何。
不假定执行者拥有隐形上下文或额外知识。

这让 executing-plans 可以在全新的会话里，仅凭计划文档就完成实现，极大增强了可移交性。

2.3 阶段三：完成开发------从"能跑"到"准备好被审查"

所有任务都执行并通过验证后，executing-plans 并不会就此结束。

它会将控制权移交给 superpowers:finishing-a-development-branch 这个必需子技能。

finishing-a-development-branch 的职责包括：

再次运行测试，确保分支处于"健康可运行"状态
选择合适的基础分支
给出合并选项：
- 本地合并
- 创建 Pull Request
- 保留分支不合并
- 丢弃分支
清理 git worktree，防止残留半成品工作区

这一步其实是在完成一个重要的"仪式转变"：

从"测试通过的工作分支代码"
变成"可以进入团队流程、接受 review、准备上线的代码"

如果你把整个流程想象成一个 CI/CD pipeline，那么 executing-plans 负责的是"从计划到可跑代码"的这段，而 finishing-a-development-branch 则负责"从可跑代码到团队流程接入"的最后一跳。

三、遇阻时停下：请求澄清，而不是硬猜

executing-plans 中最有工程味的一节，是它对"阻碍处理"的严格规范。

文档列举了几种典型阻碍场景，并给出了明确的强制动作：

触发条件	必须执行的操作
缺少依赖项	立即停止，通知人工，等待指示
执行期间测试失败	停止，展示失败输出，停止推进
计划中的指令不明确	停止，向人工请求澄清
验证反复失败	停止，提交证据并升级处理

并用一句话总结了设计原则：

"请求澄清，而非靠猜测。"

这里有几个关键点值得展开：

一切非预期情况，都不允许"先往前凑合走走看"
- 如果依赖缺失，继续写代码也是白费力气；
- 如果测试失败，忽略它只会导致后続任务以错误状态为前提。
阻碍是反馈，不是噪音

文档强调：
- 一份看起来完美的计划，很多问题只有在执行时才会暴露。
- 执行者对这些阻碍的反馈，是改进未来计划质量的重要输入。
- 因此，阻碍不是"烦人的异常"，而是整个工作流的一部分。
阻碍解决后要回到阶段一（审查），而不是从中途硬接上

这是一个非常细腻的点：
- 当计划被修改或澄清后，整体上下文已经发生变化；
- 继续从某个中间任务切入，很容易忽略前后关联约束；
- 回到阶段一重新审查，是保证一致性的保守做法。

工程实践中，这种设计体现的是一种非常成熟的态度：

"不要强行突破阻碍。"

不硬撑，不赌，不拍脑袋。

对于在生产环境引入 AI 辅助开发的团队来说，这一原则可以极大降低"静悄悄的灾难"发生概率------那些看似无害的小猜测，往往在几轮迭代后演变成根本性设计错误。

四、在整条开发流水线中的位置：三大必选集成点

executing-plans 并不是一个孤立技能，而是嵌在 Superpowers 的完整工作流里。

它有三个强制集成点，共同构成一个闭环开发周期：

集成点	作用	为什么是必需的
`superpowers:using-git-worktrees`	在任何代码更改前设置隔离工作空间	防止污染主分支，提供干净回滚点
`superpowers:writing-plans`	创建结构化、可执行的计划文档	计划格式即契约：前置元数据头、任务结构、验证步骤
`superpowers:finishing-a-development-branch`	处理实施后的分支生命周期	确保测试通过，明确合并策略，清理 worktree

这三个点，基本覆盖了工程实践中的黄金路径：

开始前，先把工作区隔离好
- 使用 git worktree 为每个任务分支创建独立工作目录；
- 避免在主分支上"直接开干"的坏习惯；
- 方便随时回滚、不影响其他并行开发。
真正执行前，先把计划写好
- 不再"边想边写边改"，而是在进入执行前形成一个足够细致的任务分解；
- 计划中显式标注"执行方式头部元数据"： REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task.
- 这让任何后续会话，都能自动根据计划指示选择正确执行技能。
执行结束后，要把阶段性成果纳入团队流程
- 不遗留半成品分支，不在 repo 里留下"不知道能不能用"的代码；
- 所有"执行完成"的定义都包含了：测试通过 + 分支策略明确 + 工作区干净。

4.1 从计划到执行：如何"交接"

结合 writing-plans 流程交接的具体方式：

在"计划编写与任务粒度"流程的末尾，writing-plans 会明确给出两个执行选项：
- Subagent 驱动（推荐，若平台支持）；
- 内联执行（当需要或平台受限时）。
当选择内联执行时，一个新的"执行会话"会启动：
- 它从计划文档头部的元数据读到执行建议；
- 然后调用 executing-plans 并进入"三阶段"流程。

这意味着：

计划本身携带了"如何执行我"的 meta 信息。

它不再是"静态文档"，而是"自描述的工作流入口"。

对于团队协作来说，这种设计的好处在于：

执行者可以是另一个人、另一台机器、另一个时间点，但只要拿到这份计划，就知道应该怎么安全地执行它；
执行路径可以根据平台能力和团队偏好灵活调整，而无需从头到尾重写计划本身。

五、真实案例：执行一份 1096 行的大型计划

一份类似 OpenCode 支持实施的计划文档，长达 1096 行，包含分阶段任务、确切文件路径和完整代码块。

executing-plans 的处理方式大致如下：

加载计划
- 读取 docs/superpowers/plans/2025-11-22-opencode-support-implementation.md；
- 把所有阶段、所有任务结构化为待办列表。
审查计划结构
- 确认包含目标、架构说明、技术栈、任务文件路径、带复选框的步骤等；
- 如果结构不符合规范，直接在阶段一暂停。
从任务 1 开始执行
- 按规范创建 lib/skills-core.js 并实现 extractFrontmatter 函数；
- 运行对应测试；
- 验证结果是否满足"预期：PASS"的条件。
继续执行所有任务
- 每个任务都单独执行、验证；
- 每个任务通常对应一次提交，便于后续审查与回滚。
完成阶段：移交给 finishing-a-development-branch
- 由完成技能负责最终合并决策与 worktree 清理。

这段示例和 Subagent 驱动开发的最大区别在于：

内联执行的整个过程发生在同一个连续会话；
人类可以实时观察进度，并在任意检查点插手；
不需要调度额外的 implementer subagent 或 spec 审查者，流程更线性、更直观。

对于刚开始尝试将 Superpowers 引入团队开发流程的团队来说，这样的线性模型更易于理解和落地，也更适合作为"建立规范"的起点。

六、从命令到技能：执行方式的演进

一个看似细节、实际很有意义的改变：

旧的 commands/execute-plan.md 斜杠命令已经废弃；
新的推荐方式是直接调用 superpowers:executing-plans 这个技能；
旧命令如果被触发，会引导用户转向使用新技能。

这背后的趋势是：

从"命令式调用"逐渐过渡到"可发现、可组合的技能系统"。

命令更接近于"脚本入口"，而技能则：

带有 Frontmatter、清晰的描述与使用约束；
支持被其他技能引用，形成工作流图谱；
更利于被 IDE、平台或上层 orchestrator 自动发现和调度。

从工程视角看，这是 Superpowers 从"高级工具集"演进为"可编排平台"的关键一步------executing-plans 作为其中的核心执行技能，也显然被设计成一个可复用、可组合的积木。

七、实践建议：如何在你的团队中落地内联执行计划

结合文档中的设计思想，如果你希望在自己的工程实践中引入类似的"内联执行计划"模型，可以考虑下面几个步骤：

建立"计划即契约"的共识
- 任何可交付的计划必须写清：
  - 任务拆分
  - 修改点路径
  - 验证命令
  - 预期输出
- 不写清就不能进入执行环节。
把"审查计划"变成正式步骤，而不是口头约定
- 明确谁负责初次审查（计划作者自查），
- 谁负责二次审查（执行者或代码 owner），
- 审查不过就不允许执行。
执行时强制"先验证后完成"
- 在代码评审模板或 CI 流程中加入规则：
  - 没有验证记录的任务不能标记为 Done；
  - 每个任务的测试命令与结果要可追踪。
遇阻就停：为"请求澄清"预留通道
- 在项目协作工具里（Issue/PR/Task）给执行者明确权限：
  - 任何阻碍都可以暂停当前任务，并新建"澄清任务"；
  - 完成澄清后重新从"审查计划阶段"开始，而不是强行续命。
分离"实现阶段"和"完成阶段"
- 实现阶段的完成定义是：本地测试通过 + 计划中的所有任务已执行；
- 完成阶段则包括：
  - 再跑一遍流水线测试
  - 决定合并策略
  - 清理临时分支与工作目录
- 这可以减少"工作分支堆满仓库"的常见问题。

如果你使用 Superpowers 本身，那么遵循文档中的集成方式即可：

先 using-git-worktrees，
再 writing-plans，
然后在合适场景下选择 executing-plans，
最后交给 finishing-a-development-branch 收尾。

总结

executing-plans 看上去只是一个"在单会话里顺序执行计划"的技能，实则承载着一套完整的工程观：

计划是契约：必须包含足够的执行细节与验证步骤；
执行要可审查：单一会话、显式状态、明确检查点；
阻碍是重要信号：遇到就停，先问清楚再继续；
完成不等于合并：还需要一个专门的"完成阶段"把代码纳入团队工作流；
从命令到技能：整个系统正以"技能"为基本单位被组织和扩展。

如果你关心的是"如何和 AI 一起做严肃的软件工程"，而不仅仅是"让 AI 写点代码片段"，那么这篇文档背后的思想，值得仔细阅读、在团队内讨论，并逐步融入你自己的开发规范中。