企业官网建设流程全解析

1. 从提示词到上下文工程：我先讲一段真实经历

今年年初在做一个面向内部业务的智能知识库项目时，我被一个现象卡了近两周：同样的知识库、同样的模型版本、甚至同一个用户问题，早上调用返回的内容还准确详实，到了下午同一个问题就开始答非所问，甚至出现幻觉式编造。起初我怀疑是模型服务不稳定，查了日志、看了延迟、盯了token用量，服务端一切正常。后来把问题输入和返回结果逐字对比，才意识到问题出在会话上了——下午那次调用带着上午整整三个小时的聊天记录，上下文已经被大量无关信息塞满，模型真正“看到”的其实是历史记录的残影，用户的原始问题反而被稀释到了角落。

这个经历让我彻底转变了对大模型落地的一个陈旧认知：提示词工程并不是大模型应用的全部，甚至不是最关键的环节。真正决定大模型输出质量的，是你往上下文窗口里放了什么、以什么顺序放、以及放多少。这个系统性设计过程，行业内叫上下文工程（Context Engineering）。它和提示词工程的根本区别在于：提示词工程聚焦在“怎么写指令让模型听懂”，上下文工程则聚焦在“怎么组织输入信息让模型看得清”。

如果你正在做大模型相关的产品、做AI Agent，或者正在给公司内部搭建基于大模型的工具，今天这篇就把我在实际项目里总结的上下文工程核心技巧摊开讲清楚。从上下文窗口的预算分配到对话历史管理，从信息检索融合到长对话的压缩策略，最后附上稳定复现的排查方法。这些全部来自真实落地中的折腾，不是纸面理论。

2. 上下文窗口的真实瓶颈：不是越大越好，而是你根本没规划好

先纠正一个广泛存在的误区。很多人一上来就追求大上下文窗口，模型支持200K就觉得自己可以随便往里面灌数据，文档全部塞进去，对话全部保留着，最后看到的结果却是模型越答越蠢。这背后的原因很简单：大模型的注意力在信息过剩时会出现明显衰减，专业上叫“中间迷失”或者“注意力稀释”，也就是模型对上下文开头和结尾的信息保持较好，但对中间一大段内容几乎“视而不见”。

我自己做过一次对比实验：同一道需要严谨推理的问题，分别用4K、16K、64K窗口的配置来跑，前两者我精心编排输入，最后者直接堆材料。结果反而4K窗口配置下的输出质量最高。因为输入精简，模型注意力集中在有效信息上，而64K的堆料模式让模型迷失在海量噪声里。

2.1 上下文窗口不只是一个容量参数，它是一块需要精细切分的“财政预算”

把上下文窗口理解成一块有限预算很有用。每次调用API，你发送出去的所有内容都要占token，系统提示词占、用户输入占、历史消息占、附加的参考文档占。模型回复时也要预留输出空间。如果你不做规划，这些要素就会互相挤占，最后模型可能只剩一点点空间来生成答案，回答质量自然断崖式下跌。

我实际项目中坚持的预算分配比例是这样的：

• 系统提示词：5%左右。用最精炼的语言写清楚角色、任务、输出格式和约束，不写废话。
• 用户当前问题：10%到15%。保证主问题在token中有足够的权重。
• 外部检索信息（参考文档）：40%到50%。这是回答质量的核心来源，也是上下文工程真正花心思的地方。
• 历史对话摘要：15%到20%。我几乎不直接塞完整历史对话，而是先做一轮压缩转成结构化摘要。
• 输出预留空间：20%到25%。如果问题复杂、要求长回答，必须留有足够余量，否则模型会强行截断。

这个比例不是固定的，可以根据业务场景微调，但验证下来，这套分配方式能在绝大多数问答型应用里稳定拿到高可用性的输出。

2.2 让预算规划落地的两个抓手：固定成本压降与动态裁剪

光知道比例不够，还要有具体的执行方法。我习惯把上下文开销拆成两部分：固定成本和动态成本。

