夜雨聆风
一个有意思的现象：AI 编程工具越来越强，但用起来越来越贵。
Claude Code、Cursor 这些工具确实好用，但每次对话都要重新读一遍代码库。改一个函数，AI 把整个项目翻个底朝天。几千个文件的项目，一次对话烧掉几万 token 很正常。一个月下来，光 token 费用就是一笔不小的开支。
问题的根源不在于 AI 不够聪明，而在于它"看"代码的方式太笨了——每次都从零开始，没有记忆，没有全局视角。
GitHub 上有个项目叫 code-review-graph，12.3k star，思路很巧妙：给 AI 装一张代码的"地图"，让它只看该看的地方。
AI 读代码的笨办法
先说清楚问题到底出在哪。
传统方式下，AI 助手处理一个代码任务，比如"审查这个 PR 的改动"，它会怎么做？把相关文件全读一遍。但"相关"怎么定义？AI 不知道，保险起见，全读。
这就好比你问同事"这个 bug 怎么修"，同事把整个代码库从头到尾看了一遍才回答你。效率低不说，还贵——每个文件都要消耗 token。
更离谱的是，改的是登录模块的密码加密逻辑，AI 把支付系统、数据分析、前端组件全读了一遍。这些代码跟改动八竿子打不着，但 AI 没办法，它不知道哪些有关、哪些无关。
code-review-graph 的思路：先建图，再查图
这个项目的核心思路可以拆成两步。
第一步，把代码库变成一张图。用 Tree-sitter 解析代码，生成抽象语法树（AST）。然后把 AST 转成图结构——函数、类、导入语句是节点，调用关系、继承关系、测试覆盖是边。整张图存在 SQLite 里。
这相当于给代码库建了一份"关系地图"。谁调用了谁、谁继承了谁、谁测试了谁，一目了然。
第二步，查图，只读该读的代码。AI 要做代码审查时，先查这张图：改动涉及哪些文件？这些文件的调用者是谁？依赖项有哪些？测试覆盖到没有？查完之后，拿到一个最小文件集合，只读这些就够了。
整个过程通过 MCP 协议（Model Context Protocol）完成。AI 助手调用图工具，拿到影响范围和风险评分，然后精准读取。
爆炸半径：一个从物理学借来的概念
这个项目最核心的机制叫"爆炸半径分析"（Blast-radius analysis）。
术语来自物理学。炸弹爆炸，冲击波扩散的范围就是爆炸半径。代码改动也一样——改了一个函数，影响会向外扩散：调用这个函数的代码受影响，调用那些代码的代码也受影响，一层一层往外推。
code-review-graph 做的事情，就是在改代码之前，先算清楚这个爆炸半径有多大。半径内的文件才需要 AI 关注，半径外的不用管。
举个例子：改了 parser.py 里的一个函数。图会追踪所有调用这个函数的代码、依赖这个函数的测试、继承相关的子类。可能牵扯出 15 个文件，而不是整个项目的 27,700 个文件。
数据说话：到底能省多少
有人做了实测，测试仓库是 code-review-graph 自己（174 文件，3107 节点，22227 边）。
几个关键场景的数据：
影响半径分析——传统方法消耗 99,375 token，Graph 方法只消耗 99 token。节省 99.9%。这是价值最大的场景。
架构探索——传统方法 87,769 token，Graph 方法 1,259 token。节省 98.6%。
查找调用者——传统方法 2,066 token，Graph 方法 449 token。节省 78.3%，而且速度快 5.7 倍。这是唯一在速度和 token 上双重优化的场景。
代码审查——传统方法 335 token，Graph 方法 289 token。节省 13.7%。
官方给的总账：代码审查场景 token 减少 6.8 倍，日常编码任务最高减少 49 倍。49 倍是什么概念？原来 1 块钱的对话，现在 2 分钱。
两个让体验不掉链子的机制
光能省 token 还不够，用起来不能太麻烦。code-review-graph 有两个机制保证了实际体验。
增量更新，2 秒以内。文件保存或 commit hook 触发增量更新，用 SHA-256 哈希做差分，只重新解析变更过的文件。2900 个文件的项目，重建索引不到 2 秒。用起来基本感觉不到延迟。
Monorepo 漏斗过滤。大型 Monorepo 项目动辄几万文件，漏斗过滤能把 27,700+ 文件排除在审查上下文之外，实际只读约 15 个文件。对 Monorepo 场景来说，这个过滤能力是刚需。
三行命令装好
安装过程很简单：
pip install code-review-graphcode-review-graph installcode-review-graph build需要 Python 3.10 以上。install 命令会自动检测已安装的 AI 编码工具，为每个工具写入正确的 MCP 配置，还会把图感知指令注入平台规则。
支持的工具：Codex、Cursor、Claude Code、Gemini CLI、Kiro、GitHub Copilot。主流 AI 编程工具基本都覆盖了。
什么场景值得用
不是所有项目都需要。几个判断标准：
项目够大。文件越多，省的 token 越多。几百个文件的小项目，传统方法可能更快，因为图方法首次调用有初始化开销。几千个文件的大项目，收益就开始明显了。
AI 用得勤。每天跟 AI 对话几十次的话，一个月省下来的费用相当可观。偶尔用一次的，没必要折腾。
有代码审查需求。PR review、CI/CD 自动化审查，这些场景每次都要 AI 读代码，token 消耗大，省钱效果最明显。
Monorepo 项目。几万文件的项目，漏斗过滤的价值能充分体现。
客观说几个不足
首次调用有初始化开销。小项目上，传统方法可能更快。这点官方也承认，实测数据里标注了。
Tree-sitter 虽然支持很多语言，但一些小众语言或新出的语言，解析可能不够完善。用之前最好确认一下自己的技术栈是否被良好支持。
另外，工具本身需要 Python 环境。纯前端团队或非 Python 技术栈的团队，部署门槛会高一点。
背后的趋势
code-review-graph 反映了一个更大的趋势：AI 编程工具正在从"通用助手"向"理解上下文的助手"演进。
早期的 AI 编程工具，就是把代码喂给大模型，模型回答。简单粗暴，但 token 消耗惊人。后来有了 RAG（检索增强生成），能检索相关文档。再后来，像 code-review-graph 这样的工具，开始构建代码的结构化知识图谱，让 AI 真正"理解"代码的关系网络。
这个方向走下去，AI 编程工具会越来越像一个真正懂你项目的同事，而不是每次都要从头介绍项目背景的实习生。
写在最后
code-review-graph 解决的问题很具体：AI 编程工具的 token 浪费。解决手段也很清晰：用 Tree-sitter 建代码知识图谱，通过爆炸半径分析让 AI 只读相关代码。效果数据摆在那，影响半径分析场景 token 节省 99.9%，日常编码最高省 49 倍。
开源、MIT 协议、三行命令装好。大型项目上重度使用 AI 编程工具的，值得试试。
GitHub 地址：github.com/tirth8205/code-review-graph
