从 Token 到上下文窗口：
模型到底“看见”了什么？

01Token 不是字，也不是词

模型在读到文本之前，会先把它切成一个个 token。英文常按子词切分，一个长单词可能被拆成几段；中文的一个字也可能对应一个或多个 token。不同的模型使用不同的分词表，所以同一段话在不同模型里的 token 数并不一样。

这带来两个很直接的后果：费用按 token 计，上下文上限也按 token 算。估算长度时只数字数，很容易在边界上翻车。

我的做法是先粗估再核对：中文大致按“字数 × 0.6 到 1”的量级估算，真正要卡上限时，用工具实际数一遍。留出余量，比精确到个位更重要。

02位置会改变模型的注意力

同一段信息放在开头、中间或结尾，模型对它的关注程度并不相同。经验上，开头和结尾更容易被抓住，长材料中间的部分容易被忽略，这常被称作“lost in the middle”。

所以重要的约束不要埋在长文档中间。我会把任务目标放在最前面，把关键限制在结尾再强调一次，中间才是参考资料。引用资料时保留小标题和文档名，模型也更容易判断哪一段才是依据。

03上下文窗口是工作台，不是记忆

每次请求默认是无状态的。对话之所以能继续，是因为客户端把历史消息重新发了一遍，而不是模型真的“记住”了什么。窗口再大，也只是一个一次性的工作台。

把窗口塞满通常不划算：既挤掉了真正重要的信息，又增加成本和延迟。长任务需要主动管理上下文——先总结前文，只保留结论和待办；需要细节时，再回去检索原文。

上下文窗口决定模型一次能“看见”多少，但不决定它能“理解”多少。 A NOTE TO MYSELF

04我现在会这样做

• 先列预算：系统提示、历史对话、参考资料、输出各占多少 token。
• 资料只放最相关的几段，并逐段标注来源，方便核对。
• 关键指令放在开头和结尾，材料放在中间。
• 超出窗口就摘要或检索，不把内容硬塞进去。