你改了 3 行代码，让 AI 帮你 review 一下。结果它把整个项目几百个文件全读了一遍，光 Token 就烧掉好几万。项目越大越离谱——一个中型仓库的 PR 审查，轻松吃掉 4 万多 Token，其中 90% 的内容跟你的改动毫无关系。
AI 不缺写代码的能力，缺的是"只读该读的东西"的能力。
最近有个叫 code-review-graph 的开源项目火了，思路很妙——给你的代码库建一张"知识图谱"，AI 每次只读跟变更相关的那一小片。
它到底干了什么？
一句话：用 Tree-sitter 把你的代码解析成结构化图谱，存进本地 SQLite，然后通过 MCP 协议告诉 AI "你只需要看这几个文件"。
具体来说，它做了三件事：
第一步，建图。 首次运行时扫描整个项目，把每个函数、类、导入关系、调用链路、继承结构全部提取出来，生成一张代码结构图谱。500 个文件的项目，首次建图大概 10 秒。
第二步，增量更新。 每次你改代码或 git commit，它只重新解析变更的文件，通过 SHA-256 哈希校验找到受影响的依赖节点。2900 个文件的项目，增量更新不到 2 秒。
第三步，精准投喂。 当你让 AI 做代码审查时，它先算出"影响半径"（blast radius）——哪些函数被调用了、哪些类依赖了改动的代码、哪些测试覆盖了这块逻辑。然后只把这些精准的结构摘要交给 AI，而不是把整个仓库塞过去。
数据说话：省了多少？
官方在 6 个真实开源仓库上跑了基准测试（13 次 commit），结果相当硬核：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
9.1x |
|
|
|
|
16.4x |
|
|
|
|
6.9x |
|
|
|
|
8.0x |
|
|
|
|
8.1x |
| 平均 |
|
|
8.2x |
平均 Token 消耗降到原来的 1/8。对按 Token 计费的 API 用户来说，这意味着账单直接砍掉 87%。
而且影响分析的召回率是 100%——也就是说，该被审查到的文件一个都没漏掉。F1 分数 0.54，是故意设计得偏保守的：宁可多标几个文件，也不能漏掉关键依赖。
怎么上手？三步搞定
# 1. 安装
pip install code-review-graph
# 2. 自动配置（会检测你装了哪些 AI 工具）
code-review-graph install
# 3. 建图
code-review-graph build
install 命令会自动检测你装了 Claude Code、Cursor、Copilot 还是 Codex，写入对应的 MCP 配置。配置完之后，你正常使用 AI 工具就行，图谱在后台默默工作。
它还支持 24 种编程语言 + Jupyter Notebook，包括 Python、TypeScript、Go、Rust、Java、Kotlin、Swift 等主流语言。
几个让我眼前一亮的设计
影响半径可视化。 跑 code-review-graph visualize 能生成交互式的 D3.js 力导向图，直观看到代码模块之间的依赖关系。改了一个函数，哪些地方会受影响，图上看得一清二楚。
Hub/Bridge 节点检测。 自动找出项目里"连接最多"的核心函数（Hub）和"架构瓶颈"（Bridge）。做代码重构的时候，这些节点就是最需要小心的地方。
知识缺口分析。 能识别出哪些热点代码缺乏测试覆盖，哪些模块是孤立节点。对技术债治理特别有用。
Monorepo 友好。 大型单体仓库是 Token 浪费的重灾区。实测在 27,700+ 文件的仓库里，图谱能把审查范围压缩到约 15 个文件。
跟之前聊过的 DESIGN.md 有什么区别？
上周刚聊了 Google 开源的 DESIGN.md，那个是给 AI 讲"设计系统长什么样"。而 code-review-graph 是给 AI 讲"代码结构长什么样"。
两个工具解决的问题不同，但思路一样：别让 AI 从零开始猜，提前把结构化知识准备好喂给它。
如果你在用 Claude Code 做日常开发，强烈建议在项目里加上 code-review-graph。不改变任何工作习惯，只是让 AI 变得更聪明、更省钱。
推荐标签：
#AI编程 #ClaudeCode #Cursor #代码审查 #开源工具 #Token优化 #MCP #TreeSitter #代码知识图谱 #开发效率