1. 被上下文窗口逼出来的思考我最初遇到的那三个场景这两年做 AI 辅助开发我最大的感受是模型能力早就不是瓶颈了上下文管理才是。几乎每天都能遇到这样的场景——你花二十分钟把问题背景讲清楚、把相关文件指给它结果它回了一段漂漂亮亮但完全跑偏的代码或者更离谱聊到第 30 轮之后它开始把之前自己写的东西都忘干净了。我先说三个真实发生在我项目里的场景你们看看熟不熟悉。场景一修一个 bugAI 把整个项目都读进来了。我的一个服务端仓库大概有 6 万行代码涉及十几个模块。我让 AI 帮我查一个线上超时问题它自作主张扫描了一遍整个项目结构把几十个文件都读进了上下文光这一轮就烧掉了几十万的 token 用量。结果呢它根本没有定位到问题反而被无关代码干扰给了一个建议优化数据库连接池这种正确但无用的答案。问题最后是我自己花了十分钟看日志找到的。场景二AI 只看了局部文件方案把别的模块搞崩了。反过来有一次我对 AI 说帮我把用户模块的缓存逻辑改一下它只看了用户模块的三个文件改得很痛快但完全没有意识到订单模块依赖了用户模块里一个内部方法的返回结构。部署之后订单查询直接 500事故等级不低。原因很简单——上下文里根本没有订单模块的存在它压根不知道还要照顾那边。场景三长会话后期AI 越来越笨。这个最普遍。一个功能做到了第 15 轮对话前面改过什么、什么方案被否决过、哪些约束是定死的这些历史信息挤占了大量上下文空间。到了后面几轮它开始重复提出已经被否掉的方案甚至开始自相矛盾。我那时候才意识到不是它笨是它的记忆被污染了。这三个场景指向同一个问题上下文窗口是有限的但需求方我和供给方AI 模型之间没有一个机制来主动决定什么该进上下文、什么不该进。默认行为只有两种——要么全塞进去要么只塞当前文件。前者浪费后者危险。于是我开始认真整理一套自己的方法名字就叫context-mode——不是某个现成工具而是一套围绕模式切换来管理 AI 上下文的工作流。这篇文章就把我踩过的坑、定下来的规则、实测的数据都摊开讲希望能帮你少走弯路。2. context-mode 的本质把上下文从被动接收改成主动设计2.1 先搞清楚上下文到底是怎么被消耗的要做主动设计首先得知道钱花在哪了、空间被谁占了。一次对话的上下文消耗由三部分组成消耗来源说明实际感受系统提示词与规则文件每次请求都会携带属于固定开销写得好是定海神针写不好是浪费 token用户输入的文件内容通过 引用或自动读取的文件行数越多越贵一个大文件轻松上万 token历史对话轮次之前所有问答都会被保留聊得越久占用越高而且无法单独删除某轮这张表看着简单但很多人对文件内容的成本没有直觉。我给你算一笔账一个 1000 行的 TypeScript 文件平均每行约 8~12 个 token也就是说单文件就得 1 万 token 左右。一个中型项目如果引用 8 个文件光这轮对话的文件内容就奔着 10 万 token 去了。而我常用的模型上下文窗口是百万级听起来很大但如果你每个文件都是这种量级聊个十几轮就顶天了。更要命的是历史对话的滚雪球效应。每一次回答都会变成下一轮的输入越到后面AI 可以腾出来处理新信息的空间越小。这就像一个人一边听你说话、一边还得不断复习自己之前说过什么脑容量早就被占满了哪里还顾得上深度思考当下的问题。所以 context-mode 的第一个原则就是尽可能让一次性输入占大头让历史对话占小头让无关文件直接为零。2.2 三种模式的定义精确、探索、全景我给 context-mode 定了三个标准模式对应三类完全不同的任务需求。名字不重要重要的是每个模式对该读什么、不该读什么有截然不同的判断标准。精确模式Surgical Mode适用于任务边界非常清晰的场景——改一个函数、修一个 bug、写一个独立组件。上下文里只放和这个任务直接相关的文件通常不超过 3 个。目标是让 AI 把全部注意力集中在最小闭包内不被打扰。探索模式Exploration Mode适用于我还不确定问题在哪的场景——排查线上故障、理解一段陌生代码、找某个功能的实现位置。这个模式下允许 AI 先通过结构性的手段代码搜索、目录树、调用关系做侦查而不是直接大范围读文件。等它锁定候选区域之后再切换到精确模式深入。全景模式Panoramic Mode适用于架构级任务——跨模块重构、技术方案设计、代码评审。这个模式下需要把核心模块的目录结构、关键接口、模块间依赖关系都放进来让 AI 建立起全局图景。但不是把整个仓库塞进来而是塞地图不是塞每个房间的照片。三个模式解决的核心矛盾其实就一个在有限窗口里怎么让信息密度最大。精确模式追求纵向深度全景模式追求横向广度探索模式则是两者之间的摆渡船。2.3 切换逻辑不是凭感觉而是按任务特征判断我刚开始实践时最常犯的错就是凭感觉选模式。后来我给自己定了一个判断标准就一句话如果这个任务出了错你最怕它错在哪最怕它遗漏了相邻模块的耦合关系 → 用全景模式别省那个 token。最怕它被无关信息干扰、答非所问 → 用精确模式别贪多。最怕它找错地方、连问题在哪都不知道 → 用探索模式先侦查再动手。举几个实际例子你会发现这个判断其实很快任务描述应该用的模式理由修复某个接口的空指针异常精确模式异常堆栈已经指到了具体行号直接打开那个文件就行排查用户偶尔收不到通知的诡异问题探索模式问题可能出在定时任务、消息队列、权限过滤任一环节得先定位把旧版 API 全面升级到 v2 版本全景模式影响面横跨多个模块必须看清依赖关系这套判断逻辑本质上是在替 AI 做注意力分配——你替它先筛一遍信息它才能把脑力花在真正值得的地方。这也是我在反复翻车之后最深的体会AI 不会主动帮你做减法减法必须由人来设计。3. 落地实践我的 context-mode 文件体系和操作流程3.1 根目录规则文件让三个模式可被 AI 理解光在心里想着这次用精确模式没用关键是得让 AI 知道你现在处于什么模式、应该按什么规则行事。我的做法是在项目根目录放一个规则说明文件不同工具对这类文件叫法不同有的叫 AGENTS.md有的叫 CLAUDE.md原理一致里面把三种模式的定义和切换条件写得清楚明白。文件的核心结构大概是这样的# 项目规则Context-Mode 本仓库使用 context-mode 工作流。对话开始时请先确认当前模式。 ## 模式定义 - surgical: 精确模式。只允许读取我明确指定的文件禁止扫描其他目录。 - explore: 探索模式。先使用仓库搜索工具定位问题向我报告候选范围等待我确认后再读文件。 - panoramic: 全景模式。我会提供模块地图和接口清单基于此回答禁止自行读取超过 5 个文件。 ## 切换规则 - 每轮对话开始我会声明模式例如 [surgical] 修复 auth.ts 的第 42 行空指针 - 如果你认为我声明的模式与任务不匹配允许你指出但最终由我决定。这里有一个非常关键的细节禁止和允许必须写具体不能写模糊的请酌情处理。我在早期版本里写的是根据任务需要读取文件结果 AI 的需要和我的需要完全是两套标准。改成明确的数量限制和范围限制之后效果立刻不一样。3.2 项目结构约定为每个模块准备地图卡片全景模式要想不烧 token前提是项目里有地图而不是让 AI 自己摸索。我的习惯是给每个核心模块维护一份简短的说明文档放在模块目录下刻意控制在一屏以内只包含四件事模块职责、对外接口、依赖的其他模块、常见的修改点。举个例子我某个后端项目的用户模块说明文档长这样# 模块user用户账号 ## 职责 - 注册、登录、token 签发与刷新 - 用户资料查询与更新供 profile、order 模块调用 ## 对外接口 - getUserById(id): UserInfo - updateUserProfile(id, patch): UserProfile - 注意返回的 UserInfo 中的 phone 字段自 v2.1 起默认脱敏 ## 依赖 - redis缓存 session - 内部事件总线发布 user.updated 事件给 order 模块 ## 常见修改点 - 登录流程在 login.ts - 脱敏逻辑在 dto/user-info.ts别小看这几行字。全景模式下我把 6 个模块的地图卡片一起丢给 AI加起来不到 2000 token但它对整个系统的理解已经远超你丢给它 20 个源文件的效果。这就是信息的压缩率——地图是稠密的照片是稀疏的。3.3 三种模式的具体操作姿势纸上谈兵够了说说我在实际会话里是怎么操作的。精确模式的操作流程开头声明模式[surgical] 修复 user-service 第 42 行空指针。只 引用两个文件出错的文件 它的直接调用方如果有的话。给出复现步骤或堆栈信息要求 AI 在改动前先用两句话复述它理解的现状。改动完成后要求 AI 列出它改了哪几个函数、影响范围是什么——这是为了防止它在精确模式下盲人摸象。第 3 步是我加的一个保险栓。AI 复述现状这一步能有效过滤掉它根本没看懂代码就动手改的情况。如果它复述错了你还能及时纠正比等它写完一坨代码再改成本低得多。探索模式的操作流程声明模式[explore] 排查用户偶尔收不到订阅通知的问题。禁止 AI 直接读取文件要求它先运行搜索找出与订阅通知相关的所有代码入口。让 AI 给我一份候选清单按可能性排序每条附上它在哪个文件、为什么觉得这里可疑。我在清单上圈定 1~2 个最可疑的位置然后明确说切到 surgical深入看这两个文件。这个模式最大的好处是省 token。探索阶段搜索操作的开销远低于读取文件而 AI 给出的候选清单相当于一份免费的事故排查简报。不过我要提醒一句探索模式的输出质量很依赖搜索工具对仓库索引的完整性如果你的项目里有过大文件或二进制文件记得先配置好忽略规则。全景模式的操作流程声明模式[panoramic] 评估将用户模块的缓存从本地内存迁移到 Redis 的影响。一次性提供各模块的地图卡片我上面说的那种小文档、整体目录树、以及一张手写的依赖清单。要求 AI 先输出它对架构的理解用文本描述一遍模块间数据流——这一步能验证地图是否传达到位。在它回答方案时要求每个改动点都注明涉及哪个模块、依赖什么接口方便我做影响面复盘。全景模式是最容易失控的因为 AI 往往会觉得既然你给了地图我再看几个源文件也不过分。所以规则文件里的禁止自行读取超过 5 个文件很重要一旦越过这个限制上下文成本就不可控了。4. 实测两周效果数据与反面教材4.1 用数据说话token 消耗与回答质量的变化我把这套方法用在一个中型 Node.js 后端项目上连续两周记录数据和之前随手把文件丢给 AI的做法做对比。不敢说严谨但趋势是非常明显的指标使用 context-mode 前使用 context-mode 后单次任务平均 token 消耗约 8.2 万约 3.1 万一次通过率AI 回答无需返工约 40%约 68%修复一个跨模块问题平均耗时约 25 分钟约 12 分钟因上下文污染导致的反复修正每周约 6 次每周约 1 次token 消耗降低 60% 我其实不太意外因为大部分无效读取被拦住了。让我惊喜的是一次通过率从四成升到接近七成——这说明上下文里的信息密度提升直接转化成了回答质量的提升。过去 AI 经常在无关代码之间迷路现在它每次拿到的文件都是有明确目的性的答非所问的情况自然就少了。4.2 两个典型翻车现场以及我怎么补的窟窿再好的方法也有翻车的时候。我挑两个最有代表性的说共同点是都暴露出 context-mode 的边界。翻车案例 A全景模式漏了隐式依赖。有一次做支付模块的改造我给了全景模式所有模块的地图卡片自以为信息给足了。结果 AI 给的方案里完全没提对账系统——因为我压根没在对账模块的地图卡片里写清楚支付成功事件会触发对账任务。AI 不知道这件事自然就漏了。问题根源在我的地图画得不完整不在 AI。这件事让我养成了一个习惯每次全景点完名之前自己先花两分钟过一遍这次改动会碰到的所有外部接口写在地图卡片之外单独发给 AI。地图卡片是静态的而这种本次任务关联清单是动态的两者配合才完整。翻车案例 B精确模式改了一个被别处 import 的函数签名。精确模式下我让 AI 修改某个内部工具函数的签名它干净利落地改完了还庆幸地跟我说影响范围已确认。结果那个函数被另外三个文件引用而我只给了它两个文件。好在项目有完整的单元测试CI 阶段直接飙红没有上线。但这次翻车让我意识到精确模式的精确必须建立在全局符号索引之上。所以我后来在探索模式和精确模式之间加了一条硬规则凡是修改函数签名、修改模块导出、修改接口返回结构这类有外部影响的操作哪怕任务本身看起来很小也要先花一分钟确认引用关系。具体做法是让 AI 先跑一次谁在引用它的搜索把引用方列表展示给我我再决定要不要加文件。这多花的 30 秒能省下后面一小时的返工。5. 进阶玩法把 context-mode 变成团队规范和自动化检查一个人用 context-mode 解决的是效率问题一个团队用 context-mode 解决的是协作问题。5.1 让地图卡片像代码一样被 review我见过太多项目里的 README 或架构文档写着写着就变成了历史遗迹——模块早就重构了文档还停留在半年前。context-mode 依赖的地图卡片如果过期比没有地图更坑因为 AI 会一本正经地基于错误信息给出看似合理的方案。所以我在团队里立了一条规矩修改模块的对外接口或依赖关系时必须同步更新模块目录下的地图卡片并且在 PR 描述里注明已更新模块文档。不需要专门走一个流程就在日常代码 review 的时候顺便看一眼。这样干了两周后地图卡片的准确率就基本能维持在业务迭代的节奏上了。5.2 在 CI 里加一道上下文文件过期检查这个是我们后来觉得光靠自觉不够写进 CI 的一个小检查。思路不复杂写一个脚本在提交时检查地图卡片里的对外接口与代码中的实际导出是否匹配。比如文档里写了getUserById(id): UserInfo脚本就去代码里找这个函数确认它还存在、签名还是一致的。一旦发现不一致就让 CI 提示模块文档可能需要更新。这个脚本本身不难写难的是定检测规则。我的建议是别把它做成一个太重的校验器先只查两件事接口是否存在、函数签名是否匹配。这两项占维护成本 20%但能发现 80% 的文档过期问题。对于 team 来说一个不会频繁误报的检查才有人愿意长期维护。5.3 这条路的下一步让模式切换变得更自动做到现在context-mode 还停留在人先判断、再手动切换的阶段。我自己也一直在想能不能把这个过程自动化一部分。比如探索模式跑完AI 给出的候选清单里我圈定了一个位置下一个动作切到精确模式并读取该文件完全是可以自动化的。一些编辑器插件也已经支持了这类按任务类型自动组织上下文的能力只是还没有形成统一的标准。我个人判断未来一两年里会出现更多支持层级化上下文的工具——全局规则、模块地图、任务局部上下文分三层自动组装。context-mode 现在做的事本质上就是提前踩出了这条路的轮廓。最后说点个人的体会。这套方法不是一次设计出来的是我在反复被上下文问题折磨之后一点一点试出来的。过程中最大的认知转变是别把 AI 当成一个什么都知道的同事要把它当成一个记忆力有限但非常专注的同事——你自己得想清楚今天这个任务它到底需要记住哪三件事。你替它省下来的每一分注意力都会直接变成更靠谱的回答、更少的返工、更省的 token。这个账怎么算都划算。