我用一个2.7万星的开源工具做代码审查，AI终于不再通读整个代码库了

code-review-graph 把代码变成一张图，让 AI 只读该读的部分，token 消耗中位数减少 82 倍

前几天我在 GitHub Trending 上刷到一个项目，名字很直白：code-review-graph。          它的 slogan 更直白：Stop burning tokens. Start reviewing smarter.          我花了一下午把它搭在一个自己的项目里试了试，结论有点反常识——AI 代码审查最大的瓶颈，可能不是模型不够聪明，而是它读了太多不该读的东西。

发生了什么：有人把代码库画成了一张图

code-review-graph 是一个今年 2 月才创建的 Python 项目，到今天已经拿了 27,774 个 Star，MIT 协议完全开源。          它的核心思路很简单：代码从来不是一堆文件，而是一张图。          函数调用函数，类继承类，模块导入模块，测试覆盖功能。这些关系本来就存在，只是以前没有被结构化地提取出来。code-review-graph 用 Tree-sitter 把代码库解析成一张知识图谱：函数、类、导入、调用、继承、测试覆盖，全部变成节点和边，存在本地的 SQLite 里。          当你改了一个文件，它不会把整份代码塞进 AI 的上下文窗口，而是先算一遍「影响半径」：这个函数被谁调用？哪些测试会受影响？依赖链往哪传？然后只把这些真正相关的内容喂给 AI。          项目作者在 README 里放了一组实测数据：在 6 个真实开源仓库上，用图引导的上下文比「无脑读全库」平均少了 82 倍 token，最高在 FastAPI 上做到 528 倍。换句话说，以前 AI 可能要读近 100 万个 token 才能回答的问题，现在 2000 个 token 就够了。          更夸张的是更新速度。一个 2900 文件的项目，首次建图之后，每次增量更新不到 2 秒。

为什么重要：大家都在比窗口大，它在比读得准

2026 年的 AI 编程工具竞争，基本都在围绕一个数字打转：上下文窗口。          Claude 做到 100 万 token，Gemini 做到 200 万，OpenAI 也不断往上堆。厂商发布会上的 PPT，几乎都把「能读更多代码」当成核心卖点。          但这里面有个被忽略的问题：窗口大，不等于读得准。          想象一下，你问 AI「我改了 login 函数，会不会影响支付流程」。如果 AI 把整个代码库 10 万行全读一遍，它理论上能找到答案，但成本极高，而且大量无关信息会稀释注意力。如果它只读关键词搜索到的几个文件，又可能漏掉间接调用。          code-review-graph 的解法不是堆窗口，而是做「结构化上下文」。它让 AI 知道代码的结构关系，而不是在文本堆里猜。          它通过 MCP 协议接入了 14 个以上的 AI 编码平台，包括 Claude Code、Cursor、OpenCode、Codex、Windsurf 这些主流工具。安装后，AI 会自动调用它的 30 个工具：查询调用者、算影响半径、找架构热点、生成审查问题……等于给 AI 配了一张代码地图。          还有一个我很看重的点：它是 local-first。所有数据存在本地 SQLite，不会把代码上传到任何第三方服务器。对在乎代码隐私的团队来说，这是默认就成立的信任基础。

我实际用下来的感受

我在一个几百文件的中型项目里试了一下。          初始化建图大概 10 秒左右，之后每次改文件它会自动增量更新。最直观的感受是：做代码审查时，AI 不再频繁问「这个函数在哪里被调用」「这个改动会影响哪些测试」——因为图里已经标好了。          举个例子。我改了一个权限校验的中间件，放在以前，AI 要么要我手动贴相关文件，要么自己读一堆无关模块。用了 code-review-graph 之后，它直接返回 6 个调用这个中间件的路由文件和 3 个对应的测试文件，上下文精简到原来的几十分之一。          但我也发现了它的边界。          第一，如果是单文件的小改动，建图本身的开销可能超过收益，适合用在有一定规模的项目上。          第二，它的流检测（execution flow）召回率目前在 33% 左右，Python 和 PHP/Laravel 效果最好，JavaScript 和 Go 还需要改进。          第三，语义搜索的排序还有优化空间，top-4 能找到正确结果，但排第一的概率不高。          这些都不是硬伤，而是明确在 README 里列出来的待优化项。一个开源项目愿意把短板摊开讲，反而让我觉得更可靠。

这意味着什么

我觉得 code-review-graph 代表了一个正在成型的趋势：AI 编程工具的下一个战场，不是更大的模型，而是更好的上下文工程。          模型层会越来越同质化。GPT、Claude、Gemini 之间的差距在缩小，价格也在往下走。真正拉开体验的，是你怎么把代码的「相关知识」组织好、喂给模型。          这可能意味着未来会分成两层：一层是模型本身，负责推理和生成；另一层是上下文工程层，负责理解项目结构、选择信息、管理记忆。code-review-graph 做的就是第二层。          对普通开发者来说，好消息是你不需要换掉正在用的 AI 工具。只要你的工具支持 MCP，装一个 code-review-graph 的 server，就能让现有工具变聪明一截。这有点像给 Claude Code 或 Cursor 加了一个「本地大脑」。          如果你也在用 AI 做代码审查，建议收藏这个思路。下次团队讨论「要不要买更贵的模型」时，你可以问一句：我们是不是先让 AI 少读点无关代码？

聊聊

如果只能二选一，你更愿意要一个「读得少但读得准」的 AI，还是一个「上下文窗口无限大」的 AI？          或者你已经用过类似的代码图谱工具？体验怎么样？          来评论区聊聊，我想听听你的真实看法。

— — —

📧 2291595496@qq.com | 🐙 github.com/GitOfUser | 📱 微信公众号：码律工坊 莫染记          接小程序/APP开发、UI设计兼职，欢迎邮件咨询。