想象一下：一位分析师把一份整整四百页的并购协议整本拖进对话框，然后只问了其中一个埋在第312页的责任条款。几秒钟后，模型不仅引出了那句话、标出了页码，还解释了它为什么和几个月后签的一份补充协议相冲突。没有摘要、没有切片、也没有断线。
这正是长上下文模型想做到的事：一个大到能装下一整本文档、一整套代码库或一小时视频的上下文窗口。这个 headline 数字涨得飞快，最常被提起的例子是谷歌的 Gemini 1.5 Pro——它把一百万 token 的窗口真正送进了生产环境。
上下文窗口可以理解成模型在一次对话里的"工作台内存"。你粘贴进去的所有东西——提示词、文档、前面的对话——都占着这块内存。一旦塞满，最早的内容就被挤出去。窗口越大，你在模型开始"失忆"之前能喂给它的原材料就越多。早期模型只能处理几千个 token，够写封短信，放不下合同。Gemini 1.0 顶到三万两千 token，而 2024 年初跳到一百万 token，几乎是一代之内三十倍的跨越。
谷歌披露，Gemini 1.5 Pro 在单次提示里能处理一小时视频、十一个小时音频、三万行以上的代码库，或超过七十万英文词。在他们的"大海捞针"测试里——把一个事实藏进长文本中——即便拉满到一百万 token，模型仍有 99% 的概率把它找出来。谷歌还提到在研究中测过最高一千万 token 的窗口，并向部分用户开放了两百万 token。
但实际用起来有三个诚实的提醒。第一，找得到不等于想得通：模型能在第 90 万个 token 处找到事实，却仍可能对它得出错误结论。第二，存在被反复验证的"中间遗忘"效应：在长上下文的头尾，模型召回最强，中间最弱——一百万的窗口并不等于对全部一百万 token 一视同仁。第三，成本和延迟随长度线性上涨，每个 token 都要被计算、计费、驻留内存，百万级提示词远比聚焦式贵且慢。
到 2020 年代中期，长上下文已经不是某家实验室的噱头，而是中美各家都把它当作入场标配——用户现在就指望能整本贴文档，而不是贴片段。真正的 frontier 已经从"能有多长"转向"模型是否真的用好了它读到的东西"。
对普通人来说，这种变化最直观的好处是"少做苦力"。过去要让模型啃下长材料，你得先自己分段、写摘要，还得担心它前后记混；现在可以整本丢进去，让它跨章节比对细节。但它不是终审法官——一份几百页的合同里，要害常常埋在中段，而模型恰恰对中间部分最不敏感。所以把长文档交给它之后，关键结论仍要回到原文复核，把它当成不知疲倦、却偶尔走神的助手就好。
另一个常被忽略的是隐私与成本。把一整本书、一整年聊天记录一次性塞进云端模型，意味着这些内容都会离开你的设备、进入服务商的存储与计费系统。窗口越长，单次请求越贵，也越容易把敏感信息一并送出。在享受"整本可读"的便利前，先想清楚：这份材料真的需要一次性全交给它吗？
普通人现在能做什么
1. 工具支持时，试着整本贴入一份文档（租约、论文、规格书），而不是自己先手写摘要——然后把答案回到原文核对一遍。
2. 在把大文件交给模型前，先查清它标注的上下文上限；"支持长上下文"在不同产品间差异巨大。
3. 别默认"越长越聪明"：短而明确的问题，一个紧凑提示通常胜过扔进去一百万 token。
诚实的局限
长上下文模型确实有真本事，也有真天花板。它减少了苦力活——不必再把一份 PDF 拆成二十份——却消灭不了幻觉，甚至可能自信地曲解一份就摆在眼前的原文。独立的超长上下文基准还不成熟，厂商数字应被当作最佳情况来读。而超长输入的存储与算力账单并不便宜，尤其当同样内容在每一轮都被重新处理时。