为什么多轮 AI 编程任务一定要做 checkpoint commit

为什么多轮 AI 编程任务一定要做 checkpoint commit

最近做了一次持续多轮的首页调整。导航、模型跑马灯、内嵌生成器、模型展示和 Footer 先后经过确认，页面一度已经接近预期。隔了一段时间再打开预览，前面通过的改动却少了大半。

这次恢复花掉的时间，比补一两个样式问题多得多。最后能找回主要成果，靠的是会话记录里的补丁和少量已经提交的代码。它也让我重新确认了一条很具体的工程习惯：多轮 AI 编程任务里，每个被接受的阶段都应该做一次 checkpoint commit。

未提交的成果很容易变成临时状态

当时的问题由几个条件叠加产生。任务持续了很多轮，已经确认的模块仍停留在工作区，没有形成 commit；开发目录又放在系统临时目录中；后来为了继续工作，临时目录基于一个较旧的分支状态被重新创建。结果很直接，Git 能稳定保留的只有已经提交的内容，工作区里那些看起来“已经做完”的修改没有进入可追溯历史。

Git 官方文档将 git commit 描述为把当前选定的变更记录到仓库中。这里的“记录”很关键。页面能运行、预览能打开、用户已经确认，都不能替代一次提交。只要变更还停留在工作区，它仍依赖当前机器、当前目录和当前进程的连续性。

多轮任务会不断扩大恢复成本

单轮改动丢失时，通常重新写一次即可。多轮任务的麻烦在于，后面的调整往往建立在前面的结果上。导航结构会影响首页间距，生成器会影响首屏节奏，模型卡片的尺寸又会影响整页密度。某个早期状态消失后，后续决策也失去了参照。

这次恢复没有简单地“回到上一版”。我需要重新定位原会话中的每次补丁，辨认哪些版本被用户接受，按依赖顺序恢复文件，再重新跑类型检查、国际化检查和响应式预览。代码还能找回，决策上下文却需要重新拼接，这部分最费时间。

checkpoint commit 的价值就在这里。它给每个已确认阶段一个明确坐标。后续方案不理想时，可以回到最近的坐标继续，而不用猜测某一刻的工作区到底包含哪些文件。

worktree 解决隔离，commit 负责保存

Git 官方文档说明， 可以为同一个仓库建立多个工作目录，让不同分支同时处于检出状态。它很适合 AI 并行开发或长任务隔离，因为主目录可以继续处理日常工作，实验性的首页改动放在独立 worktree 中，不会互相覆盖。