1. 内容整体设计与思路拆解

1.1 context-mode 到底是个什么东西

我先说结论：context-mode 在当下 AI 工具圈里，最常见的指向是 Claude 那套“上下文模式”的玩法，尤其是一段时间里大家截图疯传的那条系统指令——让模型在处理超长文档、多轮对话或者编码任务时，把“当前上下文”折叠成一份可查看、可核对、可追溯的结构化摘要。说白了，就是给大模型的记忆装了一个“目录页”。

我没记错的话，这条指令最开始是在一些技术论坛和推文里传开的，原文大致意思是：当用户上传了大量材料或者对话特别长的时候，建议模型开启 context-mode，自动把上下文归纳成若干区块，并在每次回复前先展示这份“上下文摘要”，让用户一眼看清模型记了什么、忘了什么、准备做什么。很快就有不少人把它当成了“官方隐藏技能”去折腾。

这里我想先纠正一个误区：context-mode 不是什么模型自带的开关，也不是什么高深的新算法。它本质上是一条精心设计的系统提示词，利用的是大模型对指令的遵循能力，让模型自己维护一份上下文清单。理解这一点特别重要，因为它决定了你到底该怎么用它——你不是在“打开一个功能”，而是在“教模型用一种更好的工作方式”。

这个模式能解决的问题非常具体：

• 接了一个 500 页的 PDF，模型聊着聊着就忘了前面的结论，你要反复重复背景；
• 多轮对话里，模型把早期确认过的关键决策悄悄改掉，你还浑然不觉；
• 一份代码库的上下文太长，模型越往后回答越飘，东一句西一句；
• 咱们自己作为用户，根本不知道模型到底“以为”自己记住了什么。

context-mode 就是冲着这些痛点去的。它的核心价值不是让模型记住更多，而是让“记忆状态”变得透明、可管理。

1.2 为什么需要给模型做“上下文目录”

我在实际使用大模型做长文档分析的时候，遇到的最大的坑其实不是模型笨，而是模型“自以为记住了但记串了”。有一次我让它读一份几十页的行业研报，前面明明已经确认了某个关键数据口径，到了第 20 轮问答时，它居然按照一个完全不同的口径重新算了一遍。一核对发现，它把这个口径跟另一份参考文档里的说法搞混了。

这其实就是上下文管理的经典问题：模型每轮对话都要重新处理全部上下文——或者被截断的部分上下文——它对早期信息的“记忆强度”会随着中间内容的增加而不断衰减。你让它一次读 10 份文档，它当然不是像人一样读完就记住了，而是在每个生成步骤都重新“看”一遍所有内容，然后注意力机制会把权重分散到最新、最显眼的部分去。

上下文窗口再大，也架不住内容多。而且很多时候我们真正需要的不是“无限上下文”，而是把关键状态固定住。context-mode 的做法就很聪明：它让模型自己主动去维护一份摘要目录，相当于每次回答问题之前，先花一点点精力整理好自己的工作台，把最重要的几件事摆在桌面上。你上传一堆材料，它会先归纳出“领域/任务/已知信息/未知信息”几个区块；你中途补了一段新信息，它会更新这份摘要再继续回答。

这个思路放在工程上，就是在做有状态服务的内存管理：与其让所有历史数据都占据注意力资源，不如抽出最关键的状态快照，让模型基于快照进行推理。这个逻辑听起来简单，但真正用好了，效果提升非常明显。

1.3 这套模式适合谁用

说实话，不是所有人都需要 context-mode。我自己测试下来，下面这些人用了是真划算：

• 做行业研究和报告解读的人：动不动就上百页的 PDF、招股书、年报、研报。这类内容细节多、前后关联性强，非常适合让模型用 context-mode 结构化拆解，然后你基于拆解结果去追问。
• 写代码的人：一次性把整个项目核心文件贴进去，或者把一堆报错日志、框架配置文件交给模型分析。context-mode 能让模型先建立起“项目背景”区块，再逐块分析具体问题，比直接提问稳很多。
• 做知识管理的人：把零散笔记、访谈记录、会议纪要丢给模型，让模型先整理上下文框架再回答，输出质量明显上了一个台阶。
• 用 API 做开发的工程师：你可以把 context-mode 的系统提示词固化在你的应用里，让每次请求都先要求模型维护上下文摘要，相当于不写代码就获得了一层简单的记忆管理。

反过来，如果你只是问一些轻量级问题，比如“这道菜怎么做”“这段文字帮我润色一下”，那 context-mode 就是纯纯的累赘——它会让每次回答的开头都多出一段结构化总结，白白消耗 token，还显得啰嗦。工具用对场景才有价值，这是我要说的第一条经验。

