上下文窗口是什么？一次讲清模型的「工作台容量」
我发现很多初学者会问一个很经典的问题：为什么聊到后面，模型好像把我前面说过的话忘了？
我一开始也以为是模型「记性差」，后来才搞明白，问题通常不在记性，而在上下文窗口这个硬性容量上。
之前我写过 Token 相关的几篇基础文章，这篇就不重复切词原理了，专门把上下文窗口这个概念讲透。看完你会知道它到底是什么、怎么算、超了会怎样，以及该怎么省着用。
一、上下文窗口到底是什么
简单说，上下文窗口就是模型在一次回答时能同时看到的内容总量上限。
我喜欢用一个比喻来理解：模型没有长期记忆，它更像一个每次都清空的办公桌。你的提问、之前的对话历史、系统提示词、工具返回的结果，全都要摆在这张桌子上，模型只能看着桌子上的东西作答。桌子有多大，就是上下文窗口有多大。
几个关键点：
- 它是一个容量上限，单位是 Token，不是「条数」。不是说能记 50 条消息，而是能装多少 Token。
- 它同时装输入和输出。你塞进去的内容越多，模型能用来回答的空间就越少。
- 它是单次可见范围，不是永久记忆。关掉对话，模型不会记得你。
二、窗口里到底装了什么：一份完整清单
很多人超限了都不知道为什么，其实是因为忽略了「隐性内容」。一次请求里占用窗口的通常包括：
| 内容类型 | 是否占用窗口 | 常见误区 |
|---|---|---|
| 系统提示词/人设设定 | 是 | 以为它是免费的 |
| 你的当前提问 | 是 | 长文档粘贴最容易超 |
| 历史对话记录 | 是 | 越聊越占地方 |
| 模型的回答 | 是 | 回答本身也占额度 |
| 工具调用返回结果 | 是 | 接口返回的大段数据很吃空间 |
| 附件、网页、图片解析文本 | 是 | 以为只是「看一眼」不占额度 |
所以一个很实用的心算是：
可用空间 = 上下文窗口总容量 − 系统提示词 − 历史对话 − 本次输入 − 预留给回答的空间
三、输入和输出是共用一个窗口的
这一点我踩过坑：我以为窗口是「输入上限」，于是贴了超长材料，结果模型要么报错，要么回答被硬生生截断。
正确理解是：输入加输出，加起来不能超过窗口总容量。
举个不带具体数字的直观例子：假设某个模型的窗口能装 N 个 Token，你这次贴的材料加历史对话已经占掉九成，那模型最多只能用剩下的一成来写回答，写到一半就到顶了。
这就是为什么很多产品里会单独有一个「最大输出长度」的设置项，它本质上是在给回答预留空间。下面是一个示意写法，具体参数名以官方文档为准：
# 伪代码示意：为回答预留空间
窗口总容量 = 8000
本次输入占用 = 6000
预留回答空间 = 1500
剩余可用 = 窗口总容量 - 本次输入占用 - 预留回答空间
如果 剩余可用 < 0：
提示「内容过长，请删减材料或分批提问」
else:
正常发起请求，并限制最大输出不超过预留空间
四、超过窗口会发生什么
不同产品和接口的处理方式不一样，常见有这几种：
- 直接报错：提示内容过长，请求失败。API 调用里最常见。
- 自动截断：砍掉最早的内容，通常是历史对话的开头。表现就是「模型把前面的事忘了」。
- 拒绝处理：产品界面提示你新开一个对话。
- 回答被切断：输入刚好卡满，输出写到一半戛然而止。
我建议你遇到「模型失忆」时，第一反应不是怪模型，而是先算一下窗口占用。八成情况都是容量问题，不是能力问题。
五、怎么快速估算自己占了多少
不需要精确到个位，量级对了就够用。我的做法是三步：
第一步：数字符，换算大致 Token 量。
经验上，中文一个字往往接近 1 个 Token，英文大约 4 个字符对应 1 个 Token。这只是粗估，精确数字请以官方计数工具为准。
# 粗略估算思路
中文内容：字数 × 1 ≈ Token 数
英文内容：字符数 ÷ 4 ≈ Token 数
总占用 = 系统提示 + 历史 + 本次输入 + 预留回答
第二步：优先砍三块最占地方的内容。
系统提示词里的重复啰嗦、历史对话里的旧附件解析结果、与本次问题无关的大段背景材料。
第三步：留出回答空间。
至少给回答留出总量的百分之十几到二十，否则回答容易被截断。
六、四个立刻能用的省空间技巧
这部分是我实践下来最有效的，按性价比排序：
1. 摘要代替全文
不要每轮都把完整材料挂在历史里。聊到第五轮时，把前几轮结论压缩成一段摘要，只保留摘要，丢掉原始长文本。
2. 拆分任务，分批喂料
一份长文档分段处理，每段让模型输出小结，最后只把小结汇总起来做总分析。这样窗口永远只需要装「一段原文加若干小结」。
3. 只给必要上下文
新问题如果和前面无关，就开新对话。别让无关历史一直占着桌子。
4. 用检索代替塞满
资料很多时，不要一股脑贴进去，而是先检索出和问题最相关的几段再给模型。这就是常说的检索增强思路，能大幅降低窗口压力。
七、长上下文不是万能药
现在确实有不少模型支持很长的窗口，但我的体会是，别迷信「窗口越长越好」：
| 现象 | 说明 |
|---|---|
| 中间内容容易被忽略 | 材料太长时，模型对开头和结尾更敏感，中间细节可能被漏掉 |
| 成本会涨 | 塞进来的每一段内容都在计费和计数范围内 |
| 速度会慢 | 输入越长，处理时间通常越长 |
| 关键信息仍需突出 | 重要结论最好显式写出来，别指望模型自己从海量文本里挖 |
所以我的原则是：能用短上下文解决的，绝不硬塞长材料。把关键信息前置、明确、结构化，效果往往比堆字数好得多。
八、动手清单：下次对话前先做这四件事
- 确认当前模型的窗口大小和最大输出限制（以官方说明为准）。
- 估算本次输入的大致 Token 量，给回答留足空间。
- 检查历史里有没有可以丢掉的旧材料。
- 长任务优先考虑拆分加摘要，而不是一次性全塞。
做到这四点，你会发现「模型失忆」「回答被截断」这类问题基本消失了。
最后总结一句：上下文窗口不是玄学，它就是一张大小固定的桌子。学会收拾桌子，比换更大的桌子更实用。