企业官网建设流程全解析

那次演示翻车之后，我才认真去思考"记忆"这件事。当时我给内部团队搭了一个AI助手原型，演示环节有人连续追问了三个问题，结果助手把前一轮的结论完全抛在脑后，回答得牛头不对马嘴。场面一度很尴尬。

问题根子不在模型本身，而在于我压根没做上下文管理。大模型接口天生无状态，每次调用都是一张白纸，你传什么它看什么。想让助手"记得"用户刚才说了什么、正在看什么、手头有什么资料，必须自己造一套记忆系统。这个需求后来被我做成了项目代号为"context-mode"的功能模块，简单说就是让AI助手具备一种"上下文模式"：能感知当前对话所处的场景，把相关的历史信息、环境信息和用户意图一起送进模型，再输出回答。

这篇文章不是讲理论，是把我从设计到落地、再到上线后被真实用户按在地上摩擦的完整过程记录下来。内容包括上下文窗口怎么分配、记忆怎么分层、检索怎么避坑、延迟怎么压下来，以及最后我怎么搭了一套评测机制。适合正在做AI助手、智能客服、Copilot类应用，被"模型记不住事"折磨过的开发者参考。项目代号X也行、context-mode也好，思路是通用的。

1. 从"一问三忘"到context-mode：先搞清楚要治什么病

1.1 无状态AI的尴尬现场

先说个最典型的翻车场景。用户问："帮我看看这个模块的代码，感觉性能有问题。"助手回答了一大段优化建议。用户接着问："那第二点提到的方案，如果数据量翻一倍还能撑住吗？"——如果助手没有上下文，它根本不知道"第二点"是哪一点。

这类问题在纯问答场景里还能用"把整个对话历史拼进Prompt"来凑合。但如果对话很长，或者用户中途切换了话题，你塞进去的历史越多，模型越容易"串味"。更麻烦的是，真实产品里用户往往不只有对话，他可能正打开某个文件、正在调试某个报错、昨天刚配置过某个环境——这些"环境上下文"如果也能被助手感知，回答质量会提升一个量级。

context-mode要治的就是这个病：让AI助手在生成回答时，不仅仅依赖当前这一句话，还要参考"用户此刻在什么场景里、之前说过什么、手头有什么材料"。

1.2 上下文模式的本质：给AI装一个工作记忆

人跟人聊天时，彼此默认共享大量背景信息。你在帮同事看代码，对方递过来一行报错，你立刻知道这是哪个项目的哪段逻辑。AI助手要复现这种体验，需要三样东西：

• 会话上下文：本轮对话之前聊了什么，用户已经提供过的信息。
• 环境上下文：用户当前的操作场景，比如打开了哪个文件、正在执行什么命令、浏览的是哪个页面。
• 知识上下文：产品内置的资料库、历史工单、团队文档，回答问题时需要的参考资料。

context-mode做的就是把这三种上下文按需抓取、按优先级组装成一份"工作记忆"，在每次调用模型时注入。它跟"对话历史硬拼"最大的区别是：有选择、有结构、有优先级，而不是一股脑全塞进去。

1.3 适合做context-mode的场景清单

不是所有产品都需要这套东西，但下面几类场景做了之后收益非常直接：

我自己最先落地的是代码助手场景，后面又把同一套context-mode抽象出来接到了客服问答上。核心逻辑完全复用，差别只在上下文来源的采集方式。

2. 上下文来源、窗口分配与记忆衰减：设计阶段的三个关键抉择

设计阶段我纠结最久的是三个问题：上下文从哪来、塞多少进去、以及哪些记忆该被保留。这三个问题如果没想清楚，代码写得再漂亮也是白搭。

2.1 显式上下文与隐式上下文的取舍

上下文来源可以分成两类：

• 显式上下文：用户主动提供的信息，比如指定"只看这个目录下的代码""参考这份文档"。这类上下文可靠性高，因为用户明确授权了。
• 隐式上下文：系统从用户行为里自动推断的，比如检测到用户当前打开的文件、最近的键盘输入、正在浏览的页面。这类上下文不用用户额外操作，体验好，但容易抓错。

我的建议是：隐式上下文必须配合显式确认机制。比如代码助手检测到用户打开了A文件，但用户提的问题是关于B项目的，这时不能默认把A文件的内容塞进去，应该允许用户用"@文件路径"或"关注范围：xxx"的方式手动指定。

当时我踩过一个典型坑：助手检测到用户在看测试文件，自动把测试代码当作上下文注入，结果用户问的是生产环境的性能问题，回答里全是测试数据，反而误导了用户。后来我加了一条规则——隐式上下文只作为候选，必须经过相关性打分超过阈值才允许注入，否则宁可不注入。

