Query：索引先行浪费上下文吗？

原始问题：context engineering 说上下文是有限的 attention budget，每个 token 都要节省；但本知识库的工作规则却要求 LLM 每次操作前先读 purpose.md 和 index.md——这不是自相矛盾地浪费 token 吗？ 档位：standard。依据页面：context engineering、LLM Wiki 模式、context engineering 原文。

回答：不矛盾，这恰恰是 attention budget 的正确花法

1. 索引是“轻量标识符”，不是内容本身。 Anthropic 的 just-in-time 检索策略核心是：维护轻量标识符（文件路径、一行摘要），运行时按需加载完整内容。index.md 正是这样一份标识符清单——几十行就覆盖全库地图。读它花的是小钱，买到的是“接下来只读真正相关的 2-3 页”的精准性。不读索引的替代方案是全文扫描或猜测，那才是 attention budget 的灾难。

2. 这是渐进式披露（progressive disclosure）的制度化。 “agent 通过探索逐层组装理解，工作记忆里只保留必要的部分”——索引先行把这个原则变成了固定动作：第一层读地图（index），第二层读相关页，第三层才碰原始资料（deep 档）。query 的三档位就是三层披露深度的显式开关。

3. purpose.md 是“正确高度”的锚。 system prompt 要在“硬编码”和“空泛”之间找正确高度；purpose.md 对 wiki 操作起同样作用——它不规定怎么做（schema 管那个），而是给出“为什么存在、什么该纳入”的判断启发式。没有它，LLM 在模糊内容归档时只能瞎猜，猜错的返工远贵于读它的几百 token。

4. 数量级对比。 purpose + index 合计约 1-2K token，而一次盲目的全文扫描加上误读几个不相关页面，消耗往往高出一个数量级、还污染上下文（粗略估算，非实测）。Karpathy 的经验是这套索引导航“在 ~100 份资料规模下工作得出奇地好，避免了 embedding RAG 设施”。

结论

“索引先行”不是无视上下文稀缺，而是因为上下文稀缺才存在的规则：用固定的小额导航成本，换取检索的精准与可预期。它会失效的临界点是索引本身变得太大——schema.md 已预设了应对（单主题超 ~60 页拆分子索引）。