上下文窗口：它一次能看多少

你把一份很长的招标文件交给 AI，追问第一页写明的付款条件。它回答得干脆，却引用了后半部分的一般条款，漏掉第一页那句例外说明。文件明明已经上传，为什么像没看见？

「放进去了」不等于「每一段都能被同样可靠地使用」。模型一次能处理的文字有上限；即使没有超过上限，关键信息埋在长材料中间，也可能被忽略。

先给答案

上下文窗口是模型单次处理输入与输出的容量。超限时，接口可能报错，产品也可能截掉、摘要或压缩旧内容；具体做法各不相同。没超限也不代表逐字记牢，长材料仍要测试检索和引用效果。

## 「一次能看多少」到底怎么算？

上下文窗口是模型一次生成时能够处理的 token 总量。也就是说，当前问题并不是单独占一个口袋；系统说明、先前对话、上传资料、工具返回的文字，以及模型准备写出的答案，通常都要在同一份容量预算里计算。

Token是模型切分文字后的处理单位。也就是说，窗口不是按 PDF 页数或汉字数计算。两份同为 30 页的文件，一份是短句表格，另一份是密集合同，消耗可能很不一样；扫描图片经过识别后也可能多出页眉、页码和乱码。

假设你先放入产品说明、合同、三轮讨论，又要求模型输出一份详细报告，可用空间会被这些内容共同占用。输出也需要留位置：输入已经贴到边缘，再要求写很长的答案，系统可能提前停止，或干脆拒绝请求。窗口的具体容量随模型和接口变化，应查看当前文档和实际用量，正文不值得背一个很快过时的数字。

模型不会自己把无限长的材料塞进有限窗口。超限处理通常发生在调用它的产品或接口层，而且没有统一答案。官方 API 可能直接返回「输入过长」错误；有的应用会删除最早几轮；有的会先把旧对话压成摘要；还有的只抽取上传文件中与问题相关的片段。用户界面若不说明，你看到的只是回答变了。

因此，「超出会被悄悄截断」只能描述某些产品行为，不能当作所有模型的固定规律。真正要问的是：系统送给模型的最终输入里还剩什么？企业采购时，应要求说明超限策略、告警方式和日志能力。

截断最早内容会造成一种常见故障。第一轮你规定「金额均含税」，聊到第二十轮后，这条规则被移出输入，模型开始按未税金额比较。摘要也会损失细节：原话是「法务与财务都批准后才能付款」，摘要若只留下「批准后付款」，两个前置条件就少了一个。

检索片段则有另一种风险。系统先从整份文件找几段，再交给模型回答；如果搜索没有找到第一页的例外条款，模型看到的上下文里就根本没有它。此时不是窗口装不下，而是选择材料的环节选错了。

研究者把关键信息放在长文本不同位置测试，发现不少模型在信息位于开头或结尾时表现较好，埋在中间时下降。这类现象常被称为「中间遗失」。也就是说，容量上允许看见，不代表模型能均匀利用每个位置。

例如，把 40 份短记录连在一起，其中第 21 份写着设备序列号，再问序列号是什么。模型可能答对；加入更多相似编号和无关说明后，它就可能拿错第 20 或第 22 份。窗口像桌面大小，只说明文件能摊开，不保证阅读者已经逐页核对。

这也是为什么「支持超长上下文」不等于「可以一次丢进所有公司资料」。窗口容量是准入条件，检索准确率、信息位置、材料冲突和任务复杂度共同决定结果。对合同审查，可以先按章节处理，再汇总风险；对多份制度，可以要求每条结论附文件名和原句；对关键数字，可用程序抽取后再让模型解释。

实践中还有三个简单办法。第一，删掉重复页眉、无关附件和过时对话，给真正需要的内容留空间。第二，把要求和关键资料放在清楚的位置，并给文件加标题或编号。第三，设计「针测试」，也就是在长材料的开头、中间、结尾各放一条可验证信息，检查系统是否都能找回。不要等上线后才用真实损失发现它漏读。

准备三段各约 300 字的普通文字，在第一段加入「项目代号是青砚」，第二段加入「验收口令是 4729」，第三段加入「归档标签是北岸」。把三段一起发给 AI，要求只返回三个值和对应原句。

我们在 2026 年 8 月用 Cursor 当前会话模型试过，三项都能找回。随后在三段中加入候选名称、旧编号和示例数字，仍要求引用原句；本次答案继续正确。短实验不能证明长文件一定可靠，它只提供一条基线。

你可以逐步增加无关材料，观察哪一项先漏掉；不要用机密文本测试公共聊天产品。你试的时候结果可能不同，重点是看它的行为模式。

误解一：窗口越大，模型就记得越牢。 窗口说的是可处理容量，不是每个细节的召回保证。长文本中间的信息仍可能被忽略。

误解二：上传成功就代表全文进入模型。 产品可能做文字识别、检索、摘要或截断。尤其是扫描 PDF、复杂表格和多栏排版，要检查实际抽取内容及引用。

不要只比较窗口宣传数字。请供应商说明超限策略，并用你最长、最乱的真实文档做开头—中间—结尾召回测试，逐条检查原文引用。