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. 关于上下文工程我踩过之后才明白的几件事第一件事上下文工程不是“优化”而是“设计”。很多人把它当成提示词工程的附属品觉得“随便写写就行”。但实际做下来上下文组织方式对输出质量的影响往往比提示词措辞更大。你花在“放什么、怎么放、放哪里”上的时间回报率远高于反复修改“请帮我”“麻烦你”这些措辞。第二件事少即是多但“少”的前提是“准”。删掉无关内容很容易难的是判断什么算“无关”。我的经验是如果一段内容你不确定它有没有用先删掉跑一遍。如果输出质量没下降说明它确实无关如果下降了再加回来。这个“删了再加”的过程比“留着以防万一”更高效。第三件事格式是隐形的指令。同样一句话放在代码块里和放在普通段落里模型的理解完全不同。利用好格式你不需要写“请注意”“重要”这些词模型就知道该重点对待。这比在文字里反复强调要优雅得多也有效得多。第四件事上下文工程没有标准答案。不同的模型、不同的任务、不同的数据特点最优的上下文组织方式都不一样。别人的模板可以参考但不能照搬。你必须自己跑对比实验找到适合你当前场景的那一套。这个过程没有捷径但一旦跑通收益是持续的。