检查点使用示例
Claude Code 中高效使用检查点的真实案例。
注意：每次用户提示都会自动创建检查点，无需手动保存。回退时按两次 Esc（Esc+Esc）或使用 /rewind 打开检查点浏览器。
示例一：数据库迁移
场景
需要从 MySQL 迁移到 PostgreSQL，但想同时探索直接迁移和渐进式双写两种方案。
工作流
用户：实现从 MySQL 到 PostgreSQL 的直接迁移
[自动创建检查点 A]
Claude：我来实现直接迁移……
[替换数据库驱动、更新查询、修改 Schema]
用户：运行测试
[自动创建检查点 B]
Claude：运行测试中……
❌ 15 个测试失败——连接池问题
用户：这个方案有问题，改用双写模式吧
[用户按 Esc+Esc，选择检查点 A，选择"恢复代码和对话"]
用户：现在实现双写模式，同时写入两个数据库
Claude：我来实现双写迁移……
[实现双写层和渐进迁移策略]
用户：运行测试
Claude：运行测试中……
✅ 所有测试通过
用户：双写方案明显更稳妥，提交吧。示例二：性能优化
场景
尝试多种性能优化策略。
工作流
用户：优化 API 响应时间，当前：450ms
[自动创建"基准"检查点]
Claude：我来添加数据库查询缓存……
[实现 Redis 缓存]
用户：运行性能测试
Claude：结果：平均响应时间 280ms（提升 38%）
用户：我想试试另一种方案。
[用户按 Esc+Esc，选择"基准"检查点，选择"恢复代码和对话"]
用户：改为优化数据库查询
Claude：我来优化数据库查询……
[添加索引、优化 N+1 查询]
用户：运行性能测试
Claude：结果：平均响应时间 180ms（提升 60%）
用户：我还想试第三种方案。
[用户按 Esc+Esc，选择"基准"检查点，选择"恢复代码和对话"]
用户：尝试响应压缩和 CDN
Claude：我来添加压缩和 CDN……
[实现 gzip，配置 CDN]
用户：运行性能测试
Claude：结果：平均响应时间 320ms（提升 29%）
用户：查询优化效果最好。回退到那个版本，再叠加缓存。
[用户按 Esc+Esc，选择查询优化后的检查点，选择"恢复代码和对话"]
用户：在这些优化过的查询上再加 Redis 缓存
Claude：[在优化后的查询基础上添加 Redis 缓存]
用户：运行性能测试
Claude：结果：平均响应时间 95ms（提升 79%）🎉
用户：完美！就是这个方案，提交吧。示例三：UI/UX 迭代
场景
为 Dashboard 尝试不同布局方案。
工作流
用户：用侧边栏布局重新设计 Dashboard
[自动创建"起点"检查点]
Claude：[实现侧边栏布局]
用户：给我看截图
Claude：[展示截图]
用户：侧边栏感觉太挤了，试试顶部导航吧。
[用户按 Esc+Esc，选择"起点"检查点，选择"恢复代码和对话"]
用户：试用顶部导航布局
Claude：[实现顶部导航]
用户：给我看截图
Claude：[展示截图]
用户：好多了，但还想试试卡片式网格布局
[用户按 Esc+Esc，选择"起点"检查点，选择"恢复代码和对话"]
用户：试用卡片式网格布局
Claude：[实现卡片网格]
用户：给我看截图
Claude：[展示截图]
用户：很不错！能把顶部导航和卡片网格结合起来吗？
[用户按 Esc+Esc，选择卡片网格后的检查点，选择"恢复代码和对话"]
用户：在卡片网格布局上加上顶部导航
Claude：[为卡片网格添加顶部导航]
用户：完美！这就是最终设计。示例四：调试会话
场景
通过多个假设追踪棘手的 Bug。
工作流
用户：应用中有内存泄漏
[自动创建"调试前"检查点]
Claude：我来排查……
[分析代码]
用户：我觉得是事件监听器的问题，先修那里。
Claude：[修复事件监听器清理逻辑]
用户：运行内存分析
Claude：仍在泄漏——事件监听器不是问题所在
用户：回退，换个思路试试。
[用户按 Esc+Esc，选择"调试前"检查点，选择"恢复代码和对话"]
用户：可能是数据库连接的问题？
Claude：[修复连接池相关问题]
用户：运行内存分析
Claude：仍在泄漏——也不是连接的问题
用户：再回退，换个角度。
[用户按 Esc+Esc，选择"调试前"检查点，选择"恢复代码和对话"]
用户：检查一下循环引用
Claude：[在缓存中发现并修复循环引用]
用户：运行内存分析
Claude：✅ 内存泄漏已修复！缓存层中的循环引用是罪魁祸首。
用户：太好了！提交这个修复。示例五：API 设计演进
场景
多次迭代设计 REST API。
工作流
用户：为博客平台创建 REST API
[自动创建"API 设计前"检查点]
Claude：[创建基础 CRUD API]
用户：太简单了，加上分页和过滤
Claude：[添加分页和过滤]
用户：需要更好的资源关联
Claude：[实现 HATEOAS 链接]
用户：其实我们试试 GraphQL 而不是 REST
[用户按 Esc+Esc，选择"API 设计前"检查点，选择"恢复代码和对话"]
用户：为博客平台实现 GraphQL API
Claude：[实现 GraphQL API]
用户：还是 REST 更适合我们的场景。
[用户按 Esc+Esc，选择 HATEOAS 之后的检查点，选择"恢复代码和对话"]
用户：我们继续推进 REST 方案。示例六：配置管理
场景
测试不同的配置管理方案。
工作流
用户：将配置迁移到环境变量
[自动创建"原始配置"检查点]
Claude：[实现环境变量配置]
用户：在开发环境测试
Claude：本地可以，但生产部署有问题
用户：试试另一种方案。
[用户按 Esc+Esc，选择"原始配置"检查点，选择"恢复代码和对话"]
用户：试用带校验的配置文件方式
Claude：[实现 YAML 配置 + JSON Schema 校验]
用户：在开发环境测试
Claude：✅ 运行良好，校验错误提示清晰
用户：敏感值也支持用环境变量覆盖吗？
Claude：[为 secrets 添加环境变量覆盖支持]
用户：测试部署
Claude：✅ 所有环境均正常运行
用户：完美！可以上生产了。示例七：测试策略
场景
实现全面的测试覆盖。
工作流
用户：为 auth 模块添加单元测试
[自动创建检查点]
Claude：[使用 Jest 添加单元测试]
用户：运行测试
Claude：45 个测试通过，覆盖率 78%
用户：再加集成测试
Claude：[添加集成测试]
用户：运行测试
Claude：89 个测试通过，覆盖率 92%，但测试很慢（3 分钟）
用户：测试太慢了，优化一下。
Claude：[优化测试配置，添加并行执行]
用户：运行测试
Claude：89 个测试通过，覆盖率 92%，耗时 35 秒 ✅
用户：好！现在为关键路径添加 E2E 测试
Claude：[添加 Playwright E2E 测试]
用户：运行所有测试
Claude：112 个测试通过，覆盖率 94%，耗时 2 分钟
用户：覆盖率和速度平衡得很好！示例八：使用"从此处总结"
场景
经过一段漫长的调试后，想压缩对话同时保留上下文。
工作流
用户：[经过 20+ 条调试和探索消息之后]
[用户按 Esc+Esc，选择一个早期检查点，选择"从此处总结"]
[可选：提供指令，如"重点总结我们尝试了什么以及哪些有效"]
Claude：[生成从该检查点到现在的对话摘要]
[原始消息保留在记录中]
[摘要替换显示的对话，减少上下文窗口占用]
用户：现在继续推进有效的方案。核心要点
- 检查点是自动的：每次用户提示都会创建检查点——无需手动保存
- 用 Esc+Esc 或 /rewind：这是访问检查点浏览器的两种方式
- 选对恢复选项：根据需要选择恢复代码、对话、两者都恢复，或总结
- 大胆实验：检查点让你可以安全地尝试激进的方案
- 结合 git 使用：检查点用于探索，git 用于最终成果
- 长会话使用总结：使用"从此处总结"保持对话可管理