2. 核心细节解析与实操要点

2.1 指令的核心结构拆解

要理解 context-mode，最直接的办法就是把那条系统指令拆开看。我根据自己实际测试和网上公开流传的版本，整理出一份可以复用的框架，它有五个关键模块：

第一模块：角色设定。明确告诉模型“你现在是一个擅长处理和分析复杂上下文的助手”，并要求它在回答前先整理上下文。这一步是在给模型“定调”，因为大模型的输出风格高度依赖角色预期，角色设定越清晰，后续行为越稳定。

第二模块：动作要求。核心指令是让模型“在回答前先回顾并整理对话中的所有信息和材料”，并将整理结果以 Markdown 的引用格式输出。用引用块的目的是从视觉上把“上下文摘要”和“正式回答”区分开，方便你快速扫描模型到底记住了哪些信息。

第三模块：结构模板。要求摘要必须包含几个固定区块，常见的是：对话目标与任务、已知的确定性信息、不确定性信息、目前进行中的事项。这个模板化的输出设计非常关键，它相当于强制模型把杂乱的信息分类归档，比笼统的“请总结一下上下文”要精确得多。

第四模块：动态更新机制。要求模型在每轮回答时都更新这份摘要，把新增信息合并进去。这是 context-mode 和单纯“总结上下文”最关键的区别——它不是一个静态的快照，而是一个持续维护的动态状态。

第五模块：边界约束。要求模型严格区分“上下文里有的事实”和“自己推测的内容”，遇到缺失信息时明确说明，而不是为了迎合用户而编造。这个约束能从机制上大幅压低模型一本正经胡说八道的问题。

五个模块组合在一起，效果就是：模型每轮回复之前先亮出当前的工作记忆清单，你看一眼就知道它有没有跑偏。如果跑偏了，你在回复里指出来，它下一轮就会修正这份摘要。在我看来，这套东西本质上是用“少量额外 token”换“全局一致性”的巧妙交易。

2.2 核心参数与 Token 成本核算

我知道很多人关心一个现实问题：开了 context-mode，会不会特别费钱？说实话，会有额外开销，但比你想的小得多。

咱们来算一笔账。假设你贴了一份 5 万 token 的文档进去，然后开始多轮问答。正常情况下，每一轮问答模型都要把 5 万 token 的文档全部过一遍，哪怕你只是问一个简单的问题，注意力也要遍历全部内容。开启 context-mode 后，模型在每轮回答前会额外生成一份上下文摘要。这份摘要写得好，大约占用 1 到 2 千 token——相比 5 万 token 的基数，只增加了 2% 到 4% 的输入成本。

而换来的收益是：后续每轮问答，你其实可以让模型优先基于摘要进行回答，只有在你需要深究某个具体细节时，再让它回到原始材料中查找。我在测试中甚至发现，有些场景下模型的输出质量会因为上下文摘要的存在而显著提高，反而减少了你来回追问、反复纠正的次数。算总账之后，总成本往往是降低的，不是升高的。

但这里有一个隐藏陷阱：如果模型的摘要是“重新回顾一遍全文”式的输出，而不是“基于已有摘要增量更新”，那每一轮都会产生一次大代价的全量处理。所以你在设计指令时，一定要明确告诉模型：“如果上下文摘要已经存在，直接在原有基础上更新，补充新增信息，不要重复全文。”我在实际使用时，发现不少模型默认会老老实实重写摘要，加了这句约束之后，成本立刻降下来了。

2.3 普通模式与 context-mode 的直观对比

我专门做了几组对照测试，用同一个问题、同一份材料，分别测试默认模式和 context-mode 的表现。这里把结果整理成一个表格，方便直观对比：

从这个表格里能看出，context-mode 最大的优势不在第一轮的惊艳，而在多轮对话的长期稳定性。如果你只是问一两个问题就结束，这个模式带来的提升有限；一旦对话超过 10 轮，尤其是中间穿插了大量材料补充，有没有上下文管理，表现差距会越来越大。

2.4 使用时的三个“绝对禁区”

我踩过不少坑，挑三个最典型的出来说。

禁区一：不要同时上传太多同类型文档，却不做区分。如果你一次性把 20 份合同丢给模型，用 context-mode 归纳出来的摘要很可能出现“张冠李戴”——把 A 合同里的条款混进 B 合同。我实测最稳妥的做法是：要么把文件重命名成清晰的编号（比如“附件1-采购合同-张三”），要么先让模型逐份概括，再统一汇总。文件名真的是模型理解内容的重要线索，别省这个功夫。

