AI 越聊越蠢，不是模型不行，是你把上下文喂脏了

用 AI Coding 工具一段时间之后，大概都遇到过这种情况：聊到一半，它突然开始犯低级错误，之前说好的约定不认了，改过的文件又改回去了。

Claude Code、Cursor、Qder、Codex，工具不同，症状类似。

第一反应是上下文不够长。200K tokens 还不够？

够了。问题不在长度，在噪声。

三层噪声，层层叠加

上下文这 200K tokens 不是全归你用的。

第一层：工具定义的固定开销。 每接一个 MCP Server，它带的工具定义就常驻在上下文里。一个典型的 MCP Server 包含二三十个工具定义，每个大约 200 tokens，合计五六千。接 5 个，光工具定义就占掉两万五千 tokens，还没开始干活就去了 12.5%。

Cursor 的 Rules、Qder 的 Rules，本质一样。规则写得越长，常驻开销越大。

第二层：工具输出的动态噪声。 跑一次测试，完整输出几千行。AI 真正需要知道的就是”过了还是挂了，挂在哪”，其余都是噪声。但只要出现在上下文里，就是实实在在的 token 消耗。

第三层：压缩机制的误伤。 上下文快满时，系统会自动压缩。默认逻辑是按”能不能重新读取”来判断优先级，早期的文件内容会被先删。问题是，你在第一个小时定下的架构决策、模块边界，也可能一起被扔了。两小时后 AI 再改代码，完全不记得之前定了什么。

三层叠加的结果：上下文满了不可怕，可怕的是上下文脏了。 有用信息被噪声淹没，AI 做决策时参考的是一堆垃圾，能不犯错才怪。

五个治理方法

知道问题在哪，治理思路其实不复杂。

一、子任务做上下文隔离。 这是我觉得最有用的一条。扫代码库、跑测试、做 Code Review 这类会产生大量输出的事，不要在主对话里做。派一个子任务去干，干完拿一个摘要回来。

这背后还有个技术原因：AI Coding 工具普遍依赖 Prompt 缓存来加速响应，缓存是按前缀匹配的。主线程的前缀越稳定，缓存命中率越高，响应越快。一旦往主线程里灌大量工具输出，前缀变了，缓存失效，不仅上下文脏了，速度也慢了。子任务隔离的不只是噪声，还保护了主线程的缓存。

我现在的习惯是，凡是预期输出超过一屏的操作，都丢给子任务。主线程只做决策和协调。

二、主动管理会话生命周期。 不要等系统自动压缩。任务切换时清空会话，同一任务进入新阶段时手动压缩。长会话质量下降，本质是中间产物把上下文污染了。换个干净的会话，比在脏上下文里反复调 Prompt 有效得多。

三、探索和执行拆开。 改一个复杂模块之前，先让 AI 只读不写。看完代码、理清依赖、列出方案，确认了再动手。探索阶段产生的大量文件读取不会污染执行阶段的上下文。

四、限制工具输出长度。 跑测试、查日志的时候，加一个 | head -30 或者只输出失败的部分。看起来是小习惯，但在 100 次编辑的会话里，每次少塞几千 tokens 的噪声，累积下来差别很大。

五、给压缩写说明书。 在项目配置文件里加一段压缩指引，告诉系统哪些信息必须保留。架构决策、模块边界、关键约定，这些一旦被压缩掉，后续所有操作都在错误的基础上进行。另一个做法是开新会话前让 AI 先写一份进度文档，新会话读这份文件就能接上。

不是模型不聪明

回头看，AI Coding 工具大多数”不听话”的情况，不是模型不够聪明，是我们给了它错误的上下文。

结果不稳定，查上下文里有没有噪声。长会话质量下降，看有效信息是不是被中间产物挤掉了。产出越来越离谱，可能是压缩把关键约定删了。

治理上下文比扩大上下文重要得多。 200K tokens 够用，前提是你别让噪声先把它占满了。

以前写代码拼手速，现在拼上下文管理。关注 YannTalk，继续拆 AI Coding 的工程实践。