古法编程

当你的 AI 编码平台不支持子代理（Subagent）机制时，executing-plans 是执行实现计划的 fallback 方案。它让 AI 在单个会话内按顺序执行计划中的任务，并用严格的人工检查点替代自动审查：遇到任何指令不清、阻塞或验证失败都会立即停止并请求澄清，确保执行过程可靠可控。本文将详解 executing-plans 的完整流程、与 subagent-driven-development 的选择逻辑，以及如何将其无缝嵌入 Superpowers 的 writing-plans 与 finishing-a-development-branch 工作流。

executing-plans 与 subagent-driven-development 怎么选：没有子代理时的计划执行流程

在 Superpowers 工作流中，完成头脑风暴和编写计划后，就进入了关键的执行阶段。此时，Superpowers 提供了两种核心执行技能：subagent-driven-development（子代理驱动开发，简称 SDD）和 executing-plans（执行计划）。选择错误的技能会导致执行效率低下或质量失控。本文将明确两者的核心差异、选择标准，并重点拆解当平台不具备子代理能力时，executing-plans 如何提供一套严格、可靠的单会话执行方案。

核心差异与平台选择策略

选择哪种技能，根本上取决于你的 AI 编码平台是否支持子代理（Subagent） 机制。

subagent-driven-development：子代理支持的黄金路径

SDD 是 Superpowers 推荐的执行路径。它要求平台能够派发独立的、拥有干净上下文的子代理来执行单个任务。其核心优势在于自动化和高质量门禁：

  1. 派发子代理：为计划中的每个任务，派发一个全新的子代理。
  2. 两阶段审查：每个子代理任务完成后，自动触发两轮审查：首先是规格合规审查（代码是否符合计划要求），然后是代码质量审查。
  3. 连续执行：只有在两轮审查都通过后，才进入下一个任务。

目前，像 Claude Code 和 Codex 这样的平台支持这种能力，因此应优先使用 SDD。

executing-plans：无子代理时的可控回退

当你的平台不具备子代理能力，或者任务之间高度耦合、需要你人工精细控制节奏时，就应选择 executing-plans。

一个明确的判断依据来自 Gemini CLI 的工具映射文档。其中指出，Gemini CLI 没有与 Claude Code 的 Task（子代理派发）工具完全等价的功能。因此，在 Gemini CLI 上尝试使用 SDD 时，工作流会自动降级，转而通过 executing-plans 来执行计划。这使 executing-plans 成为在特定平台上的唯一可靠选项。

简单决策流程：

  1. 你的 AI 编码平台（如 Claude Code）支持子代理吗？
    • 是 → 优先使用 subagent-driven-development。
    • 否（如 Gemini CLI、普通对话界面） → 使用 executing-plans。
  2. 即使平台支持子代理，但任务高度耦合、需要你频繁在关键节点介入？ → 也可以考虑使用 executing-plans 以获得更精细的控制。

executing-plans 的完整执行流程详解

executing-plans 的设计哲学是批判性审阅和遇阻立停。在没有自动审查的情况下，它通过强制性的流程和人工检查点来保障执行质量。

第一步：宣布意图并批判性审阅计划

AI 会首先宣布：“I‘m using the executing-plans skill to implement this plan.” 紧接着，它不是立刻执行，而是加载计划文件并进行严肃的审阅。

这一步的核心是“像人类开发者一样思考”。AI 会主动检查：

  • 计划中的指令是否存在模糊或矛盾？
  • 任务之间的依赖关系是否清晰定义？
  • 有没有明显的遗漏？（例如，某个任务依赖一个尚未在之前任务中创建的接口）

如果发现问题：AI 会立即暂停，向你（人工伙伴）清晰指出疑虑，等待你的确认或修正计划。这直接对应了技能文件中的要求：“If concerns: Raise them with your human partner before starting”。 如果没有问题：AI 会创建一个任务列表（如 TodoWrite），然后进入执行阶段。

第二步：逐任务顺序执行，严格遵守验证

AI 将按顺序处理计划中的每个任务，对每个任务执行以下固定步骤：

  1. 标记任务开始：将当前任务状态标记为 in_progress。
  2. 精确执行：严格按照计划中描述的“一口大小”（bite-sized）步骤执行，不跳过任何步骤，也不自作主张增减逻辑。
  3. 运行验证：执行计划中为该任务指定的验证命令（如运行特定测试、检查输出结果）。
  4. 标记任务完成：验证通过后，标记任务为 completed，然后进入下一个任务。

“遇阻立停”：强制停止的规则

这是 executing-plans 最关键的质量控制机制。技能文件明确列出了必须立即停止的几种情况：

  • 遇到阻塞：例如缺少依赖库、测试持续失败、指令无法理解。
  • 计划存在关键缺陷，导致当前任务根本无法开始。
  • 不理解某条指令。
  • 验证步骤反复失败。

