企业官网建设流程全解析

1. 从一次"AI答非所问"说起：上下文工程到底在解决什么问题

去年我接手了一个内部的知识问答机器人项目，那是我第一次真正理解"上下文工程"这个词的分量。项目前期一切顺利，模型跑通了，接口也稳定了，但一上线就被业务部门吐槽：答非所问、信息陈旧、一本正经地胡说八道。

最典型的一个场景：用户问"我们平台现在对退款时效是怎么规定的"，机器人直接根据训练数据里的旧政策给出"7个工作日内到账"。实际上运营团队三个月前已经调整为"48小时内原路退回"。业务的人当然不理解什么叫模型幻觉，他们只知道这个东西不能用。

当时我的第一反应和大多数做同样事情的人一样：改提示词。我在系统提示里加了"请务必基于最新政策回答""如果你不确定，请直接说不确定"，试了好几版都没有实质变化。后来我才想明白，问题的根源不在"怎么问"，而在"模型眼前有没有正确答案"。

这句话就是上下文工程的核心逻辑：模型的能力上限，很大程度上取决于它在这个时刻能看到什么、以及这些信息以什么形态出现在它面前。

所谓上下文工程，就是围绕大模型上下文窗口做的一系列设计、筛选、组织和更新工作，确保模型在推理时拿到的信息是相关的、准确的、结构清晰的，能直接支撑它给出正确输出。

很多人会把上下文工程和提示词工程混为一谈。我个人的理解是：提示词工程解决的是"怎么跟模型说话"，上下文工程解决的是"让模型看到什么信息、以及这些信息怎么摆放"。提示词像是给员工下指令的方式，上下文工程则是决定你递给员工的资料包里装了什么、按什么顺序放、哪些是过期的。

这里列个简单的对照，方便大家快速建立感觉：

现在各类大模型都在拼上下文长度，几十万、上百万 token 的窗口也不再新鲜。但有一种普遍错觉是：窗口大了，上下文工程就不重要了，把全部资料塞进去让模型自己挑不就行了。这个想法我踩过很大的坑，后面会细说。

简单总结：上下文工程之所以重要，是因为你不可能指望一个模型"知道"所有本该知道的东西。它的出厂知识来自训练语料，是滞后的、静态的；而真实业务的信息是动态的、分散的、有噪音的。上下文工程，就是在这两者之间搭桥的那个人。

2. 上下文窗口的"存储器"本质：为什么模型聪明但记不住

要理解上下文工程为什么重要，先得理解大模型的"记性"是怎么回事。

用一个不太严谨但很好用的类比：模型预训练阶段学到的知识像是人的长期记忆，存在大脑皮层里，稳定但不一定记得清所有细节；上下文窗口则像是工作记忆，也就是你此刻手边桌面上摊开的材料。一个人再聪明，如果桌面上那份材料是错的、缺失的或者被压在三十层文件下面，也不可能给出正确答案。

模型就是这样：它能做复杂推理、能写代码、能总结长文档，但这一切的前提，是相关内容确实出现在它的上下文窗口里，并且处于它"注意得到"的位置。

这里就引出了第一个反直觉的点：给模型的信息不是越多越好，因为在长上下文里存在严重的注意力分配问题。

2.1 "迷失在中间"现象

业内有个很出名的说法叫 Lost in the Middle，意思是当关键信息被放在一段很长的上下文正中间时，模型找到它并用好它的概率会明显下降。模型对开头和结尾的内容处理得更好，中间段落容易被稀释。

我自己复现过这个现象：把同样一份技术文档的核心结论分别放在上下文的开头、中间和结尾，让模型回答同一个问题。放在开头和结尾时，准确率能到九成左右；放在中间时，直接掉到七成以下，而且模型会一本正经地引用错误段落。

这说明一个问题：上下文不只是"有什么"，还包括"在哪"。信息的摆放位置，本身就是工程对象。

2.2 token 不是免费的

长上下文的第二个问题是成本和时间。现在不少模型支持百万级 token，输入输出按 token 计费，输入越长，单次调用越贵。同时，输入长度增加会导致首 token 延迟明显上升。

我在做文档问答系统时统计过：一段 20 万 token 的上下文，单次调用的输入费用是一次 2 万 token 的十倍以上，接口响应时间也从 1 秒左右涨到 6-8 秒。业务方根本接受不了这种延迟。所以上下文工程里有个基本功叫"token 预算"——你必须在效果和成本之间做显式的取舍，而不是放任自流。

提示：凡是上线到真实业务的模型调用，建议第一件事就给上下文设硬预算。比如单次调用输入不超过 3 万 token，超出即触发压缩或检索策略。没有预算的方案，上了线一定会被账单和延迟教训。

2.3 内部知识与外部事实的冲突

第三个容易忽视的点是：模型并不会因为你在上下文里放了正确答案，就老老实实用它。它的内部知识会"参与竞争"。

举个例子，我让模型基于某公司 2024 年的内部制度文档回答薪酬结构的问题，文档里写得很清楚，但模型训练语料里可能有很多"通用薪酬常识"，于是它经常把两者混在一起，输出一份"看起来合理但完全错误"的答案。