禁区二：不要在摘要已经很长之后还只用一轮对话硬撑。context-mode 虽然能维护摘要，但摘要本身也有长度上限。当摘要长到一定程度，模型会自己开始“简化”摘要，这过程中就可能在不知不觉中丢掉细节。我的经验是，当摘要超过 1500 token 时，就应该考虑“分叉对话”——核心问题留在当前对话，新话题开一个新的对话窗口，把旧摘要复制过去作为新对话的开场白。

禁区三：不要迷信“上下文越长模型越聪明”。我自己测试过，很多推理任务的准确率在上下文窗口用到 60% 以上后就开始下降，并不是说上下文越长越好。context-mode 的作用恰恰是把上下文“压缩”到精华部分，让模型在有限的注意力里聚焦最重要的信息。如果你还是给模型塞一堆无关材料，那模式再好也救不了。

3. 实操过程与核心环节实现

3.1 在网页端的完整配置流程

网页端使用 context-mode 非常直接，不需要安装任何插件或工具，核心就是在对话开头给它一段精心设计的指令。我把自己常用的版本分享出来，你直接照着输入就行：

你是一位擅长处理复杂文档和多轮对话的资深分析助手。在回答每一个问题之前，请先回顾当前对话的全部内容，并在回复的最前面以 Markdown 引用块形式输出一份“上下文摘要”。摘要需包含以下五个区块：1. 对话目标与任务；2. 已知的确定性信息；3. 尚不确定或缺失的信息；4. 当前正在推进的事项；5. 后续建议或待确认问题。如果之前已经输出过摘要，则基于既有摘要进行增量更新，补充本轮新增信息，不要重复已经有过的内容。在摘要之后，再给出正式回答。当信息不足导致无法完整回答时，明确告知缺失的信息点，宁可追问也不要推测。

输入这段指令之后，再把你的文档或材料贴进去，接下来的对话就全部处于 context-mode 的管控之下了。首轮回复时，模型就会先给你亮出摘要，你再开始正式提问。

我在实际使用时喜欢在文档后面附加一句：“以上为本轮新增材料，请更新上下文摘要后回答我的问题。”这样模型就会非常明确地先把新材料合并进摘要，再回答你的追问，不会出现“旧摘要和新材料互相打架”的情况。

这里有个小技巧：如果你希望摘要不被当作正式回答的一部分被误读，可以在摘要结束后加一条分割线，然后再写正式回复。引用块格式本身就能起到视觉分隔的作用，加上分割线更保险，尤其是当你把模型输出复制到自己的文档里时，前后分隔清楚能省不少整理时间。

3.2 在 API 调用中的固化玩法

如果你不是用网页端，而是通过 API 开发自己的应用，context-mode 的价值会更大——你相当于给自己的应用白嫖了一层“记忆管理中间件”。

实现方式不复杂：在构造请求时，把前面那段指令放在 system prompt 里，而不是放在用户的对话消息里。这样模型每次响应都会遵循该指令，不需要使用者手动粘贴。我用 Python 举个例子：

import anthropic SYSTEM_PROMPT = ( "你是一位擅长处理复杂文档和多轮对话的资深分析助手。" "在回答每一个问题之前，请先回顾当前对话的全部内容，" "并在回复的最前面以 Markdown 引用块形式输出一份'上下文摘要'。" "摘要需包含：1. 对话目标与任务；2. 已知的确定性信息；" "3. 尚不确定或缺失的信息；4. 当前正在推进的事项；" "5. 后续建议或待确认问题。" "如果之前已经输出过摘要，则在此基础上增量更新，不要重复已有内容。" "信息不足时明确告知缺失点，不要推测。" ) client = anthropic.Anthropic() def ask_with_context(conversation_history, user_message): messages = conversation_history + [{"role": "user", "content": user_message}] response = client.messages.create( model="claude-sonnet-4-5", max_tokens=4096, system=SYSTEM_PROMPT, messages=messages, ) return response.content[0].text

这段代码的要点是：

• SYSTEM_PROMPT是全局恒定的，所有请求都会带上；
• ask_with_context函数接收对话历史，把新的用户消息追加进去，再一起发给模型；
• 每次返回的结果就是“摘要 + 正式回答”的组合文本。

用 API 的方式还有一个额外好处：你可以在拿到模型回复后，自己解析出摘要部分，单独存储到一个变量或数据库里。下一轮对话时，直接把这份摘要放在历史消息的最前面，替代传统的全量历史回顾，既省 token 又稳定。

