原文发布于 robatdasorvi.com

认真用语言模型做开发大约六个月后，我撞上了一堵没想到的墙。当时我想把一份 3000 行的代码库塞进提示词，让模型帮忙重构一个棘手的模块。结果呢？它一直在忘事。它会回答文件开头某个函数的问题，却好像完全没见过四百行之后那个类定义。它不是真的在幻觉，它只是在用自己“拿得住”的那部分信息工作。

打开网易新闻 查看精彩图片

从那一刻起，上下文窗口对我而言不再是一个跑分数字，而是一个真实的设计约束。

后来我和很多开发者聊过，尤其是在公开构建和发布产品的时候，同样的模式反复出现：大家都知道上下文窗口这个概念，都在营销文案里见过这个数字，但很少有人真正把它当回事，直到某天东西坏了。

上下文窗口，就是模型一次能处理的全部文本量：你的系统提示词、对话历史、你注入的任何文档，以及正在生成的回答，全部加在一起。一旦超过限制，会发生两种情况：要么直接报硬错误，要么模型悄悄丢弃更早的内容。两种都不优雅，而“悄悄丢弃”更糟糕，因为你往往要等到输出开始变得不对劲，才会发现问题。

对开发者来说，上下文窗口就是模型在特定任务中的“工作记忆”边界。它不是模型的一般知识（那来自训练），也不是它的推理能力（那来自架构）。它只是你在当前这次会话里，模型能同时拿在手上用的记忆空间。如果你在构建一个用户会进行长对话的应用，或者要把文档灌进处理管线，又或者跑多步骤的智能体任务，那么上下文窗口就是你不断撞到头的那块天花板。

理解这个区别，比大多数人以为的更重要。训练数据决定模型知道什么；上下文窗口决定它能就当下的任务推理到什么程度。前者的价值已经被讲得很充分了，后者却常常被忽略，直到生产环境出问题才开始补救。

所以，当你下一次看到某个模型宣传“百万上下文”时，先别急着鼓掌。真正要问的是：在长上下文里，它还能不能记得住开头、抓得住重点、不把早期信息悄悄丢掉？数字是一回事，可用性才是另一回事。