同一个模型，同样的问题，之前答得又快又准，突然开始答非所问、把老需求翻出来、一本正经地复述你自己刚说过的话。换个新模型，一样的毛病。

于是你开始怀疑：模型变笨了？上下文缩水了？厂商偷偷降智了？

真相往往更朴素：不是模型变笨了，是你的上下文被喂撑了。

这一篇不谈参数、不谈跑分，只谈一件事——上下文工程（Context Engineering）。说人话：怎么把该给 AI 看的东西给对，不该给的坚决不给。我拿自己折腾的几个场景做了一轮实测，踩坑过程比结论更值得说。

一、先说一个反直觉的结论：上下文不是越多越好

直觉是：AI 知道得越多越准，那就多塞点。项目文档、日志、历史对话、相关代码文件，一股脑丢进去。

实测结果是：塞到某个点之后，准确率不是线性上升，而是断崖式下跌。

原因不难理解。大模型本质上做的事是：基于上下文预测"下一个最合理的词"。当上下文里塞满十几种风格、五个版本的方案、三段互相矛盾的需求时，模型面对的就不是"解决问题"，而是"猜你想听哪个"。它会讨好地选一个最像答案的说，甚至把上下文里某个错误方案原样复述给你——那感觉像 AI 在跟你抬杠，其实它只是被自己喂饱了。

经验值：一份上下文里，同一主题的有效信息超过三个来源之后，模型的答案质量会开始劣化。你以为你在提供背景，其实在制造噪声。

二、四种典型翻车现场，附翻车原因

病症一：历史对话的"鬼魂"——它总在提三周前的旧需求

翻车现象：AI 突然按你很久以前的方案来实现，而不是你刚说的新要求。

病因：上下文里保留着多轮历史对话，而这些对话里明确出现过"用方案 A""不要用方案 B"。模型读到"用户之前说过不要 B"，就老老实实避开了。你现在说"就用 B"，它不是不听话，是它同时看到了两条互相矛盾的指令，然后选了服从"历史一致性"而不是"最新指令"。

药方：重要指令要复述。真要改方案，就加一句"推翻此前关于 X 的所有设定"。别指望模型自己悟。

病症二：日志灌满窗口，模型开始编造

翻车现象：贴 800 行日志进去问"这个报错是什么原因"，模型给出头头是道的分析——但它引用的那几行根本不存在于你的日志里。

病因：长日志里全是重复样板（心跳、健康检查、正常的 200 OK），中间夹着三五行真正的异常。人看日志靠跳读，模型没这本事，它被淹没在噪声里，然后开始"补全"一段看起来合理的日志。

药方：别把原始数据直接扔进去，先做一次收敛。要么只截取异常窗口前后各几十行，要么先用 grep/awk 过滤掉高频样板行。800 行过滤到 60 行，同样的问题给错概率明显下降，引用的行号终于对得上。

病症三：整个代码库塞进去，它开始"考古"

翻车现象：让 AI 改一个函数，它顺手把项目里三年前的 deprecated 目录风格也复制了一遍，还言之凿凿："为了保持项目风格一致"。

病因：你给它看整个仓库，它就把仓库当"风格模板"，而模板里混着不同时代、不同作者的代码。

药方：给它看邻居，不给它看整栋楼。要它改 A 模块，就只喂周边两三个同类实现作为风格参考，顺手把 deprecated 目录明确排除掉。这一条的提效，比换模型明显得多。

病症四：Prompt 里塞满了"注意力噪音"

翻车现象：你精心写了 800 字系统提示，前 200 字是关键约束，后面 600 字是历史沿革和"请务必温柔一点"。结果模型只记住了"温柔一点"。

病因：长 Prompt 有个坏脾气：中间部分容易被忽略。人读到结尾印象最深，模型更像把开头结尾当重点，中间当背景板。关键约束写在中间等于白写。

药方：关键约束放最前面，兜底检查放最后面，中间留给背景说明。这个结构上的小调整，效果往往比"再强调一遍"立竿见影。

三、一套能立刻上手的上下文配比法

把踩坑经验收敛一下，我现在的做法：

上下文配比（按重要性从高到低）：

1. 任务指令 + 硬约束      —— 放最前面，一条一行，别写散文
2. 验收标准              —— 明确"做到什么算完成"，可判定
3. 关键素材（已过滤）    —— 只保留与本任务相关的片段
4. 风格参考（邻近样本）  —— 2~3 个就够，不要整仓
5. 兜底复述             —— 最后再把硬约束压一遍

第 2 条最容易被忽略，也最值钱。以前写"帮我写个函数"，交上来能跑但风格八竿子打不着；改成"入参可空、错误返回统一 sentinel、命名跟同目录一致"后，命中率立刻上来了。验收标准就是给模型的目标分布，比一百条形容词有用。

心法一：把"形容词"换成"判定条件"。"写得专业一点"是废话；"输出必须是可直接运行的 shell 命令，不带任何解释文字"是判定条件。

心法二：与其压缩上下文，不如压缩任务。一次让 AI 干十件事，它会平均分配注意力，十件都六十分；拆成三次调用，每次只干一件，反而更快更准。

心法三：长会话要主动"清零"。做长任务的时候，该开新会话就开新会话，把结论手动带过去。指望模型从一百轮对话里精准捞出第二十轮的那句约束，是不现实的。

四、工具实测：一次"上下文瘦身"的对照

我拿一个真实的运维排查任务做了对照：把 1200 行服务日志定位到根因。

对照组：整段日志 + 问题描述，直接丢进去。

实验组：先按时间戳和错误码过滤，只留 70 行相关片段，再附一段"该服务正常时的错误返回格式"作为参照。

结果差异：对照组根因方向基本正确，但引用了三处不存在的日志行；实验组不仅根因说对，行号全部对得上，还主动指出"这个错误码在正常路径下也会出现一次"——这句话对照组完全没提，直接省了我一轮复查。

还有个反直觉的发现：实验组的调用次数反而更少。喂得准，模型不用反复自我怀疑；喂得杂，它会把 token 花在"我到底看到哪一行"上。

五、几句掏心窝子的话

AI 工具吹得最凶的功能，百分之九十都建立在"上下文够准"上。所谓智能体、多步自主规划，说白了就是不停地把"当前该看什么"喂对。上下文一歪，agent 越自主歪得越离谱——它把错误当成既定事实往下推演，最后给你一份逻辑自洽、事实全错的报告。

所以下次别急着换模型，先回头看一眼：你给它的东西，真的一句都不能少吗？

上下文工程没有银弹，它的味道更像扫地：看不到戏剧性变化，但每隔一阵你就发现屋子干净了。而且它会随着你对业务的理解加深而越来越省力——本质上，你不是在使用 AI，你是在把"你怎么思考"翻译成它能消化的形状。

这活儿不酷，但真的有用。