最近不少AI产品都悄悄加了一个按钮，有的叫“深度思考”，有的叫“精简回答”，本质上都是同一个东西在用户端的体现——context-mode，上下文模式。我平时帮团队调AI应用，也帮不少朋友优化自己接的API调用，发现大部分人压根没搞明白这个模式到底在切换什么。有人以为开“深度思考”就是模型变聪明了，有人嫌回答啰嗦就永远开精简，结果在长文档分析上翻车翻得很难看。

这篇东西就把context-mode从头到尾拆一遍：它到底是什么、底层在做什么、什么时候该选哪个模式、选错会出什么问题、真出问题了怎么排。我尽量用干活的视角讲，不堆术语，适合正在用AI工具写东西、做分析、写代码的人，也适合想把这类功能做进自己产品里的开发者。

1. context-mode到底是什么——先说清楚它切换的其实是“工作台”

1.1 上下文窗口：模型一次能“看到”的全部文本

要理解上下文模式，得先理解上下文窗口。上下文窗口是模型在处理你当前请求时，能一次性读取的全部文本量。它包含你刚输入的问题、历史对话记录、上传的文档内容，以及系统预设的指令。你可以把它想象成一张工作台：摆在上面的所有资料，模型在做决定时都能参考；没摆上去的，它“看不到”，跟你没提过是一回事。

不同模型的窗口大小差别很大，小的几千token，大的能到几十万甚至上百万token。但“能容纳”和“利用得好”是两码事。就像桌子能摊开一百份材料，可你眼睛一次只能聚焦几份。上下文模式，本质上就是在管这张桌子——哪些材料摆上来、哪些收进抽屉、以什么顺序摆。

1.2 三种主流上下文模式的功能差异

我实际接触过的产品，不管名字怎么起，底层无非是几种模式在排列组合：

• 标准模式：完整保留最近的对话历史，通常保留最近几轮到十几轮的原始消息。所有历史都能被模型看到，但超出一定轮次后会被裁掉。适合日常问答、信息查询、简单修改。这个模式最安全，也最不容易让人产生“AI怎么变傻了”的错觉。

• 聚焦模式（也有人叫简洁模式、快速模式）：只会把当前输入和很少量的核心上下文传给模型。有的实现会优先保留系统指令和最新一条消息，之前的对话全部丢弃或只留摘要。优点是响应快、消耗少，缺点是模型“没有记忆”，你前面说过的东西它会忘。这个模式如果用在需要连续推理的复杂任务上，会非常灾难。

• 扩展模式（长文模式、全局模式）：尽可能把全部上下文塞给模型，包括长文档、多轮历史、检索到的参考片段。有些产品还会在后台做分块压缩、知识图谱之类的处理，让模型可以“浏览”整份资料。代价是响应变慢、费用上升，而且窗口塞得太满时，模型反而会抓不住重点。

这三者的关系，拿做饭类比特别合适：标准模式是厨房备齐常用调料（够用就好）；聚焦模式是你只拿盐和锅就开火（快，但很多菜做不了）；扩展模式是食材、菜谱、厨具全摊开（全面，但找东西的时间也上去了）。没有哪个绝对好，只有匹配不匹配。

1.3 被大多数人忽略的“生成风格”其实也是上下文模式的一部分

还有个经常被混为一谈的东西——生成风格。同样是“回答这个问题”，你可以让模型给三句话结论，也可以让它给完整推导过程。这类设置在很多产品里也被塞进了“模式”选择里，和真正的上下文取舍混在一起。我个人建议把它和上下文范围分开理解：

• 上下文范围管的是“模型参考什么”；
• 生成风格管的是“模型怎么表达”。

两者经常一起出现，但背后逻辑完全不同。你看那些AI产品里的预设选项，“简洁模式”往往是“小上下文+短回答”，“深度模式”是“大上下文+长回答”。明白这一层之后，你就能在自定义选项时把它们拆开调，而不是被预设框死。

2. 不同场景下的模式选型——我踩过坑之后的真实推荐

2.1 日常问答和内容润色：标准模式就是最优解

