做AI应用落地这些年，我见过太多类似的场面：同一个基础模型，A团队调出来的系统像个干了五年的老师傅，话术得体、边界清楚、引用准确；B团队调出来的却像第一天上班的新人，答非所问、张嘴就跑火车。差别通常不在模型本身——底层模型是同一个，提示词看着也差不多——真正的分水岭，往往藏在“上下文工程”这四个字里。
上下文工程，简单说就是让模型在一个对的时机，用对的形式，看到该看的信息。它适合所有正在拿大模型做实际业务的人：后端开发、算法工程师、产品经理、运营，甚至只是把AI当成生产力工具的普通重度用户。这篇文章把我这些年做真实项目攒下来的一套思路、流程和踩过的坑，完整梳理一遍，能帮你少走至少三个月的弯路。
1. 上下文工程到底是什么：不是提示词，也不是RAG
1.1 一句话定义
上下文工程，是在不动模型权重的前提下，通过对输入侧信息的筛选、结构化、排序和压缩，让基础模型的输出更符合业务目标的系统性工程方法。
这里的关键词是“系统性”。它不等于写好一段提示词，也不等于接入一个知识库，而是把模型输入侧当成一个完整的产品来设计。模型权重是固定的，能力天花板也是固定的，但能力实际能发挥出多少，很大程度上取决于你给它的“舞台”搭得怎么样。
打个比方：一个业务能力很强的新员工，你手上有三样东西——工作手册、参考资料、会议记录。你会怎么让他尽快上手？当然是把手册编清楚、把资料整理好、把会议纪要提炼出结论再递给他。模型也一样，它只有几分钟的瞬时记忆，你塞给它的每一段信息都会影响最终表现，所以这些信息怎么组织，就成了一门工程。
1.2 上下文的三个层面
我习惯把上下文的供给拆成三层，任何一次糟糕的模型输出，基本都能归到某一层出了问题：
第一层是行为层，主要是系统提示词。它定义模型是谁、要完成什么目标、有哪些行为边界、输出什么格式。第二层是知识层，指外部注入的信息，包括产品文档、数据库查询结果、API返回数据、用户画像等。第三层是记忆层，指多轮对话里积累起来的用户状态、历史事实、中间结论。
这三层不是独立工作的。系统提示词负责“立规矩”，知识层负责“给弹药”，记忆层负责“接上下文”，三层协同好了，模型才像一个稳定可靠的服务，而不是一个时灵时不灵的玩具。
1.3 为什么很多人做成了“随机调参”
我在不少团队看到同样的失败循环：效果不行 → 改提示词 → 肉眼看着好像好了一点 → 上线 → 几天后又翻车 → 再改提示词。整个过程没有结构，没有度量，没有版本管理，改的是措辞还是信息结构，根本没人在意。今天把“请”改成“务必”觉得有效，明天删掉一句话觉得也没差，最后改回来发现效果一样——这种全凭感觉的“随机调参”，本质就是没有工程化。
上下文工程要求的是可观测、可复现、可回归。改一个地方，要知道改了为什么有效、对哪种问题无效、会不会引发其他问题。这也是这篇文章想重点讲清楚的东西。
2. 底层约束：注意力不是平均分配的，上下文也不是免费的
2.1 塞得进窗口，不等于用得上
做上下文工程，先得理解模型的两个物理限制：上下文窗口大小，和注意力分布的不均匀性。
上下文窗口是模型一次能“同时看到”的最大信息量。现在主流模型的窗口已经从几万token做到了几十万甚至上百万token，听起来很美好，但工程实践告诉我们：塞得进，不等于用得上。注意力机制在处理长文本时并不是均匀分配权重的，研究者早就发现了一个被称为“Lost in the middle”的现象——当关键信息排在长文本的中间位置时，模型忽略它的概率会明显升高，信息放在开头和结尾则更容易被模型捕捉。
我自己的实测也印证这一点：同一份产品手册，把一条业务规则放在文档前部，模型几乎次次都能用对；把它移到长文档的第40段附近，模型经常视而不见；再挪到文档末尾，表现又回来了。这个规律不是玄学，是注意力机制的实际分布特征。你辛辛苦苦塞进去的知识，如果位置不对，跟没塞差不多。
2.2 位置效应怎么用：头尾放最重要
理解了注意力不均匀，编排信息时就要主动顺应它。我的习惯是：系统提示词的核心指令放在靠近输出的尾部，也就是最后一轮指令的位置，那里是模型“临门一脚”前看到的信息，权重往往最高。知识片段中最重要的内容，放在离用户问题最近的地方，而不是把所有检索结果一股脑堆在前面。
还有一个容易被忽视的点：在一个很长的系统提示词里，如果你有五六条规则要模型执行，不要把最关键的一条夹在中间。要么把它提到开头，要么放在最后单独强调。很多人喜欢把规则按逻辑顺序从背景写起，写到中间才说“最重要的是……”，结果模型根本没抓住重点。
2.3 上下文的经济账
上下文工程不只是效果问题，也是成本问题。大模型的计费是按token来的，输入的每个token每次调用都要计费，多轮对话还会反复消耗。你给模型越长的上下文，每一次交互的输入成本就越高。更麻烦的是，注意力机制的计算复杂度大约随序列长度平方级增长，所以窗口翻倍，很多时候推理开销的增长远不止翻倍。
举个简单的例子：一个客服系统原本平均每次调用输入1500 token，接入知识库后涨到4500 token，光输入这一项成本就翻了三倍。如果日调用量有5万次，每天输入token总量从7500万涨到2.25亿，一个月下来成本差距非常可观。所以上下文工程本质上是在约束条件下做最优配置：窗口有限、注意力有限、预算也有限，怎么把有限的输入额度花在最值得的信息上，这才是核心能力。
3. 供给端三板斧：系统提示词、知识注入和记忆管理
3.1 系统提示词：先给模型立规矩
系统提示词是最基础的上下文，但大部分人写得太随意。我见过太多“你是一个智能助手，请帮助用户解决问题”这种空话，它除了占token，什么作用都没有。好的系统提示词应该有确定的结构：
- 角色与身份：明确模型在这个场景里是谁；
- 任务目标：这一系统要解决什么问题；
- 行为规则：先做什么、后做什么、按什么流程处理；
- 边界与红线：什么不能做、什么必须拒绝、什么必须转人工；
- 输出格式：JSON、Markdown、还是特定字段结构。
举个对比案例。低质量版本是这样：
你是一个电商客服助手，请帮助用户解决问题。而高质量版本至少应该写成这样：
你是某电商平台的售前售后客服助手，你的任务是解答用户在售前咨询、订单处理、售后维权中的问题。 行为规则： 1. 先判断用户问题属于哪一类，再按对应流程处理。 2. 回答退款政策时，必须严格依据资料库中的最新版本，引用时标注资料编号。 3. 如果用户情绪激烈，或问题超出你的处理范围，直接转人工并说明原因。 禁止行为： 1. 禁止编造任何政策、时效、价格信息。 2. 禁止承诺“一定可以退款”等主观保证。 输出格式：先给结论，再给依据，最后给下一步建议，每段不超过3句话。差别不在于辞藻，而在于信息结构。第二版告诉模型“遇到什么情况怎么做、什么不能做”，模型的行为边界一下子就清楚了。另外注意，系统提示词每一轮都在，所以要写稳定不变的规则，不要把“今天的促销活动”这种高频率变化的信息塞进去，那是知识层该干的活。
3.2 外部知识注入：检索只是开始，编排才是关键
知识注入最典型的形态是RAG，完整链路包括：知识切片 → 向量化 → 召回 → 再排序 → 注入模板 → 模型生成。很多项目做到“召回”就结束了，把Top-10片段直接拼接丢给模型，结果模型被一堆半相关甚至无关的信息搞得“眼花缭乱”，输出质量反而下降。
上下文工程的视角下，真正的功力在“注入编排”这一步。我常用的注入模板大概是这个样子：
以下是系统提供的业务资料，请优先基于这些资料回答用户问题。 每段资料前标注了[来源编号]，回答中引用到具体政策时，请在句尾对应标注编号。 如果资料与用户问题无关，请直接说明“资料库中没有相关信息”，不要强行使用。 [来源1] 《售后退款政策（2025年3月版）》第3条：... [来源2] 《物流时效说明》第2章：... [来源3] 《商品退换货流程》第1节：...为什么这个模板有效？因为它做了几件关键事：限定了资料的使用边界，防止模型把资料当闲聊素材；强制要求标注来源，逼着模型“落到具体片段”；还给了模型一个“无信息时怎么办”的出口，避免强行编造。
实际编排时还有几个细节：检索到的片段要先做去重，同一段知识反复出现会把注意力分散；每个片段要裁剪到2-3句话的核心信息，长篇大论塞进去容易把其他片段挤到“被遗忘区”；按相关度排序，最相关的紧挨用户问题。还要注意，不是所有问题都需要检索，如果用户只是在闲聊或问通用常识，强行注入一段知识反而污染回答。这一步可以加一个前置判断：先判断问题是否需要业务知识，不需要就不检索。
3.3 记忆管理：该记住的怎么留，该忘的怎么扔
对话历史是上下文最大的消耗者，也是很多人忽略的地方。一个多轮对话跑了十轮，每轮原文都堆进上下文，窗口几万token很快就没了，后面的模型既记不住重点，又看不到新信息。记忆管理常见的策略有三种：
滑动窗口是最简单的，只保留最近N轮对话原文，优点是不会失真，缺点是很早之前的关键信息彻底丢了。摘要压缩则是每隔几轮把前面的内容生成一段摘要，占用token少，覆盖时间长，但摘要过程本身可能丢失细节或扭曲原意。关键事实抽取更进一步，只提取用户ID、订单号、未完成诉求、用户偏好等结构化字段单独存储，不保存对话过程。
我在实际项目里通常用两级记忆：最近两到三轮对话保留原文，用来处理连续性诉求；更早的内容压缩成摘要，用来维持长程上下文；关键事实单独抽出来存成结构化字段，直接写进系统提示词或注入模板。典型的token配额大概是：系统提示词800token，记忆摘要500token，最近两轮对话1200token，知识片段2400token，预留输出空间。这个预算不是死的，但你要有“上下文额度”意识，而不是随意堆料。
4. 实战拆解：某电商客服助手从“工具人”到“老员工”
4.1 第一版：裸奔式调用，答非所问
先讲一个我参与过的真实项目：某电商平台要做一个客服助手，用来处理售前咨询和售后维权。第一版最简单，用户提问直接丢给模型，没有系统提示词，没有知识库，没有任何上下文管理。
结果可想而知：闲聊还能聊几句，一涉及具体业务就开始瞎编。用户问“七天无理由退货从哪天算起”，模型随口说“从收货之日算起”，但平台实际规则是“从签收之日算起，部分类目不适用”；用户问“运费险赔付金额”，模型直接编出一个数字。业务方崩溃，这玩意只能当玩具，不能上线。
这版的问题非常典型：模型没有角色边界，所以什么话都敢说；没有资料依据，所以只能靠内置知识硬编。第一版给我们的教训就是：模型不是搜索引擎，光把问题丢过去，它只会给你一段“看起来很流畅的幻觉”。
4.2 第二版：结构化护栏，学会不乱说
我们做的第一件事，是写一版完整的系统提示词：明确角色是电商客服，任务边界是售前咨询和售后维权，禁止编造政策，要求引用官方信息时先说明信息来源，遇到情绪激烈用户要转人工。
改动不大，效果却立竿见影：瞎编率明显下降，模型不再张口就来“肯定可以退”“三天到货”，遇到不确定的政策会回答“这部分需要查询最新政策”而不是编造。但新问题很快暴露出来：模型开始说废话，动不动就是“根据我们的退款政策，您可以申请退款”，看似没错，但毫无价值。
为什么？因为提示词里没有任何具体的政策内容。护栏只能挡住“乱来”，却挡不住“空转”。模型知道要有依据、不能乱说，可你根本没给它依据。这时我们意识到，缺的是知识注入，系统提示词解决不了信息缺失的问题。
4.3 第三版：知识注入，从“废话”到“专业”
第二版上线两周后，我们开始做知识注入。把商品说明书、售后政策、物流规则、退换货流程全部切片，向量化，每次用户提问先召回最相关的Top-5片段，再按模板注入上下文。
这一版的提升是跨越式的：七天无理由的起算时间、运费险赔付上限、特殊类目不适用等规则，模型都能准确回答，还会带来源编号。更关键的是，当知识库里确实没有相关信息时，模型会老实说“需要转人工核实”，而不是硬编答案。
第三版也带来了新的难题：知识库的更新机制。政策一改，旧版本切片还留在库里，检索会召回旧片段。我们的补救方案是给每个切片打上版本号和生效日期，在注入模板里加一句“优先使用版本日期最新、与问题直接相关的资料”，把优先级交给模型。这算是知识层和编排层的一次联动调整。
4.4 第四版：动态记忆，从“对话”到“服务”
前三版做完，单轮问答已经很稳了，但多轮场景还是一团糟：用户问完订单问题又问物流，再问退款，模型记不住前面提供的订单号，每次都让用户重新复述；用户已经表现出明显不满，模型还在公事公办地念政策。
第四版我们引入动态记忆管理：抽取用户ID、当前订单号、问题类型、历史诉求，单独存成结构化字段；最近两轮原始对话保留，更早内容压成摘要。同时加了一个情绪识别规则，检测到愤怒、重复追问等信号，直接转人工并附上对话摘要。
这版上线后，几个关键指标全部改善：用户重复提供信息的比例大幅下降，转人工率从32%降到14%，人工坐席接手的会话平均时长也缩短了。用户体感上的差异非常明显——“像一个真正记住了你们家情况的客服，而不是每次都从头开始”。
4.5 落地顺序：先护栏、再知识、再记忆
回头复盘，这个项目的推进顺序很关键。如果一开始就上多轮记忆和复杂编排，问题定位会非常困难。我们实际是按“护栏 → 知识 → 记忆 → 编排优化”的顺序一步步走的，每一步先保证效果稳定，再叠加新能力。
这套顺序我后来在多个项目里反复验证过，都走得通：先让模型不乱说，再让它有东西可说，然后让它记得住，最后才轮到调措辞、调顺序这些细节。顺序反了，你会被各种问题同时淹没，根本分不清是哪个环节导致的。
5. 高频翻车与一条能复用的排查链路
5.1 翻车现场一：长知识的“中间遗忘”
有个知识问答项目，我们把操作手册全文塞进上下文，大概一万多token。上线后发现，模型对手册前部的内容回答得很准，对中部的内容频繁答错，越接近文档中间越离谱。业务方怀疑模型“没学过”，其实问题出在位置上——关键信息被推到了注意力的低权重区。
排查链路是这样的：先固定一条用户问题做最小复现，保持同样的知识注入，逐段删除观察输出变化；然后调换知识片段顺序，看输出是否跟着变，以此确认是“位置敏感”而非“内容缺失”；最后把最相关的三段提到模板最前面，紧跟用户问题，效果立刻回来。
这个案例的教训是：不要相信模型能“通读全文”。上下文是给模型“看”的，不是让它“读”的，位置编排和内容质量一样重要。
5.2 翻车现场二：检索片段把模型“带偏”
某次客服助手迭代中，我们给模型接入了新的价格政策知识库，结果发现模型开始引用一份“已过期三个月”的旧价格表。我们起初怀疑是切片更新没生效，打印出每次召回的Top-5片段一看，问题清楚了：向量检索把旧价格表和新价格表都召回了，旧版本排在前面，模型优先用了它。
这种“带偏”问题比遗忘更隐蔽，因为知识确实“送进去了”，只是送进去的次序和版本出了问题。排查思路是：把召回片段完整打印出来人工复核，确认是否有过时或者不相关内容混入；定位到具体是哪一段让模型跑偏，再在注入模板中明确“优先使用最新版本、与问题直接相关的资料”；同时对低相关度的召回片段做截断，不注入、不浪费token。这个问题的本质是知识层和编排层没有对齐，光改检索没有用。
5.3 翻车现场三：上下文膨胀后的成本失控
还有一个项目让我印象深刻：功能效果很好，但上线一个月后账单吓人。查下来发现，会话跑得越长，每次请求都把全部历史、摘要、知识片段一起带上，输入token从最初的2000涨到8000甚至更多，调用成本几乎是线性往上爬。
成本失控的根源是没有做上下文预算管理。我们加了两层措施：第一层监控，统计每次请求的输入token，重点看P95峰值，凡是超过阈值的会话强制触发摘要压缩；第二层限制，知识注入设定上限，超过就截断最不相关的片段，历史压缩到固定长度。一个简单的“输入token配额表”就能避免大部分成本失控，问题是大多数人压根没这个意识。
5.4 翻车现场四：护栏太密，模型“保险式闭嘴”
另外一个常见问题，是系统提示词里的禁止项写得太多太密，结果模型变成惊弓之鸟，用户随便问什么，它都回答“我无法处理”。业务方一开始以为是模型变笨了，实际是护栏过载——模型被十几条“禁止”吓住了，学会了最保险的回答方式。
修复思路是区分硬护栏和软引导：硬护栏只保留真正的红线，比如“禁止编造政策条款”“禁止给出主观承诺”，数量控制在3条以内；其他表达方式、语气问题全部改成正面引导，比如“先分析用户诉求再给出结构化建议”。护栏不是越密越好，越密的护栏越容易压制模型的正常能力。
6. 让上下文工程可复现：评测集、指标和迭代节奏
6.1 先建一个100条左右的评测集
上下文工程最忌讳“今天改、今天用肉眼看效果”。靠谱的做法是先建评测集，哪怕数量不多。我建议从线上真实对话里抽100到150条，覆盖四类问题：正常业务咨询、边界条件咨询、需要转人工的情绪化诉求、和业务无关的闲聊。每个用例标清楚期望答案的关键点，比如“必须提到七天起算日”“不得给出承诺退款的表述”“必须转人工且附摘要”。
100条够用吗？刚开始完全够。它能让你快速感知一次改动是变好还是变坏，也能在回归测试时拦住明显的退化。随着迭代推进，再把线上出现的新问题逐步补充进去，让它变成活的评测集。
6.2 看哪几个指标最反应上下文质量
满意度问卷这种指标太滞后，做上下文迭代时我主要看几个更敏感的指标：事实准确率，即回答在核心事实上是否出错；引用命中率，即回答声称有依据时，是否真的用到了注入的对应片段；误拒绝率和越界率，即该答的不答、不该答的乱答的概率；转人工率；以及每次调用平均输入token量，这是成本指标。
把这些指标做成一张表，每次改动跑一遍对比，效果是涨是跌一目了然。没有这个基础，你说的“变好了”和同事看到的“还是有问题”，永远对不上。
6.3 按“供给→编排→输出”的顺序迭代
最后说迭代节奏。我自己的排查顺序是固定的：先确认知识有没有送进去——切片、召回、注入是否都正常；再确认送进去的知识有没有被有效使用——模板结构、排序、版本优先级；最后才调整措辞和格式——因为措辞是最容易调也最不该先调的东西。
有一次团队花了两周微调提示词措辞，效果始终不理想，后来发现是知识切片质量太差，召回的全是残缺段落，怎么调措辞都没用。这是个非常典型的反面教材：看起来是输出问题，根子在供给端。所以每次遇到效果波动，我都建议按这条链路排查一遍，绝大多数问题在供给和编排层就能找到答案。
如果只能分享一句话，我可能会说：先把上下文分好层，再谈调提示词。上下文工程看起来没有微调模型那么“硬核”，但大多数业务系统里，决定AI上线效果上限的恰恰是这些不起眼的输入侧细节。我的习惯是给每个改动建版本记录，配套一个小评测集，每次改完跑一遍回归。别急着一次把方案做到完美，先做完“护栏—知识—记忆”这个最小闭环，你会发现模型的表现，已经是另一种水准了。
