最近“context-mode”这个词在我常逛的几个技术社区里反复出现一开始我以为是某个新框架的独有概念后来才发现它其实代表了一类正在被普遍重视的能力AI 编程工具怎么去“看”你的项目。我最早对它有直观感受是在一个老项目里让 AI 助手帮忙改一个按钮样式结果它直接动了全局 CSS差点把整个导航栏搞崩。原因很简单它只看到了我贴给它的那个文件项目里其他几十个相关文件它一概不知。这个问题本质上就是上下文缺失的问题而 context-mode 这一类设计正是为了治这个病。这篇文章我想从自己的使用经验出发把“上下文模式”是什么、底层怎么工作、实际怎么配置、容易踩哪些坑以及怎么把它用好系统梳理一遍。适合正在用 AI 辅助写代码的开发者也适合对大模型应用、prompt 工程感兴趣的朋友。我会尽量讲得具体不绕弯子。1. 从“AI 答非所问”说起context-mode 要解决的到底是什么1.1 一个典型的翻车现场先说一个我印象特别深的翻车经历。当时我在改一个 React 项目项目里有一个设计系统级的全局样式文件里面定义了很多公共类名其中一个.btn-base被十几个页面组件复用。我让 AI 助手帮我调整某个页面中按钮的对齐方式它看了看我选中的那个组件文件觉得问题出在.btn-base的display属性和margin上于是直接改了全局样式文件里的定义。结果是那个页面的按钮确实变了但其他十几个页面的按钮全部错位测试同学直接在群里发了一连串问号。这个问题的根源不是模型能力不行而是我根本没有给它足够的上下文。它不知道这个全局样式文件被多少人引用不知道改这个类名会影响哪些地方也不知道这个项目的设计规范是什么。它只是在“信息不全”的情况下做出了一个看起来最合理的猜测。那一周里我连续遇到了好几次类似的问题。要么是 AI 改了一个接口的返回结构但没注意到前端某处还在用旧的字段名要么是它重构了一个工具函数但没发现其他模块正在依赖某个有副作用的分支逻辑。这些问题的共同点都是模型本身没犯错错在它“没看见”。1.2 上下文模式的定义与边界那 context-mode 到底是什么我的理解是它不是某一个按钮也不是某一个固定功能而是一整套决定“当前任务需要哪些背景信息、以什么方式把这些信息喂给模型”的工作机制。你可以把它类比成一个新来的程序员第一天入职你会带他先看哪几张图纸、哪几份文档、哪几段核心代码而不是把整个公司的资料库直接搬到他面前。context-mode 干的就是这件事。它要解决的核心矛盾是模型可用的信息处理能力是有限的但一个稍大的项目里代码、文档、配置文件、历史记录可能有几万甚至几十万个文件不可能全部塞进去。所以上下文模式本质上是一套“信息筛选与注入”的策略组合。它解决的问题包括从哪些文件里取信息取多少按照什么优先级排序什么时候用全文什么时候只用检索片段以及哪些信息根本不需要看它的边界也很清楚它不是数据库索引也不是项目文档系统它更接近一个“注意力分配器”决定模型在回答你之前先把自己的注意力放在哪里。1.3 为什么这个词突然热起来了这个词能成为热搜词背后有几个趋势是绕不开的。第一AI 编程助手从“问答工具”变成了“自主执行工具”。最早我们是用 AI 问问题、补全代码现在很多工具已经能自己读文件、做规划、写代码、跑命令甚至自己修复报错。这种 Agent 化的产品一旦出现上下文管理就不再是“锦上添花”而是核心竞争力。因为 Agent 的每一步都依赖对上下文的正确理解理解错了后面的动作全是错的。第二大模型的上下文窗口虽然越做越大但大家发现“窗口大”和“用得好”是两回事。窗口大了之后盲目地把文件都扔进去模型反而更容易抓不住重点而且 token 消耗、响应延迟都在飙升。我实测过一个项目如果把整个仓库几百个文件都扫描进去一次请求的 token 消耗可以高达几十万费用和等待时间都让人肉疼。第三行业里开始出现大量“上下文工程”相关的方法论沉淀比如用规则文件定义项目上下文、用子代理隔离上下文、用语义搜索替代全量扫描。当这些方法逐渐成为共识一个统一的词就出现了也就是现在的 context-mode。2. 上下文模式背后的机制模型是如何“记住”你的项目的2.1 上下文窗口与 token为什么不是越多越好要理解上下文模式必须先理解 token 和上下文窗口这两个基本概念。token 是模型处理文本的最小单位你可以把它粗略理解成“词片”。一段英文大概 4 个字符算一个 token一个汉字大约要占 1 到 2 个 token。模型一次能处理的 token 总数是有上限的这个上限就是上下文窗口。比如某个模型的上下文窗口是 128k那它就一次最多接收大约 128k 个 token 的输入。很多人觉得上下文窗口越大越好其实不一定。我一个很直观的感受是当上下文里堆了大量无关内容时模型对关键信息的“注意力”会被稀释。研究里有个现象叫 Lost in the Middle意思是大模型在处理长文本时对开头和结尾的内容记忆比较牢对中间部分的内容最容易忽略。换句话说你一古脑儿把 100 个文件塞进去真正关键的那 2 个文件刚好在中间位置模型很可能就“没看见”。我做过一个实验同样一个代码重构任务一种做法是把整个模块的 30 个文件全部加入上下文另一种做法是我先手动挑出 5 个最核心的文件加进去再在 prompt 里明确说明“其他文件不要动”。结果是第二种做法的准确率明显更高修改后几乎没有产生副作用。所以上下文的关键从来不是“多”而是“准”。2.2 上下文拼接的基本逻辑系统指令、项目指引、检索片段模型在一次对话中收到的内容其实是一个拼接好的整体。大致包括几个部分系统指令也就是最底层的行为准则。它告诉模型“你是一个资深工程师”“你的回答要简洁”“不要在代码里加注释”之类的约束。项目指引通常是项目根目录下某个固定文件里的内容比如 AGENTS.md、CLAUDE.md。这部分会随着每次会话自动加载相当于项目的“长期记忆”。用户指令就是你当前输入的话。检索片段或文件全文这是上下文模式下变化最大的部分可能来自你手动指定的文件也可能是工具自动检索出来的代码片段。工具返回结果比如你让 AI 跑了一个命令命令的输出会作为新的信息补充进来。这些部分不是平权的。系统指令优先级最高项目指引次之检索片段再次。上下文模式的核心工作就是决定上面第四部分的内容和顺序。顺序也很重要。我自己在使用中会刻意把最重要的信息往 prompt 后面放或者放在最近的位置因为模型对较新的内容通常更敏感。如果你有一堆背景资料要提供不要把最重要的埋在一大段文字的中间。2.3 三种上下文模式自动扫描、手动指定、规则化配置根据我的使用体验目前主流 AI 编程工具里的上下文模式可以粗略分成三种形态。第一种是自动扫描模式。工具会扫描整个项目目录把文件结构、关键代码、依赖配置等作为一个整体上下文加载。它适合项目比较小或者你刚打开一个陌生仓库想让 AI 快速了解全局的时候。第二种是手动指定模式。你用 符引用某个具体文件或者在对话里说“请只参考 src/core 目录下的代码”让 AI 把注意力集中在指定范围内。它适合你已经清楚知道问题出在哪里的场景。第三种是规则化配置模式。你在项目里维护一份专门的说明文件把项目的技术栈、目录结构、常用命令、注意事项都写进去工具每次启动时会自动加载这份文件。它适合长期维护的项目能让 AI 始终保持对项目的基本认知。这三种模式各有侧重但并不是互斥的。实际项目中我通常是“规则化配置打底 手动指定聚焦 小范围自动扫描辅助”组合使用。2.4 不同项目规模下该怎么选模式不同体量的项目适用的上下文策略差异很大。如果是几个文件组成的小项目无脑自动扫描就够了总共也没多少 token模型可以把所有代码都看一遍。如果是几十个文件的中型项目我建议手动指定为主配合一份简短的项目说明文件。你不需要让 AI 看所有代码只需要让它看你正在改的这一块以及跟这块相关的几个文件就够了。如果是上百个文件的 monorepo 或者大型业务项目就必须依赖规则化配置和语义搜索了。这种项目里盲目全量扫描不仅是 token 灾难还会让模型在各种无关代码中迷失。正确做法是把项目结构讲清楚让 AI 先搜索定位再针对定位到的文件做分析。我见过很多人在大项目里直接用自动扫描结果一个任务跑了几分钟回复却驴唇不对马嘴。开头的思路选错了后面再怎么调都很难救回来。3. 实战配置把 context-mode 用起来的完整步骤3.1 准备阶段建立一份权威的项目说明文件如果你想长期用 AI 助手维护一个项目我强烈建议你在项目根目录放一份类似 AGENTS.md 的说明文件。这份文件的价值相当于给 AI 写一份“入职手册”。我自己的 AGENTS.md 一般包含几个固定模块项目一句话简介说清楚这个项目是做什么的。技术栈清单框架、语言、关键依赖。目录结构说明哪些目录是核心业务哪些目录是公共组件哪些目录不要动。常用命令开发启动命令、测试命令、构建命令、lint 命令。代码风格约定命名规范、组件写法、样式方案。常见陷阱哪些地方以前出过问题改代码时要特别小心。举个例子我曾经在两个配置文件里改错过东西后来我直接在说明文件里写了这么一段 “注意项目中有 settings.dev.yaml 和 settings.prod.yaml 两份配置文件生产环境的配置禁止修改调试时请只改 dev 文件。”有了这条AI 再也没动过错文件。提示这份文件不是给你自己看的是给模型看的。所以表述要直接、清晰避免空话套话。多写“禁止”“务必”“优先”这类明确的指令性语言效果比单纯描述要好。3.2 手动指定核心目录与关键文件第二种方式是手动指定适合已有明确目标的时候。我在实际工作中会这样操作。如果我想让 AI 改某个业务模块我会先明确告诉它这个模块涉及哪些文件而不是让它自己猜。比如 “请参考以下文件来完成修改src/pages/order/detail.tsx、src/hooks/useOrder.ts、src/api/order.ts其他相关文件请先搜索确认再动手不要直接修改全局样式文件。”这里的重点是两个 一是给出准确文件路径减少模型检索成本 二是明确“不要动”的范围防止它越界改到不该改的地方。我还习惯在让 AI 动手改代码之前先让它“复述一遍”它理解的项目背景比如让它简要说明这几个文件之间的关系。这个步骤看起来多余但非常有效能够提前暴露它对项目的错误理解。如果它复述得不对你马上纠正比它写完了再返工要省时省力得多。3.3 规则化配置排除规则与优先级规则当项目目录比较庞大时排除规则非常重要。大多数 AI 编程工具在读取项目时都会自动忽略 node_modules、dist、.git、venv 这类目录但不同工具的默认行为不一样有些工具会把一些你不希望它看的文件也读进去。我自己在配置文件里一般这样写# 忽略目录和文件 node_modules/ dist/ build/ coverage/ .tmp/ *.log这只是基础。更有价值的是“优先级规则”。比如在一个项目里src/shared/types 下的类型定义是全项目的基础AI 改任何代码之前都应该先看这些类型定义。那我就会在说明文件里写 “项目中的 src/shared/types 定义了全项目共享的核心类型修改任何业务代码之前请确保理解相关类型定义。”这相当于给 AI 设定了一个“先看什么”的固定顺序能够有效避免它从错误的地方入手。顺便提一句规则文件本身也要注意维护。项目重构了、目录改了说明文件不更新AI 就会拿着过时的地图去走新的路反而更坑。我会在每个迭代周期里抽时间更新这份文件让它始终跟代码保持同步。3.4 验证配置是否生效两个快速测试方法配置完之后怎么知道 AI 的上下文机制真的按你的预想在工作我一般用两个方法快速验证。第一个方法是基本信息提问。我会直接问 “这个项目的技术栈是什么启动命令是什么有哪些不该修改的目录”如果它能准确答出来说明规则文件的加载是成功的。如果答错了我会检查是不是文件命名不对、放置路径不对或者工具根本没有自动加载这个文件。第二个方法是反向测试。我会故意问一个“陷阱题”比如问一个只在生产配置里存在的字段或者在说明文件里声明为“禁止修改”的模块看 AI 怎么回答。如果它能准确说出这个模块是禁止修改的就说明上下文生效了如果它傻乎乎地把相关信息找出来并且开始分析怎么改那我就要去检查规则配置的优先级是不是被别的东西覆盖了。这个方法特别适合在切换不同 AI 工具时用。每个工具对规则文件的支持程度不太一样迁移之后第一件事不是看代码写得好不好而是先确认上下文加载正常。4. 翻车实录上下文模式最常见的几个坑和排查链路4.1 崩溃现场一上下文溢出AI 开始“失忆”使用 context-mode 时间长了遇到的第一个大坑基本是上下文溢出。症状很有意思对话前几轮还挺聪明越到后面越蠢开始重复自己的话甚至答非所问。严重的时候工具直接报错提示上下文长度超限。我遇到过一次特别典型的在一个大文件上做重构。那个文件单文件就有几千行我又让它同时参考了另外十几个文件聊了几轮之后模型开始把前面自己写过的函数名搞混一会儿叫 fetchUserData一会儿叫 getUserData完全没意识到这是同一个东西。根因其实很简单每一步对话的历史都会被保留下来再加上那些大文件token 很快就堆满了。一旦超出窗口上限最老的部分会被“挤出去”对话就失去了开头说好的背景。遇到这种情况我现在的处理方法是一旦发现模型开始“复读”或者忘记自己说过的话第一反应不是继续追问而是立刻开一个新会话。在开新会话之前我会先让模型把当前进展、已修改的文件、待办事项整理成一份简要纪要然后把它粘贴到新会话里作为新的上下文基础。提示这里的核心教训是上下文不是无限续杯的。该断则断带着“纪要”而不是带着“全部历史”去新会话效率反而高得多。4.2 崩溃现场二上下文污染无关文件抢占注意力第一次用“全项目扫描”模式的时候我遇到了另一种崩溃AI 确实看了很多文件但看了太多不该看的。印象比较深的一次是让 AI 在一个老项目里帮我找一个定时任务为什么不触发。它从项目里找到了好几个包含 cron 配置的文件有的是历史遗留的废弃脚本有的是别的小项目拷贝过来的示例代码。最终它把一个废弃配置文件当成主配置分析了一长串结论完全跑偏。后来我看了下它实际注入的上下文发现它是按文件路径和关键词搜索的把路径里带“config”的文件全都搜出来了根本没有区分哪个是真正被加载的配置。这种情况就是典型的上下文污染信息不是太少而是太杂关键信息被淹没在无关信息里了。解决办法有三个方向。第一缩小范围明确告诉 AI“不要搜索整个项目只搜索 conf 目录下的 task 相关配置”第二用排除规则把这些历史遗留目录加入 ignore 列表第三如果是手动指定文件的场景就只指名道姓给它正确的文件不给它选择空间。4.3 崩溃现场三每次开新会话就“失忆”还有一种更隐蔽的崩溃很多团队都会遇到。项目里背景信息很多但你每次开新会话都要像第一次见面的陌生人一样把项目背景重新跟 AI 解释一遍心累。我参与过一个中大型项目核心背景信息大概要写几百个字才能交代清楚不同模块的职责、哪些目录是核心、哪些代码已经废弃、历史上有哪些需求是怎么拍板的。一开始我图省事每次开新会话都在对话开头说一遍。后来我发现这样有两个问题一是我自己的描述每次都不完全一样AI 的理解会漂移二是这些背景占掉了大量上下文窗口真正留给代码分析的 token 就少了。正确的做法是把这些背景信息固化到项目说明文件里让它每次自动加载。这跟 3.1 节说的是同一件事但在“场景驱动”下看它的意义更明确它解决的不是单次任务质量而是“项目长期可维护性”的问题。从那以后我养成了一个习惯任何项目第一次用 AI 深度参与前先花二十分钟把项目说明文件写好。这笔时间投进去后续每个会话都能省回来。4.4 一条完整的排查链路从“症状”到“根因”遇到上下文相关的问题我建议你按照下面的链路排查而不是直接怀疑模型能力不行。第一步复现问题并缩小范围。比如模型改错了文件先把任务简化到“只让它分析指定两个文件之间的关系”看它是否还会出错。第二步查看当前请求实际注入了什么。很多 AI 编程工具支持查看本次请求的 token 使用情况和引用的文件列表如果没有这个功能你也可以直接问模型“你刚才参考了哪些文件”它通常能列出来。第三步判断到底是“没看到”还是“看错了”。如果它引用的文件列表里根本没有关键文件就是上下文缺失如果它列了正确文件但结论还是错才是真正的语义理解问题。这两个问题的解法完全不同前者改上下文策略后者可能要换模型或改 prompt。第四步针对根因修正。缺文件就手动指定或加规则文件太杂就加排除规则历史信息丢失就写进项目说明文件。下面这个表可以帮你快速定位症状常见根因解决方向模型改了无关文件上下文边界模糊手动指定范围、加“不要修改”的约束长对话后开始失忆上下文溢出早期信息被挤掉开新会话并携带阶段纪要引用了废弃代码搜索/扫描未过滤历史目录更新 ignore 列表、排除废弃目录每次新会话都需要重新介绍项目背景信息只存在对话中把背景写入项目说明文件回答泛泛而谈、不具体注入信息过少指定更多核心文件或触发检索5. 进阶玩法把上下文当资源来管理5.1 用子任务隔离上下文当我开始把一个稍微大一点的模块重构任务交给 AI 时我意识到一个道理上下文不只是“喂什么”的问题更是“怎么切分”的问题。我在实践里用到的一个有效方法是子任务隔离。举个例子有一次我要让 AI 把一个老旧的订单模块改造成新的状态机模式整个模块包含数据模型、状态流转、接口层、前端页面四层逻辑如果一次性全部扔给它改它要同时跟踪的信息量非常大后面基本会乱。我把它拆成了四个阶段先改数据模型和状态定义这一步只参考类型文件和状态图文档再改状态流转逻辑这一步只参考上一步完成的结果然后接接口层最后才动前端页面。每一个阶段都是一个新的会话只携带它需要的那一小块上下文。这个做法本质上是对上下文窗口的“分治”。每个子任务需要的信息量都不大模型可以保持高精度。代价是你要在任务之间做一些衔接传递上一个阶段的产出物但这个衔接成本比后期花大量时间去检查和修复错误要低很多。5.2 阶段纪要给上下文做“压缩”阶段纪要这个方法是我自己用了很久之后觉得最值得推荐的经验之一。它解决的是长任务场景下的上下文衰减问题。具体做法很简单当你觉得当前对话已经聊了很多轮或者任务完成了一个阶段就让 AI 把当前进展整理成一份 Markdown 纪要内容包括已完成的任务、修改了哪些文件、当前系统状态、遗留问题、下一步建议。然后把这份纪要保存成一个文件比如.ai-progress.md。下一个会话开始时你不需要复制粘贴之前所有的聊天记录只需要让 AI 读取这份纪要文件它就能快速恢复到之前的工作状态。这个方法和“把项目背景写进 AGENTS.md”的区别在于AGENTS.md 记录的是静态的项目事实而阶段纪要记录的是动态的推进过程。一个像是地图一个像是行军日志。两个配合起来几乎可以无限延续一个复杂任务的进展。5.3 搜索摘录替代全文灌入对于大型项目让 AI 读大量文件全文是一种奢侈而且往往没必要。我现在越来越倾向于使用“搜索摘录”的方式。这个方式的思路是先让 AI 对项目做关键词或语义搜索定位到最相关的文件或者代码片段然后再针对这些片段进行分析而不是一开始就把整个模块的全文塞进去。比如我想让 AI 帮我排查一个数据重复提交的问题我不会直接告诉它“看看整个 request 模块”而是让它先搜索与提交、防重、token 刷新相关的代码片段把候选片段返回我再指定它去看最相关的两三个文件。这样做有两个好处。第一是 token 消耗大幅下降费用和延迟都变得可控。第二是从一开始就把无关信息过滤掉模型的分析会更加聚焦。代价是你要多一轮“让 AI 检索、你确认”的交互但这点时间换来的准确率提升完全是值得的。5.4 成本与质量什么时候该“上强度”说了很多“少喂东西”的方法但也要承认有些场景确实是需要“上强度”的。比如跨模块的大型重构或者要评估一个修改对全局的影响这时候你就必须给模型足够多的上下文否则它给的建议会非常片面。我通常在这种情况下会临时放开限制让模型读取更多文件哪怕 token 消耗翻倍。我的判断标准大概有三个 第一任务的修改范围是否跨模块如果是就需要全局上下文 第二是否有隐性依赖比如某个函数被很多地方调用改了签名就要全局排查这需要更广的范围 第三失败成本高不高如果是改一个核心接口出错可能导致线上问题那在上下文上多花点 token 反而是性价比最高的保险。反过来如果只是一个局部 bug 修复、一个样式微调、一个文档补充那就不要用大范围上下文没必要也不可能更聪明。提示上下文管理不是“越省越好”也不是“越全越好”而是“刚好够用且关键信息不丢”。这个平衡点只能靠你在具体项目里反复试出来。6. 关于 context-mode 我最后的几点实战体会讲了这么多最后说点个人的真实感受。context-mode 这个词听起来很技术但它背后其实是一种协作习惯的转变。用过一段时间之后我最大的体会是与其说我在教 AI 怎么用项目不如说我在被迫重新梳理自己对项目的理解。在写项目说明文件的时候我需要说清楚每个目录是干什么的、哪些代码是核心、哪些地方容易踩坑。这个过程逼着我把以前凭直觉了解的项目信息变成显性化的文字。以前我觉得自己对这个项目很熟但真让我写下来我才发现自己忽略了很多边界情况。还有一点很重要的是上下文模式不是设置一次就一劳永逸的。项目会重构新的模块会加进来旧的规则会失效。我现在每隔一段时间就会检查一下项目说明文件更新目录结构、补充新的陷阱点、删除过时的内容。这个维护成本是必须付的不付的话AI 会拿着过期的上下文给你“自信满满”的错误建议。最后分享一个小技巧在项目说明文件里专门加一个“常见错误假设”的章节把团队里新成员最容易误解的地方、AI 以前犯过的典型错误都写进去。比如“这个项目不是微服务架构是模块化单体”“这里用的不是 Redux是 Zustand”“配置文件的修改必须重新构建才生效”。我实测下来这一小段内容比很多冗长的架构说明都管用AI 犯低级错误的概率会明显下降。context-mode 不是魔法它解决不了所有问题但它确实把我从大量“反复解释项目背景”和“检查 AI 是否改错了地方”的琐碎工作里解放了出来。如果你也开始觉得 AI 助手“不太懂你的项目”不妨从一份清晰的上下文配置文件开始。
