80页合同才几万字，100万窗口的AI却读到第20页忘了前19页：缺的根本不是窗口_IT互联网

八月的AI圈在集体刷同一个数字：100万。7月16日，Kimi K3发布，2.8万亿参数、100万上下文。微博微博

8月3日Qwen3.8-Max正式版跟上，2.4T参数、单次激活95B，同样带100万上下文。微博 8月12日，DeepSeek官网悄悄更新API文档，V4-Pro就这么上线了。微博

8月14日Gemini 3.7 Flash上线，支持100万Token超长上下文，还能一口气读取文字、图片、视频、音频和PDF。微博 8月26日，智谱发布GLM-5.3-Flash，把这场军备竞赛凑齐了第五块牌。微博 K3官方技术报告的第一页摘要里，"100万token上下文窗口"就是卖点之一。知乎

但另一个平台上，风向完全相反。9月1日的小红书笔记写了很多人的真实体验：想让AI帮你梳理一份80页的合同，结果它读到第20页就忘了前面说了啥。小红书另一篇教"三步让AI读长资料"的笔记发布时间只隔一天，文末避坑提醒写的是：资料太长就分段喂，别一次塞太多。小红书

一边说整包丢进去，一边说拆开喂。我翻完8月下旬这四个平台的翻车帖和技术文章，结论是：大部分人把锅甩错了对象——你的AI忘事，从来不是因为窗口不够大。

先算一笔容量账，数字小得反常识

一份80页的合同，按每页500到800字算，也就4万到6万字。现在主流模型的中文token比在0.6到1之间，换算下来撑死六七万token。而100万token的窗口，按中文估算能吃进上百万字——一份80页合同占不满窗口的十分之一，就算回到128K窗口的老模型，它也放得下。

所以你遇到"读到第20页忘了前19页"的时候，窗口里其实空了九成。这不是塞不下的问题，是看见了没记住的问题。知乎8月31日那篇《上下文越大，AI越容易忘事》里有句话说得准：上下文窗口是工作记忆，不是长期记忆，容量变大不等于记得更牢。知乎

原因不玄乎：Transformer处理n个token要做n²次两两注意力计算，每多一个token，都从那块有限的注意力预算里分走一杯羹，窗口越长，单条信息分到的注意力越薄。Anthropic在2025年9月发布的《Effective Context Engineering for AI Agents》给这个现象起了名字：context rot（上下文腐坏）——随着token数量增长，模型对信息的召回精度反而下降。知乎而且这是注意力机制的固有属性，Claude、GPT、DeepSeek、GLM、Kimi，一个都绕不开。

研究早就画出了那个坑的形状：U形

斯坦福Liu等人2023年的论文《Lost in the Middle》（后发表于TACL 2024）做过一个直观的测试：给模型一长串文档，其中只有一篇含答案，把答案文档从开头滑到结尾，画出来的"位置—准确率"曲线是标准的U形——开头和结尾最准，中间掉得最狠。更扎心的是：当答案埋在 20 篇文档正中时，GPT-3.5 的得分甚至低于它"不看任何文档"的闭卷基线（56.1%）。知乎喂了长文，还不如不看。

这两年新模型只是把坑填浅了些，没填平，从4K到1M都是这个形状。知乎注意厂商爱用的"百万字大海捞针测试"——它只测单针检索：捞得起一根针，不等于记得住一把针。

对着你的合同看，这个形状有多要命：头几页是主体和定义（U的左端，稳），末页是签章和附件说明（U的右端，也稳），而违约责任、自动续约、免责条款、排他约定，全挤在中间。社区里流传最广的那句"AI没提的条款是不是就没有"，问的其实就是这个中间洞。8月21日知乎还有文章介绍ACL 2026专门治位置偏差的三种方案，它对现象的描述很直白：把关键信息放在长文本的正中间，模型反而最容易忽略它。知乎

社区里的"忘事"分三种，只有一种要怪模型

把这轮翻车帖按毛病分个类，别一锅端：

中间条款漏看：单条义务、散落各章的限定条件对不上。这是结构性问题，中间洞，换谁家新模型都还有。
总结丢出处：纪要整整齐齐，追任务时发现负责人和截止时间没了。多半是用法问题——你根本没要求它带页码。
多轮越问越乱：追问十几轮后前后矛盾。这是长对话逼近上限触发了压缩、或者旧结论和新结论在窗口里打架，还是用法问题。

顺带和之前那篇"AI把PDF读错了"的讨论划个界：那是文档解析翻车（表格、扫描体没拆开），错在"没看清"；这篇是看清了但没记住，错在"注意力"。两种病，别开同一个药方——第一种的解法是换解析工具，换模型没用；第二种才是今天的主题。

决策表：什么时候整包丢，什么时候别丢

可以放心整包丢的：

50页以内、只要大意和框架的文档——整包丢就是比手动分段快，别被焦虑帖骗回去手搓分段粘贴；
关键词原话检索："这份文件里哪几处提到’竞业’？"找字面出现的词是强项；
单份文件的通读式摘要。

别整包丢、要换打法的：

合同审核、条款冲突检查、数字核对这类漏一条就有成本的活：不要指望它"通读后总结"，改成"先列目录、再逐条回查"；
多文件对比（甲方稿和乙方稿各一份）：分开喂，要求输出差异清单而不是各自摘要；
开会前救命用的长报告：摘要之外，必须加一轮反向质询。

三句可以直接抄进对话框的指令，前两句来自我翻到的社区做法，第三句是我把机制倒推出来的：

“列出这份合同的全部条款标题和对应页码，不许省略。”——先把骨架捞出来，标题结构在文档层级里重复出现，掉不进洞底。
“只根据文件本身整理’结论｜依据｜使用条件’三栏表，每条结论标注章节或页码；找不到就写’没找到’，不要把建议当事实。”
“列出你认为最可能被漏掉的中段条款，给我页码。”——主动逼它自查中间洞，比问"还有补充吗"有用得多。

第二句是从小红书一篇教Kimi读30页报告的帖子里抄来的，妙处就在"没找到"三个字：它给模型留了诚实的出口，堵住一半幻觉。小红书

接下来盯什么

一是厂商披露口径：发布会放出的只有跑分表——比如千问官方8月中旬公布的Qwen3.8-Max基准成绩表，Document intelligence一栏确实排得漂亮，但那测的是"看得懂文档"，不是"读完一百页还记得住第五十页"。到目前为止，没有一家公布"召回精度随上下文长度衰减"的曲线。下次再有新模型喊200万、500万，先看它放没放长文评测曲线，只有大海捞针成绩的，先按营销处理。