100万上下文并非刚需，你也用不上“上下文压缩”！

作者：袖梨 2026-07-29

优化AI Coding上下文管理，应先看清LLM“愚蠢区间”，而非迷信压缩工具与100万上下文！核心内容：1. 标准开发流程如何管理AI Coding上下文2. 斯坦福论文为何能解释LLM“愚蠢区间”3. 如何应对开发场景的认识偏差

大家好，我是小码，前一篇文章介绍了我在实际开发中用到的mattpocock/skills技能包：mattpocock/skills新版本能力：批处理grill-me&wayfinder体验本文是基于Matt Pocock这一系列skills在实践中的启发，来说说在AI Coding中的上下文管理。（但本文描述的现象脱离mattpocock/skills依然适用！）Matt Pocock的这一系列技能中，最常用的工作流程是：

// 逻辑是把需求整体好、写成方案、拆成执行工作票、开始实施、Review等 grill-with-docs -> to-spec -> to-tickets -> implement

在你把需求写成方案（Plan/Spec）并拆成执行工作票（Tickets）之后的下一步是实施（Implement）。这里有个很重要的步骤，就是你在每个Ticket实施的时候，按照推荐，最好新开会话、按照顺序逐个实施（根据依赖也可以并行）。

很多人可能有疑惑，现在LLM的100万上下文几乎成标配了，再说了很多工具比如Codex的上下文压缩非常丝滑了，为什么还要每次新开会话去实施？

愚蠢区间（Stupid Zone）

目前业界普遍认为，LLM处理长文本的时候存在显著的“愚蠢区间”，特别是在处理复杂逻辑、多步推理的任务中，有显著的智力下降表现。这是因为LLM对信息的关注度不是均匀分布的，它只对开头和结尾的信息记得最牢，分布类似一条U型曲线：

准确率 (Accuracy) 100% |                                     /      |                                    /      |                                   /      |                                  /      |      ___________________________/   0% +-------------------------------------------> 文本位置     开头 (0%)                 中间 (50%)         结尾 (100%)  (开头：记忆深刻)           (中间：彻底遗忘)      (最后：记忆清晰)

这个现象最早由斯坦福大学、加州大学伯克利分校等机构的学者在 2023 年的重磅论文《Lost in the Middle: How Language Models Use Long Context》中提出，它揭示了LLM在长文本中提取和使用信息的能力，取决于该信息在文本中出现的位置。有兴趣可以阅读：

https://arxiv.org/abs/2307.03172

在真实的开发场景中，开头的Token一般包含：系统提示词、skills、AGENTS.md 以及部分项目上下文，结尾是才是你的具体需求。很多人的Agent工作环境在开头部分就直接占满了，一般是装了太多了Skills、MCP、配置了复杂的AGENTS.md（CLAUDE.md）等。而且目前很难消除这个“愚蠢区间”，这可能是Transformer架构的注意力机制缺陷。但是可以避免让上下文落到“愚蠢区间”。

150K 黄金推理区间

Matt Pocock基于真实的编程工作流提出过一个双区模型：

聪明区（SMART ZONE）：上下文在100K左右，此区间内的LLM推理能力最强，代码生成、指令遵循都处于最佳状态。
愚蠢区（DUMB ZONE）：上下文超过临界点，LLM幻觉激增、遗漏指令、胡说八道。

随着LLM能力的增强我觉得可以适当放宽这个区间，比如150K，甚至更高一些，但是最高不能超过上下文的40%左右。AI大神Karpathy也提出过类似的观点，他认为LLM的上下文就类似于计算机的“内存”。如果你试图把硬盘数据全部塞进内存，后果可想而知。社区中有个很好的比喻：

“大模型在面对长上下文时的表现，就像一个在考试前一天晚上临时抱佛脚（Cramming for an exam）的差生。你能够牢牢记住你复习的前几章（开头）和最后看的几章（结尾），但是夹在中间那 3 个小时复习的内容全都变成了浆糊（turn to mush）。”

你可能看过很多LLM厂商在介绍自己的LLM长上下文的时候使用“大海捞针”这种测试或者比喻（Anthropic）来说明LLM在长上下文中表现的出色。但是AI编程属于复杂的多步推理任务，不是简单的“检索”任务，在长上下文中，做搜索式的大海捞针可能没问题，但是不适合复杂的、多步推理的编程任务。

减少上下文占用

很多人给自己的Agent装了大量的Skills、MCP、插件等工具，撰写了数百行的AGENTS.md，导致LLM开口第一句就超过了100K，直接进入愚蠢区间。随着模型能力的提升，太多的Prompt反而是污染和束缚，Anthropic在发布Opus5、Fable5等新模型的时候，官方的Claude Code工具移除了80%的系统提示词，性能反而提高。你需要做减法了：重新审视安装的Skills、MCP等插件，别让无关的内容浪费上下文。检查AGENTS.md(CLAUDE.md) 它需要那么长吗？别写成了README.md。复杂任务拆分，不要在一个会话里完成所有任务！检查你的Codex/Claude Code配置，设置最长上下文不要超过150K或者其他数值！