当 AI 读完你的代码：code-review-graph 给代码库建了一张持久地图
当 AI 读完你的代码：code-review-graph 给代码库建了一张持久地图
你让 Cursor 帮你改一个函数，它先花 30 秒扫一遍整个仓库。你再让它改隔壁那个函数，它又扫 30 秒。同一个仓库，同样的结构信息，每次都从头读起。
这不是 AI 不够聪明，是它没有地图。
tirth8205/code-review-graph 解决的就是这件事：给你的代码库建一张持久化的结构地图，让 AI 工具只读它真正需要的那一小块。
问题：AI 编程工具的"金鱼记忆"
当前 AI 编程工具（Cursor、Claude Code、Copilot）有一个共同的隐藏成本：每次对话都从零开始理解代码库。
典型流程是这样的：你问"这个函数在哪被调用"，AI 工具要么 grep 全仓库（慢且噪音多），要么用向量检索找相似文本片段（可能漏掉精确调用关系）。无论哪种方式，每次对话都要重新扫描，每次扫描都要把结果塞进上下文窗口。
一个 10 万行的代码库，AI 工具每次对话可能要消耗 5 万 token 只是为了"理解上下文"。这就像你每次走进办公室都要重新认路——门在哪、工位在哪、会议室在哪，全都要重新摸索。
根本问题是颗粒度错配：AI 工具在"文件+行"颗粒度上工作，但代码的结构信息存在于"函数+调用关系+模块依赖"颗粒度。用错的颗粒度去理解代码，就像用显微镜看地图——放大倍数够了，但你永远看不到整条路。
code-review-graph 的方案：先建地图，再问路
code-review-graph 的核心思路分三步：
第一步：用 Tree-sitter 做结构化解析。 Tree-sitter 是 GitHub 开源的增量解析库，能在毫秒级别把源代码解析成语法树。code-review-graph 不依赖语言特定的 LSP（Language Server Protocol），而是用 Tree-sitter 统一处理所有语言——Python、TypeScript、Rust、Go 都走同一条管道。
第二步：把解析结果存成图。 不是文件树，不是符号表，而是一张关系图：函数 A 调用函数 B，类 C 继承类 D，模块 E 依赖模块 F。这张图存在 SQLite 里，持久化在本地。下次 AI 工具问"这个函数被谁调用"，不用扫仓库，直接查图。
第三步：通过 MCP 暴露给 AI 工具。 MCP（Model Context Protocol）是 Anthropic 推出的标准协议，让 AI 工具以统一方式访问外部数据源。code-review-graph 实现了 MCP server，任何支持 MCP 的 AI 工具（Claude Code、Cursor 等）都能直接查询这张代码图。
为什么"地图"比"搜索"快
传统 AI 编程工具的上下文获取方式是搜索驱动：你问一个问题，它搜索相关文件，把搜索结果塞进上下文。每次搜索都是从零开始。
code-review-graph 的方式是地图驱动：它预先建好代码的结构图，AI 工具的问题变成图查询而不是文本搜索。
| 维度 | 搜索驱动 | 地图驱动 |
|---|---|---|
| 首次查询 | 全仓库扫描 | 查图（毫秒级） |
| 后续查询 | 重新扫描 | 查图（毫秒级） |
| 上下文消耗 | 5万+ token | 几百 token |
| 调用关系 | grep 模糊匹配 | 精确图边 |
| 增量更新 | 无 | 只更新改动部分 |
这和 RAG 不一样
有人会问：这不就是代码版的 RAG（Retrieval-Augmented Generation）吗？
不一样。RAG 用向量检索找"语义相似"的文本片段，但代码的调用关系不是"语义相似"能捕捉的。函数 A 调用函数 B，可能两个函数名字完全不像、语义完全不同，但调用关系是精确的结构事实。
RAG 的核心假设是"语义相似 ≈ 相关"，这个假设在规则世界不成立——Euclid-MCP 的实验已经证明，480B 参数的大模型在 1000 条事实的规则推理上和 8B 模型一样烂。代码调用图就是典型的规则世界：A 调用 B，这是事实，不是概率。
code-review-graph 不做语义检索，做结构查询。它回答的不是"哪些文件和这个问题相关"，而是"这个函数的调用者是谁、被调用者是谁、依赖什么模块"。精确事实，不需要概率。
"Local-first" 不是装饰
code-review-graph 强调"local-first"——所有数据存在本地 SQLite，不上传云端。这不只是隐私考量，是性能考量。
云端方案（如 Sourcegraph）的延迟在 100-500ms，本地 SQLite 查询在 1-5ms。对于 AI 编程工具来说，100ms 的查询延迟意味着每次对话多等 0.1 秒，一天累积下来就是几分钟。本地优先不是"隐私友好"的营销话术，是"快 100 倍"的工程选择。
概念谱系：从"暴力搜索"到"结构地图"
code-review-graph 的核心洞察可以放进一个更大的概念谱系：
- 章鱼 RNA 编辑：DNA 预训练 + RNA 推理时计算，不改蓝图改施工图
- 黏菌外化记忆：用黏液轨迹外化记忆，不需要神经元
- 鸟类量子磁感应：放大器和传感器分开，分工比统一更有效
- Euclid-MCP 推理外包：让 LLM 当诗人，让 Prolog 当会计
- code-review-graph 结构地图：把代码结构外化成持久地图，AI 工具只查询不扫描
谁该用
- Cursor/Claude Code 用户：如果你的代码库超过 1 万行，每次对话的上下文扫描成本已经显著。code-review-graph 能把上下文消耗降一个数量级。
- MCP 生态参与者：code-review-graph 是 MCP 协议在代码智能领域的标杆实现，值得研究其接口设计。
- 代码库维护者：即使不用 AI 工具，code-review-graph 的结构图也能帮你理解大型代码库的依赖关系。
局限
- 只支持 Tree-sitter 能解析的语言：冷门语言可能不支持
- 图的质量取决于 Tree-sitter 语法树：语义层面的复杂关系（如设计模式）无法捕捉
- 增量更新机制还在早期：大型 monorepo 的增量性能未经充分验证
结尾
AI 编程工具的下一个突破不会来自更大的模型，而来自更好的上下文工程。code-review-graph 把"理解代码"这件事从"每次重新搜索"升级到"查一张持久地图"，这和人类程序员的工作方式一致——你不会每次走进办公室都重新认路，你有一张内化的地图。
地图比搜索快 100 倍，不是因为地图的引擎更强，而是因为地图不需要每次都重新画。
---
GitHub: https://github.com/tirth8205/code-review-graph 官网: https://code-review-graph.com MCP 协议: https://modelcontextprotocol.io