1. 从“提示词”到“上下文工程”为什么我们需要重新理解这门手艺如果你最近在关注大模型应用开发大概率已经被一个词反复刷屏Context Engineering中文一般译作“上下文工程”。这个词最早在提示词工程Prompt Engineering的圈子里冒出来后来被不少做AI应用落地的团队反复提及逐渐从一个学术概念变成了工程实践里的高频术语。我最初接触这个概念是在整理一套机器学习课程笔记的时候当时看到“Context Engineering”这个标题第一反应是这不就是提示词工程的换皮说法吗但真正把相关材料啃完、又在几个实际项目里踩过坑之后我才意识到这两者之间的差别远比字面上看起来要大得多。简单来说上下文工程关注的是“模型在生成回答之前它的上下文窗口里到底应该放什么”。提示词工程更多聚焦在“怎么把一句话问得更好”而上下文工程要解决的是更系统的问题哪些信息该进上下文、以什么形式进、按什么顺序排列、放多少、什么时候该丢弃、什么时候该压缩。它解决的核心痛点是大模型的上下文窗口虽然越来越大但“塞得多”不等于“用得好”信息过载、注意力稀释、关键信息被淹没这些问题在实际应用里非常致命。这篇文章适合谁看如果你只是偶尔用聊天工具问几个问题那提示词技巧可能就够了但如果你在做RAG系统、智能体Agent、多轮对话产品或者任何需要把外部知识、历史记录、工具返回结果拼进上下文的场景那上下文工程就是你必须跨过去的一道坎。我会从概念拆解、核心原理、实操方法、常见坑几个角度把这件事讲透尽量让刚入门的人也能看懂同时给已经上手的人一些能直接抄作业的细节。2. 上下文工程到底在工程什么核心概念与设计思路拆解2.1 上下文窗口不是“越大越好”的仓库很多人对大模型上下文的第一印象是窗口越大越强。早期模型只有2K、4K token的窗口后来一路涨到32K、128K甚至更长。于是很多人的直觉是既然窗口这么大那我把我能拿到的所有资料全塞进去不就行了我一开始也是这么想的直到在一个知识问答项目里被现实教育了一顿。当时我把一整份产品手册大约3万字直接塞进上下文然后问模型一个很具体的问题。结果模型给出的答案里混进了手册里其他章节的无关内容甚至把两个不同型号的参数张冠李戴。后来我把上下文缩减到只保留相关章节答案立刻准确了。这件事让我明白一个道理上下文窗口更像是一张工作台而不是一个仓库。工作台再大你同时摊开的东西太多手忙脚乱是必然的。模型在处理长上下文时注意力机制会对不同位置的信息分配不同的权重中间部分的信息往往容易被“忽略”这就是业内常说的“lost in the middle”现象。所以上下文工程的第一个核心思路就是做减法而不是做加法。你要判断的不是“我还能塞什么”而是“哪些信息对当前这一次生成是真正必要的”。这个判断过程就是上下文工程和简单拼接的本质区别。2.2 上下文的四个组成部分要把上下文工程讲清楚得先知道一个完整的上下文里通常包含哪些东西。根据我在实际项目里的拆解大致可以分成四块系统指令System Prompt定义模型的角色、行为边界、输出格式要求。这部分通常固定但也可以根据场景动态调整。历史对话Conversation History多轮对话里之前的用户输入和模型回复。这部分会随着轮次增长而膨胀是最需要做压缩和裁剪的部分。外部知识Retrieved Knowledge通过检索拿到的文档片段、数据库查询结果、API返回内容等。RAG系统的核心就在这里。当前任务Current Task用户这一次的具体问题和相关约束。这四块内容在上下文里怎么排布、各自占多少比例、用什么格式呈现就是上下文工程要处理的具体问题。举个实际例子如果你把外部知识放在历史对话前面模型可能会被历史对话里的旧信息干扰如果你把系统指令写得太长太细反而会挤占知识片段的空间。这些细节没有标准答案但有一些经过验证的实践原则。2.3 为什么它比提示词工程更“工程”提示词工程更像是一门“手艺”靠的是对语言和模型行为的直觉调一调措辞、加几个例子效果可能就变了。而上下文工程更接近“系统工程”它需要你考虑数据流、考虑成本、考虑延迟、考虑可维护性。我举个具体的对比。提示词工程里你可能会写“请根据以下资料回答问题如果资料里没有就说不知道。”这是一句提示词。而上下文工程里你要决定的是资料怎么切分、切多大、检索几条、按什么相关性排序、超出窗口时丢弃哪部分、要不要做摘要压缩、摘要用什么模型生成、生成摘要的延迟能不能接受。这些决策每一个都会影响最终效果而且它们之间是相互关联的。这就是为什么我说上下文工程是提示词工程的上层建筑——它管的不是“怎么说”而是“说什么”和“说多少”。3. 核心细节解析上下文工程的关键环节与实操要点3.1 信息筛选相关性判断是第一道关上下文工程的第一步永远是从海量信息里挑出相关的那一小部分。这一步做不好后面全是白费。在实际操作中我通常会把筛选分成两层第一层是粗筛用检索系统比如向量检索、关键词检索或者混合检索从知识库里召回一批候选片段。这一层的目标是“宁可多召回不要漏掉”通常召回10到20条。第二层是精排用重排序模型Reranker或者简单的规则对候选片段打分挑出最相关的3到5条。这一层的目标是“精准”因为最终进上下文的名额有限。这里有个容易被忽略的细节相关性不等于有用性。有些片段和问题在语义上很接近但内容其实是重复的或者过时的。我遇到过一种情况知识库里有同一份文档的多个版本检索时把新旧版本都召回了模型看到两个矛盾的说法输出就开始摇摆。后来我在精排阶段加了一个去重和时效性过滤的规则问题才解决。所以筛选不只是算相似度还要考虑信息的质量和一致性。3.2 信息压缩摘要、抽取与结构化筛选完之后剩下的信息往往还是太长。这时候就需要压缩。压缩有三种常见策略各有适用场景压缩策略做法适用场景注意事项摘要式压缩用模型把长文档概括成短段落文档整体相关但细节不重要摘要可能丢失关键数字和专有名词抽取式压缩只保留原文中与问题最相关的句子答案集中在少数句子里需要准确的句子级相关性判断结构化压缩把信息转成表格、列表、JSON等格式信息本身有结构如参数、步骤转换过程可能引入格式错误我个人的经验是结构化压缩在工程场景里性价比最高。比如一份产品参数文档与其让模型读一大段文字不如提前把它整理成“参数名: 参数值”的列表模型读取和引用的准确率会明显提升。摘要式压缩虽然省事但在需要精确引用数字、日期、名称的场景里风险很大我一般只在做背景铺垫时用。还有一个实操技巧压缩后的内容要保留来源标记。比如每个片段前面加上“[来源1]”“[来源2]”这样模型在回答时如果引用了某个信息你可以追溯它到底来自哪里。这在调试阶段特别有用能帮你快速定位是检索错了还是模型理解错了。3.3 信息排序位置决定注意力前面提到“lost in the middle”现象这意味着信息在上下文里的位置会显著影响模型对它的关注度。根据我的实测开头和结尾的位置信息利用率最高中间部分最容易被忽略。基于这个规律排序策略可以这样设计把最关键的指令和约束放在最前面系统指令区。把最相关的知识片段放在知识区的开头或结尾。把次要的、辅助性的信息放在中间。当前任务的问题放在整个上下文的最后紧挨着生成位置。这个排序逻辑不是绝对的不同模型的表现会有差异。我建议你在自己的场景里做一个小实验把同一组信息按不同顺序排列跑个几十次统计一下答案准确率找到最适合你所用模型的排列方式。这个实验花不了多少时间但收益很实在。3.4 格式设计让模型“一眼看懂”上下文的格式对模型理解的影响比很多人想象的要大。同样一段信息用自然段落写和用带标签的结构化格式写模型的提取准确率能差出不少。我常用的格式规范有这么几条用清晰的分隔符区分不同区块比如“### 参考资料 ###”“### 对话历史 ###”。每条知识片段用编号或标签开头方便模型引用。关键字段用固定格式比如“标题xxx”“内容xxx”“来源xxx”。避免嵌套过深的结构模型对多层嵌套的解析能力有限。提示格式设计没有万能模板但有一个检验标准——你把这段上下文给一个不了解背景的同事看他能不能在10秒内找到关键信息。如果人看着都费劲模型大概率也费劲。4. 实操过程从零搭建一个上下文管理流程4.1 场景设定与需求拆解假设我们要做一个技术文档问答助手用户可以用自然语言提问系统从一批技术文档里找答案。这个场景的上下文工程需求可以拆成几点文档总量大约几百篇单篇长度从几百字到几千字不等。用户问题通常比较具体比如“某个配置项默认值是多少”“某个报错怎么解决”。回答需要准确引用文档内容不能编造。响应时间要控制在几秒内不能太慢。基于这些需求我设计的上下文结构是系统指令固定 检索到的文档片段3到5条结构化格式 当前问题。历史对话只在多轮追问时才加入并且只保留最近两轮。4.2 文档预处理与切分文档切分是上下文工程的地基。切得太碎语义不完整切得太粗检索精度下降。我的做法是按语义段落切分同时设置长度上下限。具体来说先按文档的天然结构标题、小节切分成块。如果某块超过800字再按段落进一步切分。如果某块少于100字尝试和相邻块合并。每个块保留其所属的标题路径比如“第三章 配置说明 超时设置”。这样做的好处是每个片段既有完整的语义又不会太长。标题路径在后续检索和展示时也很有用能帮模型快速定位信息的层级。4.3 检索与重排的配置检索环节我用的是混合检索向量检索负责语义匹配关键词检索负责精确匹配比如配置项名称、错误码。两路各召回10条合并去重后得到候选集。然后用一个轻量级的重排序模型对候选集打分取前5条。这里有个参数需要调向量检索的相似度阈值。阈值太高可能漏掉相关文档阈值太低会引入大量噪声。我的经验是从0.7开始试根据实际召回情况上下调整。如果发现漏召回就降到0.6如果噪声太多就升到0.75。这个值没有标准答案跟你的文档质量和嵌入模型都有关系。4.4 上下文组装与生成组装环节就是把前面准备好的各部分拼起来。我用的模板大致是这样的### 系统指令 ### 你是一个技术文档助手。请根据下方参考资料回答问题。 如果参考资料中没有相关信息请明确说明“文档中未找到”。 回答时请引用来源编号。 ### 参考资料 ### [1] 标题xxx 内容xxx [2] 标题xxx 内容xxx ### 用户问题 ### xxx这个模板看起来简单但有几个细节是踩过坑之后加上的。比如“如果参考资料中没有相关信息请明确说明”这句话能显著降低模型编造答案的概率。“回答时请引用来源编号”则方便后续做答案溯源。参考资料用编号而不是直接堆砌是为了让模型在引用时有明确的指向。4.5 效果验证与迭代上线之后不能就不管了。我通常会准备一批测试问题覆盖常见问题和边界情况定期跑一遍看准确率。同时收集用户的真实提问特别是那些回答不好的案例分析是检索问题、压缩问题还是排序问题。这个迭代过程是持续的因为文档在更新用户的问题分布也在变化。5. 常见问题与排查技巧实录5.1 模型答非所问或答错这是最常见的问题原因可能出在多个环节。我一般按这个顺序排查先看检索结果把召回的片段打印出来看有没有包含正确答案。如果没有说明检索环节有问题需要调整检索策略或切分粒度。再看上下文组装如果检索结果里有正确答案但模型没用到检查一下是不是被放在了中间位置或者格式太乱导致模型没注意到。最后看指令如果前两步都没问题可能是系统指令不够明确模型没有正确理解任务。这个排查顺序能帮你快速定位问题环节避免盲目调参。5.2 上下文超长导致截断当检索结果加上历史对话超过模型窗口时就需要截断。截断策略我推荐优先保留系统指令和当前问题然后按相关性从高到低保留知识片段最后才考虑历史对话。历史对话如果太长可以做摘要压缩只保留关键信息。千万不要简单地从尾部截断那样可能把当前问题都截掉了。5.3 多轮对话中的信息污染多轮对话里之前轮次的错误信息可能会影响后续回答。比如用户第一轮问了一个问题模型答错了第二轮用户追问模型可能会沿着错误的方向继续。解决办法是在每轮生成前对历史对话做一次“清洗”把明显错误或无关的内容剔除。这个操作可以用规则做也可以用模型做看你的成本预算。5.4 常见问题速查表问题现象可能原因排查方向解决思路答案不准确检索未召回正确内容检查召回片段调整检索策略或切分粒度答案不完整关键信息被截断检查上下文长度优化压缩策略或截断顺序答案编造指令不够明确检查系统指令增加“无信息时明确说明”约束响应太慢上下文过长统计token数量减少召回数量或做压缩多轮后质量下降历史信息污染检查历史对话清洗或摘要历史对话注意以上排查顺序不是固定的实际中可能多个问题同时存在。我的建议是每次只改一个变量改完跑测试确认有效再改下一个否则你很难知道到底是哪个改动起了作用。6. 一些踩坑之后的个人体会上下文工程这件事说到底是在“信息量”和“信息质量”之间找平衡。我见过太多团队一上来就追求大窗口、多召回结果效果反而不如精简上下文的小系统。模型不是人它不会因为你看得多就理解得深反而容易被无关信息带偏。另一个体会是上下文工程没有一劳永逸的方案。你的文档在变、用户问题在变、模型版本也在变今天调好的参数下个月可能就不适用了。所以与其追求一个完美配置不如建立一套能快速迭代的流程有测试集、有日志、有排查路径。这样每次出问题你都能快速定位和修复而不是从头再来。最后分享一个我常用的小技巧在调试上下文效果时我会把组装好的完整上下文复制出来自己先读一遍然后问自己“如果我是模型只看这段内容能不能答对这个问题”。这个“人肉模拟”的方法虽然土但往往能发现很多自动化指标看不出来的问题比如格式混乱、信息矛盾、关键内容被淹没。试过几次之后你对上下文的敏感度会明显提升后面设计起来也会更有手感。