上下文工程实战：如何组织输入让大模型输出质量翻倍

1. 为什么“喂给AI什么”比“用哪个AI”更值得花时间

大多数人第一次接触大模型时，注意力都放在“选哪个模型”上——参数多大、跑分多高、价格多便宜。但真正上手做过几个项目之后你会发现，同一个模型，换一种上下文组织方式，输出质量能差出好几倍。这不是玄学，而是因为大模型本质上是一个“条件概率生成器”：它看到的每一个字，都会影响它接下来生成什么。你给它看什么，它就在什么范围内思考。

“上下文工程”这个词听起来有点学术，说白了就是一件事：在模型能力固定的前提下，通过精心组织输入信息，让模型把注意力放在该放的地方，忽略不该放的地方。它和“提示词工程”不是一回事。提示词工程关注的是“怎么问”，上下文工程关注的是“模型在回答之前，眼前到底铺了哪些材料”。问法再漂亮，如果材料是错的、乱的、缺的，结果照样拉胯。

我做过一个对比实验：同一个信息抽取任务，一组直接把原始文档丢给模型，另一组先做结构化整理再喂进去。前者的准确率大概在六成左右徘徊，后者稳定在九成以上。模型没换，参数没调，唯一的变量就是“模型看到了什么”。这个差距让我彻底改变了对“上下文”的认知——它不是可有可无的辅助，而是决定输出质量的第一变量。

这篇文章适合两类人：一是已经在用大模型做实际项目、但总觉得输出“差口气”的开发者；二是刚开始接触AI应用、想知道除了调API之外还能做什么的入门者。我会从上下文的基本构成讲起，拆解几个真实场景下的组织策略，再分享一些踩过的坑和验证过的手法。不堆术语，尽量说人话。

2. 上下文到底由哪些东西拼成：拆开来看才管得住

2.1 系统指令、历史对话、检索内容、工具返回——四块拼图各管什么

很多人以为“上下文”就是聊天记录，其实远不止。一个完整的上下文窗口里，通常同时塞着好几类信息，它们的作用和优先级完全不同。

系统指令是模型的“行为准则”。它告诉模型你是谁、要做什么、不能做什么。比如“你是一个客服助手，只回答与产品相关的问题，不提供法律建议”。这块内容通常放在最前面，因为模型对开头和结尾的信息注意力最集中。

历史对话是“短期记忆”。多轮对话中，模型需要知道前面聊了什么才能保持连贯。但历史不是越长越好——无关的寒暄、重复的确认、已经解决的问题，都会稀释模型对关键信息的注意力。

检索内容是“外部知识”。当问题超出模型自身知识范围时，你需要把相关文档片段塞进去。这块最容易出问题：检索回来的内容可能不相关、可能太长、可能互相矛盾。

工具返回是“实时数据”。调用搜索、数据库、计算器之后拿到的结果，需要以模型能理解的格式放回上下文。格式不对，模型就可能忽略或误读。

这四块拼图的关系可以用一个比喻：系统指令是“岗位说明书”，历史对话是“刚才开会说了什么”，检索内容是“从档案室调来的资料”，工具返回是“同事刚查到的实时数据”。任何一块放错位置或格式不对，模型都会“分心”。

2.2 上下文窗口不是越大越好：注意力稀释的真实代价

现在很多模型宣称支持几十万甚至上百万token的上下文窗口。听起来很美好——把所有东西都塞进去不就行了？但实际用下来你会发现，窗口越大，模型对中间部分的注意力反而越弱。这不是我瞎猜，学术界管这叫“迷失在中间”现象：模型对上下文开头和结尾的信息召回率明显高于中间部分。

我做过一个测试：把一份关键信息放在不同位置，看模型能否准确提取。放在开头，准确率约九成；放在结尾，约八成五；放在正中间，掉到六成以下。这意味着，如果你把最重要的指令埋在长长的历史对话中间，模型很可能“看不见”。

所以上下文工程的核心不是“塞更多”，而是“放更准”。具体来说有三条原则：关键指令放开头或结尾；无关信息坚决删掉；长文档先摘要再放入。这三条听起来简单，但实际操作中很多人舍不得删——总觉得“万一有用呢”。我的经验是，宁可少放，不要多放。模型缺信息会告诉你“我不知道”，但被无关信息干扰时，它会自信地胡说八道。

2.3 一个容易被忽略的变量：上下文的“格式”也在传递信息

