你有没有过这种经历让AI助手改了一上午代码对话窗口拉得老长结果处理第二个问题时它突然反问你“这个配置文件是在哪个目录来着”这不是模型变笨了多半是context-mode没有调好。这里说的context-mode不是某个单一功能的名字而是所有以LLM为核心的编程工具在处理“哪些上下文该进模型、进多少、保留多久、什么时候压缩”时采用的一组策略与模式的统称。它决定了模型能记住什么、会忘记什么也直接决定你每月花在token上的成本。如果你是重度用AI写代码的人这篇文章值得看完因为那些“模型失忆”“答非所问”“越改越乱”的现场根源大概率都在这里。1. 模型突然“失忆”问题多半出在context-mode1.1 一次典型的丢上下文现场上个月我在重构一个支付模块。上午刚和AI讨论完订单状态机的设计把订单创建、支付中、已支付、已退款这几个状态以及各自的迁移条件都敲定了。下午我想让它顺手补一个校验逻辑支付中状态下不允许重复发起支付。结果它给出的代码里把状态常量当成了新东西居然自己定义了一个PENDING_PAYMENT和之前约定的STATUS_PAYING完全对不上编译直接报错。当时我的第一反应是“这模型怎么转头就忘”。后来查了下工具底层的日志才发现问题出在上下文管理策略上当前对话窗口虽然保留了最近几条消息但工具默认把更早讨论过的文件内容从活跃窗口里摘了出去只留了一行“总结摘要”。模型看到的是一条被压缩过的概括而不是当时逐字讨论的状态机定义。于是它只能靠猜一猜就错。这就是context-mode里最常见的默认策略带来的坑自动压缩历史、自动裁剪文件、按最后活跃度决定哪些内容留在窗口内。大多数情况下它够用但遇到对细节精度要求极高的改动这种“优雅降级”就会让你在错误结果上反复折腾。1.2 context-mode的两个构成要素我后来把context-mode拆成两件事来理解入口选择和生命周期管理。入口选择解决的是“模型到底能看到哪些内容”。比如当前打开的文件、最近聊过的对话、被引用的文件、代码库的索引摘要、终端输出、项目规范文档这些都是上下文候选。不同策略会决定哪些内容被真正送进模型窗口。生命周期管理解决的是“这些内容在窗口里怎么流动”。窗口总有上限对话越长早期内容越可能被截断或压缩。自动摘要、滑动窗口、手动清理、触发压缩的阈值都属于这一层。这两件事经常被混在一起但实际诊断问题时要分开看。模型“看不见最新的改动”那是入口选择的问题模型“忘了三天前讨论的结论”那是生命周期管理的问题。把这两层拆开之后调整context-mode就有了明确方向。上下文内容常见默认处理方式容易出的问题最近几轮对话完整保留长对话后占用大量窗口更早的对话自动压缩成摘要关键约束丢失当前打开的文件高频注入文件过大时仍会截断被引用的文件显式注入用户忘记引用就看不见代码库索引摘要按相关度召回召回不准导致答非所问项目规范文档随会话启动加载隐性占用大量token2. 全自动、半自动、全手动三种context-mode的真实体验差异2.1 全自动模式省心但窗口容易被“垃圾”占满全自动模式是大多数工具的默认选项。它的逻辑很简单把所有“可能相关”的内容一股脑塞进窗口让模型自己挑重点。刚上手时非常爽不用费心告诉模型看哪个文件它仿佛全知全能。但用久了你会发现两个问题。第一窗口很容易被无关内容占满。我在一个前后端分离的项目里把代码库索引阈值设得很大结果一次请求携带的索引摘要就有两三万token。真正相关的代码只有几百行剩下的全是“类似但没直接关系”的模块。模型在大量噪音里找信号判断力反而下降。我遇到过它把另一个模块的配置照搬到当前模块、然后一本正经解释“这是最佳实践”的场面。第二全自动模式会把所有历史对话都当作上下文。你上午让它改了三版设计、试过五条路线这些讨论全留在窗口里。下午正式动手时模型会倾向于“延续最近的风格”哪怕这条路已经被你否掉了。上下文是连续的但人的注意力是有意筛选的全自动策略把这两者混为一谈。我倒不是否定全自动它在“读一段陌生代码库”的时候确实好用相当于让模型先做全量扫描再回答问题。只是你要清楚这是一个用token换便利的模式不适合所有任务。2.2 按需注入模式上下文干净但考验操作纪律按需注入是我现在的主力模式。它的核心是不让模型自动猜而是由你显式声明“接下来要关注哪些内容”。操作上通常体现为在提问里带上文件路径比如“参考src/core/payment.ts和src/types/order.ts帮我改一下支付状态机”或者用斜杠命令、快照功能把一组文件打包进上下文。与全自动最大的差异是你不提模型就看不见。这种模式的好处非常明显。上下文干净模型聚焦在你指定的那几个文件上不会跑去翻无关模块。token占用低费用和时间都降下来了。最关键的它逼你思考“这个任务到底涉及哪些文件”而这个过程本身就是在理清需求。缺点也直接如果你的清单漏了依赖文件模型会漏看关键定义。比如你只注入了接口定义没注入对应的实现它可能会按自己的想象补一个不存在的字段。所以这里需要一点纪律性每次动手前先列清单涉及哪些文件、依赖哪些类型、需要遵守哪些约束。养成习惯后这反而是性价比最高的模式。2.3 近似空白模式适合一次性小任务还有一类场景既不需要全自动也不需要精心组织上下文就是“近似空白模式”——几乎不携带项目上下文只靠对话和模型自身知识。我用它处理临时问题写一段一次性脚本、解释一段报错信息、把一段文本翻译成另一种风格的表达。这些任务不依赖具体项目细节给模型一个干净起点反而更好响应快、token少、没有无谓的代码搅局。但如果你拿它做跨文件的模块改造那就是自讨苦吃。模型没有项目的类型定义和依赖关系就只能输出通用解法然后让你自己往项目里套。在小项目里还能将就项目一复杂这种模式的返工率高得惊人。3. 配置context-mode时最容易踩的四个坑3.1 全仓库注入听起来强大实际上毒药第一次接触上下文配置的人很容易把“让模型看得越多越好”当成原则。我把一个包含大量第三方SDK的中型项目的索引范围扩展到全仓库后工具光是生成索引摘要就跑了十几分钟。之后的每次请求模型都要吞下几万token的目录结构和文件名列表真正的业务逻辑反而淹没在里面。后来的经验是索引范围最好按目录收窄。比如后端项目只索引app/和domain/测试代码单独开一个会话处理。把node_modules/、dist/、build/这类生成目录一律排除。模型不需要知道每个第三方库的文件名它需要的是你项目的核心骨架。这样做之后响应速度上来了答案的准确率也明显更好。3.2 别忽略系统提示词和工具注入的隐性占用有时你会觉得“我就没注入多少东西窗口怎么还是很快就满了”。看一眼工具提供的token分布统计往往会发现隐性占用系统提示词、编辑器主题映射、当前Git分支、最近的git log、快捷键说明、工具自带的代码风格指南这些加在一起可能就占了一两万token。我见过一个极端案例某工具默认在系统提示词里塞了完整的XML工具调用说明再加上语言模型自身的角色设定还没开始聊窗口就已经用掉了近八千token。在32k的小窗口里这相当于直接削掉了四分之一的可用空间。排查方法很简单大多数工具都提供类似“查看上下文使用情况”的命令它会列出各类内容占用的token比例。定期看一眼你才知道钱花在哪了。如果某个工具注入了一大堆你根本用不上的规则可以在配置里关掉对应的开关。3.3 自动摘要压缩会“优雅地”丢失关键约束窗口快满时工具会自动触发压缩把早期对话整理成一段摘要。这个功能救了很多人但它有个隐蔽的问题摘要追求的是“概括性”而不是“精确性”。安全校验规则、命名规范、特定业务的边界条件这类内容在压缩时最容易丢。我踩过一次很深的坑一个项目要求所有金额字段必须用Decimal类型不能用float。我在第一轮对话里明确要求过后续十几轮都遵守了。但窗口满了之后自动压缩这条约束被压成了“注意金额精度”。下次让模型新加字段时它很自然地用了float。从摘要的角度看它没做错但结果就是不合规。我的对策是如果某个约束特别重要不要让它只存在于对话历史里把它写进项目的记忆文件比如CLAUDE.md或AGENTS.md。这类文件在每次会话启动时都会重新注入天然避开压缩丢失的问题。另一个办法是在大任务进行到关键阶段前手动保存一个干净的会话快照避免中间讨论把窗口占满。3.4 上下文残留导致跨任务串味比丢失更让人头疼的是上下文“串味”。我试过一个工作区同时放两个项目的代码在同一个会话里先给Python数据脚本写了单元测试又切去改前端界面的按钮样式。模型输出前端代码时里面赫然出现了Python式的缩进注释风格甚至用#来写CSS里的注释。这是因为会话上下文里还残留着上一个任务的代码风格、术语和决策记录。context-mode只管理内容的注入和压缩并不会自动识别“你的意图已经切换了”。现在我严格按项目建会话并且在一个任务彻底结束后主动开启新会话。换任务前花十秒钟把窗口清空比让模型带着上一份记忆硬着头皮回答要划算得多。4. 按任务类型选模式我的context-mode实践清单4.1 三类典型任务应该怎么选实践下来我基本按任务类型决定context-mode的配置方向而不是只用一种模式包打天下。单文件重构、函数级优化适合按需注入。只把当前文件和它直接依赖的类型文件放进去窗口小、聚焦准。模型能把一个函数的前后逻辑看得很透改动质量最高。跨模块、多文件改动需要一点点全自动辅助。先让模型看一遍相关模块的索引摘要再显式指定需要修改的文件清单。顺序很重要先建立全局认知再聚焦局部改动。读陌生项目、追查线上问题全自动模式效果最好。这种任务本身就是在“探索”你根本不知道哪段代码里藏着答案让模型自己按相关性召回内容比人手挑选文件更高效。任务类型推荐模式原因单文件重构按需注入聚焦准token省多文件跨模块改动按需注入全自动索引先建立全局认知再动手读陌生代码库全自动探索阶段无法人工预判相关文件写一次性脚本近似空白不依赖项目上下文响应快代码审查按需注入只审查变更文件避免无关代码干扰4.2 手把手算token账配置context-mode时很多人对token的数量级没有概念于是要么盲目给大窗口要么拼命限制。我先给一个粗略的经验账本不同模型分词器有差异但数量级是通用的一段200字的中文对话大约吃掉200到400 token一个200行的Python文件大约吃掉3000到5000 token一个中型项目的目录结构摘要可能是一万到两万token按向量检索召回的相关代码片段每次请求大概几百到两千 token。如果你用的是OpenAI系模型可以直接用tiktoken库快速估算一段文本的token数。下面这段代码会打印出给定文本的token数量import tiktoken def count_tokens(text: str, model: str gpt-4o) - int: enc tiktoken.encoding_for_model(model) return len(enc.encode(text)) sample class OrderState: CREATED created PAID paid REFUNDED refunded print(count_tokens(sample))算清楚token账之后你设置窗口大小的依据就变了。比如一个200k窗口看起来很大但一个中型项目的全量注入加系统提示词可能瞬间用掉一半。这时候真正的问题不是“窗口够不够大”而是“该不该把这么多东西一次塞进去”。4.3 一套可抄的默认配置分享一套我目前的默认配置思路它更像一份配置模板不同工具的具体写法略有差别但核心参数是通用的。context_mode: preset: smart default_window: 64k entry_points: strategy: explicit-include includePatterns: - src/**/*.ts - tests/**/*.ts - docs/architecture.md excludePatterns: - node_modules/**/* - dist/**/* - build/**/* lifecycle: compact_strategy: manual compact_reminder_after_tokens: 50000 session_strategy: per-project重点说两个容易被忽略的参数。compact_strategy: manual意味着不做自动摘要压缩窗口快满时由我来决定是清理对话、缩小引用的文件范围还是开启一个新会话。自动压缩省事但前面说过它会弄丢关键约束我宁可多花几秒手动决策。session_strategy: per-project保证每个项目独立的会话上下文避免跨项目串味。5. 实测对比调整context-mode前后差多少5.1 测试设计光说经验不够我专门做了一次对比测试。需求选了最常见的一种给一个Python数据清洗函数补单元测试同时修改两个模块的接口调用。测试任务不算复杂但涉及跨文件改动足够暴露context-mode的差异。三个环境分别是全自动模式按需注入模式以及近似空白模式。同一份需求描述分别让模型独立完成记录首次完成时间、需要人工介入的修改次数、token消耗以及人工审查时发现的问题数。有一点要说明这个测试不是严谨的学术实验变量控制也很粗但趋势能说明问题。5.2 三个模式的结果对比结果出来后差异比我想象的更极端。模式首次完成时间人工介入修改次数token消耗审查发现问题数全自动模式约25分钟7次约142k3个按需注入模式约11分钟3次约61k1个近似空白模式无法独立完成—约35k6个以上全自动模式第一次给出的代码尝试改了很多我没提过的模块因为索引摘要覆盖面太广它把“相关”的判断标准放得太宽。从结果看像是很积极实际是到处动刀反而增加审查负担。按需注入模式代码聚焦很多问题主要是漏了一个公共常量定义补上之后三轮内就改到位了。近似空白模式则直接把了一个大坑它不知道项目里已有的数据清洗函数另起炉灶实现了一套还在测试里引用了不存在的类。5.3 复盘我现在默认怎么用这组数字让我彻底调整了习惯。过去我默认全自动觉得多给context更稳妥现在我的默认起点是按需注入再用全自动索引做探索阶段的辅助。具体到日常动作是这样的新任务先花三分钟列一份“上下文清单”写清楚要改哪些文件、依赖哪些定义、必须遵守什么约束。角色扮演聊天式的prompt能省则省让模型直接看代码和约束。改动范围一旦跨模块我会先让模型跑一遍相关目录的索引但明确告诉它“只用于理解不要主动改这些文件”。窗口用量接近阈值时不靠自动压缩硬撑而是手动清理历史、开新会话把已确定的内容固化到项目记忆文件里。如果你现在正被模型失忆、乱改代码、token消耗过高这些问题困扰先别急着换更大的窗口或更贵的模型回头检查一下自己的context-mode。很多时候只是从全自动改成按需注入多写一条include规则就能省下一半token还让模型记住真正重要的约束。这个动作花不了几分钟但效果比任何花哨的prompt都来得实在。