工程与协作
检查点Checkpoint
你可能会问
检查点到底是什么？有了 Git 提交，为什么还要说「检查点」？
简单来说
可回退的阶段性状态，通常通过 Git 提交或工具快照保存。
三小时不打点一步一个点同样的冒险，不同的赌注
摔回山脚摔回上个锚点打点越勤，输得越少
01 · 先这样理解
把抽象概念放进真实场景
可回退的阶段性状态，通常通过 Git 提交或工具快照保存。
换个角度想检查点像登山时打下的保护锚点：每前进一段就固定一个，失手了最多摔回上一个锚点，而不是摔回山脚。
02 · 点击演示
让 Agent 连干三小时，你最多会亏掉多少？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- 此刻的状态
功能登录已可用测试✓ 全绿 - 这一步被跳过——
「等全做完再说」提交「登录完成」
这个状态被钉住了
- Agent 继续干
第 2 小时又改了 40 个文件第 3 小时项目跑不起来了Agent 继续干每完成一步又打一个点跑不起来时也不慌 - 摔回山脚只能回到 3 小时前，一下午白干没有锚点，摔就摔到底退一小步回到 10 分钟前的检查点，重来一轮检查点的密度，决定你最多亏多少
1 / 4
Reach · 抵达一个稳定状态
03 · 放进真实任务
什么时候会遇到它
AI 长任务的节奏
每让 Agent 完成一步就存一个点，永远只赌一小段。
实验性修改
试一个不确定的方案前先打点，失败即回滚。
工具自动快照
不少 AI 编码工具会为每轮修改自动建检查点，一键回滚。
04 · 想一想
用一个问题检查理解
让 Agent 连续干了 3 小时没存任何检查点，现在它把项目改得跑不起来了。教训是什么？
查看答案
损失等于上一个检查点到现在的全部工作——这次是 3 小时。正确节奏是每完成一个可验证的小步就存一个点：检查点的密度，决定了你最多亏多少。
最容易踩的坑
检查点的间隔就是你的最大损失。让 AI 干得越猛，打点就要越勤——别等「差不多了」才存。