04 · 上下文窗口：它为什么会忘

上下文（Context）是模型这一次能同时"看见"的全部内容；上下文窗口（Context Window）是这个容器的上限，按 Token 计。窗口之外的东西，对它来说不存在。

一张桌面

这位新人的脑子像一张办公桌：能同时摊开的资料就那么多。你不停往上放，最早那几张就被挤下去了——不是他不想记，是桌上没地方了。

每次你发一条消息，桌上其实摆着这么几摞东西：

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

上下文窗口

System Prompt入职时约法三章的那段设一次，之后每一轮都会被重新发一遍

你贴进来的资料文档、代码、表格最占地方的一摞，也最容易把别的挤掉

检索来的内容RAG 抓回来的片段整本手册塞不进来，只能挑相关的几段

工具返回的结果联网搜索、查数据库Agent 每转一圈就往上堆一层

对话历史 + 你这一句前面所有轮的一问一答聊得越久越占地方，最早的会被「挤出去」

溢出区：最早的内容被挤出去，它就「忘」了

还有第七样：它这次的输出，同样占地方

窗口满了会怎样

聊久了就跑偏最早那几轮被挤出去，你开头定的规矩等于没说过

资料塞不下放不进去就只能先检索，这就是 RAG 要解决的事

例子不能无限加示例越多越占地方，留给对话的空间就越少

窗口越大越好吗

窗口越大 → 越贵、越慢

超长上下文里，中间的内容最容易被读漏

关键不是窗口多大，是里面放了什么

七样东西挤一个空间。你贴的资料越长，留给对话历史的地方越小。

现在的窗口有多大

窗口大小这几年一直在涨，具体数字随时会变，写死在书里没意义。你只要知道量级：

量级	大概能装	典型用途
几千到几万 Token	几页到几十页中文	早期模型、部分小模型、本地跑的模型
十几万到几十万 Token	一本书	当前主流模型的常规水平
上百万 Token	一个中型代码库	少数主打长上下文的模型

大窗口不等于能放心塞满

两件事要分开：装得下和读得准。业界反复观察到一个现象——把关键信息放在超长上下文的中间，模型读漏的概率明显比放在开头或结尾高（这个现象有篇经典论文叫 Lost in the Middle）。俗称"大海捞针"测得好，不代表实际用起来不漏。

所以窗口是 100 万，不意味着你该一次塞 90 万进去。

三个由此产生的现象

一、聊久了它就"变笨"

一个对话拉长到几十轮，你会明显感觉它开始跑偏、忘掉你开头定的规矩、重复问已经说过的信息。原因就是最早那几轮被挤出去了。

有的产品会在挤出去之前自动做一次摘要塞回来，这能缓解，但摘要必然丢细节——你开头强调的那个"必须用表格"，很可能就丢在摘要里了。

二、它不记得上一个对话

新开一个会话，桌面是空的。上周你跟它掰扯了半天的项目背景，这次一个字都不在。

这不是设计缺陷，是它的工作方式。有些产品做了"记忆"功能，本质是把你之前说过的东西存起来，下次自动帮你重新贴一遍——还是塞进这张桌子，只是不用你手动贴了。

三、它"记得"其实是每次重读

多轮对话的真相：你发第 10 条消息的时候，系统是把前面 9 轮的全部内容 + 你这条打包重新发给模型的。它不是接着上次想，是每次从头读一遍。

这解释了两件事：为什么越聊越慢、越聊越贵；以及为什么中途改主意特别难——你前面说的话还都在桌上摆着，一直在影响它。

所以你该怎么用

一事一会话。 换任务就开新对话。让上一个任务的残留继续躺在桌上，只会污染这一个。

重要的规矩，重复给。 长对话里每隔一阵把关键约束重申一次："再提醒一次：只用我给的材料，不要编。"这不啰嗦，这是在把它重新放回桌面。

把最重要的放在开头和结尾。 中间最容易被读漏。长资料贴进去之后，在末尾再写一遍你的要求。

长文档分段处理。 别指望一次丢 200 页让它通读。拆成几段分别处理，再让它汇总——结果稳定得多。

发现它跑偏了，不要在原对话里硬掰。 重开一个，把前面得到的好结果作为素材贴进去。掰扯的过程本身也在占桌面。

常见的两个误解

"我把窗口用满了就是充分利用" —— 恰恰相反。桌面越乱，它抓重点越难。给得准比给得多重要。

"它说它记得我上次说的" —— 它说的话不是证据。它可能只是在预测"这里应该回答记得"。真要确认，让它复述具体内容。

下一步

05 · 幻觉：它为什么会编 —— 会忘只是不方便，会编才是真的会出事。