企业官网建设流程全解析

我真正开始认真研究 Context Mode，不是从技术文档里，而是从一次尴尬的演示翻车开始的。当时我做了一个基于大模型的客服问答原型，客户在演示现场上传了一本 60 页的售后政策手册，然后连续问了三个问题。系统确实"接住了"，但它的回答每一句都像第一次看到这份手册：第一个问题答了，第二个问题又开始重新自我解释，第三个问题直接忘了用户一开始说的订单信息。客户很客气地问了一句："你们这个不是有上下文模式吗？"

这一问让我意识到，Context Mode 不是一个勾上就能用的开关，而是一整套关于"模型如何接收、整理、取舍信息"的设计。它横跨提示词、检索、记忆管理和成本控制。这篇文章不聊概念名词，就聊我怎么从翻车到跑通，以及你现在可以照着做的落地方法。适合正在做 AI 应用、尤其是文档问答和客服场景的开发者与产品负责人。

1. 先搞明白：Context Mode 到底在解决什么问题

1.1 一次对话为什么会"断片"

先还原那段让我破防的对话，很多人看完会觉得似曾相识：

用户：退换货流程是什么？
AI：请提供订单号，我来帮您查询。
用户：订单号是 A12345，退换货需要几个工作日？
AI：根据售后政策，退货需在签收后 7 天内申请。请问您的订单号是？
用户：我刚刚说了，A12345……
AI：抱歉，我没有查询到该订单的信息。

这种"断片"太典型了。它的根因不是模型记忆力差，而是我的提示词没有帮助模型建立"上下文优先级"：用户刚刚给出的订单号应该在本轮合并为新事实，售后政策文档应该作为引用来源，这两类信息不应该被平等对待。Context Mode 本质上要做的，是把"系统设定、外部资料、历史消息、当前提问"四类文本，按照明确的优先级组装进模型输入。

如果只是简单地把所有内容拼在一起，模型虽然都"看到了"，但它不知道谁是主角、谁是背景、谁已经过期。于是它在回答时就会随机挑一个视角。明白了这一点，后面所有工程手段都围绕同一个目标：让模型在每一轮生成前，拿到一份结构清晰、主次分明的上下文。

1.2 用"后厨备餐台"理解 Context Mode

这个概念不用讲得太玄。你可以把大模型想成一位后厨：

• 系统提示词是贴在他工位上的规矩，"本店不放香菜，出餐前检查订单号"；
• 文档资料是备菜台上的食材，有的是主菜原料，有的是摆设；
• 对话历史是前面做过的菜和顾客反馈，新订单来了要参考前面做了什么；
• 当前提问是刚进来的最新订单，后厨必须优先响应。

没有 Context Mode，后厨把所有食材、旧单据、新订单混在一起，时间长了必然抓瞎。有了这套模式，主厨才知道当前这份订单要优先用哪个冰箱的原料，哪些旧订单可以忽略，哪些规矩必须守住。每次向产品同事解释时用这个类比，对方基本立刻就能理解，后面聊预算和需求也顺畅得多。

1.3 三个经常被搞混的词

很多讨论里的错位，是因为没分清三个概念。这里我直接列一张表：

我见过不少团队在"上下文窗口不够用"上死磕，反复换更大窗口的模型，但效果依然差。因为他们真正缺的不是窗口大小，而是没有建立"什么信息值得进上下文、什么信息不值得进"的筛选机制。窗口大只是容量变大，并不等于里面的每句话都有效。

2. 落地 Context Mode 的两条路线：先提示词，再工程

2.1 提示词层面的显式 Context Mode

最早我用的方法很朴素：在系统提示词里明确告诉模型"你现在处于 Context Mode"。虽然听起来像玄学，但实测确实有效，原因在于模型在预训练阶段见过大量"指令 + 资料 + 问答"的文本结构，如果你给出像协议一样的声明，它更容易进入对应的工作状态。

我的模板长这样：

你现在处于 Context Mode。 1. 用户可能会粘贴长文本、代码、日志或对话记录，这些都属于需要分析的资料。 2. 收到资料后，先整理内部摘要，再结合用户的问题作答。 3. 如果资料中没有答案，直接说"资料中没有相关内容"，不要臆测。 4. 每轮回答都必须基于对话中已经出现的事实，尤其是用户主动提供的编号、日期、状态。

这套提示词解决了我前文说的"断片"问题，因为它明确告诉模型：用户刚给的订单号等于新证据，必须带到下一轮。但它也有明显局限：如果业务文档超过上下文窗口、或者历史对话特别长，光靠提示词撑不住。所以提示词是下限，工程方法才是上限。

2.2 工程层面：RAG 检索增强的上下文组装

当资料大到塞不进单次窗口时，必须走 RAG 路线。我一直把它理解为"给后厨装一个食材管理系统"：不需要把所有食材堆在案板上，而是根据订单去冷库取对应的那一份。

