1. 为什么我在本地写了个“context-mode”来解决上下文管理问题作为一个常年跟 AI 辅助开发工具打交道的人我最崩溃的场景不是模型答错而是同一个会话里模型明明几轮前还记得的关键设定说忘就忘。你反复强调别动 service 层之后它下一轮照样给你生成一个改了 service 层接口的代码。你放进去的依赖版本、接口协议、目录结构它在十轮对话之后就像从来没看过一样。这类问题的根源其实不在模型能力上而在上下文管理策略上。绝大多数人是把所有内容一股脑塞进对话里觉得塞得越多模型就越懂。实际情况恰恰相反上下文窗口是有限的塞进去的内容会互相稀释。放了两万字的接口文档模型记住的可能是文档里无关紧要的日志格式而不是你最在意的几条约束。真正该被模型记住的核心指令和那些只用一两次就能丢弃的临时信息被丢进了同一个池子里。我用过很多现成方案比如给会话写固定 preamble、做角色设定、整理项目规范文档但都不够系统。后来我干脆自己写了一个叫 context-mode 的小工具核心思路是把上下文分成长期记忆区和短期工作区并根据当前任务类型动态调整两侧的比例和权重。用大白话说就是给对话上一套记忆管理策略——该记住的死死摁住不该记住的用完就扔。这个工具不是传统意义上的插件不需要改模型推理代码也不依赖某个特定 AI 产品。它是一层运行在你和模型之间的上下文调度层在把请求发给模型之前由它来决定哪些信息必须带上哪些可以打折哪些干脆丢弃。用完这套东西之后我在代码生成、文档总结、架构设计这几类任务上的返工率明显下降尤其是那种上一轮说的约定下一轮就忘的问题基本被根治了。这个项目适合谁如果你经常用 AI 做长对话、需要跨多轮保持一致的开发规范或者你处理的任务类型跨度很大一会儿写代码、一会儿写方案、一会儿查文档那么 context-mode 的思路和实现方式你肯定用得上。即使你不打算复刻我的代码光把上下文分区这个思考模型拿走就能显著改善你跟模型对话的效率。2. context-mode 的整体设计思路为什么分区模式比塞满窗口更好用2.1 一个生活化的类比你的大脑不可能同时记住所有事先打个比方。你上班的时候不会把过去十年的工作经历全部放在脑子里最前的位置你只会临时把今天要用的资料摊在桌面上而把那些重要但当前用不到的东西收进抽屉里。桌面上这张纸就是短期工作区抽屉里那些文件就是长期记忆区。如果今天只是写一封邮件桌面只需要一张纸就够了抽屉里那些资料压根不用打开。如果你今天要写一份年度规划那就得从抽屉里翻出好几份过往数据桌面摊开的内容就多。AI 对话也是同一个道理。模型的工作记忆是有限的每轮生成回复都要基于当前可见的全部内容。如果一上来就把公司背景、代码仓库结构、历史决策记录、本次需求、临时备注全部塞进去那模型每次都要消化大量低权重信息反应变慢不说关键约束还容易被淹没。context-mode 最核心的设计就是把可见上下文显式分成两个区域A 区长期指令区存放那些每轮对话都必须遵守的稳定规则比如编码规范、禁止触碰的模块、输出格式要求、项目关键路径。B 区临时工作区存放当前任务相关的材料比如这次要修的问题描述、上游接口文档、报错日志、相关代码片段。每次发起请求前工具会重新计算两个区域的内容。A 区几乎恒定不变B 区则跟随任务推进持续滚动更新过期的信息自动出队新的信息按优先级入队。这样模型永远在一个干净、聚焦的上下文里做推理而不是在杂物堆里猜重点。2.2 三种内建模式分别解决什么场景光有分区还不够因为不同任务对上下文的消耗方式完全不同。context-mode 内置了三套模式分别对应我在实际开发中最常遇到的三种任务类型。第一套是速战速决模式short-context mode。典型的场景是只问一个小问题比如这个函数的正则表达式哪里写错了或者这个报错是什么意思。这种任务根本不需要把项目背景全塞进去只需要把报错信息和相关十几行代码放进去就够了。这个模式下B 区会限制得非常小A 区也只保留最基础的角色设定保证模型拿到的是最小可用上下文响应速度最快、最不容易被无关信息干扰。第二套是深度任务模式deep-work mode。适用于需要多轮迭代的复杂任务比如实现一个用户认证模块或者重构整个数据层。这种任务要求模型跨多轮保持高度一致A 区必须包含完整的项目结构、技术选型、约束条件B 区则要支撑不断增大的中期产出比如已经生成的接口定义、数据结构、依赖版本。这个模式下上下文窗口的利用率最高但代价是单轮请求的 token 消耗会大不少。第三套是紧急抢救模式debug mode。专门为线上出了个 bug 你只想赶紧定位这种高压场景设计的。它会自动压低 A 区的占比把尽可能多的空间让给 B 区的报错栈信息、日志片段、线上配置。因为在跑救火任务时你的核心诉求是让模型集中精力看现场而不是反复强调代码规范。换句话说这种模式允许你暂时牺牲规则约束换取上下文聚焦上的极限收益。三种模式的本质是把上下文分配做成一个可调策略而不是一刀切。这也是我认为 context-mode 跟简单拼 prompt最大的区别后者是静态的前者是有弹性的。2.3 上下文调度的核心流程从输入到请求的四步流水线context-mode 在向模型发起请求之前会走一套四步流水线。我把它写在项目 README 的第一行因为理解这四步你就理解了整个工具的核心。第一步叫清洗sanitize。把输入里的废话、重复内容、格式杂乱的日志压缩成结构化信息。比如你把一整段 JSON 日志丢进来工具会把时间戳、非关键字段全部剥掉只保留 error message 和堆栈关键行。第二步叫归类classify把清洗后的内容按长期规则和临时材料分拣进对应的区。第三步叫压缩compress。这一步对 B 区特别重要因为临时工作区如果无限膨胀最终还是会变成新的杂物堆。工具会按照内容的新鲜度和引用频次做衰减对超过 N 轮没有被再次引用的信息做摘要压缩。第四步叫组装assemble按当前模式指定的比例把 A 区和 B 区的内容拼接成最终发给模型的请求。这套流程单独看每一步都不复杂但合在一起效果比手工整理 prompt强得多。最关键的差异在于它是自动化的、持续运行的而不是每次对话时靠你手动去复制粘贴。3. 核心功能拆解长期指令权重、上下文衰减与模式切换机制3.1 A 区长期指令的权重管理让模型至死不忘三条铁律A 区想解决的问题是模型为什么总是忘记我说过的重要要求。我检查过很多次对话记录发现模型忘事分两种一种是它真的没有收到那个信息信息压根没出现在上下文中另一种是它收到了但上下文里同类信息太多导致它无法判断哪条优先级最高。context-mode 处理第二种问题的手段是给 A 区的每条指令显式设置权重。权重最高的指令不仅放在请求的最前部还会在前缀加上强调标记。以当前主流模型对指令的敏感程度来看当若干条约束在上下文中彼此竞争时权重和位置差异就能起到决定性作用。举个例子我的一个实际项目里有三条铁律代码禁止使用 any 类型所有数据库操作必须走 repository 层生成的注释必须用中文这三条我会设置为最高权重每次请求都会原样出现在 A 区顶部。而像我记得你上次给过一个分页函数这种偶尔用到的信息权重就低很多放在 A 区末尾被压缩的优先级也最高。在实际使用中我发现一个关键细节A 区的内容不是越多越好。如果 A 区里塞了三十条重要规则那模型会把这些规则平均对待最后没有一条真正重要。context-mode 的默认策略是 A 区最多保留约 12 条权重最高的指令超出的部分强制降级到 B 区。这样做的效果非常明显——规则条目越少模型对每一条的遵从度越高。3.2 上下文衰减机制超过三轮没被引用对不起请让位B 区最大的隐患是陈旧信息堆积。举个例子你第一轮让模型分析了某个报错报错信息被放进了 B 区。之后五轮你都在讨论解决方案那个报错原文还躺在 B 区里占着位置。你要不是刻意清理它可能会一直占据几百个 token 的空间直到窗口耗尽。context-mode 的衰减机制模仿的是人类记忆规律一个信息如果在最近几轮对话中完全没有被引用它就会被判定为低热度自动触发压缩流程。默认的热度衰减系数是每轮 0.7也就是说一个信息如果连续三轮都没被模型中任何一条回复引用过它的热度就会从 1.0 降到大约 0.34这时候它占用的 token 会被压缩到原来的四分之一只保留摘要。如果连续六轮没被引用热度降到 0.1 以下工具会直接把它从上下文中移除。这里要注意衰减机制不是无脑丢信息。如果某个信息虽然多轮没被引用但它在 A 区被标记为会话级必需那它就不会被移除只会被压缩。所以 B 区的自动清理本质上只针对那些临时用一下、用完即弃的材料。我最初实现的时候直接按轮数做衰减后来发现不准确。因为有的轮次用户只回了个好字换来的是模型刷新了一整版代码这时候旧信息的引用热度其实是被刷新的。后来我改成了引用感知衰减就是当模型回复中出现与旧信息相关的片段时该信息的热度会被自动重置。这个改动让衰减机制的误杀率大幅下降。3.3 模式切换的触发策略手动为主自动提示为辅最理想的模式切换是AI 自动识别任务类型并切换但以当前的技术水平纯自动切换在复杂对话里经常判断失误。所以我采用了比较务实的策略手动切换为主自动提示为辅。用户输入的指令里如果包含特定触发词比如重构实现新功能工具就会提示当前任务疑似深度任务模式是否切换如果包含修 bug报错就会提示当前任务疑似紧急抢救模式是否切换——但最终决定权在用户手里绝不自动越权。这个设计是有原因的。我在真实使用中发现模式切换一旦自动化错误切换的代价非常高。试过在实现新功能的对话中误切成短上下文模式结果模型把之前定义的数据结构全忘了所有代码推倒重来。手动切换虽然多了一步操作但胜在确定性和可控性。工具类软件最重要的不是聪明而是可预期。4. 实操记录从零配置一个可用的 context-mode 环境4.1 环境配置与依赖准备context-mode 的使用前提是你已经有一个可以调用大模型 API 的开发环境。我用的是 Python 3.10 FastAPI 做成本地服务核心依赖只有三个openai 客户端库、pydantic 做配置校验、sqlite 做会话状态持久化。你如果不需要做成独立服务也可以直接把 context-mode 的核心函数嵌入到你自己的脚本里连 FastAPI 都不用装。安装依赖的完整命令如下pip install openai pydantic sqlite3注意sqlite3 是 Python 标准库不需要单独装。openai 库版本建议用 1.x 以上因为 0.x 的老版本接口差异太大我的代码是基于新接口写的。配置文件是我建议所有使用者首先看的入口。context-mode 使用一个 YAML 文件来管理所有模式参数核心配置项如下modes: short: a_ratio: 0.2 b_ratio: 0.5 max_tokens: 2000 deep: a_ratio: 0.4 b_ratio: 0.8 max_tokens: 8000 debug: a_ratio: 0.1 b_ratio: 0.9 max_tokens: 4000 decay: factor: 0.7 remove_threshold: 0.1 compress_threshold: 0.34 long_term: max_rules: 12 top_priority_prefix: __RULE__这几个参数背后都是有讲究的。a_ratio 和 b_ratio 表示该模式下 A 区和 B 区占上下文窗口的最大比例b_ratio 通常比 a_ratio 高因为大多数任务中临时材料本来就比长期规则多。max_tokens 不是模型的完整上下文窗口尺寸而是你允许 context-mode 实际占用的上限留出来的空间给模型生成回复用。4.2 核心实现上下文组装函数下面这段代码是 context-mode 最核心的函数负责把两个区域的内容按模式比例拼接成一个最终请求。我只保留了最小实现去掉了一些细节方便你直接理解。def assemble_context(mode: str, long_term: list, short_term: list, config: dict) - str: mode_cfg config[modes][mode] decay_cfg config[decay] # 第一步衰减和压缩短期工作区 compressed_short [] for item in short_term: if item[recency] decay_cfg[remove_threshold]: continue if item[recency] decay_cfg[compress_threshold]: item[content] summarize(item[content]) compressed_short.append(item) # 第二步按比例分配 token 预算 a_max_tokens mode_cfg[max_tokens] * mode_cfg[a_ratio] b_max_tokens mode_cfg[max_tokens] * mode_cfg[b_ratio] # 第三步组装长期指令区 result_parts [] used_tokens 0 for rule in long_term[:config[long_term][max_rules]]: prefix config[long_term][top_priority_prefix] if rule[priority] high else rule_text f{prefix}{rule[content]} rule_tokens estimate_tokens(rule_text) if used_tokens rule_tokens a_max_tokens: break result_parts.append(rule_text) used_tokens rule_tokens # 第四步组装临时工作区 for item in compressed_short: item_tokens estimate_tokens(item[content]) if used_tokens item_tokens b_max_tokens a_max_tokens: continue result_parts.append(item[content]) used_tokens item_tokens return \n\n---SEPARATOR---\n\n.join(result_parts)这段代码里几个细节值得说。衰减判断用的是 recency 字段每轮对话结束后全局减一次被引用的条目重置为 1.0。estimate_tokens 是一个估算函数中英文混合场景下我采用中文按 1.5 token/字、英文按 0.3 token/字符的经验估算虽然不完全准确但用于预算控制足够了。summarize 函数建议直接调用模型做一次摘要不要把几百行日志原样留着。4.3 首次配置的最佳实践哪些内容进 A 区哪些进 B 区配置 context-mode 最让人犯难的问题就是到底什么东西该放进 A 区我的建议很简单只放那些如果你不让模型遵守它就会犯错的内容。举个例子如果你做的是 Java 项目你希望模型生成的类名是驼峰式这属于 A 区如果你希望模型在每次回复前先列出一个 TODO 清单这也属于 A 区但如果你只是想在一轮对话里让模型参考一下某个开源项目的写法这种材料就该在 B 区用完就走。还有个容易被忽略的点A 区的内容必须用命令式语气写不要用描述性语气。禁止在代码中使用 any 类型是命令式项目中通常不会使用 any 类型就是描述式。实测下来模型对命令式指令的遵从度比描述式高很多。这大概是因为命令式指令更像用户直接给出的要求而描述式指令更像项目文档摘录容易被模型归入参考信息而不是行为约束。首次配置时不要贪多。我建议第一版先只配 3 到 5 条 A 区规则跑一周看模型在哪些地方依然反复出错再逐步补上。一次性配满 12 条你会很难定位到底是哪条规则未被遵守因为干扰太多了。4.4 调用接口设计一次完整的带 context-mode 的对话请求配置好之后实际调用流程就是先更新状态再组装上下文最后发给模型。下面是用 FastAPI 暴露接口的示例from fastapi import FastAPI from pydantic import BaseModel app FastAPI() session_store {} class ChatRequest(BaseModel): session_id: str user_message: str mode: str deep app.post(/chat) def chat(req: ChatRequest): session session_store.get(req.session_id, {long_term: [], short_term: []}) # 更新短期工作区把新的用户消息加进去 session[short_term].append({ content: req.user_message, recency: 1.0, timestamp: time.time() }) # 衰减旧信息 for item in session[short_term]: item[recency] * config[decay][factor] # 组装上下文 context assemble_context(req.mode, session[long_term], session[short_term], config) # 调用大模型 response client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是该项目的高级开发助手。}, {role: user, content: context} ] ) # 引用感知如果回复里包含旧的短期信息片段重置其 recency for item in session[short_term]: if item[content][:50] in response.choices[0].message.content: item[recency] 1.0 session_store[req.session_id] session return {reply: response.choices[0].message.content}这个接口描述的是核心回调流程实际部署时建议加上历史消息的持久化存储和线程锁避免并发请求时状态错乱。5. 踩坑记录context-mode 落地过程中最常见的五个问题5.1 衰减误杀频率低但重要的信息被提前清除这是我遇到的第一个坑。原本的衰减机制只看引用频率但有些信息虽然引用频率低重要性却极高。比如某个数据库表的结构说明只在最开始讨论字段时用过一次后续十轮都在写业务逻辑按照原版衰减规则它大概率会在第五轮左右被压缩掉但等到第八轮突然要写一个关联查询时模型已经把表结构忘干净了生成出来的 SQL 全是错的。解决办法我前面提到过把这类信息手动标记为会话级必需。context-mode 里我给短期工作区增加了一个 optional 字段optionalfalse 的条目不参与衰减移除只参与压缩。代价是这类条目会一直占着 token所以标记必需时要想清楚——只有那些后面一定会再用到的材料才值得这样标。5.2 压缩摘要导致信息丢失模型复述的能力被削弱压缩机制虽然节省了 token但摘要永远有损。我最开始用摘要替换原始内容的时候遇到一个很尴尬的情况模型知道报错发生过但不记得报错的具体行号导致修复建议一直跑偏。后来我调整了策略摘要里强制保留关键结构化字段。对日志类内容摘要必须包含错误码、行号、模块名对代码类内容摘要必须包含函数名、入参类型、返回值类型。这个改动之后压缩的可用性明显提升。说到底压缩的目标是去噪不是去信息关键信息字段的完整性必须保证。5.3 模式切换错误上下文聚焦反而让模型变蠢有一次我用紧急抢救模式去跑一个本该用深度模式的任务结果非常惨。当时要重构一个核心模块我图省事直接用调试模式进入B 区占比拉满A 区长期规则被压缩到只剩 10% 的空间结果模型连项目最基本的命名约定都忘了生成了大量风格不统一的代码。那次之后我彻底改变了思路模式切换刀一定要握在用户手里工具的自动提示只能当参考不能当替身。5.4 多会话状态混乱session 隔离不干净导致上下文串线早期版本我只有一个全局上下文存储没有按会话隔离。有一次同时开两个会话一个在改前端一个在写后端文档结果两侧的内容互相混进对方的上下文里。模型在前端会话里开始输出后端接口文档场面一度非常尴尬。后来我把 session 状态彻底隔离每个会话独立维护自己的 A 区和 B 区串线问题才彻底解决。这个教训也提醒我凡是带状态的系统隔离的设计必须放在第一天做不能等出了事故再补。5.5 估算 token 与实际不一致预算控制失真estimate_tokens 函数毕竟只是估算跟真实 API 返回的 token 数经常差 20% 到 30%。如果预算算得太紧上下文会遗漏关键材料算得太松又容易触发模型的真实上下文窗口溢出。我的解决方案是在每次请求返回后用 API 返回的 usage 信息反向校准估算函数。具体做法是维护一个最近 50 次请求的平均偏差系数估算值乘以偏差系数后再纳入预算计算。这样跑几轮之后预算控制会越来越贴近真实。老实说做 context-mode 这个工具的过程比工具本身的代码更有价值。它逼着我去思考一个之前一直忽略的问题我们跟 AI 协作时效率的瓶颈往往不是模型不够聪明而是我们没有给它足够好的信息结构。A 区和 B 区的划分、衰减机制、模式切换本质上都在做一件事把上下文的布局显式化让最重要的信息永远出现在最该出现的位置。我现在已经把这个思路用在了日常的所有 AI 对话里就算脱离工具本身我也会下意识地做分区先把核心约束写清楚再把材料按重要程度排列最后才发出去。这个习惯的收益比任何工具都大。如果你也在用 AI 辅助工作到长对话我建议你先别急着写代码而是试着用手动的方式做三天的上下文分区把每轮对话前要发的信息分类整理一次你会有一种豁然开朗的感觉。之后你再决定要不要像这样写个工具来固化流程都来得及。