aaihubhub
← 文章库
Claude Code 小白进阶课：从第一次对话到可靠协作 · 第 8 课 / 共 20 课 ↗ AI 教程

08｜Rewind：定位错误并恢复到正确现场

用真实恢复模式比较 Rewind、Git 与局部回退。

kimi
LESSON BRIEFING08 / 20

用真实恢复模式比较 Rewind、Git 与局部回退。

Git 检查点像游戏存档。存档不是为了证明你不会失败，而是让每次实验都有安全返回点。越大的未审查改动，越难区分正确与偶然。

本课交付物

创建练习分支，完成两次小改动并分别检查 diff；故意制造测试失败，使用日志和局部回退恢复，而不是整仓覆盖。

最佳实践

因为 checkpoints 是自动创建的，所以你可以专注于工作，而不用担心手动保存状态。不过，下面这些习惯仍然很重要：

如何高效使用 Checkpoints

✅ 应该做：

  • 回退前先看清楚可用的 checkpoints
  • 当你想尝试不同方向时使用 rewind
  • 保留 checkpoints 方便比较不同方案
  • 理解每个 rewind 选项的作用（恢复代码和对话、恢复对话、恢复代码、或总结）

❌ 不要做：

  • 只依赖 checkpoints 来保存代码
  • 指望 checkpoints 跟踪外部文件系统变化
  • 把 checkpoints 当成 git commit 的替代品

配置

你可以在设置中开启或关闭自动 checkpoints：

{
  "autoCheckpoint": true
}
  • autoCheckpoint：是否在每次用户提示后自动创建 checkpoint（默认：true）

局限性

Checkpoints 很适合会话级回退，但它不是版本控制系统。对于需要长期保存、可审计、可共享的改动，仍然应该使用 git。

故障排查

找不到 Checkpoints

  • 检查你是否在支持该功能的 Claude Code 版本中
  • 确认自动 checkpoint 没有被关闭
  • 重新打开会话再试一次

Rewind 失败

  • 确认你选择了一个有效的 checkpoint
  • 查看是否存在与文件系统或权限相关的限制
  • 尝试先分别恢复代码或对话，再决定是否同时恢复两者

与 Git 的集成

Checkpoints 和 git 是互补关系：

  • Checkpoints 用于会话内探索和安全试验
  • Git 用于永久保存代码历史
  • 你可以先用 checkpoints 快速试错，再把最终方案提交到 git

快速开始

基本工作流

1. 开始修改前自动创建 checkpoint
2. 尝试某个方案
3. 如果结果不理想，按 Esc 两次
4. 选择合适的 rewind 选项
5. 继续探索或提交最终方案

键盘快捷键

  • Esc + Esc：打开 checkpoint 浏览器
  • /rewind：通过命令进入回退界面
  • /checkpoint：/rewind 的别名

什么时候该 rewind：上下文监控

如果你发现这些信号，通常就该回退了：

  • 当前方案开始变复杂，而且你还没确定方向
  • 测试刚失败，问题可能就是最近一两步引入的
  • 你想比较两种实现方式
  • 你想保留一个“干净起点”继续探索

相关概念

  • Memory：跨会话的长期上下文，见 02-memory/README.md
  • Hooks：事件驱动自动化，见 06-hooks/README.md
  • Plugins：打包功能集合，见 07-plugins/README.md
  • Advanced Features：包括 planning mode 和背景任务，见 09-advanced-features/README.md

更多资源

总结

Checkpoints 的价值在于让你敢于试错。它让“先试再说”和“试错后立刻回退”变得安全，从而帮你更快找到正确方案。

示例 6：配置管理

场景

测试不同的配置方案。

工作流程

用户：把配置迁移到环境变量
      [检查点“Original config”自动创建]

Claude：[实现环境变量配置]

用户：在开发环境里测试

Claude：本地可用，但生产环境部署有问题

用户：我换个方案试试。
[用户按下 Esc+Esc，选择“Original config”检查点，选择“恢复代码和对话”]

用户：改成带校验的配置文件方案

Claude：[实现带 JSON Schema 校验的 YAML 配置]

用户：在开发环境里测试

Claude：✅ 运行良好，校验错误提示也很清楚

用户：我们也能为敏感值支持环境变量吗？

Claude：[为密钥添加环境变量覆盖]

用户：测试部署

