上午让 AI 改一个功能，它思路清晰、一步到位。下午继续，画风突变：改错文件、忘记你十分钟前刚说的约束、把之前修好的 bug 又改了回去。你盯着屏幕怀疑模型是不是降级了，甚至认真考虑换一个。
先别换。这个现象有个名字，而且有解法——大概率你只需要清一下上下文。这篇讲清楚三件事：AI 为什么会越用越钝、什么时候该动手清理、以及清理的五种手法各适合什么场合。
为什么会变钝：上下文也会“腐烂”
先补一个背景。上下文是模型每次推理时能看到的那一大摞内容——你的对话历史、它读过的文件、跑过的命令输出，全在里面。第 1 篇算过这笔账：你输入的几个词，到了模型那里是几千上万个 token。
关键在于：这一摞东西越多，不是知道得越多，而是每一样被看得越淡。
原因在注意力的工作方式。开发者 Matt Pocock 打过一个很形象的比方：给大模型加一个 token，就像给足球联赛加一支球队——联赛的比赛场次不是线性增加，是平方级增长的，因为每两支队之间都要踢。注意力关系也是如此：每个 token 都要和所有其他 token 建立联系。东西越堆越多，模型的“火力”被摊得越来越薄。
它还有一个更直观的表现：失败的尝试也是上下文。AI 钻过的死胡同、改错的文件、报错的输出，只要没清理，全都躺在那里。它每做一轮新决策，都得先从这堆废墟里扒拉出正确的那条路。经验越多越累——说的是人，也说的是上下文里的模型。
这个现象社区里叫 context rot（上下文腐烂）。而“从多少开始烂”，有一组被广泛引用的数字。
40% 法则：一条该记住的水位线
HumanLayer 的工程师 Dex Horthy 在一场社区分享里给过一个量化判断：上下文用到 40% 左右，就开始进入“变笨区”（dumb zone）——输出质量肉眼可见地下降。
他的建议按熟练度分了两档：
- 新手：尽量守在 40% 以下；摸到 60%，就该考虑收尾这一轮了；
- 老手：激进地压在 30% 以下——只有简单任务才允许水位涨到 60%。
有意思的是 Matt Pocock 补充的另一个观察：他后来干脆用“10 万 token”代替百分比当标记——因为不管你的窗口是 200k 还是 100 万，注意力稀释的规律都差不多，绝对水位到了某个量级，谁都会变钝。
所以这两个数字可以互相校验：40% 是相对刻度，10 万 token 是绝对刻度。窗口小的模型，40% 先到；窗口大的，10 万 token 先到。哪个先到听哪个。
用 /context 命令（或自己配一条 statusline，Boris 也推荐这么做）随时看水位，是这套法则的使用前提。看水位这件事本身，花不了你五分钟设置。
每一轮结束，都是一个岔路口
知道该清了，接下来是怎么清。Thariq 在内部分享里给过一个我觉得是本篇最重要的思维模型：Claude 每跑完一轮，你都站在一个岔路口上——不用惯性思维顺手往下打，先看一眼水位，再选路。
岔路有五条：
第一条：继续。 结果不错、水位也健康，就顺着往下走。顺风局最忌讳乱动作。
第二条：/rewind——倒带。 走岔了别原地修补。双击 Esc 打开 rewind 菜单，回到出错之前那个点，带着你刚学到的教训重新下指令。Thariq 把这条原则说得很直白：rewind 优于纠正——在失败上叠补丁，错误和纠正会一起污染上下文；倒带重来，废墟根本不会产生。
第三条：/compact——压缩着继续。 方向是对的，但对话太长了。/compact 把历史压成摘要，细节有损，势头还在，适合任务干到一半舍不得断的时候。它还支持带提示：/compact 专注登录重构的过程，丢掉调试报错的细节——你来决定保什么、丢什么。
第四条：/clear——下一件事，开新局。 彻底清空上下文，配一段高质量的任务简报重新出发。比 /compact 费事，但每一行带进新会话的内容都是你亲手挑的——高风险的下一步，值得这份讲究。顺带纠正一个常见误解：/clear 之后上一段对话并没有被删掉，它作为独立会话保留着，/resume 随时可以回去翻旧账。
第五条：派分身。 重活、脏活外包给子代理，过程留在它自己的上下文里，主对话只收结论——第 4 篇讲过的上下文经济学，这里正是它最主要的用武之地。
选哪条，判断标准就一个问题：**下一件事，需要多少旧上下文？**全都还需要但太长了，压缩；只需要结论，清空；方向错了，倒带；需要的是过程之外的一切，外包。
交接术：让 Claude 给自己写遗书
清空和倒带都有一个共同的顾虑：脑子里那些没落盘的东西怎么办——刚踩过的坑、口头约定的方案、调试到一半的线索。
Thariq 给了个非常优雅的动作：在 /rewind 或 /clear 之前，先让 Claude 自己写一份交接摘要。你可以就说一句“从这里开始总结一下当前进展和注意事项”，它会把关键上下文浓缩成一段话。你把这段话贴进下一个会话的开头，或者干脆存进项目里。
他的原话把这招形容成“给上一个自己留的便条”——就像穿越剧里，未来的自己给过去的自己递了一张纸条：哪些路是死的、哪个文件有雷、方案定到哪一步。上一段会话清掉了，这段便条还在。
配合第 2 篇的思路用更顺：会反复用到的东西，别靠交接便条，写进 CLAUDE.md 或 rules——便条管这一次交接，落盘的规矩管每一个新会话。
自动压缩是安全气囊，不是日常操作
Claude Code 有自动压缩（auto-compact）：水位接近上限时会自动触发，把历史压成摘要，默认不用你操心。settings 里甚至能调触发窗口。
但 Thariq 提醒了一个时机问题：自动压缩触发的时刻，恰恰是模型状态最差的时刻——上下文已经涨到开始腐烂，这时候压出来的摘要，质量也高不到哪去。所以老手的做法是盯着水位手动压（还带提示保重点），把自动压缩当成忘了看水位时的安全气囊。
安全气囊的 meaning 是兜底，不是驾驶方式。这条对上下文管理同样成立。
收工清单
- AI 越用越钝不是错觉，是 context rot：失败尝试和工具输出全在稀释注意力
- 40% 是相对刻度，10 万 token 是绝对刻度，哪个先到听哪个；用
/context或 statusline 盯水位 - 每轮结束看一眼岔路口：继续、/rewind、/compact、/clear、派分身
- rewind 优于纠正：回到岔路口带教训重来，别在错误上叠补丁
- /compact 带提示用（保什么、丢什么你说了算），别干等自动压缩在最笨的时刻触发
- /clear 不删历史，旧会话可 /resume；高风险的下一步，用 /clear 加亲手挑的简报
- 清理前先交接：让 Claude 总结进展，便条贴进新会话；反复要的东西落盘进 CLAUDE.md
至此，配置侧的地基（记忆、三大原语、Hooks、权限）和这套日常维护的手艺都齐了。下一篇进入实战：把 Command、Agent、Skill 串成一条完整的流水线，手把手搭一个真实能跑的编排系统。