什么是上下文窗口？这个限制解释了AI的大半怪事

用大白话讲清楚

上下文窗口，是模型一次能同时看在眼里的文本总量。关于你当前这段对话，它所知道的一切都必须装进去：你的指令、你们双方发过的每一条消息、你上传的每一个文件，以及它正要写的那段回答。

一个好用的心理图景：模型对你们的对话其实完全没有记忆。你每发一条消息，整段对话都会被重新完整地递给它，它从头读一遍，然后写出下一条回复。上下文窗口，就是这份记录必须摆得下的那张桌子的大小。桌子满了，就得挪走点东西。

所以AI才会前二十条消息表现得很敏锐，然后开始自相矛盾、忘掉你一开始设的某个限制，或者要一个你早就给过它的文件。它不是糊涂了。是对话早期的部分从桌子上滑下去了。

有一个区别必须马上分清，因为它造成了大量误解：上下文窗口不等于记忆。 ChatGPT和Claude这类产品有一个单独的记忆功能，把关于你的信息在多段对话之间存下来，并悄悄塞进新的对话里。那是搭在模型之上的产品功能。上下文窗口则是模型本身的硬性属性，任何记忆功能都不会把它变大。

token，以及怎么估算它

上下文窗口是按token而不是按词来计量的，因为模型并不是按词阅读的。它读的是一块块的片段：常见单词通常算一个token，更长或更少见的词会被拆成几个，标点和空格也要算。

值得记住的粗略换算：

• 1个token大约相当于4个英文字符，也就是约四分之三个单词。
• 1000个token大约是750个英文单词，差不多一页半的普通文字。
• 中文更费token。 一个汉字往往就要占掉一到两个token，所以同样篇幅的中文材料，通常比英文消耗更多额度。
• 代码更密集。 因为有符号、缩进和不常见的标识符，通常接近每三个字符一个token。

有了这些，你就能把宣传材料里的数字变成具体的画面：

上下文窗口	大致相当于
8000 token	一篇长文章
32000 token	一篇短论文加笔记
128000 token	一本三百页的书
200000 token	一本厚技术手册，或一个中等规模代码库
1000000 token	好几本书，或一年的会议记录

这张表藏起来的重点是：这个上限算的是整段对话，不是每条消息。128000 token的窗口，并不意味着你可以反复发送128000个token。它的意思是，所有内容累计起来，包括模型自己写的回复，都必须保持在这个数字以下。

到底是什么把你的窗口填满的

人们通常会惊讶于窗口满得这么快，因为塞进去的东西大部分是看不见的。在一次普通的聊天里，模型每一轮都要把下面这些全部读一遍：

1. 系统提示词。 产品在你打字之前就发过去的指令：该怎么表现、有哪些工具可用、今天的日期、安全规则。往往有好几千个token，而你从来看不到它。
2. 你的自定义指令或记忆。 产品存下来的关于你的一切，会被自动注入。
3. 之前的每一条消息，你的和模型的，全文照收。模型那些长回答同样计入，而且通常是占比最大的部分。
4. 每一个上传的文件，或者从中提取出的部分。一份四十页的PDF大约是两万到三万个token。
5. 工具和搜索结果。 一次抓了五个网页的搜索，可能比你到目前为止的整段对话还长。
6. 正在生成的那段回复。 输出和输入共用同一份额度。

所以一段感觉还很短的对话，可能已经接近上限了。你只发了八条简短消息，但模型写了八段长回答，你附了两份文档，它还跑了三次搜索。你能看见的部分，也许只占总量的一成。

这也解释了为什么“重开一段对话”常常就能治好一段变糊涂的聊天。你不是在给模型换个心情，你是在清空桌面。

标称大小和可用大小

这是最重要、却最少被讨论的一部分。模型的质量并不会一路平稳到上限，然后断崖式下跌。它是逐渐下滑的，而且早在到达上限之前就开始了。

关于这一点，被研究得最清楚的版本常被称为“中间迷失”效应。把某个具体事实放在长文档的开头，模型找得到。放在结尾，模型也找得到。把它埋在两百页的中间，检索准确率就明显下降了。注意力并不会均匀地分布在一段长输入上，两端总是分到得更多。

如果任务还需要把散落在长输入各处的好几个事实组合起来，那就更难了。大海捞一根针，是已经被解决的问题。捞出四根针再推理它们之间的关系，还没有，而这恰恰是人们用大上下文窗口去做的事。

