最近一段时间我的主力工作流从“自己写代码AI补全”切换成了“AI写主体我review”。切换之后最先崩溃的不是准确率而是AI的“记忆”。我手里同时维护着三个功能分支经常刚聊完feature A的上下文转头就要处理bugfix BAI在同一个对话窗口里把两个分支的代码搅在一起给我生成了根本不存在的函数。后来我把context-mode当作一个正式项目来对待围绕它搭了一套上下文调度流程这个问题才算被按住。这里说的context-mode既指我自己封装的一小套CLI和配置文件也代表一类很值得推广的AI编程工作方式。这篇文章不打算讲大道理直接从我踩过的坑出发聊聊它到底怎么用、什么时候用、什么时候千万别用。如果你正在用AI写代码且经常觉得它“忘性大”“答非所问”这篇文章应该能给你一些可以直接抄的解法。1. AI编程里最容易被忽略的成本上下文失忆1.1 为什么模型窗口越来越大代码却越来越“飘”现在AI编程工具的窗口动辄几十万token理论上能塞下整个代码库但实际用起来根本不是这样。我自己就做过一个测试把某个模块的10个文件一次性丢进对话让AI帮我重构其中3个文件。结果前3轮还好到第5轮AI开始把第2个文件里的旧接口名和第7个文件里的新接口名混着用最后给出的代码别说跑起来连语法上都有未定义的变量。问题不在于模型能力而在于“有效上下文”这个概念。窗口大不等于AI真的能一直保持对每个字的注意力对话越往后、塞进去的材料越多模型就越容易“只记得最近的消息和最开头的那份说明”中间那一大堆文件反而变成了背景噪声。更麻烦的是当你在同一次对话里切换任务比如从改A模块跳到改B模块时AI并不会主动清空A模块在它脑子里留下的“惯性”它会用A模块的代码风格和接口习惯去回答B模块的问题结果自然驴唇不对马嘴。这种“失忆”不是偶然发生的而是长上下文推理中的常见现象。模型在处理长文本时会不断更新注意力分布早期信息如果没有被反复强化权重就会越来越低。你可能会觉得“我才发了三句话AI应该还记得”但如果你这三句话前面还有两个小时的讨论和大量文件内容那三句新指令可能压根排不进重点区。所以我一直认为AI编程工具里真正的稀缺资源不是token数量而是“当前焦点”。谁能把焦点管理好谁的生成质量就能稳定很多。1.2 context-mode管的不是提示词是“调度层”正因如此我给自己的AI工作流加了一个轻量调度层名字就叫context-mode。它要解决的核心问题只有一个让AI在正确的任务里看到正确范围内的信息并且不被上一个任务的信息干扰。很多人第一次听到这名字以为它是某种prompt模板或者“上下文拼接工具”其实都不是。它更像一道闸门在AI和项目文件之间决定哪些内容能进入模型视野哪些内容先留在仓库里待命。设计上context-mode分成两层。底层是“上下文仓库”用来保存不同的上下文快照比如每个任务的描述文件、涉及文件清单、当前进度、需要遵守的约束条件顶层是“切换器”提供类似use profile、push、pop、peek的操作让你在不同快照之间随时切换。它不是提示词模板也不直接修改你的代码。如果AI是一个需要长时间集中注意力的助手context-mode就是办公桌上那个带分隔层的文件架你用哪个任务就抽出哪个抽屉而不是把桌上所有纸全堆在它面前。相比手动复制粘贴它最大的区别是把“该看什么”从隐形知识变成了显式配置。以前我得自己记住“这个任务要贴哪几个文件”“上次改到哪了”“哪些文件不能动”现在这些全部写进profile里既不用靠脑子团队里其他人也能复用同一套规则。在动手写配置之前我先说清楚一个原则context-mode的价值不在于“把更多内容塞给AI”而在于“减少AI需要关心的内容”。很多人一听上下文管理第一反应是“那我干脆把所有文档都喂进去”这恰恰是最大的误解。后面所有配置和用法你都会看到我反复在做减法。2. 拆开看context-mode的两种工作模式会话级和项目级2.1 会话级把AI的短期记忆做成可切换的抽屉我在第一版实现里只做了会话级的上下文栈。核心逻辑很简单每个任务对应一份独立的上下文记录里面包括任务目标、涉及文件、当前进度和注意事项。通过类似push/pop的操作可以在同一个编辑器窗口里来回切换任务。为什么先做会话级因为我发现日常开发里最让人抓狂的不是模型蠢而是你已经跟它聊了半天A任务临时插进来一个B问题它居然还会拿A任务的前提来回答B。举个例子。假设我在改一个支付模块手上同时有一个“增加退款接口”的任务A和一个“修复汇率计算精度”的任务B。旧办法是在同一个对话里跟AI说“现在回到退款那件事”但AI的注意力并不会因为这句话就自动清空B的残留信息。使用context-mode之后我会先执行context-mode push refund-task context-mode add docs/payment/refund.md src/payment/refund.ts context-mode note 目标新增退款接口保持与原订单状态兼容处理完一部分切到Bcontext-mode pop context-mode push fx-precision context-mode add src/payment/exchange.ts tests/payment/exchange.test.ts每次push都会生成一份新的上下文“抽屉”而pop会把当前抽屉存回历史避免污染下一个任务。实测下来AI串线的频率大幅下降因为它看到的始终是当前任务的完整目标而不是上一任务的残余。会话级模式还支持一个list命令可以看到当前有哪些未关闭的上下文context-mode list这个列表我一般当作任务清单用。如果发现同时有超过三个活跃上下文说明当前任务切得太碎应该考虑合并或者先关掉一部分。另外每次note命令后面写的内容不需要长篇大论一两句话把“目标、边界、验收标准”说清楚就够了。AI对明确指令的依赖远大于对长故事的依赖写太多背景反而分散它的注意力。2.2 项目级用一份配置文件声明AI该看什么会话级适合临时切换但每次手动add还是有点麻烦。于是第二版加了项目级配置用一份.contextmode.yaml来定义不同场景的profile。这个东西才是日常效率提升的关键。先看一份最基本的配置version: 1 profiles: default: description: 日常编码适合大多数任务 include: - README.md - docs/architecture.md - src/utils/types.ts exclude: - node_modules - dist frontend: description: 前端页面改动 include: - src/components/** - src/styles/** - docs/ui-guide.md exclude: - src/server/** >context-mode use frontend context-mode use>npm install -g your-org/context-mode如果你不想装npm包纯shell版本也能跑核心就两个函数读配置、生成上下文摘要。安装完先初始化context-mode init这个命令会扫描项目根目录自动识别README、package.json、tsconfig.json、源码目录等常见信息生成一份默认配置。接着可以跑这两个命令context-mode scan context-mode treescan会重新扫描项目结构tree则会把当前加载的上下文来源以树状打印出来。我强烈建议每次换人review之前跑一下tree看看AI实际能看到哪些文件——很多时候你以为它没看到其实它看了也有时候你以为它看到了其实根本没加载进去。这种信息差是代码review最大的隐患因为你会默认AI看到了全部代码而它实际只处理了你丢过去的那一小部分。另外context-mode validate这个命令我每次改完配置都会跑一遍。它能检查include路径里有没有写错的globbing模式、有没有重复匹配、有没有引用了不存在的文件。这个命令救过我很多次尤其是当配置文件被人在review时随手改了两行之后。validate的输出尽量保持无警告状态别把警告拖到下次再处理因为一旦警告多了真正重要的错误反而会被淹没。3.2 一份可以抄作业的profile配置拿我最近在维护的一个内部中后台项目举例这套配置直接放到项目根目录就能用version: 1 project: name: ops-console stack: - typescript - react - vite - express conventions: - 所有API返回格式统一为 { code, data, message } - 组件文件使用PascalCase非组件工具函数使用camelCase profiles: default: include: - README.md - docs/architecture.md - docs/api-conventions.md - package.json exclude: - **/*.test.ts - node_modules feature: include: - src/features/** - src/shared/** - docs/feature-guide.md exclude: - src/legacy/** bugfix: include: - src/**/*.ts - tests/** exclude: - docs/** - *.md注意看细节project.conventions这一栏非常关键。它不加载任何文件但会被拼进上下文摘要里作为AI生成代码时必须遵守的规范。如果没有这一栏AI只会模仿你给的文件风格但不会主动套用团队约定。每个profile都尽量只带一个业务域的代码。feature和bugfix的边界很清楚避免任务之间互相串味。bugfix profile特意排除了所有文档因为修bug时AI最容易被设计文档带偏它应该优先看测试和实现。文档里写的往往是“理想设计”而bugfix需要面对的是“当前实现”两者对不上时AI就会开始打圆场生成一些看似合理但实际无效的代码。这里分享一个实用技巧在profile里设置compress: true可以让context-mode把长文件自动裁剪成只包含类型定义、函数签名和关键注释的精简版本。对于几百行的文件来说这个功能效果立竿见影——上下文占用小AI反而看得更清楚。压缩不是简单截断它会保留函数头、类型声明、TODO和依赖关系去掉大段实现细节。AI真正需要的是“知道有哪些函数、各自什么签名、之间怎么引用”而不是把整个函数体的每一行都背下来。3.3 接入AI编辑器与IDE快捷键CLI只是底层实际使用频率最高的入口是编辑器。我主要用VS Code在settings.json里加一组快捷键[ { key: ctrlaltc, command: workbench.action.terminal.sendSequence, args: { text: context-mode use frontend\n } } ]更顺手的做法是如果编辑器里的AI助手支持外部文件引用可以直接让context-mode生成一份context.md然后在对话中引用它context-mode export --output .context/context.md我用的是Continue插件对话框里输入context/context.mdAI就会按这份文件里的摘要来理解任务。注意export生成的文件要加入.gitignore它本质上是临时产物不该进版本库。这也是我在踩过坑之后才养成的习惯刚开始我没忽略它结果每次切换分支都会产生大量diff噪音review的人以为是谁手误改错了文件白白浪费沟通成本。如果你用的AI助手不支持文件引用也可以直接把export出来的摘要复制粘贴到对话开头。效果接近只是少了自动更新的便利。反正核心目标是让AI在生成代码前能先看到一份“当前任务说明书”而说明书这种文件本来就不该写得又臭又长。4. 实测复盘跨文件重构和多任务并行到底省了多少事4.1 场景一把一个工具文件拆成三个模块前阵子我需要把src/utils/format.ts这个600行的工具文件拆成date.ts、number.ts、string.ts三个模块并且要更新所有引用它的文件。这个任务放在以前我会把format.ts和所有引用了该函数的文件全丢给AI让AI“看着改”。结果就是改完number.tsAI把date.ts里的formatDate的引用路径也改了最后编译错误一大堆。这次我用context-mode建了一个refactor-format的profile内容只有四样目标说明拆分方式、新文件命名规则、不能改动公共API签名format.ts的完整代码引用点清单grep -rn utils/format src的结果一段明确指令“每次修改一个文件确认该文件不再引用旧路径后再进行下一个文件”AI生成的改动非常规矩它严格按照引用点清单一个个改没有多余发挥。整个重构花了两小时其中大部分时间是我在review真正返工只有一处——某个测试文件里的mock路径没更新。对比之前同样规模的重构需要大半天这个效率变化是肉眼可见的。事后我想了想这次成功的关键不是AI更聪明了而是context-mode把“任务边界”定义得非常清楚。AI知道哪些文件是这次任务允许动的哪些只是参考资料它就不用自己去猜自然也不会扩展出一些无关的破坏性改动。4.2 场景二同一个对话窗口里并行处理三个任务我平时有个坏习惯一个对话窗口可以从修bug聊到加需求再聊到代码review。以前的AI到后半段已经完全失去方向经常把“test”“fix”“refactor”混着来。context-mode帮我把这个习惯改成了严格的任务切换。具体操作是每个任务进来先push一个独立上下文任务结束时用context-mode export把这次对话的摘要存到.context/history/下再pop释放。三个任务并行时AI始终只看当前任务的profile历史记录对AI不可见。这里有个数字对比我记录过差不多两周的数据包含9个任务对比项手动管理上下文使用context-mode平均每个任务跟AI“解释背景”的时间15分钟3分钟需要重写AI生成内容的次数约40%约15%任务间互相污染的出错次数每周3-4次每周不到1次必须承认这个对比不算严格对照实验但趋势非常明显问题主要出在上下文切换而不是模型能力。以前我总觉得AI写了烂代码是模型不行现在看很多时候是我们在输入侧就没给它一个干净的“工作台”。模型本身不是为“一心多用”设计的它会把前面任务里的一些偏好带进新任务而人类对这种干扰又特别不敏感。你只有在看到AI把A任务的命名风格用到B任务里时才会意识到污染已经发生了。4.3 反例什么时候不应该开context-modecontext-mode不是万金油。某些场景下开它反而拖慢速度最典型的就是单文件小函数的编写、临时问答或者读一段报错日志。这种任务上下文很小AI直接看当前文件就够了你给它套一个profile反而是画蛇添足。我的判断规则很简单问自己一个问题这个任务里AI如果只看到当前打开的文件会不会凭猜测补全如果会就开profile如果不会就不开。改一个函数的返回值类型、加一个if判断、给组件加个样式这些都不需要context-mode。只有跨文件、多阶段、或者涉及项目规范时才轮到它出场。我见过有人把context-mode做成“打开任何项目就强制加载全部文档”的工具结果每个对话都要等上下文摘要生成半天生成质量也没提升。正确的用法是让它处于“待命”状态默认profile只做兜底复杂任务才手动激活特定profile。5. 踩坑记录context-mode最常见的三个翻车点5.1 重复加载导致同一份代码出现两个版本第一个坑也是我最早踩的profile里的include路径写得不够精确导致同一个文件被加载两次而且两份内容版本不同。当时的情况是我在include里写了src/components/**同时又在下一个profile里写了src/components/Button/index.tsx。默认profile和feature profile叠加时AI在同一份上下文里看到了Button组件的新旧两个版本生成代码时随机选一个结果就是一段代码里同时出现两个互不兼容的props定义。排查方式用context-mode tree查看实际加载的上下文来源会看到同一个文件出现两行。修复方式有两种一种是改用精确路径另一种是在profile里加dedupe: true。现在我的所有profile都默认开dedupe这是唯一一个我建议无条件开启的选项。如果你发现AI生成的代码里出现了“某个符号存在两个不同定义”这样的奇怪错误优先怀疑上下文里有重复文件。这一条排查经验放到任何AI编程工具里都适用。5.2 频繁切换反而把AI的注意力切碎了第二个坑属于使用习惯问题不是context-mode的bug而是我自己的误操作。我一开始把profile切成常态写5分钟代码切一次结果AI每次都像失忆一样重新理解任务产出质量反而下降。后来我想明白了context-mode的切换应该发生在任务边界而不是时间碎片里。如果只是临时看一眼另一个模块用context-mode peek profile它会把目标profile的摘要作为只读附加信息展示而不会替换当前上下文。peek完之后当前任务的主上下文仍然还在AI不会“串台”。这里有个细节peek加入的附加信息会被模型当作次要内容权重低于主上下文所以不用担心喧宾夺主。不过要注意peek次数也别太多一次任务里超过两三次主上下文的注意力还是会受影响。这跟人工作时的状态很像你可以在专心写代码的时候瞄一眼旁边的资料但每次瞄完都需要几秒钟重新进入心流AI也是一样。所以能用peek就不要用use能切一次就不要切三次。5.3 塞得太满重点被淹没第三个坑是“上下文完美主义”。我一度想把整个项目的文档、类型定义、设计稿全塞进profile觉得这样AI一定更懂项目。结果恰恰相反AI生成代码时反而经常忽略最关键的几个文件给出的答案非常平庸。原因是上下文越长模型对每个token的注意力越稀薄重要信息反而被淹没。我现在给profile定了一个硬约束一个profile最多包含5个核心文件加1份说明文件如果超过就拆成子profile用context-mode include按需临时追加。简化后AI生成质量的提升立竿见影。我甚至觉得任何长上下文工具的使用者都应该先做减法再做加法。补充一点如果确实需要给AI一大段代码库信息可以用compress和摘要工具把文件先压成大纲再放进去而不是直接丢原始文件。压缩后的信息保留关键结构去掉实现噪音模型反而更容易抓住重点。6. 几个让我用得越来越顺的小技巧6.1 把context-mode和Git分支绑定在一起最实用的一点让profile跟着分支走。我经常在feature/payment和fix/exchange-rate两个分支之间横跳如果忘了切profileAI就会用上一分支的代码上下文来回答当前任务。所以我写了一个Git post-checkout钩子自动切换profile#!/usr/bin/env bash branch$(git symbolic-ref --short HEAD) case $branch in feature/*) context-mode use feature-${branch#feature/} ;; fix/*) context-mode use bugfix-${branch#fix/} ;; main|develop) context-mode use default ;; esac放在.git/hooks/post-checkout后每次git checkout完成都会自动切上下文。如果你用的是direnv或者类似工具也可以在目录进入时触发同样的逻辑。这个钩子的价值不仅是省事更重要的是避免“串分支”这类低级但危险的错误。如果你的分支命名跟profile不一致可以在钩子里加一个映射表或者干脆约定新分支创建时同步创建同名profile。后者我们团队试过成本很低收益很稳定——大家再也不用口头提醒“你现在切到bugfix分支了记得切上下文”。6.2 用模板和脚手架自动生成项目上下文为了让新项目不用从零写配置我在context-mode init里内置了自动扫描逻辑读取package.json的scripts、tsconfig的paths、README里的项目说明生成初始profile。生成后我只需要再补两样东西——项目约定和“禁改区域”。“禁改区域”是我的profile里一个重要字段constraints: do_not_touch: - src/generated/** - src/config/production.ts must_not_rename: - src/utils/legacy.ts这个字段会被拼进上下文摘要AI看到后就不会自作主张去动这些文件。对代码生成工具来说明确告诉它“哪里不能碰”有时候比告诉它“要改哪里”还重要。之前我在没有约束字段的情况下让AI重构一个模块它顺手改了同目录下另一个无关文件的import差点引发连锁错误。从那以后每个涉及重构的profile我一定会写清“不能碰”的边界。6.3 团队共享和新人上手的低成本方案context-mode的配置文件完全可以提交到仓库团队里每个人共用一套。新人入职时执行context-mode init和context-mode use default就能拿到当前项目的技术栈说明、架构文档和编码约定比读半天Wiki快得多。不过团队场景必须注意一点profile文件要由固定的人维护否则很容易出现“每个人往里面塞自己关心的文件”最后profile变成一个大杂烩。我们团队的规则是默认profile只放所有任务都需要的稳定信息临时需求一律通过context-mode include动态追加不写进配置文件。这样既能保持配置稳定又保留了灵活性。另外.context/history/这种个人历史目录建议加入.gitignore不要让每次任务的临时记录变成仓库噪音。团队只共享配置和模板不共享个人上下文历史。写到这里我其实把最近两周跟context-mode打交道的经验都倒干净了。个人体会是它解决的不是“让AI更聪明”而是“让AI不被乱七八糟的旧记忆拖累”。如果你也在用AI编程助手并且遇到那种“明明窗口挺大怎么越聊越蠢”的情况我建议先不要急着怀疑模型试试从上下文管理入手——哪怕不装任何工具只是把每个任务要用的文件、目标、边界写进一个独立的markdown每次开新对话前带上去效果都会不一样。等我把分支绑定这套玩法在更多项目里跑一段时间再来分享更细的数据。