# 图谱的真实用途 · 一个诚实的「模型 vs 客户端」之辨

> 建好的代码库图谱怎么被用？一个反直觉的真相：它不喂给模型，而是给 grok-web 编辑器做 IDE 级的跳转导航。这一章看图谱的增量 actor 与语言感知排序，更重要的是——教你别假设「凡索引皆为 LLM」。

- 作者：David（道雾轩）
- 专栏：Grok Build 源码解读（https://daiw.org/manual/grok-build.md）
- 最后更新：2026-09-13
- 原文：https://daiw.org/manual/grok-build/codebase-graph-use
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 图谱的真实用途 · 一个诚实的「模型 vs 客户端」之辨

[上一章](https://daiw.org/manual/grok-build/codebase-graph-build)建好了符号图。自然的问题是：它怎么被用？——这里有个**反直觉、但很重要**的真相。

## 增量 actor：文件一变就更新

图谱由 `IndexManager`(一个 actor)维护。它进程级去重(`ACTIVE_MANAGERS` 按规范化根路径存 `Weak`)，文件变化时(来自 [fsnotify](https://daiw.org/manual/grok-build/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](https://daiw.org/manual/grok-build/read-and-search)、[LSP](https://daiw.org/manual/grok-build/lsp)、read_file；这张图服务的是人的编辑器。

<Callout type="warn">
  **这是读源码最该学的一课之一。** 看到「代码库图谱」「符号索引」，很容易脑补成「给 RAG / 给模型上下文」。但真相是：grok 既是一个 **agent**，也是一个 **web 编辑器的后端**——这张图属于后者。**别假设「凡索引皆为 LLM」**；跟着代码的实际消费者走，而不是跟着你的预期走。这也正是读**真实源码**、而不是读架构 PPT 的价值。
</Callout>

## 那模型到底怎么理解代码？

顺带把这条线理清：模型理解代码库，靠的是**工具**——`grep` 按文本搜、`lsp` 按语义查、`read_file` 读细节，外加 [system prompt](https://daiw.org/manual/grok-build/system-prompt) 里注入的 AGENTS.md 与首条消息里的 git 状态。**没有一个「把整个代码库图谱塞进上下文」的动作**。这其实很克制，也很对：上下文是稀缺资源，按需 grep/read 比预先灌一大张图高效得多。

## 和《从 LLM 到 Coding Agent》对照

这一章几乎没有对照，但它给了一个**方法论**上的提醒：读一个真实系统时，一个子系统的「用途」不能靠命名猜，要靠**追踪它的消费者**。codebase-graph 命名上像是给 AI 的，实际是给编辑器的。这种「实现与直觉不符」的地方，恰恰是源码解读最有价值的产出。下一章看一个确实为并行 agent 服务的硬核子系统：快速 worktree。

---

上一篇：[代码库图谱 · 构建](https://daiw.org/manual/grok-build/codebase-graph-build) · 下一篇：[并行 worktree](https://daiw.org/manual/grok-build/fast-worktree)
