上个月帮同事排查一个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 的用法，本质上就是这种沟通意识在开发流程里的技术化表达。
我现在每做一个项目，都会提前想好上下文怎么组织。看起来是多花了几秒钟规划，但省下的是反复改稿和来回横跳的几十分钟。这笔账，怎么算都划算。
