我用 AI 编程工具有个老毛病：让它 review 一段改动，它先把半个仓库的文件全读一遍，token 烧得心疼，关键信息还淹没在一堆无关代码里。后来想明白了，不是模型笨，是它没有"地图"，只能地毯式搜索。
code-review-graph 干的就是给 AI 编程工具配这张地图。它用 Tree-sitter 把代码库解析成一张知识图谱存进 SQLite，AI 审查时先查图谱算出受影响范围，只读必要文件。6 个仓库实测 token 省 38 到 528 倍，monorepo 里 27700 多个文件排除后只读大约 15 个。
这篇是我自己装一遍后整理的上手 SOP，4 步走通：装、建、用、查。每步附真实命令和可复制 Prompt，文末有踩坑记录。想先了解项目设计思路的，去看本批另一篇开源介绍，这篇只讲怎么落地。
一、它解决什么问题
AI 编程工具（Cursor、Claude Code、Codex 这些）审查代码时，默认做法是把相关文件全塞进上下文。小项目无所谓，仓库一大就出事：几万个文件里大部分跟你的改动毫无关系，模型却要把它们都过一遍才能判断影响范围。token 白烧，注意力被稀释，审查质量跟着掉。
code-review-graph 的思路很直接：提前把代码库的结构关系存成一张 SQLite 图谱。节点是函数、类、导入，边是调用、继承、测试覆盖。审查时 AI 先查图谱，算出改动的 blast radius（受影响的调用方、依赖、测试），然后只读这几个必要文件，不搞全量扫描。
二、装：安装并配置平台
前置条件：Python 3.10 以上。推荐装 uv，后面用 uvx 跑会很方便。没装 uv 的话用 pip 或 pipx 也行。
先装 code-review-graph 本体：
# 方式一：pip
pip install code-review-graph
# 方式二：pipx（推荐，隔离环境不污染全局）
pipx install code-review-graph装完本体还不够，关键一步是让它和你用的 AI 编程工具对接：
# 自动检测并配置所有支持的 AI 编程工具
code-review-graph install
# 如果你只用某一个平台，可以指定，避免装多余配置
code-review-graph install --platform cursor
# 其他可选平台：claude-code / codex / gemini-cli / copilot / kiro 等这条命令背后做了三件事：写正确的 MCP 配置、装平台原生 hooks/skills、往平台 rules 里注入图谱指令。说白了就是让 AI 工具知道"审查代码前先查图谱"。
装完必须重启编辑器或工具。MCP 配置不会热加载，不重启等于白装。这个坑后面还会讲。
三、建：构建代码图谱
配置好平台，下一步把代码库解析成图谱：
code-review-graph build这条命令用 Tree-sitter 把代码解析成 AST，提取出函数、类、导入作为节点，调用、继承、测试覆盖作为边，最后存进一个 SQLite 图数据库。500 个文件的项目，大约 10 秒建完。
原理一句话讲清楚：Tree-sitter 把代码解析成抽象语法树，节点是函数/类/导入，边是调用/继承/测试覆盖关系，全部存进 SQLite 图数据库。审查时图谱工具根据这些关系算出最小必要文件集，AI 只读这些文件。本质上是用空间换时间，图谱建一次，后面每次审查都受益。
四、用：触发图谱并增量更新
图谱建好了，回到你的 AI 编程工具里，跟它说一句：
Build the code review graph for this project之后 watch 模式和平台支持的 hooks 会自动增量更新图谱。文件保存时更新，commit hook 触发时也更新。增量速度很快，2900 个文件的项目重新索引不到 2 秒，你不用每次改动都手动 rebuild。
这一步的意义在于：图谱不是一次性的快照，它会跟着你的代码变动走。你正常写代码、保存、提交，图谱在后台默默更新，下次审查时 AI 拿到的永远是最新结构。
五、查：带着图谱审查代码
这一步是真正出效果的地方。你请 AI 审查改动时，它会先经 MCP 查图谱，算出这次改动的 blast radius，也就是受影响的调用方、依赖和测试，然后只读这些文件。
试一下这个提问方式：
Review the changes in src/auth/, what's the blast radius?AI 会先查图谱定位 src/auth/ 下的改动，算出哪些调用方、依赖、测试被波及，然后只把这几个文件拉进上下文做审查。效果是实打实的：6 个仓库实测 token 省 38 到 528 倍，平均每个问题读的文件量少 93 倍。monorepo 里 27700 多个文件，排除后只读大约 15 个。
对比一下就明白差距了：没有图谱时，AI 审查一个改动可能要读几十上百个文件才能搞清楚影响范围；有了图谱，它直接知道哪几个文件受影响，上下文窗口留给真正重要的代码。
六、卸载与清理
不想要了，卸载是对称的，只删 code-review-graph 自己的文件，不会动你其他的 MCP 配置、hook 或 skill。
# 先预览会删什么，不实际执行
code-review-graph uninstall --dry-run
# 确认后真正执行
code-review-graph uninstall --yes
# 清理所有注册过的仓库
code-review-graph uninstall --all-repos
# 只删平台集成，保留图谱数据库（下次还能复用）
code-review-graph uninstall --keep-data我的习惯是卸载前先跑一遍 --dry-run 看看要删什么，心里有数再动手。--keep-data 这个选项挺实用，如果你只是想暂时关掉集成但保留建好的图谱，下次重新 install 时就不用重新 build 了。
七、踩坑记录
实际装下来有几个坑值得提前说。
坑一：不重启编辑器，以为没生效。 install 命令写完 MCP 配置，但编辑器不会自动重新加载。你回到工具里试，发现图谱没反应，以为装失败了，其实就差一个重启。装完第一件事：关掉编辑器，重新打开。
坑二：Tree-sitter 不支持你的语言。 Tree-sitter 解析器覆盖的语言有限。如果你的语言不在支持列表里，得自己在项目根目录建 .code-review-graph/languages.toml，把文件扩展名映射到 tree_sitter_language_pack 里对应的语法，并指定节点类型（function/class/import/call）。第一次配容易漏节点类型，导致图谱里缺边少节点，审查时算出的 blast radius 不准。
坑三：uvx 和 pip 混用。 两种安装方式生成的配置不完全一样。install 命令会自动识别你是 uvx 还是 pip 安装的，生成对应配置，但中途换安装方式，旧配置可能残留。建议从头到尾用一种，别混。
坑四：超大 monorepo 初始构建慢。 仓库特别大的时候，第一次 build 会花不少时间。可以先单独跑完 build，再开 watch 模式，别指望第一次边建边用。build 跑完之前图谱不完整，审查结果也会打折扣。
坑五：卸载前不看 --dry-run。 虽然 uninstall 只删 CRG 自己的文件，但不看预览直接 --yes，万一注册过多个仓库，可能删得比你预期的多。养成先预览的习惯，哪怕只是扫一眼。
八、小结
整个流程四步：装配置、建图谱、触发增量、带图谱审查。配好之后 AI 编程工具审查代码的 token 消耗会显著下降，审查质量也因为注意力集中而提升。最大的收益不在省 token，在于 AI 拿到了代码库的结构化理解，审查时能精准定位影响范围，而不是在海量文件里碰运气。
这篇是上手实战，和本批的另一篇《code-review-graph：给 AI 编程工具减负的本地代码知识图谱》配着看。那篇讲是什么和为什么，这篇讲怎么落地。两篇一起看，从理解到上手一条线打通。
参考来源
- code-review-graph GitHub 仓库：https://github.com/tirth8205/code-review-graph
- PyPI 包页面：https://pypi.org/project/code-review-graph/
- 项目官网：https://code-review-graph.com