改错了怎么撤：检查点能救你什么，不能救什么

让一个代理去改你的四十份文件，最实际的顾虑只有一个：改坏了怎么办。

Claude Code 有一套自动检查点机制，多数情况能救你。但它有明确的边界，而边界之外恰好包含最危险的那类操作。这篇讲清楚两边各是什么。

它怎么工作

每次你发出一条指令，就自动创建一个检查点。 不需要你做任何事。

• 一个会话里保留最近 100 个检查点的文件快照
• 检查点跟着会话一起保存——resume 回到旧会话后照样能回退
• 默认 30 天后随会话一起删除（可以在设置里改 cleanupPeriodDays）

怎么用

输入框为空时按两下 Esc，或者输入 /rewind，打开回退菜单。

⚠️ 输入框里有字的时候，双击 Esc 是清空输入，不是打开菜单。清掉的内容会存进历史，按 ↑ 能召回。

菜单列出你这个会话里发过的每一条指令。选中一个时间点，然后挑一个动作：

「只回退对话」这个选项很有用。 有时文件改得没错，只是你和它的对话跑偏了、上下文里塞满了试错过程——这时候你要的是清理对话，不是撤销工作成果。

如果选中的检查点之后没有文件改动，两个「恢复代码」的选项不会出现。

两个摘要选项是干什么的

它们其实是定点版的 /compact。

典型场景：你花了一小时排查一个问题，中间试了七八种方法，上下文被大量无用的试错过程占满了。这时候用「从此处摘要」，把排查过程压成一段摘要，同时保留你最开始那几条重要的指令。

摘要不改磁盘上的文件，原始消息也还在会话记录里，Claude 需要时仍能查。

想控制摘要的侧重点：用方向键高亮某个摘要选项，在提示「add context (optional)」的那行输入指令，再回车。

四类它救不了的改动

这一节比上面重要。

一、bash 命令改的文件（最危险）

官方原话是明确的：检查点不追踪 bash 命令修改的文件。

也就是说，如果它执行了：

rm file.txt
mv old.txt new.txt
cp source.txt dest.txt

这些改动无法通过回退撤销。 只有通过文件编辑工具做的直接修改才被追踪。

这条最要命的地方在于：删除和移动恰恰是你最想撤销的操作。

二、子代理做的编辑

子代理（subagent）在后台做的文件编辑，落在你会话的检查点之外，回退不会恢复它们。要撤销得靠 Git。

三、Claude Code 之外的改动

你自己在别的编辑器里改的文件、另一个并行会话改的文件，都不在追踪范围内。

四、符号链接和硬链接指向的文件

回退时会跳过这类路径，并提示「Restored the code, but skipped N files」。被跳过的文件保持现状。

（配置管理工具软链进项目的文件、包管理器硬链的文件，都属于这一类。）

所以真正的防线是什么

官方自己说得很清楚：

Think of checkpoints as “local undo” and Git as “permanent history”.

检查点是「本地撤销」，Git 是「永久历史」。 前者用于会话内的快速恢复，替代不了后者。

对研究咨询工作，落到实处就是三条：

一、要处理的目录先纳入 Git。 不需要懂 Git——让 Claude Code 帮你 git init 并提交一次即可。之后任何改动都有底，包括 bash 删掉的文件。

二、原始素材单独存一份，只读。 访谈原始转录、客户给的原件，放在一个不参与处理的目录里。让它在副本上工作。

这一条比什么机制都可靠：没被碰过的文件不需要撤销。

三、第一次跑之前，先在样本上试。 拿三份文件试一遍，看清它的行为方式，再放它处理四十份。

一个容易忽略的用法

回退菜单还能跨过 /clear。

如果你在同一个 Claude Code 进程里执行过 /clear，回退菜单顶部会多出一条 /resume <session-id> (previous session)。选它就能回到 /clear 之前那个对话。

清屏之后才发现「刚才那段还有用」——不用重来。这个入口在你退出 Claude Code 或切换到别的会话之前一直有效。

小结

把这张表看完，你就知道为什么第一件事是 git init。