ai大模型上下文窗口是什么

你大概遇到过：把一份长文档丢给模型，它前面答得挺好，聊到后面就开始漏细节、重复问过的问题。这通常不是模型变笨，是上下文窗口被塞满了。这篇不重复 Token 和计费的基础概念，只解决两件事：怎么判断手头的活会不会超窗，超了以后按什么顺序处理。

把一份长文档丢给模型，前面几段答得挺准，聊到后面就开始漏细节、把你刚说过的话又当新问题问一遍。这多半不是模型突然变笨，而是它一次能「同时看见」的内容已经被塞满了。这个能同时看见的总量，就是上下文窗口。它决定的不是模型懂多少，而是这一次对话里模型手上能摆多少东西。

这篇不重复 Token 和计费的基础概念，只解决两件事：怎么判断手头的活会不会超窗，超了以后按什么顺序处理。判断标准给到位，动作也给到位，剩下的数字去站内对应页面核对当天口径。

一句话说清：它是模型一次能「同时看见」的内容总量

更贴切的类比是一张工作台面，不是记忆力，也不是知识库。你每问一次，模型都把台面上当前摆着的东西重新读一遍再回答；台面之外的内容，它天然看不见，也谈不上记住。所以窗口大小不改变它训练时懂过什么，只改变这一次它能参考多少。

工作台面

一次请求里模型能读到的全部输入，加上它准备写出的输出

台面之外

上一轮被你删掉、或超出上限被截掉的内容，模型完全看不到

每轮重读

多轮对话不是增量记忆，而是把当前台面整体再递一次给它看

• 台面上摆的包括系统提示、历史对话、你粘贴的原文、工具或检索返回的结果，还有模型自己的输出
• 窗口是「一次能看多少」，不是「能记多久」，跨会话不带记忆
• 同一个台面里，你多塞一份附件，就少留一份空间给对话和答案
• 模型的固有能力（懂什么语言、会不会写代码）和窗口大小是两回事，别混着比

到底哪些东西在吃你的窗口

窗口被吃掉，通常不是因为你话多，而是因为某些内容的增长你没注意。把占位的东西列成清单，按「谁会随使用不断涨」排序，砍的时候从最上面砍，效率最高。

清单里最容易被低估的是工具返回。一次搜索、一次数据库查询、一次接口调用，返回的内容可能比你贴的文档还长。真正省窗口的动作，往往发生在调用工具之前，比如限定返回条数、只取需要的字段，而不是事后再删。

三步定位是谁在占位

1. 把变量写下来把一次请求里所有输入拆成固定项和增长项，固定项先放一边，只看会涨的
2. 按增长排序谁随着使用不断变大就排前面，历史对话和工具返回一般排最前
3. 先砍第一名从排最前的开始处理，别一次全改，改完再观察症状是否消失

窗口有多大别背数字，去站内查当天口径

窗口规格这东西，同一家厂商不同档位不一样，命名和口径也常调整，背下来大概率已经过期。正确做法是动手前花一分钟去站内查当天的数字，再和你估算的量级对一遍。

• 查各家模型当前的规格和说明，到 /models 核对
• 看官方 API 的接口能力与限制说明，到 /official-api 对照
• 搞不清单位换算和占用关系，去 /ai-dict/category/basics 补一下基础口径
• 想比较不同渠道在实际调用里的表现，用 /tools 里的工具实测

超窗的六种典型症状，对上两个就该怀疑它

超窗不一定报错，更多时候是「质量悄悄下滑」。下面这些症状单独出现未必是窗口问题，但成对出现时，优先怀疑台面不够用，而不是模型不行。判断时可以先重开一轮对话做对照。

• 前文提过的名字、数字被答错，或者答成了别的东西
• 反复问你已经回答过的信息，像没看见一样
• 引用长文档时只答开头和结尾，中间整段略过
• 回答突然变短、变敷衍，或者明显没写完就停
• 多轮对话越聊越糊，重开一轮立刻恢复正常
• 出现内容过长的报错或提示，这已经是硬失败而不是体验问题

如果你发现症状集中在「答案不准、引用对不上」，而它并没有丢记忆，那多半不是窗口问题，而是检索和提示词没写对，这条线到 /guides/rag-basics-problem 看更合适。

什么情况下这套判断不适用

不是所有任务都值得为窗口操心。有些场景里窗口根本不是瓶颈，硬去做压缩和拆分会白花时间，甚至把简单问题搞复杂。

• 短任务、单轮问答，输入本来就小，窗口基本不会成为瓶颈，别过度优化
• 代码补全类工具走的是另一套截取逻辑，按行按块看附近代码，不是按整段对话算
• 本地跑小模型处理长文本时，瓶颈常常是显存，先确认是显存不够还是窗口不够
• 问题出在答案不准而不是记不住时，那是检索和提示词的事，先调那两块

开工前的四步估算清单

你不需要精确算数，只需要估个量级。目标不是算准到个位，而是提前知道「这活大概会不会超」，好决定要不要一开始就按省着用的方式做。

1. 拆输入把输入分成固定部分（系统提示）和增长部分（对话、检索结果、附件），只关注增长部分
2. 估量级按轮次乘一遍增长部分，粗估就行，比如大概几百还是几千的量级
3. 给输出留位置输出也占窗口，要写长文就留宽一点，别把输入塞到刚好卡满
4. 对档位把估算结果和站内查到的当前档位对一遍，够就正常做，不够就直接进治理顺序

估算时最常犯的错是漏掉输出。很多人只算自己贴了多少，忘了模型要写的内容同样摆在台面上。让模型一次输出长报告，等于它在写的过程中不断挤掉自己的余量。

真的塞满了，按这个顺序处理

发现超窗别第一反应就是换模型。换模型意味着成本、延迟、稳定性都要重新摸一遍，代价通常比治理输入高。按下面的顺序走，能解决大部分情况，实在不行再考虑换。

1. 先砍输入去掉重复粘贴的原文和无关历史，这是最便宜也最快见效的一步
2. 再做摘要压缩把前面的对话换成要点保留，而不是原样堆着，牺牲一点细节换空间
3. 改成按需检索长文档不要整篇塞，用检索只取相关片段，思路见 /guides/rag-basics-problem
4. 拆任务分工一次只让模型干一件事，分步产出再拼起来，每步输入都更小
5. 最后才换模型前面都试过仍不够，再考虑更大窗口的方案，并重新评估成本与稳定性

这个顺序的核心是：越靠前的动作越可控、越便宜。换模型排在最后，不是因为它不好，而是因为它会同时动到成本、速度和稳定性三个变量，不适合当第一手。

三个能长期省窗口的习惯

治理是一次性的，习惯是长期省事的。下面三条不需要工具配合，改起来成本很低，但能明显减少你遇到超窗的次数。

• 新话题就开新会话，别把不相关的任务堆在同一条对话里
• 贴材料前先问一句：这段是必须的，还是我以为它可能有用
• 系统提示写紧，规则用短句和清单，别写大段背景故事

上下文窗口管的是这一次能看见多少，不是模型记住了多少。