很多人用AI辅助编程工具卡在最窝火的一点给AI的上下文太少了它答得驴唇不对马嘴给太多了它又“选择性失忆”要么忽略关键约束要么把无关代码也读进去生成一堆花架子。我折腾了几个月试过各种提示词模板和“高级”玩法最后沉淀出一套叫context-mode的上下文管理模式专门解决AI编程时“喂什么、喂多少、怎么切换”的问题。这套方案不依赖特定工具不写玄学咒语就是一套可落地的上下文管理规则适合天天跟AI结对编程的人参考。我先把结论放前面AI编程的质量很多时候不是模型能力决定的而是你给模型看的上下文决定的。context-mode的核心思想是——把上下文分成几种固定模式像换镜头一样按任务切换让AI始终保持在“刚刚好”的信息密度下工作。下面我详细拆解这套方案的设计思路、实操配置、踩坑记录和效果对比。1. 为什么context-mode值得做AI编程的上下文与token经济学1.1 上下文不是越多越好存在“降智曲线”先说一个很多人没意识到的现象大语言模型处理上下文时并不是信息越充分、回答就越准确。我实测过几次给AI塞一个完整的大型项目几万行代码都读进去它的生成质量反而不如只给它几百行高度相关的代码。原因有二一是注意力机制在超长上下文下会稀释关键信息模型容易“忘记”中间段落的约束二是无关代码自带噪声AI会猜测哪些才是重点猜错了就跑偏。我管这个现象叫“降智曲线”。不是说模型变笨了而是你的上下文喂法让它的有效智力变低了。我拿同一个Bug修复任务做过对比不筛上下文AI给出了三个候选方案其中两个不适用于当前项目版本只给核心文件AI直接给出可合并的具体补丁。差距非常明显。所以“上下文越全越好”这个直觉在AI编程场景下是错的。正确做法是让AI收到一份“经过筛选的、结构化的、与当前任务强相关”的上下文。这就是context-mode要解决的核心问题。1.2 token预算喂什么是核心怎么喂是技巧聊上下文绕不开token。现在的模型窗口动辄几十万token听起来很大但你算一笔账就明白了一个中型项目的目录树加关键文件可能就占几万token全量塞进去后模型能做深推理的余地就被挤没了。更现实的问题是接口费用和响应时间——上下文越长单次请求越贵、出字越慢。我建议把上下文当成一份“预算”而不是一个“垃圾桶”。给AI喂内容前先问自己三件事当前任务需要知道哪些文件这些文件里哪几个函数或定义真正影响输出哪些信息属于背景噪音可以省略这三问就是想清楚“喂什么”。至于“怎么喂”涉及信息的排列顺序、格式和触发方式context-mode就是把这套流程固化下来。从设计角度讲一个健壮的上下文管理模式至少要满足三个要求可复现不同任务都能套用、可测量知道当前上下文大概有多少token、可切换该细的时候细该粗的时候粗。2. context-mode的三种核心模式设计2.1 全局模式global先问方向再动手全局模式解决的是“这个项目里有没有类似实现”“新功能应该放在哪个模块”这类方向性问题。这时候AI需要看到项目的整体结构但不需要看每个文件的细节。我通常给AI喂的是项目目录树去掉vendor和缓存目录、README或架构文档、关键入口文件的文件名列表。重点在于让AI了解“有什么”而不是“具体是什么”。实测下来40层深的目录树配合一行简要说明比贴十个源代码文件更有效。配置示例## context-mode: global 你正在处理的是一个全栈项目。 请先输出项目的整体结构分析包括 1. 各目录的职责 2. 新增功能应放在哪个模块 3. 可能受影响的历史文件 不需要阅读具体源文件除非用户要求。2.2 聚焦模式focus把AI锁在指定文件里聚焦模式是我日常用得最多的。它的使用场景是改Bug、加功能、重构单个模块。此时AI需要读的就三块内容目标文件本身、目标文件直接依赖的接口定义、调用目标文件的入口处代码。真正动手时我会先在对话里明确写出“只看这些文件”再把文件内容按依赖顺序排列放进去。依赖顺序比随便粘贴重要得多——先放被调用的接口定义再放调用方最后放目标文件AI理解调用关系的准确率会高很多。配置示例## context-mode: focus 只允许阅读用户指定的文件。 请按以下顺序分析 1. 被依赖的接口定义 2. 用户明确给出的目标文件 3. 调用目标文件的上层代码 忽略其它文件不要主动扫描整个仓库。 如果发现信息不足只需要说明需要补充哪个文件。2.3 精简模式slim忘记代码只聊逻辑有些场景其实不需要AI看任何代码。比如你只是想讨论一套技术方案、让AI给你解释某个概念、或者梳理一段业务逻辑。这时候如果强行给它塞代码反而会让回答变啰嗦。精简模式的原则是只靠对话历史和用户描述干活。我会告诉AI“不要读取任何文件”把它当成一个纯粹的讨论对象。别小瞧这个模式很多人在AI前面写Prompt小作文其实就是舍不得“喂代码”这个动作。你让AI纯靠逻辑推理帮你理清思路效果往往更清爽。配置示例## context-mode: slim 不要读取项目中的任何文件。 仅基于对话内容和用户提供的代码片段进行回答。 如果问题涉及具体实现细节明确询问用户不要自行假设。2.4 规划模式plan写代码前先交方案规划模式适合大一点的需求跨多文件改动、引入新依赖、重构模块边界。这类任务如果直接让AI生成代码很容易改一处崩三处。正确姿势是先让它做设计再让它动手。plan模式我会强制AI按固定模板输出现状分析→改动方案→涉及文件清单→风险点→测试计划。AI在输出方案的过程中会自己检索需要的文件这时候上下文可以放宽一点但格式必须严格收敛。等方案确认后再切换到focus模式去实现。## context-mode: plan 不要直接修改任何文件。 用户会描述一个需求你需要先输出完整设计方案格式如下 - 现状分析需要阅读哪些文件 - 改动方案具体到文件与函数 - 涉及文件清单 - 风险点与回滚方案 - 测试计划 方案经用户确认后再询问是否进入focus模式进行实现。3. 落地实操我在工具链里配置context-mode3.1 把规则文件当配置文件管理而不是当提示词刚开始我是把模式写在系统提示词里的结果发现两件事让人崩溃一是切换模式时要复制粘贴一大段文字烦二是规则写太多后AI反而开始“选择性遵守”只按字数最少的部分执行。后来我改成把规则文件当成项目的“配置文件”来管理每个模式对应一个独立的Markdown规则文件。项目结构大概是这样的.claude/ ├── rules/ │ ├── global.md │ ├── focus.md │ ├── slim.md │ └── plan.md └── context-mode.md然后在context-mode.md里写清楚每种模式的触发词和适用场景再把不同工具对应的规则文件路径告诉AI。这样每次切换模式只要在对话里输入触发词AI就知道该执行哪一套规则。# context-mode 使用说明 本项目内置四种上下文模式 - context:global 模式用于方向性提问见 rules/global.md - context:focus 模式用于修改具体文件见 rules/focus.md - context:slim 模式用于纯逻辑讨论见 rules/slim.md - context:plan 模式用于跨文件改动前的方案设计见 rules/plan.md 默认使用 focus 模式。 用户说出 context:xxx 时切换为对应模式并加载对应规则文件。3.2 不同AI工具的具体接入方法我在Cursor、Claude Code和本地用API调用的环境里都跑过这套方案接入方式大同小异但有几个细节值得注意。Cursor环境下把规则文件内容粘贴到.cursor/rules目录或者直接放进.cursorrules文件里即可。这里有个关键操作规则文件里不要只写“建议”要写“必须”。Cursor对规则文件的执行强度很高但如果你在规则里用“可以考虑”“尽量”这种词它就会在长对话中逐渐忽略。我在实测里发现写上“不要主动扫描整个仓库”比写“请减少上下文”管用得多。Claude Code环境下对应的是CLAUDE.md文件。这个工具的特别之处在于它会把规则文件作为项目说明自动加载所以我会把context-mode.md和四个模式文件都放进.claude/rules/里并在主规则里明确指定各模式文件的路径。一旦规则文件中只有context-mode启动说明AI会自动去读取对应的模式文件。如果直接用API做开发思路类似把模式配置做成一个可拼接的system prompt前缀。我在代码里维护了一个字典key是模式名value是对应的规则文本。请求时根据用户指令动态选择前缀拼进system prompt。这样即使用脚本调用模型也能享受模式切换的收益。3.3 上下文压测用真实任务对比效果配置完不是终点得压测。我自己做了个小实验选了三类任务修一个TypeScript类型报错、给一个Python服务加缓存、分析整个项目的目录结构并建议重构方向。每类任务分别用纯对话不切模式、focus模式、global模式各跑一遍。结果很有意思任务纯对话focus模式global模式修TypeScript报错擦边改完还留下两个隐患直接命中代码干净回答泛泛而谈没定位Python服务加缓存方案能用但没考虑并发给出带锁的实现考虑周全讨论了三种方案但没落地目录结构分析输出很散像是模板没触发文件读取信息不足结构清晰指出了两个被忽视的耦合点从表格里能直观看到不同模式的适用边界。别指望一个模式打天下。真正熟练使用context-mode之后你会在一个任务里主动切换两三次模式——先plan做方案再focus改代码最后slim让AI解释某段逻辑。这种动态切换本身就是上下文管理的一部分。4. context-mode的避坑指南与常见问题4.1 模式失效的几种情况与排查思路规则文件配好了不代表AI每次都乖乖执行。我踩过的坑有四个各写一下表现和排查方向。第一种情况是切换指令被当成普通对话。这通常是因为规则文件里没用“必须”类的强指令导致AI把context:focus理解成“用户随口说的短语”。排查方向检查规则文件里的指令强度改成“用户说出context:xxx时必须切换模式并加载对应规则”。第二种情况是“模式叠buff”。你在全局规则里让它“照顾用户需求”又在focus规则里让它“只看指定文件”结果AI两头摇摆最后还是偷偷扫了仓库。排查方向给模式规则设优先级明确说明“模式规则覆盖普通规则”或者在当前对话里直接强调一次临时指令。第三种情况是切换后AI仍然引用旧上下文。比如你刚从global切到focusAI还在讨论其他模块的文件。这个问题多半是因为对话历史里保留了之前的代码片段。解决方法是遇到重要任务直接开新会话用新的会话加载对应模式不要硬在一个长会话里反复横跳。第四种情况是token被背景内容占满。我遇到过配置好好的AI还是读了大量无关文件一看token统计项目里某个自动生成的配置文件就吃掉了将近三分之一。排查方向给工具配置忽略清单把dist、build、node_modules、lock文件全部排除在上下文之外别让AI有读取这些文件的机会。4.2 大仓库裁剪的实战技巧大项目里最头疼的就是怎么让AI“只看到该看的”。我总结了三招层层递进。第一招是“目录树摘要法”。不要直接丢目录树而是先让AI读目录树然后输出一份“精简版目录摘要”把无关目录标注为忽略项。之后的过程都基于这份摘要展开。相当于先让AI做一次压缩再基于压缩结果做推理有效避免它把几百个文件名都放进上下文里。find . -type d -not -path */node_modules/* -not -path */.git/* | head -80第二招是“接口优先法”。当你需要AI改某个模块时只给它这个模块对外的接口定义类型、函数签名、导出列表不给内部实现。AI对接口的理解通常比看实现更快而且更不容易被细节带偏。等它确认了接口层面没问题再给一小段关键实现。第三招是“最近调用链剪枝”。用git log查看最近改动的文件再结合调用链分析把AI需要读的文件范围缩小到“改动文件直接调用它的文件它依赖的核心库定义”。这种剪枝比手工挑文件靠谱得多。我给一个遗留系统做重构时用这个方法把上下文从八个文件减到三个输出质量反而提升了。4.3 不同任务下的推荐组合速查表最后分享一份我常用的模式组合表遇到任务直接照着选即可。这份表是我跑了两个月项目总结出来的不同团队可能有差异但大方向通用。任务类型推荐模式补充说明新功能放哪个模块global再加一个plan模式输出方案修一个具体的Bugfocus指定文件和依赖文件重构单个函数focus加上核心测试文件跨文件迁移逻辑plan focus先迁移方案再逐个文件落地纯逻辑讨论slim别让AI读代码代码审查focus一次只审查一个模块技术方案选型slim plan先纯聊再出设计大仓库结构梳理global让AI先做目录摘要使用过程中每次切换模式都问自己一句这个任务真正需要的上下文是哪些这句话能帮你避免百分之八十的无效喂料。我个人在实际操作中的体会是context-mode这套东西最值钱的不是某个模式的配置而是它逼你养成了“控制上下文”的自觉。踩过几次坑之后我现在写代码时会下意识地想这个问题AI到底需要哪些信息哪些信息是我偷懒塞进去的噪音如果你也被AI编程的“上下文爆炸”折磨过强烈建议按这个思路整理一套自己的模式配置哪怕只有两个模式——粗看和精看——也会比无脑堆文件强得多。最后再分享一个小技巧规则文件里别写“不要做X”直接写“只做Y”模型的执行力度不是一个量级的。