同样一段内容，用不同格式呈现，模型的解读可能完全不同。举个例子：你要让模型从一段文字里提取人名。如果直接给一段自然语言段落，模型需要先理解语义再定位。但如果你用列表或表格把候选信息整理好，模型的提取准确率会明显提升。

更微妙的是，格式本身会暗示“重要性”。用Markdown标题包裹的内容，模型倾向于当作“章节主题”；用代码块包裹的内容，模型倾向于当作“精确数据”；用引用块包裹的内容，模型倾向于当作“需要特别注意的提示”。这些倾向不是模型明确知道的规则，而是训练数据中形成的统计规律。

我在实际项目里会刻意利用这一点：需要模型严格遵守的约束，用引用块或加粗标注；需要模型灵活理解的内容，用普通段落；需要模型精确复制的内容，用代码块。这比单纯在文字里写“请注意”有效得多。

3. 从“能跑”到“跑得好”：四个场景下的上下文组织策略

3.1 信息抽取场景：先给“模板”再给“材料”，顺序反了效果差一半

信息抽取是上下文工程最能发挥价值的场景之一。任务通常很明确：从一段非结构化文本中提取指定字段。但很多人直接把原文丢给模型，然后问“帮我提取XX信息”。这种做法的命中率很不稳定。

我试过一种更稳的做法：先给模型看“输出模板”，再给“输入材料”。比如要抽取合同中的甲方、乙方、金额、期限，我会先写一段：

请从下面的文本中提取以下字段： - 甲方： - 乙方： - 合同金额： - 合同期限： 文本内容： [这里放原文]

这个顺序的妙处在于，模型先看到了“它需要找什么”，相当于带着问题去读材料。实测下来，字段完整率比“先材料后问题”高出不少。原因也不难理解：先给模板相当于给模型装了一个“过滤器”，它在阅读时会主动寻找对应信息，而不是读完之后再回忆。

还有一个细节：如果原文很长，不要整段塞进去。先做一次粗筛，把可能包含目标字段的段落截取出来。截取时保留上下文各一两句话，避免断章取义。这个预处理步骤看起来麻烦，但比模型返回错误结果再人工核对要省时间得多。

3.2 多轮对话场景：什么时候该“忘掉”前面聊过的内容

多轮对话的上下文管理，核心矛盾是“连贯性”和“注意力”的平衡。全保留，模型会被历史噪音干扰；全丢弃，模型又接不上话。我的做法是分层管理：

第一层：永久保留。系统指令、用户的核心身份信息、已经确认的关键事实。这些不随对话轮次变化。

第二层：滑动窗口保留。最近三到五轮对话原文。这保证短期连贯性。

第三层：摘要保留。更早的对话做一次摘要，只保留结论和关键决策，丢弃寒暄和重复确认。

具体操作上，我会在每五轮左右触发一次摘要。摘要的提示词大概是：“请用三句话总结以上对话中已经确认的事实和用户的核心诉求，丢弃所有问候、确认和重复内容。”然后把摘要放在历史对话的最前面，标注为“之前对话的摘要”。

这样做的好处是，模型既知道“之前聊了什么”，又不会被几十轮前的无关细节干扰。实测下来，对话超过二十轮之后，不做摘要的模型开始出现“答非所问”和“重复提问”，做了摘要的模型仍然保持稳定。

3.3 代码生成场景：把“项目结构”和“编码规范”放在模型眼前

用大模型写代码，最容易翻车的地方不是语法，而是“不符合项目上下文”。模型不知道你的项目用了什么框架、什么命名习惯、什么目录结构，生成的代码往往“能跑但没法用”。

我的做法是在每次请求里固定带上三样东西：项目结构树、关键依赖版本、编码规范摘要。项目结构树不用完整，只列到二级目录，让模型知道“代码该放哪”。关键依赖版本写清楚，避免模型用旧版API。编码规范摘要用三五条概括，比如“使用驼峰命名”“异步操作统一用async/await”“错误处理用自定义异常类”。

这三样东西加起来通常不超过五百token，但效果立竿见影。模型生成的代码从“需要大改”变成“微调即可”。更重要的是，它减少了来回沟通的次数——你不用每次都解释“我们项目不用这个库”。

还有一个技巧：如果任务涉及修改现有文件，把相关文件的完整内容放进去，而不是只放片段。模型需要看到完整上下文才能做出正确的修改决策。片段会导致它“猜”周围代码长什么样，猜错就出bug。

3.4 长文档问答场景：先摘要再检索，还是先检索再摘要

