GitHub 上有个项目，标语只挂了一句："Stop burning tokens. Start reviewing smarter."（别再烧 token 了，开始更聪明地审查。）仓库 tirth8205/code-review-graph，到 2026 年 7 月 29 日已经攒了 27401 颗星、2536 个 fork，Python 写的，MIT 协议，2026 年 2 月 26 日创建，最新版本是 7 月 18 日发布的 v2.3.7。它干的事一句话能讲明白：用 Tree-sitter 把代码库解析成一张知识图谱，再通过 MCP 把"刚好够用"的上下文喂给 AI 编程助手，让它别再把整个仓库从头读一遍。官方在 6 个真实仓库上测下来，token 节省从 38 倍到 528 倍，单次提问平均少烧约 93 倍。
一、痛点：AI 编程助手烧 token 烧错了地方
用过 Claude Code、Cursor 这类 coding agent 的人多半撞过这堵墙：你问一句"这个函数被谁调用了"，它先把整个仓库读一遍，几千上万 token 进去，答案还不一定准。代码库一大，每次提问都像让助手重新通读一遍《辞海》，只为回答你一个字。
背后是两个具体的浪费。第一，agent 不知道你改的那几行到底牵连谁，只好把"可能相关"的文件一股脑塞进上下文。monorepo 里动辄几万文件，真正和这次改动相关的可能就十几个，剩下的全是噪声。第二，每次改动后重新索引成本高，助手要么不更新，拿着过时的上下文瞎猜；要么暴力重读全库，token 像流水一样花。结果就是三件事一起坏：token 烧得快、代码审查不准、长任务动不动超窗口。code-review-graph 冲的就是这两处浪费，把代码结构化成图，改了哪儿就只让 AI 看哪儿。
这不是一个"让模型更聪明"的工具，它干的是更朴素的活：在模型开口之前，先把该看的、不该看的分清楚。模型再强，喂进去的是噪声，它也只能在噪声里找答案。
二、它干什么：Tree-sitter 解析成图，MCP 精准投喂
底层是 Tree-sitter 解析加 SQLite 存储。Tree-sitter 把每个源文件解成抽象语法树（AST），从中抽出节点和边：节点是函数、类、导入这些代码实体，边是它们之间的关系，比如谁调用了谁、谁继承了谁、哪段测试覆盖了哪段业务代码。这些关系不是每次提问现算的，而是预先结构化、存进一张 SQLite 图谱，随时可查。
输出方式是 MCP（Model Context Protocol）。它把这张图接成一个 MCP 服务器，AI 助手就能像调用其它 MCP 工具一样，按需查询图谱，而不是把整个代码库塞进上下文窗口。增量这部分也跟踪了：哪些文件改过、哪些节点失效，图谱记着，只重新解析变动的部分。最终给到 AI 的，是"该读的读到、不该读的一字不看"的最小上下文。
这套架构有两个实在的好处。图谱是本地 SQLite，数据不出仓库，对隐私敏感的团队友好；投喂走标准 MCP，凡支持 MCP 的 agent 都能接，不绑死某一个工具，你今天用 Cursor、明天换 Claude Code，图谱还在那。存储选 SQLite 而不是某个图数据库，也是为了零依赖、装上就能跑，不用再起一个服务。
三、38x 到 528x：六个仓库的真实数字
最能说明问题的是它敢放实测数字。官方在 6 个真实代码仓库上跑，token 节省从 38 倍到 528 倍不等。最直观的是单次提问的对比：不走图谱时一次提问要吃掉 208821 个 source token，走图谱后返回的响应只用约 2495 个 token，省了大约 93 倍。
这两个数字的差距（38x 到 528x）本身就在传递信息：节省幅度强依赖代码库形态。文件之间耦合越深、调用链越长、monorepo 里无关文件越多，图谱能排除的"噪声上下文"就越多，倍数就越大。反过来，一个小而扁平的项目，本来要读的就不多，节省空间自然小。所以别把 528x 当成对所有人的承诺，它更像是"最该上这套东西的场景能省到什么程度"的上限示意。但即便是下限的 38 倍，对天天和 agent 搏斗的人来说也够实在了。
要注意这组数字测的是"上下文投喂"这一环的节省，不是端到端说你的 API 账单直接打一折。真正能省多少，取决于你提问的频率、代码库的耦合程度、以及 agent 原本有多依赖全量读库。但方向是确定的：把噪声挡在上下文之外，token 必然少花。
四、Blast-radius：改一个文件，只让 AI 读该读的
它有个核心功能叫 blast-radius 分析。逻辑是这样：当你改了某个文件，它顺着图谱往回追溯，找出所有受影响的调用方、依赖、以及相关测试，然后只把这些塞给 AI。AI 不再是"全库扫一遍找关联"，而是拿着一张明确的受影响清单干活，既省 token，审查也准。
monorepo 场景最能体现这个价值。官方给的数据：一个 27700 多文件的 monorepo，blast-radius 把无关文件排除出审查上下文后，AI 实际只读了大约 15 个文件。从两万七到十五，这就是图谱相比"全量喂上下文"的差距。换句话说，agent 原本要消化的信息量被砍掉了三个数量级，这对 token 账单和审查准确性都是直接的提升。
blast-radius 解决的其实是个老问题：改动影响面分析。以前这事靠人脑或者静态分析工具做，做完还得人去把结果喂给 AI。现在图谱把这一步自动化了，AI 拿到的不再是"整个仓库"，而是"这次改动真正波及的那张子图"。
五、增量与保鲜：两秒重索引，watch 加 hooks
图谱建好只是开始，能不能跟上代码变动才是关键。增量更新这块它给的数据是：2900 文件的项目重新索引只要不到 2 秒。这意味着你每次提问前，图谱都是新鲜的，AI 拿到的是当前代码状态，而不是上次 build 时的快照。
保持新鲜靠两个机制：watch 模式和 git hooks。watch 模式盯着文件系统，你一保存，它就地增量更新受影响的那部分图谱；hooks 则卡在 git 提交这些节点上，让图谱跟着代码流转一起更新。两条路都是为了同一个目的：不让图谱和真实代码脱节。
这点比那种"建一次图用半年"的工具实在。脱节的图谱比没有图谱更危险，因为 AI 会带着错的关联自信地胡说。两秒一次的增量更新，把"图谱过时"这个隐患压到了几乎可以忽略的程度。
六、三步上手，15+ 平台与对称卸载
pip install code-review-graph
code-review-graph install
code-review-graph build三步搞定。第一步装包；第二步 install 会自动检测你机器上装了哪些 AI 编程工具，把 MCP 接入配好；第三步 build 把当前仓库解析成图谱。它自动支持的平台官方列了 15 个以上：Codex、Claude Code、CodeBuddy Code、Cursor、Windsurf、Zed、Continue、OpenCode、Antigravity、Gemini CLI、Qwen、Qoder、Kiro、GitHub Copilot（VS Code 版和 CLI 版都行）。你不用挨个去改每个工具的 MCP 配置文件，install 一把梭。
初始构建不算慢：500 文件的项目大约 10 秒建完。环境要求 Python 3.10 以上，官方推荐用 uv（uvx）跑，避免污染全局环境。卸载也设计成了对称的，code-review-graph uninstall 支持 --dry-run（先预览会删什么再决定）、--yes（跳过确认）、--all-repos（所有仓库一起清）、--keep-data（保留图谱数据只删接入配置）。重点是它只删自己创建的 MCP 和 hook 配置，不动你别的工具留下的东西。这点对装了一堆 MCP、生怕一个 uninstall 把全家配置带走的人，是个实在的工程克制。
七、语言覆盖有多广，自定义 grammar 留口子
语言侧，Tree-sitter 能解析它就能覆盖。官方列了一长串：Python、JavaScript、TypeScript、TSX、Go、Rust、Java、C、C++、C#、Ruby、Kotlin、Swift、PHP、Scala、Solidity、Dart、R、Lua、shell、Elixir、Zig、PowerShell、Julia，外加 Vue 和 Svelte 的单文件组件、Astro，还有 Jupyter 和 Databricks notebook。后端、前端、移动端、智能合约、数据脚本基本都吃，覆盖面在同类工具里算很宽的。
遇到 Tree-sitter 没现成语法的语言，它留了口子：在仓库里的 .code-review-graph/languages.toml 写自定义语言映射，自己接 grammar。冷门语言或自研 DSL 不会被一棍子打死，但代价是你得自己维护这套映射，有学习成本。平台侧前面说了 15+，存储侧是 SQLite 加 Tree-sitter，纯本地、图谱数据留在你仓库里。社区方面，官网 code-review-graph.com 有文档，Discord 有讨论区，Trendshift 榜上也挂着，MCP 协议兼容。
八、适合谁，局限在哪
适合的人很清晰：代码库偏大、用 coding agent 频繁、token 成本敏感或老撞上下文窗口的开发者；monorepo 维护者；做大规模代码审查、需要追踪改动影响面的团队。Python 3.10+ 的门槛对多数人不是问题，uv 一行命令就装好。
局限也得讲明白。第一，语言覆盖虽广但仍有边角，冷门语言或自研 DSL 要自己配 grammar，有维护成本。第二，初始构建对超大仓库（几万文件级）需要等一会，虽然增量更新快，首次全量解析还是要花时间，不是零等待。第三，装完 MCP 后多数编辑器要重启才能识别新工具，第一次配完记得重启。第四，也是最根本的，它解决的是"上下文范围"问题，不是"模型能力"问题：模型本身理解错或产生幻觉，图谱帮不上。把它当成给 AI 戴了一副"只看该看的"眼镜，而不是给 AI 换了个脑子。
code-review-graph 不复杂，复杂的是把代码结构化成图之后怎么持续保鲜。装上、build 一遍，省的是你每次提问让 AI 通读全库的 token 和等待时间。想知道自己项目能省多少，最直接的办法是拿官方那套对比方式在自家仓库跑一次：记下走图谱前后的 token 消耗，数字会替它说话。本周它还在涨星，迭代不慢，上线前建议锁版本号。
参考来源
- code-review-graph GitHub 仓库（27401 star / 2536 fork，MIT，Python）：https://github.com/tirth8205/code-review-graph
- PyPI 包（pip install code-review-graph）：https://pypi.org/project/code-review-graph/
- 官网与文档：https://code-review-graph.com