1. 从对话越聊越傻说起context-mode 到底在解决什么如果你最近用过 AI 编程助手改过老项目大概率遇到过这个场景对话刚开三分钟模型把需求理解得明明白白代码改得又快又准聊到二十分钟后它开始反复用一个已经不存在的旧函数名把你上周刚删掉的工具类又 import 回来甚至一本正经地告诉你某个配置在哪可那个文件根本不在当前分支上。这不是模型变笨了而是它的上下文被污染了。大模型在一轮对话里能看到的所有内容就像一个临时工作台随着历史消息、系统提示、各类文件摘要不断堆进去真正对当前任务有用的信息比例越来越低。我最早意识到这个问题是在用 AI 重构一个老旧的 Django 服务时模型连续三次把数据库连接配置改错——每次它都说我看一下 settings.py然后对着一个 session 里早已过期的旧版本做判断。后来我手动清空会话、重新只贴关键文件一次就改对了。这就是context-mode即上下文模式这个概念要解决的核心问题它不做别的专门负责管理 AI 工具在项目里的视野范围。你让它只看某个模块它就不会把整个仓库的边角料都塞进窗口你让它只在某个任务里记下临时结论它就不会把这些结论带到下一个任务里干扰判断。现实里有人把它理解成让 AI 记住项目背景其实不完全准确——context-mode 的本质不是延长记忆而是控制视野。大多数人对 AI 编程工具的使用方式是把所有相关文件一股脑喂进去觉得喂得越多模型就越懂项目。但模型的处理窗口是固定的上下文里塞五十个文件和塞五个高度相关的文件后者的输出质量往往反而更高。context-mode 就是在这种多多益善和精挑细选之间给了你一套显式的控制和切换机制。适合读这篇文章的人有三类一是用 AI 助手改大型项目时经常觉得刚开始好用、越用越乱的开发者二是想给团队制定一套统一的 AI 协作规范避免各写各的提示词、上下文浪费严重的 Tech Lead三是对大模型应用原理感兴趣想搞明白为什么同样一个模型换个上下文组织方式效果差这么多的人。2. context-mode 的两种工作模型回放式会话与外挂式感知很多人以为 context-mode 是某个工具独有的小功能其实它是一种通用的设计思想。市面上所有带上下文管理能力的 AI 编程工具底层基本都是两条路线基于纯文本回放构建上下文或者基于工具感知动态提取上下文。两条路线的实现原理完全不同适用场景也完全不一样。2.1 基于纯文本回放的会话上下文这是最简单也最常见的模式。它的工作方式是把用户发送的消息、模型的历史回复、粘贴进来的代码、系统预设的规则文件全部按时间顺序拼成一个长长的文本块每次调用模型时完整带上。你可以把它想象成一个会议录音——会议室里说的每一句话都被原封不动地放给后来参会的人听不管这句话还有没有参考价值。这种模式的优点是实现简单、行为透明你发过什么、模型回过什么都可以随时翻看排查问题非常方便。但它的致命弱点是上下文长度会随时间膨胀。对话进行到第 15 轮时前面 14 轮的反复试探和错误代码还占着大量窗口真正有效的当前目标 当前文件内容反而被挤到边缘。我在实际项目中做过一次统计一段持续 40 分钟的重构对话里模型真正依赖的有效上下文可能只占全部上下文的 30%剩下 70% 都是历史噪声。正因为这样几乎每个基于回放会话的工具都会额外提供一个压缩或总结入口——把前面的对话浓缩成几条要点然后开启新一轮会话。这就是一种朴素的 context-mode 切换从完整回放切到精华摘要。如果你经常手动清空会话、把结论贴到新对话里继续干活你其实已经在用 context-mode 了只是切得比较粗糙。2.2 基于工具感知的动态上下文提取第二种模式更聪明一些。工具不是被动地把所有历史消息堆给模型而是先通过命令行工具比如文件检索、目录树、代码搜索、Git 状态检测去扫描项目再根据模型当前正在使用的文件列表主动决定把哪些内容装进上下文。这个模式下上下文不再是一条持续增长的流水账而是一个按需构建的工作集。打个比分回放模式像把整栋楼的监控录像全部回放一遍让你找线索工具感知模式则像先派几个侦查员去楼里盯着可疑位置专门把关键画面传回来。命令行的定位能力相当于侦查员模型则是看画面的指挥官。这种模式的典型形态是一种作用在目录级别的白名单 焦点机制。你可以给项目根目录维护一份上下文规则类似通用的 AGENTS.md / CLAUDE.md 这类项目规范文件在里面声明哪些目录是核心逻辑、哪些目录是自动生成的产物、模型读文件时应该按什么顺序切入。当模型跳转文件时工具会拿着这份规则去决定该不该读、读多深、读完了保留还是丢弃。我在一个规模约 3 万文件的中型前端仓库里试过开启工具感知模式后单次任务的 token 消耗比无脑全量加载下降了约 60%而且改到第 20 轮时模型依然能准确引用最初的接口定义。2.3 一张表看懂两种模式的差异对比项回放式会话模式工具感知提取模式上下文来源历史对话 用户主动粘贴实时扫描项目 按规则动态抽取上下文长度随对话线性增长相对稳定按任务需要构建抗干扰能力弱旧信息容易污染判断强白名单隔离明显适用场景单文件修改、快速问题解答跨模块重构、大型仓库、多任务并行实现复杂度低几乎零配置高需要维护规则我自己实际用下来的感受是两者不是替代关系而是协作关系。日常改个小 bug回放模式够用一进入跨模块开发就必须切到工具感知模式否则再好的模型也会被陈旧上下文拖垮。3. 实操全流程把一个真实前端项目切进 context-mode概念讲多了容易飘我直接用一个模拟的电商前端仓库来做一遍完整配置。这个仓库有 8 个模块包含 Vue 页面、Node 中间层、一个本地 mock 数据目录和一个自动生成的类型文件目录。目标是让 AI 助手在开发购物车结算页时只关心相关模块不去碰支付回调逻辑也不去读自动生成的类型文件。3.1 第一步先给项目建立上下文地图在配置任何模式之前你得先知道自己项目的上下文长什么样。我最常用的做法是先跑一遍目录树把整体结构拍下来tree -L 3 -I node_modules|dist|.git|build|coverage这一步不是为了给模型看而是为了给你自己看。你需要在几十个目录里圈出哪些是核心源码、哪些是配置文件、哪些是脚手架产物。以电商仓库为例我圈出来的结果是核心源码区src/下的components/、views/checkout/、stores/cart.js接口定义区src/api/checkout.js所有请求都汇到这里本地数据区mock/目录改页面时可以看部署时不看生成产物区src/types/api-auto.ts由后端契约自动生成模型读它纯属浪费无关模块区src/views/admin/和src/services/payment/结算页开发时不需要了解把这几个区域写进项目根目录的上下文规则文件里相当于给 AI 助手发了一张地图。没有这张地图工具感知模式的扫描就失去了指引模型可能会从components/目录里无关组件开始看起。3.2 第二步选定工作模式明确白名单边界结合两种上下文工作模型我通常在项目根目录的规则文件AGENTS.md中写明默认使用工具感知模式按模块聚焦然后定义每个模块的白名单边界。示例片段如下# 项目上下文模式配置 ## 全局默认 - 焦点目录: src/, mock/, public/ - 忽略目录: node_modules/, dist/, src/types/api-auto.ts - 单文件读取上限: 600 行超出部分按函数签名摘要 ## checkout 结算页模块 - 入口文件: src/views/checkout/index.vue - 关联文件: src/stores/cart.js, src/api/checkout.js - 不要主动读取: src/services/payment/callback.js, src/views/admin/**这里的关键是忽略目录要比焦点目录更精确。很多人刚开始配置时只在白名单里写需要看哪些,结果模型确实只看那部分了但它调用的函数依赖了外部模块一执行就报错。我的做法是先允许它读取入口和关联文件等它跑出需求再按需扩大范围而不是一上来就放开全仓库的读取权限。3.3 第三步会话内的上下文约束指令项目级文件能管住默认行为但每个具体任务还需要一条会话级指令来锁定当前 focus。我的惯用开头是开启 context-mode模式: 聚焦焦点: 结算页。 任务: 修复结算金额在满减活动下计算错误的问题。 限制: 只读取 checkout 模块相关文件其他模块只允许查看接口签名不允许修改。这一句话同时做了三件事声明模式、声明目标、声明边界。模型拿到这句话后会过滤掉大部分无关文件只保留购物车状态管理、结算金额计算、接口请求三个上下文组块。实测下来同样的需求我在不开启 context-mode、只贴两三个文件的做法对比下出错率大概下降了 70% 以上。3.4 第四步持久化记忆与上下文压缩真正的生产项目不是单次对话就能搞定的。今天改结算页明天调满减规则后天可能又回头改购物车。每次重开会话时都要重新贴一遍规则显然不现实。所以我会设计一套永久记忆 短时记忆的上下文组合。永久记忆沉淀在项目级的AGENTS.md和docs/context/目录下的模块说明文档里由我手动维护记录的是不会频繁变化的事实比如模块职责、核心函数位置、约定命名方式。短时记忆则依赖 context-mode 提供的会话摘要能力——每轮任务收尾时让模型生成一份最终结论记录包含改了哪些文件、每个文件改了哪几块逻辑、留下了什么 TODO、下次续接时应该从哪里开始。例如做完结算页金额修复后我让模型生成一条摘要记到docs/context/checkout-session.md里 结算页金额修复 2025-06-18 起因: 满减条件判断使用了裸比较未考虑优惠券叠加 改动: - src/stores/cart.js: 新增 calcDiscount 函数统一算价 - src/views/checkout/index.vue: 调用 calcDiscount 替换内联算式 关联风险: mock 数据里 price 字段为字符串建议统一转 number 续接建议: 下一步可重构优惠券模块让折扣规则可配置化有了这个文件下次再让模型开发优惠券模块时只需要把这份摘要塞进新会话的上下文它就能快速接上完全不需要重新翻一遍旧代码。这一步就是上下文压缩的精髓——把 40 轮对话压缩成 6 行有效结论token 省了准确性还高了。3.5 完整示例一次对比实验的真实数据我用同一个任务在两种模式下各跑了一遍任务内容是给结算页加一个优惠码输入框并校验优惠码有效性。回放模式下我直接把结算页相关三个文件全量贴给模型让它一次性改完context-mode 下我维护好了上文所述项目级规则设置焦点目录为 checkout 模块让工具按需读取。结果对比如下指标回放模式全量粘贴context-mode按需读取首次正确率改完出现 3 处明显错误第一次编译通过上下文 token 消耗约 5.2 万约 1.8 万修改文件数量5 个含 2 个无关文件2 个后续追加需求时旧上下文污染严重清了会话重新来摘要里直接续接无污染token 消耗的数字会根据模型和工具实现有浮动但正确率和污染程度的差距是普遍存在的。这也是我把 context-mode 当作项目标配而不是锦上添花功能的原因。4. 踩坑记录我遇到的五个 context-mode 典型问题工具再好配置不当照样翻车。以下五个问题是我在不同项目里真实踩过的每一个都花了不少时间排查。如果你配置 context-mode 之后发现效果更差了大概率命中其中之一。4.1 旧上下文残留导致模型自相矛盾现象是第一个任务让模型读了老版本的支付模块第二个任务切到新的结算模块时模型还是会时不时引用老版本支付模块里的函数名。我检查后发现工具感知模式并没有我预想的严格隔离它采用的是一个类似引用的机制——新任务构建了新的上下文但旧任务的关联片段仍然被部分保留在内部缓存里模型在模糊判断时会去翻这些旧碎片。解决办法有两个一是每次切换任务时强制清理会话并重新生成摘要而不是基于旧会话继续追加二是给每个任务的会话标注明确的生命周期task 结束后就把对应目录从上下文白名单中摘除。做电商仓库时我遇到的旧上下文污染就是因为在checkout 模块任务里手动查看过payment目录的接口后来再切到购物车任务时模型总是试图调用payment模块的一个已废弃回调函数清掉会话后问题立刻消失。4.2 白名单设置过宽工具狂读无关文件有一次我为了省事把整个src/目录都写进了焦点区觉得反正模型会按需读。结果工具感知模式的扫描器还是忠实地把src/views/admin/下二十多个管理后台页面都扫了一遍美其名曰建立全局索引。单次任务的预处理 token 直接翻了三倍而且扫描结果还把模型带偏了——它误以为管理后台的权限模型也是结算页的一部分。复盘之后我把白名单改成了入口文件 关联文件 按需扩展三层结构并明确指定忽略**/admin/**。扫描范围和判断准确率立刻回归正常。这条经验很便宜但很值钱白名单不是越大越好它更像一个路由表只负责告诉模型该往哪走而不是把每条路都先走一遍。4.3 上下文压缩把关键决策记录剪掉了利用摘要机制压缩上下文时我犯过一个新手错误让模型自己决定摘要里保留什么。结果好话说尽它把修改了哪些文件记得很清楚却把最关键的为什么不能直接用某个第三方库这个决策原因给压缩没了。等下一次会话接着改时模型又重新用了那个被我否掉的方案前功尽弃。现在我给摘要设了一个固定模板强制要求包含四项决策背景、被否方案及原因、最终改动、遗留风险。那几条看似无用的被否方案及原因恰恰是防止模型走回头路的最重要信息。你可以把摘要文件里的格式直接 copy 过去用实测非常管用。4.4 根级上下文与模块级上下文互相打架这是多模块项目里最容易遇到的坑根目录的AGENTS.md写着全局默认忽略 admin 模块而src/views/checkout/AGENTS.md里为了结算页开发又写着需要读取 admin 模块的权限配置做联调参考。两条规则冲突时不同工具的生效策略还不一样有的后读覆盖先读有的直接报错停下。我的建议是建立一个 n 级目录只允许有一个权威规则的约定。根级规则只写全局不可变的东西比如忽略 node_modules、不修改类型文件所有模块相关的规则下沉到具体模块目录里并在模块规则开头写明它覆盖根级规则的哪一条。没有这份约定conflict 的排查成本会比省下的 token 还高。4.5 误以为 context-mode 能替代真正的架构设计这个坑不是工具的问题是使用心态问题。有些同事配置好 context-mode 后把 AI 助手当成能读懂的架构师让它一口气重构几个模块之间的依赖关系。结果模型确实忠实地只读了白名单内的文件但它的判断跳不出白名单——它看不到外面那个早就耦合成一坨的全局状态管理所有重构方案都是在局部视图内做的一落地就炸。context-mode 能帮你控制视野但不能帮你扩大视野。真正做架构级改动时我反而会把白名单暂时放宽优先读取架构设计文档和核心抽象层再回到具体模块。它不是万能药只是一把好用的手术钳切哪、怎么切还得靠你的判断力。5. context-mode 的进阶玩法与使用边界当你把基础配置跑顺之后context-mode 能玩的花样其实不少。这里分享三个我亲测有效的场景以及一个我认为非常重要的关闭时刻。5.1 用 context-mode 做多任务并行隔离我以前不敢让 AI 同时处理多个问题因为会话上下文一混就乱。后来利用工具感知模式的目录级隔离能力我把不同任务绑定到不同焦点目录里——任务 A 只读checkout/任务 B 只读payment/两个会话完全独立互不干扰。需要它们协作时再把 A 的会话摘要插入 B 的上下文让 B 知道 A 的结果但看不到 A 的中间过程。这相当于给 AI 助手做了一套多进程隔离系统。在提交代码时A 任务和 B 任务的改动也能分别打包、分别 review减少互相牵连。我一度用这个模式同时跑三条业务线的改造只要不共用目录几乎没出过上下文错乱的问题。5.2 设置上下文衰减与轮换策略长周期项目里同一个模块会经历需求变更、重构、回滚多个阶段。如果上下文里永远保留最早期的决策反而会误导当前开发。我引入了一个简单的时间衰减机制每周一检查docs/context/目录超过两周没有被引用的模块摘要就显式标记为历史上下文新会话默认不加载只在模型明确需要时才按路径读取。这么做的好处是防止项目里到处躺着过期结论。有个很典型的例子优惠券模块上个月做过一次规则重构对应的摘要文档仍然躺在 context 目录里。这个月改结算页时如果工具傻乎乎地把优惠券摘要也加载进 checkout 任务的上下文模型就可能沿用旧规则。衰减机制是给上下文做定期清理和给代码库做定期垃圾回收一个道理。5.3 context-mode 对新人协作的价值团队里引入 AI 助手时最头疼的不是模型能力而是大家各自用的方式不一样。有人喜欢全部贴文件有人只让模型看单个文件产出质量和排查成本完全不可控。以 context-mode 项目级规则文件作为统一入口相当于给团队的 AI 协作定了一份 SOP。新人入职后只需要先读根目录的AGENTS.md按模块规则开启会话就自动获得和资深成员差不多的上下文视野。相当于给团队加了一双可以横向复制的项目眼镜。交接时最常出现的代码看得懂但摸不准哪些能改的问题会被显式规则迅速消解。5.4 有些时候应该果断关掉 context-mode最后说一个重要结论context-mode 不是任何时候都要开。我通常会在两类场景里显式关闭它。第一类是探索性问题比如这个仓库里有没有某个隐藏的配置项或这段报错信息在项目里有哪几种解法的迹象。这种开放式搜索恰恰需要模型看到更广的上下文白名单反而会挡住答案。第二类是代码评审之前我会把关键改动文件直接贴在模型面前让它在不依赖扫描的情况下做一次全量逻辑审查防止焦点目录的既有印象影响它对改动风险的判断。另外一个反直觉的经验当模型开始频繁主动请求读取某些文件时往往说明当前焦点配置不对劲。上下文健康状态下它应该只在任务推进时按需补充文件如果老是在问可以读一下 xxx 吗多半是白名单缺了核心模块或者上一轮上下文已经被无关内容淹没。这五年做 AI 辅助开发我最深的体会是模型的能力只决定答案质量的上限上下文的管理却决定你能不能触及这个上限。context-mode 就好比给模型戴上的一副适当变焦眼镜——该看宏观的时候看宏观该聚焦细节的时候聚焦细节比一双永远长焦的眼睛好用太多。你现在就可以挑一个你个人维护的中型项目花半小时配置一份项目级规则文件再跑一轮真实任务试试。相信我对比之下你会回来给这半小时点赞。 1. 从对话越聊越傻说起context-mode 到底在解决什么如果你最近用过 AI 编程助手改过老项目大概率遇到过这个场景对话刚开三分钟模型把需求理解得明明白白代码改得又快又准聊到二十分钟后它开始反复用一个已经不存在的旧函数名把你上周刚删掉的工具类又 import 回来甚至一本正经地告诉你某个配置在哪可那个文件根本不在当前分支上。这不是模型变笨了而是它的上下文被污染了。大模型在一轮对话里能看到的所有内容就像一个临时工作台随着历史消息、系统提示、各类文件摘要不断堆进去真正对当前任务有用的信息比例越来越低。我最早意识到这个问题是在用 AI 重构一个老旧的 Django 服务时模型连续三次把数据库连接配置改错——每次它都说我看一下 settings.py然后对着一个 session 里早已过期的旧版本做判断。后来我手动清空会话、重新只贴关键文件一次就改对了。这就是context-mode即上下文模式这个概念要解决的核心问题它不做别的专门负责管理 AI 工具在项目里的视野范围。你让它只看某个模块它就不会把整个仓库的边角料都塞进窗口你让它只在某个任务里记下临时结论它就不会把这些结论带到下一个任务里干扰判断。现实里有人把它理解成让 AI 记住项目背景其实不完全准确——context-mode 的本质不是延长记忆而是控制视野。大多数人对 AI 编程工具的使用方式是把所有相关文件一股脑喂进去觉得喂得越多模型就越懂项目。但模型的处理窗口是固定的上下文里塞五十个文件和塞五个高度相关的文件后者的输出质量往往反而更高。context-mode 就是在这种多多益善和精挑细选之间给了你一套显式的控制和切换机制。适合读这篇文章的人有三类一是用 AI 助手改大型项目时经常觉得刚开始好用、越用越乱的开发者二是想给团队制定一套统一的 AI 协作规范避免各写各的提示词、上下文浪费严重的 Tech Lead三是对大模型应用原理感兴趣想搞明白为什么同样一个模型换个上下文组织方式效果差这么多的人。2. context-mode 的两种工作模型回放式会话与外挂式感知很多人以为 context-mode 是某个工具独有的小功能其实它是一种通用的设计思想。市面上所有带上下文管理能力的 AI 编程工具底层基本都是两条路线基于纯文本回放构建上下文或者基于工具感知动态提取上下文。两条路线的实现原理完全不同适用场景也完全不一样。2.1 基于纯文本回放的会话上下文这是最简单也最常见的模式。它的工作方式是把用户发送的消息、模型的历史回复、粘贴进来的代码、系统预设的规则文件全部按时间顺序拼成一个长长的文本块每次调用模型时完整带上。你可以把它想象成一个会议录音——会议室里说的每一句话都被原封不动地放给后来参会的人听不管这句话还有没有参考价值。这种模式的优点是实现简单、行为透明你发过什么、模型回过什么都可以随时翻看排查问题非常方便。但它的致命弱点是上下文长度会随时间膨胀。对话进行到第 15 轮时前面 14 轮的反复试探和错误代码还占着大量窗口真正有效的当前目标 当前文件内容反而被挤到边缘。我在实际项目中做过一次统计一段持续 40 分钟的重构对话里模型真正依赖的有效上下文可能只占全部上下文的 30%剩下 70% 都是历史噪声。正因为这样几乎每个基于回放会话的工具都会额外提供一个压缩或总结入口——把前面的对话浓缩成几条要点然后开启新一轮会话。这就是一种朴素的 context-mode 切换从完整回放切到精华摘要。如果你经常手动清空会话、把结论贴到新对话里继续干活你其实已经在用 context-mode 了只是切得比较粗糙。2.2 基于工具感知的动态上下文提取第二种模式更聪明一些。工具不是被动地把所有历史消息堆给模型而是先通过命令行工具比如文件检索、目录树、代码搜索、Git 状态检测去扫描项目再根据模型当前正在使用的文件列表主动决定把哪些内容装进上下文。这个模式下上下文不再是一条持续增长的流水账而是一个按需构建的工作集。打个比分回放模式像把整栋楼的监控录像全部回放一遍让你找线索工具感知模式则像先派几个侦查员去楼里盯着可疑位置专门把关键画面传回来。命令行的定位能力相当于侦查员模型则是看画面的指挥官。这种模式的典型形态是一种作用在目录级别的白名单 焦点机制。你可以给项目根目录维护一份上下文规则类似通用的 AGENTS.md / CLAUDE.md 这类项目规范文件在里面声明哪些目录是核心逻辑、哪些目录是自动生成的产物、模型读文件时应该按什么顺序切入。当模型跳转文件时工具会拿着这份规则去决定该不该读、读多深、读完了保留还是丢弃。我在一个规模约 3 万文件的中型前端仓库里试过开启工具感知模式后单次任务的 token 消耗比无脑全量加载下降了约 60%而且改到第 20 轮时模型依然能准确引用最初的接口定义。2.3 一张表看懂两种模式的差异对比项回放式会话模式工具感知提取模式上下文来源历史对话 用户主动粘贴实时扫描项目 按规则动态抽取上下文长度随对话线性增长相对稳定按任务需要构建抗干扰能力弱旧信息容易污染判断强白名单隔离明显适用场景单文件修改、快速问题解答跨模块重构、大型仓库、多任务并行实现复杂度低几乎零配置高需要维护规则我自己实际用下来的感受是两者不是替代关系而是协作关系。日常改个小 bug回放模式够用一进入跨模块开发就必须切到工具感知模式否则再好的模型也会被陈旧上下文拖垮。3. 实操全流程把一个真实前端项目切进 context-mode概念讲多了容易飘我直接用一个模拟的电商前端仓库来做一遍完整配置。这个仓库有 8 个模块包含 Vue 页面、Node 中间层、一个本地 mock 数据目录和一个自动生成的类型文件目录。目标是让 AI 助手在开发购物车结算页时只关心相关模块不去碰支付回调逻辑也不去读自动生成的类型文件。3.1 第一步先给项目建立上下文地图在配置任何模式之前你得先知道自己项目的上下文长什么样。我最常用的做法是先跑一遍目录树把整体结构拍下来tree -L 3 -I node_modules|dist|.git|build|coverage这一步不是为了给模型看而是为了给你自己看。你需要在几十个目录里圈出哪些是核心源码、哪些是配置文件、哪些是脚手架产物。以电商仓库为例我圈出来的结果是核心源码区src/下的components/、views/checkout/、stores/cart.js接口定义区src/api/checkout.js所有请求都汇到这里本地数据区mock/目录改页面时可以看部署时不看生成产物区src/types/api-auto.ts由后端契约自动生成模型读它纯属浪费无关模块区src/views/admin/和src/services/payment/结算页开发时不需要了解把这几个区域写进项目根目录的上下文规则文件里相当于给 AI 助手发了一张地图。没有这张地图工具感知模式的扫描就失去了指引模型可能会从components/目录里无关组件开始看起。3.2 第二步选定工作模式明确白名单边界结合两种上下文工作模型我通常在项目根目录的规则文件AGENTS.md中写明默认使用工具感知模式按模块聚焦然后定义每个模块的白名单边界。示例片段如下# 项目上下文模式配置 ## 全局默认 - 焦点目录: src/, mock/, public/ - 忽略目录: node_modules/, dist/, src/types/api-auto.ts - 单文件读取上限: 600 行超出部分按函数签名摘要 ## checkout 结算页模块 - 入口文件: src/views/checkout/index.vue - 关联文件: src/stores/cart.js, src/api/checkout.js - 不要主动读取: src/services/payment/callback.js, src/views/admin/**这里的关键是忽略目录要比焦点目录更精确。很多人刚开始配置时只在白名单里写需要看哪些,结果模型确实只看那部分了但它调用的函数依赖了外部模块一执行就报错。我的做法是先允许它读取入口和关联文件等它跑出需求再按需扩大范围而不是一上来就放开全仓库的读取权限。3.3 第三步会话内的上下文约束指令项目级文件能管住默认行为但每个具体任务还需要一条会话级指令来锁定当前 focus。我的惯用开头是开启 context-mode模式: 聚焦焦点: 结算页。 任务: 修复结算金额在满减活动下计算错误的问题。 限制: 只读取 checkout 模块相关文件其他模块只允许查看接口签名不允许修改。这一句话同时做了三件事声明模式、声明目标、声明边界。模型拿到这句话后会过滤掉大部分无关文件只保留购物车状态管理、结算金额计算、接口请求三个上下文组块。实测下来同样的需求我在不开启 context-mode、只贴两三个文件的做法对比下出错率大概下降了 70% 以上。3.4 第四步持久化记忆与上下文压缩真正的生产项目不是单次对话就能搞定的。今天改结算页明天调满减规则后天可能又回头改购物车。每次重开会话时都要重新贴一遍规则显然不现实。所以我会设计一套永久记忆 短时记忆的上下文组合。永久记忆沉淀在项目级的AGENTS.md和docs/context/目录下的模块说明文档里由我手动维护记录的是不会频繁变化的事实比如模块职责、核心函数位置、约定命名方式。短时记忆则依赖 context-mode 提供的会话摘要能力——每轮任务收尾时让模型生成一份最终结论记录包含改了哪些文件、每个文件改了哪几块逻辑、留下了什么 TODO、下次续接时应该从哪里开始。例如做完结算页金额修复后我让模型生成一条摘要记到docs/context/checkout-session.md里 结算页金额修复 2025-06-18 起因: 满减条件判断使用了裸比较未考虑优惠券叠加 改动: - src/stores/cart.js: 新增 calcDiscount 函数统一算价 - src/views/checkout/index.vue: 调用 calcDiscount 替换内联算式 关联风险: mock 数据里 price 字段为字符串建议统一转 number 续接建议: 下一步可重构优惠券模块让折扣规则可配置化有了这个文件下次再让模型开发优惠券模块时只需要把这份摘要塞进新会话的上下文它就能快速接上完全不需要重新翻一遍旧代码。这一步就是上下文压缩的精髓——把 40 轮对话压缩成 6 行有效结论token 省了准确性还高了。3.5 完整示例一次对比实验的真实数据我用同一个任务在两种模式下各跑了一遍任务内容是给结算页加一个优惠码输入框并校验优惠码有效性。回放模式下我直接把结算页相关三个文件全量贴给模型让它一次性改完context-mode 下我维护好了上文所述项目级规则设置焦点目录为 checkout 模块让工具按需读取。结果对比如下指标回放模式全量粘贴context-mode按需读取首次正确率改完出现 3 处明显错误第一次编译通过上下文 token 消耗约 5.2 万约 1.8 万修改文件数量5 个含 2 个无关文件2 个后续追加需求时旧上下文污染严重清了会话重新来摘要里直接续接无污染token 消耗的数字会根据模型和工具实现有浮动但正确率和污染程度的差距是普遍存在的。这也是我把 context-mode 当作项目标配而不是锦上添花功能的原因。4. 踩坑记录我遇到的五个 context-mode 典型问题工具再好配置不当照样翻车。以下五个问题是我在不同项目里真实踩过的每一个都花了不少时间排查。如果你配置 context-mode 之后发现效果更差了大概率命中其中之一。4.1 旧上下文残留导致模型自相矛盾现象是第一个任务让模型读了老版本的支付模块第二个任务切到新的结算模块时模型还是会时不时引用老版本支付模块里的函数名。我检查后发现工具感知模式并没有我预想的严格隔离它采用的是一个类似引用的机制——新任务构建了新的上下文但旧任务的关联片段仍然被部分保留在内部缓存里模型在模糊判断时会去翻这些旧碎片。解决办法有两个一是每次切换任务时强制清理会话并重新生成摘要而不是基于旧会话继续追加二是给每个任务的会话标注明确的生命周期task 结束后就把对应目录从上下文白名单中摘除。做电商仓库时我遇到的旧上下文污染就是因为在checkout 模块任务里手动查看过payment目录的接口后来再切到购物车任务时模型总是试图调用payment模块的一个已废弃回调函数清掉会话后问题立刻消失。4.2 白名单设置过宽工具狂读无关文件有一次我为了省事把整个src/目录都写进了焦点区觉得反正模型会按需读。结果工具感知模式的扫描器还是忠实地把src/views/admin/下二十多个管理后台页面都扫了一遍美其名曰建立全局索引。单次任务的预处理 token 直接翻了三倍而且扫描结果还把模型带偏了——它误以为管理后台的权限模型也是结算页的一部分。复盘之后我把白名单改成了入口文件 关联文件 按需扩展三层结构并明确指定忽略**/admin/**。扫描范围和判断准确率立刻回归正常。这条经验很便宜但很值钱白名单不是越大越好它更像一个路由表只负责告诉模型该往哪走而不是把每条路都先走一遍。4.3 上下文压缩把关键决策记录剪掉了利用摘要机制压缩上下文时我犯过一个新手错误让模型自己决定摘要里保留什么。结果好话说尽它把修改了哪些文件记得很清楚却把最关键的为什么不能直接用某个第三方库这个决策原因给压缩没了。等下一次会话接着改时模型又重新用了那个被我否掉的方案前功尽弃。现在我给摘要设了一个固定模板强制要求包含四项决策背景、被否方案及原因、最终改动、遗留风险。那几条看似无用的被否方案及原因恰恰是防止模型走回头路的最重要信息。你可以把摘要文件里的格式直接 copy 过去用实测非常管用。4.4 根级上下文与模块级上下文互相打架这是多模块项目里最容易遇到的坑根目录的AGENTS.md写着全局默认忽略 admin 模块而src/views/checkout/AGENTS.md里为了结算页开发又写着需要读取 admin 模块的权限配置做联调参考。两条规则冲突时不同工具的生效策略还不一样有的后读覆盖先读有的直接报错停下。我的建议是建立一个 n 级目录只允许有一个权威规则的约定。根级规则只写全局不可变的东西比如忽略 node_modules、不修改类型文件所有模块相关的规则下沉到具体模块目录里并在模块规则开头写明它覆盖根级规则的哪一条。没有这份约定conflict 的排查成本会比省下的 token 还高。4.5 误以为 context-mode 能替代真正的架构设计这个坑不是工具的问题是使用心态问题。有些同事配置好 context-mode 后把 AI 助手当成能读懂的架构师让它一口气重构几个模块之间的依赖关系。结果模型确实忠实地只读了白名单内的文件但它的判断跳不出白名单——它看不到外面那个早就耦合成一坨的全局状态管理所有重构方案都是在局部视图内做的一落地就炸。context-mode 能帮你控制视野但不能帮你扩大视野。真正做架构级改动时我反而会把白名单暂时放宽优先读取架构设计文档和核心抽象层再回到具体模块。它不是万能药只是一把好用的手术钳切哪、怎么切还得靠你的判断力。5. context-mode 的进阶玩法与使用边界当你把基础配置跑顺之后context-mode 能玩的花样其实不少。这里分享三个我亲测有效的场景以及一个我认为非常重要的关闭时刻。5.1 用 context-mode 做多任务并行隔离我以前不敢让 AI 同时处理多个问题因为会话上下文一混就乱。后来利用工具感知模式的目录级隔离能力我把不同任务绑定到不同焦点目录里——任务 A 只读checkout/任务 B 只读payment/两个会话完全独立互不干扰。需要它们协作时再把 A 的会话摘要插入 B 的上下文让 B 知道 A 的结果但看不到 A 的中间过程。这相当于给 AI 助手做了一套多进程隔离系统。在提交代码时A 任务和 B 任务的改动也能分别打包、分别 review减少互相牵连。我一度用这个模式同时跑三条业务线的改造只要不共用目录几乎没出过上下文错乱的问题。5.2 设置上下文衰减与轮换策略长周期项目里同一个模块会经历需求变更、重构、回滚多个阶段。如果上下文里永远保留最早期的决策反而会误导当前开发。我引入了一个简单的时间衰减机制每周一检查docs/context/目录超过两周没有被引用的模块摘要就显式标记为历史上下文新会话默认不加载只在模型明确需要时才按路径读取。这么做的好处是防止项目里到处躺着过期结论。有个很典型的例子优惠券模块上个月做过一次规则重构对应的摘要文档仍然躺在 context 目录里。这个月改结算页时如果工具傻乎乎地把优惠券摘要也加载进 checkout 任务的上下文模型就可能沿用旧规则。衰减机制是给上下文做定期清理和给代码库做定期垃圾回收一个道理。5.3 context-mode 对新人协作的价值团队里引入 AI 助手时最头疼的不是模型能力而是大家各自用的方式不一样。有人喜欢全部贴文件有人只让模型看单个文件产出质量和排查成本完全不可控。以 context-mode 项目级规则文件作为统一入口相当于给团队的 AI 协作定了一份 SOP。新人入职后只需要先读根目录的AGENTS.md按模块规则开启会话就自动获得和资深成员差不多的上下文视野。相当于给团队加了一双可以横向复制的项目眼镜。交接时最常出现的代码看得懂但摸不准哪些能改的问题会被显式规则迅速消解。5.4 有些时候应该果断关掉 context-mode最后说一个重要结论context-mode 不是任何时候都要开。我通常会在两类场景里显式关闭它。第一类是探索性问题比如这个仓库里有没有某个隐藏的配置项或这段报错信息在项目里有哪几种解法的迹象。这种开放式搜索恰恰需要模型看到更广的上下文白名单反而会挡住答案。第二类是代码评审之前我会把关键改动文件直接贴在模型面前让它在不依赖扫描的情况下做一次全量逻辑审查防止焦点目录的既有印象影响它对改动风险的判断。另外一个反直觉的经验当模型开始频繁主动请求读取某些文件时往往说明当前焦点配置不对劲。上下文健康状态下它应该只在任务推进时按需补充文件如果老是在问可以读一下 xxx 吗多半是白名单缺了核心模块或者上一轮上下文已经被无关内容淹没。这五年做 AI 辅助开发我最深的体会是模型的能力只决定答案质量的上限上下文的管理却决定你能不能触及这个上限。context-mode 就好比给模型戴上的一副适当变焦眼镜——该看宏观的时候看宏观该聚焦细节的时候聚焦细节比一双永远长焦的眼睛好用太多。你现在就可以挑一个你个人维护的中型项目花半小时配置一份项目级规则文件再跑一轮真实任务试试。相信我对比之下你会回来给这半小时点赞。