上个月帮同事排查一个AI改代码的翻车现场同一个函数前两次改稿把状态管理逻辑删了第三次又给加回来来回横跳。我问他给AI喂了多少上下文他说“没管直接把整个项目丢进去了”。这就是 context-mode 没控制好时最典型的代价。我越来越觉得context-mode 是当前开发流程里最容易被低估的一个环节。它不是某个API的名字也不是某个插件的专属功能而是泛指“当前状态下上下文从哪来、范围有多大、如何切换”的一套控制机制。在不同工具里它长得完全不一样可能是编辑器顶部固定显示的函数签名可能是AI编程工具里你允许模型看到的文件范围也可能是移动端长按列表项后弹出的操作栏。这篇文章就把这三种常见形态拆开讲清楚配合一些我实际踩过的坑和调优经验给你一套可以直接照搬的上下文管理思路。1. 先分清三种“context-mode”后面才不会用错我见过太多人把 context-mode 当成一个东西来讨论结果两个人说的根本不是一回事。所以在聊细节之前先做一次名词对齐。1.1 编辑器里的“我在哪”第一种 context-mode解决的是人脑工作记忆的问题。写代码的时候我们大脑里其实维护着一个隐形的栈当前文件是什么、当前类是什么、当前函数是什么、这段缩进属于哪个分支。一旦滚屏或者跳转这层记忆就要重新加载。函数越长、嵌套越深加载成本越高。context.vim 这类插件做的就是这件事把“当前所在作用域”的信息固定显示在窗口顶部让上下文始终停留在视觉范围内。它不需要你记忆也不需要你手动切换属于“静态上下文”的范畴。1.2 AI 工具里的“它知道什么”第二种 context-mode是大模型辅助编程中的上下文范围控制。大语言模型写代码时能参考哪些文件、哪些历史对话、哪些外部文档都取决于工具收集并拼接到提示词里的上下文。范围太小模型可能理解不了全局范围太大无关代码会稀释注意力回答变得又泛又水。AI辅助编程工具里的上下文控制本质上就是一个“信息带宽阀门”。你把它开多大模型就看到多大的世界。这也是当下最值得花时间研究的 context-mode。1.3 系统 API 里的“选择后能干什么”第三种 context-mode是 Android 等移动平台上经典的 Contextual Action Mode翻译过来也叫“上下文操作模式”。长按选中一段文本或者一个列表项时顶部弹出的那一排操作按钮就是 ActionMode。它和前面两种没有直接关系只是名字里都带“context”经常被人混为一谈。如果你在搜索引擎里输入 context-mode八成会同时搜到这两种完全无关的内容。先分清楚自己需要的是哪一种才不会走弯路。2. 编辑器静态上下文让作用域信息真正“钉”在视线里我日常的主力场景是 Vim/Neovim所以第一个要重点聊的是编辑器里的静态上下文模式。用到的开源插件是 wellle/context.vim它相当轻量却能在日常编码里省掉大量“往上翻几屏确认自己位置”的动作。2.1 最简安装与首屏效果安装方式非常简单。用 vim-plug 的话在配置里加一行call plug#begin() Plug wellle/context.vim call plug#end()Neovim 用户用 lazy.nvim 也差不多{ wellle/context.vim }装完重启编辑器打开一个结构比较深的文件比如一个嵌套了多层方法的长类。把光标挪到某个方法内部你会看到窗口顶部出现一小块固定区域上面显示着当前所在的类名、方法签名、以及外层控制结构。滚动文件的时候这个区域会实时更新。我第一次用的时候是有点惊讶的因为它的响应速度几乎感觉不到延迟。你往下翻顶部的函数签名跟着变永远不会出现“我到底在哪个函数里”的茫然。2.2 它是怎么算出“当前上下文”的很多人以为这种效果需要语言服务器支持其实 context.vim 走的是另外一条路。它不依赖 LSP不启动额外进程而是通过文本层面的结构分析来近似判断作用域从光标位置向上回溯根据代码缩进和括号配对找到最近的类声明、函数声明、if/for/while 等块级结构把这些行的开头提取出来组合成一段“上下文摘要”然后渲染在窗口顶部的独立区域中。这个方案有取舍但它极其聪明。语言服务器能给你精确的 AST 上下文代价是初始化慢、内存占用高、还要维护索引而 context.vim 选择了务实路线——对“我当前在哪个作用域里”这个高频需求来说语法层面的近似已经足够可靠。而且它天生支持所有语言不用等你装了对应的 LSP 才生效。如果你用的是 Neovim也确实有基于 Treesitter 的替代方案能拿到更精确的语法树结构。但我的经验是轻量方案在心智负担和实用度上更平衡。除非你对精确度有强迫症否则 context.vim 这种纯文本分析方案完全扛得住日常使用。2.3 主题兼容与性能调优默认配置下context.vim 会把上下文行渲染成一个高亮区域。但在某些主题里这个区域的背景色可能和代码块区分不开看起来就像一块突兀的补丁。我踩过这个坑最后是通过自定义高亮解决的highlight link ContextLinePMenu Normal把上下文行的高亮组直接链接到已有的主题组视觉上会自然很多。如果顶部区域分界线不明显可以再单独设置一条分隔线。性能方面context.vim 的算法本身很快但如果你打开了一个几千行的巨型文件它每滚动一次都要重新计算上下文。这时候可以设置最大高度限制它渲染的行数let g:context_max_height 8这个参数的意思是顶部最多显示 8 行上下文。行数越多信息越全但计算和渲染开销也越大。把它调到 5 到 8 之间视觉和性能最平衡。还有一个常被忽略的点有一些特殊的 buffer 类型不应该启用上下文比如 help 窗口、quickfix 列表。在那些窗口里显示上下文毫无意义还容易误触。建议直接把它们加入黑名单let g:context_buftype_blacklist [nofile, quickfix]2.4 给AI辅助工具准备的“人眼锚点”我后来发现编辑器静态上下文还有一个延伸价值它输出的那几行作用域摘要恰恰是给 AI 编程工具提供“人眼锚点”的好素材。比如你在提示词里告诉模型“我正在 OrderService.getOrderDetail 方法里改第 102 行的逻辑”这比说“帮我改一下订单详情相关代码”要精确得多。模型不需要去猜你指的是哪段逻辑因为你已经手动把上下文钉在了对话里。这也是为什么我一直强调好的上下文管理是人机协同的共同产物而不只是工具默认行为。3. AI 辅助编程的上下文模式决定模型“看得见什么”如果说编辑器上下文解决的是“我在哪”那 AI 编程工具里的 context-mode解决的就是“让它知道什么”。这一块是当前开发效率的最大变量也是大多数人最没意识去管理的地方。3.1 四种常见的上下文范围我一般会把 AI 编程的上下文范围分成四档分别对应不同的任务类型上下文范围适用场景主要风险单文件局部重构、改bug、补注释视野太窄容易忽略调用方影响相关文件组接口 实现 测试的联动修改需要手动指定依赖个人判断整个仓库架构分析、跨模块重构、未知代码定位注意力稀释回答泛化token浪费对话历史 外部资料设计讨论、技术选型、文档理解历史噪声污染上下文窗口溢出四档不是谁替代谁的关系而是同一任务在不同阶段需要切换的模式。问题是很多人的习惯是默认待在整个仓库那一档从头到尾不切换。3.2 最小必要上下文原则我给自己的约束很简单一个任务里让模型看到的代码越少越好。这句话听起来反直觉因为大家总觉得给的信息越多回答就越准。但真实情况恰恰相反。大模型在处理超长上下文时注意力会被无关代码摊薄就像让一个新人同时读十个模块的代码然后问他其中一个模块的问题他大概率会给出一个“看起来都对但哪都不准”的答案。我把这种状态叫“上下文通货膨胀”。解药就是最小必要上下文原则只提供回答当前问题所必需的文件和描述。具体实践上我一般按依赖顺序来添加上下文首先要改动的目标文件目标文件依赖的接口定义或数据模型直接调用目标文件的调用方确保改动不破坏现有行为只有在第四步还搞不定的时候才考虑放开整个仓库3.3 用显式引用把关键文件“拽”进视野现在主流的 AI 编程工具都支持用 之类的语法手动指定文件、目录把特定代码单元加进上下文。这是我最依赖的操作因为它把“模型自己碰运气搜索”变成了“用户精确制导”。我一般会在提示词里直接写请参考 src/services/order.ts 中 OrderService 类的 getOrderDetail 方法说明订单状态机的当前实现。这样写比“帮我看看订单模块”要稳得多。原因很简单工具自带的语义搜索和代码索引虽然有召回能力但本质上是近似匹配。它可能找到十个相关文件其中两个真正相关剩余八个属于“看起来相关”。如果你不显式指定模型会把这十个都当成依据结果反而被噪声带偏。还有一个我实测很有效的小技巧在让 AI 动手前先让它复述一遍它理解的上下文。比如直接问它“根据我提供的文件当前订单状态流转逻辑是怎样的”。如果它复述得准确再让它在基础上修改如果复述已经偏离说明上下文没给对这时候让它直接动手只会越改越离谱。3.4 对话历史的长度管理与重置除了文件范围还有一个容易被忽略的上下文来源对话历史本身。大模型的上下文窗口是有限的。你连续聊了两个小时后早期的信息还占着窗口新的代码又被塞进来模型只能在有限空间里挤来挤去。更麻烦的是历史里如果包含了你之前尝试但放弃的方案模型可能被旧思路卷回去出现“来回横跳”的状态。我踩过最深的坑就是连续在一个会话里做了三个不相关的任务结果第三个任务时模型还在沿用第一个任务的状态管理风格。那一次之后我养成了一个习惯一个任务解决完马上开启新会话。如果中间产生了重要的决策结论我会把它写进代码注释或者项目文档里再在新会话里通过引用文件的方式把它带回来。这就是把“记忆”外置到代码里而不是无限制地塞进对话历史。效果比死磕同一个会话好得多。4. 上下文模式用偏了的三个真实事故讲完正确做法再看三个真实事故。这些都是我身边同事踩过的坑每一个的根因都不是模型能力不够而是上下文模式控制出了偏差。4.1 全仓库上下文导致的“注意力稀释”前阵子有个后端同事排查一个线上偶发超时问题。他把整个仓库的上下文丢给 AI让 AI 分析可能原因。AI 非常认真地给了八个可能性从数据库锁到网络抖动从缓存穿透到 GC 停顿每一个看起来都专业但没有一个能直接定位。问题的根源是他给了模型太多无关代码模型的注意力被摊薄了只能给出覆盖式的泛化回答。后来我让他把日志里的堆栈片段直接贴进去指定两个可能相关的服务模块文件把范围缩到最小。模型这才开始针对性地分析具体链路最后定位到是一个第三方 SDK 在低并发下触发了非预期的毒快速失败。这个案例让我记住了全仓库上下文适合“帮我在这个项目里找 X”不适合“帮我解释这个具体堆栈为什么这样”。前者需要广度后者需要深度。深度问题必须用窄上下文解决。4.2 跨项目串扰A项目的“经验”跑进了B项目另一个同事更冤。他同时维护两个项目在同一个 AI 编程会话里来回切换。改完 A 项目的后端逻辑又切到 B 项目改前端样式。结果 AI 在 B 项目里给出的建议import 路径居然带着 A 项目的目录结构连代码风格都串了。大模型对话历史里的项目上下文是互相污染的。它在 A 项目里见过的类型命名、目录规范、依赖版本都会成为后续回答的隐性先验。对单个项目来说这是“经验丰富”对另一个项目来说这就是严重的上下文串扰。解决办法其实非常便宜一个项目一个独立会话。哪怕是同一个项目一个需求一个独立会话。不要让“全局技术讨论”和“特定项目编码”混在同一个上下文里。4.3 上下文过期重构之后它还在按旧接口写第三个事故最普遍。团队重构了一个支付接口把 createOrder 改成了 createOrderV2参数结构也变了。同事没注意继续在旧会话里让 AI 改支付相关的代码。结果 AI 生成的所有调用代码都是旧版接口编译直接报错。这不是模型笨而是它看到的上下文停留在旧版本。对话历史里的接口定义早就是过去的快照只要不刷新它就永远基于旧认知作答。我的处理方式是遇到接口变更这类重大事件第一时间清空相关会话或者至少在提问前明确告诉模型接口已经被重构请先阅读 XXX 文件中的最新定义再开始修改。强制让模型重新加载最新源码而不是依赖对话历史里的旧记忆。4.4 系统性规避这三类事故三个事故对应三类问题范围过宽、范围串扰、范围过期。把它们合并成一套规则执行起来并不难事故类型核心措施注意力稀释默认使用最小必要上下文深度问题限制在具体文件跨项目串扰每个项目独立会话每个需求独立会话上下文过期重大重构后清空会话强制模型重新读取最新源码另外我还会在代码评审里多问一句这次改动你给 AI 提供了哪些上下文这句话既能帮我理解同事的思考过程也能顺带提醒大家注意上下文管理。效果比单纯看 diff 好得多。5. 同名不同义移动端还有另一个 context mode聊到现在如果是在校学生或者移动端开发者可能会疑惑你说的 context-mode 怎么跟我认识的 ActionMode 完全不一样这里必须澄清一下Android 开发里的 Contextual Action Mode简称 ActionMode是另一个完全不同的概念。5.1 Contextual Action Mode 是干什么的在 Android 里ActionMode 指的是“用户对某段内容执行选中操作后出现的临时操作栏”。最经典的场景是长按选中文字后文本选择工具栏出现在顶部或者是列表多选模式下顶部出现“删除/分享/复制”等批量操作按钮。它解决的是“当前选中状态下提供哪些操作”的问题。和开发者所说的编程上下文、AI 上下文没有技术层面的直接关系纯粹是命名撞车。5.2 一个最小可跑的 ActionMode 示例如果你在做移动端开发实现一个简单的 ActionMode 并不复杂。核心是实现 ActionMode.Callback 接口然后在需要的时候调用 startActionMode 启动它。下面是一个用 Kotlin 写的极简示例。场景是给 RecyclerView 的条目加一个长按多选操作栏val actionModeCallback object : ActionMode.Callback { override fun onCreateActionMode(mode: ActionMode, menu: Menu): Boolean { mode.menuInflater.inflate(R.menu.menu_contextual_delete, menu) return true } override fun onPrepareActionMode(mode: ActionMode, menu: Menu): Boolean { return false } override fun onActionItemClicked(mode: ActionMode, item: MenuItem): Boolean { return when (item.itemId) { R.id.action_delete - { deleteSelectedItems() mode.finish() true } else - false } } override fun onDestroyActionMode(mode: ActionMode) { clearSelection() } } // 在条目长按时启动 holder.itemView.setOnLongClickListener { if (actionMode null) { actionMode it.startActionMode(actionModeCallback) } itemBinding.isSelected true true }代码里有个小细节值得注意onActionItemClicked 返回 true 表示事件已处理false 则事件会继续传播。我见过不少新手在这里直接返回 true导致菜单项后续逻辑执行两遍或出现预期外行为。5.3 同一个关键词不同的管理思路虽然这个概念跟本文前两部分无关但把它单独拿出来说很有必要因为差异本身就提醒了我们context 这个词在不同语境下含义完全不同。搜索资料时先判断你说的是哪种 context-mode能省掉大量筛选噪音的时间。6. 把上下文意识沉淀成一套工作流讲了这么多最后分享一套我现在实际在用的工作流。这套流程不依赖任何特定工具换什么编译器、用什么 AI 助手都适用核心就是一件事把上下文管理变成显式动作而不是默认状态。6.1 我的日常工作流编辑器层面我始终开着 context.vim 这类静态上下文。顶部那几行作用域信息保证我在任何时候都清楚“自己在哪”。AI 辅助编程层面我遵循最小必要上下文原则。拿到一个新的编码任务先做一次上下文规划这个任务到底涉及哪几个文件哪些可以靠显式引用直接拉进对话哪些真的需要模型自己搜动手前我会先让模型复述一遍对现有代码的理解确认无误后才开始指挥它修改。一个任务结束后主动开启新会话。如果有需要保留的关键决策写进代码注释或项目文档里作为下一个会话的可引用上下文。6.2 最值得投入的改进方向如果只选一个方向投入我会建议你先练“上下文瘦身”。大多数人用 AI 编程工具的低效不是模型不行而是喂给模型的上下文太臃肿。试着把一个任务需要的信息压到最小目标文件、接口定义、直接调用方、一句明确的问题描述。你会发现模型的回答质量肉眼可见地上升迭代次数也会明显减少。这跟给同事派活是一个道理你丢一堆代码让对方自己猜对方大概率给你一个万金油答案你把入口、边界、期望结果讲清楚对方才能真正帮上忙。context-mode 的用法本质上就是这种沟通意识在开发流程里的技术化表达。我现在每做一个项目都会提前想好上下文怎么组织。看起来是多花了几秒钟规划但省下的是反复改稿和来回横跳的几十分钟。这笔账怎么算都划算。 
长河君 · 2026/10/29 8:39:30 · 阅读 1.2k Context-Mode全解析：从编辑器到AI编程的上下文管理实战
上个月帮同事排查一个AI改代码的翻车现场同一个函数前两次改稿把状态管理逻辑删了第三次又给加回来来回横跳。我问他给AI喂了多少上下文他说“没管直接把整个项目丢进去了”。这就是 context-mode 没控制好时最典型的代价。我越来越觉得context-mode 是当前开发流程里最容易被低估的一个环节。它不是某个API的名字也不是某个插件的专属功能而是泛指“当前状态下上下文从哪来、范围有多大、如何切换”的一套控制机制。在不同工具里它长得完全不一样可能是编辑器顶部固定显示的函数签名可能是AI编程工具里你允许模型看到的文件范围也可能是移动端长按列表项后弹出的操作栏。这篇文章就把这三种常见形态拆开讲清楚配合一些我实际踩过的坑和调优经验给你一套可以直接照搬的上下文管理思路。1. 先分清三种“context-mode”后面才不会用错我见过太多人把 context-mode 当成一个东西来讨论结果两个人说的根本不是一回事。所以在聊细节之前先做一次名词对齐。1.1 编辑器里的“我在哪”第一种 context-mode解决的是人脑工作记忆的问题。写代码的时候我们大脑里其实维护着一个隐形的栈当前文件是什么、当前类是什么、当前函数是什么、这段缩进属于哪个分支。一旦滚屏或者跳转这层记忆就要重新加载。函数越长、嵌套越深加载成本越高。context.vim 这类插件做的就是这件事把“当前所在作用域”的信息固定显示在窗口顶部让上下文始终停留在视觉范围内。它不需要你记忆也不需要你手动切换属于“静态上下文”的范畴。1.2 AI 工具里的“它知道什么”第二种 context-mode是大模型辅助编程中的上下文范围控制。大语言模型写代码时能参考哪些文件、哪些历史对话、哪些外部文档都取决于工具收集并拼接到提示词里的上下文。范围太小模型可能理解不了全局范围太大无关代码会稀释注意力回答变得又泛又水。AI辅助编程工具里的上下文控制本质上就是一个“信息带宽阀门”。你把它开多大模型就看到多大的世界。这也是当下最值得花时间研究的 context-mode。1.3 系统 API 里的“选择后能干什么”第三种 context-mode是 Android 等移动平台上经典的 Contextual Action Mode翻译过来也叫“上下文操作模式”。长按选中一段文本或者一个列表项时顶部弹出的那一排操作按钮就是 ActionMode。它和前面两种没有直接关系只是名字里都带“context”经常被人混为一谈。如果你在搜索引擎里输入 context-mode八成会同时搜到这两种完全无关的内容。先分清楚自己需要的是哪一种才不会走弯路。2. 编辑器静态上下文让作用域信息真正“钉”在视线里我日常的主力场景是 Vim/Neovim所以第一个要重点聊的是编辑器里的静态上下文模式。用到的开源插件是 wellle/context.vim它相当轻量却能在日常编码里省掉大量“往上翻几屏确认自己位置”的动作。2.1 最简安装与首屏效果安装方式非常简单。用 vim-plug 的话在配置里加一行call plug#begin() Plug wellle/context.vim call plug#end()Neovim 用户用 lazy.nvim 也差不多{ wellle/context.vim }装完重启编辑器打开一个结构比较深的文件比如一个嵌套了多层方法的长类。把光标挪到某个方法内部你会看到窗口顶部出现一小块固定区域上面显示着当前所在的类名、方法签名、以及外层控制结构。滚动文件的时候这个区域会实时更新。我第一次用的时候是有点惊讶的因为它的响应速度几乎感觉不到延迟。你往下翻顶部的函数签名跟着变永远不会出现“我到底在哪个函数里”的茫然。2.2 它是怎么算出“当前上下文”的很多人以为这种效果需要语言服务器支持其实 context.vim 走的是另外一条路。它不依赖 LSP不启动额外进程而是通过文本层面的结构分析来近似判断作用域从光标位置向上回溯根据代码缩进和括号配对找到最近的类声明、函数声明、if/for/while 等块级结构把这些行的开头提取出来组合成一段“上下文摘要”然后渲染在窗口顶部的独立区域中。这个方案有取舍但它极其聪明。语言服务器能给你精确的 AST 上下文代价是初始化慢、内存占用高、还要维护索引而 context.vim 选择了务实路线——对“我当前在哪个作用域里”这个高频需求来说语法层面的近似已经足够可靠。而且它天生支持所有语言不用等你装了对应的 LSP 才生效。如果你用的是 Neovim也确实有基于 Treesitter 的替代方案能拿到更精确的语法树结构。但我的经验是轻量方案在心智负担和实用度上更平衡。除非你对精确度有强迫症否则 context.vim 这种纯文本分析方案完全扛得住日常使用。2.3 主题兼容与性能调优默认配置下context.vim 会把上下文行渲染成一个高亮区域。但在某些主题里这个区域的背景色可能和代码块区分不开看起来就像一块突兀的补丁。我踩过这个坑最后是通过自定义高亮解决的highlight link ContextLinePMenu Normal把上下文行的高亮组直接链接到已有的主题组视觉上会自然很多。如果顶部区域分界线不明显可以再单独设置一条分隔线。性能方面context.vim 的算法本身很快但如果你打开了一个几千行的巨型文件它每滚动一次都要重新计算上下文。这时候可以设置最大高度限制它渲染的行数let g:context_max_height 8这个参数的意思是顶部最多显示 8 行上下文。行数越多信息越全但计算和渲染开销也越大。把它调到 5 到 8 之间视觉和性能最平衡。还有一个常被忽略的点有一些特殊的 buffer 类型不应该启用上下文比如 help 窗口、quickfix 列表。在那些窗口里显示上下文毫无意义还容易误触。建议直接把它们加入黑名单let g:context_buftype_blacklist [nofile, quickfix]2.4 给AI辅助工具准备的“人眼锚点”我后来发现编辑器静态上下文还有一个延伸价值它输出的那几行作用域摘要恰恰是给 AI 编程工具提供“人眼锚点”的好素材。比如你在提示词里告诉模型“我正在 OrderService.getOrderDetail 方法里改第 102 行的逻辑”这比说“帮我改一下订单详情相关代码”要精确得多。模型不需要去猜你指的是哪段逻辑因为你已经手动把上下文钉在了对话里。这也是为什么我一直强调好的上下文管理是人机协同的共同产物而不只是工具默认行为。3. AI 辅助编程的上下文模式决定模型“看得见什么”如果说编辑器上下文解决的是“我在哪”那 AI 编程工具里的 context-mode解决的就是“让它知道什么”。这一块是当前开发效率的最大变量也是大多数人最没意识去管理的地方。3.1 四种常见的上下文范围我一般会把 AI 编程的上下文范围分成四档分别对应不同的任务类型上下文范围适用场景主要风险单文件局部重构、改bug、补注释视野太窄容易忽略调用方影响相关文件组接口 实现 测试的联动修改需要手动指定依赖个人判断整个仓库架构分析、跨模块重构、未知代码定位注意力稀释回答泛化token浪费对话历史 外部资料设计讨论、技术选型、文档理解历史噪声污染上下文窗口溢出四档不是谁替代谁的关系而是同一任务在不同阶段需要切换的模式。问题是很多人的习惯是默认待在整个仓库那一档从头到尾不切换。3.2 最小必要上下文原则我给自己的约束很简单一个任务里让模型看到的代码越少越好。这句话听起来反直觉因为大家总觉得给的信息越多回答就越准。但真实情况恰恰相反。大模型在处理超长上下文时注意力会被无关代码摊薄就像让一个新人同时读十个模块的代码然后问他其中一个模块的问题他大概率会给出一个“看起来都对但哪都不准”的答案。我把这种状态叫“上下文通货膨胀”。解药就是最小必要上下文原则只提供回答当前问题所必需的文件和描述。具体实践上我一般按依赖顺序来添加上下文首先要改动的目标文件目标文件依赖的接口定义或数据模型直接调用目标文件的调用方确保改动不破坏现有行为只有在第四步还搞不定的时候才考虑放开整个仓库3.3 用显式引用把关键文件“拽”进视野现在主流的 AI 编程工具都支持用 之类的语法手动指定文件、目录把特定代码单元加进上下文。这是我最依赖的操作因为它把“模型自己碰运气搜索”变成了“用户精确制导”。我一般会在提示词里直接写请参考 src/services/order.ts 中 OrderService 类的 getOrderDetail 方法说明订单状态机的当前实现。这样写比“帮我看看订单模块”要稳得多。原因很简单工具自带的语义搜索和代码索引虽然有召回能力但本质上是近似匹配。它可能找到十个相关文件其中两个真正相关剩余八个属于“看起来相关”。如果你不显式指定模型会把这十个都当成依据结果反而被噪声带偏。还有一个我实测很有效的小技巧在让 AI 动手前先让它复述一遍它理解的上下文。比如直接问它“根据我提供的文件当前订单状态流转逻辑是怎样的”。如果它复述得准确再让它在基础上修改如果复述已经偏离说明上下文没给对这时候让它直接动手只会越改越离谱。3.4 对话历史的长度管理与重置除了文件范围还有一个容易被忽略的上下文来源对话历史本身。大模型的上下文窗口是有限的。你连续聊了两个小时后早期的信息还占着窗口新的代码又被塞进来模型只能在有限空间里挤来挤去。更麻烦的是历史里如果包含了你之前尝试但放弃的方案模型可能被旧思路卷回去出现“来回横跳”的状态。我踩过最深的坑就是连续在一个会话里做了三个不相关的任务结果第三个任务时模型还在沿用第一个任务的状态管理风格。那一次之后我养成了一个习惯一个任务解决完马上开启新会话。如果中间产生了重要的决策结论我会把它写进代码注释或者项目文档里再在新会话里通过引用文件的方式把它带回来。这就是把“记忆”外置到代码里而不是无限制地塞进对话历史。效果比死磕同一个会话好得多。4. 上下文模式用偏了的三个真实事故讲完正确做法再看三个真实事故。这些都是我身边同事踩过的坑每一个的根因都不是模型能力不够而是上下文模式控制出了偏差。4.1 全仓库上下文导致的“注意力稀释”前阵子有个后端同事排查一个线上偶发超时问题。他把整个仓库的上下文丢给 AI让 AI 分析可能原因。AI 非常认真地给了八个可能性从数据库锁到网络抖动从缓存穿透到 GC 停顿每一个看起来都专业但没有一个能直接定位。问题的根源是他给了模型太多无关代码模型的注意力被摊薄了只能给出覆盖式的泛化回答。后来我让他把日志里的堆栈片段直接贴进去指定两个可能相关的服务模块文件把范围缩到最小。模型这才开始针对性地分析具体链路最后定位到是一个第三方 SDK 在低并发下触发了非预期的毒快速失败。这个案例让我记住了全仓库上下文适合“帮我在这个项目里找 X”不适合“帮我解释这个具体堆栈为什么这样”。前者需要广度后者需要深度。深度问题必须用窄上下文解决。4.2 跨项目串扰A项目的“经验”跑进了B项目另一个同事更冤。他同时维护两个项目在同一个 AI 编程会话里来回切换。改完 A 项目的后端逻辑又切到 B 项目改前端样式。结果 AI 在 B 项目里给出的建议import 路径居然带着 A 项目的目录结构连代码风格都串了。大模型对话历史里的项目上下文是互相污染的。它在 A 项目里见过的类型命名、目录规范、依赖版本都会成为后续回答的隐性先验。对单个项目来说这是“经验丰富”对另一个项目来说这就是严重的上下文串扰。解决办法其实非常便宜一个项目一个独立会话。哪怕是同一个项目一个需求一个独立会话。不要让“全局技术讨论”和“特定项目编码”混在同一个上下文里。4.3 上下文过期重构之后它还在按旧接口写第三个事故最普遍。团队重构了一个支付接口把 createOrder 改成了 createOrderV2参数结构也变了。同事没注意继续在旧会话里让 AI 改支付相关的代码。结果 AI 生成的所有调用代码都是旧版接口编译直接报错。这不是模型笨而是它看到的上下文停留在旧版本。对话历史里的接口定义早就是过去的快照只要不刷新它就永远基于旧认知作答。我的处理方式是遇到接口变更这类重大事件第一时间清空相关会话或者至少在提问前明确告诉模型接口已经被重构请先阅读 XXX 文件中的最新定义再开始修改。强制让模型重新加载最新源码而不是依赖对话历史里的旧记忆。4.4 系统性规避这三类事故三个事故对应三类问题范围过宽、范围串扰、范围过期。把它们合并成一套规则执行起来并不难事故类型核心措施注意力稀释默认使用最小必要上下文深度问题限制在具体文件跨项目串扰每个项目独立会话每个需求独立会话上下文过期重大重构后清空会话强制模型重新读取最新源码另外我还会在代码评审里多问一句这次改动你给 AI 提供了哪些上下文这句话既能帮我理解同事的思考过程也能顺带提醒大家注意上下文管理。效果比单纯看 diff 好得多。5. 同名不同义移动端还有另一个 context mode聊到现在如果是在校学生或者移动端开发者可能会疑惑你说的 context-mode 怎么跟我认识的 ActionMode 完全不一样这里必须澄清一下Android 开发里的 Contextual Action Mode简称 ActionMode是另一个完全不同的概念。5.1 Contextual Action Mode 是干什么的在 Android 里ActionMode 指的是“用户对某段内容执行选中操作后出现的临时操作栏”。最经典的场景是长按选中文字后文本选择工具栏出现在顶部或者是列表多选模式下顶部出现“删除/分享/复制”等批量操作按钮。它解决的是“当前选中状态下提供哪些操作”的问题。和开发者所说的编程上下文、AI 上下文没有技术层面的直接关系纯粹是命名撞车。5.2 一个最小可跑的 ActionMode 示例如果你在做移动端开发实现一个简单的 ActionMode 并不复杂。核心是实现 ActionMode.Callback 接口然后在需要的时候调用 startActionMode 启动它。下面是一个用 Kotlin 写的极简示例。场景是给 RecyclerView 的条目加一个长按多选操作栏val actionModeCallback object : ActionMode.Callback { override fun onCreateActionMode(mode: ActionMode, menu: Menu): Boolean { mode.menuInflater.inflate(R.menu.menu_contextual_delete, menu) return true } override fun onPrepareActionMode(mode: ActionMode, menu: Menu): Boolean { return false } override fun onActionItemClicked(mode: ActionMode, item: MenuItem): Boolean { return when (item.itemId) { R.id.action_delete - { deleteSelectedItems() mode.finish() true } else - false } } override fun onDestroyActionMode(mode: ActionMode) { clearSelection() } } // 在条目长按时启动 holder.itemView.setOnLongClickListener { if (actionMode null) { actionMode it.startActionMode(actionModeCallback) } itemBinding.isSelected true true }代码里有个小细节值得注意onActionItemClicked 返回 true 表示事件已处理false 则事件会继续传播。我见过不少新手在这里直接返回 true导致菜单项后续逻辑执行两遍或出现预期外行为。5.3 同一个关键词不同的管理思路虽然这个概念跟本文前两部分无关但把它单独拿出来说很有必要因为差异本身就提醒了我们context 这个词在不同语境下含义完全不同。搜索资料时先判断你说的是哪种 context-mode能省掉大量筛选噪音的时间。6. 把上下文意识沉淀成一套工作流讲了这么多最后分享一套我现在实际在用的工作流。这套流程不依赖任何特定工具换什么编译器、用什么 AI 助手都适用核心就是一件事把上下文管理变成显式动作而不是默认状态。6.1 我的日常工作流编辑器层面我始终开着 context.vim 这类静态上下文。顶部那几行作用域信息保证我在任何时候都清楚“自己在哪”。AI 辅助编程层面我遵循最小必要上下文原则。拿到一个新的编码任务先做一次上下文规划这个任务到底涉及哪几个文件哪些可以靠显式引用直接拉进对话哪些真的需要模型自己搜动手前我会先让模型复述一遍对现有代码的理解确认无误后才开始指挥它修改。一个任务结束后主动开启新会话。如果有需要保留的关键决策写进代码注释或项目文档里作为下一个会话的可引用上下文。6.2 最值得投入的改进方向如果只选一个方向投入我会建议你先练“上下文瘦身”。大多数人用 AI 编程工具的低效不是模型不行而是喂给模型的上下文太臃肿。试着把一个任务需要的信息压到最小目标文件、接口定义、直接调用方、一句明确的问题描述。你会发现模型的回答质量肉眼可见地上升迭代次数也会明显减少。这跟给同事派活是一个道理你丢一堆代码让对方自己猜对方大概率给你一个万金油答案你把入口、边界、期望结果讲清楚对方才能真正帮上忙。context-mode 的用法本质上就是这种沟通意识在开发流程里的技术化表达。我现在每做一个项目都会提前想好上下文怎么组织。看起来是多花了几秒钟规划但省下的是反复改稿和来回横跳的几十分钟。这笔账怎么算都划算。