1. context-mode 到底在调什么：先搞清楚这个模式控制的是哪块记忆

先说个我自己的经历。早先用 AI 辅助写代码、写文档的时候，经常遇到一种诡异的情况：明明上一个问题它还答得好好的，我补了一句"顺便把刚才那个函数也改了"，结果它把整个文件结构都给重写了，甚至把我之前明确说"不要动"的部分也动了。后来我把工具的上下文模式从"自动"切到了"严格"，同样的对话，它就只动我指定的那一段。那一刻我才意识到，问题根本不出在模型笨，而是我从来没管过它能看到什么、记住什么。

context-mode，直译就是"上下文模式"，它控制的不是 AI 的智商，而是 AI 的记忆范围和信息来源。在 AI 辅助编程、写作、数据分析这些场景里，上下文模式决定了每一次向模型发起请求时，哪些信息会被打包送进推理过程：是只有当前文件？还是整个项目目录？还是把最近的 20 轮对话全部带上？

这个功能几乎出现在所有主流 AI 工具里，只是叫法不一样：Cursor 里它藏在 @ 符号和模型选择器附近，Copilot 的对话面板里有"上下文"下拉框，一些本地推理工具（比如 Open WebUI、Cherry Studio）把它叫"记忆模式"或者"关联上下文"。不管叫什么，本质都是同一件事：给模型划定一个工作半径，半径越大，它掌握的信息越全，但你也得为这份"全"付出时间和金钱的代价。

这篇文章我想把 context-mode 这件事彻底讲透：它背后是什么原理、不同模式分别适合什么场景、怎么配置才能少花 token 多干实事，以及我在实际使用中踩过的那些坑。适用人群很广，哪怕你完全不懂大模型原理，只要你在用 AI 工具干活，这篇文章就能帮你省下一大笔冤枉钱，也能让你少生很多气。

2. 核心设计与原理解读：为什么"上下文"是 AI 的临时工记忆

2.1 大模型的上下文窗口，就是一张随时会过期的便签纸

要理解 context-mode，先得理解模型的工作方式。你每一次向 ChatGPT、Claude 或者某个本地模型发起提问，模型并不是像人一样"想起来了什么"，而是把它收到的所有内容看作一段连续的文本，从头到尾预测下一个词。这段文本就叫上下文（context），它通常由几部分组成：

• 系统提示词（System Prompt）：工具预设的规则，比如"你是编程助手"。
• 对话历史（Chat History）：你和 AI 之前一来一回的所有消息。
• 当前输入（Current Input）：你刚刚写下的问题、代码片段或文件内容。
• 检索结果（Retrieved Content）：工具主动从项目、知识库或网页里抓来的信息。

这些内容会被拼接在一起，塞进模型的上下文窗口里。窗口是有容量上限的，不同模型上限不同，3.5K、8K、32K、128K、200K 都有。注意，这里的单位是"token"，不是"字"。一个 token 大概是 0.6 到 0.8 个汉字，具体取决于语言和分词方式。

打个比方：上下文窗口像一张临时便签纸。你每次提问，都要把便签纸上的旧内容擦掉一些，再写下新内容。模型呢，只看得到纸上现在写的东西，纸以外的记忆它一概没有。你今天上午跟它讨论的方案，如果没写在这张便签纸上，它下午就"忘"得干干净净——不是它故意忘，是它根本没地方存。

context-mode 的作用，就是决定谁来写这张便签纸、写多少、以及先擦掉哪部分。

2.2 三种主流模式：自动、严格、自定义到底各管什么

现在市面上大部分工具提供的 context-mode 可以归纳为三类：

自动模式是最常见的默认选择，也是最容易出问题的一个。它的问题在于"自行判断"这件事本身就是个黑盒，你根本不知道它到底带了多长的历史。我实测过某工具，同样一句"帮我把这个函数改成异步"，在自动模式下它从对话里翻出了 8 轮前的需求做参考，结果改出来的代码里夹带了一堆无关的旧逻辑；切到严格模式后，它老老实实只看我当前贴的代码，干净利落。

严格模式听起来省 token，但它有个明显的副作用：模型没有"记性"。你前面刚让它定义了变量命名规范，切到严格模式后它当场忘掉，你得重新说一遍。所以严格模式不是万能的，它适合那种"每次指令都自包含"的任务——比如翻译一段文本、修一个 bug、写一个独立函数。

