图谱的真实用途 · 一个诚实的「模型 vs 客户端」之辨
建好的代码库图谱怎么被用？一个反直觉的真相：它不喂给模型，而是给 grok-web 编辑器做 IDE 级的跳转导航。这一章看图谱的增量 actor 与语言感知排序，更重要的是——教你别假设「凡索引皆为 LLM」。
图谱的真实用途 · 一个诚实的「模型 vs 客户端」之辨
上一章建好了符号图。自然的问题是：它怎么被用？——这里有个反直觉、但很重要的真相。
增量 actor：文件一变就更新
图谱由 IndexManager(一个 actor)维护。它进程级去重(ACTIVE_MANAGERS 按规范化根路径存 Weak)，文件变化时(来自 fsnotify)增量重建那个文件的符号，而不是整仓重扫。更新用 Arc::make_mut(写时复制)：除非有查询正拿着旧快照，否则零成本；文件事件还会按路径合并(Removed-after-Create 抵消)。
查询侧有个亮点：find_definitions_smart / find_references_smart 会做语言感知排序——和「当前上下文文件」同语言的结果排前面。查 foo，你在 .rs 里，Rust 的定义就优先。
反直觉的真相：它不喂给模型
现在是关键。你可能理所当然地以为：建这么一张符号图，是为了喂给模型、让它更懂代码。不是。
代码库图谱是 grok-web 编辑器的 IDE 导航功能(跳转定义、查引用)，给人类用户的编辑器用的，不是给模型的。证据：
- shell 的 ACP 扩展
extensions/code_nav.rs注册的是x.ai/code/goto-definition、.../find-references这些编辑器方法； - 资格判定
code_nav_eligibility_inner有四道闸，第一道就是ClientType::GrokWeb才启用——明确只给 web 客户端，不给模型； - 全仓库 grep 确认：没有任何 LLM 工具、没有任何 prompt/上下文构造器消费这个索引。模型理解代码靠的是 grep、LSP、read_file；这张图服务的是人的编辑器。
这是读源码最该学的一课之一。 看到「代码库图谱」「符号索引」，很容易脑补成「给 RAG / 给模型上下文」。但真相是：grok 既是一个 agent，也是一个 web 编辑器的后端——这张图属于后者。别假设「凡索引皆为 LLM」；跟着代码的实际消费者走，而不是跟着你的预期走。这也正是读真实源码、而不是读架构 PPT 的价值。
那模型到底怎么理解代码？
顺带把这条线理清：模型理解代码库，靠的是工具——grep 按文本搜、lsp 按语义查、read_file 读细节，外加 system prompt 里注入的 AGENTS.md 与首条消息里的 git 状态。没有一个「把整个代码库图谱塞进上下文」的动作。这其实很克制，也很对：上下文是稀缺资源，按需 grep/read 比预先灌一大张图高效得多。
和《从 LLM 到 Coding Agent》对照
这一章几乎没有对照，但它给了一个方法论上的提醒：读一个真实系统时，一个子系统的「用途」不能靠命名猜，要靠追踪它的消费者。codebase-graph 命名上像是给 AI 的，实际是给编辑器的。这种「实现与直觉不符」的地方，恰恰是源码解读最有价值的产出。下一章看一个确实为并行 agent 服务的硬核子系统：快速 worktree。
上一篇：代码库图谱 · 构建 · 下一篇：并行 worktree