Claude：✅ 所有环境都正常工作

用户：完美，这个已经可以用于生产。

示例 7：测试策略

场景

实现完整的测试体系。

工作流程

用户：给 auth 模块添加单元测试
      [检查点自动创建]

Claude：[添加 Jest 单元测试]

用户：运行测试

Claude：45 个测试通过，覆盖率 78%

用户：再加上集成测试

Claude：[添加集成测试]

用户：运行测试

Claude：89 个测试通过，覆盖率 92%，但测试太慢了（3 分钟）

用户：测试太慢了，我们来优化。

Claude：[优化测试设置，增加并行执行]

用户：运行测试

Claude：89 个测试通过，覆盖率 92%，35 秒完成 ✅

用户：很好！再给关键路径加上 E2E 测试。

Claude：[添加 Playwright E2E 测试]

用户：运行所有测试

Claude：112 个测试通过，覆盖率 94%，2 分钟完成

用户：很好，覆盖率和速度都平衡得不错！

示例 8：从检查点开始总结

场景

在一次很长的调试会话后，你想压缩对话内容，同时保留上下文。

工作流程

用户：[经过 20 多条消息的调试和探索之后]

[用户按下 Esc+Esc，选择较早的检查点，选择“从这里开始总结”]
[可选地提供指令：“重点保留我们尝试过什么，以及什么有效”]

Claude：[生成从该点开始的对话总结]
[原始消息保留在记录里]
[总结会替换当前可见对话，从而减少上下文窗口占用]

用户：现在继续推进那个有效的方案。

关键结论

  1. 检查点是自动创建的：每次用户提示都会创建一个检查点，不需要手动保存。
  2. 使用 Esc+Esc 或 /rewind：这两种方式都可以打开检查点浏览器。
  3. 选择合适的恢复方式：根据需要恢复代码、对话、两者都恢复，或者直接总结。
  4. 不要害怕试验：检查点让你可以安全尝试激进的改动。
  5. 和 git 结合使用：检查点用于探索，git 用于最终落地。
  6. 长会话要及时总结：用“从这里开始总结”来保持对话可管理。

本站实战工作台

检查点不是为了炫耀 Git

检查点的作用是把实验切成能理解、能比较、能局部撤销的小段。没有检查点时，十个文件一起变化，你很难知道测试是被哪一步破坏，也容易用整仓覆盖误伤别人尚未提交的工作。

动手前拍一张现场照片

git status --short
git branch --show-current
git log -3 --oneline

如果工作区本来就不干净，把现有改动视为用户资产。记录哪些文件与你的任务重叠，不要用 reset 或 checkout 清理。必要时新建分支或 worktree 隔离，而不是覆盖现场。

小步不是小提交数量竞赛

一个检查点应该表达完整意图，例如“补充失败测试”或“实现最小修复”，而不是“改第一行”。提交前看 diff，确保不混入格式化、调试输出和无关重构。测试失败也可以成为本地检查点，只要消息清楚说明当前状态，且不推送为完成版本。

安全制造并恢复一次失败

在练习分支修改一个被测试覆盖的返回值，让定向测试失败。保存失败输出，定位到本次差异，然后只撤回那一小块。恢复后再次运行同一测试，证明因果关系。

比较两种危险习惯：直接复制旧文件覆盖新文件，会丢掉同期合法修改；整仓 reset 会抹掉所有未提交工作。优先使用编辑补丁、反向提交或明确文件范围的恢复方式，并始终先审查目标差异。

Checkpoint 与 Commit 的区别

Claude Code 的检查点能力可帮助恢复会话内变更，Git 提交则是仓库级、可共享的历史。两者可以互补，但不能互相假装。会话检查点不替代数据库备份，Git 提交也不会撤销已经发送的邮件、迁移的生产数据或付费 API 调用。

恢复后还要检查外部状态

如果任务启动了服务、改变了端口、安装了依赖或执行了迁移，文件恢复不代表环境恢复。建立恢复清单：进程、数据库、生成文件、锁文件、远程分支、临时凭据。每种状态有自己的撤销工具。

交付恢复演练

创建 recovery-log.md，记录基线、两个检查点、注入的失败、定位证据、使用的局部恢复和恢复后测试。最后让另一位学习者只看日志复现。真正的可恢复不是“我知道 Git 命令”，而是事故发生时仍能保护不属于本任务的工作。