夜雨聆风「AI搭档实操系列第11篇」：用 AI 的人都经历过"越聊越蠢"。不是模型变笨了，是上下文中毒了。4 种中毒方式 + 3 条止损心法 + 我的实战诊断记录分享给你。
你有没有遇到过这种事——
跟 AI 聊了三十多轮之后，它开始犯你半小时前就纠正过的错误。你说"别用 class 组件"，它又给你写了个 class 组件。你说"字段名是 account_id 不是 user_id"，它又换回去了。
你心想：这东西是不是越聊越蠢？
答案是：是的。但不是它变笨了——是它的"工作记忆"被你们的对话废料塞满了。
这个概念有个学名，叫Context Engineering（上下文工程）。最近学斯坦福 CS146S 的 Week 3 内容，整周都在讲这件事。课程解读文章原话是：「如果整门课只能深读一周，选 Week 3」，具体见我之前发布的公众号文章，有专门讲Week 3的精华内容。
学完之后我做了一件事：给自己的 AI 做了一次"体检"。
结果发现它同时背着 60 个工具、10 条矛盾规则、7 份重复配置。
怪不得它蠢。换我我也蠢。
01丨Prompt Engineering 是加法，Context Engineering 是乘法
大部分人优化 AI 的方式是调 prompt——换个问法、加个"请一步步思考"、多给几个示例。
这是加法。加一条 prompt 优化一次结果。
Context Engineering 不是优化你怎么问——是优化你给 AI 看到什么。
你精心打磨了一条 prompt，但如果 AI 的上下文里充斥着过时的规则、无关的工具描述和矛盾的信息——这条 prompt 也救不了它。
上下文工程可以拆成 5 个维度：信息选择（给 AI 看什么不看什么）、信息组织（怎么结构化）、信息质量（有没有错误和矛盾）、信息时序（什么时候给什么）、工具配置（通过工具扩展感知范围）。
我搭的 AI 规则体系本质上就是一套上下文工程系统——核心规则最小化常驻加载，业务知识按关键词触发才读取，经验库按需调用不预加载。一度以为自己只是在"整理文件"，学了上下文工程才发现——我是在设计 AI 的感知世界。
但设计得好不够。还得知道它会怎么坏。
02丨4 种上下文中毒方式——你的 AI 就是这么变蠢的
"为什么不把所有东西都扔进 AI 的上下文里？"
这是最常见的误解。现代模型支持百万 token 的上下文窗口，但盲目填满它们会导致 4 种崩溃。
第 1 种：上下文中毒（Context Poisoning）
一旦错误信息进入上下文，AI 会反复引用和放大它。
Google 做过一个实验：让 Gemini 自动打宝可梦。当一条虚假信息进入上下文后，Agent 开始"执着于一个不可能达成的目标"，无休止地重复无效操作——不是因为它蠢，是因为它太听话了，忠实地按照错误信息做决策。
我自己踩过一模一样的坑。让 AI 用 Python 分析一份 Excel 数据，第一轮我描述字段格式时漏了一种分隔符。AI 后面连错三次——第一次只用逗号分隔没处理换行符，修复后只改了一层没贯穿五层，第三次"包含"逻辑还是没到位。
不是它不行。是我第一轮给的信息有毒，后面三十轮都在中毒的基础上打补丁。
对策： 发现对话中有错误信息且已被多处引用——不要在当前对话里修补。开新会话。
第 2 种：上下文分心（Context Distraction）
上下文过长时，模型开始"重复历史行为，而不是综合新策略"。
Databricks 的研究数据：超过 32K token 后，模型正确率显著下降。不是"忘记了"早期信息——是被近期信息分散了注意力，决策质量退化。
你遇到过这种情况吗：跟 AI 聊了 40 轮之后追加了一条新约束，它表面上说"好的明白"，但生成的代码还是按旧逻辑来。不是抗拒你的指令——是上下文里太多噪音了，你的新约束被淹没了。
对策： 一个对话做一个任务。需要切换方向时，开新会话。
第 3 种：上下文混乱（Context Confusion）
太多工具定义或无关信息干扰模型判断。
Berkeley 做了一个工具调用排行榜测试：每个模型在工具数量增加时性能都下降。Llama 3.1 8B 在 19 个工具时正常运作，46 个工具时就开始出错。即使 GPT-4 级别的模型也不能免疫。
Anthropic 在官方工程博客里的原话：「更少、设计良好的工具优于全面的 API 包装器。」
说直白一点：你给 AI IDE 装了 5 个 MCP 插件，总共 60 个工具——写需求单时它能看到设计工具，做数据分析时它能看到代码仓库工具。那些不相关的工具，不是静静躺在那里——它们在占据上下文空间，干扰 AI 对真正需要的工具的判断。
这就是我给自己 AI 做体检时发现的第一个问题。后面细说。
第 4 种：上下文冲突（Context Clash）
来自多个来源的信息相互矛盾时，模型性能断崖式下跌。
微软和 Salesforce 的联合研究量化了这个影响：先给模型部分错误答案、再给完整正确信息——性能平均下降 39%。OpenAI 的 o3 从 98.1 分暴跌到 64.1 分。错误答案留在上下文里，严重干扰了最终判断。
在实际场景里长什么样？你的项目 README 说用 PostgreSQL，但 docker-compose.yml 配置的是 MySQL。两份文件都在上下文里，AI 不知道该信谁——结果生成的代码一半 PostgreSQL 语法一半 MySQL 语法。
对策： 确保所有上下文来源一致。发现矛盾时立刻修复——不要指望 AI 自己"判断哪个是对的"。
还有一个隐形杀手：上下文腐烂（Context Rot）
Chroma 测试了 18 个主流模型，发现一个普遍规律：随着输入长度增加，模型性能显著且一致地下降，即使对极简单的任务也是如此。
更反直觉的发现：一条干扰信息就能显著降低准确率。
一句话总结：不是更多的上下文更好——是更精准的上下文更好。你给 AI 的每条信息都有成本——不仅是 token 费用，更是注意力分散。
03丨我的实战诊断记录
学完这 4 种失败模式之后，我立刻给自己的 AI 做了一次诊断。
发现 1：10 条常驻规则，7 条是重复的旧版
我之前做过一次规则体系重构，把旧版规则文件搬到了 backup 目录。但搬的时候漏了一步——没把旧文件的"始终加载"标记关掉。
结果就是：每次对话开始，AI 同时加载新版规则和旧版规则。两份内容高度重叠但有细微差异。
这就是 Context Clash + Context Distraction 的教科书案例。
修复很简单：把 7 个旧文件的"始终加载"全部关掉。常驻加载文件从 10 个降到 3 个。
发现 2：同时加载 60 个工具
盘了一下我的工具情况：
其中知识库的 34 个工具，我日常只用搜索和读取两个功能——但 34 个端点全部暴露给了 AI。
按 Anthropic 的"精选不堆砌"原则，这明显超标了。34 个工具描述占据上下文空间，干扰 AI 对真正需要的工具的判断。
修复：写了一个代理层iwiki-proxy（具体实践分享请见本系列下一篇），把 34 个工具收敛成 5 个高阶工具。总工具数从 ~60 降到 ~31。
修复之后的体感变化
没有量化数据，但主观感受明显：AI 选对工具的频率提高了，对话中不再频繁出现"调错工具又重来"的情况。 修复前这是经常发生的事。
04丨3 条止损策略
诊断治标，止损治本。
这 3 条策略来自两个团队的实战经验：Cognition（Devin 背后的公司）的 Agents 101 指南，以及 HumanLayer 团队的 ACE-FCA 框架。
策略 1：更早止损
Devin 团队原话：
如果你发现自己在想「它在忽略我的指令」或「它在绕圈子」——就该停下来，开新会话或手动接管。发更多消息更可能说明任务复杂度超出了 Agent 的能力，而不是某个可以纠正的简单错误。
大白话：AI 开始胡说的时候，你多发十条消息纠正它，不如开一个新对话从头来。 因为纠正消息本身也在占上下文，让情况更糟。
策略 2：重新开始比修补快
ACE-FCA 框架的作者 Dex Horthy 说了一句精辟的话：
Starting over is the right answer a lot more often with agents than with humans.对 Agent 来说，"重来"是正确答案的频率，远高于和人类协作时。
Agent 纠正搞乱的上下文的能力，远不如它从零开始写新内容的能力。 跟人类不一样——人类有记忆和经验可以在烂摊子上修补，Agent 只有上下文窗口里的东西。窗口里全是垃圾，修补只会更乱。
策略 3：意图性压缩——进度存在文件里，不存在对话里
这是最实用的一条。
不是等上下文快满了才停——而是主动把已完成的工作压缩成结构化文件，然后用这个文件开新会话。
怎么做：当你觉得对话开始"有点长了"，让 AI 执行一条指令——
把我们到目前为止做的所有事情写到 progress.md，包括最终目标、采用的方法、已完成的步骤、当前遇到的问题。或者直接说一句，请对本会话内容进行意图压缩。
然后关掉当前对话。开一个新的，告诉 AI："读这个文件，从上次断点继续。"
核心思想：对话是一次性的，文件才是资产。
ACE-FCA 框架把这套方法推到了极端：每个会话只做一件事（研究 / 计划 / 实现），每件事做完都压缩成文件，下个会话从文件恢复。保持上下文利用率在 40%-60%，不让它超载。
这个方法听起来"多此一举"——开新会话不是浪费吗？
不是。Dex Horthy 的实战数据：在一个 30 万行 Rust 代码库上，用这套方法大约 1 小时修复了一个 bug，PR 第二天被直接批准合并。他一个"业余 Rust 开发者"，靠的不是 Rust 水平，是上下文管理水平。
05丨你可以今天就做的 3 件事
不需要学完整套理论，今天就能改善 AI 协作体验：
1. 一个对话一个任务。 别在同一个对话里又写代码又改文档又做分析。每切一个任务，开一个新对话。
2. 发现 AI 犯了你纠正过的错误——立刻开新对话。 不要追加消息纠正。带上之前的正确结论，重新来。
3. 检查你的 AI 工具配置。 如果你用 Cursor、Claude Code 或类似工具，看看同时加载了多少插件和工具。不用的就关掉。每个多余的工具都在消耗 AI 的"注意力"。
上下文工程不是什么高深学问。说白了就是：别让 AI 的工作记忆里塞满垃圾。
你精心设计一条 prompt，和你精心设计 AI 看到的整个信息世界——效果差距不是 2 倍，是指数级的。
以前我觉得"要优化的可能是协作结构，而非单条 prompt"只是一句感悟。现在有理论支撑了：prompt 管一次，上下文管以后每一次。
点击关注下方账号，学习AI的路上，带你一起进步~
往期文章分享
斯坦福大学现代软件开发课程Week 1：6 种 Prompt Engineering 核心技术学习分享
斯坦福大学现代软件开发课程Week 2：拆开一个 AI Agent，看看里面到底有什么
AI搭档实操系列第10篇：你和 AI 聊出来的洞察，正在蒸发——Karpathy 的 LLM Wiki 和我的实践
AI搭档实操系列第9篇：别让 AI 编程工具读走你的密钥，10 分钟搭完 5 层安全防护
AI搭档实操系列第8篇：我给 AI 加了一声「叮」，再也不用反复切屏看它干完没了
产品经理的AI搭档实验系列第7篇：AI 帮我做数据分析，连错了 3 次——我是怎么让它不再犯的
我在微信置顶了微信Clawbot，然后花10分钟让它变成了懂我的老搭档
Karpathy 2025 LLM 年度回顾深度解读：当“幽灵智能”撞碎 AGI 幻想
4个MCP、9个技能、20多条规则：一个PM是怎么把AI搭档"驯服"的
OpenClaw能帮你干什么？8个真实场景，看完你就知道该不该装
