最近帮团队梳理AI辅助研发流程发现一个特别有意思的现象大家用的模型上限其实差不多但实际产出天差地别。有人用AI写代码像请了个贴身架构师有人用AI写代码像在跟一个失忆的实习生反复说同一句话。问题基本不在模型智商而在上下文怎么给、给多少、怎么存——说白了就是 context-mode上下文模式这一整套东西没理顺。我把上下文模式理解为模型在回答之前到底能看什么、按什么顺序看的全部策略总和。它不是一个工具的某个按钮而是你在用AI干活时对注意力资源做的调度。这篇文章不聊模型选型专门讲我怎么设计、配置、调整上下文模式以及在真实项目里踩过的坑。适合已经用AI写过一段时间代码、但总觉得效果不稳定的朋友也适合准备给团队搭一套统一AI协作规范的同学。1. 模型能力接近天花板之后剩下来拼的是上下文管理1.1 一次模型很聪明结果很离谱的真实经历上个月有个后端项目要加一个导出功能我让AI直接改一个快两百行的服务类。需求描述写得很详细导出字段、过滤条件、文件格式、异常处理方式。AI回答得也很快代码结构和注释风格都挺规范。但跑测试的时候直接报错——它调了一个项目中根本不存在的工具方法还把另一个同名但含义完全不同的状态枚举当成了我要的那个。当时我的第一反应是这模型真笨。后来把完整上下文翻出来才发现它压根没看到项目里那个枚举的真实定义也没看过项目里已有的导出工具类。它只是根据我给的只言片语猜了一个最像的答案。猜错了而已。这件事之后我做了个实验同一个需求我把相关文件用引用方式显式喂给工具把项目规则文件也挂在上下文里再问一次。结果它不但用了正确的枚举还主动复用了项目里现成的导出工具类。同一个模型同一个需求两个结果。差别只有一个——上下文模式的配置。1.2 上下文窗口是一个固定大小的储物间很多朋友对上下文窗口的理解是越大越好这句话只说对了一半。模型确实能看到的原始token数在变大但它的有效注意力是有限的。你把一个十万行的代码库全塞进去模型在理解每个局部问题时能调用的有效记忆并不会线性增长。我习惯把上下文窗口想成一间储物间。你往里放的东西越多找东西越慢而且真正重要的东西容易被埋住。关键不是你塞了多少而是你把最重要的信息放在了最显眼的位置。上下文模式解决的核心问题就是在一个有限的储物间里如何按当前任务需要动态决定把哪几样东西摆在台面上。这就引出一个关键认知上下文管理不是把能放的全放进去而是根据任务目标做筛选和编排。1.3 上下文模式本质上是注意力资源的调度策略我见过最朴素的做法是把项目全部代码路径列出来然后在提问时手动挑几个文件贴进去。这种做法不是不行但非常依赖人的判断力而且每次都要重复劳动大脑会先累死。稍微进阶一点的做法是用工具提供的索引和规则能力让AI在回答前自动搜索、自动读取相关文件。再往上就是形成一套按角色、按任务类型、按项目规模切换上下文策略的方法论。我在这篇文章里把它统称为 context-mode。说白了上下文模式就是一套注意力资源的调度策略。调度得好有限的上下文窗口就能持续集中在高价值信息上调度得差再大的窗口也不够用。2. 我理解中的四种上下文模式以及它们各自擅长的事2.1 会话模式把背景知识全部塞进一次对话会话模式是最基础、大家用得最多的形式启动一个新对话把需求、背景、约束条件一股脑写在Prompt里然后从AI的回答继续追问。这种模式适合一次性、范围明确的小任务比如帮我把这段JSON转成Go的结构体解释一下这个报错是什么意思。它的优点是启动成本低适合问题边界清晰、不需要跨文件理解的场景。缺点是上下文全靠人肉维护每开一个新会话之前聊过的关键决策就丢了。我见过不少团队在同一个需求上反复开新对话每次都要重新解释一遍项目背景效率非常低。所以我给会话模式的定位很明确它适合单点问答不适合需要连续修改多个文件的工程任务。如果一件事需要三个以上的来回才能做完就不该继续依赖裸的会话模式。2.2 文件链接模式用显式引用把指定代码钉进上下文文件链接模式比纯会话更进一步。常见的形态是 文件名、#文件引用、或者直接把文件路径作为上下文标签。它的核心作用是让模型在回答时能看到你指定的那几个文件的真实内容而不是靠猜。这种模式在改动一个具体函数、排查一个具体Bug时非常好用。把两个相关文件引用进去模型就能看到函数定义和调用方的实际代码回答精确度会高一个量级。但也有明显的边界一旦问题牵扯到七八个文件以上的依赖链路靠手动引用就会变得很累而且很容易漏掉关键文件。相当于你指给AI看的东西越来越窄它仍然看不见整个项目的全貌。2.3 项目级索引模式让AI自己去找而不是等着你喂项目级索引模式是目前主流AI编程工具的标配能力。工具会为代码库建索引当你提出问题时它先做语义搜索自动把相关的代码片段拉进上下文再生成回答。Cursor里的代码库检索、Codex里的项目上下文、Cline里配置的索引文件本质都是这个路子。这种模式的优点是省心适合需要跨文件的改造任务AI会自己去找它认为相关的定义、调用方、测试文件相当于你给模型配了一个自动检索器。缺点也很现实检索质量和项目的组织方式高度相关。如果你的代码命名混乱、模块划分不清楚索引出来的东西经常是错的。我遇到过AI把两个项目的同名函数混在一起引用的情况差点把不相关的模块改了。项目级索引不是银弹它需要配合良好的工程结构才能发挥真正的价值。2.4 代理模式让模型连续决策自主执行上下文选择代理模式Agent模式是最近一两年最热门的形态。在这种模式下AI不只是回答一个问题而是被赋予一个目标然后自动决定下一步要看哪个文件、执行什么命令、读哪些文档直到完成任务。它的上下文管理是动态的模型每走一步都会把新读到的信息追加进上下文同时压缩旧信息。这种模式的优点在于它能处理非常复杂的多步骤任务相当于你雇了一个会自己查资料的实习生。缺点则是不可控性明显增加它可能读了很多不必要的东西可能在错误的方向上走很远也可能被上下文中某个过时信息带偏。所以我的用法是代理模式适合探索性任务比如重构这个模块之前先帮我梳理一下它的依赖关系。但是在动关键代码之前我会切回文件链接模式把需要精确修改的范围钉住。理解工具给的模式是第一步会用组合拳是第二步。下面这个表格是我给自己团队整理的模式对照分享出来供大家参考。模式上下文来源最擅长的任务主要风险我的使用频率会话模式用户提问中携带的背景单点问答、快速解释上下文丢失、重复劳动低文件链接模式显式引用的文件内容精确改函数、查Bug依赖人工筛选、易漏文件高项目索引模式语义搜索召回的项目代码跨文件改造、新加入功能检索不准、受工程结构影响中代理模式模型动态读取并追加信息探索分析、复合任务执行不可控、token消耗大中3. 手把手把项目的上下文管理从裸奔升级为按需供给3.1 先给任务分好类再决定用什么模式我自己的经验是不要上来就纠结工具配置先把任务类型分清楚。我习惯把日常任务分成四类问答类、修改类、新增类、排查类。不同类型对应的上下文策略完全不同。问答类任务比如这个函数是干什么的用会话模式就够了不需要额外喂太多信息。修改类任务比如把某个接口的入参从A改成B必须用文件链接模式把接口定义、调用方、测试文件都显式引用进去。新增类任务比如在现有模块里加一个新的导出能力建议用项目索引模式让AI先摸清现有结构和代码风格。排查类任务比如为什么线上突然报这个错优先用项目索引加日志片段组合的方式让AI能同时看到实时日志和对应代码。3.2 搭一个项目记忆文件规则、结构与禁忌我现在每个正式项目里都有一个类似 CLAUDE.md 或项目规则文件的东西里面固定维护三块内容项目结构说明、编码约定、容易踩的坑。这个文件不是给新员工看的是专门用来在每次AI会话启动时注入上下文的。第一块写项目结构但不要写长篇大论只写哪几个目录各自负责什么入口在哪里核心领域模型定义在哪个上层位置。第二块写编码约定比如错误处理统一走某个公共方法、命名规范、数据库访问必须走DAO层。第三块写这个项目独有的坑比如这个模块的缓存有两层不要只查一层就下结论。有了这个文件之后我在每个新会话里都会先把文件链接进去或者配置成自动注入。效果非常直接AI很少再生成和项目风格不一致的代码也不再反复问你们项目用什么日志框架这种已经回答过的问题。3.3 把喂多少内容变成一道计算题一开始我也踩过喂少了不够、喂多了淹没重点的坑。后来我给自己定了一个粗略但实用的计算方式单次任务的上下文里系统指令和用户需求占20%目标文件内容占50%参考文件内容占30%。如果参考文件太多就只挑最关键的依赖定义而不是把整个依赖链路全部贴进去。比如要改一个订单服务的方法我不会把整个订单服务几百行全塞进去而是把方法签名、涉及到的实体类定义、调用处的约束逻辑这三样拿进去。这样模型的注意力能集中在真正要动的代码上而不是被无关的分支逻辑分散掉。我还建议给每个文件标一下角色——哪个是主要修改对象哪个只是参考。很多工具支持在引用时加说明文字比如file: order_service.py (只参考其中checkout方法). 这个动作虽小但能让模型明确知道该花多少注意力在不同文件上。3.4 同一个需求在三种模式下的效果对比为了说清楚模式切换的价值这里分享一个真实案例。需求是在用户管理页面增加一个停用账号的按钮并在点击后发送通知邮件。用纯会话模式的时候AI完全不知道用户管理页面用的是哪个前端框架也不知道后端有没有现成的邮件发送服务。它给了一版通用的实现前端结构也和项目里现有的页面组件对不上。切到文件链接模式后我把用户管理页面的组件文件、后端用户状态管理服务、邮件发送工具类三个文件引用进去。AI这次生成的前端结构对了也正确调用了邮件工具类但按钮的状态管理逻辑和项目里其他按钮的风格不一致——因为它没看过其他按钮组件。最后我用项目索引模式先让AI自己总结这个项目里按钮组件通常怎么写、状态管理怎么放在统一Store里再结合文件链接模式去改目标文件。这一次生成的结果基本可以直接合入结构一致、复用正确、状态管理也进了统一Store。这个案例让我彻底想明白一件事上下文模式不是把按钮从自动改成手动的简单事而是要在具体任务里回答清楚模型现阶段最需要看什么。多数时候先用索引模式建立全局认知再切到文件链接模式精改效果远好过一直开着自动模式。4. 别忽视token预算长上下文不是越多越好4.1 为什么模型会忘记中间段落很多做大模型应用的朋友都知道Lost in the Middle这个现象当关键信息出现在上下文中间位置时模型对它关注度会明显下降。开头和结尾的信息最容易保留中间部分容易变成背景噪音。这意味着哪怕你的上下文窗口足够大也不能掉以轻心。一段放了二十个文件超长上下文的对话模型真正高注意力处理的可能只有前面和后面那一小部分。中间那些文件不是被理解了而是被看过了——这两个词之间的差别在工程上就是天壤之别。我自己的验证方法是做一个小测试把项目的核心架构描述写在Prompt的开头把具体的修改目标写在中后部把强制约束写在末尾。结果发现AI对后半段约束的执行明显比中部目标更卖力。后来我把修改目标提到开头、把约束放在紧跟其后的位置执行准确率立刻上了一个台阶。4.2 给上下文预算做分配既然有效注意力是有限的我们就要学会分配预算。我给团队定的默认预算分配是这样的目标任务描述占10%项目级规则和约束占20%核心目标文件占50%辅助参考材料占20%。如果任务特别复杂就把辅助参考材料压缩到10%把省下的空间留给核心文件。另外我强烈建议在动手前先估算一下要喂进去的文件总token量。有些大文件动辄几千行全部塞进去可能直接吃掉一半窗口。遇到这种情况优先做裁剪可以只喂关键类的关键方法或者用工具先提取类的公开接口和结构再决定要不要全文读入。记住一个原则宁可让AI多问一次这个函数的完整实现我没看到需要我读一下吗也不要让它在一堆无关代码里自己找。主动裁剪比被动给全量文档要稳妥得多。4.3 长会话的压缩与重启策略上下文模式还有一个经常被忽视的场景就是长会话。当一个对话来回超过二三十轮之后早期的关键决策会被后面大量讨论内容埋没。这时候硬撑下去AI的表现会越来越像在背诵早期结论而不是基于当前代码做判断。我的做法是建立会话重启决策简报机制每完成一个阶段性目标就手动做一份简短的项目状态摘要包含已经改了什么、当前在改什么、下一步要做什么、有哪些遗留风险。然后开一个新会话把这份摘要作为上下文起点。效果比在旧会话里硬续要好很多。这套东西看着简单但实际用下来能显著降低模型的选择困难。很多看起来是模型变笨的情况其实是上下文被无效信息污染了。5. 事故复盘这几类context-mode翻车现场我都遇到过5.1 事故一无脑开全自动项目上下文小事搞成大工程有一段时间我图省事所有任务都开项目索引模式让AI自动检索。结果一个只需要改一行配置的小需求AI前前后后检索了七八个文件改了五处地方还自以为是地把相关函数做了顺手重构。代码本身没看出错但评审成本一下翻了三倍。后来我给自己立了一条规矩改动范围在单个文件以内直接用手动引用不给AI自由发挥的空间只有改动范围跨三个文件以上才考虑自动索引。很多工具之所以提供严格模式和自动模式的切换就是给这类精细控制留的接口不要图省事一把梭。5.2 事故二两个规则文件对同一件事给出相反指令我们项目里同时有一个人工维护的规则文件和一个AI自动生成的说明文件。有一次我在规则文件里写了新代码禁止使用全局变量但AI自动生成的说明文件里保留了旧的全局状态管理方式。结果AI在生成新代码时一会儿遵守前者一会儿遵守后者改了三轮状态管理才统一。这个事故让我意识到上下文模式里规则一致性必须优先于规则数量。我把规则文件合并成一个唯一信任源并且规定所有自动生成的说明都不得越过主规则文件。同时还加了一句明确的优先级指令放在Prompt最前面若存在冲突以项目规则文件为准。之后再没出现过这种矛盾。5.3 事故三把一个大文件整个塞进去结果当场失效有次排查性能问题我想让AI分析一个上千行的核心服务类。第一反应是把整个文件引用进去让它从头看。结果模型确实看完了但给的分析和建议非常泛基本就是把代码表结构复述了一遍根本没有深入到具体性能瓶颈。后来我换成两步走第一步先让AI读这个类的公开方法和关键字段帮我列出哪些方法可能存在性能风险第二步只把风险最高的两三个方法的具体代码引用进去再让它做深挖。效果立竿见影。这个教训是大文件不是不能喂而是要先做粗筛再精读。上来就全量塞入等于把最多token花在了模型注意力最分散的地带。5.4 事故复盘问题定位的完整排查链路如果你也遇到加了个上下文反而更差的情况我建议按下面这个顺序排查而不是直接怀疑模型智商。第一步确认当前会话实际注入了哪些内容。很多工具在界面里能看到已读取的文件列表或者可以发一句你刚才参考了哪些文件来确认。第二步检查目标文件是否真的被正确读取而不是只读了文件名。有时候引用路径写错AI根本没看到内容。第三步检查规则是否冲突。把项目里所有规则文件打开逐条对比约束。第四步估算有效上下文的占比。如果目标文件只占总token的30%以下那大概率是信息被稀释了。第五步看模型是否在过度自由发挥。如果是立即切换到文件链接模式把修改边界收紧。顺着这条链路走绝大多数AI突然变笨的问题都能定位到具体的上下文配置上。6. 多人和团队协作时的上下文协同策略6.1 团队级记忆文件的分层设计上下文模式在个人项目里很容易管理但到了团队就复杂了因为不同成员对项目的理解不一样写进规则文件的内容也会互相冲突。我们团队最后采用的是三层结构第一层是团队全局规则管通用编码规范和流程约束第二层是模块级规则管某个服务或前端应用的特殊约定第三层是人维度记忆管个人常用的偏好和习惯不强制要求别人遵守。这样分层之后每个人在发起会话时按需注入对应层级的内容既不会让团队规则被个人偏好污染也不会让个人经验流散到团队规范里。上下文不再是谁规则写得多谁说了算而是变成了一套有优先级的引用体系。6.2 用脚手架脚本按需生成上下文我后来还做了一件提升团队效率的事写了一个脚手架脚本自动生成项目上下文包。脚本会用固定模板扫描项目目录收集模块说明、最近改动范围、核心依赖路径然后打包成一个上下文文件。成员在启动新会话时只需要指定要改哪个模块脚本就自动把对应层级的规则和结构信息拼装好。这个脚本我用了大半年最大感受是它把上下文模式从一个依赖个人经验的手艺变成了团队里人人可以复用的工程能力。新成员加入时不需要先看一个月代码才能开始用AI干活照着脚本生成的上下文包就能快速上手。6.3 我的边界感什么时候不该用上下文模式聊了这么多怎么用好上下文模式最后我想强调一个反直觉的点不是所有任务都该把上下文喂得越全越好。越是大而复杂的任务越要先做减熵让模型聚焦在真正需要决策的地方。比如架构评审这类任务我反而不会把全部代码塞进去而是把目标模块的边界、依赖关系和不变量喂进去让AI站在架构视角给意见。再比如技术选型讨论也不需要把整个代码库都放进去只需要把约束条件、现有技术栈和关键性能指标列清楚就够了。换句话说上下文模式的价值不在于让AI看得更多而在于让AI看得更准。真正的高手是能在合适的时候把上下文收窄把模型逼到必须直面核心问题上。这个度只能靠一次次实际项目里的调试和复盘去拿捏。我个人用过这么多工具和方法之后最深的体会是上下文模式不是一个可以抄完就一劳永逸的配置模板它更像一套需要持续调校的注意力管理习惯。每次模型答非所问的时候先别急着骂模型不行停下来看看现在的上下文里到底装了什么、该装什么、不该装什么。把这一层想清楚手里的工具才能真正发挥出它应有的水平。