按检查点执行计划

LingCode 的速度足以在一次连续运行中完成多步骤计划。这感觉像是一场胜利，直到你在最后读到 diff 时才发现问题。

当没有中途检查点时，会发生三件事：

• 架构偏差会累积。第 2 步选择了一个略微错误的模式。第 3 步在此基础上继续构建。到第 8 步时，每个文件都围绕着错误的模式成型，而修复它意味着要重做八个步骤，而不是一个。发现第 2 步错误的正确时机，就是第 2 步完成之后。
• 审查疲劳随之而来。审查一个文件很容易。坐下来一次性审查四十个由 AI 编写的文件则令人精疲力竭，你会不可避免地略读。略读的审查会放过 bug。
• 你失去了廉价的回滚机会。如果第 3 步（共 12 步）出了问题，回退一个步骤轻而易举。但如果问题藏在"这个 40 文件的 diff 某处"，你要么接受全部，要么从头再来。

检查点是解药：在每个计划步骤（或每对相关步骤）之后，LingCode 停下来，总结它做了哪些更改，然后等待你确认才继续。代价是小小的中断。回报是在回退还只需一次撤销时就发现偏差。

• 仓库中的计划文件。如果还没有，请先阅读使用 LingCode 编写实施计划。计划是检查点检验的依据。
• 干净的工作区。提交（或暂存）所有无关的工作。你希望检查点的 diff 只显示 LingCode 在当前步骤所做的更改。
• 可运行的测试。即使覆盖率很低，你也需要一个"测试通过"的基线，这样逐步验证才有参照。如果测试套件在开始前就已经损坏，先修复它。

告诉 LingCode 逐步执行计划，并在每步之后停下来。默认行为是一路推进；你必须明确地选择退出这种模式：

Execute IMPLEMENTATION_PLAN.md one step at a time.

After each step:
1. Summarize what you changed (files touched, behavior before
   vs. after) in 3-5 lines.
2. Run the verification specified for that step in the plan.
   Paste the actual output, not "looks good."
3. Stop and wait for me to confirm before starting the next
   step. Do not roll into the next step.

If a step fails verification, stop and diagnose — don't move on
hoping a later step will fix it. If the plan is wrong, propose
a plan amendment rather than silently deviating.

Start with step 1.

这三条规则——总结、验证、停下来——就是整个技巧的精髓。本教程的其余内容是关于当 LingCode 偏离这些规则时如何把它拉回来。

当 LingCode 提交检查点摘要时，先读摘要。将其与计划中这一步骤应该完成的内容进行比对。

• 与计划一致？略读 diff 确认一下，然后批准。
• 做的比计划多？提出异议。"第 2 步应该只是添加数据库列。你还添加了 API 端点——那是第 3 步的内容。请回退该端点，让我单独批准它。"超出范围的工作隐藏在检查点内，是最常见的偏差模式。
• 做的比计划少？询问缺少了什么。有时 LingCode 遇到了意外的依赖关系并悄悄跳过；你需要让这个问题浮出水面，而不是被忽略。
• 做了不同的事？暂停进行真正的审查。要么计划需要修改（明确修订），要么更改需要回退。

每个计划步骤都应该指定了验证方式——请参阅计划编写教程了解原因。在检查点处，运行（或让 LingCode 运行）那个精确的命令，并查看实际输出。

"看起来没问题"不是验证。"xcodebuild test -scheme MyApp 以退出码 0 完成，47 个测试通过，0 个失败"才是。要求后者。

如果验证失败，你已经在问题出现的确切步骤捕获了它。现在就诊断，在第 N+1 步在其上继续构建之前。

当检查点通过——摘要与计划一致，验证结果为绿色——单独提交该步骤：

git add -A
git commit -m "Step 2: Add user_quota table and migration"

按检查点提交有三个好处：