2.2 窗口分配策略：不是越多越好

大模型输入端有个上下文窗口上限，即使窗口很大，也不代表塞满就好。原因有两个：

• 注意力稀释：上下文过长时，模型对关键信息的权重会下降，海量无关内容会干扰回答。
• 成本与延迟：处理的token越多，响应越慢、费用越高。

我当时用了一个非常朴素的分配策略，效果却很稳定：

这个分配不是拍脑袋，而是从一次内部评测得出的经验：当知识上下文的占比超过40%时，回答会开始偏离用户的问题，夹杂太多资料里的话术；当会话上下文超过30%时，模型会在历史里打转。30%左右是一个比较平衡的点。

2.3 记忆的优先级与衰减模型

不是所有历史对话都值得记住。用户昨天问过的问题、上周看过的文档，对今天的回答可能毫无帮助，甚至起反作用。

我给每条记忆设计了一个"新鲜度-重要性"二维打分，公式大概是：

记忆分 = 0.6 * 新鲜度分 + 0.4 * 重要性分 新鲜度分 = 1 / (1 + 距离当前时间的小时数) 重要性分 = 由事件类型决定（用户明确标记=1.0，问题被追问=0.8，普通问答=0.5，闲聊=0.2）

只要记忆分高于0.4的才进入候选用途，低于这个阈值直接丢弃。这个模型简单到有点粗暴，但它让我避开了"什么都想留、什么都往Prompt里塞"的陷阱。上线第一个月，因为记忆衰减过滤掉的无效上下文占了总候选量的60%以上，回答准确率反而提升了。

3. 记忆分层与上下文组装：让AI拥有"工作记忆"的骨架

3.1 短期记忆与长期记忆的分层

context-mode的记忆系统我分成了两层：

• 短期记忆：当前会话内的对话记录、临时状态，存内存数据库，TTL设为2小时。会话结束后可以清理，或者把有价值的摘要沉淀到长期记忆。
• 长期记忆：跨会话的信息，包括用户偏好、历史问题模式、业务知识片段，存向量数据库，按用户ID和业务场景维度做索引。

分层的核心原因是访问频率和生命周期完全不同。短期记忆读写频繁，要求低延迟；长期记忆查询频率低，但需要支持语义检索。混在一个存储里，两头都做不好。

3.2 上下文状态的流转逻辑

我设计了一个简单的状态机来管理上下文的切换：

• CONTEXT_NEW：新会话，没有历史上下文，无需加载。
• CONTEXT_ACTIVE：当前会话正在进行，加载短期记忆和当前环境上下文。
• CONTEXT_SWITCHING：检测到话题切换，旧上下文归档，新上下文初始化。
• CONTEXT_CLOSED：会话结束，短期记忆做摘要后写入长期记忆。

话题切换检测是这里最容易出问题的地方。我的做法是：每轮对话结束后，用当前问题与上一轮问题的向量相似度做判断。相似度低于0.4就认为发生了话题切换；在0.4到0.7之间时，保留上一轮的摘要但降低它的权重；高于0.7则完全是延续，原样保留。

3.3 上下文组装管线

组装过程我拆成了四个步骤，每一步都有明确产出：

1. 采集：从短期记忆、环境监控模块、知识库检索接口分别拉取原始数据。
2. 过滤：用前面提到的记忆分和相关度阈值，砍掉低价值内容。
3. 压缩：对超过预算的长文本做摘要。会话历史太长时，我采用"最近N条完整保留 + 更早部分分段摘要"的策略，而不是一刀切。
4. 拼接：按照固定模板把系统指令、用户问题、三类上下文拼成最终的Prompt。

这套管线最大的好处是每一层都可以单独调试。比如发现回答质量下降，可以先看是采集不到数据、过滤砍太狠，还是摘要压坏了关键信息。比起在最终Prompt里调来调去，定位问题快得多。

4. 动手实现：一个能跑的context-mode最小闭环

4.1 整体架构与模块划分

整个模块我拆成了五个部分，彼此尽量解耦：

数据流大概是：用户发起请求 → ContextCollector并行拉取会话、环境、知识三类数据 → ContextFilter打分过滤 → ContextCompressor对超预算内容压缩 → ContextAssembler按模板拼接 → 调用大模型API。整个过程在服务端完成，对用户无感。

4.2 核心代码骨架

核心的ContextAssembler我写得比较朴素，但够用：

