检查点(Checkpoint)与回滚(Rollback):干净地退回,而不是将错就错
在有风险的步骤之前打一个Git提交,加上内置的回退(Rewind)功能,能把一次失败的智能体尝试变成简单的“退回”,而不是没完没了地缝缝补补。
检查点的两个层级
在智能体工作中,检查点在两个层级上都很有价值:一个是Git中的永久性检查点(在有风险的步骤之前打一个提交,你随时可以有针对性地回退到这里),另一个是工具本身内置的本地检查点,例如Claude Code的检查点机制(Checkpointing),它会在每次提示之前自动保存文件状态。
Claude Code的回退(Rewind)如何工作
Claude Code会在每次提示之前自动保存一份代码快照。通过/rewind(或在输入框为空时按两次Escape),你可以打开一个带有多种恢复选项的菜单——从彻底重置代码和对话,到只重置对话、保留代码不变。
为什么回滚比将错就错更好
如果一个智能体在错误的方案上越陷越深,“干脆让它继续修”往往只会在已经损坏的地基上不断打新的补丁。干净地回滚到最后一个可用的状态、再有意识地重新开始,通常比一步步抢救一个已经乱套的状态更快。
检查点的局限
内置检查点只能捕捉工具自身通过其文件工具所做的改动——通过rm、mv或cp等bash命令做出的改动不会被记录。检查点是对Git的补充,而不是替代:检查点是本地的“撤销”,Git才是永久的历史记录。
示例
git add -A && git commit -m "checkpoint: 重构auth.py之前" # 之后让智能体自由工作 # 如果需要:git reset --hard HEAD~1(回退到检查点) # 或者在会话内:/rewind → 针对最后一次提示选择“重置代码”
🛠️ 练习——自己动手试试
在让智能体处理一个有风险的任务之前,有意识地设置一个Git检查点,并测试/rewind和Git回滚两种方式。
- 用一条清晰的检查点提交信息,提交你项目当前的干净状态。
- 让智能体进行一次较大、有风险的改动(例如跨多个文件的重构)。
- 使用/rewind,有针对性地只重置代码,同时保留对话。
- 模拟一个更糟糕的情况:再额外用git reset --hard测试性地回退到上一个提交。
✅ 自查清单
- ☐ 你能否用/rewind有针对性地只重置代码,而不丢失对话?
- ☐ 如果智能体是用rm删除了文件,你会怎么做?
小测验
Claude Code的检查点机制不会记录什么,因此仍然需要依赖Git?
来源
- Claude Code官方文档:检查点机制(Checkpointing) ↗ code.claude.com
- Git官方文档:git-commit ↗ git-scm.com
- Git官方文档:撤销操作(Undoing Things) ↗ git-scm.com