1. 先纠正一个误区AI不是全知的神它的视野由你决定1.1 上下文模式不是话术风格而是AI的视野范围很多人第一次接触 context-mode会把它理解成语气开关觉得选简洁就是少说废话选详细就是多写注释。这是最典型的误解。上下文模式真正控制的是AI在回答问题之前到底读了哪些材料。我在本地项目里做过一个简单的对照实验。同样的需求——给fetch_user_profile函数补充异常处理三次提问分别只给函数体、给整个文件、开全仓索引用仓库模式。结果很有意思只给函数体的那次AI做的是最小改动逻辑干净但完全没考虑调用方默认它不会抛错的约定给整个文件的那次AI自动沿用了同文件里其他API函数的错误处理风格基本不需要二次修改开仓库模式的那次AI甚至开始沿着导入关系去翻其他模块最后给出的方案里包含了一个文件里根本不存在的基础类明显是想当然。这个实验后来我重复过很多次结论从来没变过不是模型变笨了是模型看到的东西变了行为就会跟着变。你喂给它的代码范围就是它的世界观。1.2 一个类比远程会诊的读片范围我常用一个医疗类比来理解上下文模式。你请一位专家会诊只给他一张CT片子选区模式他的判断一定聚焦在片子上快但也容易忽略既往病史的影响如果你把他带进病房让他翻阅整套病历文件模式他能结合历史情况做综合判断可你要是把整个医院的病例库都搬给他仓库模式他反而可能被大量无关信息干扰甚至把某个偶然扫到的罕见案例当成你的主诊断。这个类比解释了为什么上下文越大越好是错的。对于AI编程助手来说上下文模式的选择本质上是你在替模型做一次信息筛选哪些代码必须看见哪些代码最好别看。筛得好模型的判断力会明显上一个台阶筛得不好模型就变成一个知识渊博但严重偏题的实习生。1.3 视野决定行为行为决定代码质量代码质量不是抽象概念它由一个个具体的约束组成现有函数的命名习惯、同模块的异常处理约定、数据层的访问边界、调用方的隐式假设。这些约束分散在代码里模型默认是看不到的除非你通过上下文模式让它们进入视角。上下文模式选得对不对直接决定了AI是在你的约束范围内做优化还是在它自己脑补的约束范围内发挥。后者产出的代码看起来头头是道放进项目里往往第一个Review就过不了。2. 底层机制拆解上下文窗口、注意力偏差与工具端的检索理解了视野这层接下来要钻进去看机制。因为只有明白机制你才知道什么时候应该手动干预上下文而不是傻等工具自己处理。2.1 上下文窗口是硬约束token预算要心里有数所有AI模型一次能处理的内容量都有一个上限叫上下文窗口。这个窗口按 token 计量而不是按行数或者字符数。中文场景下一个汉字大约占1到2个token英文大约4个字符折合1个token。一个典型的2000行代码文件如果完整喂进去轻轻松松占掉一两万token。这个数字意味着什么主流AI模型的上下文窗口虽然动辄几十万token但你的预算是共享的既塞了代码也塞了对话历史还要给模型的输出留位置。如果在上下文里堆了一堆无关文件真正关键的接口约束可能就被挤到窗口边缘。我自己写了一个小工具来估算每次粘贴的内容量逻辑很简单def estimate_tokens(text): cn_chars sum(1 for ch in text if \u4e00 ch \u9fff) other_chars len(text) - cn_chars return int(cn_chars * 1.5 other_chars * 0.28) sample open(target_file.py).read() print(roughly, estimate_tokens(sample), tokens)不需要精确够估算就行。当一次任务的全量上下文估算超过两三万token时我就会主动开始做减法而不是继续往里堆。2.2 位置偏差模型更擅长记住开头和结尾大语言模型在超长上下文里的表现并不是一条平坦的曲线。过去两年有不少团队做过针对性研究结论高度一致模型对上下文开头和结尾的信息利用率明显更高夹在中间的内容则容易被稀释。业界管这个叫 lost in the middle意思是中间部分在注意力机制里天然吃亏。这个结论落到实操里非常值钱。既然中间区域容易被忽略我在组装给AI看的材料时就遵循一个原则最关键的事实放开头最后的指令和要求放结尾参考资料和辅助细节放中间。比如仓库模式下第一句话永远是下面这个问题涉及A服务和B服务核心代码在xx路径最后一段永远是最明确的指令——只修改xx不要动其他文件。这么安排之后AI理解任务的成功率提升非常明显。2.3 工具端其实帮你做了预筛选另一个经常被忽略的点是当你选择文件模式或仓库模式时AI助手并不是真的把项目所有代码一字不差地喂给模型。工具端会先做一层预筛选——通过语法分析提取符号和结构、用向量化检索计算代码与问题的相关度、再把命中的文件按得分排序拼进上下文。这也是为什么你在仓库模式下会感觉AI好像真的懂我的项目因为它确实读了部分索引但读的未必是你最在意的那部分。理解了这一层就会明白一个特别重要的推论工具替你做的预筛选本质上是一种概率猜测它不一定猜得准。所以不要把它会自动看代码当成理所当然。关键时刻你需要在提示词里显式点名关键路径把工具检索的偶然性降到最低。这个点我在第五部分会展开讲。3. 四种常用上下文模式的分工边界与选型逻辑这一部分进入实操。我把日常用得最多的上下文模式归纳为四种选区模式、文件模式、仓库模式和Agent模式。不同工具的菜单名可能不一样但底层逻辑高度一致。3.1 选区模式精确制导适合改动既有函数的局部行为选区模式有的工具叫只读选中内容适合处理局部性非常强的任务给一个现有函数补异常处理、优化一个循环、调整一段逻辑的顺序。这种模式下模型只看到你选中的代码块视野最窄因此不会受到同文件其他部分风格的影响也不会冒出翻别处代码的冲动。结果通常可控、可预期、改动量小。但选区模式有一个明显的短板你选中的函数往往依赖文件顶部定义的常量、类型和工具函数这些依赖不在上下文里模型就只能猜。为了补偿我会在提示词里把必要的外部依赖补一句比如这个函数里的logger是标准logging模块的实例LogLevel来自common/constants.py。有个更稳妥的折中方案不要只选中函数体而是把该函数所在类的声明区域或者紧邻的辅助函数一起选中再把提问范围严格限定在目标任务上。这样既保持视野小又给了模型足够的锚点。3.2 文件模式当前文件的全景地图日常高频的甜点位文件模式是大多数日常任务的最佳选择。模型能看到当前整个文件包括导入语句、其他函数、类的整体结构。这意味着它不需要脑补同文件的约束自然能模仿文件里已有的风格和约定。我自己的经验是如果任务要求新加一个函数到某个文件或者统一调整某个文件中多个函数的错误处理方式文件模式几乎是唯一正确的选项。它比选区模式信息多又比仓库模式噪音少推理速度也理想。需要留意的是文件规模。项目里有些文件动辄上千行全量塞进去同样会造成上下文拥挤。这种场景我不会直接开文件模式而是先手动拆分目标函数区域或者用工具自带的限定文件内某一片区域的能力。判断标准很简单这个文件超过500行且任务只涉及其中一小段就回到选区模式加手动补充依赖文件在300行以内且任务涉及文件整体就放心开文件模式。3.3 仓库模式跨文件问题的重武器要有节制地用仓库模式解决的是真正涉及多个文件的问题一个功能跨服务调用、一个Bug需要沿着调用链排查、或者一次涉及十几个文件的重构。这种任务的共同特点是单文件视角下根本没法给出靠谱答案。但仓库模式的开销和风险也是最高的。一方面它要消耗大量token做检索和汇总另一方面模型在检索到的海量代码中更容易做出过度联想把本不该动的代码一并纳入修改范围。我给自己定了一个使用门槛只有当任务描述里至少要提到两个不同路径的文件时才考虑开仓库模式。如果任务只涉及单个文件内的事情无论看起来多复杂都不要开。此外如果工具支持指定文件夹这种中间档优先选它而不是整个仓库效果会稳很多。3.4 Agent模式放权给AI自主搜索但必须给足护栏Agent模式是最近两年AI编程工具里发展最快的方向。它和前面几种模式的本质区别在于AI会自己决定去看哪些文件、执行哪些步骤直到完成任务。好处是彻底解放了手动喂上下文的动作坏处是它自主行动的前提假设一旦出错会把错误放大。我对Agent模式的态度是可以用但提示词里必须写清楚两件事——第一允许它读哪些范围例如只允许查看src/和tests/目录不要读docs/和scripts/第二禁止它做什么例如禁止修改除了src/core/cache.py以外的文件。这就像给实习生派活你把场地边界画清楚他才能在边界内发挥。另一个实用技巧是分步授权不要一上来就让它完成一个大重构而是先给一个小目标比如找到缓存失效的原因等它对问题的分析符合预期后再通过追加指令让它继续下一步。把Agent模式当成一个可以随时叫停的协作者而不是撒手不管的自动编程机。4. 踩坑实录我把能翻的车基本都翻了一遍理论讲再多不如一次具体的翻车现场有说服力。下面四个坑全是发生在我自己项目里的真实案例。每个我都写清楚了当时的错误决策和后来的修正方式。4.1 翻车一全仓模式改一个三行BugAI顺手重构了整个模块某次我接到一个线上告警client模块抛TypeError原因是某个配置校验函数少判断了一种输入类型。问题很小正常十分钟就能改完。我图省事直接在仓库模式下让AI修然后在指令里写了句顺便看看有没有类似问题。结果AI不仅改了那个函数还按照它理解的更优雅的写法重写了整个校验模块删了两个旧函数新抽象了一个基类。代码确实写得漂亮但它违反了团队约定而且直接引发下游六个调用点报错。我花了整整半天把重构回滚重新精改。教训就一句话修Bug的时候上下文越小越好。你让AI看到的越少它自作主张的空间就越小。后来我把需求改成只修复is_valid_config函数里的类型判断分支其它任何代码不要动同样是仓库模式AI果然一笔多余改动都没有。4.2 翻车二只贴函数体AI脑补出错误的接口契约有次我处理一个数据管道报错想快速让AI分析某段解析逻辑。当时觉得整个文件太长只选中了异常附近的20行贴进对话。AI很快就给出了分析信誓旦旦说问题出在异步迭代未做并发保护。我按照它的建议改了代码一跑照样崩。仔细一看才反应过来那20行代码根本不在异步函数里AI之所以这么推测是因为它看不到函数定义和调用上下文于是用最常见的模式脑补了一个异步场景。后来我换了个做法先把整个函数和调用它的地方一起选中再让AI分析。上下文一补全它立刻指出真正的问题在于上游传入的数据结构里嵌套了一层意想不到的None。对比非常强烈。这让我彻底记住了你贴给AI的代码必须是它做判断所需的最小子集而不是你顺手复制的那一段。4.3 翻车三在Chat窗口讨论跨文件逻辑全程梦游还有一种高频翻车是上下文模式本身用对了但聊天历史里积累了很多不相关的话题。比如我先让AI帮忙写过一段正则聊了不少无关细节然后紧接着问它一个完全不同的跨模块问题。结果AI的回答明显受到前一个话题的影响甚至把正则的转义符方案套到了数据库查询上。问题出在我自己没有在切换任务的时候清理上下文。Chat窗口不是人脑前一个任务留下的中间分析不会自动归档它们会继续占用注意力并污染后续回答。现在我的习惯是一旦任务类型发生切换立刻新开一个会话哪怕只是从写正则切到查数据管道。省下来的token和困惑远比重新描述一次背景的成本划算。4.4 翻车四大仓库里AI像被搜索引擎背刺某次排查支付回调的重试逻辑我开了仓库模式明确描述了异常现象。AI给出的第一个结论完全跑偏它盯着一个名称相似但完全是另一业务的支付对账模块分析了一整页。原因不难理解工具端预筛选靠的是语义相似度而支付这个词足够相似把对账模块也拉进来了反而把真正的回调模块挤到了排序后面。模型没有错是检索阶段给了它错误侧重的证据。事后我的修正方案是在提示词里显式点名关键文件路径核心逻辑在src/payment/callback.py请以这个文件为主分析其它模块只做引用参考。加了这一句之后AI的注意力立刻被拉回来。检索工具不是搜索引擎你可以用显式点名强行纠正它的排序倾向。5. 高质量上下文动手实践与其找模式不如造上下文懂了机制、看过了翻车案例接下来才是提升空间最大的部分——主动去设计上下文。上下文模式只是帮你打开视野真正决定AI上限的是你喂给它的内容质量。5.1 给AI建一份项目地图我强烈建议在大型仓库的根目录维护一个简短的上下文说明文件比如 AI_CONTEXT.md。内容是固定的几项项目入口在哪、核心目录结构、必须遵守的约定、容易踩的坑。这个文件存在的意义是让任何上下文模式下的AI都能在一开始就读到你的世界观。# 项目上下文速览 - 入口app/main.pyFastAPI启动端口8000 - 配置config.yaml禁止硬编码环境变量 - 数据访问repository/ 目录下的仓储类service层禁止直接写SQL - 异常统一抛自定义 BizException错误码在 errors.py 定义 - 测试tests/ 下按模块建文件夹跑测试用 pytest -q为什么会有效因为模型在面对一个陌生项目时最缺的就是最重要的几条规则。你把这个文件塞进上下文相当于在它动手之前先给它做了十分钟的项目介绍。很多工具在仓库模式下会自动读取这类说明文件但即便不自动读你也可以在提示词里用一句先读AI_CONTEXT.md把它拉进来。5.2 把验收标准写进提示词而不是只给代码大多数人的习惯是把代码贴过去然后说帮我改改。这其实是最低效的提问方式。高质量的上下文不只是代码还包括任务背景、预期行为、约束和验收标准。我总结了一个简单公式背景一句话 现状位置 预期行为 明确约束 验收标准。举个例子同样是让AI优化一个函数背景用户反馈批量导入速度很慢瓶颈疑似在逐条插入。 现状src/importer.py 的 insert_batch 函数约120行。 预期把逐条插入改为批量插入保持对外行为不变。 约束不新增第三方依赖保持日志格式不变事务仍由调用方控制。 验收改造后跑通 tests/test_importer.py 全部用例单批1万条耗时下降50%以上。这样一段上下文模型几乎不可能走偏。它知道自己要完成什么、边界在哪、怎么判断自己是否做对了。很多时候AI产出的方案不行不是模型能力不够而是你根本没让它知道做成什么样才算合格。5.3 显式提名关键文件把检索偶然性压到最低上一节翻车案例里提到过仓库模式的检索可能抓错重点。对应的通用解法就是我一直在用的显式提名在提示词里把所有你希望模型聚焦的文件路径直接写出来。这个做法还有一层作用它等于告诉模型这些是定海神针其他信息都只是参考。很多工具内部会把提示词里出现的文件路径做加权处理让这些文件在检索排序里获得更高优先级。即便工具没有这个机制模型对显式提到的路径也会更注意这是两个层面的双重保险。如果任务涉及的文件清单很长我会先做一个简单的路径清单而不是在中间反复穿插。开头列一次结尾列一次开头给事实结尾下指令呼应前面讲过的位置偏差原理。5.4 用约束回填做自我纠正比反复说不对更高效人机对话里最让人恼火的时刻是改了几轮还在犯同一个错误。传统做法是继续在对话里说不对还是有问题然后重复贴代码。效率很低而且历史越长模型越容易混乱。这里有个更高效的技巧当AI的方案偏离你的约束时不要笼统地说不对而是直接把那条约束作为新的事实补进上下文并附带出处。比如注意调用方在 src/process.py 第120行已经假设该函数永远返回非空列表因此不要新增返回None的分支。这条新信息会像一根桩一样钉进对话模型基于它重新推导时往往一两轮就能修正方向。我把它称作约束回填本质上是把纠错过程变成一次上下文补充。你不是在告诉模型你错了而是在告诉它你还缺一个关键事实。5.5 控制轮次及时清空无关历史最后一个建议最便宜但见效极快任务一旦切换马上新开会话。对话历史在上下文窗口里占据的体积比想象中大得多而且每一轮累积的中间推理对后续任务基本都是噪音。写代码任务通常5到8轮就该出明确结果如果超过这个轮次还在原地打转大概率不是差一轮对话的问题而是该换上下文模式或重新整理提示词了。6. 一张可以直接照抄的模式决策清单把前面所有讨论浓缩一下我平时在项目里是这样做选择的。6.1 任务-模式对照表任务类型推荐上下文模式操作提示修复单函数内的Bug选区模式同时选中依赖的常量和辅助函数在现有文件里新增函数文件模式提示词里写清预期行为和约束统一调整文件内多处逻辑文件模式若文件超500行拆成区域处理跨文件排查调用链仓库模式或指定文件夹显式提名关键文件路径大规模重构Agent模式分步执行每次只授权一个子目标讨论架构、设计方案对话模式不需要喂具体代码给摘要即可这个表格是我自己贴在显示器边的备忘遇到拿不准的情况就先对着它过一遍。大部分情况下模式选对了AI的输出质量就已经及格了剩下那部分分数靠的是第五部分所说的上下文设计。6.2 使用清单前先回答自己两个问题第一个问题这个任务真的跨文件吗如果答案是否定的就果断回落到更小的模式。你不需要为了一个单函数修改付出全仓检索的代价那是拿大炮打蚊子。第二个问题你希望AI改动多大范围希望改动范围越小上下文模式就应当越窄。这不是限制AI恰恰是保护你的需求不被稀释。AI的发挥一旦超过你划定的边界就会从帮忙变成添乱。这两个问题想清楚模式选择基本不会出错。剩下的就是在选好的模式里把上下文内容做扎实文件路径点到位、约束说清楚、验收标准写明白。我在大量项目里试下来最深的体会是上下文模式不是一个需要调教的玄学它只是人给AI划定信息边界的方式。你越清楚自己想让AI看到什么、不看到什么AI就越接近一个靠谱的协作者而不是一个偶尔灵光乍现的自动补全工具。先把视野管好再谈让AI写得更好。 AI编程上下文模式怎么选？视野决定代码质量
1. 先纠正一个误区AI不是全知的神它的视野由你决定1.1 上下文模式不是话术风格而是AI的视野范围很多人第一次接触 context-mode会把它理解成语气开关觉得选简洁就是少说废话选详细就是多写注释。这是最典型的误解。上下文模式真正控制的是AI在回答问题之前到底读了哪些材料。我在本地项目里做过一个简单的对照实验。同样的需求——给fetch_user_profile函数补充异常处理三次提问分别只给函数体、给整个文件、开全仓索引用仓库模式。结果很有意思只给函数体的那次AI做的是最小改动逻辑干净但完全没考虑调用方默认它不会抛错的约定给整个文件的那次AI自动沿用了同文件里其他API函数的错误处理风格基本不需要二次修改开仓库模式的那次AI甚至开始沿着导入关系去翻其他模块最后给出的方案里包含了一个文件里根本不存在的基础类明显是想当然。这个实验后来我重复过很多次结论从来没变过不是模型变笨了是模型看到的东西变了行为就会跟着变。你喂给它的代码范围就是它的世界观。1.2 一个类比远程会诊的读片范围我常用一个医疗类比来理解上下文模式。你请一位专家会诊只给他一张CT片子选区模式他的判断一定聚焦在片子上快但也容易忽略既往病史的影响如果你把他带进病房让他翻阅整套病历文件模式他能结合历史情况做综合判断可你要是把整个医院的病例库都搬给他仓库模式他反而可能被大量无关信息干扰甚至把某个偶然扫到的罕见案例当成你的主诊断。这个类比解释了为什么上下文越大越好是错的。对于AI编程助手来说上下文模式的选择本质上是你在替模型做一次信息筛选哪些代码必须看见哪些代码最好别看。筛得好模型的判断力会明显上一个台阶筛得不好模型就变成一个知识渊博但严重偏题的实习生。1.3 视野决定行为行为决定代码质量代码质量不是抽象概念它由一个个具体的约束组成现有函数的命名习惯、同模块的异常处理约定、数据层的访问边界、调用方的隐式假设。这些约束分散在代码里模型默认是看不到的除非你通过上下文模式让它们进入视角。上下文模式选得对不对直接决定了AI是在你的约束范围内做优化还是在它自己脑补的约束范围内发挥。后者产出的代码看起来头头是道放进项目里往往第一个Review就过不了。2. 底层机制拆解上下文窗口、注意力偏差与工具端的检索理解了视野这层接下来要钻进去看机制。因为只有明白机制你才知道什么时候应该手动干预上下文而不是傻等工具自己处理。2.1 上下文窗口是硬约束token预算要心里有数所有AI模型一次能处理的内容量都有一个上限叫上下文窗口。这个窗口按 token 计量而不是按行数或者字符数。中文场景下一个汉字大约占1到2个token英文大约4个字符折合1个token。一个典型的2000行代码文件如果完整喂进去轻轻松松占掉一两万token。这个数字意味着什么主流AI模型的上下文窗口虽然动辄几十万token但你的预算是共享的既塞了代码也塞了对话历史还要给模型的输出留位置。如果在上下文里堆了一堆无关文件真正关键的接口约束可能就被挤到窗口边缘。我自己写了一个小工具来估算每次粘贴的内容量逻辑很简单def estimate_tokens(text): cn_chars sum(1 for ch in text if \u4e00 ch \u9fff) other_chars len(text) - cn_chars return int(cn_chars * 1.5 other_chars * 0.28) sample open(target_file.py).read() print(roughly, estimate_tokens(sample), tokens)不需要精确够估算就行。当一次任务的全量上下文估算超过两三万token时我就会主动开始做减法而不是继续往里堆。2.2 位置偏差模型更擅长记住开头和结尾大语言模型在超长上下文里的表现并不是一条平坦的曲线。过去两年有不少团队做过针对性研究结论高度一致模型对上下文开头和结尾的信息利用率明显更高夹在中间的内容则容易被稀释。业界管这个叫 lost in the middle意思是中间部分在注意力机制里天然吃亏。这个结论落到实操里非常值钱。既然中间区域容易被忽略我在组装给AI看的材料时就遵循一个原则最关键的事实放开头最后的指令和要求放结尾参考资料和辅助细节放中间。比如仓库模式下第一句话永远是下面这个问题涉及A服务和B服务核心代码在xx路径最后一段永远是最明确的指令——只修改xx不要动其他文件。这么安排之后AI理解任务的成功率提升非常明显。2.3 工具端其实帮你做了预筛选另一个经常被忽略的点是当你选择文件模式或仓库模式时AI助手并不是真的把项目所有代码一字不差地喂给模型。工具端会先做一层预筛选——通过语法分析提取符号和结构、用向量化检索计算代码与问题的相关度、再把命中的文件按得分排序拼进上下文。这也是为什么你在仓库模式下会感觉AI好像真的懂我的项目因为它确实读了部分索引但读的未必是你最在意的那部分。理解了这一层就会明白一个特别重要的推论工具替你做的预筛选本质上是一种概率猜测它不一定猜得准。所以不要把它会自动看代码当成理所当然。关键时刻你需要在提示词里显式点名关键路径把工具检索的偶然性降到最低。这个点我在第五部分会展开讲。3. 四种常用上下文模式的分工边界与选型逻辑这一部分进入实操。我把日常用得最多的上下文模式归纳为四种选区模式、文件模式、仓库模式和Agent模式。不同工具的菜单名可能不一样但底层逻辑高度一致。3.1 选区模式精确制导适合改动既有函数的局部行为选区模式有的工具叫只读选中内容适合处理局部性非常强的任务给一个现有函数补异常处理、优化一个循环、调整一段逻辑的顺序。这种模式下模型只看到你选中的代码块视野最窄因此不会受到同文件其他部分风格的影响也不会冒出翻别处代码的冲动。结果通常可控、可预期、改动量小。但选区模式有一个明显的短板你选中的函数往往依赖文件顶部定义的常量、类型和工具函数这些依赖不在上下文里模型就只能猜。为了补偿我会在提示词里把必要的外部依赖补一句比如这个函数里的logger是标准logging模块的实例LogLevel来自common/constants.py。有个更稳妥的折中方案不要只选中函数体而是把该函数所在类的声明区域或者紧邻的辅助函数一起选中再把提问范围严格限定在目标任务上。这样既保持视野小又给了模型足够的锚点。3.2 文件模式当前文件的全景地图日常高频的甜点位文件模式是大多数日常任务的最佳选择。模型能看到当前整个文件包括导入语句、其他函数、类的整体结构。这意味着它不需要脑补同文件的约束自然能模仿文件里已有的风格和约定。我自己的经验是如果任务要求新加一个函数到某个文件或者统一调整某个文件中多个函数的错误处理方式文件模式几乎是唯一正确的选项。它比选区模式信息多又比仓库模式噪音少推理速度也理想。需要留意的是文件规模。项目里有些文件动辄上千行全量塞进去同样会造成上下文拥挤。这种场景我不会直接开文件模式而是先手动拆分目标函数区域或者用工具自带的限定文件内某一片区域的能力。判断标准很简单这个文件超过500行且任务只涉及其中一小段就回到选区模式加手动补充依赖文件在300行以内且任务涉及文件整体就放心开文件模式。3.3 仓库模式跨文件问题的重武器要有节制地用仓库模式解决的是真正涉及多个文件的问题一个功能跨服务调用、一个Bug需要沿着调用链排查、或者一次涉及十几个文件的重构。这种任务的共同特点是单文件视角下根本没法给出靠谱答案。但仓库模式的开销和风险也是最高的。一方面它要消耗大量token做检索和汇总另一方面模型在检索到的海量代码中更容易做出过度联想把本不该动的代码一并纳入修改范围。我给自己定了一个使用门槛只有当任务描述里至少要提到两个不同路径的文件时才考虑开仓库模式。如果任务只涉及单个文件内的事情无论看起来多复杂都不要开。此外如果工具支持指定文件夹这种中间档优先选它而不是整个仓库效果会稳很多。3.4 Agent模式放权给AI自主搜索但必须给足护栏Agent模式是最近两年AI编程工具里发展最快的方向。它和前面几种模式的本质区别在于AI会自己决定去看哪些文件、执行哪些步骤直到完成任务。好处是彻底解放了手动喂上下文的动作坏处是它自主行动的前提假设一旦出错会把错误放大。我对Agent模式的态度是可以用但提示词里必须写清楚两件事——第一允许它读哪些范围例如只允许查看src/和tests/目录不要读docs/和scripts/第二禁止它做什么例如禁止修改除了src/core/cache.py以外的文件。这就像给实习生派活你把场地边界画清楚他才能在边界内发挥。另一个实用技巧是分步授权不要一上来就让它完成一个大重构而是先给一个小目标比如找到缓存失效的原因等它对问题的分析符合预期后再通过追加指令让它继续下一步。把Agent模式当成一个可以随时叫停的协作者而不是撒手不管的自动编程机。4. 踩坑实录我把能翻的车基本都翻了一遍理论讲再多不如一次具体的翻车现场有说服力。下面四个坑全是发生在我自己项目里的真实案例。每个我都写清楚了当时的错误决策和后来的修正方式。4.1 翻车一全仓模式改一个三行BugAI顺手重构了整个模块某次我接到一个线上告警client模块抛TypeError原因是某个配置校验函数少判断了一种输入类型。问题很小正常十分钟就能改完。我图省事直接在仓库模式下让AI修然后在指令里写了句顺便看看有没有类似问题。结果AI不仅改了那个函数还按照它理解的更优雅的写法重写了整个校验模块删了两个旧函数新抽象了一个基类。代码确实写得漂亮但它违反了团队约定而且直接引发下游六个调用点报错。我花了整整半天把重构回滚重新精改。教训就一句话修Bug的时候上下文越小越好。你让AI看到的越少它自作主张的空间就越小。后来我把需求改成只修复is_valid_config函数里的类型判断分支其它任何代码不要动同样是仓库模式AI果然一笔多余改动都没有。4.2 翻车二只贴函数体AI脑补出错误的接口契约有次我处理一个数据管道报错想快速让AI分析某段解析逻辑。当时觉得整个文件太长只选中了异常附近的20行贴进对话。AI很快就给出了分析信誓旦旦说问题出在异步迭代未做并发保护。我按照它的建议改了代码一跑照样崩。仔细一看才反应过来那20行代码根本不在异步函数里AI之所以这么推测是因为它看不到函数定义和调用上下文于是用最常见的模式脑补了一个异步场景。后来我换了个做法先把整个函数和调用它的地方一起选中再让AI分析。上下文一补全它立刻指出真正的问题在于上游传入的数据结构里嵌套了一层意想不到的None。对比非常强烈。这让我彻底记住了你贴给AI的代码必须是它做判断所需的最小子集而不是你顺手复制的那一段。4.3 翻车三在Chat窗口讨论跨文件逻辑全程梦游还有一种高频翻车是上下文模式本身用对了但聊天历史里积累了很多不相关的话题。比如我先让AI帮忙写过一段正则聊了不少无关细节然后紧接着问它一个完全不同的跨模块问题。结果AI的回答明显受到前一个话题的影响甚至把正则的转义符方案套到了数据库查询上。问题出在我自己没有在切换任务的时候清理上下文。Chat窗口不是人脑前一个任务留下的中间分析不会自动归档它们会继续占用注意力并污染后续回答。现在我的习惯是一旦任务类型发生切换立刻新开一个会话哪怕只是从写正则切到查数据管道。省下来的token和困惑远比重新描述一次背景的成本划算。4.4 翻车四大仓库里AI像被搜索引擎背刺某次排查支付回调的重试逻辑我开了仓库模式明确描述了异常现象。AI给出的第一个结论完全跑偏它盯着一个名称相似但完全是另一业务的支付对账模块分析了一整页。原因不难理解工具端预筛选靠的是语义相似度而支付这个词足够相似把对账模块也拉进来了反而把真正的回调模块挤到了排序后面。模型没有错是检索阶段给了它错误侧重的证据。事后我的修正方案是在提示词里显式点名关键文件路径核心逻辑在src/payment/callback.py请以这个文件为主分析其它模块只做引用参考。加了这一句之后AI的注意力立刻被拉回来。检索工具不是搜索引擎你可以用显式点名强行纠正它的排序倾向。5. 高质量上下文动手实践与其找模式不如造上下文懂了机制、看过了翻车案例接下来才是提升空间最大的部分——主动去设计上下文。上下文模式只是帮你打开视野真正决定AI上限的是你喂给它的内容质量。5.1 给AI建一份项目地图我强烈建议在大型仓库的根目录维护一个简短的上下文说明文件比如 AI_CONTEXT.md。内容是固定的几项项目入口在哪、核心目录结构、必须遵守的约定、容易踩的坑。这个文件存在的意义是让任何上下文模式下的AI都能在一开始就读到你的世界观。# 项目上下文速览 - 入口app/main.pyFastAPI启动端口8000 - 配置config.yaml禁止硬编码环境变量 - 数据访问repository/ 目录下的仓储类service层禁止直接写SQL - 异常统一抛自定义 BizException错误码在 errors.py 定义 - 测试tests/ 下按模块建文件夹跑测试用 pytest -q为什么会有效因为模型在面对一个陌生项目时最缺的就是最重要的几条规则。你把这个文件塞进上下文相当于在它动手之前先给它做了十分钟的项目介绍。很多工具在仓库模式下会自动读取这类说明文件但即便不自动读你也可以在提示词里用一句先读AI_CONTEXT.md把它拉进来。5.2 把验收标准写进提示词而不是只给代码大多数人的习惯是把代码贴过去然后说帮我改改。这其实是最低效的提问方式。高质量的上下文不只是代码还包括任务背景、预期行为、约束和验收标准。我总结了一个简单公式背景一句话 现状位置 预期行为 明确约束 验收标准。举个例子同样是让AI优化一个函数背景用户反馈批量导入速度很慢瓶颈疑似在逐条插入。 现状src/importer.py 的 insert_batch 函数约120行。 预期把逐条插入改为批量插入保持对外行为不变。 约束不新增第三方依赖保持日志格式不变事务仍由调用方控制。 验收改造后跑通 tests/test_importer.py 全部用例单批1万条耗时下降50%以上。这样一段上下文模型几乎不可能走偏。它知道自己要完成什么、边界在哪、怎么判断自己是否做对了。很多时候AI产出的方案不行不是模型能力不够而是你根本没让它知道做成什么样才算合格。5.3 显式提名关键文件把检索偶然性压到最低上一节翻车案例里提到过仓库模式的检索可能抓错重点。对应的通用解法就是我一直在用的显式提名在提示词里把所有你希望模型聚焦的文件路径直接写出来。这个做法还有一层作用它等于告诉模型这些是定海神针其他信息都只是参考。很多工具内部会把提示词里出现的文件路径做加权处理让这些文件在检索排序里获得更高优先级。即便工具没有这个机制模型对显式提到的路径也会更注意这是两个层面的双重保险。如果任务涉及的文件清单很长我会先做一个简单的路径清单而不是在中间反复穿插。开头列一次结尾列一次开头给事实结尾下指令呼应前面讲过的位置偏差原理。5.4 用约束回填做自我纠正比反复说不对更高效人机对话里最让人恼火的时刻是改了几轮还在犯同一个错误。传统做法是继续在对话里说不对还是有问题然后重复贴代码。效率很低而且历史越长模型越容易混乱。这里有个更高效的技巧当AI的方案偏离你的约束时不要笼统地说不对而是直接把那条约束作为新的事实补进上下文并附带出处。比如注意调用方在 src/process.py 第120行已经假设该函数永远返回非空列表因此不要新增返回None的分支。这条新信息会像一根桩一样钉进对话模型基于它重新推导时往往一两轮就能修正方向。我把它称作约束回填本质上是把纠错过程变成一次上下文补充。你不是在告诉模型你错了而是在告诉它你还缺一个关键事实。5.5 控制轮次及时清空无关历史最后一个建议最便宜但见效极快任务一旦切换马上新开会话。对话历史在上下文窗口里占据的体积比想象中大得多而且每一轮累积的中间推理对后续任务基本都是噪音。写代码任务通常5到8轮就该出明确结果如果超过这个轮次还在原地打转大概率不是差一轮对话的问题而是该换上下文模式或重新整理提示词了。6. 一张可以直接照抄的模式决策清单把前面所有讨论浓缩一下我平时在项目里是这样做选择的。6.1 任务-模式对照表任务类型推荐上下文模式操作提示修复单函数内的Bug选区模式同时选中依赖的常量和辅助函数在现有文件里新增函数文件模式提示词里写清预期行为和约束统一调整文件内多处逻辑文件模式若文件超500行拆成区域处理跨文件排查调用链仓库模式或指定文件夹显式提名关键文件路径大规模重构Agent模式分步执行每次只授权一个子目标讨论架构、设计方案对话模式不需要喂具体代码给摘要即可这个表格是我自己贴在显示器边的备忘遇到拿不准的情况就先对着它过一遍。大部分情况下模式选对了AI的输出质量就已经及格了剩下那部分分数靠的是第五部分所说的上下文设计。6.2 使用清单前先回答自己两个问题第一个问题这个任务真的跨文件吗如果答案是否定的就果断回落到更小的模式。你不需要为了一个单函数修改付出全仓检索的代价那是拿大炮打蚊子。第二个问题你希望AI改动多大范围希望改动范围越小上下文模式就应当越窄。这不是限制AI恰恰是保护你的需求不被稀释。AI的发挥一旦超过你划定的边界就会从帮忙变成添乱。这两个问题想清楚模式选择基本不会出错。剩下的就是在选好的模式里把上下文内容做扎实文件路径点到位、约束说清楚、验收标准写明白。我在大量项目里试下来最深的体会是上下文模式不是一个需要调教的玄学它只是人给AI划定信息边界的方式。你越清楚自己想让AI看到什么、不看到什么AI就越接近一个靠谱的协作者而不是一个偶尔灵光乍现的自动补全工具。先把视野管好再谈让AI写得更好。