1.CC的checkpointing快照机制如何平衡上下文窗口管理与状态可逆性？
Claude Code 的 状态回滚机制（Checkpointing） 与 上下文定向压缩技巧（Summarize / Rewind）。
一句话总结：它教你如何一边保证"写错的代码能一键撤销"，一边保证"聊爆了的上下文（Token）能精准裁剪"。
你可以从 "代码状态与上下文管理" 、"全量压缩 vs 定向压缩" 以及 "两种定向压缩的实战场景" 三个维度来理解。
在用 Claude Code 开发时，有两个东西需要管理：本地的代码文件 和 AI 的内存/上下文空间。
代码安全（Checkpointing /
/rewind）：
每次你给 Claude 发送消息之前，系统都会静默给代码仓拍照（快照）。
如果 Claude 把代码改乱了，你可以直接运行
/rewind一键回滚到刚才的物理文件状态。上下文安全（Summarize 定向压缩）：
- 针对内存中的 Token 空间。当聊天记录太长挤爆上下文时，用来给对话"打瘦身针"。
全量压缩（
/compact）与定向压缩的区别
/compact（全量傻瓜式压缩）：
把整段对话一锅端，全部浓缩成一份概述。
缺点：你无法控制保留哪些、放弃哪些，可能把你刚讨论出来的关键细节点给压缩丢了。
定向 Summarize（精准手术刀压缩）：
- 给你选择权，让你自由决定压缩前半段 还是后半段。
两种"定向压缩"的实战场景
1.
Summarize from here（从选定位置往后压缩）
操作 ：选中某条消息，从它开始往后 的所有对话全部压缩成简短摘要，之前的内容保持完好。
典型场景（走错路/废话偏离）：
你前面讨论好了项目架构设计（非常宝贵），接着尝试一种新方案，结果聊着聊着走弯路了，试错失败。
你不想破坏最开始讨论好的架构设计，就可以在试错起点点击
Summarize from here，把后面这堆无用的探索细节压缩清空，只留摘要。2.
Summarize up to here（从选定位置往前压缩）
操作 ：选中某条消息，它之前 的所有对话全部压缩成摘要，它及之后的内容原封不动。
典型场景（长途试错后找到正解）：
你在前半段花了大把 Token 踩坑、排查各种报错，最后终于锁定了正确方案。
此时前面几十轮排错过程已经没用了，你想腾出 Context 空间。就可以在正解起点点击
Summarize up to here，把前面漫长的试错杂音压缩掉，保留当前正在推进的最新实现细节。
1.
/rewind能恢复什么？
- 只要文件是通过 Claude 自带的文件编辑工具（如
Edit、Write）修改的，/rewind就能完美地将它们回滚到对应快照时的状态。2. 为什么你的记忆里觉得"必须靠 Git"？（它的三大盲区）
正因为
/rewind并不是万能的，在很多真实场景下它确实无能为力，必须依赖 Git 或其他手段：
无法追踪 Bash 命令的破坏 ：如果 Claude 是通过运行 Shell 脚本、
rm、mv、cp或一些自动化迁移脚本来修改/删除文件的，/rewind是无法恢复这类文件变动的。生命周期短暂：这些快照只随当前的 Session 保存（默认大约 30 天清理），属于临时状态，不能替代长期的版本管理。
外部干预盲区 ：如果你自己手动在 IDE 里改了文件，或者在其他终端里做了修改，
/rewind同样无法感知和恢复。对于 Claude 直接用编辑工具写的小范围代码改动，可以用
/rewind快速撤销；但如果涉及到复杂的 Shell 脚本执行、批量重构、外部修改或长期的项目历史安全网，Git 依然是不可替代的终极保障。
2.CC的上下文窗口包含哪些组成部分？上下文满了应如何处理？
一、 上下文窗口的 6 大组成部分拆解
组成部分 Token 开销/预算 包含内容与底层机制 变化频率/特点 1. System Prompt 12,000 ~ 15,000 token 核心指令、行为规则、权限模式。分为全局静态半区 （固定规则）和用户动态半区 （如环境变量、机器信息），中间使用 SYSTEM_PROMPT_DYNAMIC_BOUNDARY作为边界标记。极高稳定区（通过边界标记保护缓存） 2. Tool Definitions 约 8,000 token 40+ 个内置与自定义工具的 JSON Schema（如 Read、Edit、Bash等定义），支持延迟加载。相对固定区（除非工具增减） 3. Project Context 动态（由项目规约决定） CLAUDE.md内容 +MEMORY.md前 25 行（受 25KB 限制）+ 未限定路径的 rules，在 session 开始时一次性加载。初始化决定，中途极少改变 4. Conversation History 持续增长 用户消息 + Claude 回复 + 所有工具调用的输入和输出（包含大段的终端报错或文件内容）。 唯一持续增长的区域，消耗 Token 的绝对主力 5. System Reminders 0.2 ~ 2K token / 轮 包含约 50 种类型的动态注入片段，插在对话中间位置用于防止长对话下模型"遗忘"规则（强化上下文）。 随轮次动态插桩 6. Current User Message 动态 当前轮次用户刚刚输入的指令/ Prompt。 逐轮更新 二、 上下文窗口的工程对抗逻辑
固定开销已占掉近 15%（约 25K~30K Token）
光是 System Prompt + Tool Definitions + Project Context 这前三项静态内容，刚启动就吃掉了 200K 预算里的 3 万左右 Token。
这也是为什么
MEMORY.md必须强行截断 25KB（200行）、CLAUDE.md建议控制在 100~200 行以内的根本原因------静态部分膨胀，留给动态推理和历史记录的空间就会被剧烈挤压。Conversation History 是真正的"空间杀手"
每次 Agent 跑
Grep搜出 500 行代码，或者调用Bash打印几百行日志，这些输出都会原封不动塞进 Conversation History 里。如果不加以控制，几十轮交互后上下文就会瞬间逼近 200K 极限，此时就需要依赖
/compact（全量压缩）或定向Summarize（精准裁剪）来释放空间。System Reminders 的防遗忘补丁
- 因为随着对话增长，开头的
CLAUDE.md规则容易被长历史冲淡，CC 会在对话中间定期动态插桩System Reminders（比如："记得遵守你的代码格式约定"），用微小的 Token 开销（0.2-2K）拉回模型的注意力。
3.CC的上下文治理策略？如何保持有效上下文？