在这些情况下，AI 必须主动停下，并执行“Stop and Ask for Help”。它需要清晰地描述：卡在哪里、已经尝试了什么、需要什么信息或决策。然后等待你的指令。技能强调“Ask for clarification rather than guessing”，严禁 AI 猜测或强行推进。

第三步：完成开发分支收尾

当计划中的所有任务都已执行并验证通过后，AI 会宣布进入收尾流程：“I‘m using the finishing-a-development-branch skill to complete this work.”

随后，它必须调用 superpowers:finishing-a-development-branch 这个子技能。该技能会执行以下操作（基于其源文件）：

  1. 验证测试：首先在最终状态下运行项目的测试套件，确保所有测试通过。如果测试失败，则必须停止并报告。
  2. 检测环境：判断当前是在普通仓库还是在由 using-git-worktrees 创建的隔离工作树中。
  3. 呈现选项：向你提供结构化的集成选项（例如：合并回主分支、推送并创建 PR、保留分支、丢弃工作）。
  4. 执行选择：根据你的选择执行相应的 Git 操作和清理工作。

这一步强制保证了任何开发工作的完整闭环，防止半成品被遗留。

与上游、下游技能的强制衔接

executing-plans 并非孤立存在，它的输入和输出都由其他技能严格约束，共同构成完整的功能开发流水线。

  • 上游输入：writing-plans executing-plans 执行的“弹药”——计划文件，来源于 writing-plans 技能。后者负责产出详细、无占位符、包含具体代码和验证步骤的可执行计划。在计划编写完成后，writing-plans 的流程中会明确给出执行选项，其“Execution Handoff”部分指出：“Two execution options: 1. Subagent-Driven (recommended) … 2. Inline Execution … Which approach?”。如果选择“Inline Execution”，则直接触发 executing-plans。

  • 强制前置：using-git-worktrees executing-plans 的技能文件在“Remember”部分强调：“Never start implementation on main/master branch without explicit user consent.” 因此，在开始执行前，必须使用 using-git-worktrees 技能（或等效操作）创建一个隔离的开发分支和工作目录，这是防止污染主分支的硬性要求。

  • 强制后续：finishing-a-development-branch 如前所述，这是执行流程的最后一个强制环节，确保工作被妥善集成或处置。

何时选择 executing-plans

总结来说，在以下场景中，executing-plans 是合适甚至唯一的选择：

  1. 你的 AI 编码平台（如 Gemini CLI）明确不支持子代理派发功能。
  2. 你需要在一个隔离的会话中执行计划，而不是在当前负责协调的“主会话”内。
  3. 任务之间高度耦合，你需要人工在关键节点介入、审查中间产物或控制执行节奏。
  4. 你更倾向于一种轻量级、人工参与度更高的执行模式。

尽管 executing-plans 缺乏 subagent-driven-development 那样强大的自动两阶段审查，但通过严格的计划审阅、遇阻立停的规则以及强制性的收尾流程，它为在不支持子代理的平台上执行计划提供了一套可靠且可控的方案。它将质量控制的责任更多地从自动化转移到了计划的质量和人工检查点的有效性上。

FAQ

Q: 如何准确判断我的平台是否支持子代理？ A: 查看平台的官方文档或工具列表。如果平台提供了类似 Task、subagent、Dispatch 或允许你派发一个具有独立上下文的代理去执行子任务的功能，则支持。例如，Gemini CLI 的文档会说明其子代理支持方式。如果没有此类功能，则应使用 executing-plans。

Q: 使用 executing-plans 执行时，AI 频繁停下来请求澄清，怎么办？ A: 这是一个强烈的反馈信号，表明上游的 writing-plans 产出的计划文件质量不足，其中存在模糊、矛盾或遗漏。正确的做法是暂停执行，返回并重新审视、细化计划，解决这些问题后再从头或从受影响的任务处重新开始执行。

Q: 没有自动的双阶段审查，如何保证代码质量？ A: 质量保证主要依赖两个支柱：一是 writing-plans 中为每个任务设定的具体、可运行的验证步骤（如“运行此测试命令并确认输出”）；二是你在 “遇阻立停”检查点所做出的人工判断。虽然不如自动审查严谨，但“遇阻立停”原则能有效防止错误被掩盖或带病运行。

Q: 执行过程中发现计划有根本性错误，能修改计划吗？ A: 可以，而且应该修改。根据 executing-plans 的流程，当发现基础方法需要重新思考，或者你根据 AI 的反馈更新了计划后，应该让 AI 返回到“第一步：加载并批判性审阅计划”，确保它对更新后的计划理解保持一致，然后再继续执行。