class ContextAssembler: def __init__(self, budget_alloc): # budget_alloc: {"system": 0.05, "query": 0.10, # "session": 0.25, "env": 0.30, "knowledge": 0.30} self.budget_alloc = budget_alloc def assemble(self, user_query, session_ctx, env_ctx, knowledge_ctx, token_fn): total_budget = token_fn(user_query) / self.budget_alloc["query"] sessions = self._fit(session_ctx, total_budget * self.budget_alloc["session"]) envs = self._fit(env_ctx, total_budget * self.budget_alloc["env"]) knows = self._fit(knowledge_ctx, total_budget * self.budget_alloc["knowledge"]) return self._render_prompt(user_query, sessions, envs, knows)

_fit方法做的事情是先按相关度排序，然后从高到低往里塞，塞到预算上限为止。超预算的部分直接丢弃，不再额外处理，因为前面的过滤和压缩已经把质量把控住了，组装层只负责"装得下"。

这里有个细节容易忽略：token_fn不能简单用len(text)估算，中文字符和英文token的比例差异很大。我用的方案是按字符数估算，再乘以1.5的安全系数，宁少勿多，防止组装完发现超了窗口，又得回来砍。

4.3 接入大模型API的请求组装

最终发送给模型的Prompt长这样：

[系统指令] 你是一个具备上下文感知能力的助手。以下内容是按优先级排列的参考上下文。 [知识上下文] （检索到的资料，按相关度从高到低排列） [环境上下文] （用户当前正在处理的文件/页面信息） [会话上下文] （最近对话记录，最旧的在最上面） [用户问题] （当前这一轮的完整问题）

顺序不是随意的。知识上下文放在最前面，是因为它的信息量大、需要模型花更多注意力处理；会话上下文放在最后，是为了跟紧挨着的用户问题形成连贯；环境上下文居中，起到"场景锚点"的作用。这是我做了几轮对照实验得出的顺序，把知识上下文和会话上下文对调之后，测试集的回答准确率掉了大约7个百分点。

4.4 性能与成本控制

context-mode最大的开销不在逻辑本身，而在上下文采集和检索。如果每次请求都实时去拉数据、做向量检索、做摘要，延迟和成本都压不住。

我用三板斧解决：

• 采集并行化：会话、环境、知识三路采集同时发起，等最慢的那路返回再继续。原本串行耗时350毫秒，并行后压到120毫秒。
• 短期记忆走缓存：最近半小时内的会话上下文直接读内存缓存，不查数据库。这一项把会话上下文的平均采集时间从80毫秒降到15毫秒。
• 摘要结果做二级缓存：同一用户、同一话题的摘要缓存10分钟，避免每轮对话都重复压缩同样的长历史。

成本方面，加了context-mode之后单次请求的token消耗大约涨了40%，但这是值得的——因为回答准确率上去了，用户不再反复追问同一个问题，总请求量反而降了。实际算下来，单位有效回答的成本是下降的。

5. 上线后踩坑实录：上下文污染、检索偏差与延迟黑洞

功能上线前我信心满满，觉得设计已经很完善了。结果第一个月就被真实流量教育了三次，每次都是课堂上不会教的坑。

5.1 上下文污染：旧记忆干扰新任务

第一个坑是上线第三天发现的。用户在聊天里聊了几轮A项目的数据库优化，然后突然转去问B项目的接口设计。我的话题切换检测当时设的是相似度低于0.4就切换，但A项目聊得很深，积累了不少短期记忆，这些记忆即使权重降了，仍然被塞进了新话题的Prompt里。

结果助手回答B项目接口设计时，时不时冒出一句"这个表结构可以参考之前A项目的分库方案"。用户看得很懵。

修复方案分两步：一是话题切换时，旧会话的原始记录直接归档，只保留一条不超过200字的摘要作为"跨话题参考"，原始内容不再参与新话题的组装；二是给每条记忆打上话题标签，组装时优先匹配与当前问题话题标签一致的记忆。

5.2 检索偏差：相关知识检索不到的尴尬

第二个坑出在知识上下文检索上。我最初用的纯向量检索，按语义相似度召回。某些专业名词、简称、代码标识符，向量检索的效果很差——明明知识库里有答案，召回结果里却没有。

比如知识库里存了一条"SRE-告警-磁盘使用率超过80%时执行清理脚本"，用户问的是"磁盘快满了怎么办"，向量相似度居然不到0.3，这条资料压根没被召回来，助手只能空泛回答"建议检查磁盘空间，清理不必要文件"。

