最近整理一个老项目发现一个有意思的现象同一套 AI 辅助工具项目里的年轻同事用得风生水起但到了我手上改出来的代码总是不对味。问题不在工具能力而在我怎么给它喂上下文。后来我把“上下文”当成一种显式的模式来管理——给每个开发阶段定义明确的 context-mode事情才开始顺起来。这里说的 context-mode不是某个软件里的开关按钮而是一套关于“该让 AI 看到什么、不该看到什么”的策略集合。它能解决的问题很具体为什么模型有时过度修改、有时答非所问、有时又完全失忆。适合的人群也很明确正在用 AI 助手写代码的开发者、做大模型应用尤其是 RAG 和智能体的技术人以及被“上下文越长效果越好”这个误区坑过的人。这篇文章不讲抽象理论只把我自己的踩坑记录、配置模板和排查方法全部摊开。你会看到三种 context-mode 的定位与取舍、每个阶段切换模式的判断入口以及一套可以直接抄走用的落地方案。1. 先把 context-mode 讲清楚它不是按钮而是一套策略1.1 一次失败的代码修改让我开始研究上下文先还原一个具体的失败现场。我之前维护一个支付模块想让 AI 帮忙优化其中某个回调函数的超时重试逻辑。我很自然地打开会话把整个模块的代码文件一个不落地拖进了对话然后告诉它“帮我看看重试逻辑有没有问题。”结果模型确实很认真地看完了所有文件然后给我提了一个“全面优化方案”把服务类的命名改了、把消息队列的消费方式也换了、还顺带重写了一个跟重试毫无关系的鉴权中间件。我只要求改一个函数它却动了整个模块。事后复盘我发现问题不在模型的水平而在我的输入方式。我把整个模块都喂给了它它当然会在“全局模式”下思考自然会觉得自己应该做全局优化。这个教训让我意识到AI 工具并不存在一个默认的最佳配置上下文给多少、给哪些、以什么顺序给完全取决于调用者有没有清晰的设计。1.2 一个生活化的类比案板理论我后来经常用一个“案板理论”来解释 context-mode。做菜的时候高水平厨师不会把后厨所有食材一口气全摆在案板上而是会根据这道菜的需求提前把需要用到的配料切好、摆好其余的留在冰箱里。案板上摆什么就决定了厨师接下来的注意力分布。模型也是一样。你给它的上下文就是它的“案板”。案板上只有重试逻辑相关的文件它就会专注优化重试逻辑案板上躺着一整个模块的代码它就会认为你希望它通盘考虑。所谓 context-mode本质就是一套“案板管理规则”——明确每一个工作阶段应该摆放哪些信息以及哪些信息必须锁在冰箱里。顺着这个理解我给自己定义了三种基本形态全量模式Full-context、局部模式Local-context、空白模式Clean-slate。它们的区别不是“好不好”而是“什么时候用”。1.3 三种基本形态的定位与取舍先看全量模式Full-context mode。这种模式下我会把项目的整体结构、技术栈、关键模块说明全部塞给 AI让它先建立对整个项目的完整认知。优点是想得很周全缺点是开销大、容易被无关信息带偏。它适合“我要评估整个项目能不能改造”“我想了解系统全貌”这类宏观问题而不适合“帮我修这行 bug”这类微观任务。再看局部模式Local-context mode。这是我日常使用频率最高的一种。它会只加载当前任务直接相关的若干文件、接口定义、数据表结构、相关函数的调用关系把范围刻意收窄。优点是精准缺点是如果边界划错了模型容易因为缺少邻接信息而给出“局部最优但全局错误”的方案。最后是空白模式Clean-slate mode。这种模式下我几乎不提供项目代码只保留任务本身的描述让模型用通用常识和训练阶段积累的经验来回答。它特别适合做代码评审、写测试用例、做技术方案头脑风暴这类“不需要知道历史包袱”的任务因为旧代码的惯性反而会污染判断。三种模式的关系我用一个表格来对比模式案板上放什么典型任务主要风险全量模式项目结构 核心模块 技术文档架构评估、技术改造、系统梳理信息过载、决策被无关细节带偏局部模式任务相关文件 接口 数据表bug 修复、单点优化、功能补充边界划错导致方案整体不匹配空白模式任务描述 约束条件代码评审、用例编写、方案探讨缺少背景可能提出不可落地的建议你可能会问为什么不干脆一直用全量模式答案是成本和噪声。我实测过同样一个任务全量模式下模型首轮输出的 token 消耗平均是局部模式的三到五倍而且因为噪声大经常要多轮追问才能回到正轨。效率低是小事更麻烦的是它会在你没注意的地方自作主张地“顺手优化”这种隐形的越界往往比效率问题更致命。2. 实战场景什么时候该切到哪种 context-mode2.1 全局探索适合“这项目能不能改造”这种问题判断入口当你面对的问题本身就是“这个系统是怎么运转的”“有哪些瓶颈”“从哪个模块下手改造性价比最高”这类开放性问题时果断切全量模式。这类场景最常见的做法是先把项目的 README、架构文档、模块清单、数据流图整理好按“由总到分”的顺序投喂给模型而不是直接把几千个程序文件压进去。我在实际中使用的顺序是先给项目说明文字再给最高层次的模块划分最后只在模型追问时才把具体的类或接口代码掏出来。这里有个非常实用的细节全量模式不是“不设边界地全给”而是“按层次地给全”。如果你一上来就把整个代码库压缩成几个大文件塞进去模型很快会被同名变量、重复的工具函数和各种历史遗留代码搞得晕头转向。正确做法是把信息拆成“项目概览→业务模块→关键技术点”三层让模型像读地图一样先看整体再看局部。我自己的习惯是在全量模式下要求模型每看完一层就复述一遍它的理解确认无误后再进入下一层。这样做看起来多花了几轮对话但能避免后面所有回答都建立在错误的地基上。模型对项目理解错了后面的方案再漂亮也是空中楼阁。2.2 局部深挖适合“帮我修这个函数”这种问题判断入口当你已经知道问题出在哪个文件、哪个函数任务范围明确边界清晰就切换到局部模式。局部模式的重点在于“划边界”。以修复一个函数为例我的标准做法是提供四类信息目标函数本身的完整代码、它直接调用的那几个函数最多两到三层调用链、它依赖的数据结构和返回类型定义、以及它的调用方防止模型误改函数签名导致其他地方报错。至于那些跟这个函数无关的服务注册、定时任务、配置文件一律不放进去。边界划得好不好决定了模型输出质量的八成。我见过很多同事把“局部模式”用成了“小号全量模式”明明要改 A 模块的一个函数却把 A 模块的三十个文件全贴了过去还美其名曰“多给点上下文总没错”。结果模型给出的“修复”方案里经常带着对 A 模块其他功能的改动意向因为上下文里包含了太多本不该出现在案板上的内容。边界划小的另一层价值是让模型的注意力更集中。在我的实测中把上下文从三十个文件压缩到五个文件之后同样是让模型修一个 bug它的首轮准确率明显提升而且给出的解释也更聚焦。这是因为模型在局部模式下会把注意力资源集中到真正相关的代码路径上不会把 token 浪费在“看看这个文件里有没有什么相关的东西”这类探索行为上。2.3 隔离验证适合“帮我评审这段算法”这种问题判断入口当你要评审一段算法、推敲一个设计、或者让模型用“第三视角”挑毛病时屏蔽掉项目历史切空白模式。这类任务最大的敌人就是历史包袱。项目里的既有实现方式、历史决策、甚至你自己在对话里表达过的偏好都会成为模型的“锚点”让它不自觉地顺着你的思路走。空白模式的作用就是把所有锚点清掉让模型用最朴素的逻辑来判断。我做一个算法评审时的典型操作先把待评审的算法代码和输入输出约束单独整理出来不附任何历史代码然后明确告诉模型“假设这是一个全新项目不考虑任何兼容性约束请你从正确性、边界条件、性能三个维度给出评审意见”。这个指令一旦说清楚模型的输出质量立刻不一样——它会更大胆地指出逻辑漏洞而不是费心考虑“如果要保留旧接口应该怎么改”。当然空白模式也有代价它会漏掉一些重要的领域约束。比如支付系统里的金额计算必须考虑小数精度这在任何“全新视角”里都是不明显的。所以我的做法是在空白模式下让模型先放飞评审一轮拿到原始意见后再切回局部模式把被遗漏的领域约束补充给它让它出第二版针对性意见。两轮意见叠加比单靠一种模式靠谱得多。3. 落地实操给项目配一套可复用的 context-mode 配置3.1 第一步盘点信息源建立“上下文清单”先说一个反常识的结论上下文管理和数据管理一样第一步不是“收集”而是“清点”。在没有清单之前你根本不知道自己到底有多少信息是可以喂给模型的哪些信息又是绝对不能喂的。我建议每个项目都维护一份“上下文清单”按信息类型分类列出例如基础信息项目名、语言版本、技术栈、框架、构建命令结构信息目录树、模块划分、核心包的依赖关系业务信息领域术语表、核心业务流程、数据字典代码信息各模块入口、关键接口定义、数据库表结构约束信息编码规范、分支策略、部署环境差异禁用信息密钥、个人敏感数据、客户隐私字段、内部审计记录这个清单不需要做得像知识库那样庞大只需要保证“知道每类信息在哪里以及它属于哪一层级”。我见过最实用的做法是把这份清单直接写进项目根目录的 CONTEXT.md 里每次要启动一个 AI 会话之前先打开它按清单决定带哪些信息进会话。3.2 第二步给上下文分优先级——必须/可选/应忽略信息清点完之后第二件事是分类定级。我把清单里的每一条信息都打上三个级别之一第一级“必须”是无论切哪种模式都一定要带上的比如项目技术栈和构建命令连它们都不带模型连代码应该怎么编译都判断不了。第二级“可选”是根据任务类型决定带不带的比如某个模块的接口文档修那个模块的 bug 时必须要评审另一个模块的算法时就不必。第三级“应忽略”是明确不要带进上下文的包括过时的设计文档、废弃的接口、含敏感信息的环境变量示例。这个分级动作的威力我在一次重构中体会得特别深。那时候刚接手一个老系统里面有一堆“上一版设计”的历史文档我最初把它们全部喂给模型结果模型严格按照废弃文档里已经过时的接口设计给出了重构方案架构上完全走错了方向。后来我把“过时文档”直接划入“应忽略”层级禁止进入任何会话的上下文问题立刻消失。3.3 第三步写一份可复用的 context-mode 模板先声明一下我这里说的“模板”不是指某个工具的具体配置文件而是一套适用于各种 AI 编程助手、代码对话工具甚至通用大模型聊天的最佳实践范式你可以按自己手头的工具翻译成对应的提示词、规则文件或项目配置。我自己的模板长这样记录在一份叫 CONTEXT_RULES.md 的文件里# 项目背景始终携带 - 项目定位xxx - 技术栈xxx - 模块划分xxx # 会话建立规则 - 启动会话前先从 CONTEXT.md 里查出本次任务的上下文清单 - 依据任务类型选择模式架构评估 - 全量bug 修复 - 局部评审 - 空白 # 上下文进出规则 - 进入规则只有能直接影响本次任务产出的信息才被允许加入 - 退出规则模型给出最终答复后立即清理本轮注入的上下文 - 禁用规则密钥、客户隐私、过时文档一律不得进入上下文 # 输出质量要求 - 模型每给出一个结论必须标注它依据的上下文来源 - 若模型发现上下文不足以回答必须明确说信息不足而不是猜测这份模板的价值在于它把“上下文管理”从一次性的口头约定变成了可以持续积累、迭代的书面纪律。我把这套模板放在团队的项目 Wiki 里后来几个新同事也照着用明显减少了“AI 改错代码”的返工次数。3.4 第四步设置切换触发条件与评估指标有了模式和模板最后一步是立规矩什么时候切模式、切了之后怎么判断这次切换值不值。我的经验是切换条件应该由“问题类型”而不是“个人感觉”来触发。比如当我发现自己提问时在说“你看一下这个问题的背景”时说明我还没把问题的范围想清楚此时应该先切全量模式建立背景当我说“只改这一处别动别的地方”时就应该立刻切局部模式并缩小上下文当我说“你觉得这个方案本身怎么样”时就应该切空白模式。至于评估指标我一般看三个数首轮正确率模型第一轮给出的方案能不能直接用、平均对话轮数一个问题通常追问几轮才能收敛、越界修改次数模型有没有自作主张改了任务范围外的代码。这三个数都能手工记录不需要专门的工具。我坚持记录两周之后发现局部模式把首轮正确率从不到一半提到了七成以上同时把平均对话轮数从四轮降到了两轮左右这个数据直接让我相信了 context-mode 的价值。4. 上下文管理的三个坑与排查记录4.1 上下文污染模型把旧逻辑当成新事实这是我最常踩的坑而且往往发生得悄无声息。现象是模型给出的方案里混着一些项目里“曾经的逻辑”但那些逻辑已经在新版本里被替换掉了。你质问它“这里怎么还用旧接口”它还很笃定地回答“这是你项目里现有的代码呀”——因为它确实在上下文中看到了旧代码。排查思路一开始很让人头大后来我总结出一个规律凡是模型引用某个符号或者接口时如果上下文里同时存在“旧定义”和“新定义”模型有很大概率把先看到的那一份当成权威。所以我现在处理这类问题时第一反应不是怪模型而是检查这次的上下文里是不是混入了过时信息。解决办法非常土但非常有效在注入上下文时主动标注版本。“以下文件是当前生效版本其他任何同名定义均视为废弃”。就这一句话就能让模型在内部做一次“信息冲突消解”大概率会选择你标注为生效的那份。如果再搭配把过时文件彻底从清单里划掉基本可以杜绝这类污染。4.2 上下文丢失换了会话就失忆第二个高频问题是模型在这个会话里答得很好可一旦你新建一个会话、或者让模型处理另一个文件它就把上一轮的所有结论忘得干干净净。很多人这时候抱怨“AI 记性太差”但在我看来这是典型的“上下文没有被显式管理”。排查下发现所谓的“失忆”其实是因为上下文只存在于单个会话的窗口里会话一关信息就没了。解决思路不是指望模型记住而是把关键结论沉淀成外部记忆。我现在有个习惯每一轮有价值的对话最后都会让模型把“最终结论”和“决策依据”整理成一份几十行的摘要我直接粘到 CONTEXT.md 里。下次新会话把这份摘要带进去模型就能无缝接上之前的结论完全不需要重新梳理。这个方法在跨会话协作时效果好得出奇。有一次功能开发跨了两周中间我开了几十个会话但因为有持续沉淀的上下文摘要模型始终记得“支付回调的重试策略已经定为指数退避、上限五次”这个结论后面的所有修改都没有推翻它。4.3 上下文过载把模型“喂撑”了还有一个坑跟第一个正好相反上下文太多模型反而“消化不良”。表现是你给的资料越全它回答得越慢而且回答内容开始出现自相矛盾——前文说方案 A后文论证方案 B完全不知道听谁的。这个问题的本质是注意力资源被稀释了。模型在一个超长的上下文里对越靠后的信息记忆越模糊对明显无关的信息也难以完全屏蔽。我最早的错误做法是“宁多勿少”把项目里能拿到的资料都塞进去结果换来了高 token 消耗和低质输出。后来我终于接受了“上下文是一张案板不是一座仓库”这个设定开始在长度和相关性上做取舍。排查“过载”有一个简单信号当你发现模型的回答开始重复它自己的话或者开始引用一些你都没有提供的细节时多半就是上下文已经把模型的“有效注意力”耗尽了。这时我会把原始的巨型上下文拆成三到五个小块分轮喂给它每轮只针对一个小块提问再汇总结果效果立竿见影。4.4 问题速查表把上面三类的现象、原因和应对方式整理成速查表方便以后遇到同类问题直接对号入座现象可能原因快速应对方案里混入过期接口或旧逻辑上下文混入过时文件注入时明确标注“当前生效版本”过期文件划入忽略层级新一轮会话完全遗忘之前结论关键结论没有沉淀到外部每轮让模型输出摘要写入 CONTEXT.md 后带入新会话回答变慢且自相矛盾上下文过长、注意力稀释拆成小块分轮提问只保留任务直接相关信息模型自作主张改无关代码全量模式下上下文过宽先缩小到局部模式仅保留目标函数和直接调用链模型说“信息不足”但实际资料齐全资料结构混乱、未被有效引用按“概览→模块→细节”分层投喂让模型先复述理解这张表我贴在自己常用的笔记软件里每次排查都先按表里的顺序过一遍能省下大量试错时间。说实话这套方法第一次跑通之后我的第一反应不是“AI 变聪明了”而是“原来是我之前一直在给 AI 添乱”。上下文管理这件事表面上是技术活实际上更像是一种沟通纪律你想让一个能力很强但很容易被误导的协作对象做好一件事最好的方式不是把所有资料都堆给它而是帮它把注意力放到正确的地方。根据我个人的经验context-mode 这个概念一旦内化成习惯收益最大的场景不是某个高难度的架构评审而是日常那些琐碎的 bug 修复和需求变更——因为这类任务最容易被“多给一点上下文”的惯性害死也最需要清晰的边界。如果你也在被 AI 辅助开发时的各种“灵异事件”困扰强烈建议从今天开始给自己手头项目建一份 CONTEXT.md定义好三种模式再坚持记录两周的首轮正确率数据。数据会告诉你这到底是不是值得长期坚持下去的工作方式。