我用这个思路给一个小工具做过改造，原来每轮请求要把 2 万 token 的文档全文带上，改造后只需要带 1 千 token 的摘要加当前问题，成本直接降到原来的 5%。这个节省幅度相当可观，做应用开发的读者一定要试试。

3.3 在编码与调试场景中的特殊用法

编码场景我用 context-mode 的姿势和其他人不太一样，这里单独分享一下。如果你面对的是一个大型项目，需要让模型帮你定位 Bug 或者做代码审查，直接把整个项目贴进去往往不现实——代码量太大了。

我的操作分三步走：

第一步，让模型先读项目结构。我通常把项目的目录树、关键配置文件和入口文件的摘要先喂给它，让它维护一份“项目背景摘要”。图示如下。

src/ ├── api/ │ ├── client.py # 请求封装，包含重试逻辑 │ └── models.py # 数据模型定义 ├── core/ │ ├── engine.py # 主逻辑引擎 │ └── utils.py # 工具函数 ├── tests/ │ └── test_engine.py # 核心测试 └── main.py # 程序入口

第二步，逐模块分析。等背景摘要建立之后，再把真正需要审查的代码文件贴给模型，让它基于已有的项目背景来分析，这样就不会出现“看到一个变量名问一遍它是什么”的尴尬。

第三步，汇总问题清单。让模型输出一份问题列表，标明严重程度、涉及文件、修改建议。由于模型有前面的背景摘要，这份问题清单的准确度和可操作性比直接问要高得多。

这里有个额外小技巧，让模型在摘要中维护一份“已确认的技术决策”清单。比如你们确认了“异常处理统一走 retry 逻辑”“数据库连接走连接池”之类的决策，模型的上下文摘要会把这些决策固定住，后面的问答就不容易跑偏。这其实就是在用 context-mode 做团队技术共识的数字化沉淀。

3.4 多文档对比分析的高阶玩法

最后说一个我最近发掘出来的高级场景：多文档对比分析。

以前我对比两份合同，做法是把两份文档都贴给模型，然后让它“对比一下两份合同的差异”。结果模型经常只回复一个笼统的“两者存在多处差异”，具体差异点却很敷衍。

开了 context-mode 之后，我用了一个新的思路：先分别让模型为每一份文档建立独立的上下文摘要，再让模型基于两份摘要进行对比。

具体来说，第一轮对话：贴入文档 A，让模型输出文档 A 的结构化摘要。第二轮对话：另开新对话，贴入文档 B，让模型输出文档 B 的结构化摘要。第三轮对话：把两份摘要同时贴入新对话，附加指令“请基于以上两份摘要进行逐项对比，列出所有实质差异，并标注这些差异可能产生的影响”。

这个操作的关键在于：模型做对比时不需要重新看原文，只需要对比两份已经被提炼过的摘要。浓缩后的对比不仅速度快，而且由于摘要经过了结构化整理，模型更容易定位到真正的差异点。我在对比合同条款、技术方案和需求文档时用这个方法，效果出奇地好。

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

4.1 摘要越写越偏怎么办

这是我觉得最常遇到的问题：一开始摘要挺准，越到后面模型的摘要越“自由发挥”，甚至开始往摘要里塞一些根本没出现过的内容。这种情况通常不是模型变笨了，而是摘要更新机制出现了偏差。

我的排查思路分三步：

• 检查是不是对话中间引入了新的术语或概念，但你没有明确它们和旧信息的关系。模型在不确定性较高的状态下，容易倾向用推测填补空缺。
• 检查摘要中的“未知信息”区块是否存在。如果模型长期不标注“缺失信息”，说明你的指令约束不够强，它怕说“不知道”会显得不专业。这时候可以在指令中增加一句：“缺失信息是正常现象，请明确列出，不要猜测。”
• 如果以上两种检查都没问题，那就手动纠偏。直接在回复中写：“你第 X 条摘要里关于 Y 的描述不准确，正确的事实是 Z，请修正摘要后再回答。”大模型对直接的修正指令响应非常好，通常一轮就能掰回来。

4.2 开启 context-mode 后回复变慢怎么办

很多人在网页端第一次用 context-mode 时，最直观的感受是“怎么出字变慢了”。这其实非常正常——模型在生成正文之前，要先整理摘要，相当于多了一步思考过程。而且摘要本身也是逐字生成的，多花的这一两秒就是在写摘要的时间。

处理办法有两条路径：

路径一：接受这个速度损失，换取质量提升。如果你处理的是长文档、多轮对话、复杂推理，这几秒的等待完全值得。我宁可多等两秒换一个不跑偏的回答，也不愿意看到一个秒回但是胡说八道的答案。

