你那百万 token 的上下文窗口在骗你

百万 token 的上下文窗口来了，所有人都得出了那个显而易见的结论：检索完蛋了，pipeline 完蛋了，直接把整个代码库 / 所有文档 / 完整历史全贴进 prompt，让模型自己去理清。这是个诱人的故事。它也错了——错的方式会在每个 token 计数器都 显示你没问题的时候，悄悄拖垮你的产品。

窗口并不均匀，而中间是一片坟场

这个令人不安的发现，被反复复现：模型不会均匀地关注它的上下文。它重重地依赖开头和结尾，而中间被草草 略读——也就是「lost in the middle」的 U 形曲线。Chroma 关于「context rot」的研究 发现，当相关事实落在窗口中间时，准确率下降 30%+，仅仅 ~10k token 之后就出现可测量的退化——不管盒子上印的那个百万 数字是多少。NVIDIA 自己 2026 年的指南对此直言不讳：让你的 prompt 保持在声称窗口的三分之一以下。

更大的上下文窗口并不意味着模型读得更多。它意味着模型有更多空间去忽略你恰恰需要它看到的那一样东西。

想想这对「全都塞进去」意味着什么。你把那条关键指令、或那个唯一相关的函数、或真正要紧的那一条款——放进了一份 400k token 转储的浩瀚中间。token 计数器是绿的。模型径直滑了过去。而你永远不会看到报错；你会看到一个略微更差、却看起来完全 合理的答案。

上下文是你要设计的资源，不是你往里装东西的桶

这重新定义了整个「上下文管理」技能。窗口不是存储——它是注意力预算，而位置是预算的一部分。把它管理好，才是现在 真正的手艺，它看起来是这样：

• 给窗口做预算。 把「我用了多少窗口」当成一个真实的约束，让实时载荷远低于声称的上限——三分之一是个不错的默认值。 大窗口是余量，不是目标。
• 把要紧的东西放在两端。 把指令和最高价值的上下文放在开头和结尾，也就是模型真正会看的地方。永远不要把那句 承重的话埋在中间。
• 更少，但更对。 一段小而相关、位置得当的上下文，胜过一段巨大却让信号淹没其中的。检索没有随着长上下文死去——它变得 更 有价值了，因为把对的 1% 放到模型面前，胜过把 100% 倒进坟场。
• 留意还有谁在占地方。 工具定义、历史、样板——它们会在你的任务还没开始之前就把窗口吃掉。 每一个你本不需要的 token，都在把你真正的内容推向模型只会略读的那一段。

结论

上下文窗口变大了，营销说「全都放进去就好」，然后一大批产品在仪表盘保持绿色的同时悄悄变差了。尺寸是余量，不是理解力。 模型会读两端、略读中间，而当你的答案退化时，没有任何计数器会警告你。

别再填满窗口，开始去设计它：给它做预算，把要紧的东西放在两端，把对的上下文放进去——而不是把全部都放进去。