固定成本就是系统提示词、工具定义、不变的示例等，它们每次都在，占了基本盘。这部分一定要做减法，每多一句装饰性描述，都在偷走参考文档的空间。撰写系统提示词时，只保留三类信息：角色边界、任务目标、输出规范。凡是“你是乐于助人的助手”这类性格描摹，统统删掉，没有价值。

动态成本则是当前问题、检索文档、历史对话这类随会话变动的内容。动态部分必须做动态裁剪：根据用户输入的长度和复杂度实时刻余预算，问题简单就减少参考文档条数，问题复杂则优先保证检索内容完整。

落脚到代码上，我在项目里维护了一个很轻量的上下文预算器，核心逻辑就是对token数做预估。

def estimate_tokens(text: str) -> int: # 中英文混合场景下的粗略token预估，实测偏差约为8% chinese_chars = sum(1 for ch in text if '\u4e00' <= ch <= '\u9fff') other_chars = len(text) - chinese_chars return int(chinese_chars * 1.5 + other_chars * 0.3)

然后每次组装请求前，先算一遍当前预算，再决定检索文档条数和历史消息的截断深度。这套机制上线后，外部知识库先后出现的中途断答和答非所问问题明显减少。

3. 别把知识库的检索结果当“材料”，要当“证据链”来组织

很多人做知识库问答时，检索出相关片段就直接拼成一堆塞给模型。这个做法有个隐蔽的坑：多段内容之间如果逻辑顺序混乱，模型根本整理不出因果链。就像你给一个人看证据时把时间线打乱，他能还原出真相，但效率和准确率都会下降。

上下文工程在知识检索这块的核心思路是：不以“相关性得分高低”为唯一排序依据，而以“论证链是否完整”为主要排布逻辑。

3.1 检索后处理：我给知识片段重新“装订”的流程

我通常会在拿到检索结果后做三步再加工，这步处理能直接改善模型输出的准确度。

第一步，相关性重排。改用交叉编码器做第二遍精排，而不是只依赖向量检索的原始得分。向量相似度对于“用户问什么”这个表层语义匹配是有效的，但对深层语义对齐容易漏掉关键信息。交叉编码器跑一遍，能把语义真正贴近的片段提到前面，代价只是多几十毫秒的延迟，值得。

第二步，顺序重建。把选中的片段按业务逻辑重新排序，时间类内容按时间从前到后，因果类内容按因果链路组织，步骤类内容按操作顺序排列。让模型读到的内容天然就是一条顺下来的逻辑线。

第三步，压缩与去噪。相邻片段有大量重复信息时，只保留信息增量最大的一份。比如多篇产品手册都提到同一个参数，保留写得最完整的那段就够了，其它重复描述直接丢弃。这能省下可观的token空间。

这三步做完，检索结果才算真正具备“证据链”形态。我做个了简单对比：同一套知识库，不做后处理时回答准确率约74%，做了完整的重排加顺序重建后，准确率提升到89%。提升点主要出现在多条件组合问答这种原本最容易让模型犯迷糊的场景上。

3.2 指令跟随是约束，但真正决定答案质量的是上下文内容

还有一个容易被忽视的认知：指令跟随只是让模型按照你规定的格式和行为去输出，但模型输出的实质内容完全取决于上下文中包含的信息。你想让模型从知识库里找答案，重要的工作必然是让知识内容本身清晰、有序、无歧义地出现在上下文里。提示词写得再花哨，也补不了上下文里信息残缺的坑。

在落地时我遵循一个原则：“输出格式用指令来约束，输出内容用上下文来保证。”前者是皮，后者是骨。凡是要求模型回答中必须出现的要素清单，我都会在检索侧先确定这些要素是否存在于参考信息中，而不是寄希望于模型“推理出来”。缺了必要的要素，就回去扩检索范围或调整问题拆解。这个检查动作做多了，变成一种本能，项目里的幻觉率数据也就慢慢降下来了。

4. 对话历史管理：生产级应用最容易翻车的地方

