我见过的绝大多数工程问题其实都不是模型能力不够而是“喂给模型的东西压根没有认真设计过”。这句话是我读完Google那篇70页上下文工程材料之后最大的感受。那篇材料在圈子里流传得很广不少人第一时间点了收藏但真能沉下心把70页翻完、再转化成自己项目里可用方法的并不多。这篇文章就是我啃完它之后整理出的一套中文解读笔记也是我给自己做中文PPT汇报时用的底稿。我会先讲清楚上下文工程到底在解决什么问题再把它从定义、边界、工作流到落地陷阱逐层拆开保证你就算没看过那70页也能直接拿来用。1. 这份材料出圈的背景模型能力已经够用拉开差距的是输入组织方式1.1 上下文窗口越来越大使用方式却还停留在“贴文档”先聊一个很反直觉的现象。过去两年各家模型的上下文窗口从几千token一路卷到128K、200K甚至1M级别。单看数字你会觉得长文本处理早就不是问题了但真正把长上下文丢给模型跑过的人都知道窗口大了不代表模型能把窗口里的内容都“看懂”更不代表它会在需要的地方精准调用信息。我在内部一个客服助手Demo里做过对比。同样一组用户问题A方案把所有知识库文档按顺序拼接后塞进上下文B方案把同样的内容分成“任务指令、核心规则、参考文档、示例、输出要求”几个区块再调整了顺序。模型的参数、温度、采样方式完全一致最终的准确率差了将近两成。A方案还经常出现一种让人哭笑不得的情况用户的诉求明明写在第2000行模型却只盯着第50行的历史对话回答把中间的内容直接“遗忘”了。这个现象在材料里有个专门的说法叫“Lost in the Middle”。注意力机制天然更关注序列开头和结尾的内容中间部分即便信息量很大也容易被模型忽略。上下文窗口变长之后这个问题不仅没有被解决反而被放大了——因为人们默认“窗口大了塞得越多越好”结果中间区域的信息密度越来越高真正关键的指令反而被淹没。1.2 提示工程解决“一条提示”上下文工程解决“整个输入环境”以前大家说优化提示词通常只干一件事把那条发给模型的prompt改得更好。比如加上“你是一个资深专家”、强调“分步骤回答”、给出几个示例。这套方法当然有用但它的视野太窄了它把模型输入看成一条孤立的文本而没有意识到模型实际上收到的是一个完整的“输入环境”。我理解的上下文工程就是把这个输入环境当成一个可设计的对象来看待。要回答什么问题、给模型什么背景、从哪里检索资料、资料按什么顺序放、模型应该遵循哪些行为准则、输出格式怎么约束、甚至让模型在动手之前先输出哪些推理这些都是可以在上下文层面控制的变量。那篇70页的材料本质上就是把这些分散的经验统一成了一个体系告诉大家模型内部权重一旦固定你在推理期唯一能大规模干预的就是输入上下文。很多团队明明用的是同一款模型效果却天差地别根子就在这里。有的团队把上下文工程当成核心研发环节每一轮修改都有版本记录和评测数据有的团队只是把文档一股脑丢进去再祈祷模型“理解一下”。我一直觉得用好大模型不是选模型的问题而是组织输入的问题。2. 上下文工程的定义与边界它和RAG、微调、提示词到底什么关系2.1 材料里反复强调的中心论点那份70页材料里给我印象最深的不是某个具体技巧而是它对上下文工程的定义方式。把它翻译成大白话就是通过设计、组织和编码送入模型上下文窗口的信息引导模型高质量完成指定任务。关键词是“设计”和“编码”。我之前习惯把提示工程、RAG、微调看成三座孤岛调提示词是文本层面的事RAG是检索管道的事微调是训练流程的事。读完材料之后我才反应过来这三座岛其实都围着同一个目标转——如何让模型在正确的上下文里做出正确的行为。提示词只是上下文工程中最表层的那一部分RAG也只是上下文内容的一种来源管道而已。这个认知变化很关键。它意味着你把“调prompt”这件事的优先级提得再高也只是在修一处细节而没有系统性地管理整个输入链路。上下文工程要做的是把任务目标、背景信息、示例演示、工具说明、输出约束、推理策略打包成一套完整的上下文方案并且像软件工程一样对这套方案做版本管理、评测和迭代。2.2 一张表看清四类技术的分工为了在中文分享会上快速说清楚这件事我画了张对比表效果很好也放在这里技术方向干预对象典型操作改动成本适用时机提示工程单条提示词改写措辞、增加示例、调整语气低按次修改模型行为偏差不严重快速试探RAG外部知识检索与注入建索引、检索排序、拼装上下文片段中需维护知识库模型自身知识不足或需要实时信息微调模型内部权重构造训练集、训练、评估高周期长需要固化某种行为模式或领域风格上下文工程整个输入上下文环境组装、排序、编码、指令设计、评测迭代中见效快推理期可控时最通用可叠加上述任何方式这张表最大的价值是帮团队统一语言。我以前经常遇到一种情况业务方说“模型效果不好要不微调一下”但实际上问题出在知识库文档太乱、检索结果顺序不对属于典型的上文工程问题微调不仅贵而且解决不了输入侧的结构问题。有了这张表至少能先对齐一下“到底该动哪个层”。2.3 上下文工程的四个可干预要素材料里虽然没有用“四个要素”这种口诀式说法但通读下来我认为可以归纳成四类干预抓手第一内容。上下文里出现哪些信息信息来自哪里是知识库检索、用户实时输入还是历史会话摘要。这是最基础的抓手也是RAG主要贡献的环节。第二结构。信息以什么顺序排列哪些放开头、哪些放中间、哪些放结尾用什么样的分层标题或XML标签分隔。结构决定了注意力分配。第三指令。系统提示、任务目标、行为边界。指令不只是在“告诉模型做什么”更是在短时间内建立模型的行为基线。第四推理参数。温度、采样策略、以及“是否要求模型先输出推理过程”。很多人忽略这一点但模型是在写之前先列计划还是直接作答结果往往差异巨大。需要说明的是这四项不是彼此独立的。你改了结构可能就要同步调整指令你增加了检索内容可能就要重新设计指令来区分“哪些是参考资料哪些是硬性规则”。上下文工程本身就是一门协调这些要素的手艺这也是它跟单点调prompt最本质的区别。3. 从70页中提取的五步工作流把“设计上下文”变成可执行的日常动作3.1 步骤一先用评测标准反向定义“好上下文”读那篇材料之前我习惯拿到任务就开始拼上下文拼完跑几个例子感觉“差不多”就收工。材料给了一个相反的建议先定义评测标准再开始设计输入。我在做客服助手时就把这一步落到了实处。任务是用户解释了“误操作”场景后模型给出补救步骤。我没有急着写系统提示而是先跟业务方对齐了四条衡量标准正确引用率模型给出的补救步骤是否能在知识库文档中找到依据步骤可执行率步骤是否具体到用户照做就能完成格式通过率输出是否稳定符合预设的字段结构敏感场景拒绝率涉及违规操作时是否知道拒绝并引导人工客服。这四条标准就是我在后续迭代里的“裁判”。没有这个裁判你就会陷入一种很常见的幻觉这版上下文改了之后单看几个例子感觉更顺了但说不清到底哪里提升了下一轮又会犹豫要不要回滚。有了标准每一次修改要么被数据支持要么被数据否决优化才变成一件可积累的事。3.2 步骤二把上下文拆成可复用的模块材料里让人耳目一新的地方是把上下文当成“组装”出来的产品而不是“写”出来的文本。既然是组装就得有零件。我在客服助手里把上下文拆成了六类模块任务定位块说明这是一个什么场景、模型承担什么角色行为规范块硬性规则比如“不能编造政策”“优先引导用户走自助流程”参考知识块来自知识库的检索结果每段带来源标记少样本示例块3到4组标准问答覆盖典型场景和边界场景输出格式块JSON结构说明或者对回复字段顺序的硬约束推理引导块要求模型先输出“当前用户诉求的识别结果”再输出“处理步骤”。把这些模块化的好处有两个。第一维护成本变低。政策更新了只需要替换参考知识块示例效果不好只动示例块系统提示一行不用改。第二便于做版本对比。我们可以像管理代码包一样管理这些上下文模块每个版本改动了哪个模块一目了然。3.3 步骤三按“上下文语法”组装并刻意利用位置效应组装顺序是回报率最高的环节也是最容易被忽略的环节。我在帮团队梳理上下文结构时总结出了一个相对稳定的组装顺序实测下来效果比“按素材顺序平铺”明显更稳。开头位置放任务定位和行为规范。这是模型注意力最集中的区域要用来建立“你要解决什么问题、按什么原则解决”的基线。中间位置放参考知识块和少样本示例。对于不追求即时输出的长文档还应该在中间段开头加一行摘要防止模型读着读着丢了主线。结尾位置放输出格式和推理引导。模型对结尾的注意力同样很高这里放执行要求能有效提升输出的规范度。这里有个很关键的心理模型模型阅读上下文的注意力曲线跟你自己开会时的状态其实很像——开头大家都在认真听到中间开始走神临近结束又打起精神。给模型喂上下文不能只考虑“信息在逻辑上该放哪”还要考虑“信息在注意力上放哪”。3.4 步骤四像调超参一样单变量迭代很多人都经历过这个场景模型输出不理想你同时加了示例、改了指令、调整了顺序、换了检索策略一通操作猛如虎效果确实变了但完全说不清是哪个改动起了作用。等下次需要复用这套经验时依然两眼一抹黑。材料给的方法非常朴素一次只改一个变量。我给自己定了一条纪律每次迭代只改上下文六个模块中的一处然后到评测集里跑一组完整结果记下指标变化再决定下一步动作。这个过程听起来很简单做起来却很考验耐心。有一次我在客服助手上连续做了六轮实验前五轮的指标几乎都没变化第六轮我只是把示例里的“订单修改”场景从2条加到3条且换成了一条更真实的用户话术正确引用率就提升了3个百分点。如果没有单变量实验的纪律这个归因根本不可能成立我大概率会误以为是之前某轮的系统提示改对了然后在一堆无效变量上反复横跳。3.5 从五步工作流到我日常使用的检查清单我在日常工作中把上面五步浓缩成了一张检查清单每次设计新任务时照着走一遍任务要解决的业务问题是否清晰评测指标是否定下来了上下文是否拆成了独立模块每个模块是否有明确的维护责任人组装顺序是否符合注意力分布规律关键指令是否放在了开头或结尾这次迭代只改一个变量改前是否留下了旧版本是否跑了一组评测数据而不是只看了两三个孤立的例子。这张清单本身不惊人但它是把70页材料转化为日常生产力的关键。理论看得再多最后还是要落到每一次动手之前的两分钟自问。4. 容易被翻页跳过的六个细节每一处都直接影响输出效果4.1 系统提示的真正作用是覆盖模型默认行为很多人写系统提示写得像一段“礼貌的开场白”。材料里的观点完全不同系统提示是模型在本次会话里的“新默认行为”。默认行为意味着只要上下文里没有冲突信息模型会优先按系统提示的方式行动。它不是在给你帮忙而是在重新定义模型。明白了这一点你就会理解为什么系统提示里要用肯定的陈述句而不是模棱两可的商量语气。比如“你是一个售后客服专家必须基于知识库文档回答禁止编造政策”就比“如果你知道的话请尽量回答用户的问题”有效得多。前者锚定了模型的行为基线后者只是给模型留了一个自由发挥的后门。4.2 示例的位置和复杂度比示例数量更重要少样本示例是调节模型行为最高性价比的手段。但你不需要很多示例——过犹不及。我在实践中的体会是3到5个高质量示例覆盖任务的关键边界情况效果远好于堆10个示例因为普通同质化的示例不仅占用窗口还会稀释模型对重点示例的注意力。更值得留意的是示例的摆放位置。材料里以及我后续复测都指向同一个结论示例紧贴着输入问题之前放比放在整段上下文最开头效果更好。因为示例本质上是在告诉模型“接下来你要用这种格式、这种语气、这种深度来回答”它离待处理的输入越近这种“接下来”的指向就越强。4.3 先列计划再回答等于给模型分配“推理预算”如果要我选一个“性价比最高的单项改动”我会选这个在输出格式约束里要求模型在给出最终答案之前先输出一段简短的推理或计划。我在客服助手的上下文里加了一句结构化要求先识别用户诉求的类别再列出处理思路最后输出给用户的回答。就这一步格式通过率没有明显变化但回答的合理性和严谨性提升了一大截。原因也不难理解直接回答相当于让模型跳过思考直接开口而先列计划相当于给模型分配了一笔“推理预算”让高价值推理发生在最终决策之前。需要提醒的是这一步会显著增加输出token数和响应延迟。如果是实时对话场景记得在推理预算的长度和延迟之间做权衡比如把中间推理限制在50字以内。4.4 输出格式本身也是上下文的一部分我在很多项目里见过这种场景上下文里写满了业务知识但模型返回的答案经常是纯文本大段话下游程序解析费劲只好靠正则硬抠。其实把期望的JSON Schema直接写进上下文本身就是一种上下文编码方式。我推荐的写法不是在系统提示里说“请以JSON格式返回”而是把完整的字段结构、类型、示例值一并给出甚至顺带放一个最小的示例对象。模型对结构化的输入非常敏感你把输出骨架定义得越清晰它遵循得越好。这不需要任何工程魔法只需要你在组装上下文时愿意多花一分钟把输出格式写完整。4.5 多模态场景下文字与图片的相对位置那篇材料还花了不少篇幅讨论多模态上下文。提炼出来最核心的经验是如果你希望模型关注某张图片那么与这张图片相关的文字描述应该放在图片之前并且直接引用图中的某个具体元素而不是放一个泛泛的“见下图”。这个原则在处理产品截图、报表图、流程图的自动解读时尤其管用。我在一个图像处理Demo里测试过两种放法一种是把图片放在段落最后另一种是先用文字描述图像里的关键区域再放图片后者的信息利用率和回答准确度都明显更高。原因是图片在上下文编码时也会占据注意力资源先立好文字锚点再去读图相当于给模型指了一条路。4.6 上下文不是越多越好要敢于做减法材料里反复出现一个观念上下文质量永远优先于数量。但在实际项目里人人都喜欢做加法很少有人主动删上下文。我的建议是每次评测结束后做一次“上下文最小化实验”。把某个模块去掉或缩短再看看评测指标是否有变化。如果指标没有下降这段内容就不值得留在上下文里。这个实验我做过很多轮几乎每次都能删掉10%到20%的内容而效果不受影响有时甚至会更好因为模型终于可以把注意力放到真正重要的指令上了。省钱是一方面让模型聚焦才是更重要的收获。5. 我做中文PPT解读时的重组框架不逐页翻译按六部分重新讲5.1 要先把PPT的目的定下来再谈内容组织标题说要整理70页材料的中文PPT解读很多人第一反应是“逐页翻译”这是我最不推荐的思路。纯翻译版中文PPT除了信息量大没有任何记忆点。分享出去之后听众只会觉得“讲了很多”但留不下任何可操作的东西。我给自己定的规则是先问一个问题这版PPT是给谁看、干什么用的。如果是给团队做技术分享重点放在定义、工作流和落地陷阱如果是给决策层做汇报重点放在上下文工程的ROI和案例数据如果是给自己做学习笔记重点放在概念对照和原理推导。目的不同重组方式完全不同。我下面给出的是技术分享版的结构。5.2 适合中文技术分享的六部分结构我做了几十页原材料的梳理之后把它重组成了一份不到20页的中文PPT结构如下第一部分背景铺垫。讲上下文窗口变大但效果分化加剧抛出“Lost in the Middle”现象用两个对比案例说明问题。第二部分定义辨析。讲上下文工程的定义并放出那张与RAG、微调、提示工程的对比表让听众快速建立坐标系。第三部分五步工作流。这是整个PPT的主角用每一步配一个小例子来讲。听众可以当场对号入座想想自己之前的流程卡在哪一步。第四部分核心设计原则。把材料里的位置效应、系统提示、示例策略、推理预算等凝练成规则做到“一页一条原则、每条配一个实例”。第五部分现场Demo或录屏回放。我倾向于用提前录制好的效果对比因为现场实时跑模型存在随机性容易翻车。录屏则可以展示同一输入在优化前与优化后的输出差异。第六部分落地清单。最后给出三件事明天就能做的改动、两周内要建立的工作流、长期要积累的评测集和版本管理机制。5.3 做中文PPT时容易踩的翻译与演示坑翻译术语这件事比想象中更容易翻车。上下文工程相关词汇在中文社区还没有完全统一同一个英文术语有四五种译法。我在PPT里做了一个术语对照表每次新词汇第一次出现都采用“中文英文”后面再统一用中文避免听众来来回回猜你讲的是什么。还有一个实操层面的建议PPT里放截图和演示结果时一定要提前匿名化。我见过有人在分享会上直接投屏内部知识库截图虽然没有明文规定说不能放但这种细节很容易把听者的注意力带偏。提前把用户名、订单号、内部系统名打码是基本的职业素养。5.4 给听众的一句“带走版本”我每次做分享收尾时都会不留长篇总结只给一句话上下文工程不是新模型也不是新框架它只是把“输入”当成一个值得认真设计的产品来对待。这句话听上去平平无奇但我发现听众离开会场后最能记住的反而是这句话。因为技术细节会被时间冲淡但一个“把输入当成产品”的心智模型会一直影响他们之后每次写系统提示、拼上下文、做检索排序时的决策方式。6. 看完这70页后最容易走的弯路三个落地陷阱与我的修正6.1 陷阱一把系统提示写成一本塞满一切的操作手册我见过最典型的反面案例是把系统提示当成一个无限容器。业务规则、话术模板、后台接口说明、失败兜底策略、合规要求全部堆进去长度直逼两千字。这样做看起来“考虑周全”实际上系统的注意力资源是有限的你把不太重要的规则放在长篇大论的中后部它根本不会被模型有效吸引更糟糕的是还会掩盖真正置顶的任务定位。我的修正做法是系统提示里只放任务定位、硬性行为边界和输出框架其他所有知识全部拆到参考知识块和示例块里。用软件架构的话说系统提示只做“接口定义”不做“数据存储”。6.2 陷阱二上下文更新靠无限追加而不是重写另一个高频问题是长会话上下文越拖越长。每次用户输入系统就往上下文里追加一段流水账不加裁剪不做摘要。结果模型被大量重复、过时的中间过程牵着走延迟升高、费用上升、回答质量反而下降。正确的做法是给会话做“滚动摘要”。每隔几轮用模型或规则生成一段简短的历史摘要替换掉原始对话。材料里虽然没有手把手教这个操作但它反复强调的“上下文质量优先于数量”直接指向这个方向。我在客服场景里的经验是历史摘要控制在200字以内保留用户核心诉求和已经给出的承诺其余细节一律清出窗口。6.3 陷阱三用一两个例子判断效果然后就宣布成功“这版看起来好多了”这是工程师在不确定面前最危险的默认反应。单例观察会被太多偶然因素污染模型采样随机性、用户话术恰好匹配示例、评测集过窄导致以偏概全。我把这条弯路归结为“用叙事替代了数据”。现在我的做法是任何一次上下文改动必须有至少30条评测样本的跑分记录而且每条样本跑2到3次观察波动。阶段性的目标是看均值提升更重要的是看方差是否收窄。模型输出的稳定性在生产环境里往往比单次拔尖重要得多。6.4 一些更实际的上路建议把上下文版本管理建起来说句实在话我在刚读完那篇材料时也有点不知从何下手。后来真正让这套方法论落地生根的不是记住了多少概念而是建立了一个最朴素的机制为每一次上下文变更打版本号。我给客服助手的上下文模块建了一个简单的目录每次改动都记录三件事改了哪个模块、改动的动机是什么、评测前后的指标变化是多少。这个档案维护了三周之后团队里任何一个人都能回答“当前线上环境跑的是哪版上下文上一版为什么被回滚”这种确定性对生产项目来说太重要了。我在实际运行这套机制时还发现了一个额外收获当你必须为每次修改写“改动动机”时你会在动手前多思考一轮很多头脑发热的乱改直接就被拦在门外了。这个机制不是70页材料里专门讲的但如果非要说我读完它之后最值得的决定我会把这一条排在前三。上下文工程最终沉淀下来的是一套让输入持续进化的习惯而不是某一次完美的配置。