executing-plans

执行计划

概述

加载计划，进行严格审查，分批执行任务，并在批次之间汇报以供审查。

核心原则： 分批执行，并设置检查点供架构师审查。

开始时声明：“我正在使用 executing-plans 技能来实施此计划。”

流程

第 1 步：加载并审查计划

1. 完整阅读计划文件
2. 严格审查计划——在问题造成高昂的返工成本之前发现它们。留意以下情况：
   • 步骤含糊或相互矛盾
   • 缺少依赖项或设置
   • 实际代码库中不成立的假设
   • 值得质疑的技术选择
3. 如果有疑虑：继续之前先与合作伙伴沟通。现在达成共识，可以避免之后花费数小时做无用功
4. 如果计划看起来可靠：创建待办事项跟踪表，然后进入第 2 步

第 2 步：执行批次

默认：每批执行前 3 项任务

由检查点驱动的方法（执行 3 项任务，暂停征求反馈，然后继续）能让合作伙伴了解进展，避免在有问题的基础上继续构建。

对于批次中的每项任务：

1. 在跟踪表中将其标记为 in_progress
2. 严格按照计划中的步骤执行——这些步骤的设计目标是小而可验证
3. 标记为完成前，先运行指定的验证——尽早发现错误
4. 如果验证失败：停止、汇报并等待指示
5. 如果验证通过：标记为已完成，然后继续下一项任务

专注做好当前工作。与其盲目执行 10 项任务、半途才发现方向错了，不如先做好 3 项任务并征求反馈。

第 3 步：汇报

批次完成后，清楚地汇报：

• 展示已实施的内容（变更、新文件、修改的代码）
• 展示验证输出（测试结果，以及任何错误消息）
• 总结意外发现或与计划的细微偏差
• 以以下文字结束：“已准备好接收反馈。”

暂停并汇报至关重要。这能让合作伙伴在你投入更多工作之前纠正方向。

第 4 步：继续

合作伙伴会回复。他们可能会：

• 批准并要求你继续（执行下一批次）
• 指出问题并要求修改（返回第 1 步或第 2 步）
• 根据新信息更改计划（返回第 1 步）

遵循他们的指示。这个循环（执行 → 汇报 → 反馈 → 继续）可以避免偏离方向。

完成所有批次并获得合作伙伴批准后，进入第 5 步（完成开发）。

第 5 步：完成开发

所有任务完成并通过验证后，最终确定分支。验证所有测试均通过，确保工作区干净，然后向用户提供以下选项：合并到 main、创建 PR，或保留分支以供进一步审查。

• 最后再运行一次完整测试套件
• 确认没有未跟踪或未提交的更改
• 询问用户：现在合并、创建 PR，还是留待手动审查

何时停止并寻求帮助

遇到以下情况时，应暂停执行并请求澄清：

• 在批次执行过程中遇到阻碍（缺少依赖项、测试失败、指示不明确）——盲目继续会浪费精力
• 计划存在妨碍开始执行的关键缺陷——无法执行不存在的内容
• 不理解某项指示——询问比猜测更快
• 验证反复失败——这表明计划可能基于错误假设

为何这很重要： 尽早停止可以避免浪费精力，并让合作伙伴提供正确的指导。暂停澄清比在错误的基础上继续构建更高效。

何时重新审视前面的步骤

在以下情况下返回审查（第 1 步）：

• 合作伙伴根据你的反馈更新了计划——之前的审查不再适用
• 需要重新思考根本方法——新信息改变了策略

强行排除阻碍会造成技术债务。 暂停重新考虑，比之后修正错误更快。

牢记

• 首先严格审查计划
• 严格按照计划步骤执行
• 不要跳过验证
• 计划要求参考技能时，务必参考
• 每批次之间：只汇报并等待
• 遇到阻碍时停止，不要猜测
• 未经用户明确同意，绝不要在 main/master 分支上开始实施

常见陷阱

Agent 跳过审查，立即开始执行

问题： 直接跳到步骤 2（执行批次），没有先完成步骤 1（加载并审查计划）。这样会错过发现计划缺陷的机会，导致白费功夫。

原因： 执行比阅读感觉更有成效；“先开始再说”的冲动很强。

如何避免： 强迫自己阅读计划、记录问题，并在将第一个任务标记为 in_progress 之前提出这些问题。审查阶段是防止返工的最佳时机。

批次过大导致混乱

问题： 试图在一个批次中执行 10 项以上的任务，很难追踪已完成的工作、受阻的事项以及验证失败的位置。这样会失去检查点的作用。

原因： 想要快速推进，或误将“默认：前 3 项任务”理解为最低数量，而不是安全默认值。

如何避免： 每批次坚持执行 3 项任务，除非计划明确另有说明。汇报并获得反馈后，你就能判断是否应该扩大批次。批次越小，汇报越清晰，反馈循环越快。

忽略验证失败

问题： 验证失败（测试未通过、输出与预期不符），但你仍将任务标记为已完成并继续推进。问题会不断累积，因为后续任务依赖前面的任务正常运行。

原因： 急于“标记完成”并继续推进。验证被误认为可有可无的润色。

如何避免： 验证失败时，任务就尚未完成。停止本批次，汇报失败情况并等待指导。计划可能存在缺陷，或者你可能误解了某个步骤。你的协作者需要知道。

执行过程中计划过时

问题： 执行到一半时，协作者意识到计划需要更新（范围变更、技术选择有误、发现新的阻碍），但你仍继续执行旧计划。

原因： 你专注于眼前的任务，没有意识到计划已被取代。

如何避免： 每次汇报批次后，仔细阅读协作者的回复。如果对方提到计划变更，即使你已经执行到一半，也要返回步骤 1（审查）。更新后的背景信息比一味向前推进更重要。

集成

相关工作流技能：

• writing-plans — 生成本技能要执行的计划。本技能假定已有结构完善的计划；如果需要创建计划，请先参考该技能。
• brainstorming — 生成供 writing-plans 使用的设计。完整工作流为：运行 brainstorming → writing-plans → executing-plans。

Git worktree 提示： 执行计划之前，可以考虑在隔离的 git worktree 中运行，这样你的工作就与 main 隔离：

git worktree add ../feature-work -b feature/my-feature

这样可以避免在 main 上发生意外，也能让你轻松放弃失败的实验。