标准流程是：

1. 清洗文档，去掉页眉页脚、水印、无效符号；
2. 按章节或固定长度切块，通常每块 500~800 token，块与块之间保留 50~100 token 的重叠，防止关键信息被切断；
3. 把每个块做向量化，存入向量库；
4. 用户提问后，先做向量召回，取 TopK 个候选块；
5. 如果候选块太多，再加一层重排，用轻量模型或分数融合选出最相关的 3~5 块；
6. 最后把选中的块拼进上下文。第 5 步非常关键，我一开始跳过它，结果召回质量波动很大，加了一层重排之后输出明显稳定了。

RAG 属于 Context Mode 的"资料层"工程化，它解决的不是模型能力问题，而是"让模型真正读到该读的段落"。

2.3 对话太长：滑窗 + 摘要记忆

另一个容易翻车的地方是多轮对话。用户聊了 20 轮之后，前 5 轮的细节可能占了几千 token，如果全部保留，后面的上下文窗口放不下；如果粗暴丢弃，用户的关键信息又丢了。

我现在用的方案是"两层记忆"：

• 滑动窗口：只保留最近 N 轮完整消息，通常 N 取 5~8，保证近期意图不丢；
• 摘要记忆：把窗口之前的内容定期压缩成一段 200~300 token 的会话摘要，放在系统层。比如把"用户问过退换货流程，订单号 A12345，已确认 7 天内可退"提炼成结构化摘要，这样旧信息以高密度形式存活，又不占用太多窗口。

这个方案很像人做会议纪要：太久远的细节不记原话，但结论和关键数据写进纪要。我靠这套结构，把单次请求的 token 消耗稳定控制了近 40%，长对话的连贯性反而更好。

3. 手把手：5 步搭一个带 Context Mode 的问答助手

3.1 明确场景约束

先定义清楚需求。以我最近一个客服项目为例：

• 输入资料：一本 50 页的售后政策文档；
• 单次回答长度要求：不超过 300 字；
• 模型上下文窗口：8K token；
• 并发压力：中等，需控制单次请求成本。

这些约束决定了下游所有参数。很多人一上来就写代码，结果做到一半发现文档太长、预算超标，返工成本很高。我建议先花半小时把"资料量、窗口上限、回答长度、预算"四件事写清楚。

3.2 把静态文档拆成可检索片段

这一步决定了后面回答质量的底线。我采用"标题优先 + 固定长度兜底"的切块策略：

1. 优先按 Markdown 标题或 Word 大纲切分，让每个片段自带语义边界；
2. 遇到没有标题的长段落，按 600 token 切，重叠 100 token；
3. 切完后给每个片段记录来源页码和更新时间。

比如售后政策里"退货时限"和"退款方式"如果落进同一个块，会弱化各自的聚焦度；按标题切分后，检索"退款多久到账"时，召回器能精准定位到"退款方式"章节，而不是拿着整章文档去做模糊匹配。

3.3 组装"三层上下文"

确定检索到的片段之后，组装顺序很讲究。我用固定三层结构，顺序如下：

第1层：系统提示词（规则、输出格式、Context Mode 声明） 第2层：检索到的资料片段（带编号和来源） 第3层：最近的对话历史 + 当前问题

注意顺序不是随意排的。模型对开头的文本注意力权重更高，所以规则必须放最前面；资料放中间，作为证据区；最新问题放最后，让模型带着刚读完的资料直接生成回答。如果反过来，把历史对话放在资料前面，模型容易被聊天语气带偏，削弱对资料的引用。

3.4 触发条件与优先级规则

不是每个问题都需要检索，也不是每段资料都同等重要。我加了一层轻量判断逻辑，规则很简单：

• 问题超过 20 个字，或者包含"政策、流程、多久、多少、能否"等业务词，强制走检索；
• 用户提供了新的编号、日期、订单状态，优先更新"会话摘要记忆"，不进资料层；
• 资料片段之间冲突时，优先采用更新时间最新的片段，并在回答中注明来源。

这个优先级规则是"防断片"的关键。我最初踩的坑是把用户临时输入和静态资料混在一起，导致模型分不清哪句是刚发生的事实，哪句是旧文档内容。拆开之后，模型基本不会再用文档口径去否定用户刚说的话。

3.5 Token 与成本估算

落地前必须算清 token 账。我给出一个可以直接套用的估算公式：

单次请求总 Token ≈ 系统提示词 Token + 检索片段数 × 平均片段 Token + 历史窗口条数 × 平均历史 Token + 当前问题 Token

用一个真实数据算一遍：

• 系统提示词：约 350 token；
• 检索召回 4 个片段，每段平均 600 token：2400 token；
• 历史窗口保留 5 条对话，每条约 100 token：500 token；
• 当前问题：约 80 token；
• 合计：3330 token。

