「聊着聊着，AI 就把我开头说的要求忘了」——这是很多人用 AI 时最常见的困惑之一。原因不在模型「记性差」，而在一个叫上下文长度的硬指标。这篇讲清楚它是什么、怎么估算够不够用，以及长对话怎么用更省钱。
上下文长度是什么？模型的「工作台」
你每发一条消息，模型并不是只看你这一句，而是把你和它的全部对话历史重新读一遍，再接着往下说。能同时读多长的历史，就是上下文长度，单位是 token。它像一张工作台：桌面就这么大，所有材料必须同时摊在桌上；放不下的部分，模型就「看不到」了。
32K、128K 到底能装多少字？
token 可以粗略理解为字块：中文 1 个字 ≈ 1.5~2 个 token，英文 1 个单词 ≈ 1~1.5 个 token（不同模型略有差异）。按这个经验值换算：
- 32K ≈ 中文两万字上下——一份长报告加几轮对话就差不多了
- 128K ≈ 中文八万字上下——一本书的部分章节、一个项目的大部分代码
- 200K 及以上——真正的「大部头」场景，比如整本长篇小说的一次性分析
举个具体的例子：一份两万字的报告约 3~4 万 token，塞进 32K 窗口已经很紧张；换成 128K 就非常从容。
窗口满了会发生什么？
超出窗口的内容不会报错，但会被「挤下桌面」：多数客户端会自动截断或压缩最早的对话。这就是为什么长会话聊到后面，AI 会「忘记」你开头提的要求——不是它记性差，是开头的内容已经不在工作台上了。
记住一个关键区分：上下文长度 ≠ 永久记忆。新开一个会话，模型对之前聊过的一切一无所知。
三个实用建议
- 长文档先分块：超长文档别整篇塞进去，先按章节让模型做摘要，再基于摘要提问，效果和成本都更好
- 长对话及时开新会话：一个话题聊完就新开窗口，别让无关历史一直占着工作台
- 大任务选长上下文模型：比如 kimi-k3 这类以长文本见长的模型，整章整节地喂也不怕
还有一个容易被忽略的成本细节：每一轮请求都会把全部历史重新计费。聊到第 30 轮时，你实际在为前面 29 轮的内容反复付费——所以「及时开新会话」不光省窗口，还省钱。
常见问题
为什么我发的文档 AI 说「读不完」？
要么超出了窗口，要么客户端做了主动截断。可以先只发关键章节，或者换长上下文模型再试一次。
怎么快速估算一段文字的 token 数？
中文按「字数 × 1.5~2」估算，英文按「词数 × 1.3」估算，日常判断足够用了；要精确值可以看控制台日志里每次请求的实际 token 统计。
上下文越长，模型越强吗？
不是。窗口大只代表「装得多」，不代表「想得好」；塞得太满反而可能稀释重点。把关键信息放在输入的结尾位置，效果通常比一股脑全塞更好。