最近我被 AI 编程助手折腾得有点“怀疑人生”。现象很奇怪同一个会话里前 20 轮它还非常懂我到了第 30 轮开始答非所问甚至把上一轮已经废弃的函数签名又“考古”出来硬塞进新代码里。起初我以为是模型越聊越笨后来重新读了一遍发送出去的 request才发现问题其实在我上下文窗口里堆满了过期信息、重复代码和不相关文件模型等于在垃圾堆里帮我翻宝。把上下文当成一个可以随时堆叠的草稿纸是我那段时间最失败的习惯。后来我花了两周时间专门收拾这件事顺手整理成一套可以在日常工具链里直接落地的思路名字就叫 context-mode。它不是某个官方协议也不是神秘库而是一套“在请求发给模型之前先对上下文做采集、压栈、裁剪”的工程化打法。如果你也在用各类 AI 辅助编程、AI 文档问答或者长对话工具并且经常遇到“答非所问”“越聊越蠢”“检索结果互相打架”这类问题这篇文章应该能给你一点不一样的角度。我会把为什么模型会“失忆”、怎么设计三种上下文模式、如何写一个最小可用的 context-mode 工具以及我实际踩过的坑一次性讲清楚。1. 为什么你的 AI 搭档会“越聊越笨”1.1 失忆现场一次让我头大的多轮对话调试先还原一个真实场景。我在改一个前端项目的列表筛选逻辑刚开始跟助手说清楚问题后它给出的方案很干净。到了第三轮我问“那排序也一起处理掉”它突然把负责接口请求的 service 文件也改了一遍理由是根据上下文里某个“早期约定”。我翻聊天记录确实在第五轮提过一句“这个接口可能要支持多个排序字段”但那是当时的一句假设后来已经否掉了。问题不在于模型的推理能力也不在于它故意乱来。模型能看到的只是我喂给它的那几千个 token。那几千个 token 里面除了当前讨论的代码还有五轮以前的一句假设、两段已经不需要的旧 diff、三个无关模块的 description。它按照“最全面的理解”去推断自然会认为那句假设仍然有效。这个场景很多搞过 AI 编程的人应该都不陌生。对话越久上下文越“脏”模型反而越难保持初心。传统文本编辑器里我们有“文件”、“窗口”、“标签页”这些心智模型但在 LLM 工作流里很多人根本没有想过要给上下文做分层和分区管理。1.2 上下文不是草稿纸是预算表大语言模型的注意力范围有限这一点和人的短期记忆很像。你不可能在开会时让每个人先读 30 份无关材料再讨论一个战术问题。给我的编程助手喂上下文本质上也是在做一个预算分配系统指令、项目规则、当前文件、相关代码、历史摘要、用户最新需求、模型输出预留每一块都要花钱。你给模型的上下文越多单个 token 能分到的“被注意权重”就越低。尤其是当上下文里塞满高度相似但不相同的代码片段时模型很可能被其中更啰嗦、位置更靠前的版本带走。之前我就遇到过同一个工具函数被检索器从不同分支里各取了一份一个旧版本一个新版本混在同一个 prompt 里模型最终选择了旧版本的参数顺序生成的新代码全部对不上。后来我给自己定了条原则上下文是预算表不是仓库。每一轮对话、每一次检索、每一行 diff都要先问一句这玩意儿值不值得占预算。这个原则往后演化就成了 context-mode 的雏形。2. 拆解 context-mode 的管线采集、压栈、裁剪2.1 采集层别把整个仓库灌进去很多 AI 工具配置里有个偷懒选项“把整个项目打包发过去”。对小型 demo 项目可能还行但工程稍微大一点几千个文件灌进上下文里基本等于把淡水鱼扔进海水里——能活但状态肯定不对。采集层的任务是确定“候选集合”也就是哪些文件哪些路径哪些最近变更哪些文档片段有资格进入下一步。我常用的采集组件有这几个代码搜索工具ripgrep按关键词定位相关文件而不是靠目录遍历。Git 状态获取当前分支最近改动明确本次任务聚焦范围。目录树生成器只输出前两层目录结构和文件作用说明不展开正文。文档索引按语义相关度召回每次召回量限制在几个 block 以内。采集层做得越窄后续压缩越轻松。这里有个容易被忽视的点采集也要带时间意识。比如一个搜索命中了 5 个文件其中两个已经超过 30 天没有改动与本次需求相关的可能性就低很多按时间权重排序后直接裁掉它们比什么都往 prompt 里扔要省不少 token。2.2 压栈层让摘要替代细节采集完之后候选材料可能还有好几千行。这时候不要急着直接塞先做一轮“摘要压栈”。所谓压栈就是把“沉重”的细节压缩成高层概况只保留当前任务需要的那一层精度。举个例子。我要让 AI 帮忙重构一个支付模块里的订单状态机最笨的做法是把整个状态机文件 800 行全部贴进去。更聪明的办法是先生成一份结构摘要文件路径src/payment/orderStatus.ts顶层函数getCurrentStatus, transitionTo, guardPending, cancelOrder核心不变量只有 pending 状态可以取消任何状态都可跳转到 closed涉及的外部调用billingService.notify, webhook.emit模型不需要一次看到 800 行它需要先理解这份地图。等讨论到具体某个函数再把对应函数体展开做第二层细节补充。两级甚至三级压栈是我目前用过最有效的省钱方案。压栈工具可以是任意一个支持文档摘要的通用模型也可以是轻量级规则提取器。我自己的习惯是让同一个模型做摘要因为风格统一。但要注意摘要层必须带上路径和行号的锚点否则后续需要展开细节时模型根本不知道去哪里找。2.3 裁剪层给 token 排优先级裁剪是把“预算表”变成“实际预算”的最后一步。假设模型窗口是 32k你不能把 32k 全部花光因为还需要给模型预留输出 token 的空间。一般来说输出至少要留 20%-25% 的窗口否则模型会生成到一半被迫截断导致代码残缺。裁剪时我按固定优先级处理这个顺序基本可以通用系统指令必须保留不可裁剪。用户最新需求必须保留原文引用。当前文件相关片段高优但可以按需折叠。最近 git diff中优优先保留与当前任务相关的路径。目录结构低优只保留一层。历史会话摘要低优强制压缩成几句话。无关样本直接丢弃。用一个具体例子说明预算分配。某次我用 32k 窗口的模型做重构实际分配大概是这样的。项目预算说明模型输出8000必须给足防止截断系统指令与项目规则1500工程规范、语言偏好当前文件片段10000本次任务核心最近改动 diff4000相关文件的 patch目录结构与文件清单1500帮助模型理解项目边界历史会话摘要2000只保留结论不保留过程冗余余量1000应对突发上下文合计28000留 4000 缓冲不塞满这里最关键的动作是“限制历史会话摘要”。很多人喜欢把整个聊天记录倒进下一轮 prompt这几乎是浪费 token 最典型的姿势。历史对话里大量的语气词、重复解释、错误尝试对模型帮助约等于零。我会在每轮结束后让系统对“已经消耗的对话”做一次压缩生成 2000 token 以内的状态摘要包括当前目标、已否决方案、遗留问题。3. 三种可切换的 context-mode 模式把采集、压栈、裁剪组合起来就有了三种可以随时切换的 context-modelightweight、balanced、deep。名字不重要关键是每种模式对应的上下文口径完全不同。我自己的经验是把模式切换做成一个显式的动作而不是全靠自动判断反而更容易控制效果。3.1 lightweight当前文件 光标上下文lightweight 模式只给模型最小上下文大约 2k-6k token。它适合场景非常明确、改动面很小的提问比如“这个函数为什么返回 null”“把这里改成箭头函数”“这个单测断言错在哪里”。在这种模式下采集层只关心当前打开文件。光标位置附近上下各若干行比如 50-100 行。当前文件顶层函数清单。项目根目录的一行说明。它不加载 git 全局 diff也不搜索历史文档。对你没看错就是故意不加载。因为很多轻量问题的答案就藏在当前文件里。加载过多无关内容只会让模型更可能从“记忆库”里抽取一套无关模式来回答。lightweight 模式的哲学是既然问题很小就让模型专心看局部代码。3.2 balanced最近的改动都能看得到balanced 是我日常用得最多的模式适合中等粒度的功能开发、Code Review 片段分析、多文件 bug 定位。它大约占 12k-20k token在轻量与深度之间取得平衡。采集层在 lightweight 基础上多了几样东西当前分支的 git diff、最近修改文件的路径、与当前改动直接相关的模块入口、项目规则文件。压栈层会把不必展开的依赖函数做摘要把真正要动的函数保留全文。举个例子我要给某个表单增加校验规则。balanced 模式会加载表单组件、校验工具、接口请求模块以及本次分支里所有相关的 diff。它不会去扫描整个 utils 目录也不会把十几年前的旧文档捞出来。这个模式的裁剪原则是凡是和“这次改动的调用链”无关的文件一律不进上下文。3.3 deep整仓理解 检索增强deep 模式适合那些“问题发生在整个系统层面”的任务。典型场景包括分析跨模块的数据流、设计新的接口协议、排查偶发性能瓶颈、梳理老项目的技术债。这种模式需要更大的窗口甚至配合外部检索索引。deep 模式的实现分两步。第一步先对仓库做一轮异步索引建立文件级别的摘要库和代码片段 embedding。第二步根据用户需求做检索增强把高相关片段和文件摘要一起送进上下文。因此deep 模式不只是“把所有东西都塞进窗口”而是“先全局搜索再局部展开”。它更像是带资料的搜索引擎而不是一个贪婪的搬运工。我在处理一个历史遗留项目的路由重构时就用了 deep 模式。项目有 2000 多个文件我不可能把它们全塞进 prompt。深度模式先扫描了所有路由文件生成了路由模块地图然后针对 /api/v2 相关链路做了召回一口气把 30 个核心文件的相关片段带了出来。那次重构的准确性明显比之前盲改要好改动后回归测试一次性通过的比例高了不少。3.4 不同任务到底选哪个模式很多人在用 AI 辅助的时候习惯永远用同一种上下文套娃这是最容易出问题的。我把常见任务和模式的对应关系整理成了自己的选择表任务类型推荐模式原因单行修改、变量命名、追问解释lightweight局部上下文足够新写一个函数、调整一个模块、排查一个 bugbalanced需要调用链和最近改动跨模块重构、系统链路分析、技术栈迁移deep需要全局外部检索多轮需求澄清balanced 会话摘要既要历史又要防污染这个表不是一个死规则。当你发现模型在当前模式下频繁给出 “合理但无关” 的答案优先上跳一档比如 lightweight 切 balanced当模型开始在大文件里反复横跳优先下跳一档减少干扰。切换模式的动作本质上是调整上下文的“焦距”。4. 手写一个最小可用的 context-mode 工具理论再好不落地也是空谈。我抽了一部分时间做了个小工具大概三百行左右足够支撑日常编码场景。下面把设计过程分享出来你可以直接在自己的项目里照着做。4.1 配置文件长什么样工具的核心是一个 JSON 配置定义了三种模式分别需要采集哪些目录、哪些操作以及 token 预算。配置文件我放在项目根目录的.contextmode.json里{ modes: { lightweight: { maxTokens: 6000, include: [src/current.ts, rules.md], exclude: [**/node_modules/**, **/*.test.ts], useGitDiff: false, useDirectoryTree: false }, balanced: { maxTokens: 16000, include: [src, tests, docs/architecture.md], exclude: [**/node_modules/**, **/dist/**], useGitDiff: true, useDirectoryTree: true }, deep: { maxTokens: 42000, include: [.], exclude: [**/node_modules/**, **/dist/**, **/coverage/**], useGitDiff: true, useDirectoryTree: true, useEmbedding: true } }, rules: [ 不要修改公共工具函数的对外签名, 优先保持向后兼容, 提交代码前检查 TODO 是否清理 ] }切模式就是一句命令的事ctx-mode --mode balanced 给订单状态机增加超时取消逻辑这个命令会先收集候选文件再按预算裁剪最后把构造好的上下文打印到终端或者直接传给调用的模型 SDK。整个工具本身不跟任何模型绑定你可以在 OpenWebUI、本地模型 API、各种 CLI Agent 之间复用。4.2 核心流程的伪代码我习惯用 TypeScript 写这类工具伪代码大概长这样type ContextMode lightweight | balanced | deep; async function buildContext(mode: ContextMode, userPrompt: string) { const config loadConfig(); const budget config.modes[mode].maxTokens; // 1. 采集候选文件 const candidates await collectFiles( config.modes[mode].include, config.modes[mode].exclude ); // 2. 如果开了 git diff把最近变更归为高优先级 let diffPriority: string[] []; if (config.modes[mode].useGitDiff) { diffPriority await getChangedFiles(); } // 3. 按优先级给文件排序最近改动 当前文件 相关模块 其他 const ranked candidates.sort((a, b) { return priorityOf(b, diffPriority) - priorityOf(a, diffPriority); }); // 4. 依次读入文件并做 token 估算 const contextBlocks: ContextBlock[] []; let usedTokens 0; const outputReserve Math.floor(budget * 0.25); for (const file of ranked) { if (usedTokens outputReserve budget) break; const content await readFile(file.path); const tokens estimateTokens(content); if (tokens budget * 0.3) { // 大文件先压缩成摘要 const digest await summarizeFile(file, content); contextBlocks.push(digest); usedTokens digest.tokens; } else { contextBlocks.push({ type: full, ...file, content }); usedTokens tokens; } } // 5. 拼接系统指令、规则、上下文、用户请求 return assemblePrompt(config.rules, contextBlocks, userPrompt, mode); }这里有个很有用的细节大文件不直接全文载入而是先尝试摘要。摘要的 token 成本只有全文的三分之一左右但保留了文件路径、导出函数、核心不变量。当模型真的需要看某个函数实现时可以在对话中继续请求展开再按需读取。4.3 本地执行与效果衡量本地执行的效果衡量我建议关注三个指标一轮对话的 token 消耗明显下降说明裁剪生效。回合修改准确率模型改完后 tests 通过率是否提升。人工修正成本是否还频繁出现“模型改错文件”的情况。跑完一批任务后把统计打出来看一眼。我自己的结果是balanced 模式比之前“手动贴整包上下文”平均省掉 45% 的 token而多轮对话的正确率提升了不少尤其体现在“没有再次引入已否决方案”这一点上。工具本身不算复杂复杂的是设计决策。要不要用摘要代替全文要不要把 git 变更设为最高优先级要不要为 deep 模式加载外部索引每个决策都对应一个效果权衡。我的经验是先跑最小版本统计两周的数据再决定要不要上外部向量数据库。不要一开始就搞重型架构。5. 实测中的三个坑和补救办法这套东西看着挺顺但我在实际使用中还是踩了好几个坑。有些坑在网上文档里根本不会写只有跑过大量真实任务才碰得到。我挑三个最典型的说一下。5.1 摘要“折叠”丢精度反而误导了模型第一个坑出现在压栈层。我给一个大文件做了摘要摘要里写了“该文件包含订单相关的各类状态判断”。模型根据这个摘要自信地推导出某个常量存在结果在真正展开代码时发现没有。就是因为摘要把细节给折叠掉了模型只能靠语义补全一旦补错方向错误就顺着对话一路蔓延。补救办法是摘要必须带上“锚点清单”把文件里的顶层函数名、导出常量名、关键行号完整列出来。哪怕摘要本身只有 200 token锚点清单也要占 100 token不能省。模型看到锚点清单后就知道去要求展开哪个具体区间而不是自己瞎猜代码细节。5.2 旧 diff 一天不清代码越改越偏第二个坑跟 git diff 有关。我之前设置成“只要开启 balanced 模式就加载最近 diff”结果遇到一个跨了两天的分支diff 里堆积大量已经废弃的临时改动。模型以为这些改动仍然在和当前需求相关于是遇到相似函数名时就照着旧 diff 去 “完善”把已经删掉的代码又写了一遍。后来我给 diff 加了一个生效时间窗口只加载本次 session 开启之后产生的 diff或者只加载最近 30 分钟内修改过的文件对应的 patch。更严格点时每轮对话之前都主动检查一遍“哪些 diff 文件的内容已经和磁盘上不一致”不一致的直接从上下文里剔除。这一条看起来简单实际操作中需要用心但对防止模型“考古”非常关键。5.3 token 分给工具不给模型留余量第三个坑是我低估了输出预留的重要性。最开始设计预算时我把窗口 32k 几乎用到了 30k留给模型输出只有 2k结果模型经常在生成完一个函数后戛然而止连 import 都没写完等于废了一次请求。后来我才认真做了计算模型输出 token 数量跟代码长度高度相关长函数 注释很可能超过 4k所以输出预留不能低于窗口的 25%。新公式很简单输出预留 max(4000, 窗口大小 * 0.25) 可用上下文 窗口大小 - 输出预留 - 系统指令 - 缓冲这个式子看起来平平无奇但真正执行的人不多。很多人以为“上下文管理”只是控制输入忘了输出也是模型生成的一部分也要占据窗口资源。控制输入只是手段给输出留空间才是目的。6. 最后说一点我的个人体会如果你也在使用 AI 编程助手并且已经被“上下文跑偏”折磨过那我建议你先别急着换模型也别急着买更贵的套餐先把自己的 context-mode 理顺。每次动手前想一想这个任务到底值不值得加载这么多文件每轮对话结束后想一想哪些信息已经失效了下一轮是不是应该从摘要继续而不是把聊天记录原封不动再发一次。我自己维护这套 context-mode 已经有一段时间最大的感受是真正复杂的不是工具逻辑而是自我约束。那些“顺手多贴一个文件”的冲动那些“它应该还记得前面说过什么”的侥幸才是让上下文失控的真凶。把上下文当成预算之后我对模型的信任度反而回升了——因为我知道自己给它的材料是干净的、聚焦的、最新的。这套模式我现在还维持着每周一次的复盘目标只有一个检查是否有新的“上下文浪费点”出现。比如某个固定的系统指令是否已经过时某个一直开启的文件夹是否已经成了噪音源。AI 工具会持续迭代但管理上下文的意识什么时候都不过时。