如果模型窗口是 8K，那么留给输出的余量是 8000 - 3330 = 4670 token，非常充裕。但如果你把召回片段提到 8 个、历史提到 20 条，总 token 会迅速涨到 7000 以上，不仅成本翻倍，还会把输出空间挤得很小。我自己的经验是：检索片段宁可少而准，不要多而杂，出了问题时优先砍片段数量，而不是盲目开更大的窗口。

3.6 固定输出格式 + 完整日志

最后一个容易被忽略但特别重要的步骤，是让模型以固定格式输出，同时把每次请求的上下文组成记进日志。我的输出格式强制要求包含两个字段：引用来源编号和结论置信度。

结论：<回答正文> 来源：[文档-03，第 12 页，更新时间 2025-06-01] 置信度：高/中/低

日志则记录：本轮用了哪几个片段、命中路径是什么、总 Token 用了多少、最终回答是什么。别小看这些日志，它是我排查问题最依赖的工具。模型回答不对时，第一件事不是调提示词，而是把日志打开，看看检索到底召回了什么。往往答案就在日志里：要么召回了过时版本，要么召回了完全不相关的章节。

4. 现场排障：Context Mode 最常见的 6 个翻车点

4.1 答非所问，先查检索到了什么

"它怎么答到外太空去了"是最常见的反馈。大多数时候问题不在模型，而在检索层。我排查的第一步永远是看日志里的片段列表，确认召回的片段跟问题是否真的相关。如果片段列表里混入了类似关键词但不相关的内容，就降低召回数量，或者加强重排环节；如果召回结果空荡荡，就检查切块大小和向量化方式。

4.2 资料自相矛盾，谁来裁决

文档大了以后必然出现版本冲突：有的章节说"退货 7 天内可申请"，另一个表格写"按批次最长 30 天"。模型遇到矛盾时会随机选一个或给出含糊回答。我的解法是在每个片段上记录更新时间，并在系统提示词里明确写"当资料冲突时，优先参考更新时间最新的片段，并如实说明存在版本差异"。至少保证模型不编造，面子上也说得过去。

4.3 上下文越长，回答越飘

有些开发者以为把资料全部塞进上下文就能提高准确率，结果发现问题越多，回答越飘。原因很简单：模型在注意力计算时会被大量无关 token 分散注意力，垃圾进、垃圾出。这是一个典型的"上下文窗口很大但有效信息密度低"的问题。我的经验是：强制限制资料层最多 4~6 个片段，宁可让模型说"资料中没有相关内容"，也不要给它一堆云里雾里的干扰项。

4.4 长对话开头被"遗忘"

长对话超过窗口后，如果粗暴滑窗，早期用户说过的重要信息会丢失。比如用户在第 2 轮报了订单号，第 18 轮再提退换货时，模型可能不知道这个订单号的存在。这就是我前面说的摘要记忆的用武之地：在滑窗前，把关键事实提炼成结构化摘要，固定放在系统层。相当于给模型一张"长期记忆卡"，即使原始对话已经被裁掉，结论还在。

4.5 成本像坐过山车

Context Mode 做得越复杂，每次请求拼进上下文的内容越多，成本越容易失控。我见过一个项目因为把整本手册每次都塞进系统提示词，单次调用成本直接翻了 5 倍。控制成本有三板斧：限制检索片段数量、限制历史窗口条数、对历史做摘要压缩。每个季度我还会拉一次 Token 使用报表，看哪些请求超出预期，再针对性调参。

4.6 格式飘忽不定，解析困难

模型偶尔会在该输出结构化格式时突然"自由发挥"，把来源编号写成一句话或者漏掉置信度，这会影响下游解析。解法是在系统提示词里放一两个固定示例，同时把输出格式要求从"请按格式输出"改成"只输出以下 JSON 结构，不要输出任何额外内容"。示例比任何描述都管用，这是我在实际调试中反复确认过的一句话。

4.7 翻车点速查表

最后把常见问题整理成一张速查表，方便你在现场快速定位：

5. 做 Context Mode 大半年，我最后想说的几句实话

把 Context Mode 从概念落到生产环境之后，我最大的体会是：它不是某个模型自带的魔法按钮，而是一套应用层策略。每次救场的不是更贵的模型，而是"让模型看到的东西更干净、更有序"这个朴素原则。我现在接到新需求，第一句话会先问产品："你说的上下文，到底指哪几个信息来源？"这个问题想清楚了，方案基本就成了一半。

也分享一个最近还在用的习惯：每次发布新版本前，我会把三组比较刁钻的测试问题跑一遍——一组考验长对话记忆，一组考验资料引用，一组考验新旧信息冲突。三组都过了，我才敢往线上推。这套方法让我的迭代回归成本低了很多，也不用每天盯着线上日志看用户吐槽。Context Mode 这条路上没有一劳永逸的捷径，但它值得你把每一步都做扎实。