检查点（checkpointing）机制在 Claude Code 中默认开启，每次用户提示都会自动保存文件状态，让”大胆尝试—随时回退”成为默认工作流。在 /rewind 菜单里，”Summarize from here”与”Summarize up to here”看似相近，实则面向不同的上下文裁剪场景，前者保留前置细节压缩后段、后者保留最近细节压缩前段。理解这两条路径的设计意图，才能把”状态可逆性”与”上下文窗口预算”这对矛盾调到合适的平衡点。
（项目背景：在一次大型重构里，先让 Claude 沿一条思路跑了 20 轮，验证发现分支选错了。直接 rewind 会丢掉中间发现的几个有用 API 边界；用 summarize 后整段对话只占 600 token，既保留了早先的 API 约束，又腾出空间重新尝试。）
一、检查点机制的基本形态
Claude Code 默认开启检查点，无需手动开启。每个用户提示若触发文件编辑，系统就在编辑前对相关文件做一次快照，连同对话状态一起写入本地。检查点随会话持久化保存，跨 /resume 也能用，30 天后自动清理。
| 属性 | 行为 |
|---|---|
| 触发时机 | 每次用户提示且伴随文件编辑 |
| 持久化范围 | 当前会话 + resume 之后 |
| 默认保留 | 30 天（可配置） |
| 捕获范围 | 仅 Claude 文件编辑工具触发的改动 |
| 不捕获范围 | Bash 命令修改、外部进程改动、未跟踪的并发编辑 |
最后两行是踩坑高发区。rm、mv、cp、管道重定向都跑在 Bash 里，绕过了快照通道；你在 IDE 里手动改的文件、另一个会话同时改的文件都不会被记录。涉及破坏性操作前，要么让 Claude 用文件编辑工具写，要么自己先 git commit 兜底。
二、/rewind 菜单的六种动作
按 Esc+Esc 或执行 /rewind，菜单列出本会话的每个用户提示。选中后可选六种动作，CLI 完整版有六项，VS Code 扩展版仅暴露其中三项。
| 动作 | 改文件 | 改对话 | 适合场景 |
|---|---|---|---|
| Restore code and conversation | 是 | 是 | 整体回退到某次提示前 |
| Restore conversation | 否 | 是 | 保留代码，重做任务指令 |
| Restore code | 是 | 否 | 保留讨论，撤回错误改动 |
| Fork conversation from here | 否 | 新分支 | 平行尝试另一种方案 |
| Summarize from here | 否 | 部分 | 保留前段，压缩后段 |
| Summarize up to here | 否 | 部分 | 压缩前段，保留后段 |
前四个动作改的是”状态”——文件、对话或两者一起被还原。Summarize 两个动作改的是”密度”——文件不动，只把一段对话塞进 AI 生成的摘要里。这两类动作的设计意图截然不同：前者服务于”撤销错误”，后者服务于”腾出窗口”。
三、Summarize from here 的设计意图
“从选定点向后压缩”。选中的消息及其后所有内容被替换成一段摘要，更早的上下文按原样保留。设计上对应”我已经确认了开头是对的，只是中间某段跑偏了”的场景。
原文结构
[任务描述 A] -> [早期探索 B] -> [选中点 C] -> [走偏的尝试 D..L]
Summarize from here at C
[任务描述 A] -> [早期探索 B] -> [摘要(覆盖 C..L)]文件不受影响，原始消息保存在会话记录里供 Claude 回查。压缩后的会话仍处于同一会话，连续性最强，缺点是必须确保 C 之前的对话本身是干净的——否则那部分也会跟着占用预算。
实操中这条路径最常用：从某个明显走偏的提示处压起，把冗长的 debug 试探折叠成”试过 X、Y 不行，Z 有进展”这种短摘要，既保留关键发现，又省下大量 token。
四、Summarize up to here 的设计意图
“从选定点向前压缩”。选中的消息及其后所有内容按原样保留，更早的对话被压缩成摘要。设计上对应”前面的指令、规则、上下文已经讲完，现在最关键的是当下”。
原文结构
[大量任务设定 A..K] -> [选中点 L] -> [最近的工作 M..R]
Summarize up to here at L
[摘要(覆盖 A..L)] -> [最近的工作 M..R]这条路径对应”任务刚启动时塞了一大段设定，到第 30 轮时设定早已被消化，但每次循环还在重复读取它”的典型场景。等价于给整个会话做了一次定向 /compact，但只压前半段。
它的副作用是：早期那些被记成摘要的细节如果后来还需要，模型只能从摘要里再捞一次。因此官方建议在摘要时附一句可选说明（比如 /rewind summarize up to here 保留所有测试命令与修改文件列表），引导模型把关键信息保留在摘要中。
五、状态可逆 vs 窗口预算的取舍
检查点机制本身要解决的是两件冲突的事：一是把每一次尝试都做成”可逆的”，鼓励大胆实验；二是上下文窗口是有限预算，长的会话必须能瘦下来。Rewind 五个动作（不含 fork）正好分别对应这两条线的不同组合。
| 需求 | 优选动作 |
|---|---|
| 改坏了想撤回 | Restore code / Restore code and conversation |
| 方案想换但代码别丢 | Fork conversation from here |
| 中段走偏想留前文 | Summarize from here |
| 前段啰嗦想留后文 | Summarize up to here |
| 改主意但代码还能用 | Restore conversation |
判断标准很简单：你要保留的是”哪个时间段”。改坏代码要回到”过去某个时间点”，所以选 restore 类；要节省 token 也要留住最新进展，所以选 summarize 类。
六、实操中容易踩的坑
检查点不是版本控制，Git 该用还得用。
- Bash 修改的文件无法回退，破坏性操作先 git commit；
- VS Code 扩展版的 rewind 菜单只暴露 fork / rewind code / 两者并用三类，不支持 summarize；
- summarize 后想再要原始内容，模型只能从会话记录里翻页，不可逆”再膨胀”；
- 检查点保留 30 天，跨 session resume 之后仍可用，但项目里手动删掉的对话对应检查点也会消失；
- 父子会话之间的检查点互不影响，fork 出来的分支独占自己的检查点链。
常见问题（FAQ）
Q1：检查点能完全替代 Git 吗？
不能。检查点服务于”会话内快速撤销”，Git 服务于”长期版本历史”，两者互补，不互相替代。
Q2：为什么我用 Bash 删的文件无法 rewind？
检查点只跟踪 Claude 的文件编辑工具。Bash 触发的改动不在快照范围，必须借助 Git 兜底。
Q3：Summarize from here 与 Summarize up to here 怎么选？
要保留”前段细节”压后段选 from here；要保留”最近工作”压前段选 up to here，方向相反。