日常碎片化问答，比如查资料、问概念、让AI帮忙改个段落措辞，这类任务有两个特点：一是单次独立性强，二是上下文之间关联弱。用扩展模式纯属浪费，响应慢、费用高不说，模型还容易被前面无关的闲聊干扰。用聚焦模式呢？改文案这种活儿，AI往往需要知道你整体的语气和前后文，只给一句话，它给你改完可能风格都对不上。

这种情况下我就推荐标准模式。它保留最近几轮对话，足够维持一个连贯的工作状态——你让AI“接着上一版改”，它知道你说的是哪一版。如果对话超过了一定轮数，标准模式会自动丢弃最早的，这个机制正常情况下不会伤到你，因为它丢掉的通常都是已经“翻篇”的内容。

2.2 长文档分析与代码调试：扩展模式才扛得住

要说最需要认真选模式的场景，一定是长文档分析。拿我自己处理过的一件事举例，有回让我分析一份七十多页的产品需求文档，标准模式读完前二十页就开始混淆后面的内容，问“第三章的需求是什么”，它答的是第二章的内容。后来切到扩展模式，同样的PDF，它一口气把全文读完，再问细节就准确多了。

代码调试同理。一段几百行的代码，如果你只把报错行数发给模型，使用的是聚焦模式，它能做的就是帮你猜；把整个相关模块代码都喂进去，切换扩展模式，它才能顺着调用链帮你查状态传递、找出变量覆盖的问题。这里有个平衡要注意：扩展模式也不是把越多代码塞进去越好。一次让它读几百个文件，它照样会蒙。我习惯的做法是，把报错信息连同涉及的模块文件一起给，控制在能覆盖问题链路的最小范围，效果反而最好。

2.3 多轮对话和琐碎沟通：别让上下文变成“杂音放大器”

还有一种很隐蔽的坑：多轮对话里的上下文是这样累积的。前几轮你让AI帮忙写了一份活动方案，后面又让它改表格公式，中间聊了几句无关的闲天。这些内容全都会被当成上下文保留下来。在标准模式下，后面的回答会同时参考这些杂七杂八的信息，模型很容易被带偏——它可能突然“记起”你前面说过的一个不相干细节，然后塞进当前答案里。

遇到这种对话已经聊乱的情况，与其纠结用哪个模式，不如直接清空重开。很多产品都有“新对话”按钮，这个操作成本极低，但能彻底避免上下文污染。我自己有个习惯：每切换一个任务类型，必开新对话。写代码归写代码，写文案归写文案，不混在一个上下文里。这也是context-mode使用中最容易养成也最容易被忽略的好习惯。

2.4 场景选型速查表

为了方便你直接照着选，我把常见场景和推荐模式整理成一张表：

这张表只是起点，真正精确的选型还得看你手里AI产品的具体实现。但大方向是靠谱的：单次任务，小的对；全局任务，大的对；前后要连贯的，取中间。

3. 实操环节——从用户到开发者都适用的配置与参数解析

3.1 窗口资源怎么分配：不是全塞进去就完事

如果你只是用现成的AI产品，这段你可以大概扫一眼，但如果你是开发者、或者自己在搭AI工作流，这一节是关键。

一个请求的上下文窗口，要放的内容其实是四部分：系统指令、历史对话、当前输入（比如文档）、预留生成空间。很多人的误区是只盯着“把历史对话和文档塞进去”，忽略系统指令和输出空间。

先说系统指令。这个必须软性固定，而且要放在所有内容的最前面。它决定了模型的角色、回答规范和约束条件，一旦被历史对话挤掉，模型行为会明显“漂移”。我自己写配置时有个习惯，系统指令单独算一份预算，通常控制在500到800token以内，写清楚“你是谁、输出什么格式、不能做什么”，不写废话。

再说输出空间。这是特别多人栽跟头的地方。你把窗口塞得满满当当，留给模型生成回答的空间就只剩一点点。于是模型开始“惜字如金”，回答变得简短敷衍，或者直接中断输出。我见过好些人说“换了扩展模式之后AI反而变笨了”，排查到最后，就是上下文塞满、输出空间不足导致的。预留生成空间，我建议至少留总窗口的15%到20%。

