为什么压缩后的会话感觉像失忆
Anthropic 毫不委婉地描述了这一过程：Claude Code “首先清除较旧的工具输出，然后在需要时对对话进行总结。您的请求和关键代码片段将被保留；对话早期的详细指令可能会丢失。”
最后那句话就是全部体验的写照。摘要在特定方向上是有损的——它保留了发生过的事情的轮廓，却丢掉了你早期所说内容的精确度。你在第三分钟提到过一次的约束，恰恰是摘要会压缩的那种细节，而且没有任何通知会告诉你丢掉了什么。
但并非所有内容都会经过摘要生成器。Anthropic 发布了一张按机制分类的表格，说明了压缩后每种内容会发生什么，其中最有趣的栏目是那些完全不触及摘要的内容：
系统提示词和输出样式：“两者仍然适用。”项目根目录的 CLAUDE.md 和未指定范围的规则：“从磁盘重新注入。”自动记忆（Auto memory）：“从磁盘重新注入。”Claude 在计划模式下编写的计划：“从磁盘重新注入。”带有 paths: 前置元数据的规则：“当 Claude 读取它们匹配的文件时，Claude Code 会重新加载它们。”子目录中嵌套的 CLAUDE.md 文件：“当 Claude 读取该子目录中的文件时，Claude Code 会重新加载它们。”Claude 读取或编辑过的文件：“Claude Code 会重新读取最多五个文件，最近修改的优先。”
请把这个列表看作是一个设计指令，因为它确实是。磁盘上的任何内容都会恢复。任何仅因为你将其输入到对话中而存在的内容都会被总结摘要。Anthropic 在几行前用自己的话阐明了这一结论：“将持久规则放在 CLAUDE.md 中，而不是依赖对话历史记录。”
这也是为什么长上下文不等于记忆的真实答案——这一点不仅适用于这一个工具，我们在为什么长上下文窗口不是记忆中也阐明了这一观点。
人们尝试的其他替代方法
在压缩前启动新会话。 这确实有效，但它会把你想要保留的对话部分与不想要的对话部分一起丢弃。它还会把问题转移到下一个会话，而新会话开始时没有任何历史信息——这就是在 Claude Code 会话之间共享上下文背后的协调问题。
关闭自动压缩。 这是可行的，其后果也有文档记录：“关闭自动压缩后，会话将在 200K 边界处停止并提示上下文限制错误，而不是进行压缩。”你并没有避开这个边界；你只是用硬停止代替了有损摘要。
将窗口调到最高。 这也有文档记录，并且同样有上限：“将自动压缩窗口设置在 200K 以上并不能解除限制，因为 Claude Code 会将该窗口限制在模型的上下文窗口内。”该窗口只是真实限制的一部分，而不是绕过它的方法。
假设默认值是一个固定数字。 它取决于模型和环境。Anthropic 的基准是，在没有设置的情况下，“当对话达到模型的上下文限制时，Claude Code 会进行压缩”，并列出了云端会话、在 200K 边界处压缩的几种模型，以及具有原生 1M 窗口的模型的例外情况，后者“在窗口填满之前进行压缩，默认在大约 967K token 处”。
盲目运行 /compact。 总比什么都不做强，如果加上焦点（focus）会好得多，而这是大多数人从未发现的控制项。
在每次压缩后重新粘贴约束。 这种临时应对方法揭示了真正的解决方案：如果一个规则在摘要后需要重新陈述，那么它就应该放在磁盘上。同样的直觉也适用于人们不断向上滚动寻找的命令历史记录，我们在为什么 Claude Code 会丢失你之前的命令中探讨过这个问题。
解决方案：刻意设置触发器，然后告诉摘要生成器什么重要
两个控制项，按以下顺序使用。
步骤 1：将必须保留的规则放在磁盘上，而不是对话中
这是最具杠杆效应的一步，而且不需要任何成本。项目根目录 CLAUDE.md 中的任何内容和未指定范围的规则都会在压缩后从磁盘重新注入。自动记忆会从磁盘重新注入。在计划模式下编写的计划会从磁盘重新注入。当 Claude 读取匹配的文件时，路径范围的规则会重新加载；当 Claude 读取该子目录中的文件时，嵌套的 CLAUDE.md 文件会重新加载。
因此，实用的规则是：如果你发现自己在一次会话中说了两次同样的话，它就应该写入 CLAUDE.md，而不是作为消息发送。这会将其从摘要可能压缩的内容转变为每次都会逐字重新加载的内容。
然后添加直接与摘要生成器对话的控制项。Anthropic 表示：“要控制压缩期间保留的内容，请在 CLAUDE.md 中添加 'Compact Instructions'（压缩指令）部分，或运行带有焦点（focus）的 /compact（例如 /compact focus on the API changes）。”'Compact Instructions' 部分是该项目中每次未来压缩的常设简报——写一次，用三四行指明必须保留的内容。
步骤 2：选择在哪里设置窗口，并了解哪个设置优先
Anthropic 记录了三个地方，它们之间的覆盖顺序是明确的。
对于当前会话及以后的会话，运行带有数值的 /autocompact。Claude Code “将其作为 autoCompactWindow 保存到您的用户设置中，并应用于当前会话”——在调试前值得了解的一个警告是：“如果高优先级设置范围（如托管设置）设置了该键，该命令会保存您的值，但会话将保留该范围的窗口，并且该命令会说明这一点。”运行 /autocompact auto 可返回“为您的模型调整的窗口”。
对于单次启动，传递 --autocompact 标志，它“会覆盖该次启动的已保存设置，而不会更改它”。该标志具有命令所不具备的属性：“与 /autocompact 不同，该标志不会被高优先级设置范围（如托管设置）抢占。”
对于脚本和云环境，设置 CLAUDE_CODE_AUTO_COMPACT_WINDOW 环境变量。它高于一切：“设置它后，它优先于命令、标志和设置，并且 /autocompact 会报告覆盖情况，而不是更改窗口。”
三个杠杆，一个顺序：环境变量优于标志优于命令优于已保存设置，其中托管设置可以抢占命令但不能抢占标志。如果你的窗口不是你设置的值，那么这个列表就是调试顺序。
步骤 3：识别意味着窗口不是问题的错误信息
有一条消息值得单独列出一步，因为它会把人们引向错误的控制项。Anthropic 表示：“如果您看到 Autocompact is thrashing: the context refilled to the limit...（自动压缩正在抖动：上下文重新填满至限制...），说明自动压缩成功了，但文件或工具输出立即连续多次重新填满了上下文窗口。Claude Code 停止重试，以避免在没有进展的循环中浪费 API 调用。”
抖动（Thrashing）意味着压缩起作用了，但某些巨大的内容立刻又跑了回来。调大窗口没有帮助；解决办法是阻止重新填满。Anthropic 自己的建议是进行有针对性的压缩，丢弃违规内容——“运行带有焦点的 /compact 来丢弃大型输出，例如 /compact keep only the plan and the diff。”
还有一个伴随消息也值得识别：如果 /compact 返回 “Not enough messages to compact.”（没有足够的消息可压缩。），则说明对话“轮次太少，无法总结；即使在上下文已满的情况下，如果单个大型粘贴填满了它，也可能会发生这种情况。”相同的诊断，不同的症状——问题在于单个对象，而不是窗口。
在 MemoryLake 中进行设置
上面的每一步都是将事实从对话中转移到更持久的地方，而 CLAUDE.md 的持久性仅限于一台机器上的一个仓库。MemoryLake 是一个由你自己写入更长生命周期事实的存储库，它独立于任何会话，并且可以从你连接的每个助手读取。你用自己的语言自己编写这些条目。没有任何内容会从 Anthropic 的系统或任何其他供应商的存储中读取、写入或删除——你的会话、转录和规则文件完全保留在 Claude Code 自己的控制之下。
步骤 1：创建 API 密钥
从控制面板生成一个密钥。正是它让当前会话、下次压缩后的会话以及另一个仓库中的会话能够访问相同的事实集。
步骤 2：上传你的第一批记忆
从你在压缩后重新陈述过的事情开始：约束、决定及其原因、已被排除的方法。十几个简短的条目通常就能覆盖一个项目。将它们写成带有日期的陈述，而不是叙述性文字。
步骤 3：连接你的 AI 和智能体
将 Claude Code 指向该层，以便这些事实在会话开始时加载，而不是在摘要中幸存。然后以能够证明效果的方式进行测试：刻意压缩一个会话，并要求找回其中一个事实。如果它能回答，压缩就不再是决定你保留什么的关键了。
这在实践中带来了什么改变
第一个改变是压缩不再让人感觉是随机的。它在你可检查和设置的窗口触发，它在总结对话的同时重新注入文件，并且在发生抖动时会告诉你。这是三种不同的行为，有三种不同的应对方式。
第二个改变是 CLAUDE.md 得到了正确的使用。一旦重新注入表呈现在你面前，该文件就不再是存放项目琐事的地方，而是成为了“什么必须在摘要中幸存”的答案——其中 Compact Instructions 部分是通往摘要生成器的直接通道。
第三个改变是长会话重新变得可行。每小时重新开始的本能来自于对压缩的不信任；引导它比避开它成本更低，而且它保留了新会话会丢弃的连续性。在分叉（split）确实是正确选择的情况下，那是一个具有不同继承规则的不同操作，我们在分叉的 Claude Code 会话携带了什么中对此进行了阐述。
第四个改变是错误消息变得有用。抖动和“没有足够的消息可压缩”都指向一个超大对象，而不是你的设置，了解这一点可以省去一下午调整错误数字的时间。关于压缩过程应该允许丢弃什么的更广泛问题，我们在另一个工具的决定什么在压缩中幸存中进行了探讨。
Claude Code 压缩的最佳实践
说两次，就写下来。 你在会话中重新陈述的任何内容都属于 CLAUDE.md，它会从磁盘重新注入，而不是被总结摘要。
为每个项目添加 Compact Instructions 部分。 这是带有焦点的 /compact 的常设版本，适用于未来的每一次压缩。
在调整前了解覆盖顺序。 环境变量，然后是启动标志，然后是命令，最后是已保存的设置——并且托管设置可以抢占命令。
使用 /autocompact auto 恢复正常。 它将会话返回到为你的模型调整的窗口，而不是你曾经选择的某个数字。
将抖动视为内容问题。 压缩成功了；某些庞大的内容重新填满了窗口。通过有针对性的压缩丢弃该对象。
将跨会话事实保留在仓库之外。 CLAUDE.md 在项目内的压缩中幸存；它不会传播到其他项目或其他工具。
结论
Claude Code 的自动压缩有两个控制拨盘，而大多数人两个都不用。触发器是自动压缩窗口，可通过 /autocompact、--autocompact 标志或 CLAUDE_CODE_AUTO_COMPACT_WINDOW 进行设置，它们之间有文档记录的优先级，并且上限为模型自身的上下文窗口。内容由磁盘上的内容决定——项目规则、自动记忆、计划模式计划和路径范围规则都会被重新注入——以及由 Compact Instructions 部分或有针对性的 /compact 决定。
丢失的内容被 Anthropic 清楚地阐明：请求和关键代码片段会被保留，而“对话早期的详细指令可能会丢失”。这是摘要的本质，而不是缺陷，供应商自己的建议是正确的：将持久规则放在文件中，而不是依赖对话历史记录。
在此之外的一步很小，但很值得迈出。文件在一个项目内部的压缩中幸存。而你在下个季度、在不同的仓库中、使用不同的助手仍将执行的决定，值得存放在一个任何会话边界都完全无法触及的地方。