Claude Code 的检查点功能就像给前端开发流程装了个"后悔药"——每次你发完指令，自动存档，随时可以回到任意版本。本文展示如何用检查点做 UI 迭代、组件重构、状态管理调试，以及那些"早知道就..."的场景。
前端开发的困境
写前端最难的不是写代码，是选方案。
这个按钮放左边还是右边？那个状态管理用 Context 还是 Pinia？动画用 CSS 还是 JS 驱动？每次改动都要花时间实现，然后发现不对，再改回去——或者干脆忍着继续往下写，因为改不动了。
直到我发现了检查点。
什么是检查点
检查点是 Claude Code 自动保存的对话快照，包含：
- 所有对话消息
- 文件修改内容
- 工具调用历史
- 当时的上下文
说人话：每次你发一条消息，Claude 就自动帮你存档一次。想回到任何一个存档点？按两下 Esc 打开检查点浏览器，选中，回退。
三种回退方式
| 方式 | 效果 |
|---|---|
| 恢复代码和对话 | 回到那个时间点，文件和对话都回去 |
| 仅恢复对话 | 代码保留，只把对话倒回去 |
| 仅恢复代码 | 对话保留，只把文件改回去 |
前端开发实战场景
场景 1：UI 设计迭代
问题：三种布局方案，想都试试看再决定。
用户：给这个 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 写法，但不确定改完会不会有问题。
用户：用 useEffect 重构这个定时器组件
[检查点 A]
Claude：[完成重构]
用户：跑一下测试
Claude：❌ 3 个测试失败——useEffect 清理函数有问题
用户：回退，我来换个思路
[Esc + Esc，选择检查点 A，恢复代码和对话]
用户：别用 useEffect，用 requestAnimationFrame 实现
Claude：[实现新版本]
用户：Run tests
Claude：✅ All passing
关键：不用怕重构——有检查点在，改错了大不了回来，不会丢任何东西。
场景 3：状态管理调试
问题：Redux store 的某个状态莫名奇妙的变了，不知道是谁改的。
用户：帮我查一下 user.isPremium 是从哪里被修改的
[检查点 A]
Claude：[分析代码，发现有两个地方可能修改]
用户：先看第一个，在 authSlice 里加个 log
Claude：[添加日志]
用户：刷新页面，看看 log
Claude：没触发
用户：回退，看第二个地方
[Esc + Esc，选择检查点 A，恢复代码和对话]
用户：在 subscriptionSlice 里加 log
Claude：[添加日志]
用户：刷新页面
Claude：✅ 找到了，subscriptionSlice.setPremium()
调试时经常要加日志看行为，加完发现不对又要删掉重来——检查点让这个过程零成本。
场景 4：样式方案对比
问题：同一个动画效果，想对比 CSS transition 和 Framer Motion 两种实现。
用户：用 CSS transition 实现这个按钮的 hover 效果
[检查点 A]
Claude：[实现 CSS transition 版本]
用户：感觉不够流畅，回退一下
[Esc + Esc，选择检查点 A，恢复代码和对话]
用户：用 Framer Motion 实现同一个效果
Claude：[实现 Framer Motion 版本]
用户：这个更自然，但别删——我还想试试 CSS keyframes
[Esc + Esc，选择检查点 A，恢复代码和对话]
用户：用 CSS @keyframes 再试一次
Claude：[实现第三版本]
三个版本都在，一个都没丢，最后选最好的一个就行。
工作流模式
分支探索模式
适合需要对比多个方案的场景：
1. 当前状态 → [自动检查点 A]
2. 尝试方案 1 → 检查点 B
3. 回退到 A → 尝试方案 2 → 检查点 C
4. 回退到 A → 尝试方案 3 → 检查点 D
5. 对比 B、C、D，选最优
安全重构模式
适合大的代码改动：
1. 开始重构前 → [自动检查点]
2. 做改动
3. Run tests
4. 通过 → 继续
5. 失败 → 回退，换个思路
调试排除模式
适合排查未知问题：
1. 发现问题 → [自动检查点]
2. 假设 A，加日志验证
3. 不是 → 回退
4. 假设 B，加日志验证
5. 找到根因
局限性
检查点不是万能的，知道它的边界很重要：
| 不支持 | 说明 |
|---|---|
| Bash 命令的文件变更 | rm component/Foo.tsx 这种操作不记录 |
| 外部编辑器修改 | 在 VS Code 直接改的文件不跟踪 |
| 替代 Git | 检查点只存在于当前 session，Git 才是永久存储 |
最佳实践：检查点用于探索，Git 用于存档。重要的决策完成一个就 commit 一个。
快速上手
- 正常写代码——检查点自动创建，你不用管
- 想回到某个版本——按
Esc两下，或输入/rewind - 选检查点——看时间戳和修改内容，选中
- 选回退方式——代码+对话都回、只回对话、只回代码
总结
检查点解决的是前端开发中最痛苦的时刻：选错方案。不管是 UI 设计、技术选型还是调试排查，有检查点在，你可以大胆尝试，因为错了也能一键回到从前。
用多了之后，我发现心态变了：不再"想了再动手"，而是"先动手试试，不对就回退"。这才是探索该有的状态。
下一步：下次你做 UI 迭代或者技术方案调研时刻意思考检查点——你会发现以前很多"将错就错"的决定，其实都可以重来。
*相关文档：检查点官方文档
