⚡精通 Claude 第 8 课 | 给 Claude 装个撤销按钮：检查点完全指南

Claude Code 的检查点功能就像给前端开发流程装了个"后悔药"------每次你发完指令，自动存档，随时可以回到任意版本。本文展示如何用检查点做 UI 迭代、组件重构、状态管理调试，以及那些"早知道就..."的场景。

前端开发的困境

写前端最难的不是写代码，是选方案。

这个按钮放左边还是右边？那个状态管理用 Context 还是 Pinia？动画用 CSS 还是 JS 驱动？每次改动都要花时间实现，然后发现不对，再改回去------或者干脆忍着继续往下写，因为改不动了。

直到我发现了检查点。

什么是检查点

检查点是 Claude Code 自动保存的对话快照，包含：

所有对话消息
文件修改内容
工具调用历史
当时的上下文

说人话：每次你发一条消息，Claude 就自动帮你存档一次 。想回到任何一个存档点？按两下 Esc 打开检查点浏览器，选中，回退。

三种回退方式

方式	效果
恢复代码和对话	回到那个时间点，文件和对话都回去
仅恢复对话	代码保留，只把对话倒回去
仅恢复代码	对话保留，只把文件改回去

前端开发实战场景

场景 1：UI 设计迭代

问题：三种布局方案，想都试试看再决定。

less 复制代码

用户：给这个 Dashboard 用 sidebar 布局
      [检查点 A 自动创建]
Claude：[实现 sidebar 布局]

用户：Run dev server，我要看效果
Claude：localhost:3000 已启动

用户：sidebar 太挤了，换成 top nav 试试
[Esc + Esc，选择检查点 A，恢复代码和对话]

用户：试试 top navigation 布局
Claude：[实现 top nav]

用户：不错，但能不能再试试 card grid？
[Esc + Esc，选择检查点 A，恢复代码和对话]

用户：试试 card grid 布局
Claude：[实现 card grid]

三次尝试，同一套代码，同一个对话------只是因为检查点让我随时重来。

场景 2：组件重构

问题：要把一个 Class 组件改成 Hooks 写法，但不确定改完会不会有问题。

css 复制代码

用户：用 useEffect 重构这个定时器组件
      [检查点 A]
Claude：[完成重构]

用户：跑一下测试
Claude：❌ 3 个测试失败------useEffect 清理函数有问题

用户：回退，我来换个思路
[Esc + Esc，选择检查点 A，恢复代码和对话]

用户：别用 useEffect，用 requestAnimationFrame 实现
Claude：[实现新版本]

用户：Run tests
Claude：✅ All passing

关键：不用怕重构------有检查点在，改错了大不了回来，不会丢任何东西。

场景 3：状态管理调试

问题：Redux store 的某个状态莫名奇妙的变了，不知道是谁改的。

scss 复制代码

用户：帮我查一下 user.isPremium 是从哪里被修改的
      [检查点 A]
Claude：[分析代码，发现有两个地方可能修改]

用户：先看第一个，在 authSlice 里加个 log
Claude：[添加日志]

用户：刷新页面，看看 log
Claude：没触发

用户：回退，看第二个地方
[Esc + Esc，选择检查点 A，恢复代码和对话]

用户：在 subscriptionSlice 里加 log
Claude：[添加日志]

用户：刷新页面
Claude：✅ 找到了，subscriptionSlice.setPremium()

调试时经常要加日志看行为，加完发现不对又要删掉重来------检查点让这个过程零成本。

场景 4：样式方案对比

问题：同一个动画效果，想对比 CSS transition 和 Framer Motion 两种实现。

css 复制代码

用户：用 CSS transition 实现这个按钮的 hover 效果
      [检查点 A]
Claude：[实现 CSS transition 版本]

用户：感觉不够流畅，回退一下
[Esc + Esc，选择检查点 A，恢复代码和对话]

用户：用 Framer Motion 实现同一个效果
Claude：[实现 Framer Motion 版本]

用户：这个更自然，但别删------我还想试试 CSS keyframes
[Esc + Esc，选择检查点 A，恢复代码和对话]

用户：用 CSS @keyframes 再试一次
Claude：[实现第三版本]

三个版本都在，一个都没丢，最后选最好的一个就行。

工作流模式

分支探索模式

适合需要对比多个方案的场景：

css 复制代码

1. 当前状态 → [自动检查点 A]
2. 尝试方案 1 → 检查点 B
3. 回退到 A → 尝试方案 2 → 检查点 C
4. 回退到 A → 尝试方案 3 → 检查点 D
5. 对比 B、C、D，选最优

安全重构模式

适合大的代码改动：

markdown 复制代码

1. 开始重构前 → [自动检查点]
2. 做改动
3. Run tests
4. 通过 → 继续
5. 失败 → 回退，换个思路

调试排除模式

适合排查未知问题：

markdown 复制代码

1. 发现问题 → [自动检查点]
2. 假设 A，加日志验证
3. 不是 → 回退
4. 假设 B，加日志验证
5. 找到根因

局限性

检查点不是万能的，知道它的边界很重要：

不支持	说明
Bash 命令的文件变更	`rm component/Foo.tsx` 这种操作不记录
外部编辑器修改	在 VS Code 直接改的文件不跟踪
替代 Git	检查点只存在于当前 session，Git 才是永久存储

最佳实践：检查点用于探索，Git 用于存档。重要的决策完成一个就 commit 一个。

快速上手

正常写代码------检查点自动创建，你不用管
想回到某个版本 ------按 Esc 两下，或输入 /rewind
选检查点------看时间戳和修改内容，选中
选回退方式------代码+对话都回、只回对话、只回代码

总结

检查点解决的是前端开发中最痛苦的时刻：选错方案。不管是 UI 设计、技术选型还是调试排查，有检查点在，你可以大胆尝试，因为错了也能一键回到从前。

用多了之后，我发现心态变了：不再"想了再动手"，而是"先动手试试，不对就回退"。这才是探索该有的状态。

下一步：下次你做 UI 迭代或者技术方案调研时刻意思考检查点------你会发现以前很多"将错就错"的决定，其实都可以重来。

*相关文档：检查点官方文档