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

厂商把上下文长度当 RAM 来卖：越大越好，把所有东西都塞进去就行。但注意力并不均匀。研究一次又一次发现同样的 U 形——模型会稳定地用到窗口的开头和结尾，却悄悄忽略中间部分，一旦重要的东西被埋在那里，准确率会掉 30%+，有时才 10k token 就开始了。上下文不是一个你往里装东西的桶。它是一种稀缺的、跟位置有关的资源，需要你去设计。「全都放进 prompt 里」就是新的过早优化。

- **Author:** Fedor Chishchin
- **Published:** 2026-07-01
- **Tags:** architecture, methodology
- **Source:** https://fedorthinks.com/zh/blog/your-context-window-is-lying-to-you

---

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

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

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

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

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

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

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

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

## 结论

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

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