后来我把召回策略改成混合式：先做关键词召回，再做向量召回，两条路的结果合并后统一重排。关键词召回能抓住代码标识符、专业名词这种精确匹配；向量召回擅长处理口语化表达。两者合并后，知识上下文命中的准确率从62%提到89%。这中间花了两天时间调召回数量，最后定为每条路径各取Top 20，合并后按综合分取Top 10。

5.3 延迟黑洞：检索太慢拖垮整个响应

第三个坑是延迟。context-mode上线后，P95响应时间从原来的1.2秒涨到2.8秒，用户体感明显变差。排查下来，罪魁祸首是知识上下文的向量检索：每次请求实时查询向量库，查询本身只要30毫秒，但前面的文本向量化编码耗时400多毫秒。

关键是这400多毫秒里，很多是重复劳动——用户问的问题跟上一轮语义接近，向量化结果几乎一样。我的优化方案是：

• 对用户问题的向量化结果做缓存，key是"用户ID + 问题前32个字符"，命中率大约三成。
• 把知识检索改为异步预取：用户输入停顿超过1.5秒时，后台先按当前输入做一次粗检索，等用户真正发送时，结果已经在缓存里了。
• 给向量检索加了超时熔断：超过200毫秒没返回就直接走关键词召回结果，不阻塞主流程。

这三招叠加之后，P95响应时间回落到1.5秒，知识上下文的摄取对用户基本无感。

5.4 没有评测就谈不上优化

踩完这些坑之后我意识到一件重要的事：context-mode这种模块，每个人改一个参数都可能影响最终效果，但没有评测机制的话，你根本不知道改好还是改坏了。

我搭了一套轻量评测系统，核心是一个包含300条真实问题的测试集，每条问题都标了正确答案和期望引用的上下文。每次改动后跑一遍，记录三个指标：

• 回答准确率：输出与标准答案的语义相似度，用模型打分。
• 上下文命中率：期望引用的上下文是否真的出现在最终Prompt里。
• 响应延迟：P50和P95两条线都要记录。

没有这套评测，我后来做的几轮参数调优根本不敢动。有了它，每次改动到底有效还是负优化，跑一次就知道。

6. 实测数据与总结思考：context-mode到底值不值

6.1 上线三个月的实测数据

项目上线三个月，我对接了代码助手和智能客服两个场景，数据上有一些值得分享的变化：

准确率提升在意料之中，但"用户追问次数下降39%"这个数据最让我意外。追问减少意味着用户对第一轮回答的满意度提升了，这是比准确率更能反映真实体验的指标。代价是响应时间涨了0.3秒，token消耗涨了40%，但换来的是有效回答率的大幅提升，总体算下来是划算的。

6.2 context-mode在什么情况下可能不是好方案

我也要泼一盆冷水。如果你的产品满足下面任一条件，context-mode短期内不必上：

• 单轮问答为主：用户每次提问都是独立的、不含前后依赖，比如计算器、翻译工具。这种场景硬加上下文只会增加延迟和成本。
• 领域极窄且封闭：助手只处理固定格式的请求，比如表单校验、格式化输出，上下文图形同虚设。
• 上下文来源无法可靠获取：没有埋点、没有日志、拿不到用户当前环境的任何信号。这种情况下硬凑出来的上下文基本靠猜，还不如不做。

6.3 关于这件事我的几点体会

最后聊几句实践中积累的体会。

第一，context-mode的收益上限由上下文采集质量决定。模型能力再强，你喂给它的上下文是脏的、偏的、不新鲜的，它也只能在错误的信息上做推理。所以我把最多的精力花在采集和过滤上，组装反而最简单。

第二，别迷信复杂的记忆模型。我在设计时一度想把记忆做得非常精细，比如情感权重、话题图谱、时间衰减曲线。后来发现对大多数场景来说，新鲜度加重要性这两维就够用了。复杂度上去了，调试成本也跟着上去了，收益却很不明显。

第三，评测先行这句话，在context-mode这个项目上真的救了命。没有那300道题的测试集，我后续的每次调优都相当于盲人摸象。你如果也要做类似功能，我强烈建议先花时间建评测集，再动手调参。

第四，我想特别提醒一点：context-mode不改变模型本身的推理能力，它只是在恰当的时候把恰当的信息送到模型面前。设计时可以追求"让AI看起来记得住"，但别指望它能自主判断哪些信息重要、哪些不重要——那是你的工作。把上下文捡好、筛好、摆放好，剩下的交给模型。

如果你正在做类似的AI应用，我建议从最小闭环开始：先接一种上下文来源，跑通后再逐步加。别一上来就搞全套，否则你会同时面临采集不准、过滤误杀、组装超预算三个问题，根本分不清是哪个环节出了问题。