Claude改错后，用回退重建干净上下文

Claude 改错了文件，继续输入「撤销刚才的修改」看起来最顺手，却会把错误、纠正和返工一起留在会话里。作者建议：遇到这类失误，先用 /rewind 回到出错前，再补上约束重新执行。

这篇文章真正有用的地方，是讲清了回退的边界：它能恢复部分文件修改和对话，但不负责撤销所有操作。理解哪些改动被记录，比记住快捷键更重要，否则很容易把「会话已回退」误认为「工作区已恢复」。

为什么改错后，值得先回退会话

作者的核心判断是：用自然语言纠错，会让错误版本及后续解释继续占据上下文，影响接下来的生成。/rewind 则允许退回较早的提示位置，把后续对话从当前上下文中移走，并按选择恢复文件。

这里要区分事实与判断。回退文件和对话是文中描述的功能；「继续纠正会让会话更差」是作者的经验判断，原文没有提供成功率、token 消耗或对照实验。

入口有两个：输入 /rewind，或者在输入框为空时连续按两次 Esc。菜单列出会话中的提示，选中后可执行：

• Restore code and conversation：同时恢复代码和对话。
• Restore conversation：只回退对话，保留工作区。
• Restore code：只恢复代码，保留对话。

原文声称有五种操作，却只列出三种，另外两种没有交代。涉及代码恢复的两个选项，也只会在对应检查点存在可恢复文件修改时出现。

输入框有文字时，第一次 Esc 会先清空输入；随后可按 Up 从输入历史取回文字。

哪些改动能恢复，哪些必须自己查

/rewind 的文件恢复范围，只覆盖检查点追踪到的修改。

作者给出的范围表，直接决定了它能不能救回一次误操作：

Edit / Write by Claude         tracked, /rewind restores it
Bash: rm, mv, cp               not tracked
Your own edits in the editor   not tracked
Background subagents           not tracked
Symlinks and hard links        skipped on restore

最该盯住第二行：通过 Bash 执行的 rm、mv、cp 不在追踪范围内。如果 Claude 用 shell 删除了 old_config.yml，回退不会把它找回来。你在编辑器里的修改、其他并发会话的修改，以及后台子代理的修改，也不由它恢复。

子代理有一个例外：声明了 context: fork 和 background: false 的前台分叉技能，其修改可以恢复。不能把这个例外扩大到所有子代理。

软链接和硬链接路径会在恢复时跳过。作者特别提到 dotfile 管理器和 pnpm 存储可能遇到 Restored the code, but skipped N files。此时可以执行 /debug，再读取 ~/.claude/debug/<session-id>.txt，查看跳过的路径及原因。

还有一个容易误判的细节：Claude 工作期间排队发送的消息，会加入正在执行的轮次，没有独立检查点，因此不会单独出现在菜单里。

检查点能保留多久，其他命令能替代吗

每个启动新轮次的提示都会创建检查点，但文件快照只保留会话内最近的 100 个检查点。会话最后一次保存快照后，大约 30 天会触发清理，期限由 settings.json 中的 cleanupPeriodDays 控制。

下面的配置把清理期限设为 90 天，并启用文件检查点：

{
  "cleanupPeriodDays": 90,
  "fileCheckpointingEnabled": true
}

关键是 cleanupPeriodDays：需要长期保留时，应在快照被清理前调整。已经清理的快照不会因调大期限而回来，恢复时可能出现 No files were restored。

检查点随会话保存，隔几天恢复会话仍能看到回退菜单，但菜单可见不代表文件快照仍在。同一进程执行过 /clear 时，菜单顶部还可出现 /resume <session-id> (previous session)，用于回到清空前的会话；该入口要求 v2.1.191 或更高版本。

关闭快照可以把 fileCheckpointingEnabled 设为 false，或导出环境变量 CLAUDE_CODE_DISABLE_CHECKPOINTS，赋任意非空值。

其他会话命令的用途不同：/clear 清空上下文并保存旧会话；/compact 在原会话中用摘要替换对话；/resume、--resume、--continue 加载已有会话；/branch、--fork-session 将当前对话复制到新会话。按原文描述，这些操作都不恢复工作区文件。

我的判断

我认同作者把「修复文件」和「清理上下文」放在一起考虑。一次误改如果来自任务理解错误，恢复后补全提示约束，比只要求撤销更有操作价值。

但「别用文字纠错」不适合当成绝对规则。局部小问题是否值得回退，取决于后续有没有值得保留的修改，以及错误是否影响任务方向。作者没有给出两种处理方式的对照数据，不能据此认定回退总能省 token、提高质量。

检查点适合会话内恢复，Git 负责版本历史。 原文明确说它不操作 Git。尤其遇到 Bash、并发会话和后台子代理，回退后的工作区仍需检查。文中版本与保留策略也应按原文信息理解，不能推断所有安装版本都相同。

能拿来做什么

• Claude 误改前端组件或 Node 配置时，先定位出错前的提示，再选择是否同时恢复代码和对话，避免连续返工后难以判断起点。
• 回退后执行 git status 并查看差异，重点核对 Bash 和后台子代理产生的改动，确认实际恢复范围。
• 重新发送任务时补上缺失约束，例如允许修改的目录、必须保留的接口和配置，再让 Claude 执行。
• 长期保留会话时，提前调整快照期限，同时保留 Git 提交；90 天的清理配置并不会取消最近 100 个检查点的快照限制。