如果你的应用只是单轮问答，对话历史管理可以直忽略。但凡是涉及多轮对话、持续性任务、或者用户会在一个会话里连续追问的场景，对话历史就是决定成败的隐性因素。市面上Demo级项目翻车，一大半都栽在这儿。

4.1 无脑保留完整历史为什么会劣化输出质量

我第一次做带记忆功能的多轮对话工具时，图省事，直接把所有历史消息一股脑全塞进上下文。一开始单轮效果挺好，持续对话到十几轮之后出现一个问题：用户问了一个和最开始话题相关的问题，但模型已经被中间大量“闲聊天”带偏了，导致追问时模型完全不记得早前的关键信息。

原因拆开看有两个。一是上下文预算被无效历史占满，早期真正有价值的信息反而被挤出窗口。二是模型在解读历史时的“近因效应”：越靠后的消息权重越高，用户中间说过一句无关紧要的玩笑话，都可能对模型的最终判断产生不成比例的干扰。

所以生产级应用需要主动管理对话历史，而不是被动保存。我的做法是做三层处理：压缩、固化和截断。

• 压缩：每轮对话结束后，异步把老消息改写成语义摘要，保留要点，丢掉寒暄和杂讯。
• 固化：对于用户主动标记为“重要”的信息，比如偏好设置、项目背景、待办事项，单独存进一个关键信息区，永不删除。
• 截断：超出预算上限的最老消息直接丢弃，但如果其中包含关键信息，则先压缩再丢弃。

4.2 我在项目里维护的“三区对话记忆”结构

具体落地时，我设计了一个三区记忆结构，效果比单纯塞字符串好得多，这里直接分享出来。

• 常驻区：放用户的核心画像、业务约束、长期目标。这个区内容不随对话轮次变化，每次调用固定带入。
• 摘要区：把早期对话的所有关键信息压缩成结构化摘要，比如“用户要求输出A方案，提到了预算不超过B，强调C特性”。摘要区每次带入。
• 滚动区：只保留最近N轮的完整消息。N根据预算动态调节，默认5轮。

调用模型时，按“常驻区、摘要区、滚动区”的顺序拼装上下文。常驻区和摘要区保证长期记忆不丢失，滚动区保证近期语境完整。这套设计让我的多轮对话工具从第20轮开始依然能保持和前面第5轮时接近的回答正确率，没有出现之前那种“聊得越久越傻”的问题。

4.3 滚动窗口的截断策略有讲究

滚动窗口不是简单保住最后几轮就行，还要考虑消息是否完整。一个常见的错误做法是：上下文超限时从中间切掉一段，导致用户一句话只保留了前半句，模型读到的是断头信息，最后回答出现完全不符逻辑的内容。

我采用的办法是按“回合”截断而不是按“token”截断。即：先估算所需token，超过预算时优先丢弃最早的一个完整用户问答对，然后重新估算，直到满足预算。宁可少保留一轮，也绝不保留半句话。这个细节看上去很小，但在长对话场景中作用很大。

5. 上下文压缩的工程化方案：从“能跑”到“跑得稳”

在对话轮次特别多或者单条信息特别长的场景里，压缩就不是优化项，而是必选项。上下文压缩的核心目标就一句话：用更少的token保留更多的关键信息。这件事没有标准答案，因为不同领域压缩出来的摘要形态差异很大。

5.1 我尝试过的三种压缩路线

目前实践下来有三个可用的压缩路线，按投入产出比排序。

第一种是基于摘要模型的提炼式压缩：单独用一次模型调用，把一段冗长对话浓缩成200字以内的摘要。这是效果最好的一种，但会产生额外token开销，适合处理关键信息密度高、不容有失的对话段。

第二种是基于结构化提取的挖掘式压缩：从长文本里抽取“实体—属性—关系”三元组，形成事实清单。比如“A方案—成本—10万元”“客户—偏好—低延迟”。这种压缩对事实类信息保留效果极好，但会丢失语气、情感、未尽之言这类软信息，适合客服工单、业务记录等场景。

