结论先给：上下文窗口是模型一次能同时「看到」的文字量上限（用 Token 计）。它决定了模型在回答时能记住多少前文。对话越聊越长，一旦超过窗口，最早的内容就会被挤出或需要压缩——这就是「它怎么把前面说的忘了」的原因。
用桌面打个比方
把模型的工作台想成一张有限的桌面：你能同时摊开的资料就那么多。新资料放上来，旧的可能被挤下去。窗口越大，能同时摊开的越多；但再大也有上限。
和额度不是一回事
窗口是「一次看多少」，额度是「一共花多少」。两者独立，详见 额度 vs 限流。
| 上下文窗口 | 额度 | |
|---|---|---|
| 管什么 | 一次能看到多少 | 一共能用多少 |
| 超了会怎样 | 忘掉/压缩旧内容 | 余额见底 |
| 和长度关系 | 单次对话长度 | 累计消耗总量 |
太长会怎样
- 模型开始「失忆」，重复问已经说过的信息。
- 回答偏离前文设定，风格或要求不一致。
- 需要把旧内容压缩成摘要，细节可能丢失。
怎么应对
- 长任务分段做，每段开头重申关键设定。
- 把重要信息整理成一份「背景摘要」，需要时贴回去。
- 别把无关内容塞进同一段对话，减少占用窗口。
常见问题
为什么它聊着聊着忘了前面？
因为对话超过了上下文窗口，最早的內容被挤出或压缩了。
窗口大就更省钱吗？
不一定。窗口大不代表消耗少，额度是按累计使用算的。
怎么让长任务不丢设定？
分段做，并在每段开头重申关键设定或贴背景摘要。
窗口和额度是一回事吗？
不是。窗口管「一次看多少」，额度管「一共用多少」。
相关页
怎么判断是不是窗口问题
- 聊到中途开始「忘事」：早先的细节被挤出或被压缩成摘要。
- 让它复述前面内容会出错：说明早期上下文已不在当前窗口里。
- 新开一个会话就恢复正常：基本可确认是窗口问题，而不是服务故障。
窗口和额度是两回事
窗口决定「一次能记住多少」，额度决定「总共能用多少」。窗口不够，表现是记不住；额度不够，表现是用不了。遇到问题先分清属于哪一类，处理方式完全不同——加额度解决不了记不住，清空会话也解决不了没额度。
三个实用做法
- 长任务拆成几个会话，每个会话开头带一份简短摘要。
- 把关键结论写在最前面，别指望模型一路都记得。
- 需要连续上下文时，主动把要点复述一遍。
窗口大小会影响什么
| 窗口小 | 窗口大 |
|---|---|
| 聊久了会「忘掉」前面的内容 | 能一次读完长文档 |
| 长对话消耗更省 | 单次请求消耗更多 |
| 适合短问答 | 适合整理长材料 |
三个实用习惯
- 聊到关键结论时，让它复述一遍要点，确认它没忘。
- 长任务拆成几段，每段重新给一次背景。
- 处理长文档时，先让它输出结构，再逐段处理。
一次长任务该怎么拆
假设你要让它读完一份 30 页的文档并给结论。直接整篇丢进去，很可能超出窗口、或者它「读了后面忘了前面」。更稳的做法是三步：
- 先让它列出文档的目录结构（只要结构，不要内容）。
- 按章节分批处理，每批开头重新贴一次「我们正在做什么」。
- 最后把各批结论拼起来，让它写一个总览。
拆开处理通常比一次塞进去更省额度、也更准——因为窗口里的无关内容越少，模型越不容易跑偏。
把上下文窗口当成额度——一个管「记住多少」，一个管「能用多少」。
以为超了会报错——通常是被截断或摘要。
把不同模型的窗口混为一谈。
自检清单
最后核对：2026-10-08。内容来自公开分享与我们的核对；具体窗口大小随模型与服务变化。
出处：本页是公开信息与社区说法的整理（定义 / 对照），不是我们亲测的步骤；有分歧处两种都保留。涉及金额、时限的数字按「社区口径」处理，最终以 App 内为准。核对时间 2026-09～10。
这些会变：入口位置、额度、政策。以页面顶部的「最后核对」日期为准，日期旧了就当参考。
下一步：额度 vs 限流：怎么分辨。如果想回头看整条路径，回教程目录。
邀请码来自网络公开分享：HUZM98，不填也能用，填了双方各得额度。以注册后 48 小时内、App 内显示为准。