什么是上下文工程？比提示词更大的一盘棋

先说结论：一个 AI 任务反复失败，多数人的头一个反应是改提示词，改到七八版还是不行，问题往往出在上下文——模型看到的材料不全、顺序不对，或者被无关内容挤满了。上下文工程管的就是这件事：在有限的窗口里决定放什么、按什么顺序放、什么时候删。它比提示词大一圈，因为提示词只是其中一格。

两者管的范围不一样

提示词工程处理的是你敲进输入框的那段文字：措辞、示例、格式约束。上下文工程处理的是模型这一次推理能看到的全部内容：系统设定、历史对话、检索到的文档、工具返回的结果，甚至文件的排列顺序。同一句提示词配不同的上下文，输出可能完全不同。

这张表可以直接当排查顺序用：先改提示词，不行再动内容，再不行调顺序，末了才考虑压缩。多数人卡在头一步反复打磨措辞，其实材料本身就选错了。

一次请求里，进来的是什么

把一次调用拆开看，进到模型里的通常是四段：系统指令、对话历史、外部材料、本轮问题。系统指令定角色和边界；历史记录提供连续性，也最容易变成负担；外部材料是检索或上传的内容；本轮问题是触发器。四段拼在一起，总长度不能超过上下文窗口。

模型的处理方式是注意力分配：它不会平均地读每一段，而是根据问题与各段的关联度决定看哪里。这解释了一个常见现象——材料越多，答案反而越差。无关内容没有消失，它参与竞争，稀释了真正有用的那部分。

出去的是什么？一段基于这些材料生成的文本。它没有记住你没给它的东西，也不会主动核对材料之外的事实。所以上下文工程的头一条原则是：模型不知道的事，不要指望它推出来。

窗口是预算，不是仓库

很多人把长上下文当成可以随便塞的仓库，实际它更像预算：每一段材料都在花额度，也在分散注意力。窗口变大解决的是能不能放进去，不解决该不该放进去。

窗口长度和成本直接相关。上下文越长，首字等待越久，单次请求的消耗也越高，生成速度与 token 的关系里有更细的说明。免费版和付费版在窗口大小上的差异，也常是同一个任务表现不同的原因，额度与模型的版本差异可以作为对照。

顺带说清一个常被混淆的点：窗口大小和参数量是两个独立指标。参数量 7B 与 70B 的差别讲的是模型本身的规模，不能拿来判断它能读多长；反过来，窗口大也不代表推理更强。

四个能立刻上手的动作

一是先删后加。给材料之前问一句：这段内容里哪几句是回答问题必须的？只留那几句。一整份四十页的规范，真正相关的可能只有两页。

二是把要求放在两端。开头说任务和约束，结尾重复关键约束。中间塞大段材料时，模型对结尾的注意力通常高于中段。

三是长对话定期重开。聊到二三十轮后，早期的设定会被稀释，与其不断提醒它记住前面说的，不如把结论摘出来，开一个新会话重新开始。

四是给材料加结构。同样三份文档，加上「文档一：接口规范」「文档二：历史故障」这样的标签，模型区分来源的准确率会明显高于直接拼接。压缩材料时也一样，压得越狠，越要保留结构和出处，这和模型量化的取舍是同一种交换：用精度换空间，边界在于哪些信息丢了不影响结论。

它解决不了的问题

上下文工程补不上模型能力的缺口。需要精确计算、需要最新事实、需要在长文档里做严格逻辑推理，这些失败不是调整上下文能救的。材料整理得再干净，模型算错还是算错。

它也不能替代领域判断。材料里有两份互相矛盾的规范，模型会挑一个看起来更合理的，但它不知道哪份是最新的。这类冲突必须由你标注出来：以 2025 版为准，旧版仅作参考。

还有一种失效场景是材料本身质量差。扫描件解析出的乱码、双栏排版错乱的 PDF、带大量页眉页脚的网页存档，进到上下文里只是噪声。先修文件，再谈工程，顺序反了怎么调都无效。

怎么判断该改哪一层

有个简单的分流方法。输出格式不对、语气不对、该说的没说，先改提示词。答案笼统、引用了不存在的段落、答的是另一个问题，先查上下文里放了什么。前几轮对、后面越答越偏，是长度问题，该压缩了。

再补一个信号：让它复述一遍你的要求。复述错了，说明上下文里干扰太多；复述对了但做错了，说明任务本身超出能力范围。这个动作花十秒，能省掉半小时的盲目调参。

上下文工程速查

• 任务失败先分流：格式问题改提示词，内容问题改材料
• 材料只留回答问题必需的那几段
• 关键约束放开头和结尾，别埋在中段
• 长对话超过二三十轮就摘要重开
• 多份材料加标签区分来源，冲突处由人标注以哪份为准

把它当成一项日常整理工作更合适：每次任务开始前花两分钟清一遍桌面，比事后反复调措辞有效。模型能力会继续变化，给它看对的东西这条不会过时。