长文档问答是上下文工程最考验策略的场景。文档几十页，问题可能只涉及其中一段。全部塞进去浪费窗口还稀释注意力，只塞一段又怕漏掉关键信息。

我试过两种策略，各有适用场景：

策略一：先摘要再检索。先把文档按章节做摘要，每个章节摘要控制在两百字以内。用户提问时，先用问题去匹配章节摘要，找到最相关的两三个章节，再把原文对应段落放进去。这种策略适合文档结构清晰、章节主题明确的情况。

策略二：先检索再摘要。直接用问题去检索原文段落，把检索到的前五段拼在一起，再做一次压缩摘要，最后把摘要和原文关键句一起放入。这种策略适合文档结构松散、主题交叉的情况。

两种策略的共同点是：不要让模型直接面对全文。模型的注意力是有限资源，你要帮它做第一轮筛选。筛选的质量决定了最终回答的质量。我通常会两种都跑一遍，对比结果再决定用哪个。虽然多花一次调用成本，但比人工核对答案要划算。

4. 那些让我重新调整策略的翻车现场

4.1 检索内容太长导致模型“只看了开头就下结论”

有一次做产品文档问答，用户问“这个功能的限制条件是什么”。检索系统返回了五段相关文档，每段都挺长，加起来大概三千字。我直接全部塞进上下文，结果模型只回答了第一段里提到的限制，后面四段里更重要的限制完全没提。

排查后发现，模型并不是“没看到”后面的内容，而是第一段的信息已经足够让它生成一个“看起来完整”的答案，它就停止了深入阅读。这是大模型的一个典型行为：它会优先使用最先遇到的相关信息，而不是最全面的信息。

修复方法很简单：把检索到的内容按相关性排序，最相关的放最后（因为模型对结尾注意力也高），并且在每段前面加一句“以下内容也需要考虑”。更重要的是，控制总长度，超过一千五百字就做压缩摘要。压缩时保留具体数字、条件、例外情况，丢弃举例和解释性文字。

4.2 系统指令被历史对话“淹没”的典型症状

另一个坑是系统指令失效。我设置了一个客服助手，系统指令明确写了“不回答与产品无关的问题”。前几轮对话正常，但聊到第十几轮时，用户开始问一些无关问题，模型居然开始回答了。

原因在于，随着历史对话越来越长，系统指令在上下文中的“相对权重”被稀释了。模型看到的绝大部分内容都是对话历史，系统指令只占很小一部分，它的约束力就下降了。

解决办法有两个：一是定期在对话中“重申”系统指令，比如每五轮插入一句“提醒：你是一个客服助手，只回答产品相关问题”；二是把系统指令同时放在开头和结尾，利用模型对首尾的高注意力。我通常两个都用，效果比较稳。

4.3 工具返回格式不对，模型直接“装没看见”

调用外部工具时，返回结果的格式很关键。我遇到过一种情况：调用数据库查询返回了JSON，但JSON的键名是英文缩写，模型看不懂，就干脆忽略了这部分信息，用自己的知识瞎编。

后来我改成了“自然语言+结构化数据”的混合格式。比如：

查询结果如下： - 用户总数：1,234人 - 活跃用户：567人 - 查询时间范围：最近30天 原始数据：{"total": 1234, "active": 567, "range": "30d"}

这样模型既能理解语义，又能精确引用数字。关键是，自然语言部分要用人能看懂的话写，不要直接翻译JSON的键名。模型对“用户总数”的理解远好于对“total”的理解。

5. 我常用的上下文压缩与优先级排序手法

5.1 用“信息密度”而不是“字数”来决定保留什么

上下文窗口有限，必须做取舍。我的取舍标准不是“这段内容重不重要”，而是“这段内容的信息密度高不高”。信息密度高的内容，用很少的字数传递关键约束或事实；信息密度低的内容，啰嗦半天其实什么都没说。

举个例子，用户说“我想问一下，就是那个，之前我提到的那个功能，它有没有什么限制？”这句话信息密度很低，压缩后就是“询问某功能的限制”。而系统指令“不回答与产品无关的问题”信息密度很高，一个字都不能删。

实际操作中，我会对历史对话做“信息密度评分”：包含具体数字、明确约束、关键决策的，保留原文；包含寒暄、重复确认、情绪表达的，直接删除或压缩成一句“用户表达了不满/满意”。这样能把历史对话压缩到原来的三分之一甚至更少，同时不丢失关键信息。

5.2 优先级排序的实操规则：什么放开头、什么放结尾、什么必须删

基于“迷失在中间”现象，我总结了一套优先级排序规则：