路径二：把摘要的频率降低。把指令改成“每三轮对话更新一次摘要”或“仅当发现重要新信息时输出摘要”。这样虽然牺牲了一部分实时性，但能大幅减少速度损失。适合那些只需要保持大体方向一致、不需要严格逐轮管理的场景。

4.3 输出格式混乱，摘要和正文混在一起

这个问题也比较常见，尤其是当你用的模型版本比较低，或者指令措辞不够清晰时。模型有时候会在摘要里写一大段正文，有时候又跳过摘要直接回答。

解决办法是在指令中做双重约束：

• 第一重：明确格式要求。写明“摘要必须使用引用块，正式回答必须使用普通段落，两者之间用分割线隔开”。
• 第二重：给出反例。写明“不要将正式回答内容写入摘要区块，引用块内只允许出现五区块摘要信息”。

用自然语言给模型描述“不要做什么”，比单纯描述“应该做什么”更有效果。因为大模型对否定表达的约束能力其实是比较弱的，但把正反两面都说明白之后，它就很难搞混了。

4.4 摘要信息量太大，反而淹没重点

这是我后来才遇到的一个问题：context-mode 用得太久，摘要越写越长，信息密度越来越高，结果每次回复前光摘要就有几千字，看摘要的时间比看正文还多。这个模式就失去了它“快速把握重点”的初衷。

我对策是加一条硬性约束：要求摘要控制在 200 字以内，只维护最关键的一级信息。更细节的内容可以让模型放在正文里首次提及时再展开。换句话说，摘要负责“提词”，正文负责“展开”。这样每轮回复前扫一眼摘要只需要几秒钟，效率反而更高。

根据我的经验，200 字摘要 + 正文展开的组合，是最适合日常长对话的配置。如果你处理的材料特别复杂，可以把上限提高到 500 字，但尽量不要超过这个数，否则摘要本身的维护成本就失去意义了。

4.5 常见问题速查表

我把上面所有问题整理成一个速查表，方便你遇到问题时对号入座：

5. 我的一些补充心得与后续玩法

5.1 关于 context-mode 本质的一点点思考

用了这么久，我越来越觉得 context-mode 的价值其实不是“技术层面”的，而是“使用习惯层面”的。它逼着你用一种更结构化、更有条理的方式跟模型对话。以前我问模型问题，总是想到哪问到哪，结果模型也经常跟着我跑偏。现在每次它先给我亮出摘要，我反而会因为看到摘要而意识到：哦，原来我们已经确认过这件事了，那我不该重新问。我自己整理问题的思路变得更清晰了。

这种变化挺有意思的：你以为你在教模型怎么工作，其实模型也在反过来重塑你的工作方法。尤其是做复杂分析的时候，摘要本身的五区块结构——目标、已知信息、缺失信息、推进事项、待确认问题——本身就是一套非常好的思考框架，你可以直接借用到自己的项目复盘和文档管理中去。

5.2 后续可以扩展的方向

context-mode 这个思路其实可以延伸到很多场景，我自己正在尝试的有两个方向：

第一个是团队知识库的轻量化管理。我把每次项目会议纪要用 context-mode 的格式处理，生成结构化摘要，然后把这些摘要串成一个项目的时间线。后续写周报或者复盘的时候，只需要翻阅摘要时间线，就能快速还原整个项目的发展脉络。微信里聊过什么、文档里写了什么，都不重要了，摘要就是项目的“数字记忆”。

第二个是把 context-mode 和自动化流程结合。比如一个定时任务，每天早上把前一天的销售数据、客服反馈、竞品动态交给模型生成一份摘要，存到数据库里。坚持一段时间后，你就拥有了一份自动维护的“业务上下文库”，后续做任何分析，都可以基于这份上下文集来操作，而不是让模型每次都从头理解所有材料。

5.3 最后的经验之谈

如果让我用一句话总结对 context-mode 的体会，我会说：它教给我们的不是如何让模型记住更多，而是如何让自己与模型之间的沟通更有结构。上下文窗口再大，我们也不能指望模型把一切都记住；但我们可以通过清晰的结构、及时的纠偏和合理的摘要维护，让模型把“值得记住的事情”稳稳当当地记住。

我现在的习惯是，只要对话预期超过 10 轮，或者材料超过 1 万 token，第一件事就是启用 context-mode，没有例外。这个几乎成了我的肌肉记忆。你可以先拿一份自己手头的长文档试试，开与不开分别跑三轮问答，自己感受一下前后的差别，比我说一万句都有用。如果你也试出了一些新玩法，欢迎在评论区聊聊，我很乐意继续探索这套思路的边界。