用 Claude Code 处理代码任务时，有一种让人不安的时刻：它改动了一批文件，你看着改动觉得方向有点不对，但已经不知道原来的代码是什么样子了——尤其是在它连续改了十几个文件之后。
检查点（Checkpoint）功能就是为这个场景设计的。它在 Claude Code 执行任务的过程中自动或手动保存项目状态的快照，当你发现改动走偏了，可以一键回到改动之前的状态，而不需要手动逐文件撤销或依赖 Git 的 stash 操作。
本文由 Claude Ai中文官网 整理，把检查点功能的工作原理、触发方式、回滚操作，以及与 Git 配合使用的最佳实践，系统梳理清楚，帮你在 AI 编程的试错过程中保持对代码状态的完整控制。
Claude Code 的检查点功能随版本迭代持续改进，具体交互方式和命令以你安装的版本为准。建议同时访问 Claude Ai中文官网 或 Anthropic 官方文档查阅最新说明。
一、检查点功能解决的核心问题
在理解功能细节之前，先把它解决的问题说清楚，方便你判断什么时候需要用它。
Claude Code 在执行一个任务时，可能会连续修改多个文件——改了 A 文件的函数、删了 B 文件的某个模块、在 C 文件里新增了代码、更新了 D 文件的配置。这个过程中，如果你在中途发现方向错了，想撤回到某个特定的状态，面临的选择通常只有两个：
- 手动逐文件撤销：如果你没有 Git，只能靠 Ctrl+Z 逐步撤销，但跨文件的撤销顺序很难保证正确，而且可能已经关闭了某些文件。
- 依赖 Git：如果项目有 Git，可以用
git checkout或git stash，但这需要你提前做了 commit 或 stash，在任务进行中这个操作并不总是及时。
检查点功能在 Claude Code 内部提供了第三个选项：在任务执行过程中自动或手动保存状态快照，任何时候都可以一键回滚到某个快照，不依赖外部工具，不需要提前操作。
二、检查点的两种创建方式
方式 1：Claude Code 自动创建检查点
Claude Code 会在以下时机自动创建检查点，无需你手动触发：
- 开始执行写操作之前：当 Claude Code 即将对文件进行写入、修改或删除操作时，它会在执行前自动保存当前状态。这是最常见的自动检查点触发场景。
- 每轮对话结束时：在完成一个对话轮次（你发送一条消息，它执行并回复）之后，Claude Code 会保存当前的项目状态。
- 执行批量操作之前：当 Claude Code 判断接下来要执行的操作涉及多个文件或具有较高影响面时，会在开始前自动创建检查点。
自动检查点是无感知的——你不需要做任何操作，Claude Code 会在后台静默创建。你只有在需要回滚的时候，才会意识到它们的存在。
方式 2：手动创建检查点
在以下场景，建议你主动创建检查点，而不是完全依赖自动触发：
- 你即将让 Claude Code 执行一个风险较高的操作（如大规模重构、删除模块）
- 当前的代码状态是你满意的”基准状态”，你想在此基础上进行实验性的修改
- 在开始一个新的子任务之前，希望能够独立回滚这个子任务而不影响之前的改动
在 Claude Code 的交互界面中手动创建检查点：
# 在 Claude Code 对话中，用自然语言请求创建检查点 请在开始修改之前，先为当前状态创建一个检查点。 # 或者直接通过命令 /checkpoint save "重构前的稳定状态"
手动创建时建议附上描述性的标签，方便后续在多个检查点之间找到目标状态。
三、查看当前的检查点列表
在 Claude Code 的交互界面中，你可以随时查看当前会话中已有的检查点列表：
# 查看所有检查点 /checkpoint list # 或者在对话中询问 请列出当前所有可用的检查点。
检查点列表通常会显示以下信息：
- 检查点的序号或 ID
- 创建时间
- 创建检查点时正在进行的操作描述（自动创建）或你填写的标签（手动创建）
- 该检查点对应的文件变更摘要
了解当前有哪些检查点，能帮你在回滚时选择正确的目标状态，避免回滚过头或回滚不足。
四、回滚操作：怎么用检查点还原代码状态
当你发现 Claude Code 的改动方向有问题，或者测试结果不符合预期，需要回到之前的状态时，操作步骤如下：
步骤 1：确认你想回到哪个检查点
先查看检查点列表，找到你想回滚的目标状态。如果你不确定应该回到哪个，可以查看每个检查点的变更摘要来判断：
# 查看特定检查点的详细信息 /checkpoint show [检查点ID] # 查看从某个检查点到当前状态的变更差异 /checkpoint diff [检查点ID]
步骤 2：执行回滚
# 回滚到指定检查点 /checkpoint restore [检查点ID] # 或者通过自然语言 请回滚到标签为"重构前的稳定状态"的检查点。 # 回滚到最近的一个检查点（最常用） /checkpoint restore latest
步骤 3：确认回滚结果
回滚完成后，Claude Code 会显示还原的文件列表和变更摘要。建议做以下验证：
- 检查关键文件的内容是否已恢复到预期状态
- 运行一次快速的测试（如果有测试套件）确认代码可正常运行
- 确认不需要的改动已经被撤销
# 回滚后验证当前状态 请告诉我当前的文件状态，确认回滚是否成功。
回滚的影响范围
需要了解的重要细节：回滚操作会将指定检查点之后的所有文件变更撤销，回到检查点时刻的精确状态。这意味着：
- 检查点之后 Claude Code 做的所有修改都会被还原
- 检查点之后你手动做的文件修改也会被还原
- 回滚不可选择性撤销（不能只还原某一个文件而保留其他文件的改动）
如果你只想撤销某个特定文件的改动而保留其他文件，使用 Git 的 git checkout -- [文件名] 更合适。
五、检查点与 Git 的配合：最稳健的工作流
检查点功能和 Git 不是替代关系，而是互补的——检查点提供了会话内的即时状态保存，Git 提供了长期的版本管理。两者结合使用，能覆盖不同粒度的回滚需求。
推荐的工作流
开始一个任务之前：在 Git 中创建一个新分支，专门用于这次 Claude Code 辅助的改动。
git checkout -b feature/claude-refactor-auth-module
在 Claude Code 中执行任务：让 Claude Code 在这个分支上工作，利用检查点功能在任务执行过程中保存细粒度的状态快照。
任务完成并验证后：将改动提交到 Git。
git add . git commit -m "feat: 重构认证模块，提升代码可读性"
如果任务失败或需要推倒重来：可以选择：
- 使用检查点回滚到会话内的某个中间状态，在此基础上继续尝试
- 使用 Git 完全放弃整个分支的改动，回到
main分支重新开始
检查点 vs Git 的分工对比
| 场景 | 推荐工具 | 原因 |
|---|---|---|
| 任务进行中，需要临时回退几步 | 检查点 | 即时操作，不需要 commit，不污染 Git 历史 |
| 当前改动整体满意，想保留进度 | Git commit | 持久化保存，支持跨会话访问 |
| 只想撤销某个特定文件的改动 | Git checkout | 检查点是全量回滚，Git 支持文件级操作 |
| 需要在不同方案之间对比切换 | Git branch | 分支支持独立保存多个方案 |
| Claude Code 会话结束后的状态保存 | Git commit | 检查点不跨会话，关闭会话后无法恢复 |
| 快速回滚 AI 的批量操作 | 检查点 | 比手动逐文件撤销快得多 |
关键注意事项：检查点不跨会话保存
检查点是会话级别的功能。当你关闭 Claude Code 会话后，该会话中的所有检查点都不再可用。 这意味着：
- 重要的代码状态必须通过 Git 提交来持久化，不能只依赖检查点
- 如果你关闭了终端或 Claude Code 进程退出，当前会话的检查点会话随之失效
- 在长期任务中，应该定期通过 Git commit 保存阶段性成果
六、高风险操作前的检查点策略
以下几类操作风险较高，强烈建议在执行前手动创建检查点：
大规模重构
涉及多个文件的重构操作（如修改接口签名、重组目录结构、替换依赖库）影响面广，一旦出现问题，手动回退的成本极高。
# 在开始大规模重构前 请先创建一个名为"重构前基准状态"的检查点， 然后再开始对认证模块的重构。
删除操作
删除文件、删除函数、删除配置项——删除操作的影响通常比修改更难手动还原，检查点在这里的价值尤其明显。
# 在删除操作前 在删除这些废弃的工具函数之前，先创建一个检查点， 万一有其他地方还在用，我需要能够快速恢复。
依赖升级
升级第三方依赖包可能导致不兼容的 API 变更，在升级前保存检查点，确保出现问题时能快速回到已知可用状态。
实验性修改
当你不确定一种实现方式是否合适，想先试试看再决定的时候，检查点是”安全地试验”的基础设施。
# 实验性修改前 我想试一种新的缓存策略，不确定效果如何。 先创建一个检查点，然后我们来实现新的策略， 如果效果不好，可以快速回滚。
七、常见问题与解决方法
Q：回滚之后，我之前手动做的一些修改也没了，怎么找回来？
A：检查点的回滚是全量的，检查点之后所有的文件变更（包括你手动做的）都会被还原。如果你的项目有 Git，可以通过 git diff HEAD 或 git stash 在回滚前先保存当前状态。养成在开始使用 Claude Code 之前先做 Git commit 的习惯，是防止这类情况的最可靠方法。
Q：检查点列表里有很多条目，怎么知道应该回滚到哪个？
A：通过 /checkpoint diff [检查点ID] 查看每个检查点到当前状态的差异，或者通过 /checkpoint show [检查点ID] 查看该检查点的摘要。如果你在手动创建检查点时给了清晰的描述标签，这个步骤会容易很多——这也是建议养成给检查点命名习惯的原因。
Q：关闭了 Claude Code 再重新打开，检查点还在吗？
A：不在。检查点是会话级别的，关闭会话后不再可用。重要的代码状态需要通过 Git commit 来持久化保存。
Q：能否只回滚某一个文件而不影响其他文件？
A：检查点的回滚是全量的，不支持选择性文件回滚。如果只想撤销某个特定文件的改动，使用 git checkout -- [文件路径]（如果该文件在上一次 commit 时的状态是你想要的）更合适。
Q：检查点会占用磁盘空间吗？
A：会，但通常不多。检查点保存的是文件状态的差异（delta），而不是完整的文件副本，对磁盘空间的占用通常在可接受范围内。Claude Code 会在会话结束后自动清理该会话的检查点数据。
Q：Claude Code 执行任务时突然中断了，检查点还有效吗？
A：如果中断发生在 Claude Code 进程退出之前，检查点通常仍然有效，可以在重新启动 Claude Code 并进入同一项目目录后查看。如果进程异常终止，检查点数据可能不完整，建议通过 Git 来确认代码状态。
八、让检查点功能真正好用的几个习惯
检查点功能的价值能否充分体现，很大程度上取决于使用习惯。以下几点是从实际使用中总结出的最有价值的习惯：
- 每个任务开始前做一次 Git commit：这不是检查点功能本身的要求，但是让检查点功能发挥最大价值的前提。有了干净的 Git 状态，你在任何时候都有”绝对安全点”可以回退，检查点负责任务执行中的细粒度回滚。
- 手动创建检查点时写清楚描述：一个月后你不一定记得”检查点 3″是什么状态，但”添加缓存层之前”或”API 接口重构完成、单元测试通过”这样的描述让你一眼就能做出判断。
- 在要求 Claude Code 做有较大风险的操作时，明确要求它先创建检查点：不要假设 Claude Code 一定会自动创建检查点，在高风险操作前主动要求，确保有明确的安全点。
- 不要过分依赖检查点，把它当作 Git 的替代品：检查点解决的是会话内的即时回滚需求，不能替代 Git 的版本管理功能。阶段性成果必须 commit，不能只存在于检查点中。
- 重要改动完成后立即 commit，不要等积累很多再一次性提交：小步提交能让 Git 历史更清晰，也能确保即使 Claude Code 会话意外终止，已有的进度也不会丢失。
总结
Claude Code 的检查点功能本质上是一个会话内的即时状态快照系统——它在 AI 执行多步骤任务的过程中，提供了一个随时可以”后悔”的机制，让你能够大胆地让 Claude Code 尝试复杂的改动，同时保持对代码状态的控制。
用好检查点功能只需要记住三件事：高风险操作前手动创建检查点并附上清晰描述；回滚时通过差异预览确认目标状态再操作；重要进度通过 Git commit 持久化，不能只依赖检查点。
检查点和 Git 是互补关系，不是替代关系。把两者的分工搞清楚，在正确的场景选用正确的工具，才能在 AI 辅助编程的工作流中既享受高效，又保持安全。
更多关于 Claude Code 功能说明、使用技巧和最新更新，欢迎访问 Claude Ai中文官网 查阅持续更新的中文开发者文档。
好的安全网让你敢于大胆行动。检查点功能的价值不在于它被用到的那一刻，而在于它存在的每一刻——知道随时可以回滚，你才能放心地让 AI 去尝试那些没有它你不敢轻易动手的改动。