这套规则不是死的。如果任务特别依赖历史信息（比如多轮调试），历史对话的优先级会提高。但总体原则不变：把最需要模型“记住”的东西放在它最容易记住的位置。

5.3 一个可复用的上下文模板结构

经过多次调整，我目前常用的上下文模板大概是这个结构：

[系统指令] 你是XX助手，负责XX任务。必须遵守以下约束： 1. ... 2. ... [历史摘要] 之前对话已确认：... [检索内容] 以下是与当前问题相关的资料： 资料1：... 资料2：... [当前问题] 用户问题：... [输出要求] 请按以下格式回答：...

这个模板的好处是层次清晰，每块内容都有明确标签。模型不需要猜“这段文字是干什么的”，标签直接告诉它了。实测下来，这种结构化上下文的输出稳定性明显高于“一大段文字混在一起”。

模板不是固定的，可以根据任务调整。比如代码生成任务会把“检索内容”换成“项目结构”和“相关文件”，把“历史摘要”换成“编码规范”。但核心逻辑一致：分类、标签、排序。

6. 验证上下文是否“喂对了”的几个笨办法

6.1 让模型复述它“看到”的关键约束

上下文组织好之后，怎么知道模型真的“看到”了关键信息？我的办法很笨但很有效：在正式提问之前，先让模型复述一遍关键约束。

比如：“在回答之前，请先复述你收到的所有约束条件。”如果模型复述完整，说明约束确实进入了它的注意力范围。如果复述遗漏或错误，说明上下文组织有问题，需要调整位置或格式。

这个方法特别适合调试系统指令。有时候你以为模型“不听话”，其实是它根本没“听清”。复述测试能快速定位是“没看到”还是“看到了但没遵守”。

6.2 对比实验：换一种上下文顺序，看输出变化

另一个笨办法是对比实验。同一个问题，准备两套上下文：一套按你的直觉组织，一套按“关键信息放首尾”的原则组织。分别跑一遍，对比输出质量。

我做过一次这样的对比：任务是让模型从一份长文档中提取所有日期。第一套上下文把文档全文放前面，问题放最后。第二套上下文把问题放最前，文档摘要放中间，文档关键段落放最后。结果第二套的日期提取完整率比第一套高出近三成。

这种对比不需要复杂工具，手动跑几次就能看出差异。关键是你要愿意花时间做这个“笨功夫”。很多人调不好上下文，不是因为不懂原理，而是因为不愿意做对比实验，凭感觉调。

6.3 记录“上下文版本”，方便回滚和迭代

上下文工程是一个迭代过程。今天调好的组织方式，明天加了新功能可能就不适用了。我的习惯是给每个版本的上下文组织方式打标签，记录在项目文档里。

比如“v1.0 基础版：系统指令+历史全文+问题”“v1.1 压缩版：系统指令+历史摘要+问题”“v1.2 首尾强化版：系统指令+历史摘要+问题+约束重申”。每次调整都记录改了什么、为什么改、效果如何。

这样做的好处是，当输出质量下降时，你可以快速回滚到上一个稳定版本，而不是从头排查。上下文工程没有“一劳永逸”的方案，只有持续迭代。记录版本是最低成本的迭代保障。

7. 关于上下文工程，我踩过之后才明白的几件事

第一件事：上下文工程不是“优化”，而是“设计”。很多人把它当成提示词工程的附属品，觉得“随便写写就行”。但实际做下来，上下文组织方式对输出质量的影响，往往比提示词措辞更大。你花在“放什么、怎么放、放哪里”上的时间，回报率远高于反复修改“请帮我”“麻烦你”这些措辞。

第二件事：少即是多，但“少”的前提是“准”。删掉无关内容很容易，难的是判断什么算“无关”。我的经验是，如果一段内容你不确定它有没有用，先删掉跑一遍。如果输出质量没下降，说明它确实无关；如果下降了，再加回来。这个“删了再加”的过程比“留着以防万一”更高效。

第三件事：格式是隐形的指令。同样一句话，放在代码块里和放在普通段落里，模型的理解完全不同。利用好格式，你不需要写“请注意”“重要”这些词，模型就知道该重点对待。这比在文字里反复强调要优雅得多，也有效得多。

第四件事：上下文工程没有标准答案。不同的模型、不同的任务、不同的数据特点，最优的上下文组织方式都不一样。别人的模板可以参考，但不能照搬。你必须自己跑对比实验，找到适合你当前场景的那一套。这个过程没有捷径，但一旦跑通，收益是持续的。