AI编程准则④⑤⑥：上下文过量反而削弱AI判断力

先把本文的定位讲明白。如果你读过上一篇文章，应该已经了解前三条准则，以及显式化、客观化、机械化这三个核心动作。但本文不预设你认同“上下文越多越好是错误的”这一观点——这个说法违反直觉，很有必要深入讨论。

准则④主要包含以下三点：

第一点：上下文属于稀缺资源，窗口容量、注意力以及相关性都存在上限；一旦塞入大量无关信息，AI识别关键约束的能力就会下降。

这句话中出现了三个“有限”，但大多数人往往只注意到第一个。

第二个“有限”才是核心。窗口从20万token扩展到100万token，并不意味着AI对第80万个token的关注程度与第5个token相同。把关键约束埋藏在海量无关文档里，从物理层面看AI确实“看到”了，但在实际推理过程中很可能并未真正调用。

▲ “给AI的信息越完整越好”是一种常见误解：塞入过多内容，关键约束反被淹没（曲线示意图）

这张图为示意性质，但其曲线形态背后有清晰的机制支撑：随着填充量增加，有效信息增多，识别率先上升；超过某个临界点后，无关信息占比过大，开始分散注意力，识别率随之下降。

结合实践经验，我的判断是：窗口使用率维持在30%到50%之间较为合理。如果每次对话都需要把窗口填到80%到90%，问题不在于上下文不足，而在于上下文缺少分层管理。

第二点：精准供给，即仅提供当前任务所必需的目标、背景、规则、示例、边界条件和验收标准，确保上下文保持高信号密度。

第三点：按需补充，采用渐进式披露策略，将稳定入口、专业知识、历史决策和领域材料分层存储，借助索引、知识库、Skill或文件引用等方式，在需要时再行加载。

“高信号密度”这一表述比“少给一些”更为准确。目标并非减少信息量，而是确保每一条信息都具备实际价值。六个要素——目标、背景、规则、示例、边界、验收标准——缺一不可，但每一条都应紧密围绕当前任务来提供。

▲ 渐进式披露：三层存储，按需调用

这张图展示了“分层存储”的具体实现方式。三层划分的依据是变化频率与使用频率：

索引层为何最容易被忽略？因为它看起来像是“重复劳动”——文档本身已经存在，为何还要额外维护一份索引？答案很简单：AI并不清楚这些文档的存在。除非你明确告诉它“修改订单状态流转就读取order-state-machine.md”，否则它不会主动执行`ls docs/`然后逐一查看哪些文件有用。

这正是第05篇讲解知识库定义时提到的“可检索”判定标准的实际内涵。“可检索”不等于“文件存在”，而是指“AI知道该文件存在，并且明确何时应当读取”。前者依赖`git add`即可实现，后者则必须依靠索引来支撑。

本条准则包含两项要求：

第一项要求：文档应做到规范化、结构化、可检索、可引用，使AI与人都能迅速定位并理解关键决策、约束条件和背景信息，彻底摆脱对口头沟通和对话历史的依赖。

第二项要求：材料必须具备可验证性，关键数据和重要决策需要附带