所以，把标称数字当作最大容量，而不是舒适的工作区间。一条来自实际使用的经验法则是：大约在标称窗口的一半以内，模型的表现是可靠的；超过之后的内容，应该去核实而不是直接相信。 如果模型告诉你一份三百页的合同里没有终止条款，去查一下，尤其是当那条款可能就在中间的时候。

对做对比的启示是：一个拥有一百万token窗口的模型，并不会自动比二十万的那个更擅长处理长文档。它只是更擅长把长文档收下来。它能不能在全篇范围内做好推理，是另一个问题，而唯一的确认办法，是拿一份你已经知道答案的文档去实测。

额度用完时会发生什么

不同产品处理溢出的方式不一样，知道你用的是哪一种，能解释很多古怪的表现。

处理方式	你看到的	常出现在哪
直接报错	请求被拒绝，提示长度超限	大多数直接调用API的场景
静默截断	最早的消息被悄悄丢掉	很多聊天界面
滚动摘要	旧消息被压缩成一段摘要	聊天产品里越来越常见
检索	每一轮只取回文档中相关的部分	文档和知识库类工具

真正制造麻烦的是静默截断，因为没有任何提示。症状是：模型突然无视你一开始定下的规则、退回到你一小时前已经纠正过的语气，或者问一个你已经回答过的问题。模型本身没出毛病。那些指令只是不在桌子上了。

滚动摘要要好一些，但会丢信息。摘要留住大意、丢掉细节，于是“绝对不要用‘赋能’这个词”这条限制，就变成了“用户对文风有偏好”，而这对你毫无帮助。

真正管用的实操技巧

下面按投入产出比从高到低排列。

话题一变就重开一段对话。 这是价值最高的一个习惯。一段长对话要背负它之前的一切成本，包括那些早就不相关的岔路。长对话并不是更懂你，它只是更贵、也更被稀释。

把问题放在长材料之后，而不是之前。 如果你先贴文档再提问，问题就离答案生成的位置更近，这在长输入上能可测量地提升准确率。先贴，后问。

把重要的限制重新锚定一遍。 任何超过十五轮左右的对话，都请在真正需要它的那条消息里把关键规则再说一遍：“提醒一下，用简体中文，不要用要点列表，四百字以内。”这只花你一行，却能挺过截断。

发相关的那几页，别发整本书。 如果你要模型检查赔偿条款，就把赔偿条款和它前后的内容给它。精准胜过量大，还更快、更便宜、更准确。

有意识地做摘要然后重开。 一段工作对话变长时，要一份结构化的交接：当前状态、已做的决定、待解决的问题、限制条件。把它贴进一段新对话。你留住了实质、扔掉了噪音，而且会发现模型立刻变敏锐了。

装不下的内容，就用检索。 如果你的材料真的比任何窗口都大，解法不是更大的窗口，而是针对每个问题取回相关片段。文档类工具底层做的正是这件事。

盯住质量下滑，而不只是报错。 如果回答变得含糊、开始打太极，或者不再遵守格式要求，那你多半已经深入窗口里了。先重开一段，再去怀疑模型是不是变差了。

你到底需要多大的窗口？

按活儿来配窗口，别一味去买那个最大的数字。

你的工作	你需要什么	原因
邮件、起草、快问快答	任何现代模型	你根本挨不到上限
编辑长文档	十万以上	文档本身，加上你围绕它的对话
合同和政策审阅	二十万以上，并且要核实	文档加上围绕它的推理，注意上文的提醒
对整个代码库做推理	能拿到的最大的	代码token密度高，跨文件推理需要广度
分析好几个月的会议记录	最大的，或者改用检索	这类活往往用检索比硬塞更合适
基于API做产品	比你以为的更小，加上缓存	长提示词是成本和延迟的主要来源

对大多数人来说，诚实的答案是：上下文窗口并不是各家订阅之间的决定性因素。写作质量、生态和价格更重要。它成为决定性因素只有一种情况：你的工作经常需要塞进超过普通窗口容量的材料，而在那种情况下，差别不是一点点，而是能做和做不了的区别。

如果你想自己验证，务实的做法是把同一份长文档交给两三个模型跑一遍，再拿你已经知道答案的部分去对照检查。像Whizi这样的工作区让这件事很省事，因为GPT、Claude、Gemini、Grok和DeepSeek都在一份订阅后面，从Gemini的超大窗口切到Claude的细致综合只要点一下。可以看并排对比模型，或者读如何挑选AI模型了解更大的决策。