Claude Code 上下文管理：何时用 /clear，何时用 /compact | Tim Schipper

HN AI Tools 2026-08-08T00:52:27.097742

原文：

运行 /context，查看一个从早上持续到现在的会话。我的会话显示一大片空闲空间。没有警告，没有压缩提示，没有任何红色标记。

但这个会话的状态其实比早上九点时更糟糕。只是那个指标条没法告诉你这一点。

性能衰减早在窗口占满之前就开始了

Chroma 的 context-rot 研究测试了 18 个前沿模型，发现随着输入变长，所有模型的可靠性都会下降，哪怕任务是像重复单词这样简单的事情。他们的 LongMemEval 测试最能说明问题：同一个问题，分别用聚焦的约 300 token 提示词回答，和从它被埋没的约 113k token 完整对话中回答。两者的信息完全一样，答案差距却很大。

NoLiMa 给出了性能开始下降的具体数值。在 13 个声称至少支持 128k 上下文的模型中，有 11 个在 32k token 时就已经跌落到其短上下文基线水平的一半以下。GPT-4o 从 99.3% 降到了 69.7%。

三万二千个 token。放在 1M 的窗口里，这才刚走了百分之三。

Anthropic 把这种机制描述为注意力预算：每个 token 都要和所有其他 token 进行交互，所以 n 个 token 意味着 n² 对关系，每新增一个 token，都要从有限的预算中支取。他们自己的建议是，找到一组最小的高信号 token 来完成任务。在一百万 token 窗口的宣传旁边发这样的建议，有点奇怪，但也是对的。

长会话对代码做了什么

SlopCodeBench（arXiv 2603.24755，2026 年 3 月）是我一直期待的相关研究。它不用一次性基准测试，而是让智能体在 93 个检查点上不断扩展自己之前写的代码，需求不断演变，而且轮次之间不会交回修正后的参考实现。测试了 11 个模型，从 Sonnet 4.5 一直到 Opus 4.6 和 GPT-5.x 的 Codex 变体。

正确率数据本身就够难看的：没有哪个智能体完整解决过任何一个问题，最好的检查点解决率只有 17.2%，到了最后一个检查点，严格解决率直接崩到 0.5%。一个问题的成本涨了 2.9 倍，正确率却没有提高。

质量数据才是真正应该改变你使用习惯的部分：

这些正是我在前文「超越覆盖率与变异测试的仪表盘」中写过的同套工具：复杂度集中度与克隆检测。把它们对准一个漫长的代理会话，读出来的就是一条下滑曲线。

论文也尝试了显然该试的修复方案。质量感知提示词将 GPT-5.4 的初始冗长度降低了 34.5%，但退化斜率依旧平行。你得到了更好的起点，却仍面临同样的下滑。会话长度才是关键杠杆。

长会话的好处是真实的

2026 年 3 月的一篇论文论证了编码代理是高效的长上下文处理器，在三万亿 token 级别的语料上比已发表的最佳水平高出 17.3%。这是篇好研究，在你站到我这边之前值得一读。

但要看它赢的方式。代理将文本组织成文件系统，用普通工具进行操作。语料保留在磁盘上，窗口只承载工作集。这个结果并不能证明臃肿的窗口没问题，恰恰证明大量内容该放进文件系统。

这正是从另一方向得出的相同结论。

/context 实际衡量什么

在 Claude Code 2.1.220 中，/context 把你的窗口拆成命名类别：系统提示词、系统工具、MCP 工具、自定义代理、记忆文件、消息、空闲空间，以及大多数人会划过去的一行——「自动压缩缓冲区」。状态读数告诉你距离自动压缩的百分比，该行下方还有一条「上下文不足」的警告。

那行缓冲区才是真正有用的信息。它是你无法动用、被预留的空间，目的是在关键时刻让模型仍有足够余地给自己写一份摘要。你的可用窗口比包装盒上的标称值小，而且从来都是如此。

/doctor：审视你的环境加载

/doctor 命令负责的是另一半审查：在你输入任何内容之前，你的安装版本到底往每个会话里加载了什么。它只做基于磁盘的估算，然后明确把你指向 /context 去查看实时测量结果。安装卫生和会话卫生是两个不同的问题，而其中只有一个有对应的"检查工具"。

/compact 是模型在给自己做总结

把压缩提示词从二进制文件里抽出来看，设计思路就一目了然了。一共有三个变体：一个负责总结整个对话，一个在保留早期前缀的情况下只总结最近的部分，还有一个专门放在续接会话的开头位置。

三个变体都要求相同的八个部分：主要请求和意图；关键技术概念；文件和代码段（要带完整代码片段）；错误与修复；问题解决过程；所有用户消息；待办任务；当前工作。

这个规范相当细致。但你要知道：做总结的模型，是在你已经怀疑上下文已经劣化的情况下，给自己这场会话打分，而没有被选入这八个类别的任何内容，都会被丢掉。

提示词里有两个细节值得你注意。第一，总结器被要求逐字保留涉及安全性的用户指令，确保它们在总结后仍然有效——这直接告诉你，约束条件在重新编码的过程中是有可能消失的。第二，它被警告不要把助手消息里形似对话记录的文本归因给用户，因为总结这种东西，恰恰是那些想往你下一个窗口里掺入伪造指令的行为最喜欢的目标。

接下来，恢复会话的提示词会告诉模型：接着干，别理会那份总结，就好像中间从未中断过一样。这是刻意设计出来的顺畅感。你不会感觉到那道接缝——而正因如此，你才不应该让它在无人看管的情况下自动发生。

早清空、少压缩、简报自己写

自动压缩会在你几乎用完上下文空间的时候触发。也就是说，这份总结是由整场会话最差劲的版本写出来的——那时早就过了 32k 标记，准确性已经开始下滑。如果你确实要压缩，应该趁还有余量的时候主动做，趁记忆还清晰的时候做。

更好的做法是：根本不需要它。在任务边界处执行 /clear，把需要保留的东西写进文件，而不是留在一段摘要里。CLAUDE.md 才是跨会话留存的记忆——它不同于压缩摘要，是你亲手写的，你能读懂它，哪一行写错了也能直接删掉。但注意，只写那些智能体无法从代码仓库自行推断的约定、坑点和设计理由，否则六周后你会得到一份「自信地胡说八道」的记忆。

我实际遵循的规则是：

写这段说明只需要两分钟，而且它是比任何自动生成的摘要都更好的产物——因为你知道当时真正重要的是哪四件事，而模型在猜另外八件。

「一个任务一个干净会话」说起来容易，可当你同时想跑三个任务时就犯难了。这正是 git worktrees 的用武之地，不过有个前提：它只隔离你的文件，其他方面几乎什么都没隔离。

这里的度量问题，和生成代码面临的是同一个。工具就在那里，免费，但没人打开看——因为还没出过事。

查看原文