每次看到有人抱怨“同一个模型为什么我用起来像个智障别人用起来像个专家”我都想提醒一句问题多半不在模型而在你喂给它看的东西。模型的能力边界在那儿摆着你能控制的是它“看到什么”“先看到什么”“哪些东西不许看”。这就是上下文工程Context Engineering也是我这个标题想做的事让 AI 看到该看的东西。这事儿适合谁两类人。一类是正在做 AI 应用的开发者被幻觉、答非所问、输出不稳定折磨得头秃另一类是重度使用 AI 助手的普通用户发现自己永远在“调 prompt”却不知道为什么时灵时不灵。上下文工程解决的就是同一个痛点如何在不动模型参数、不重新训练的前提下把输入侧的信息组织成模型最容易理解、最愿意遵循的形式。1. 上下文工程到底在“工程”什么先给个定义。上下文工程说的是对整个上下文窗口context window里的信息做设计、裁剪、排序和格式化。它不是写一条好的指令那么简单而是一整套关于“信息如何入场”的学问。1.1 和 Prompt Engineering 的区别很多人会问这不就是 prompt engineering 换了个名字吗真不是区别挺大的。Prompt engineering 的核心是“指令怎么写”——角色设定、语气控制、few-shot 示例、思维链引导都发生在用户消息那一小段文本里。而上下文工程关心的是整个窗口中所有信息的布局系统指令放哪、参考资料按什么顺序、用户问题插在哪、工具返回的结果怎么拼接、哪些历史对话该保留、哪些该丢弃。用生活类比prompt engineering 是教你怎么说话上下文工程是教你怎么布置会议室。同样一拨人进来开会桌椅摆成 U 型还是剧院式白板上写没写议程资料是每人一份还是扔在桌上自己拿最终的会议质量完全不同。AI 对输入顺序、信息密度、格式结构的敏感程度比一般人的想象高得多。1.2 核心目标信噪比管理我做了大量实验后发现上下文工程的所有技巧最终都归结到一件事信噪比。你给模型的信息里有用的部分是“信号”干扰它的、让它分心的、占用注意力的东西就是“噪声”。一个常见的反面教材是做文档问答时直接把一份 200 页的 PDF 全文丢给模型让它“根据文档回答问题”。结果模型频繁引用无关章节的内容忽略了真正重要的条款甚至把不同章节的内容混在一起编造。这就是信噪比太低——文档里大量与用户问题无关的信息稀释了关键内容的影响力。上下文工程要做的就是提高信号强度、压低噪声干扰。手段可以是物理排除只选相关片段、语义加权关键内容放大字体或强调标记、结构引导用 JSON/XML 分层、位置安排放开头或结尾等等。整套方法论围绕“注意力分配”展开模型关注什么输出就靠近什么。2. 上下文的“四层结构”与注意力分布规律如果把一次完整的 AI 交互拆开看上下文窗口里通常塞着四类信息。理解这四层的各自职责是做好上下文工程的地基。2.1 四层结构的组成第一层是系统指令层。这里定义模型的身份、任务边界、输出格式、禁止事项。它的默认权重最高相当于给整个对话“定调子”。我在实践中发现系统指令写得越具体、越没有歧义后续无论用户怎么乱问模型都不容易跑偏。第二层是背景资料层。包括文档片段、数据库检索结果、知识库条目。这一层是最容易失控的因为它往往由外部系统动态注入内容多、格式乱、甚至互相矛盾。上下文工程的大量精力都花在这里清洗、排序、去重、裁剪。第三层是示例层few-shot。给一两个高质量的输入-输出范例比你在指令里写一百句“请遵循规范”有效得多。模型是预测下一个 token 的机器给它看一个优秀答案的样板它就会下意识模仿那个样板的结构和语气。第四层是实时信息与工具结果层。比如调用搜索引擎返回的网页摘要、调用某个 API 返回的数据表、代码解释器算出的结果。这层的特点是“新鲜热乎”但往往没有经过清洗需要额外包装。我通常在工具返回后加一层格式化把最关键的字段提取出来并且标注来源编号否则模型很容易被原始数据的噪声带偏。2.2 注意力不是均匀分配的这是上下文工程里最反直觉的一条规律。很多开发者误以为我给了模型 128K 的上下文窗口这 128K 内容模型都会“认真看”。实际上大量实验和学术研究都指向同一个结论模型对长文本不同位置的注意力权重是不均匀的。我自己实测的体感是开头的内容影响最大结尾次之中间最容易被忽略。学术界有个形象的说法叫“迷失在中间”lost in the middle。你辛辛苦苦放在第 5000 个 token 位置的关键规则很可能模型读是读到了但在回答时根本没想起来用。所以我在组织上下文时的顺序策略是最重要的系统规则、核心目标、禁止事项放最前面或者最后再强调一遍。需要精确引用的事实比如数字、条款尽量靠前并且在后面引用时再次出现。大段参考材料放在中部可以但必须在指令层明确指示“材料在第几段有什么用”否则模型会把它当成背景噪音。与当前任务最相关的即时信息放在用户问题之前、紧挨着问题的位置。有同行提出一个“边缘效应”的说法把关键信息分布在上下文的头尾两端变成两个“锚点”比堆在中间效果好得多。我自己测试下来把一条关键约束用不同表述在开头和结尾各写一遍模型遵守的概率明显提升。这不是让你重复啰嗦而是同一语义的两次编码模型总能捕捉到至少一个强信号。3. 上下文容量悖论给得太多反而看见得更少上下文窗口越开越大很多人的第一反应是“太好了把什么都塞进去”。但我在实操中越来越确信一件事上下文空间是一种稀缺资源不是存储空间。每多一 token 无关信息都会摊薄关键信息的注意力权重。3.1 我踩过的“全量注入”的坑有一次我在做某个指标提取任务要处理一份业务报告。第一版方案是“全部塞进去”心想上下文窗口够大让模型自己找。结果输出惨不忍睹提取出的关键指标漏了三个而且把去年的数据和今年的数据混在一起。后来我调整方案先用规则脚本把报告里跟指标相关的段落截出来剔掉大段的背景介绍和行业分析再把每个指标的上下文按统一格式排列最后在指令里明确“仅引用提供的指标卡片不要自己推断”。同样的模型没有任何参数调整准确率从“没法用”直接变成“可用”。这个对比让我对上下文工程的价值有了直观体感。把根因说透模型的注意力机制本质上在做相似度匹配。它在生成 token 时需要在上下文中找到最相关的信息来参考。如果上下文里有大段词句上和“指标”相关、语义上却不是真正目标的内容模型很容易被带偏。给它干净的、直接对口的信息它当然更容易命中。3.2 信息密度与“适度模糊”还有一层容易被忽略不是所有任务都需要极度精确的上下文。有些任务是开放性创意任务比如头脑风暴、文章框架设计这时候上下文密度太高反而限制模型的发散能力。我做创意类任务时会把背景信息压缩成几个关键词和约束条件而不是完整资料让模型有足够的自由发挥空间。这就是上下文工程里的一个权衡你需要的是“精确检索”还是“开放性生成”精确检索上下文越干净、越结构化越好最好精确到字段。开放性生成保留必要的约束即可不要塞入大量细节否则模型会过度拘泥于给定材料丧失发散能力。理解这个二分法之后你再看“上下文窗口多大才够用”这个问题就会发现真正的答案不是“越大越好”而是“刚好容纳关键信息 留一点余量”。超出余量的部分宁可砍掉也不要硬塞。4. 实操演练从零搭一个规范的上下文前面讲了不少原理现在上一个完整的实操案例。这个案例是我把上下文工程讲给团队新人时常用的也是模拟项目 X指标提取与风险评估Demo的简化版本。任务是这样给 AI 一段业务报告文本让 AI 输出其中的风险项并排序。4.1 第一版完全裸奔我直接把报告原文复制进对话框问“请帮我看看这个报告里有哪些风险”模型输出了一堆正确的废话“可能会影响项目进度、需要关注资金压力……”原因很明显没有角色定义、没有输出格式约束、没有判断标准模型的“默认模式”是生成一段四平八稳的泛泛总结。4.2 第二版加角色和格式于是我加了系统指令你是资深风险管理分析师。请阅读用户提供的报告输出 JSON 格式的风险列表。每个风险项包含severity高/中/低、likelihood高/中/低、description一句话、evidence原文摘录。这版好多了输出结构化了JSON 也能解析。但我很快发现一个问题模型会自己脑补一些报告里根本没提的风险。比如报告只说“研发周期紧”模型就脑补成“研发进度严重超期的风险”甚至给了一个高严重度。这就是典型的“意图漂移”——你给了格式没给边界。4.3 第三版加入判断标准和否定指令关键的转折在于我给了一组“什么算风险”的判据并且明确“没有证据就不要列”。系统指令 你是风险管理分析师。只能基于用户提供的报告原文提取风险不得推测报告未明示的风险。 “风险”定义为以下三类之一a) 报告明确指出的负面事项b) 报告中两个事实组合可能导致的负面结果c) 报告中的数据异常。 判定严重度时综合考虑影响范围和发生概率证据栏必须引用报告原文中的短语禁止改写或编造。 如果某事项不满足上述定义不要输出。这版的输出终于像专业分析师的产物了。风险项的理由都有原文依据改写的证据变少了。从中我能清楚看到模型不会自动知道“该做什么标准”上下文工程的一部分工作就是把评估标准显式化。4.4 第四版用 few-shot 巩固行为模式我最后加了一个示例。因为这种任务里“什么样的风险值得报、什么程度算高严重度”特别微妙文字描述说不清楚一个样例顶过千言万语。我构造了一个模拟的风险条目显示给模型“我希望的高质量输出长什么样”。示例里的风险项刻意包含了一个严重度高但影响范围小的、一个严重度中但发生概率高的、一个原文暗示但未明说的配合证据短语。模型看完之后输出风格基本定住了后续测试多条报告结构稳定率从 70% 提升到了 90% 以上。这个四步演进的过程每一步都在做“让 AI 看到该看的东西”第一不裸奔第二给框架第三给边界第四给样板。最终你发现真正费工夫的不是“写 prompt”而是“整理任务知识”——你需要把脑海里模糊知道的评估标准、边界条件、典型样例全部显式化变成模型能读懂的文本。5. 上下文组织的高级技巧压缩、分层、动态组装处理长文档和复杂任务时光靠“把关键段落挑出来”还不够。下面三个技巧是我长期在用的按推荐程度排序展示。5.1 结构化重构把原始文本变成“卡片”很多源文档的原始结构并不适合直接投喂。比如 PDF 导出后的文本标题和正文混在一起表格变成一行行的乱码。我的做法是先写一段预处理脚本把文档按语义切块每一块变成一个“信息卡片”。每个卡片包含三要素ID、来源位置标签、正文内容。卡片 ID: R-034 来源: 第三章 第2节 表格3-1 内容: 2024年毛利率 42.3%同比下滑 6.1个百分点投喂给模型时系统指令里明确写“引用信息时使用卡片 ID 加 [卡片引用] 标记”。这会让模型的引用行为变得非常可控直接解决幻觉式引用问题。模型不再说“据报告显示”而是说“R-034 卡片显示”。这种把自由文本变成结构化单位的方式是我见过性价比最高的上下文工程手段。5.2 动态组装不是所有内容都要进上下文上下文工程的另一大块是“决定什么不进去”。我常用一个两阶段方案。第一阶段用廉价的、快速的模型甚至可以用规则脚本对检索到的候选片段打分选出与当前问题最相关的 Top N。第二阶段把选出的片段按相关度重新排序最相关的放最靠近用户问题的位置依次向窗口头部回退排列。这个方案背后是对注意力分布的利用既然模型在结尾附近用户问题前的注意力最强那就把最强的位置留给最相关的材料。很多人做 RAG 时直接把检索出的 Top-K 按原始得分从高到低拼接根本不管它们在窗口里的位置效果自然打折。5.3 压缩让模型帮你浓缩信息当原始材料太长连塞进窗口都困难时我的折中方案是“摘要链 层次压缩”。先把长文档切块让模型对每一块生成一段包含所有关键数字和结论的摘要。再把摘要拼起来做一个更上层的摘要。最后只把最上层的摘要和与当前问题直接相关的某一层摘要放进上下文。代价是有信息损失但大多数任务中收益远大于损失——关键是模型在真正回答问题时参考的是高密度摘要而不是稀薄原文回答质量反而提升。很多人在这一步会担心丢了细节怎么办我的经验是给摘要链加一个“按需回溯”机制。系统指令里告诉模型“上下文只有摘要但如果回答中需要某个摘要里的具体细节请指出需要的卡片 ID我会在下一轮提供。”这在多轮交互场景里非常好用既控制上下文体积又不牺牲信息完整性。6. 常见问题排查与避坑实录做久了上下文工程你会发现大多数“AI 不听话”都能归因到几个固定模式上。下面这几张速查表是我自己整理出来的拿来即用。6.1 常见输出问题的上下文侧诊断现象大概率原因上下文侧解法回答太泛、太模板缺角色定义和判断标准加系统指令输出格式约束忽略某一关键规则该规则被放在长上下文中部移到底部或反复强调靠近用户问题引用不存在的内容上下文里的材料结构混乱模型分不清哪些可引用用卡片 ID 标记明确“只能引用卡片”答非所问上下文塞满了与问题无关的附加材料做裁剪只保留高相关片段多轮对话越聊越偏历史消息没有压缩早期无关对话还在窗口里定期清理/摘要历史限制窗口范围相同输入不同输出方差大上下文里存在语义冲突的信息检查是否有矛盾内容统一口径6.2 我亲测有效的三个排除法步骤第一做减法。出现问题时先把上下文砍到只剩“系统指令 用户问题”看模型表现是否恢复。恢复了说明是附加材料里有什么东西干扰了它的判断再把材料一点点加回来找到那个“万恶之源”。第二换位置。如果模型忽略了一条重要的约束别急着换措辞。先把这条约束挪到最靠近用户问题的地方也就是窗口末尾通常问题就解决了。位置权重在很多模型模型中表现极其显著成本为零。第三换格式。如果同一含义的文本规则模型“看见了但没执行”把它改写成一个列表、一个表格或一段 JSON。格式变化会改变 token 序列的分布规律有时候就是这一点变化让模型从“模糊理解”变成“遵循指令”。6.3 高阶避坑上下文工程不是万能的必须诚实地说一句上下文工程有边界。当任务本身超出模型能力上限比如需要复杂的多步推理、数学计算或因果推断时再优秀的上下文组织也只能小幅度改善不能质变。我的判断标准是如果经过三轮上下文优化输出仍然达不到要求那大概率要换更大的模型或者把任务拆解成多个子任务而不是继续在 prompt 里挖。还有一类任务是上下文工程无能为力的需要私有知识的问题。如果这个知识模型训练时没见过你也没在上下文里给它它只能编。不要用上下文工程对抗知识缺失该接检索接检索该建知识库建知识库。上下文工程负责“组织信息”不负责“创造信息”。末尾再补两句做上下文工程这几年我最大的体会是别把它想成一种“取巧”这实际上是在逼迫自己把任务想清楚。你要让 AI 看到该看的东西首先你得知道“什么对该任务是重要的”。这个梳理过程受益的不只是 AI还有你自己对业务的理解。再分享一个小技巧每次只改一个变量。不要同时调整角色、裁剪材料、加示例、改格式那样你永远不知道是哪一步起效的。一次一动用 A/B 的思路慢慢逼近最优实测下来这是最稳、最省时间的迭代方式。