![[AI 上下文 #3] /clear 与 /compact 的选择标准 封面图](/assets/images/posts/dbbbbbf4-c659-46d5-8a59-05ef8e331a0d/1.jpg)
前两篇已经完成诊断。上下文窗口是有限的（第 1 篇），填满并不意味着所有内容都会被使用，而且越长性能反而越差（第 2 篇）。因此解决方案很明确：必须管理上下文。包括 Claude Code 在内的编码代理，为此提供的最基本工具就是 /clear 和 /compact。
两个命令都有“减少上下文”这一点。因此，很多人会随便使用其中一个，或者等到出现剩余量警告才使用。但它们的工作原理完全不同：在不合适的场景下使用，可能会丢失整个任务上下文，也可能反过来一直携带混乱的上下文。本篇将先准确了解两个命令在内部做了什么，再确定什么时候该用哪个。
/clear：删除历史，从空白开始
/clear 的工作方式很简单：丢弃截至目前的全部对话历史。下一轮的模型只会带着系统提示、CLAUDE.md 等始终加载的文件，以及你刚输入的新消息开始工作。回想第 1 篇中的结构，含义就很清楚了：既然对话的实质是每轮重新发送完整历史，删除历史就意味着重置发送给模型的数据包。
失去的是全部对话上下文，得到的是干净的上下文。第 2 篇提到的 lost in the middle，以及旧文件版本和失败日志造成的混乱，都会随着历史消失。Token 余量完全恢复，每轮重新发送的输入也减少，因此响应更快，成本更低。
因此，/clear 适合用于任务边界。修复一个 bug 并完成 commit 后，下一个功能不需要知道前一个 bug 的 stack trace 或试错过程。混在一起只会造成伤害。每次任务结束都用 /clear 切断上下文，就能避免会话后半段相当一部分的质量下降。
/compact：用摘要替换历史
/compact 采用不同的方法。它不是丢弃历史，而是让模型总结截至目前的对话，再用摘要替换原始历史。数万 token 的历史会缩减为几千 token 的摘要，在恢复余量的同时保留任务主线。
关键在于，这是有损压缩。摘要过程由模型选择“看起来重要的内容”，用户无法控制哪些内容会保留下来。文件路径、尝试后放弃的方法、错误消息的准确措辞等具体细节，很容易在摘要过程中变得模糊。compact 后代理会立即重新读取刚才处理的文件，也是因为仅凭摘要无法准确了解当前状态。
幸运的是，并非完全没有控制手段。Claude Code 的 /compact 后面可以附加指令。例如输入“/compact 重点保留本次迁移中已确定的架构变更和剩余文件列表”，就能指定摘要重点。用户最清楚什么重要，所以即使交给模型压缩，也要给出方向。
选择标准：是否有需要延续的上下文？
标准可以归结为一个问题：下一轮的代理是否需要了解截至目前的上下文？
- 任务已完成，下一项任务彼此独立 → /clear。不必犹豫，这就是默认选项。
- 同一任务仍在继续，但余量不足 → /compact。不过，要在指令中指定需要保留的内容。
- 任务相同，但代理开始原地打转 → 出乎意料地，/clear 更好。被试错污染的上下文即使经过摘要，也只会浓缩污染。让代理把当前状态和下一步整理到文件中，然后使用 /clear，通过该文件重新开始，会更干净。
第三种情况提供了线索。clear 与 compact 之间还有第三条路：把上下文中值得保留的内容写入文件。让代理“把目前为止的决策和剩余工作整理到 PLAN.md”，然后执行 /clear，在新会话中读取 PLAN.md，就能避开摘要的不确定性，准确传递必要的上下文。不同于把保留内容交给模型的 /compact，保留内容存在于可见文件中，因此既能验证也能修改。这种“外化”模式会在第 6 篇讨论内存时进一步展开。
为什么不应等待 auto-compact
当余量达到阈值时，Claude Code 会自动执行 compact。它是很好的安全机制，但依赖它则是另一回事。
auto-compact 的触发时机由 token 余量决定，与工作流无关。它可能在最糟糕的时机进行压缩：重构进行到一半、五个文件正在修改、测试已经失败。此时的摘要会把尴尬的中间状态混在一起，之后的代理会带着细微偏差的理解继续工作。第 2 篇提到的 context poisoning，就这样通过摘要发生了。
因此，越有经验的开发者越会像管理仪表盘一样管理余量。在 commit、测试通过、决策确定等逻辑节点，把状态整理到文件中；当余量剩下 20～30% 时完成收束，由自己决定 /clear 或 /compact 的时机。即使压缩不可避免，也要控制它何时、如何发生。
总结
- /clear 删除历史，/compact 用摘要替换历史。前者丢弃上下文并最大限度恢复余量，后者保留上下文主线，但会损失细节。
- 默认做法是在每个任务边界使用 /clear。只有在需要延续上下文时才使用 /compact，并在指令中指定要保留的内容。
- 代理开始原地打转时，让它把状态整理到文件中，再用 /clear 重新开始，通常比摘要更干净。
- auto-compact 只是安全机制，最好根据任务节点自行决定压缩时机。
以上就是对话历史管理。不过，有些上下文即使使用 /clear 也不会消失，而是每轮都会随请求发送：系统提示、CLAUDE.md、工具定义等始终加载的区域。下一篇将讨论如何设计这项固定成本。核心是决定 CLAUDE.md 中该放什么、该删掉什么。