3.2 历史对话的三种处理策略

历史对话是上下文里最灵活的部分，也是最值得花心思处理的。常见的策略有三种：

• 滑动窗口：只保留最近N轮对话，更早的直接丢弃。简单、省事、实现成本低，适合大部分场景。缺点是中间的关键信息会跟着一起丢。
• 滚动摘要：把较早的对话压缩成几句话的摘要，保留摘要本身，丢掉原始对话。例如六轮前说过“客户预算有限，方案就按五千以下设计”，摘要里记成“预算上限五千”。这个策略兼顾记忆和篇幅，代价是细节有损。
• 检索式注入：不主动保留全部对话，而是先解读当前问题，从历史记录和数据源里检索最相关的片段放进来。这是最省窗口的方式，也是很多“智能助手”背后在用逻辑。实现稍微复杂一点，但效果最稳。

如果你在产品里做context-mode，我建议至少做前两种，让用户自己选；如果团队有余力，第三种能做出明显的差异化体验。但要注意，检索式注入需要保证检索质量——检索得不准，结果比老实全塞进去更糟。

3.3 一个可直接参考的上下文配置示例

下面这份配置是我在实际项目里调过的，思路是“系统指令固定、历史摘要化、当前文档全文优先、输出空间兜底”。你可以拿这个当起点，再根据实际效果微调：

{ "context_mode": "extended", "window_budget": { "system_instruction": 800, "conversation_summary": 1500, "current_document": 6000, "retrieved_references": 1200, "reserved_output": 2500 }, "history_policy": { "max_raw_turns": 6, "older_turns": "summarize", "summary_sentence_limit": 3 }, "retrieval_policy": { "enabled": true, "top_k": 5, "min_score": 0.35 }, "fallback_behavior": "truncate_oldest_history" }

几个字段的意思拆开讲一下。max_raw_turns设成6，意思是最近6轮用原始对话保留，这部分信息最鲜活，直接喂给模型。再往前的，走summarize策略，压缩成摘要。retrieved_references是当检索命中时用的预算，top_k控制在5条以内，分数低于0.35的不要，以免引入噪音。最后的fallback_behavior是指如果窗口真的超了，就丢弃最早的历史，这个行为最安全，不会把当前输入切断。

这套配置跑下来，实测在长文档问答上效果不错。它有几点值得借鉴：

• 当前文档给的预算最大（6000），因为“正在处理的内容”优先级最高；
• 摘要不是无限膨胀的，限制在三句话内，逼着系统提取最核心的信息；
• 输出兜底（2500）始终保留，保证生成质量。

3.4 为什么不能无限扩大上下文：注意力与成本的取舍

很多人的第一反应是“那我把上下文窗口买大点，全部塞进去不就行了”。且不说成本，光是效果这关就过不去。模型的注意力是有限的。窗口越大，模型越是平均用力，关键信息反而容易被淹没。有个形象的说法：上下文越长，模型越像“读了太多资料后疲劳的实习生”，你问它重点，它说出来的可能是个无关紧要的细节——这就是所谓的“注意力稀释”效应。

从成本上说，上下文token越长，单次调用费用越高，响应耗时也越长。而且对于多数任务，模型真正依赖的核心信息可能就集中在几句话里。与其把全部资料堆上去，不如做好取舍。这也解释了为什么context-mode的设计本质上是“信息管理策略”而非“窗口大小调整”——真正的功夫在于选什么喂、怎么处理再喂，而不是买多大窗口。

4. 常见问题与排查技巧实录

4.1 症状：切换模式后回答质量明显下降

这个现象特别常见，尤其从扩展模式切回标准模式，很多人马上觉得“AI变蠢了”。排查思路其实很简单：先别急着怪模型。绝大多数情况是，历史对话里的关键信息被新模式的策略清掉了。