扩展模式则是把"便签纸"换成"文件夹"。它让 AI 能看到整个项目的结构和关键文件内容，甚至能自己决定去读哪些文件。代价也很直接：贵、慢，而且容易信息过载。模型面对远超需要的上下文时，注意力会被无关内容稀释，就像让一个人同时看 50 份资料再回答问题，他反而容易抓不住重点。

2.3 为什么选错模式会让 AI 变蠢：注意力稀释效应

我想特别强调一个容易被忽略的规律：上下文不是越多越好，多到一定程度，模型的理解质量反而下降。这在大模型领域有个通俗说法叫"Lost in the Middle"——模型对长文本中间部分的信息记忆最差，对开头和结尾记忆最好。你把 30 个文件全部塞进上下文，真正关键的那段代码可能正好躺在"中间"位置，模型读是读了，但注意力权重根本顾不上它。

我踩过最惨的一次跟这个直接相关。当时我在做一个数据清洗项目，为了省事把整个目录里的 20 多个 CSV 文件全部拖进了上下文，想让模型一次性把所有字段类型统一。结果它把我明确标记过"不要动"的原始字段也给改了，原因就是它读了太多的列名，把"原始值"和"清洗值"两套字段搞混了。后来我把上下文模式切到严格，一次只喂一个文件的字段说明，它立刻分得清清楚楚。

所以选 context-mode 的核心逻辑不是"能塞多少塞多少"，而是**"刚好够用就停"**。这就像你在厨房炒菜，盐和调料都摆在你顺手的地方最合适，把整个超市搬进厨房，你反而找不到盐在哪。

3. 实操配置指南：不同任务怎么选模式，照着抄就行

3.1 单文件修改：严格模式是你的默认选项

如果你只是改一个函数、修一个 bug、润色一篇文章，我强烈建议把 context-mode 切到严格模式。操作要点如下：

1. 关闭工具的自动检索功能（比如 Cursor 里的自动 Codebase Search）。
2. 在对话里明确贴出要修改的代码片段，不要只说"你帮我改一下第 35 行的报错"，而是把那行和周围几行的代码原样粘贴。
3. 输入指令时带上边界说明，比如"只修改我粘贴的这段，函数的外部接口保持不变"。

这套组合拳的核心思路是：让模型聚焦在最小范围，排除一切无关信息。严格模式下它不会去翻旧账，也不会自作主张去改别的地方，你喂什么它看什么，指令越自包含，输出越精准。

我自己在写周报、改文章的时候也这么干。以前用自动模式，让 AI"润色得更有说服力一点"，它会把我上一段聊的某个需求里的词汇也顺手塞进来，导致文风割裂。切到严格模式，我把要润色的段落单独贴出来，它输出的就是纯粹的润色结果，干净得很。

3.2 跨文件重构：扩展模式要配合"白名单"思维

跨文件改动是扩展模式的主场，但直接用默认的"全项目上下文"是个坑。更稳的做法是手动控制 AI 能看到哪些文件，而不是让它自己满项目瞎逛。

我常用的配置方法是：

1. 先把 context-mode 切到扩展/项目模式，但立刻在对话中给出明确的范围指令，比如"本次任务只需要参考 src/models 和 src/utils 下的文件，其他目录不要读"。
2. 文件数量控制在 8 个以内。如果项目很大，先让 AI 用一个宽泛的问题梳理目录结构，定位真正相关的文件，再把这些文件加入到上下文里。
3. 为关键文件添加描述性注释，比如在对话里先写一句"以下文件是用户数据模型，修改它会影响所有引用它的地方"，给 AI 一个理解文件的锚点。

为什么控制文件数量这么重要？因为扩展模式下输入的 token 数量直接决定响应速度和成本。我做过一次简单测算：一个中等规模的 TypeScript 项目，把 20 个核心文件全部送进上下文大概消耗了 18K token，而一个 128K 窗口的模型，单次请求的成本几乎是严格模式的 10 倍以上。更别提长上下文会让首字响应时间从 1 秒拖到 10 秒，那个等待过程非常煎熬。

3.3 长对话续接：上下文压缩是省 token 的关键操作

长对话是 context-mode 里最容易被忽视的坑。你和 AI 连续聊了 50 轮，自动模式会把 50 轮的历史全部带上。可问题是，前面 40 轮里可能 90% 的内容已经过时了，比如你早就改口说"不采用 B 方案了，用 C 方案"，但旧对话里 B 方案的细节还在，模型一读到那些内容，很可能又变回 B 方案。

