用代码关系图压缩 AI 审查上下文

AI 审查大仓库时，难点往往是该读哪些文件：读太多会挤满上下文，读太少又可能漏掉被改动影响的调用方。code-review-graph 的办法是先在本地建立代码关系图，再把与变更有关的一小片上下文交给助手。

它的 README 声称，在六个仓库中，每次提问的 token 用量中位数约减少 63 倍。但原文作者没有复现这个数字，也没有跑通完整流程。这篇值得看的是筛选审查上下文的方法，收益数字还需要自己验证。

先找影响范围，再让 AI 读代码

code-review-graph 用 Tree-sitter 解析仓库，把函数、类、导入、调用和测试覆盖关系组织成本地图，再通过 MCP 提供给 AI 编程助手。

审查分支或 diff 时，助手先查询变更的影响范围（blast radius）：谁调用了它、哪些代码依赖它、有哪些相关测试，以及风险评分，再据此读取文件。

这比只看 diff 多走了一步。一个函数只改了几行，真正出问题的地方可能在未修改的调用方；关系图试图把这些文件一起找出来，同时减少无关代码进入上下文。

它提供的是审查上下文的筛选依据，审查结论仍然要靠助手阅读代码后形成。

原文列出的支持工具包括 Claude Code、Codex、Cursor、Windsurf、Zed、Continue、OpenCode、Gemini CLI 和 Copilot 等。不过，测试覆盖关系如何获得、风险分数怎样计算，原文没有解释，不能直接把它理解成运行测试后得到的覆盖率报告。

接入不难，持续更新才决定图有没有用

下面三条命令负责安装工具、配置 AI 编程平台并解析仓库：

pip install code-review-graph          # or: pipx install code-review-graph
code-review-graph install              # detect installed AI coding tools and configure each one
code-review-graph build                # parse the codebase

要留意第二条命令：code-review-graph install 会检测已安装的 AI 编程工具，为各个平台写入 MCP server 配置，在支持的平台安装 hooks 和 skills，并向平台规则文件加入使用图的指令。完成后需要重启编辑器或工具。

如果只想配置一个平台，可以执行 code-review-graph install --platform claude-code 或 code-review-graph install --platform cursor。

README 的测量是：一个约 3,000 个文件的仓库，冷构建约需 40 秒。之后可以通过 hooks 或 watch mode 随文件变更更新图。部分文件解析失败时，构建会报告 partial 状态并列出文件，这些文件保留此前的图记录。

保留旧记录让构建可以继续，但也留下了过期关系的可能。审查时应要求助手列出实际纳入上下文的文件、影响范围和相关测试；如果范围看起来不对，先重建图，再判断审查结果。

原文还提供了卸载入口，方便试用后撤回配置：

code-review-graph uninstall --dry-run    # preview only
code-review-graph uninstall              # preview, confirm, apply

注意第一行只预览；第二行按预览、确认、执行的顺序卸载。按原文说明，它只移除自己创建的文件和配置项，保留其他 MCP servers 与 hooks。

我的判断

我认可先确定依赖关系、再组织审查上下文的方向。相较于把大量文件塞给模型，它更节制；相较于只读 diff，它更有机会找到受影响的调用方。对上下文经常不够用的大仓库，这个思路有实际价值。

但「最小文件集合」更像工具的目标，原文没有证明它能完整覆盖所有影响。图是否新鲜、文件是否解析成功，都会影响筛选结果。

少用 token 和少漏问题，是两项需要分别验证的指标。

约 63 倍的数字来自 README，原文作者没有复现；安装流程也只是按 README 整理。文章没有给出审查准确率对照、各仓库特征或风险评分依据，因此目前更适合把它当作值得试验的工具方案，不能凭节省比例认定审查质量提高了。

能拿来做什么

• 在上下文容易撑满的前端或 Node 大仓库中，选一个影响范围已知的分支试用，核对它有没有找出实际调用方和依赖文件。
• 给日常 AI 审查提示词加上明确要求：列出纳入上下文的文件、变更影响范围和相关测试，让筛选过程可以人工检查。
• 在维护图时保留 hooks 或 watch mode，并检查构建的 partial 状态；发现遗漏调用方或范围异常时，先重建再继续审查。
• 比较接入前后的 token 用量时，同时核对问题检出情况，尤其检查工具有没有因缩小上下文而漏掉原本能发现的问题。