claude-howto/zh/08-checkpoints/checkpoint-examples.md

检查点示例

以下是一些在 Claude Code 中有效使用检查点的真实示例。

注意：每次用户提示都会自动创建检查点。你不需要手动保存。要回退，请连续按两次 Esc（Esc+Esc），或者使用 /rewind 打开检查点浏览器。

示例 1：数据库迁移

场景

你需要从 MySQL 迁移到 PostgreSQL，但想同时探索直接迁移和渐进式双写两种方案。

工作流程

用户：我们来实现一个从 MySQL 到 PostgreSQL 的直接迁移方案
      [检查点 A 自动创建]

Claude：我来实现直接迁移……
[更换数据库驱动、更新查询、修改 schema]

用户：运行测试
      [检查点 B 自动创建]

Claude：正在运行测试……
❌ 15 个测试失败 - 连接池问题

用户：这个方案有问题。我们改试双写模式。
[用户按下 Esc+Esc，选择检查点 A，选择“恢复代码和对话”]

用户：现在实现双写模式，同时向两个数据库写入

Claude：我来实现双写迁移……
[实现双写层、渐进式迁移策略]

用户：运行测试

Claude：正在运行测试……
✅ 所有测试通过

用户：双写方案明显更稳妥。我们提交这个版本。

示例 2：性能优化

场景

尝试多种性能优化策略。

工作流程

用户：我们来优化 API 响应时间。当前：450ms
      [检查点“Baseline”自动创建]

Claude：我来加数据库查询缓存……
[实现 Redis 缓存]

用户：运行性能测试

Claude：结果：平均响应时间 280ms（提升 38%）

用户：我想试试另一种方法。
[用户按下 Esc+Esc，选择“Baseline”检查点，选择“恢复代码和对话”]

用户：改试数据库查询优化

Claude：我来优化数据库查询……
[添加索引，优化 N+1 查询]

用户：运行性能测试

Claude：结果：平均响应时间 180ms（提升 60%）

用户：我也想试第三种方法。
[用户按下 Esc+Esc，选择“Baseline”检查点，选择“恢复代码和对话”]

用户：尝试响应压缩和 CDN

Claude：我来添加压缩和 CDN……
[实现 gzip，配置 CDN]

用户：运行性能测试

Claude：结果：平均响应时间 320ms（提升 29%）

用户：查询优化最好。让我回到那个版本，再和缓存结合起来。
[用户按下 Esc+Esc，选择查询优化后的检查点，选择“恢复代码和对话”]

用户：现在在这些优化后的查询之上再加上 Redis 缓存

Claude：[在优化后的查询之上添加 Redis 缓存]

用户：运行性能测试

Claude：结果：平均响应时间 95ms（提升 79%）🎉

用户：完美！这就是最终方案。我们提交它。

示例 3：UI/UX 迭代

场景

为仪表板尝试不同布局。

工作流程

用户：我们来把仪表板重设计成侧边栏布局
      [检查点“Start”自动创建]

Claude：[实现侧边栏布局]

用户：给我看一张截图

Claude：[显示截图]

用户：侧边栏太拥挤了。我们试试顶部导航吧。
[用户按下 Esc+Esc，选择“Start”检查点，选择“恢复代码和对话”]

用户：试试顶部导航布局

Claude：[实现顶部导航]

用户：给我看一张截图

Claude：[显示截图]

用户：好多了，不过我们再试试卡片式网格布局。
[用户按下 Esc+Esc，选择“Start”检查点，选择“恢复代码和对话”]

用户：试试卡片式网格布局

Claude：[实现卡片网格]

用户：给我看一张截图

Claude：[显示截图]

用户：这个很不错！不过我们能把顶部导航和卡片网格结合起来吗？
[用户按下 Esc+Esc，选择卡片网格后的检查点，选择“恢复代码和对话”]

用户：给卡片网格布局加上顶部导航

Claude：[在卡片网格上添加顶部导航]

用户：完美！这就是最终设计。

示例 4：调试会话

场景

用多个假设排查一个难缠的 bug。

工作流程

用户：应用里有内存泄漏
      [检查点“Before debugging”自动创建]

Claude：让我来调查……
[分析代码]

用户：我觉得问题在事件监听器里。我们先修这个。

Claude：[修复事件监听器清理逻辑]

用户：运行内存分析器

Claude：仍然在泄漏内存 - 事件监听器不是问题所在

用户：让我回到之前，换个思路试试。
[用户按下 Esc+Esc，选择“Before debugging”检查点，选择“恢复代码和对话”]

用户：也许是数据库连接的问题？

Claude：[实现连接池修复]

用户：运行内存分析器

Claude：还是在泄漏 - 也不是连接的问题

用户：我再回去，换另一个方向试试。
[用户按下 Esc+Esc，选择“Before debugging”检查点，选择“恢复代码和对话”]

用户：我们检查一下有没有循环引用

Claude：[找到并修复缓存中的循环引用]

用户：运行内存分析器

Claude：✅ 内存泄漏修复了！缓存层里的循环引用就是罪魁祸首。

用户：太好了！我们提交这个修复。

示例 5：API 设计演进

场景

为 REST API 设计做多轮迭代。

工作流程

用户：给我们的博客平台创建一个 REST API
      [检查点“Before API design”自动创建]

Claude：[创建基础 CRUD API]

用户：这个太简单了。加上分页和过滤

Claude：[添加分页和过滤]

用户：我们需要更好的资源关系

Claude：[实现 HATEOAS 链接]

用户：其实我们改用 GraphQL，不用 REST 了
[用户按下 Esc+Esc，选择“Before API design”检查点，选择“恢复代码和对话”]

用户：那就为我们的博客平台改实现 GraphQL API 吧

Claude：[实现 GraphQL API]

用户：我觉得 REST 更适合我们的场景。
[用户按下 Esc+Esc，选择 HATEOAS 之后的检查点，选择“恢复代码和对话”]

用户：那我们就把 REST 方案定下来。

示例 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. 长会话要及时总结：用“从这里开始总结”来保持对话可管理。