code-review-graph 开源项目深度解析让 AI 读更少的代码做更准的 review做 AI Coding 的人应该都遇到过这个问题让 Claude Code 或 Cursor review 一个 PR它上来就先把整个项目扫一遍token 哗哗地烧结果改了 3 行代码它读了 30 个文件。我一直在找有没有办法让 AI「精准阅读」而不是「全量扫描」。前几天找到了 code-review-graph29K StarPython 写的实测确实有效。这篇文章讲三件事它怎么用、它怎么实现的、它到底省了多少。它解决什么问题先说一个真实场景。你改了EvaluationAgent.java里的一个方法想让 AI review 一下。传统的做法是 AI 把 Controller、Service、Repository、DTO 全读一遍搞清楚上下文再给你意见。一个中等规模的 Spring Boot 项目这些文件加起来轻松 5 万 token。但真正和这次改动相关的可能只有 3 个文件调用方AgentOrchestrator、被调用的NvcKnowledgeRepository、以及对应的测试类。code-review-graph 的思路就是先建图再按图索骥。它用 Tree-sitter 解析你整个代码库构建一个函数级别的调用关系图。AI 做 review 时不再盲读文件而是从改动点出发沿着调用链找到真正相关的代码。安装和使用整个流程三步搞定。第一步全局安装pipinstallcode-review-graph# 或者用 pipxpipxinstallcode-review-graph要求 Python 3.10。建议装一下 uvMCP 配置会自动用uvx启动比直接用code-review-graph命令更稳。第二步配置 AI 工具进入你的项目目录运行cdyour-project code-review-graphinstall--platformclaude-code它会自动做这几件事动作具体操作写 MCP 配置在项目根目录生成.mcp.json注入 hooks写入.claude/settings.json的 pre-commit hook更新.gitignore添加.code-review-graph/支持的平台很多不只 Claude Codecode-review-graphinstall--platformcursor# Cursorcode-review-graphinstall--platformcodex# Codexcode-review-graphinstall--platformwindsurf# Windsurfcode-review-graphinstall--platformgemini-cli# Gemini CLI# 还有 Zed、Continue、OpenCode、Copilot 等十几个不指定--platform会自动检测你装了哪些工具一次性全配好。第三步构建图谱code-review-graph build这个命令扫描整个项目用 Tree-sitter 解析每个文件把类、函数、调用关系存到 SQLite 里。我实际跑了一下自己的项目463 个文件Spring Boot Java 21INFO: Progress: 463/463 files parsed INFO: Spring DI resolver: resolved 743 CALLS edges in 372 Java files INFO: Loaded 2993 unique nodes, 34756 edges Full build: 463 files, 3550 nodes, 35398 edges (postprocessfull)不到 20 秒就跑完了。它还识别了 Spring 的依赖注入关系743 条边Autowired注入的 Bean 关系也在图里。日常使用构建完之后日常用法就变了。以前让 AI review 代码直接说「帮我看看这个 PR」。现在用 MCP 工具/code-review-graph:review-delta # review 自上次 commit 以来的改动 /code-review-graph:review-pr # review 整个 PR 的 diffAI 会先通过 MCP 查图谱拿到改动的影响范围然后只读相关文件而不是盲扫整个项目。还有一个 watch 模式文件保存时自动更新图谱code-review-graphwatch底层实现它是怎么建图的这部分是我觉得最有价值的。code-review-graph 的架构不复杂但每一步的设计都有讲究。整体架构MCP 协议解析 AST检测变更节点边精准上下文AI 编程工具Claude Code / Cursor / CodexMCP ServerGraph StoreSQLiteParserTree-sitterIncremental Enginegit diff代码文件git/svn影响分析BFS 权重衰减核心就三个组件Parser解析器、Graph Store图存储、MCP Server协议层。ParserTree-sitter 做语法解析解析代码用的是 Tree-sitter不是正则也不是简单的 grep。Tree-sitter 是一个增量解析器生成器能把你写的源代码变成一棵完整的抽象语法树AST。它的好处是语言无关一套逻辑处理 Java、Python、Go、Rust、TypeScript 等几十种语言增量解析文件改了一行只重新解析那一行附近的 AST 节点不用全量重跑容错性强代码有语法错误也能解析出大部分结构Parser 的核心逻辑在parser.py里做的事情是递归遍历 AST 节点根据节点类型_CLASS_TYPES、_FUNCTION_TYPES等语言特定映射提取类、函数、接口从函数体里提取调用关系谁调用了谁解析 import 语句把模块路径关联起来# 伪代码Parser 的核心逻辑defparse_file(file_path):treetree_sitter.parse(file_path)# Tree-sitter 解析nodes[]edges[]fornodeinwalk_ast(tree):ifnode.typeinCLASS_TYPES:nodes.append(extract_class(node))elifnode.typeinFUNCTION_TYPES:nodes.append(extract_function(node))# 提取函数体内的调用forcallinfind_calls(node):edges.append(CALLS(sourcefunc,targetcall))returnnodes,edges对于 Java 项目它还有一个Spring DI Resolver专门解析Autowired、Qualifier这些注解把 Spring Bean 的注入关系也建到图里。这是它比通用工具好用的关键——不只是语法层面的调用关系还理解框架层面的依赖注入。Graph StoreSQLite 存图图谱存在 SQLite 里用的是经典的「节点 边」模型节点表nodes字段说明kind节点类型File、Class、Function、Type、Testqualified_name全限定名如src/auth.py::AuthService.loginfile_path所在文件line_start/end代码行范围language编程语言community_id社区检测后的社区 ID边表edges字段说明kind边类型CALLS、IMPORTS_FROM、INHERITS、CONTAINS 等source_qualified起点节点target_qualified终点节点confidence置信度用于模糊匹配的情况用 SQLite 而不是 Neo4j 之类的图数据库是个务实的选择——零依赖、单文件、嵌入式不需要额外起服务。WAL 模式支持并发读更新图谱时不影响查询。还有一个 FTS5 全文搜索表支持按名称、文件路径、函数签名做关键词搜索不需要向量化也能做基本的语义查找。影响分析算法review 时最核心的逻辑是影响半径分析Impact Radius。从改动点出发沿调用图向外扩展找到所有受影响的节点。算法是带权重的 BFSdefget_impact_radius(seed_nodes,max_depth2):impactedset()frontierseed_nodesfordepthinrange(max_depth):next_frontierset()fornodeinfrontier:# 正向这个节点影响了谁fortargetinget_forward_edges(node):scoreedge_weight*depth_decay**depthifscoreSCORE_FLOOR:next_frontier.add(target)# 反向谁依赖这个节点forsourceinget_reverse_edges(node):scoreedge_weight*depth_decay**depthifscoreSCORE_FLOOR:next_frontier.add(source)impacted.update(next_frontier)frontiernext_frontierreturnimpacted几个设计细节深度衰减每走一步影响力乘以衰减系数。离改动点越远的节点影响力越小边类型权重不同类型的边权重不同。CALLS调用关系比REFERENCES引用关系权重高双向遍历既看下游改动影响了谁也看上游谁依赖被改的东西阈值截断影响力低于SCORE_FLOOR的节点直接丢掉避免无意义的扩散增量更新全量构建只在第一次跑。之后每次只解析变了的文件git diff找出变更文件查询图谱找到依赖变更文件的其他文件只重新解析这两部分文件更新 SQLite 里对应的行通过文件哈希判断是否需要重新解析没变的文件直接跳过。这就是为什么 watch 模式几乎零开销——保存一个文件增量更新通常在毫秒级完成。MCP Server图谱建好了AI 怎么用通过 MCPModel Context Protocol。MCP 是 Anthropic 推出的一个标准协议让 AI 工具能调用外部能力。code-review-graph 把自己注册为一个 MCP Server暴露了 30 个工具工具功能build构建/重建图谱impact查某个节点的影响半径search按名称搜索代码结构traverse沿调用链遍历review生成 review 上下文detect_changes检测代码变更hotspots找高频修改的热点区域embed计算语义向量community查看代码社区聚类AI 工具通过 MCP 协议调用这些工具拿到精准的上下文而不是自己去读文件。它到底省了多少README 里有 6 个开源仓库的基准测试数据用 5 个典型 Agent 问题测的仓库全量读取 token图谱查询 token倍数fastapi948,7932,653375.6xflask143,5942,19671.0xcode-review-graph208,8213,19068.1xgin166,8682,76661.9xhttpx142,3562,66160.6xexpress136,0523,93636.0x中位数大约 65 倍最好的情况fastapi达到 376 倍。当然这个「全量读取」是上界——实际的 AI 工具不会真的把整个项目读一遍它会 grep 关键词然后读最匹配的几个文件。code-review-graph 的 eval 里也测了这个「grep top-3」的真实基线图谱方案依然有明显优势因为它不只找到直接匹配的文件还能沿调用链找到间接相关的代码。我的实际体验在我自己的 Spring Boot 项目上463 文件、3550 节点、35398 条边构建完之后重启 Claude Code确实能感受到变化review 时读的文件少了。以前改一个 Service 方法Claude Code 会把相关的 Controller、DTO、Entity 都读一遍。现在它先查图谱只读调用链上的文件Spring DI 关系被识别了。743 条Autowired注入的边意味着 AI 能理解 Bean 之间的依赖不只是方法调用增量更新快。开启 watch 模式后改一个文件保存图谱更新几乎无感也有一些局限对动态语言Python 的getattr、JavaScript 的eval的支持有限静态分析搞不定的东西它也搞不定图谱只建了结构关系不理解业务语义。它知道 A 调用了 B但不知道 A 和 B 在业务上是什么关系首次构建对大项目10 万 文件可能需要几分钟适用场景场景推荐度原因中大型项目的日常 Code Review⭐⭐⭐⭐⭐精准定位影响范围token 节省最明显Spring/Java 项目⭐⭐⭐⭐⭐专门的 Spring DI 解析器多语言混合项目⭐⭐⭐⭐Tree-sitter 支持几十种语言小项目50 文件⭐⭐收益不大AI 盲读也很快纯动态语言项目⭐⭐⭐静态分析有局限但 import 和基本调用还是能解析总结code-review-graph 的核心思路其实很简单用图谱代替盲读用结构代替猜测。它不做魔法就是老老实实地用 Tree-sitter 解析代码、建图、存 SQLite然后通过 MCP 协议暴露给 AI 工具。整个设计很工程化——SQLite 而不是图数据库、增量更新而不是全量重建、权重衰减 BFS 而不是复杂的图算法。如果你的项目超过几百个文件AI 做 review 时经常「读了一堆没用的文件」这个工具值得试试。三步安装构建一次之后就是无感使用。项目地址https://github.com/tirth8205/code-review-graph