别再让 AI 全库扫代码：code-review-graph 的上下文治理思路

AI 代码审查最容易被忽略的成本，不是模型单价，而是它为了回答一个局部问题读了多少无关代码。一个函数改动，可能把整个目录、工具输出和相似实现一起塞进上下文；模型看似掌握了更多信息，实际却更容易错过真正的调用边界。

code-review-graph 的切口不是再做一个聊天式编码助手，而是先给仓库建立一张结构地图：Tree-sitter 解析代码，节点和边写入本地图谱，再通过 CLI、MCP 和 GitHub Action 把“这次改动可能影响什么”交给审查工具。

它优化的是上下文入口

CRG 的核心流程可以拆成四步：解析函数、类、导入、调用和测试关系；将结构存进本地 SQLite 图谱；根据变更回溯调用者、依赖者和测试；向 Agent 返回一组更小的审查上下文。它不是让模型“理解整个仓库”，而是先用确定性结构分析缩小阅读范围。

这和全库向量检索不是同一件事。向量检索擅长找到语义相近的片段，图谱擅长回答“谁调用了它、它依赖谁、测试在哪里”。真正有用的组合通常是结构关系先筛范围，再用语义搜索补充说明，而不是让 embedding 独自决定影响面。

先把基准数字放回方法里

项目 README 当前公布的 6 个真实开源仓库评测，报告中位每问题 token 减少约 65 倍，范围约 36 到 376 倍；影响分析平均 F1 约 0.693。这个数字有价值，但不能直接写成“质量不变”。全库语料对比是上界式基线，影响分析的部分 ground truth 又来自图谱本身，召回率存在循环性。更诚实的结论是：CRG 很擅长降低结构化检索的上下文成本，但仍需用真实团队的漏检样本验证审查质量。

本地优先不等于没有边界

图谱默认保存在项目的 .code-review-graph/ 目录，项目声明 MIT 和零遥测。可选 embedding 仍然涉及外部模型端点，团队要明确哪些摘要、标识符和文档信息可以离开本机。GitHub Action 虽然在 runner 上构建和查询图谱，也要检查 fork PR、权限和缓存策略，不要把“源码不上传”误解成整个流水线没有数据风险。

最小试用路径

pipx install code-review-graph
code-review-graph install --platform claude-code
code-review-graph build
code-review-graph status
code-review-graph detect-changes --brief
code-review-graph serve

第一次不要直接打开自动合并门禁。先选一个有测试的中型仓库，对比三组结果：人工指定的影响文件、CRG 返回的范围、Agent 最终实际读取的文件。记录漏掉的调用者、误报的依赖、索引耗时和每次审查 token，再决定是否启用 watch、MCP 或 fail-on-risk。

它适合放在哪一层

• 适合作为 AI Coding 前的代码地图和影响面预筛选。
• 适合作为 PR 的风险提示与测试缺口辅助，而不是自动批准器。
• 适合本地优先、不能把源码交给云端索引服务的团队。
• 不适合把结构图当成业务正确性证明；并发、配置、数据质量和运行时路径仍要靠测试与 review 验证。

CRG 真正有意义的地方，是把“模型应该先读什么”从一句提示词变成了可复查的工程步骤。它减少的不是所有 AI 成本，而是无边界阅读造成的浪费。采用前最该问的也不是 token 能省多少，而是漏检一个真实依赖时，团队是否有第二道门把问题挡住。