• 回滚变得轻而易举。如果第 5 步事后证明有问题，对单个提交执行 git revert，而不是在四十个文件中逐一剥离。
• 为审查者提供清晰的叙事。PR 显示为按顺序排列的八个提交，与八个计划步骤一一对应。比一个巨大的 diff 容易跟进得多。
• 为 LingCode 的上下文提供锚点。当你说"回到第 4 步结束时的状态"，有一个真实的提交可以重置到。

大约有一半的时候，执行计划的过程会让你发现计划需要更改。这没问题——但修订本身是一个单独的步骤。

当 LingCode（或你）注意到计划需要更改时：

Don't deviate silently. Update IMPLEMENTATION_PLAN.md to
reflect the new approach for steps 5-8, explain in 2 lines
why we're changing course, and commit just the plan edit:

git commit -m "Amend plan: switch step 5 from REST to GraphQL
because the existing schema is already exposed there"

Then wait for me to confirm before continuing execution.

计划是你的契约。当契约发生变化时，要以书面形式记录并获得签认——而不是顺带地夹在代码提交里。

如果检查点揭示最后一步是错误的——方法不对、验证失败、范围蔓延——要审慎地恢复：

1. 回退提交。执行 git revert HEAD，或者如果尚未推送且想要干净的历史记录，执行 git reset --hard HEAD~1。
2. 如果步骤本身有问题，更新计划。原始计划把你引到了这里；如果不修订它，你会再次回到同一个地方。
3. 重新运行该步骤。现在从已知的良好状态出发，带着修正后的指令。

这正是检查点存在的意义。没有检查点，"回退一步"根本不是一个选项——错误的代码与七个其他正确步骤的代码混在一起，无法分离。

当最后一个计划步骤通过检查点时，工作就完成了——但还需要再验证一件事：

• 端到端运行整个计划的验证。每个步骤都验证了自身；现在确认它们组合在一起也没问题。"每个测试单独通过"并不总是意味着"整个测试套件一起通过"。
• 重新阅读计划的非目标。确保在整个运行过程中没有范围蔓延。中途的范围蔓延在检查点处更容易发现，但最后做一次全面检查是值得的。
• 检查 git 日志。八个步骤，八个提交，按顺序排列。如果日志比这更乱，在开启 PR 前先压缩提交。

在 PR 正文中引用计划文件，然后开启 PR。审查者将获得与你相同的检查点结构，只是以只读方式呈现。

将执行工作流打包为一个技能，这样每当 LingCode 运行计划时就会自动应用它：

---
name: executing-plans
description: Use when you have a written implementation plan to execute in a separate session with review checkpoints. Triggers: 'execute the plan', 'work through the plan', 'implement IMPLEMENTATION_PLAN.md', 'do steps 1-5', 'start the plan'. Actions: stepwise execution, summarize each step, verify with real output, per-step commit, deliberate plan amendment, bad-step recovery. Stops mid-plan if a step changes architecture. Output: clean diffs per step + verification evidence.
---

Execute the referenced plan file (IMPLEMENTATION_PLAN.md by
default) one step at a time.

For each step:
1. Read the step from the plan file. Confirm understanding of
   what changes, why ordered here, and how to verify.
2. Make the changes.
3. Summarize: 3-5 lines covering files touched and behavior
   before vs. after.
4. Run the verification command specified by the plan. Paste
   the actual output.
5. Commit the step on its own with message "Step N:
   <description>".
6. Stop. Wait for user confirmation before starting the next
   step.

Never roll into a later step without confirmation. If a
verification fails, stop and diagnose — do not push past red.
If the plan turns out to be wrong, amend the plan file with a
brief reason, commit the amendment by itself, and wait for
sign-off before continuing.

At the end, run the full plan's verification end-to-end and
confirm nothing in the non-goals list crept in.

保存为 ~/.lingcode/skills/executing-plans/SKILL.md——参阅安装技能了解确切路径以及技能如何被发现。

获取 LingCode →