这就是上下文工程要处理的另一个问题：当外部事实和内部知识冲突时，如何让模型明确判断"以这段材料为准"。光靠一句"请严格依据材料回答"往往不够，还需要在材料本身的组织方式上做文章，比如给材料打上明确的来源标识、日期标识、优先级标识，让模型能区分"背景知识"和"权威依据"。

3. 上下文工程的核心基本功：选、排、更

理解了为什么难，接下来就是怎么做。我把上下文工程拆成三件事：选什么、怎么排、怎么更。

3.1 选什么：相关性、时效性、去重

选材料是第一道关口。一个真实业务场景里，和某次问答相关的知识可能散落在产品手册、售后流程、历史工单、版本更新公告里。如果全部塞进去，上下文立刻爆掉；如果选错，模型就会答错。

我常用的筛选维度有三个：

• 相关性：和当前用户问题直接相关的材料优先。相关度打分可以靠向量检索的相似度，也可以靠关键词规则先粗筛再精排。
• 时效性：带有时间戳的内容，旧版本一定要能识别并降低权重甚至排除。很多业务知识的正确性是有保质期的。
• 去重：同一件事被不同文档说了三遍，只保留信息最完整、表述最清晰的那份。重复内容不但浪费 token，还会干扰模型的判断一致性。

3.2 怎么排：结构标签和优先级布局

选好材料之后，摆放方式直接影响最终效果。

我强烈建议把上下文组织成有明确边界的结构，而不是把一大段文字直接糊上去。实际操作中，我会给不同类型的材料加上统一的文本标签，比如：

<系统指令> 你是一个客服知识助手。回答问题时必须严格依据下方资料，不得使用资料之外的推测。 </系统指令> <用户画像> 用户等级：VIP；最近一次咨询：2024-11-02；历史投诉次数：1 </用户画像> <知识库资料> <来源 文档="退款政策_v3" 更新日期="2024-10-01" 优先级="高"> 1. 普通订单退款时效为 48 小时内原路退回。 2. 生鲜类订单不支持无理由退货。 </来源> </知识库资料> <对话历史> 用户：我还想确认一下生鲜订单能不能退… </对话历史>

这个模板是我在某客服机器人项目里实际用过的简化版。可以看到，每一块信息都有明确的边界和属性，模型解析起来非常轻松，不同角色信息互相污染的概率会大幅下降。

布局上有个通用经验：把最核心的指令和结论放在上下文的开头，把大段参考资料放在中间，把当前对话或最新状态放在结尾。因为模型对开头和结尾的注意权重更高，这样的布局能最大化关键信息的利用率。

3.3 怎么更：动态上下文、多轮记忆和检索更新

上下文工程不能用一次性的眼光来看，尤其对话类系统里，每轮对话的上下文都应该动态调整。

多轮对话场景常见的坑是：把所有历史对话一股脑全带上。聊到第 20 轮时，前面 19 轮的信息已经严重挤占了窗口。我现在的做法是分三层管理对话记忆：

• 近期原文层：保留最近 3-5 轮完整对话，保证模型对当前语境有完整理解。
• 摘要压缩层：把更早的对话定期用模型压缩成结构化摘要，比如"用户已确认收货地址为上海；对物流时效不满；要求优先发货"。
• 长期画像层：从历史对话中抽取的用户永久属性，例如会员等级、常用地址、偏好渠道，这些信息永远占用固定的小块空间。

检索更新方面，核心是保证每次问答都去知识库里拉取最新的相关资料，而不是把整个知识库放进上下文。我的标准架构是：问题进来后先做改写和意图识别，然后向量检索出 Top-5 相关内容，再用重排模型精排到 Top-2 或 Top-3，最后拼进上下文的资料区。每一轮都是动态拼装出来的，而不是静态模板。

4. 实战复盘：一个客服知识库机器人的上下文设计方案

光讲概念容易飘，我把最近一个真实项目的设计过程完整复盘一下。项目背景是某电商公司（我习惯叫它"模拟项目X"）要做一个客服知识库机器人，替代人工回答退款、物流、优惠券等高频问题。目标是首轮解决率达到 80%，不能给出过期政策。

4.1 第一步：先定上下文结构模板

我没有先写代码，而是先画了一张"上下文地图"，明确每一块信息占多少 token、优先级如何、什么时候出现。最终定下来的结构是：

总预算控制在大约 5000 token，远低于模型窗口上限。这样做的原因是：我们测算过单次调用的响应时间预算不能超过 2 秒，且当时的计费模型下，5000 token 是一次 20000 token 成本的 1/4。

4.2 第二步：检索链路的质量排查

项目最早跑通时，"答错"中的七成其实是检索环节出了问题：政策文档更新了，但旧的版本还在库里，向量检索经常把新版旧版一起召回，模型有时就翻了旧版的牌。

解决办法是给每份文档加了元数据字段：版本号、生效日期、状态（有效/已废弃）。检索前先按状态过滤，检索结果里如果同时出现多个版本，按生效日期排序并显式标注在标签里。这一步改进后，政策类问题的准确率从 68% 提到了 89%。

