有一种情况我相信你一定遇到过。
你在用 Claude Code 处理一个复杂任务——改一个绕来绕去的 bug，或者在一个很深的功能上加新逻辑。一开始它挺好的，分析准确，方向对，你很满意。
但不知道从哪一轮开始，它的建议开始变得有点奇怪。它忘了你之前说过的限制，开始重复已经排查过的方向，或者给你一个和前面完全矛盾的方案。
你以为它「变笨了」。
其实不是。是你的上下文窗口在腐化，而你没有发现。
上下文不是满了才出问题，是在变满的过程中就已经开始出问题了。
上下文窗口是怎么「腐化」的
大多数人对上下文的理解是：有个固定的长度上限，超过了就装不下了，Claude 就开始遗忘。
这个理解没错，但不完整。
更准确的图景是：上下文窗口是一个固定大小的容器，里面装着你们整个对话的历史。随着 session 越来越长，这个容器会越来越满。但问题在于——Claude 处理信息的方式，会随着容器的充满程度而变化。
当容器还比较空的时候，Claude 能很好地关注到你最新说的话，同时保留对整个对话脉络的理解。但当容器接近满的时候，它处理信息的质量会下降——不是突然崩溃，而是逐渐变得「分心」，对早期信息的把握开始模糊，对当前指令的执行开始出现偏差。
这就是腐化。它不是一个临界点，而是一个渐进的过程。
所以你会遇到那种情况：session 没有报错，Claude 还在正常回复，但输出质量已经悄悄下滑了。
两个信号，说明你该管理上下文了
不需要盯着 token 计数器。这两个行为信号比数字更可靠：
信号一：Claude 开始「重复已知信息」
你让它修一个 bug，它在回复里又把问题背景重新解释了一遍——你已经在五轮前说清楚了的东西。这说明它在努力重建对话脉络，而这个动作本身就在消耗它的注意力。
信号二：Claude 的建议开始「走偏」
它给的方案和你之前确定的方向有明显偏差，或者和它自己三轮前说的结论矛盾。不是模型能力下降了，是它对上下文的理解已经开始失真。
看到这两个信号，不用继续硬撑——是时候主动干预了。
/compact 和 /clear：不是同一件事
很多人知道 /clear，但不知道 /compact。这两个命令的作用完全不同，用错场景会白白损失进度。
/clear：清空重来
把当前 session 的所有上下文全部清除，回到一张白纸。适合你确实要开始一个全新任务、和当前 session 毫无关联的时候。
但如果你还在同一个任务里——你改了一半的代码，有一堆中间结论和决策——/clear 会把这些全部丢掉。你得重新交代背景，重新确认方向，重新走到现在这个位置。代价很高。
/compact：压缩保留
这是大多数人不知道的命令。
/compact 会让 Claude 把当前对话的内容压缩成一个摘要，保留关键信息和结论，然后用这个摘要替换掉原来的完整对话历史。上下文窗口的占用大幅减少，但任务上下文得以保留。
简单说：/clear 是清空，/compact 是整理。
在同一个任务里工作了很长时间，感觉上下文开始腐化——用 /compact。要开始一个全新的、毫无关联的任务——用 /clear。
主动管理，不要被动等崩
很多人的习惯是：等到 Claude 的输出质量明显变差，或者直接报上下文超限的错误，才想起来清理。
这是被动策略，代价很高。你已经在一个腐化的上下文里浪费了好几轮对话，花了 token，拿到的是质量下滑的输出。
更好的做法是主动管理。我自己用的节奏是：
- 每完成一个明确的子任务，停下来用 /compact 压缩一次
- 开始一个全新方向之前，用 /clear 清空
- 感觉 Claude 的回复开始「啰嗦」或「走偏」，立刻 /compact
不需要精确计算 token。靠行为信号判断，动作要比问题出现早半步。
一个容易被忽略的进阶用法：/compact 加自定义摘要
/compact 默认会让 Claude 自己决定压缩什么、保留什么。大多数情况下它做得不错，但有时候你可能有特定需求——比如你特别希望它记住某个关键决策，或者某段代码的最终状态。
你可以在 /compact 后面加说明：
/compact 重点保留：我们已经确认用乐观更新方案，不走服务端确认；当前 bug 根因是 race condition 在 useEffect 里
这样 Claude 在压缩时会优先保留你指定的内容，而不是按自己的判断随机取舍。
对于复杂 debug session 或架构决策类对话，这个写法能明显提高压缩后的上下文质量。
最后
上下文管理这件事，说难不难——就两个命令，用对场景就行。但大多数人都是等到 Claude 明显变差了才意识到问题。
从今天开始，试着把 /compact 加进你的工作节奏：完成一个子任务，压缩一次。你会发现长 session 里的 Claude 稳多了。
你现在用 Claude Code 最长的一次 session 跑了多久、多少轮？
更多深度内容与完整文章，欢迎关注我的微信公众号：SamLai 效率研习社
主要分享：
AI 编程与开发效率
技术趋势与工程思考
实用工具与工作流
