★ FEATURED ARTICLE 我从今年年初开始重度依赖 AI 编程助手之后踩得最深的坑不是模型能力不行而是“它明明看过我的项目却总是答非所问”。后来我才意识到问题出在上下文上——它确实看到了很多文件但看到的太多反而不知道该看什么。后来我把目光放到“context-mode”这个功能上才算是把 AI 辅助开发这件事从“能用”推到了“好用”。如果你也在用 AI 工具写代码整天被“改一版错一版”折磨那这篇文章值得看完。我尽量不写概念全讲实操把我这段时间调试上下文、配置模式、踩坑排雷的经验都摊开来讲。1. 先搞清楚上下文模式到底管的是哪件事1.1 一段典型的“越改越乱”会话先还原一下我早期的真实工作流。我有一个微服务项目代码量不算大大概两万行但模块之间依赖关系复杂。某天我想让 AI 助手帮我改一个订单状态机原本以为它看一眼相关文件就能改明白。结果我贴了一大堆东西进去订单模型、支付回调、异步任务、仓储接口、控制器路由、数据库迁移脚本基本上把整个订单域的文件都拖进了会话。一开始 AI 回答得很积极给出了一个看起来相当完整的修改方案。可等我让它落到具体代码时问题来了——它改了 A 文件但没改调用 A 的 B 文件我提醒它之后它说“抱歉我刚才没注意到 B 文件里还有一处地方引用了这个方法”然后又补了一版。这版补完C 文件里的某个常量又对不上了。最离谱的是当我把所有文件都丢进去之后它甚至开始“脑补”一些并不存在的配置项一本正经地回复我“请确认order.status字段在迁移脚本中有定义”。我当时人都麻了这玩意儿到底有没有在看我给的文件后来我才知道这堆问题的根源是我犯了上下文管理的大忌给 AI 的东西太多而且没有区分哪些是“任务相关的”哪些只是“项目里恰好存在但这次不需要的”。模型不是人它不会自己判断“这和当前目标无关我忽略掉它”。你给了它噪音它就会把噪音当成线索。1.2 Context Mode 的本质给 AI 划定“看得见”的范围那 context-mode 解决的是什么呢用一句最直白的话说它帮你决定“本次任务里模型到底能看见哪些信息”。现在各家 AI 工具都在卷上下文窗口动辄几十万 token。听起来很美好好像整个代码库都能塞进去。但“能塞进去”和“该塞进去”是两码事。模型处理长文本时注意力会快速衰减尤其是当无关信息占了绝大多数时它更难抓住真正关键的那些约束条件。我打个比方你去图书馆查资料如果管理员一次性把整栋楼的书都搬到你面前让你自己找你反而会崩溃。你真正需要的是让他根据主题先划出几个书架再帮你挑出最相关的那几本。Context Mode 干的就是这个“先划书架”的活。它通过规则、索引、白名单等机制把模型可见范围限制在一个可控集合里。比如我改订单状态机的时候只需要把状态机定义、事件枚举、对应 Service 方法、状态变更记录表结构这四类东西喂给它其他的比如支付网关配置、消息队列 topic、前端路由一概不进上下文。这样一来模型的每次回答都建立在一个“小而准”的信息基础上而不是在几十个文件的噪音里猜来猜去。1.3 它和普通“多轮对话”不是同一个东西这一点我觉得特别值得讲一下因为很多人以为自己开了个新会话就已经在“管理上下文”了。普通的连续对话是把你之前每一轮问的内容、回答的内容全部保留逐字累积。它的问题是没有优先级、没有衰减、没有过期机制。哪怕上一轮已经在讨论另一个模块了前几轮的对话记录还是占着上下文窗口还在影响后续回答。你问东它记着西。Context Mode 的做法不一样它通常会把上下文拆成几层静态上下文项目说明、目录结构、风格规范、架构约束这些是每次会话默认带上的任务上下文针对当前目标动态注入的文件、摘要、日志片段对话上下文当前会话中产生的临时讨论内容有长度限制超出后自动精简。所以我一直强调Context Mode 不是“增强版多轮对话”而是从底层把上下文的组织方式改掉了。它让模型每次回答时看到的不是“一串越来越长的聊天记录”而是一份“围绕当前任务精选过的资料包”。2. 为什么我说这是 AI 辅助开发的“第二增长曲线”2.1 上下文长度不是越多越好很多人有一个误解上下文窗口越大AI 越聪明。我前阵子也这么想过总觉得“只要我把整个项目都喂进去它一定能给出完美建议”。后来被现实反复教育。有研究者很早就观察到一个现象模型处理超长文本时对中间部分的信息利用率明显低于开头和结尾。你塞了一大堆东西进去模型真正“认真看”的可能只有最前面的系统提示词和最后面的最近几条消息中间的文件内容基本属于“看了但没记住”的状态。我在实战中也验证过这一点。有次做一次接口重构我把十几个文件全部塞进对话里每个文件几百行想让它统一协调修改。结果它改了开头给出的接口定义然后又改了最后粘贴的控制器但中间那几个服务实现文件里的调用点它漏得一干二净。这不是模型笨是信息排列方式有问题——它把注意力都分给了上下文的首尾部分中间细节直接被忽略了。Context Mode 的价值就在这里它通过压缩和筛选让送进模型的信息量永远保持在一个“注意力能覆盖”的阈值内。比如同样是那次重构后来我用聚焦模式只喂了四个文件接口定义、实现类、调用方、单元测试。结果它一次改全了连测试里的 mock 数据都跟着调整了。2.2 结构化注入比一股脑倒进去更可靠除了控制总量Context Mode 还有一个更先进的做法叫“渐进式披露”。这个词听起来绕其实就是先给模型看摘要让它按需决定要不要看细节。我举个例子你就明白了。正常人搬家不会把整个家的东西一次性全搬到新房子门口再想怎么归置。你一定是先搬大件家具再拆包小物件用到哪个箱子里的东西再拆哪个。渐进式披露就是这个逻辑。我在实际使用中会这样操作先让工具加载项目的 README、整体架构说明、模块依赖关系图文本版模型基于这些信息形成一个“全局认知”。接着我提出一个具体需求比如“把订单超时处理从轮询改成延迟消息”它会根据全局认知判断需要看哪些细节再主动拉取对应的代码文件。这个过程比我以前“先把所有可能相关的文件都拖进去”要可靠得多。因为模型的每次判断都建立在已经理解了顶层结构的基础上不会一上来就掉进某个文件的实现细节里出不来。2.3 不同开发阶段该用哪种模式Context Mode 一般会提供好几种预设模式我用了这么久觉得可以根据场景粗暴地分成三类场景推荐模式加载内容注意点新项目接手/梳理代码库全局概览模式项目结构、README、依赖清单、配置入口单次 token 消耗较大适合一次性任务改 bug / 局部重构聚焦模式目标文件、相关调用方、错误栈、测试用例别把无关文件顺手加进来新功能开发渐进式模式需求描述、相关模块摘要、按需展开文件先确认模型理解需求再让它改代码这里我想点名一个容易犯的错很多人一上来就打开“全项目模式”把所有东西喂进去让模型帮你分析。听起来很美但对日常开发来说全量加载往往意味着大量冗余信息占据上下文窗口反而拉低了回答质量。我个人的经验是全量模式只适合“首次了解项目”和“做全局影响面评估”这两件事日常改动用不到。3. 实操记录把 Context Mode 用起来的几个步骤3.1 前期准备先把“默认上下文”配置好很多人在用 Context Mode 的时候感觉没效果其实是因为静态上下文这一层根本没配。什么叫静态上下文就是那些你希望模型每次回答时都默认了解的信息。比如项目的技术栈、目录结构、代码风格规范、禁止事项不允许改哪些文件、架构约束数据库只能走 repository 层访问。这些信息如果不预先配置模型每次遇到相关问题就得现场猜。我自己的做法是先把这些信息整理成一份.context.md之类的项目说明文件放在项目根目录然后把它加入 Context Mode 的固定加载清单。文件内容不在多而在结构清楚项目order-service 技术栈Java 17 Spring Boot 3.2 MyBatis 架构约束 - 业务逻辑必须放在 service 层controller 不做业务判断 - 数据库访问只能通过 repository 层禁止在 service 里直接写 SQL - 所有状态变更必须走状态机禁止直接修改 status 字段 模块说明 - order-api对外接口定义 - order-service核心业务逻辑 - order-infra数据库、消息队列等基础设施你不用把它写成正式文档只要把平时反复跟 AI 强调的那些“烂熟于心”的规则写进去就能省掉大量重复说明。配置好之后你会发现AI 回答的“味”会完全不一样不再是通用程序员的口吻而是真的像了解你项目的同事。3.2 会话中如何正确“切换模式”以我用的工具为例Context Mode 通常支持在会话中临时指定加载范围。我一般会按这个流程来开场明确目标先说实话告诉模型“我要做什么”不给它猜的机会指定加载范围用命令或 语法把相关文件加入上下文别用粘贴直接用文件引用设定边界说明哪些文件“不要看”、哪些规则“不能破坏”先出方案再改代码让模型先基于上下文输出修改计划等我确认了再让它动手。这里放一个我最常用的提示词模板你可以直接抄【当前任务】 修复订单超时后未正确触发取消流程的问题。 【上下文范围】 请加载以下文件到上下文 - order-service/src/main/java/.../OrderTimeoutJob.java - order-service/src/main/java/.../OrderStateMachine.java - order-infra/src/main/java/.../OrderRepository.java 【不需要关注】 - 支付回调相关的逻辑本次不涉及忽略相关文件 - 不要修改数据库脚本只改 Java 代码 【输出要求】 先分析可能导致超时未取消的三个原因再给出修改方案最后再改代码。这句话一说模型基本就不会乱跑了。它只会聚焦在给定的三个文件上不会突然给你扯出支付、登录、消息推送这些东西。实际效果比我以前“帮我看看这个订单为啥超时没被取消”然后等着它自己乱翻代码要好上不止一个量级。3.3 善用“摘要归档”压缩历史上下文Context Mode 虽然帮你控制了静态和任务的上下文但会话中的“对话上下文”还是会越积越多。尤其是那种一次性能聊上几十轮的复杂改版到最后模型还是会开始“忘事”。这时候我常用一个笨但很有效的办法聊到一定阶段会主动让模型把当前结论固化成一份摘要然后把这条摘要当作新一轮会话的起点。比如我会说“请把当前确认的技术方案整理成 300 字以内的摘要包含已决定的改动点、尚未确认的问题、以及下一步计划。我会用这段摘要开启新会话继续。”然后再新开会话先把这段摘要贴进上下文再按需加载相关文件。这样既能保留关键决策信息又能把之前几十轮闲聊、试错、失败进度的垃圾信息全部扔掉。这个过程本质上就是在手动执行 Context Mode 的上下文归档逻辑。4. 我踩过的坑和排查实录4.1 症状一AI 的回答总是“泛泛而谈”这是最容易出现也最容易被忽略的问题。如果模型给你的回复特别像教科书什么“建议优化系统架构”“需要提高代码可维护性”这种正确的废话那多半是上下文里缺少项目特定信息。我当时排查过一轮发现原因就是静态上下文没配好。它根本不知道你的项目有哪些类不知道你的代码风格只能给通用建议。解决办法也很简单把项目说明文件、核心实体定义、主要流程说明加进默认上下文。加了之后AI 回答里开始出现具体的类名和方法名这才是它“看进去”了。排查清单项目根目录有没有.context.md之类的说明文件该文件是否被加进了固定加载清单配置之后有没有新开会话老会话不受影响4.2 症状二改动越到后面越错有一次我做跨模块重构会话开了很久聊了大概五六十轮。刚开始几轮 AI 的修改都是对的但越到后面它越频繁地出现“记不清前面做了什么”的情况。比如前面已经删掉的接口后面它又引用前面改过的字段命名后面它按旧名字重新生成了代码。我的排查结论上下文太久了旧的信息和试错记录严重干扰了模型判断。解决办法就是我上面说的手动做“摘要归档”强制开启新会话。新会话丢掉所有历史试错记录只保留经过验证的方案结论模型的输出质量立刻回升。现在我的习惯是超过二十轮且改动涉及多个文件时主动中断会话做阶段总结再开启新对话继续。看起来多了一步操作实际上节省了我反复纠错的时间。4.3 症状三模型总是忘掉我交代过的“禁忌”有段时间我反复跟 AI 说“不要动数据库迁移脚本”可它总是改了代码之后顺手去改迁移脚本害得我每次都得回退文件。后来才想明白临时在对话里说一个规则模型只能记住这一次但如果是长期项目约束必须把它写进静态上下文文件里。人的记忆是这样的模型的“记忆”更是这样。聊天记录里的要求是易失的但项目说明文件里的约束是每次固定加载的。把“禁止修改脚本”“所有异常必须包装成业务异常”“日志必须含 traceId”这类规则写进.context.md之后模型自己就会遵守我再也不用一遍遍重复交代了。4.4 上下文异常的通用速查表症状可能原因检查点处理办法回答泛泛而谈缺项目信息静态上下文是否配置补充项目说明文件修改不完整关联文件未加载检查本次会话加载清单补全调用方、实现类越改越乱历史上下文太长会话轮数/总 token 数做摘要归档开新会话重复犯同样错误规则未持久化规则是否在固定文件里写入项目级 context 文件回答前后矛盾引入了无关文件查看当前上下文文件列表移除无关文件缩小范围关注了错误位置没有任务边界提示词是否明确目标指定“本次不涉及哪些模块”4.5 一点独家心得上下文管理是一等公民这个总结我不想说得太抽象直接讲个最终感受我以前把 AI 编程助手当成“更智能的搜索引擎”后来才把它当成“一个记性不好的实习生”。你不能指望它自己知道什么重要什么不重要你得主动替它划重点。Context Mode 这个东西本质上就是给 AI 画了一间“视线范围”内的小屋让它专心处理屋里的事别老盯着窗外看。配置好它之后AI 的回答质量不是一点点提升而是质变级别的提升。我最近几周基本没再遇到过“改完 A 崩了 B”的循环因为每次动手前模型看到的就是那几块正确的内容不可能跑偏。如果你刚开始用这个功能我建议别一上来就研究所有模式先做两件事第一把项目说明文件写好配进默认上下文第二以后每次会话前明确告诉模型“该看哪些文件、别碰哪些文件”。就这两步你就能感受到明显的区别。剩下的各种高级玩法都是在这两步的基础上延伸出来的。
阅读完成 · 觉得有帮助？
