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( model="your-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 字段，optional=false 的条目不参与衰减移除，只参与压缩。代价是这类条目会一直占着 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 辅助工作到长对话，我建议你先别急着写代码，而是试着用手动的方式做三天的"上下文分区"，把每轮对话前要发的信息分类整理一次，你会有一种豁然开朗的感觉。之后你再决定要不要像这样写个工具来固化流程，都来得及。