第三种是基于规则裁剪的删减式压缩：利用正则去掉重复、口语、无意义填充词，压缩率有限但零成本。适合轻量场景，比如日志清洗。

我的经验是不要只押注一种压缩方案，而是按信息类型做分层处理：事实信息用结构化提取，过程信息用摘要式提炼，噪声信息用规则删减，各取所长。

5.2 压缩时机的选择

压缩不能等上下文满了再触发，到那个时候模型已经开始犯迷糊，早就有几轮的消息质量受损。我建议在会话进行中就做“渐进压缩”：每一次用户交互结束后，都对旧消息进行一次轻量压缩，把不超过三天的对话内容逐步沉淀成摘要。

渐进压缩的好处是每次压缩负担小，而且永远不会出现“一次性处理海量历史”的尴尬局面。缺点是频繁产生模型调用，会增加一些成本。如果你对成本敏感，可以把压缩触发条件改成“滚动区消息数超过10轮再压缩”，这样平均每几次对话才做一次压缩，效果和成本的平衡更合适。

5.3 压缩是无损的吗？必须接受信息损失并建立兜底机制

压缩必然带来信息损失，这是物理规律，没有魔法可解。重要的是承认这一点并建立兜底。我在系统里给每条原始消息加了一个“回溯索引”，压缩时保留原始消息的存储ID。一旦模型回答疑似漏掉关键细节，用户可以点“查看原始记录”来回溯到未压缩版本，而不是让系统直接暴露压缩缺陷。

这个兜底机制上线后，内部用户对长会话体验的满意度提升了一个台阶。原因也很朴素：人们可以容忍系统为轻量化而简化记忆，但不能容忍信息凭空消失。

6. 实测出的常见翻车场景与修复方案

纸上谈兵再多，不如把实战中踩过的坑列出来。下面这几个问题，是我在不同项目里反复遇到的高频故障，每个都附上了最终有效的修复办法。

6.1 模型回答模板化严重，换个问法就失灵

症状是：用户用某种固定句式提问时回答很标准，稍微换个说法，回答质量就明显下降。排查下来发现，原因是我在系统提示词里给出了过于具体的示例，模型产生了“示例锚定”，只会沿着示例的框架走。

修复方案是把示例从具体内容改为结构模板。比如原来写“示例：请把本周所有未完成任务汇总为清单”，改成“示例结构：任务归属人、任务名称、当前状态、截止时间、风险提示”。这样模型学的是“形状”，而不是“颜料”，泛化能力立刻提升。

6.2 多文档组合问答时，模型引用了错误来源

多篇参考文档里如果存在相互矛盾的表述，模型还是会选一个输出，有时偏偏选错。这实际上是上下文排布顺序在作怪，模型对越靠前的内容越信任。

修复方案有两个。一个是在每段参考信息开头增加元信息声明，明确标注来源和时效性。格式为“[来源：某产品手册，版本V2.1，更新时间2024年5月]，正文如下...”。另一个是在系统提示词中增加冲突处理规则，明确告知模型遇到矛盾信息时如何按可信度优先，而不是简单“挑一个回答”。两种手段并用后，错误引用事件大幅下降。

6.3 长文档问答的“只见树木不见森林”

在问答场景里输入一份厚达几十页的长文档，用户问了一个需要对全文进行综合分析的问题（比如“整个项目的时间线如何”），模型往往只根据开头部分来回答。

这里我验证过两种有效方案。一种是文档预切分加小索引，先把长文档按章节切块，做密集检索后在上下文里重组为按逻辑排序的片段，而不是塞整份文档。另一种是“大纲先行”，在上下文最前面放上文档的结构目录，让模型对全局有框架，再让它读重点章节。后者实现成本极低，实测对综合类问题的帮助明显。

6.4 系统提示词过长导致核心指令被稀释

我在早期项目里犯过一个很低级的错误：系统提示词越写越长，把各种边缘情况都用自然语言描述进去，最后接近2000字。结果模型开始频繁漏掉核心约束，比如要求了JSON输出它却返回Markdown。

