你让 Claude Code review 一个 commit。它开始读文件，读着读着把整个 FastAPI 仓库翻了一遍，两千多个文件，大部分跟你的改动毫无关系。你付了这些 token，质量还更差。这事儿每个用 AI 编程工具的人早晚会撞上。
Tirth 做 code-review-graph 的动机就是这个。他在 HackerNews 自己写的原话：受够了每次任务看着 Claude Code 把整个代码库重读一遍。这个仓库 2026 年 2 月才建，到 8 月底已经 30,924 个 Star，半年冲到这个数，不是靠营销，是靠戳中了一个真痛点。
它的思路不花哨：用 Tree-sitter 把代码库解析成一张结构化的持久图谱，存进本地 SQLite。改了什么、影响了什么，AI 直接查图，只读相关文件。README 自己标的中位数节省是约 65 倍 token，最好的仓库能到 376 倍。数字凶，但得看怎么来的。
这篇文章不打算帮你决定要不要 star。它想讲清楚一件事：这张图到底能不能让你的 AI 编程 Agent 真的变聪明，还是只是省了几次 grep 调用。往下翻。
核心亮点
最打动我的是它的本地优先不是嘴上说说。图谱是一份 .code-review-graph/ 下的 SQLite 文件，没有外部数据库，没有云服务，零遥测。GitHub Action 也在你的 CI runner 本地跑，源码不出机器，这点对企业用户很关键。把整条数据处理链路摊开看，从仓库进来到吐出最小审查集，其实就五层结构：
仓库进 Tree-sitter 解析，落进 SQLite 图，分析层算爆炸半径，最后通过 MCP、CLI、Action 吐出最小审查集。每一层都本地、都增量，没有一环依赖外部服务。
增量更新是日常路径，不是噱头。初始构建是一次性成本：500 文件项目约 10 秒，django 约 3000 文件冷构建 40 秒。之后的更新只重解析 hash 变了的那些文件，双文件改动约 2.5 秒。PostEdit、PostGit 钩子和 watch 模式让图谱跟着你的改动走，不用手动重建。
爆炸半径分析是真正值钱的功能。它不只回答谁调用了这个函数，而是算出改了 A 会影响 B、C、D 哪些文件。对改了这里会不会炸这种高频问题，比 grep 强一个量级。配合 Leiden 社区检测和 betweenness centrality，还能标出枢纽文件和桥接文件。
接入面铺得很开。MCP Server 接 Claude Code、Cursor、Codex、Gemini CLI 等 15 个以上平台。CLI 直接跑命令。GitHub Action 在 PR 上贴风险评分，还能 fail-on-risk 当合并门。30 个 MCP 工具加 5 个 prompt 工作流模板，基本把让 AI 用图的入口填满了。
可视化也不缺。D3.js 力导向图能让你肉眼看代码库的结构。Hub、Bridge 检测、Surprise 评分、知识缺口分析、Wiki 生成、图谱 diff、导出 GraphML、Neo4j、SVG、Obsidian，这些不是核心但说明作者想把工具做成平台，不是一次性脚本，这也是它比一堆一次性 AST 脚本高明的地方。
诚实度是它最反常规的地方。README 把 recall 1.0 标成图导出的循环上界，把最好的 528 倍标成 best case，中位数才是主打。小文件改动的净负开销也写进文档。这种透明度在开发者工具里罕见，后面还会看到它怎么在代码层面兑现。不过设计讲再多，上手顺不顺才是真问题，直接跑一遍就知道了。
快速体验
上手比想象简单。Python 3.10 以上，推荐用 uv。三步进项目：装包、install 自动探测并配置你的编辑器、build 解析代码库。之后就是无感使用，Agent 自动查图，你基本不用再管它。
pip install code-review-graph
code-review-graph install
code-review-graph build
接 MCP 最省事。以 Claude Code 为例，install 会写进配置，之后 Agent 每次 review 自动先查图谱。也可以当 Claude Code 插件加：claude plugin add tirth8205/code-review-graph。不想绑编辑器的，纯 CLI 路线也完全走得通。
想看它到底省了多少 token，跑下面这个面板最直接。detect-changes --brief 只读节省数字，完全不碰模型，也不会触发任何网络请求：
code-review-graph detect-changes --brief
真实输出长这样（README 示例）：一个中等 PR 就能砍掉约九成上下文，这是官方给的示例数字。
你自己的仓库大概率没这么夸张，但省的方向一致。多仓库就起守护进程：code-review-graph daemon start，后台持续维护多张图，不用每次手动更新。
可选语义搜索另说。默认不开，开了用 sentence-transformers、Gemini、Voyage 这类嵌入端点，向量 blob 也存进同一个 SQLite 文件，不另起向量库。多数人先用纯结构边就够了，嵌入是加分项不是前提。
一个小提醒：build 完第一次会有几十秒到几分钟的安静，大仓库更久。这不是卡死，是它在索引。别像我一样手贱按了 Ctrl-C，重跑一次又得等一遍。不过体验顺了，也别急着全量铺开，它到底适合谁、不适合谁，得先划清楚。
适用场景与局限
它不是万能药，先别问值不值得买，先问适不适合你。下面这张表把适用面摊开，比我嘴讲清楚：
| 场景 | 推荐度 | 原因 |
|---|---|---|
| 中大型仓库日常 review | ⭐⭐⭐⭐⭐ | 精准定位影响范围，token 节省最明显 |
| Spring / Java 项目 | ⭐⭐⭐⭐⭐ | 专用 Spring DI 解析器，识别 @Autowired 注入边 |
| 多语言混合项目 | ⭐⭐⭐⭐ | Tree-sitter 覆盖 30 多种语言 |
| 小仓库（少于 50 文件） | ⭐⭐ | AI 盲读也快，建图净负 |
| 纯动态语言项目 | ⭐⭐⭐ | 静态分析对 getattr、eval 有盲区 |
局限要直说。动态语言（Python 的 getattr、JS 的 eval）它搞不定，静态分析的天花板它一样撞。图谱只建结构关系，不懂业务语义，它知道 A 调用 B，不知道 A 和 B 在业务上啥关系。
小改动会反噬。仓库很小或 diff 只动一个文件时，图查询的元数据开销可能比直接读文件还贵。README 没藏这个，express 仓库的实测数字就说明了。这也是为什么我说小项目别急着上。
诚实的评测口径也要提醒。impact 的 recall 1.0 是图导出的循环上界，不是真百分之百召回。流检测只有 33% 的 recall，Python、PHP 强但 JS、Go 弱。语义搜索 MRR 0.35，关键词顶 4 还行，但 Express 因命名返回 0 命中。这些不是黑料，是它自己写进文档的。
如果决定试，别一上来就绑全公司。挑一个 500 文件以上、review 频繁的服务仓库做试点，先看 detect-changes 的节省面板，再决定要不要铺开。Spring 或 Java 栈收益最稳，因为有专用的依赖注入解析器兜底。回到能用在哪这件事，下一个更现实的问题是：这项目到底能不能信，维护靠不靠谱。
社区健康度
数据先摆：30,924 Star、2,813 Fork、115 个 open issue、99 个 subscriber，协议 MIT，2026 年 2 月 26 日建仓，到 8 月底还在高频更新。单维护者 tirth8205，但有 Claude 和 dependabot 大量辅助提交。Bus factor 是个绕不开的风险点。
| 指标 | 数值 | 解读 |
|---|---|---|
| Stars | 30,924 | 半年涨到这个数，增速异常 |
| Forks | 2,813 | fork 比率高，说明真有人想改它 |
| Open Issues | 115 | 含 PR，绝对数不高 |
| 协议 | MIT | 商用友好 |
| 最近提交 | 2026-08-27 | 活跃，没养老 |
维护响应是真快。v2.3.8（2026 年 8 月 21 日）一个 patch 就合了 85 个 PR，绝大多数来自社区报告。release note 里直接点名修的 issue 编号：#811、#889、#849、#892。这种把 issue 焊进 changelog 的习惯，比 star 数更说明问题。
也有真实的摩擦。HN 上有人回帖说：I tried installing it using the recommended option, via Claude, it didn’t work. I opened an issue and I’ve added what I have tried and what errors I did encounter. 通过 Claude 一键安装这条路，至少有人踩空了。我看 install 的报错谱，配置类问题居多，不是致命伤，但说明三步上车对部分平台没那么丝滑。
透明度加分。v2.3.8 还修了一个尴尬的 bug：#849 发现 get_affected_flows 在一个标注 5 次工具调用、800 token 的工作流里吐了 24.7 万 token。作者没遮，把全部 30 个工具的响应都量了一遍，给每个列表加了硬上限。这种自己打自己脸还公开的做派，在 AI 工具里不多见。说到社区和代码都翻过的现在，该下判断了：它值不值得你跟，什么时候跟。
洞察与判断
跟同类工具比？FAQ 里它自己列了对标：LSP、RAG、grep、Serena、codegraph、claude-context、repomix。一句话定位：LSP 单语言符号精度高但跨语言无图，RAG 靠相似度分块丢失结构边，grep 只能单跳。CRG 的差异化是一张持久的跨语言结构图加多跳查询。把它和几个常被拿来比的工具摆一起看：
横向看，CRG 的核心牌是跨语言结构图加多跳查询。LSP 符号精度高但跨不了语言，RAG 丢了结构边，grep 只能单跳。它站在这三者中间，既不是 ctags 2.0，也不是 RAG 平替。
我的判断是：它不是 ctags 2.0，也不是 RAG 平替。ctags 不解析调用图和继承，RAG 不保留 AST 结构边。CRG 站在这俩之间，用静态结构代替猜测。但把它当 AI 编程银弹的会失望，它解决的是读什么不是怎么改。
值不值得跟？对中大型、多文件、频繁 review 的团队，我给明确信号：值得接。三步安装，之后 Agent 自动查图，边际成本几乎为零，省下的 token 和噪声是实的。小项目、单文件 diff 为主的工作流，先别上，净负。
坑点再说实一点的。watch 模式曾经最弱，v2.3.8 前三种失败能让 daemon 报 ok 但图停更。现在修了，但用大 node_modules 的仍要注意 inotify 预算。语义搜索默认关着是对的，开了就要接嵌入端点，对离线、隐私场景是额外负担。
趋势上我偏乐观。半年 3 万 star，作者几乎周更，社区 PR 占比高，文档透明度罕见。风险在 bus factor：核心还是一个人。一旦作者精力掉档，fork 多能续命，但方向共识会散。这点我保留观望。
一个我愿意下注的猜测：AI 编程工具的下一层竞争，不在模型而在上下文工程。谁先把该读什么算对，谁就省真金白银。CRG 踩的位置正好，但同类会快速涌现，它能不能从工具变成标准，看接下来半年的生态绑定。顺便说个观察：它现在最该防的不是功能不够，而是被大厂集成吞掉。Cursor、Claude Code 都在做自己的上下文层，CRG 要么成为默认图谱后端，要么退成被复用的库。前者那条路的窗口就在接下来半年，错过就只剩被复用的命。
资源地址
-
GitHub：https://github.com/tirth8205/code-review-graph -
官网：https://code-review-graph.com -
PyPI：https://pypi.org/project/code-review-graph/ -
文档：仓库内 docs/（Usage、Commands、FAQ、Reproducing benchmarks、Roadmap） -
Discord：https://discord.gg/3p58KXqGFN -
基准复现：https://github.com/tirth8205/code-review-graph/blob/main/docs/REPRODUCING.md
总结
一句话：code-review-graph 解决的是 AI coding 里会随仓库变大而持续恶化的真问题，且用最务实的工程手段（SQLite 不是图库、增量不是全量、诚实基准不是营销）。中大型项目值得现在就接。
但别神化它。单维护者、小项目净负、动态语言盲区，这三件事决定它不是人人适用。先拿你最大的那个仓库跑一遍 build，看 detect-changes 的节省面板，数字会替你做决定。
我给它的评价比社区平均分低一点，但比一小时前的预期高很多。这叫诚实。