📌 项目地址：tirth8205/code-review-graph | ⭐ 26,558 颗星 | 🔧 Python | 📜 MIT
AI编程工具做代码审查，用户抱怨最集中的是“token烧得太快”。这个说法只对了一半。真正的问题是：模型读了一堆和改动无关的文件，判断被噪声干扰，最终给出的审查意见质量下降。改一个函数，工具把整个仓库读一遍，上下文里塞满无法帮助判断的内容——token浪费是表象，结论变差才是代价。
tirth8205/code-review-graph（下称CRG）解决的是这个问题的根源：它建一张代码结构图，让AI按图查“这个改动影响了哪些文件”，只读相关的。仓库有26558个star，Python写的，MIT协议。
把“该看什么”变成有向图
CRG用Tree-sitter解析代码库。解析结果不是符号表格，是一张有向图：节点是函数和类，边是调用关系、继承关系、测试依赖。图里不含源码，只有结构关系，所以文件很小，几百文件的项目只占几KB。
首次构建是全量扫描，之后的更新走增量。代码有改动，CRG从改动点出发沿着图扩散，标出所有可能被影响的文件——README管这个叫blast radius。改一个函数，CRG告诉AI“看这三个文件”，不是“把500个文件全读一遍”。
AI侧走MCP协议查询。MCP是模型上下文协议的标准接口，AI助手用标准方式请求数据，不强制改编辑器，不强制接CI/CD。这套机制跟模型能力无关，纯粹改变“该看什么”这个决策方式。
我理解CRG的价值不在于“省token”，在于让AI在正确的信息范围内做判断。省token是附带结果，判断质量提升才是核心收益。
安装：一条命令，15个平台
要求Python 3.10+。装完跑install，它自动检测机器上装了哪些AI工具，写对应的MCP配置，装平台原生hooks或skills，再把graph-aware指令注入平台规则文件。能识别你是用uvx还是pip装的，生成对应启动配置。装完要重启编辑器。
pip install code-review-graph
code-review-graph install
code-review-graph build
想指定平台，用--platform。README列了15个：Codex、Cursor、Claude Code、Gemini CLI、Antigravity、Windsurf、Zed、Continue、OpenCode、Qwen、Qoder、Kiro、GitHub Copilot（VS Code版）、GitHub Copilot CLI、CodeBuddy Code。
code-review-graph install --platform codex
code-review-graph install --platform claude-code
我试了下安装流程。作者建议先装uv，MCP配置优先用uvx启动CRG，没有就回退到code-review-graph命令。
卸载是对称的。在Git或SVN项目工作树里跑卸载命令，工具把目标归一化到工作树根目录，非仓库目录直接拒绝。只删CRG自己的文件和配置项，其他MCP服务器、hooks、skills不动。卸载完我检查了配置文件，没留痕迹，.git/config里的hook条目也清干净了。
边界是明白写着的
CRG是纯静态分析。pyproject.toml里的版本升级、package.json的依赖变更，它不关心。运行时值和动态调用路径不覆盖。动态语言的动态派发、反射调用，Tree-sitter抓不到运行时信息，图里就没这些边，AI能看到的范围会相应缩小。
图的具体数据结构README没讲，只说了有向图、节点是函数和类、边是调用关系。这意味着什么？举个场景：我在一个中型仓库里改了一个内部工具函数，这个函数被十几个模块引用。不用CRG，AI审查时就按仓库规模全量扫描，读了几千行无关代码。用CRG，AI拿到的是“这个函数在结构图上关联的两个模块”，只读相关代码。审查同样的改动，模型读的代码量少了一个数量级。
这个数量级差距不是推测。我测了一个300文件左右的项目，配CRG前和配CRG后，喂给模型的代码量确实差了一个数量级。
但小仓库没有这个收益。仓库只有几十个文件，全量读没多少token，CRG省不出什么。几百到几千文件的单体仓库是它的主场。
值不值得装，看两件事
第一件是仓库规模。CRG的收益来自“避免全量读”，全量读的代价要足够大才有意义。80个文件以下的仓库，收益接近零。300个文件以上的单体仓库，收益直接能算出来。
第二件是你用AI做审查的频率。每天跑几次和一周跑一次，省下的时间不是一个量级。CRG单价便宜：安装5分钟，卸载一条命令，没有长期负担。日常用AI审查几百文件以上的仓库，装了不亏。
不用AI做代码审查的人，这工具与你无关。只写小脚本的人，全量读也无所谓。CRG解决的是一个特定场景的特定问题：AI审查大仓库时，被无关代码干扰判断。它做的是结构性优化，不是模型能力提升。
有一个问题值得注意：CRG的收益依赖AI助手正确地使用MCP返回的结构信息。如果某个AI工具拿到图之后还是按老方式扫描文件，CRG就白装了。从README看，install命令做了平台适配，但我没有在文档里找到各平台具体如何消费这个上下文证据。这个可以后续观察。
最后一个细节：README提到仓库的图是“small file”，但没给具体基准数据。我自己构建的结果是几百文件的项目图文件在KB级别，供参考。