聊天越聊越长，模型突然忘了早先要求，或者漏掉资料中间的一条限制，并不一定意味着模型能力被调整了。先核实信息有没有真正进入当前请求，再检查是否被压缩、截断、淹没在重复材料里，最后再看模型利用长内容的效果。

“注意力衰减”是常见的通俗说法，不能据此断言某个模型内部一定发生了某一种变化。

一、先分清四种不同情况

不要用同一个“健忘”解释所有问题。应用只读取了文件前几页，和模型读到了全部但漏掉一个数字，是两种不同故障。

图：Anthropic 的上下文累积示意。容量足够，不等于所有位置的信息都能被同样准确地使用。

二、为什么上下文很大，也可能漏信息？

上下文容量说明可以放多少内容，并不表示每条信息都会被一样有效地使用。材料越长、噪声越多，找到与当前问题相关的内容就越困难。

早期研究《Lost in the Middle》观察到，部分模型在长材料中检索信息时，结果会受到关键信息位置影响，中间位置可能更方便被漏掉。

这项研究不能直接当成 Opus 5.5 的专门测试，也不能拿来宣布它有一个固定的“准确率下降百分比”。它帮助理解的是：能容纳长内容，与能稳定利用所有内容，需要分别验证。

三、旧消息被压缩，可能丢掉什么？

为了让长对话继续，应用可能把旧消息整理成摘要。如果摘要只保留“完成了方案讨论”，却没保留“不得修改接口”和“价格不含附加项”，后续回答就可能偏离要求。

所以，重要内容不要只埋在几百轮前的一句话里。将目标、限制、当前版本和未解决问题保存在一个容易读取的位置。

压缩不是毫无用处，它可以减少旧日志占用。但摘要应帮助恢复工作，也要保留原始材料索引，必要时能回去查细节。

四、先用一个小测试定位原因

第一步先选一条模型刚刚漏掉的明确要求。第二步再确认原句在哪个文件、哪个版本或哪轮消息里。第三步要检查它是否被实际读取或传入本次请求。

第四步是只提供相关章节和当前问题，再让模型回答。第五步要对比结果，并要求指出依据。

如果缩小后能答对，说明减少干扰可能有效；如果仍然不对，继续检查问题歧义、数据质量和模型能力。不要马上把结果归结为某个隐藏参数变化。

五、把资料分成三层，会更好管理

第一层是任务说明：本次目标、必须遵守的限制、完成要求。保持简洁，在重要阶段重新确认。

第二层是证据索引：文件名、日期、章节、主题和当前位置。它帮助模型找到需要的材料，而不用每次重复阅读所有内容。

第三层是原始资料：完整文档、代码和数据。保留原始版本，需要时按范围读取。摘要不能完全代替原文，尤其是数字、条款和例外情况。

可以使用下面的任务说明格式：

当前目标：
当前采用的资料版本：
必须保留的要求：
已经确认的事实：
仍有争议的信息：
需要查阅的原文位置：
下一步：

六、问问题时，先找证据再求结论

不要只问“根据全部聊天给我最终答案”。可以改成：“先找出与交付期限有关的原文，列出日期和适用条件，再比较它们是否冲突。”

如果是写文章，先检查标题中的问题需要哪些事实，再逐节写。每一节只处理相关材料，最后统一术语、日期和结论。

如果是改代码，先定位相关文件和调用关系，再修改。把几万行无关日志一并加入，可能增加干扰，也增加费用。

七、把关键要求重复一遍，有用吗？

适当重申当前要求通常有帮助，但不要把所有历史反复复制。重复太多，同样会扩大内容和干扰。

更适合的是维护一份当前有效要求，明确替代旧版本。例如写清“本轮采用 10 月版价格，旧版仅用于差异比较”。这样模型不必从多次修改中猜哪一版最终有效。

也不要仅靠把重要内容放在开头或结尾，就认为问题已经解决。还要有出处、读取工具和结果检查。

八、什么时候应该新开会话？

当话题已经改变、旧讨论很多而当前任务比较独立，或错误结论反复影响后续回答时，可以考虑新会话。

但新开前先整理目标、当前文件、已完成项和剩余问题。仅发一句“继续上次”通常不足以恢复完整工作。

如果是 API 或代理程序，使用上下文压缩功能时，应按当前平台支持方式保留必要内容，尤其注意思考块和会话前缀的兼容规则，不要随意裁剪结构化返回内容。

九、最后怎样确认对策有效？

用同一批问题比较整理前后结果：能否找到正确原文，有没有漏数字和限制，以及是否减少返工。还可以记录输入量、费用和完整耗时。

没有任何单一技巧能保证长上下文永不遗漏。把材料版本理清、减少重复、保留索引、按问题查原文，再核对重要结论，才是更可持续的处理办法。