遇到这种情况，我的做法是定期做一次"上下文重置 + 总结转录"：

1. 当对话进行到 20 轮左右，或者发现 AI 开始反复引用旧方案，就停下来。
2. 让 AI 用 300 字以内总结当前已确认的需求、边界和决策，输出成一段"状态摘要"。
3. 开一个新对话，把 context-mode 设为严格模式，再把状态摘要作为第一段内容粘贴进去，之后继续提问。

这个操作的本质是手动把便签纸的关键内容誊写一遍，扔掉无关的旧笔记。实测下来，它的效果非常明显：不仅 token 消耗直接减半，AI 的响应质量也明显回升，因为你喂给它的全部都是有效信息。

4. 排查实战：AI"失忆"、越改越乱、响应变慢的根源都在 context-mode

4.1 症状一：AI 突然忘记你几轮前提过的要求

典型特征是：你前面明确说了"变量命名用 camelCase"，过了几轮它给你输出 snake_case，你质疑它，它道歉说"你说得对，我忘了"。

这种情况 90% 是上下文被截断导致的。很多工具在上下文超过窗口上限时，会静默丢掉最早的部分对话，而不是报错。你以为是模型记忆不好，其实是它根本就没"看到"过那段内容。

排查方法很简单：把当轮对话往回调，看看 AI 在回答你当前问题时，有没有引用之前某个关键指令。如果它没提，大概率那段指令已经被挤出了窗口。解决办法就是我上面说的"状态摘要 + 新对话"，别指望靠重复提问把一个已被截断的上下文拉回来。

4.2 症状二：越改越乱，每次修改都引入新的问题

这个现象在编程场景里尤其常见。你用自动模式让 AI 修一个 bug，它修好了 A，却把 B 地方弄坏了，你再让它修 B，它又把 A 弄回去了。来回几次，代码越改越糟糕。

这一般是上下文里同时存在多个版本的代码，模型分不清当前有效的是哪个。当你把整个文件放进上下文，又连续多轮修改时，旧版本和新版本都在对话历史里，模型倾向于参考最近一次的输出，但你让它改的地方可能是旧代码里的。这时候最有效的操作是：保存当前稳定版本，开新对话，严格模式，只粘贴当前最新代码，一次性给出完整修改指令。别让 AI 在长历史里"猜"哪个是你要的版本。

4.3 症状三：响应速度断崖式下降，每个问题都要等很久

如果你发现同一个工具、同一个模型，之前秒回，现在每次要十几秒甚至更久，几乎没有别的可能，就是上下文里塞了太多内容。transformers 的注意力计算时间复杂度是 O(n²)，上下文长度翻倍，计算量翻四倍。你从严格模式的 2K token 切到扩展模式的 20K token，延迟上升不是 10 倍，是接近 100 倍。

这时候不用怀疑工具出问题，直接做减法：砍掉历史轮数、减少文件数量、或者干脆重置对话。我实测相同模型在 2K 和 16K token 上下文下的首字响应时间，分别是 700ms 和 6.3 秒，体感差距极其明显。所以当你觉得"AI 变笨变慢了"，第一件事永远是检查 context-mode 相关的配置，而不是抱怨模型不行。

4.4 避坑清单：这些细节能帮你多省 30% 的 token

最后整理一份我长期实践总结的避坑清单，直接抄作业就行：

• 关闭"自动将整个文件加入上下文"这类开关，改为手动选中代码片段加入对话。
• 当你在对话里粘贴了一段新代码，记得说明"下面的代码是当前最新版本，以此为准"，防止模型拿旧版本做参考。
• 用扩展模式之前，先问一句"哪些文件与当前需求相关"，让 AI 自己列出文件清单，你再决定放哪几个进去，比你盲目拖进整个项目高效得多。
• 每个大任务开始时重置一次对话，不要在一个对话里反复切换任务类型。
• 如果工具支持"上下文白名单"或".cursorrules"之类的项目规则文件，把固定的约定（比如命名规范、目录结构）写进去，这样即使切到严格模式，这些规则也会作为系统提示词保留，不会丢。

我现在的习惯是：默认严格模式，需要跨文件时才切扩展模式，每次切换都在对话开头明确声明"本次只关注 XX"。长期下来，token 消耗大约降了三分之一，AI 的输出质量却稳定了不少。context-mode 这个东西，本质上就是一个取舍开关——你把控制权握在自己手里，AI 才能精准干活，而不是变成一个看起来很努力、实际上处处添乱的同事。