注意：很多上下文工程的问题，根源根本不在模型侧，而在上游的检索和数据治理。排查顺序应该是：数据干净不干净 -> 检索准不准 -> 上下文结构清不清楚 -> 最后才是模型和提示词。

4.3 第三步：多轮对话状态的上下文管理

客服机器人一定会遇到追问场景。用户先问"退款几天到账"，再问"那生鲜呢"，如果模型看不到前面的"退款"主题，第二问就没法答。

我们当时在上下文里维护了一个"当前话题槽"，把用户的核心诉求、已确认条件、待确认条件固化下来。比如用户咨询退款的整个会话中，话题槽始终是"退款-时效"，已确认条件是"订单类型=普通订单"，这样即使某轮用户话术很简略，模型也能结合话题槽给出正确回复。

这里有个技巧：话题槽信息要放在上下文靠前的位置，并且用一个独立的标签块隔开。实测放在开头时，追问场景的准确率比放在对话历史后面高出 12 个百分点。

4.4 上线后的效果对比

把第一阶段的效果数据拉出来做个对比，上下文工程前后的差异非常直观：

我要特别强调"单次调用平均输入 token"这个指标。上下文工程做减法做出的成本节省，在这个项目里直接让整体推理费用降到了原来的四分之一。很多时候我们以为上下文工程是给模型"喂更多资料"，实际上高手在做的是"喂更对的少量资料"。

5. 高手与踩坑的分水岭：常见误区与进阶玩法

最后这一部分，我把自己踩过和见过的坑集中整理一下，再说说进阶方向。

5.1 五个最常见的误区

第一个误区：上下文越长越好。我前面已经讲过 token 成本和"迷失在中间"的问题，这里直接给结论：长度超过必要值之后，边际收益是负的。

第二个误区：上下文工程就是写提示词。提示词只是上下文结构中最上面那一条"系统指令"，真正的功夫在资料的选择、组织和更新上。很多团队花了大量时间调提示词，效果平平，一查发现知识库里有 40% 是过期的重复文档。

第三个误区：不区分事实源和背景知识。正确做法是在上下文里显式标注哪些是"权威依据"、哪些只是"参考背景"，并明确告知模型冲突时以谁为准。否则模型一旦把两者混在一起，就会产生一种"混合型幻觉"，最难排查。

第四个误区：多轮对话全量携带历史。这在长对话里简直是 token 黑洞。我见过一个项目，他们的机器人聊到 15 轮时输入已经跑到 4 万 token，响应时间严重超标，而且后续轮次准确率越来越差，就是因为旧信息噪声淹没了当前的提问。

第五个误区：没有评估体系。上下文工程改来改去，凭感觉说"好像变好了"，这是做项目的大忌。至少要建一批回归测试集，比如 100 个典型问题和 20 个对抗性问题（故意用模糊表述、误导信息），每次改动后跑一遍，看准确率和成本指标的变化。

5.2 进阶方向一：上下文压缩与分层摘要

资料太多且不能删时，压缩是比截断更好的选择。我常用的策略是层级摘要：先对每份文档生成独立摘要，再对相关文档组生成更上层的联合摘要。回答问题时优先使用联合摘要，细节不足时再展开到单文档摘要或原文片段。

这个做法很像人类做调研：先看提纲，需要时再翻正文。在一次合同审查辅助项目中，我把一批平均 8 万字的合同压缩成层级摘要体系后，单次问答的输入从 6 万 token 降到了 6000 token，关键条款的引用准确率反而从 82% 升到了 93%。

5.3 进阶方向二：多段检索与自适应上下文

更高阶一点的做法是让系统先"看一眼"再决定展开多少。具体来说，第一轮用最精简的上下文（只含系统指令和粗检索结果），让模型判断自己有没有把握回答；如果把握不足，就触发第二轮，追加更详细的资料片段继续推理。这有点类似人遇到不会的问题时先翻目录，再翻书页。

自适应上下文还有一种形态：根据用户问题的复杂度动态调整检索深度。简单问题只给一条 FAQ；复杂问题则同时拉取政策原文、历史工单案例、同类型问题的历史回复。实测在混合问题集上，自适应方案比固定 5000 token 模板再节省 30% 的成本，准确率持平。

5.4 关于评估的最后一段话

我在这类项目里最后养成的习惯是：每一次上下文结构调整，都同时记录三个数——准确率、平均输入 token、平均响应时间。任何一次改动，只有三个数里至少两个变好且没有变坏的，才允许合入正式版本。这个朴素的标准帮我挡住了很多"感觉更好了"的伪优化。

上下文工程这个领域还在快速演进，工具的称呼和形式可能会变，但底层逻辑很稳定：模型是世界知识的承载者，而上下文是它此刻唯一能依赖的事实来源。谁能把事实来源管理得更精准、更高效，谁就能让模型在真实业务里真正靠得住。做了一年多之后，我最大的体会是：别把上下文工程当成一个可有可无的调参环节，它应该和提示词设计、数据治理一起，被视为大模型应用落地的前置工程。