做了快两年AI应用开发我越来越确定一件事决定一个AI工具好用不好用的往往不是模型选得有多新而是你往模型里塞的上下文有多准。大模型本身没有记忆每次调用都得把背景信息带上去可哪些信息该带、哪些该丢、按什么顺序排就成了一个容易被忽略但影响极大的工程问题。context-mode也就是上下文模式就是为解决这个问题而生的设计思路。它不是某个开源库的名字而是一类做法把上下文的选择、组装、切换做成显式、可配置、可观测的模式而不是在代码里硬编码一套固定逻辑。只要你正在做AI辅助编程、智能客服、文档问答、个人知识库这类应用或者你只是想给自己写的AI小工具加点“记忆力”这篇文章都值得看完。我会把设计思路、数据模型、核心实现、参数推导和实测踩坑一次讲清楚。1. 内容整体设计与思路拆解1.1 为什么需要 context-mode先讲一个我在实际项目里遇到的场景。我们做一个面向研发团队的代码问答助手第一版特别简单把用户的问题和整个仓库的文件列表往模型里一塞让它回答。结果可想而知token消耗大得惊人一次请求经常要付几万token的钱回答质量却很糟糕。模型被大量无关代码淹没反而抓不住真正相关的那几个文件。这里的问题不是模型不行而是上下文的选择策略不行。大模型的注意力虽然强但也是有上限的信息越多关键信号被稀释得越厉害。就像让一个专家在堆满杂物的房间里找一份合同他能找到但速度慢、容易分心。如果在进门之前就先递给他一份“这个房间里跟合同相关的物品清单”效率完全不一样。context-mode就是这份清单的生产系统。它的核心任务是回答三个问题这次请求需要携带哪些上下文这些上下文按什么优先级组织当上下文超过模型窗口时先牺牲谁把这三个问题固化成不同的模式就能适应不同场景。比如代码问答需要“当前文件相关引用项目结构”客服机器人需要“用户历史订单FAQ会话摘要”个人知识库需要“检索到的Top-K文档片段”。如果只用一种策略去应对所有场景一定会有人觉得它又慢又笨。1.2 方案选型上下文模式的三个核心维度设计上下文模式之前我建议先想清楚三个维度因为几乎所有模式都可以拆成这三个维度的组合。时间维度上下文是单轮的、多轮的还是跨会话的单轮模式只携带当前问题相关的最新信息适合一次性问答多轮模式会带上历史对话的摘要适合需要持续交互的场景跨会话模式则要引入长期记忆比如用户偏好、历史偏好声明甚至上周问过但没解决的问题。空间维度上下文来自哪个物理范围在代码工具里是当前文件、相关文件、整个模块还是整个仓库在客服场景里是当前工单、用户历史会话、全量用户信息还是产品文档。这个维度决定了采集器需要访问多少数据源。语义维度上下文是直接相关的还是间接相关的直接相关可以通过关键词匹配、路径匹配拿到间接相关往往要靠向量检索、知识图谱甚至模型自身去挖掘。语义维度决定了检索策略和排序策略的复杂度。我建议把这三个维度当成坐标系给每个候选模式打点。比如模式时间维度空间维度语义维度典型场景聚焦模式单轮当前文件关键词解释选中代码推理模式多轮相关文件链向量召回跨文件排查Bug全局模式跨会话整个项目记忆图谱向量新需求方案设计这样做的好处是当你要给产品加新模式时不用从零设计而是先在坐标系里找到空缺位置再补对应的采集器和排序策略。1.3 模式划分的原则与边界模式不是越多越好我见过把上下文模式做成七八个选项的产品用户根本不知道怎么选最后全用默认模式。模式划分要遵循几个原则。第一每个模式必须有清晰语义用户看到名字就能猜到它干什么。compact就是更省tokenbalanced就是兼顾质量与成本full就是尽量带全信息这种命名比mode1、mode2强一百倍。第二模式之间应该可以降级。不能说用户选了full模式结果上下文超长就只能报错而应该设计一条降级链full超限降级到balancedbalanced超限降级到compact。用户的可预期性比绝对能力更重要。第三模式必须能被观测。每次请求是哪个模式、用了多少token、哪些上下文因为超限被丢掉这些都要有日志。否则用户反馈“回答变差了”你连复盘的抓手都没有。第四模式要支持用户手动覆盖。自动检测再聪明也会有判断错的时候给用户一个强制切换的开关比任何智能优化都能提升信任感。后面我会单独讲自动切换的坑。2. 核心细节解析与实操要点2.1 上下文数据模型别只存字符串很多新手第一次实现context-mode时会用一个字符串把所有拼接好然后直接塞给模型。短期能跑但很快就发现问题不知道每段内容来自哪里不知道哪段内容让模型产生了幻觉不知道缓存如何失效。所以第一件事就是把上下文建模成结构化对象。我在项目里用的是这样的数据模型from dataclasses import dataclass, field from typing import Any dataclass class ContextItem: source: str # 来源标识如 file://src/main.py#L42 content: str # 文本片段 score: float # 当前模式下的相关度 token_count: int # 预估token数 metadata: dict[str, Any] field(default_factorydict) # 语言、修改时间、权限等 dataclass class ContextBundle: mode: str # 当前上下文模式 query: str # 用户输入或任务目标 items: list[ContextItem] # 实际注入的上下文列表 total_tokens: int # 累计token数 truncated: list[str] # 被裁剪掉的source列表 created_at: float # 构建时间为什么一定要带source和truncated因为后面排错几乎全靠它们。比如模型回答了一个不存在的函数名你翻日志就能看到这个函数名来自哪个文件被裁剪掉的source有记录你就能判断裁剪策略是否太激进。token_count也很关键。不要到调用模型前才估算token那样你没法做分层裁剪。我习惯在采集阶段就估算虽然不可能百分百准但可以用 OpenAI 的 tiktoken 或本地 Tokenizer 做预切分误差控制在10%以内足够用了。2.2 上下文来源采集从哪里拿怎么拿上下文来源五花八门但采集方式有共性。以代码辅助工具为例我常用的采集器有五种。当前活动文件采集器读取编辑器光标所在文件内容再加上光标附近的展开区域。这个最常见也最容易实现。最近编辑文件采集器维护一个按修改时间排序的文件列表取前N个。它能捕捉用户刚刚改过但没保存到当前文件的关联信息。结构化信息采集器读取项目里的依赖清单、配置文件、目录结构让模型知道这个项目的技术栈和组织方式。比如用户问“这个项目怎么跑起来”模型需要知道package.json里的脚本和Python版本。语义检索采集器把用户问题向量化在项目文件的知识库中做相似度检索。这是full模式和balanced模式的主要区别点检索质量直接决定回答上限。用户手动挂载采集器允许用户手动pin一个文件或一段文本作为“必带上下文”。它的权重应该是最高的因为用户显式指定的信息一定是最重要的。采集阶段要注意去重。同一个文件可能同时被“当前活动文件”和“语义检索”命中如果不去重上下文里会出现两遍相同内容既浪费token又干扰模型。我常用的去重键是source 内容哈希简单有效。2.3 权重打分与裁剪策略决定谁进窗口采集到的候选上下文可能非常多但模型窗口有限所以必须有打分和裁剪机制。打分的目的是给所有候选上下文排一个优先级裁剪的目的是在token预算内留下优先级最高的那些。我用的打分公式是加权求和score 0.25 * lexical_similarity 0.15 * recency_score 0.30 * semantic_similarity 0.20 * explicit_weight 0.10 * structural_importancelexical_similarity是关键词覆盖率拿用户问题里的关键词去匹配上下文文本简单粗暴recency_score是时间衰减因子比如最近10分钟内的文件记1分之后按指数衰减semantic_similarity是向量相似度由向量检索给出explicit_weight是用户手动置顶或历史偏好记录的加分structural_importance是结构权重比如入口文件、核心类定义比随机配置文件重要。权重不是拍脑袋定的我建议先手动标注一批典型问题然后用网格搜索调参。不要追求理论最优够用就好。比如我调过一轮后发现代码问答场景里 structural_importance 太高会把项目入口文件反复带进来反而压低了真正的答案文件优先级后来把它的权重从0.2降到0.1。裁剪分两层。第一层是硬裁剪按token预算从高到低依次保留直到预算用尽。第二层是软裁剪如果某个上下文片段非常大比如一个几千行的文件我会先截取其关键部分而不是整段丢弃。比如只取光标所在函数、类的定义区以及顶部注释区而不是整个文件。2.4 模式切换与用户感知别让用户陷入黑盒context-mode最容易翻车的地方就是自动切换。刚开始我觉得全自动最聪明根据用户当前行为自动匹配模式结果用户完全不知道该模式下发生了什么。有人问“为什么刚才回答很快现在很慢”有人问“为什么这个文件你没看到”。问题不在判断逻辑而在用户感知缺失。我的做法是把模式名、当前token用量、上下文来源列表直接暴露给用户。界面里不用放技术词汇展示“当前模式聚焦”“已使用上下文量3.2k/8k”“已载入文件3个”就好。用户一看就知道发生了什么。自动切换的触发信号我用三类行为信号鼠标/光标停留时间、最近打开文件、复制粘贴行为查询信号问题长度、关键词类型、是否包含文件名环境信号当前窗口大小、项目规模、模型服务端的可用上下文窗口切换时要柔和。不要突然从紧凑模式跳到全局模式让用户莫名其妙。我后来加了一条规则只有用户问题中包含文件名或明显跨文件意图时才自动从聚焦模式升级到推理模式否则保持当前模式不变。多数误判问题都被这条规则挡掉了。3. 实操过程与核心环节实现3.1 最小闭环一个可用的 context-mode 引擎理论讲再多不如看一段能跑起来的代码。下面是一个简化版引擎核心流程是根据模式找到采集器、采集候选、打分排序、按token预算裁剪、组装成上下文。import time class ContextModeEngine: def __init__(self, mode_configs, token_budget8192): self.mode_configs mode_configs self.token_budget token_budget def collect_candidates(self, mode, signal): collector_configs self.mode_configs[mode][collectors] candidates [] for conf in collector_configs: collector conf[collector] items collector(signal) candidates.extend(items) return candidates def score_candidates(self, candidates, query, mode, user_explicit): scored [] for item in candidates: score self._compute_score(item, query, mode, user_explicit) scored.append((score, item)) scored.sort(keylambda x: x[0], reverseTrue) return scored def truncate(self, scored, budget): kept [] truncated_sources [] used 0 for score, item in scored: if used item.token_count budget: kept.append(item) used item.token_count else: truncated_sources.append(item.source) return kept, truncated_sources def build(self, mode, query, signal, user_explicitNone): candidates self.collect_candidates(mode, signal) scored self.score_candidates(candidates, query, mode, user_explicit or {}) kept, truncated self.truncate(scored, self.token_budget) bundle ContextBundle( modemode, queryquery, itemskept, total_tokenssum(x.token_count for x in kept), truncatedtruncated, created_attime.time(), ) return bundle这个引擎做了基本的职责分离。如果你想加新模式只需在模式配置里指定新的采集器组合复用打分和裁剪逻辑不需要改动主流程。这也是context-mode设计的核心价值上下文策略可插拔而不是所有逻辑都堆在AI调用函数里。注意我在这里没有写_compute_score的具体实现因为它是纯函数你完全可以根据自己的场景替换。我在2.3节给出的权重公式可以直接落地只要把它翻译成代码即可。3.2 关键参数怎么定token预算的推导过程token预算是最容易拍脑袋的参数但拍错了代价很大。预算太高请求慢、费用高预算太低模型缺信息、回答差。我建议按以下步骤推导而不是直接设一个固定的“8192”。可用窗口 模型上下文窗口例如 128k 输出预留 模型回答的最大长度例如 4k 系统提示与示例 固定开销例如 2k 安全余量 总窗口的 20%应对超长输出和token估算误差 上下文预算 可用窗口 - 输出预留 - 系统提示与示例 - 安全余量 128k - 4k - 2k - 25.6k 96.4k但这里有一个容易被忽略的问题很多模型在长上下文下质量会下降不是因为窗口不够而是因为注意力分散。所以我实际上线时会把计算出的预算再乘一个经验系数常见的是0.5到0.75。上面的例子折中取0.75最终上下文预算约72k再按模式区分从聚焦模式的8k到全局模式的72k分三档。另外token估算误差不可忽略。tiktoken估算比较准但中文和代码的误差率不同。保险起见我在代码里统一把估算结果向上取整5%并在裁剪逻辑中留下最后200 token的缓冲。这样即使有小规模乱码或换行差异也不会导致最终拼接后超过实际上下文窗口。3.3 接入大模型接口的结构化封装上下文拼接不是简单把字符串加起来。如果不做结构化封装模型可能会把上下文当成用户指令的一部分导致它把文件内容里的注释误认成命令。我在所有上下文片段外面套上显式的标记让模型明确知道这块是参考资料。你是智能助手。以下是本次任务需要用到的上下文资料全部标记在context标签内。 context file pathsrc/main.py languagepython ...代码片段... /file file pathsrc/utils.py languagepython ...代码片段... /file /context 请根据上述上下文回答用户问题。如果上下文不足请明确说明。 user_query {query} /user_query这里有三点经验。第一source信息必须透传给模型。模型看到file pathsrc/utils.py后回答时会自然使用“utils.py里实现了xxx”这种表达幻觉率明显降低。第二系统提示里的语气要中性。不要用“必须严格按照上下文回答”否则模型会变得过于保守明明能推理出答案也不敢答。我试过几种措辞效果最好的是“请优先引用上下文信息若缺失则说明”。第三调用模型前再检查一次拼接结果。把整个prompt打出来人工扫一眼是否有残缺标签、重复片段、乱码。这一步看起来原始但能拦住大多数线上事故。4. 常见问题与排查技巧实录4.1 上下文超长被硬截断我遇到过最频繁的问题是上下文超长。表象是模型API直接报错或者回答到一半被截断。排查时要先区分是请求前截断还是请求中截断。请求前截断通常是token估算不准特别是代码文件里的中文注释和长字符串会低估。我把估算逻辑从“按字符数乘系数”改成“按内容类型区分”代码部分用tokenizer精确切分注释部分按中文特有字符密集度加权问题才缓解。请求中截断往往是因为动态输出太长。解决方法是预留输出空间并设置max_tokens同时开启流式输出。如果遇到模型在长回答中途截断可以把它设计成先给结论再给详情的格式这样截断时至少拿到了核心答案。4.2 上下文过时导致答非所问项目文件一直在变如果上下文缓存没有及时失效模型会拿着旧代码回答问题。用户问“我刚改的函数为什么没生效”模型根据旧代码解释了五分钟越解释越错。我的解决办法是给每个文件建立内容哈希采集器返回上下文时附带哈希值。引擎比较哈希与缓存版本不一致就直接重新采集而不是复用缓存。对于特别大的项目还可以用文件系统事件监听器比如watchdog在文件保存后几秒内主动失效该文件的缓存。另外用户手动置顶的上下文也要有过期概念。不能因为用户昨天pin了一个文件今天就一直带着。我在显式上下文上加了时间戳超过设定时限后自动降权用户也能看到“该文件已被置顶超过30分钟”的提示。4.3 自动模式误判与用户冲突自动模式误判最经典的场景有两种。一种是用户明明在看前端页面却在聊天框问后端接口设计自动聚焦模式只带了前端文件答案自然不对。另一种是用户问“这个项目有几个模块”自动模式判断为聚焦模式结果只带了当前目录结构缺失全局信息。我处理误判的方式是“先降级提醒再升级”。也就是说当模型回答置信度低或者检测到当前模式上下文里没有用户问题中的关键词时不是立刻切换模式而是追加一条提醒“当前模式下可能缺少项目全局信息建议切换到推理模式或全局模式”。把主动权交给用户。还有一个容易被忽略的问题用户手动切换的模式与自动模式冲突。如果用户手动切到聚焦模式而我后台又自动升级到推理模式用户会觉得系统在跟他对着干。后来我定了规则用户手动选择优先自动切换只在用户未手动指定时才生效且自动切换后必须留下可恢复入口。4.4 实测数据与避坑经验最后分享一组我自己项目里的前后对比。最早只有全量模式时平均每次请求消耗约2.3万tokenP95延迟6.8秒用户对“回答太慢”的抱怨很多。改成聚焦/推理/全局三档后默认模式设为聚焦平均消耗降到8千token左右P95延迟降到3.1秒回答准确率主观评价提高了约15%。这个结果说明问题了吗说明降低上下文量并不一定降低质量反而因为信息更聚焦而提升了效果。但也带来一个新问题聚焦模式下用户问跨文件问题时模型经常回答“缺少上下文”。所以我又加了“检测到跨文件意图时自动升级为推理模式”的规则通过问题里的文件名、模块名关键词触发。避坑经验有几条不要追求模式数量先做两档紧凑和完整上线一周后再看日志决定是否加第三档。每次请求的上下文日志必须留包含模式名、source列表、token用量、裁剪源。没有日志优化就是盲人摸象。权重参数可以从一个基准配置开始但一定要设计成配置文件而不是硬编码这样在不同项目间切换时不用改代码。测试用例要包含“上下文不足”场景。直接问模型“信息不够时你会怎么说”确保它在缺失信息时不胡编。我个人在实际操作中的体会是context-mode最值钱的不是那一堆代码而是你对“哪些上下文真正有用”的判断。判断来自日志、来自失误、来自一次次的对比实验。如果你准备给自己的AI工具加这个能力先花一周时间记录用户真实提问把每个问题“应该带哪些文件”都标出来再回头设计模式会顺利得多。最后再分享一个小技巧把模式切换的快捷键放在用户最容易按到的地方用户越容易控制上下文模式就越信任你的AI工具。 
长河君 · 2026/10/29 8:55:36 · 阅读 1.2k AI应用开发中的上下文模式：大模型有效记忆的关键设计
做了快两年AI应用开发我越来越确定一件事决定一个AI工具好用不好用的往往不是模型选得有多新而是你往模型里塞的上下文有多准。大模型本身没有记忆每次调用都得把背景信息带上去可哪些信息该带、哪些该丢、按什么顺序排就成了一个容易被忽略但影响极大的工程问题。context-mode也就是上下文模式就是为解决这个问题而生的设计思路。它不是某个开源库的名字而是一类做法把上下文的选择、组装、切换做成显式、可配置、可观测的模式而不是在代码里硬编码一套固定逻辑。只要你正在做AI辅助编程、智能客服、文档问答、个人知识库这类应用或者你只是想给自己写的AI小工具加点“记忆力”这篇文章都值得看完。我会把设计思路、数据模型、核心实现、参数推导和实测踩坑一次讲清楚。1. 内容整体设计与思路拆解1.1 为什么需要 context-mode先讲一个我在实际项目里遇到的场景。我们做一个面向研发团队的代码问答助手第一版特别简单把用户的问题和整个仓库的文件列表往模型里一塞让它回答。结果可想而知token消耗大得惊人一次请求经常要付几万token的钱回答质量却很糟糕。模型被大量无关代码淹没反而抓不住真正相关的那几个文件。这里的问题不是模型不行而是上下文的选择策略不行。大模型的注意力虽然强但也是有上限的信息越多关键信号被稀释得越厉害。就像让一个专家在堆满杂物的房间里找一份合同他能找到但速度慢、容易分心。如果在进门之前就先递给他一份“这个房间里跟合同相关的物品清单”效率完全不一样。context-mode就是这份清单的生产系统。它的核心任务是回答三个问题这次请求需要携带哪些上下文这些上下文按什么优先级组织当上下文超过模型窗口时先牺牲谁把这三个问题固化成不同的模式就能适应不同场景。比如代码问答需要“当前文件相关引用项目结构”客服机器人需要“用户历史订单FAQ会话摘要”个人知识库需要“检索到的Top-K文档片段”。如果只用一种策略去应对所有场景一定会有人觉得它又慢又笨。1.2 方案选型上下文模式的三个核心维度设计上下文模式之前我建议先想清楚三个维度因为几乎所有模式都可以拆成这三个维度的组合。时间维度上下文是单轮的、多轮的还是跨会话的单轮模式只携带当前问题相关的最新信息适合一次性问答多轮模式会带上历史对话的摘要适合需要持续交互的场景跨会话模式则要引入长期记忆比如用户偏好、历史偏好声明甚至上周问过但没解决的问题。空间维度上下文来自哪个物理范围在代码工具里是当前文件、相关文件、整个模块还是整个仓库在客服场景里是当前工单、用户历史会话、全量用户信息还是产品文档。这个维度决定了采集器需要访问多少数据源。语义维度上下文是直接相关的还是间接相关的直接相关可以通过关键词匹配、路径匹配拿到间接相关往往要靠向量检索、知识图谱甚至模型自身去挖掘。语义维度决定了检索策略和排序策略的复杂度。我建议把这三个维度当成坐标系给每个候选模式打点。比如模式时间维度空间维度语义维度典型场景聚焦模式单轮当前文件关键词解释选中代码推理模式多轮相关文件链向量召回跨文件排查Bug全局模式跨会话整个项目记忆图谱向量新需求方案设计这样做的好处是当你要给产品加新模式时不用从零设计而是先在坐标系里找到空缺位置再补对应的采集器和排序策略。1.3 模式划分的原则与边界模式不是越多越好我见过把上下文模式做成七八个选项的产品用户根本不知道怎么选最后全用默认模式。模式划分要遵循几个原则。第一每个模式必须有清晰语义用户看到名字就能猜到它干什么。compact就是更省tokenbalanced就是兼顾质量与成本full就是尽量带全信息这种命名比mode1、mode2强一百倍。第二模式之间应该可以降级。不能说用户选了full模式结果上下文超长就只能报错而应该设计一条降级链full超限降级到balancedbalanced超限降级到compact。用户的可预期性比绝对能力更重要。第三模式必须能被观测。每次请求是哪个模式、用了多少token、哪些上下文因为超限被丢掉这些都要有日志。否则用户反馈“回答变差了”你连复盘的抓手都没有。第四模式要支持用户手动覆盖。自动检测再聪明也会有判断错的时候给用户一个强制切换的开关比任何智能优化都能提升信任感。后面我会单独讲自动切换的坑。2. 核心细节解析与实操要点2.1 上下文数据模型别只存字符串很多新手第一次实现context-mode时会用一个字符串把所有拼接好然后直接塞给模型。短期能跑但很快就发现问题不知道每段内容来自哪里不知道哪段内容让模型产生了幻觉不知道缓存如何失效。所以第一件事就是把上下文建模成结构化对象。我在项目里用的是这样的数据模型from dataclasses import dataclass, field from typing import Any dataclass class ContextItem: source: str # 来源标识如 file://src/main.py#L42 content: str # 文本片段 score: float # 当前模式下的相关度 token_count: int # 预估token数 metadata: dict[str, Any] field(default_factorydict) # 语言、修改时间、权限等 dataclass class ContextBundle: mode: str # 当前上下文模式 query: str # 用户输入或任务目标 items: list[ContextItem] # 实际注入的上下文列表 total_tokens: int # 累计token数 truncated: list[str] # 被裁剪掉的source列表 created_at: float # 构建时间为什么一定要带source和truncated因为后面排错几乎全靠它们。比如模型回答了一个不存在的函数名你翻日志就能看到这个函数名来自哪个文件被裁剪掉的source有记录你就能判断裁剪策略是否太激进。token_count也很关键。不要到调用模型前才估算token那样你没法做分层裁剪。我习惯在采集阶段就估算虽然不可能百分百准但可以用 OpenAI 的 tiktoken 或本地 Tokenizer 做预切分误差控制在10%以内足够用了。2.2 上下文来源采集从哪里拿怎么拿上下文来源五花八门但采集方式有共性。以代码辅助工具为例我常用的采集器有五种。当前活动文件采集器读取编辑器光标所在文件内容再加上光标附近的展开区域。这个最常见也最容易实现。最近编辑文件采集器维护一个按修改时间排序的文件列表取前N个。它能捕捉用户刚刚改过但没保存到当前文件的关联信息。结构化信息采集器读取项目里的依赖清单、配置文件、目录结构让模型知道这个项目的技术栈和组织方式。比如用户问“这个项目怎么跑起来”模型需要知道package.json里的脚本和Python版本。语义检索采集器把用户问题向量化在项目文件的知识库中做相似度检索。这是full模式和balanced模式的主要区别点检索质量直接决定回答上限。用户手动挂载采集器允许用户手动pin一个文件或一段文本作为“必带上下文”。它的权重应该是最高的因为用户显式指定的信息一定是最重要的。采集阶段要注意去重。同一个文件可能同时被“当前活动文件”和“语义检索”命中如果不去重上下文里会出现两遍相同内容既浪费token又干扰模型。我常用的去重键是source 内容哈希简单有效。2.3 权重打分与裁剪策略决定谁进窗口采集到的候选上下文可能非常多但模型窗口有限所以必须有打分和裁剪机制。打分的目的是给所有候选上下文排一个优先级裁剪的目的是在token预算内留下优先级最高的那些。我用的打分公式是加权求和score 0.25 * lexical_similarity 0.15 * recency_score 0.30 * semantic_similarity 0.20 * explicit_weight 0.10 * structural_importancelexical_similarity是关键词覆盖率拿用户问题里的关键词去匹配上下文文本简单粗暴recency_score是时间衰减因子比如最近10分钟内的文件记1分之后按指数衰减semantic_similarity是向量相似度由向量检索给出explicit_weight是用户手动置顶或历史偏好记录的加分structural_importance是结构权重比如入口文件、核心类定义比随机配置文件重要。权重不是拍脑袋定的我建议先手动标注一批典型问题然后用网格搜索调参。不要追求理论最优够用就好。比如我调过一轮后发现代码问答场景里 structural_importance 太高会把项目入口文件反复带进来反而压低了真正的答案文件优先级后来把它的权重从0.2降到0.1。裁剪分两层。第一层是硬裁剪按token预算从高到低依次保留直到预算用尽。第二层是软裁剪如果某个上下文片段非常大比如一个几千行的文件我会先截取其关键部分而不是整段丢弃。比如只取光标所在函数、类的定义区以及顶部注释区而不是整个文件。2.4 模式切换与用户感知别让用户陷入黑盒context-mode最容易翻车的地方就是自动切换。刚开始我觉得全自动最聪明根据用户当前行为自动匹配模式结果用户完全不知道该模式下发生了什么。有人问“为什么刚才回答很快现在很慢”有人问“为什么这个文件你没看到”。问题不在判断逻辑而在用户感知缺失。我的做法是把模式名、当前token用量、上下文来源列表直接暴露给用户。界面里不用放技术词汇展示“当前模式聚焦”“已使用上下文量3.2k/8k”“已载入文件3个”就好。用户一看就知道发生了什么。自动切换的触发信号我用三类行为信号鼠标/光标停留时间、最近打开文件、复制粘贴行为查询信号问题长度、关键词类型、是否包含文件名环境信号当前窗口大小、项目规模、模型服务端的可用上下文窗口切换时要柔和。不要突然从紧凑模式跳到全局模式让用户莫名其妙。我后来加了一条规则只有用户问题中包含文件名或明显跨文件意图时才自动从聚焦模式升级到推理模式否则保持当前模式不变。多数误判问题都被这条规则挡掉了。3. 实操过程与核心环节实现3.1 最小闭环一个可用的 context-mode 引擎理论讲再多不如看一段能跑起来的代码。下面是一个简化版引擎核心流程是根据模式找到采集器、采集候选、打分排序、按token预算裁剪、组装成上下文。import time class ContextModeEngine: def __init__(self, mode_configs, token_budget8192): self.mode_configs mode_configs self.token_budget token_budget def collect_candidates(self, mode, signal): collector_configs self.mode_configs[mode][collectors] candidates [] for conf in collector_configs: collector conf[collector] items collector(signal) candidates.extend(items) return candidates def score_candidates(self, candidates, query, mode, user_explicit): scored [] for item in candidates: score self._compute_score(item, query, mode, user_explicit) scored.append((score, item)) scored.sort(keylambda x: x[0], reverseTrue) return scored def truncate(self, scored, budget): kept [] truncated_sources [] used 0 for score, item in scored: if used item.token_count budget: kept.append(item) used item.token_count else: truncated_sources.append(item.source) return kept, truncated_sources def build(self, mode, query, signal, user_explicitNone): candidates self.collect_candidates(mode, signal) scored self.score_candidates(candidates, query, mode, user_explicit or {}) kept, truncated self.truncate(scored, self.token_budget) bundle ContextBundle( modemode, queryquery, itemskept, total_tokenssum(x.token_count for x in kept), truncatedtruncated, created_attime.time(), ) return bundle这个引擎做了基本的职责分离。如果你想加新模式只需在模式配置里指定新的采集器组合复用打分和裁剪逻辑不需要改动主流程。这也是context-mode设计的核心价值上下文策略可插拔而不是所有逻辑都堆在AI调用函数里。注意我在这里没有写_compute_score的具体实现因为它是纯函数你完全可以根据自己的场景替换。我在2.3节给出的权重公式可以直接落地只要把它翻译成代码即可。3.2 关键参数怎么定token预算的推导过程token预算是最容易拍脑袋的参数但拍错了代价很大。预算太高请求慢、费用高预算太低模型缺信息、回答差。我建议按以下步骤推导而不是直接设一个固定的“8192”。可用窗口 模型上下文窗口例如 128k 输出预留 模型回答的最大长度例如 4k 系统提示与示例 固定开销例如 2k 安全余量 总窗口的 20%应对超长输出和token估算误差 上下文预算 可用窗口 - 输出预留 - 系统提示与示例 - 安全余量 128k - 4k - 2k - 25.6k 96.4k但这里有一个容易被忽略的问题很多模型在长上下文下质量会下降不是因为窗口不够而是因为注意力分散。所以我实际上线时会把计算出的预算再乘一个经验系数常见的是0.5到0.75。上面的例子折中取0.75最终上下文预算约72k再按模式区分从聚焦模式的8k到全局模式的72k分三档。另外token估算误差不可忽略。tiktoken估算比较准但中文和代码的误差率不同。保险起见我在代码里统一把估算结果向上取整5%并在裁剪逻辑中留下最后200 token的缓冲。这样即使有小规模乱码或换行差异也不会导致最终拼接后超过实际上下文窗口。3.3 接入大模型接口的结构化封装上下文拼接不是简单把字符串加起来。如果不做结构化封装模型可能会把上下文当成用户指令的一部分导致它把文件内容里的注释误认成命令。我在所有上下文片段外面套上显式的标记让模型明确知道这块是参考资料。你是智能助手。以下是本次任务需要用到的上下文资料全部标记在context标签内。 context file pathsrc/main.py languagepython ...代码片段... /file file pathsrc/utils.py languagepython ...代码片段... /file /context 请根据上述上下文回答用户问题。如果上下文不足请明确说明。 user_query {query} /user_query这里有三点经验。第一source信息必须透传给模型。模型看到file pathsrc/utils.py后回答时会自然使用“utils.py里实现了xxx”这种表达幻觉率明显降低。第二系统提示里的语气要中性。不要用“必须严格按照上下文回答”否则模型会变得过于保守明明能推理出答案也不敢答。我试过几种措辞效果最好的是“请优先引用上下文信息若缺失则说明”。第三调用模型前再检查一次拼接结果。把整个prompt打出来人工扫一眼是否有残缺标签、重复片段、乱码。这一步看起来原始但能拦住大多数线上事故。4. 常见问题与排查技巧实录4.1 上下文超长被硬截断我遇到过最频繁的问题是上下文超长。表象是模型API直接报错或者回答到一半被截断。排查时要先区分是请求前截断还是请求中截断。请求前截断通常是token估算不准特别是代码文件里的中文注释和长字符串会低估。我把估算逻辑从“按字符数乘系数”改成“按内容类型区分”代码部分用tokenizer精确切分注释部分按中文特有字符密集度加权问题才缓解。请求中截断往往是因为动态输出太长。解决方法是预留输出空间并设置max_tokens同时开启流式输出。如果遇到模型在长回答中途截断可以把它设计成先给结论再给详情的格式这样截断时至少拿到了核心答案。4.2 上下文过时导致答非所问项目文件一直在变如果上下文缓存没有及时失效模型会拿着旧代码回答问题。用户问“我刚改的函数为什么没生效”模型根据旧代码解释了五分钟越解释越错。我的解决办法是给每个文件建立内容哈希采集器返回上下文时附带哈希值。引擎比较哈希与缓存版本不一致就直接重新采集而不是复用缓存。对于特别大的项目还可以用文件系统事件监听器比如watchdog在文件保存后几秒内主动失效该文件的缓存。另外用户手动置顶的上下文也要有过期概念。不能因为用户昨天pin了一个文件今天就一直带着。我在显式上下文上加了时间戳超过设定时限后自动降权用户也能看到“该文件已被置顶超过30分钟”的提示。4.3 自动模式误判与用户冲突自动模式误判最经典的场景有两种。一种是用户明明在看前端页面却在聊天框问后端接口设计自动聚焦模式只带了前端文件答案自然不对。另一种是用户问“这个项目有几个模块”自动模式判断为聚焦模式结果只带了当前目录结构缺失全局信息。我处理误判的方式是“先降级提醒再升级”。也就是说当模型回答置信度低或者检测到当前模式上下文里没有用户问题中的关键词时不是立刻切换模式而是追加一条提醒“当前模式下可能缺少项目全局信息建议切换到推理模式或全局模式”。把主动权交给用户。还有一个容易被忽略的问题用户手动切换的模式与自动模式冲突。如果用户手动切到聚焦模式而我后台又自动升级到推理模式用户会觉得系统在跟他对着干。后来我定了规则用户手动选择优先自动切换只在用户未手动指定时才生效且自动切换后必须留下可恢复入口。4.4 实测数据与避坑经验最后分享一组我自己项目里的前后对比。最早只有全量模式时平均每次请求消耗约2.3万tokenP95延迟6.8秒用户对“回答太慢”的抱怨很多。改成聚焦/推理/全局三档后默认模式设为聚焦平均消耗降到8千token左右P95延迟降到3.1秒回答准确率主观评价提高了约15%。这个结果说明问题了吗说明降低上下文量并不一定降低质量反而因为信息更聚焦而提升了效果。但也带来一个新问题聚焦模式下用户问跨文件问题时模型经常回答“缺少上下文”。所以我又加了“检测到跨文件意图时自动升级为推理模式”的规则通过问题里的文件名、模块名关键词触发。避坑经验有几条不要追求模式数量先做两档紧凑和完整上线一周后再看日志决定是否加第三档。每次请求的上下文日志必须留包含模式名、source列表、token用量、裁剪源。没有日志优化就是盲人摸象。权重参数可以从一个基准配置开始但一定要设计成配置文件而不是硬编码这样在不同项目间切换时不用改代码。测试用例要包含“上下文不足”场景。直接问模型“信息不够时你会怎么说”确保它在缺失信息时不胡编。我个人在实际操作中的体会是context-mode最值钱的不是那一堆代码而是你对“哪些上下文真正有用”的判断。判断来自日志、来自失误、来自一次次的对比实验。如果你准备给自己的AI工具加这个能力先花一周时间记录用户真实提问把每个问题“应该带哪些文件”都标出来再回头设计模式会顺利得多。最后再分享一个小技巧把模式切换的快捷键放在用户最容易按到的地方用户越容易控制上下文模式就越信任你的AI工具。