最近一段时间，我的主力工作流从“自己写代码+AI补全”切换成了“AI写主体+我review”。切换之后最先崩溃的不是准确率，而是AI的“记忆”。我手里同时维护着三个功能分支，经常刚聊完feature A的上下文，转头就要处理bugfix B，AI在同一个对话窗口里把两个分支的代码搅在一起，给我生成了根本不存在的函数。后来我把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 "目标：新增退款接口，保持与原订单状态兼容"处理完一部分，切到B：
context-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": "ctrl+alt+c", "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.md，AI就会按这份文件里的摘要来理解任务。注意，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.ts，AI把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-mode
context-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两个分支之间横跳，如果忘了切profile，AI就会用上一分支的代码上下文来回答当前任务。所以我写了一个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，每次开新对话前带上去，效果都会不一样。等我把分支绑定这套玩法在更多项目里跑一段时间，再来分享更细的数据。