比如你让AI看完一份合同，前几轮问过“违约金比例那条”，切到标准模式再问“那这条和第几条冲突吗”，它可能完全没接上。原因就是合同全文不在新模式的上下文里了。解决办法，一是回到扩展模式，二是把关键原文手动粘回去。这里有个经验：当你需要在对话中保留一个很重要的信息时，最好的办法不是指望AI记住，而是在当前提问里主动带上关键片段。比如直接写“基于这份合同里违约金是20%的条款，和下面这条有没有冲突……”——这类“自包含提问”能绕开上下文模式的所有限制。

4.2 症状：长文档分析时前面的内容被无视

长文档分析，尤其是几十页起步的材料，就算开了扩展模式也有人会遇到“前面的内容被忽略”的情况。原因通常是窗口确实塞满了，或者文档太长，模型阅读时对前部内容的权重会自然降低。这时候如果你用的是支持分段处理的产品，可以手动把文档拆成几个部分，分别问一遍，再让AI汇总。这个过程麻烦一点，但准确度很不一样。

我实际操作时的流程是这样：先让它读第一章到第三章，列要点；再读第四章到第六章，列要点；最后把两份要点一起丢进去，让它交叉比对。这和让一个人分次读书再交流笔记是一个道理，模型每次聚焦的内容少了，理解自然更深。

4.3 症状：输出越来越简短，或突然中断

如果你没改过任何设置，但AI的回答越聊越短，十有八九是上下文运行在“满负荷”附近。这在扩展模式追加了很多历史后最容易出现。刚才讲了，输出空间被挤压，模型只能给你挤牙膏式回答。排查方法也很简单：开新对话，把关键信息带过去，输出长度基本会恢复。

还有一种情况是回答写到一半中断。如果产品没有自动续写能力，这可能就是上下文预算爆了。解决思路相同：缩短输入、整理历史，给生成留出空间。做产品的话，这时候最好的前端处理是自动检测接近窗口上限，提前提示用户，而不是等到断了才报错。

4.4 症状：越到对话后期，AI越容易“串信息”

聊得越久，对话里的信息越多，模型把前期信息搞混的概率就越高。这个不是错觉，是长上下文带来的固有现象。尤其是早期对话里的一些细节，在后期可能会被模型错误地“缝合”进新问题里。

一个例子：你前期说过“方案A比较贵”，后期在聊预算时，AI可能会把“贵”这个属性自动关联到别的方案上。这种错误很难彻底根治，但可以缓解。我习惯的做法是，在觉得对话开始“飘”的时候，主动做一次“信息复位”：把当前需要的信息用全新一句话重述，开启新对话继续。这和程序员“重启大法”有点像，不好说是最优解，但确实每次都能解决问题。

4.5 排查思路速查表

这张表其实透露了一个核心思想：context-mode不是设置一次就完事的开关，而是要随着对话的进展不断重估。开始用扩展模式拿到全局信息，分析得差不多后，切回标准模式做具体加工；做完了重新问新问题时再开新对话。模式跟着任务阶段走，而不是一直锁死在某一个选项上。

5. 一些个人心得，关于context-mode的深层理解

做context-mode相关功能这么久，我最大的体会是：这个模式的本质不是“给AI更多资料”，而是“帮AI聚焦重点”。模式切换的名字可能各不相同，但底层逻辑万变不离其宗——上下文的管理策略。这个观念想通了，你就不需要死记硬背任何产品说明书上的模式推荐了，看一眼任务的上下文需求，自然知道该开哪个档。

另一个心得是关于信息位置的。不管用哪个模式，把最重要的信息放在离问题最近的位置，永远是性价比最高的操作。模型的注意力天然偏向靠后的内容。这个规律在聚焦模式里最明显，在扩展模式里也存在。高手和新手用同一个模型、同一个模式，差别往往就体现在这里：高手会主动调整输入内容的组织顺序，新手只会抱怨AI不够聪明。

最后分享一个在项目里常用的小技巧：每次准备让AI处理复杂任务前，先花十秒钟想一下——“如果只让AI看三样东西，应该给它哪三样？”想清楚了再决定用什么模式、喂什么内容。这个习惯帮我省下大量token和调试时间，也减少了无数“AI答非所问”的瞬间。把context-mode当成整理桌面，而不是无限堆纸，你的使用体验一定会上升一大截。