上下文窗口是什么？为什么 AI 会「忘记」前面说的话
上下文窗口（context window）是大模型一次能「同时看到」的文本上限，单位是 token；超过这个上限的内容，模型就读不到、也记不住，于是表现得像「忘记」了前面说过的话。 它不是 AI 的「记忆力」，而更像一张固定大小的桌面：桌面铺满后，新纸进来，旧纸就被挤出去。
理解上下文窗口，能帮你想明白很多日常困惑：为什么聊久了 AI 会前后矛盾、为什么贴一份长文档它只抓住开头、为什么 AI 编程助手在大项目里容易「失忆」。这篇把原理、影响和应对一次讲清。
为什么需要关心上下文窗口
大模型本身是「无状态」的——它不会真的把你们的对话存进脑子里。每次回复，程序都会把当前这一轮要参考的所有文本（系统提示、历史对话、你贴的文档、你的新问题）拼成一大段，整个塞给模型。
这一整段能塞多少，就由上下文窗口决定。它直接影响三件事：
- AI 能不能记住前文：超窗的历史会被砍掉，于是「失忆」。
- AI 能不能读完你的资料：贴的文档太长会被截断，它只看到前一部分。
- 你花多少钱、等多久：窗口里塞的 token 越多，单次调用越贵、越慢。
所以它既是能力上限，也是成本和体验的开关。
token 是什么，窗口上限怎么算
token 是模型处理文本的最小单位，不等于「字」也不等于「词」。一个 token 可能是一个英文单词、半个单词，或一个汉字、一个标点。粗略记：一个汉字通常约等于 1～2 个 token，具体由各家分词器决定，精确换算以官方文档为准。
上下文窗口的上限就用 token 计数，比如某模型标称「128K 上下文」，意思是输入加输出加起来最多约 12.8 万个 token。这里有个关键点常被忽略：
窗口是输入和输出共享的。你塞进去的提示越长，留给模型「写回答」的空间就越小。
各家模型的窗口上限差别很大，从几千 token 到上百万 token 不等，且更新很快——选型时以官方文档的最新参数为准，别背具体数字。
自己动手估算一次要用多少 token
不用等模型报错才知道超没超窗，动手前先粗算一下：
- 数你要贴的中文字数，乘以 1.5～2，得到大致 token 数（比如一份 3000 字的产品文档，粗估 4500～6000 token）。
- 数英文单词数，乘以 1.3 左右，token 数会比单词数略多。
- 代码和 JSON 另算：符号密度高，同样字符数换算出的 token 往往比自然语言更多，长代码文件要打个折扣预留余量。
- 想要精确值，直接用模型厂商提供的 tokenizer 工具（比如在线分词计数页面，或调用 API 前先跑一次 token 计数接口）算出真实数字，别只靠估算拍板。
举个实际会踩坑的例子：你把一份 8 万字的需求文档整篇贴进对话，估算下来就是 12～16 万 token，如果模型标称窗口是 12.8 万，这份文档大概率已经把输出空间挤没了，AI 要么被迫截断内容作答，要么直接告诉你输入超限。这时候该做的不是硬塞，而是先拆分文档或只贴相关章节。
超出窗口后会发生什么
一旦内容超过上限，系统不会报错卡死，而是悄悄做三种处理之一，结果都表现为「AI 忘事」：
| 处理方式 | 怎么做 | 你看到的现象 |
|---|---|---|
| 截断 | 直接砍掉超出部分的文本 | 长文档只读了前半段，后面像没贴过 |
| 滑动遗忘 | 丢弃最早的几轮对话 | 聊久了忘掉开头的设定和要求 |
| 压缩/摘要 | 把旧内容总结成短摘要再带上 | 记得「大意」但丢了细节原话 |
注意：模型对窗口中间段落的关注往往弱于开头和结尾（业内常称「中间迷失」）。所以哪怕没超窗，把关键信息埋在超长上下文的正中间，也可能被「读漏」。这和大模型幻觉是两类问题——幻觉是「编造」，超窗是「没看到」，但都会让回答不可靠。
长上下文模型解决了什么，没解决什么
近年很多模型把窗口做到几十万甚至上百万 token，这类「长上下文模型」确实缓解了截断问题：能一口气读完整本手册、整个代码库的大部分文件。
但它不是万能药：
- 越长越贵越慢：把 100 万 token 全塞满，单次成本和延迟都很可观。
- 中间迷失依旧存在：窗口大不代表每个角落都被同等重视。
- 窗口 ≠ 长期记忆：关掉对话，这些内容不会被「记住」。要跨会话记忆，得靠外部存储，参见 AI Agent 的记忆机制。
真正能让 AI「记住海量知识」的，通常是 RAG 检索增强：把资料存在外部库里，每次只检索出最相关的几段放进窗口，而不是把全部硬塞进去。
大窗口和 RAG，到底该选哪个
这是个实际取舍问题，不是「越新越好」：
- 资料量不大、且这次对话就要通读全文（比如审一份 20 页的合同、改一篇几千字的文章）：直接贴进大窗口最省事，不用额外搭检索系统。
- 资料库有几百上千份文档、且每次只需要其中一小块（比如客服知识库、公司内部规章、产品全套手册）：老老实实做 RAG，检索命中率比「全塞进超大窗口」更可控，成本也低得多——你总不会想每次提问都把整个知识库过一遍。
- 两者可以叠加用：先用 RAG 把范围收窄到十几段最相关的内容，再把这些内容和用户问题一起放进窗口，兼顾覆盖面和精度。团队里常见的误区是迷信「窗口越大越省事，干脆不做检索了」，结果一份混杂了大量无关内容的超长提示喂进去，模型反而更容易读漏关键段落、答非所问。
它对编程和长对话的实际影响
写代码时：你用 Cursor 或 Claude Code 改一个大项目，模型不可能把所有文件都装进窗口。它靠工具按需读取相关文件——所以你给的指令越聚焦、相关文件越明确，效果越好；让它「读完整个仓库再改」往往超窗且低效。
长对话时：聊到几十轮后 AI 开始前后矛盾，多半是早期内容被滑出窗口了。应对办法很直接：
- 及时开新对话：任务换主题时，别在一个超长会话里硬撑。
- 关键设定置顶或重申：把不可丢的要求放在每轮提示里，而不是指望它记着 20 轮前的话。
- 长文档分段喂：与其一次贴 10 万字，不如分块处理或先做摘要。
- 善用「记忆/项目」功能：很多工具支持把固定背景沉淀成长期上下文，避免每次重贴。
编程场景里几个容易踩的坑
带团队用 AI 编程助手时，这几件事我见得最多：
- 一股脑把整个仓库拖进对话：项目大到几十上百个文件，工具就算支持大窗口，也会因为无关文件太多而分散注意力，改动准确率反而下降。正确做法是先让它按需搜索、定位到具体文件，再针对性地读改。
- 改动指令和历史需求混在一堆闲聊里：聊了几十轮之后，最初的编码规范、命名约定早被挤出窗口，AI 按自己的习惯写代码。解决办法是把项目规范写成一份固定文件（很多工具支持项目级配置文件），每次对话自动带上，而不是指望它记住第 5 轮说过的话。
- 贴报错日志只贴一半：堆栈很长时容易只贴前半段，AI 拿不到关键的最后几行反而定位错方向。贴日志时优先保留报错发生处和调用链末尾，中间可省略。
- 反复重复贴同一份大文件：每一轮都把同一个几千行的文件整篇重新贴一次，既浪费窗口空间也拖慢响应。更好的方式是让工具自己按需读取文件，你只在文件变化时提示它重新读。
常见问题
上下文窗口和 AI 的记忆是一回事吗？ 不是。窗口是「这一轮能看到多少」，是临时的工作台；关掉对话就清空。真正的跨会话记忆要靠外部数据库或记忆模块，窗口只是把检索出的内容临时摆上桌。
1 个 token 等于几个字？ 没有固定换算。英文里 1 个 token 约等于 0.75 个单词，中文里一个汉字大致 1～2 个 token，标点和空格也算。精确数值由各模型分词器决定，以官方文档为准。
窗口越大模型就越聪明吗？ 不一定。大窗口解决「装得下」，不解决「理解对」。窗口太大还可能让关键信息淹没在中间被读漏，而且更贵更慢。够用、聚焦，往往比一味求大更实用。
为什么贴了长文档，AI 还是只回答开头的内容？ 很可能文档超出了窗口被截断，模型只读到了前一部分；也可能没超窗但信息在中间被「读漏」。把文档分段、或先提炼要点再提问，通常能改善。
怎么判断我的对话是不是快超窗了？ 没有精确提示线，但有信号：AI 开始忘记早期设定、回答和前文矛盾、或对你贴的长内容只抓住片段。出现这些就该开新对话或重申关键信息了。
👉 看看 AI 数字员工落地指南，或了解 数字员工搭建实战课。需要为企业落地方案，欢迎找我们聊 企业服务。