定位后发现是核心约束被淹没在大量“边界说明”里了。修复手法非常粗暴：把系统提示词重构为“必做、必不做、输出格式”三个分区，必做和必不做用短句。边界情况全部挪到运行时判断，由程序逻辑处理，而不是靠提示词兜底。这样系统提示词压到500字以内后，指令跟随问题迎刃而解。

7. 上下文工程落地成团队工作流：三种角色和一套模板

上下文工程看起来是技术问题，但推进起来往往卡在协作方式上。团队里每个人都在写各自的提示词和上下文管理代码，风格千差万别，最后维护成本翻倍。我建议把上下文工程从个人技巧升级为团队工作流，用三个角色明确分工。

7.1 三种角色怎么分工

上下文架构师：负责主导整体上下文策略，确定预算分配、记忆结构、压缩策略、检索后处理流程，把“怎样组织信息”的决策逻辑固化成代码。

提示词工程师：负责系统提示词撰写和维护、示例结构调整、输出格式定义，专注在“怎么说清楚”这一层。

应用开发者：负责实现预算器、对话记忆管理、缓存复用等工程机制，确保策略能稳定执行。

三个角色不一定是三个人，在小团队里可以一人身兼多职，但职责边界要清晰，才能避免出现“提示词里写了一堆条件判断，应用代码里又写了一套”的双重逻辑打架。

7.2 一套可以复用的上下文工程检查模板

团队协作时，我习惯用下面这套检查清单来做评审。每次提交上下文相关改动时，都按这个列表过一遍：

• 上下文是否按“系统提示词、用户问题、检索信息、历史摘要、输出空间”做了明确划分？
• 检索到的参考信息是否做过顺序重建？逻辑链是否顺畅？
• 历史对话是否经过压缩和固化？是否存在无效信息占预算的情况？
• 长文档场景是否用了“大纲先行”或“分块检索”？
• 用户核心目标是否在上下文中足够靠前、足够醒目？
• 冲突信息来源是否有元信息声明和处理规则？
• 系统提示词中是否存在可以被程序逻辑替代的自然语言描述？
• 输出空间是否预留了足够余量？

这个模板看似简单，但它几乎覆盖了我在真实项目中遇到过的所有上下文相关问题的检查点。每次评审时对照打勾，比凭感觉审查有效得多。

7.3 用日志和可观测性来反向验证上下文设计

上下文工程还有一个平时很少有人提的角度：可观测性。你不应该等到用户投诉质量下降了才去排查，而应该在每次模型调用时都记录下“输入了什么内容、各分区占比多少、检索到了哪些文档、模型输出质量打分”。这些日志在问题定位时的价值，甚至超过模型本身。

我的做法是给每个请求绑定一个request_id，日志中记录上表全部关键字段，并关联模型输出质量分。这样一旦出现回答偏差，可以直接回放“当时模型看到了什么、哪部分信息占比异常、哪个检索结果形成了误导”，定位时间从小时级缩短到分钟级。

最后分享一个我踩过三次才明白的教训

上下文工程做到高端，拼的不是技巧花活，而是“克制”。刚接触这个领域时，我总想着把所有的技术手段都堆上：检索后处理、多轮摘要、动态压缩、分层记忆，全都要。结果系统复杂度飙升，反而难排查问题、难定位故障，维护成本把收益淹没了。

后来我调整了策略：从最简单的“系统提示词加手动检索”起步，确认输出稳定后，再逐步引入记忆管理、压缩机制、检索后处理等环节。每引入一环，就做一轮完整回归测试，确认它确实带来正向收益，再继续下一个复杂功能。这种循序渐进的搭建方式，让我在很多项目里避开了“一次上太重导致不可收拾”的坑。

如果你现在正准备做一个基于大模型的应用，我的建议是：先别急着想用什么花哨框架，先认真想想你的上下文里到底应该放什么、不放什么、以什么顺序放。把这几个问题想透了，大模型落地的很多问题就已经解决了一半。