用 AI 审代码的人都有过这种体验。让 Claude Code 看一个 PR它开始读文件——一个接一个越读越多。你盯着 Token 计数器往上涨但仔细一看它读进去的文件一大半跟这个 PR 没关系。code-review-graph 做了一件事给代码库建一张结构图谱让 AI 只读该读的部分。它不是又一个 AI 编程助手。它是给现有助手装上的精准上下文引擎。它不替代 Claude Code 或 Cursor而是让它们不再把整个仓库当上下文往里灌。怎么做到的理解它的原理只需要一句话用 Tree-sitter 把代码解析成 AST把函数、类、导入变成节点把调用关系、继承关系、测试覆盖变成边存进本地的 SQLite 文件。当你改了一个文件图会沿着边追踪——谁调了这个函数这个类的子类是谁哪些测试覆盖了这段逻辑这就是它说的爆炸半径。AI 只需要看爆炸半径内的文件而不是整个仓库。它的基准测试数据让人印象深刻。6 个仓库的中位数每次问题 Token 减少约 82 倍。fastapi 仓库的单次最佳成绩是 528 倍原本需要 95 万 Token 的上下文压缩到 2,169 个。在自己的仓库上跑也达到了 93 倍。即便是基准测试里表现最差的 httpx 仓库也有 38 倍的降幅。不过要注意528 倍是极端最佳情况不是日常典型值。README 自己也坦诚了这一点。实际使用非常简单。装完 Python 3.10 以上的环境两条命令就能跑起来pip install code-review-graph code-review-graph install code-review-graph buildinstall 命令会自动检测你装了哪些 AI 工具——Claude Code、Cursor、Codex、CodeBuddy Code、Gemini CLI、Copilot 等 16 个平台它都认识。build 命令开始解析代码库500 个文件的项目大概 10 秒完成。之后的增量更新更快一个 2,900 文件的项目重新索引不到 2 秒。因为是纯本地运行不需要任何外部数据库或云服务图谱数据就存在项目目录下的 SQLite 文件里。用它之后的工作流变成这样在 AI 助手里对项目说一句Build the code review graph for this project或者在 PR 中触发审查图就会返回爆炸半径和风险评分。AI 拿到的是精选过的文件列表而不是全仓库。跟同类方案比它的定位很清晰。LSP 语言服务器在单符号级别的精确度更高但每个语言要跑独立的守护进程code-review-graph 给你一个跨语言的持久化图。RAG 用相似度分块做检索它用 AST 解析出的结构化边做关联——这是两种完全不同的解题思路。grep 在单跳查找上更快但到了多跳场景调用者的调用者、测试关联图的能力就体现出来了。项目在 FAQ 里列了对比——Serena、codegraph、claude-context、repomix 都在列但没有给出每个竞品的 Star 数和 URL。这个对比更多是概念层面的区分。目前的限制也需要说清楚。影响分析的精确度 F1 分数是 0.714设计上偏保守会标记一些可能受影响的文件——换句话说会有误报。搜索质量的 MRR 只有 0.35正确结果通常在前四个里但排名不够精准。流检测的召回率只有 33%在 Python 和 PHP 上表现最好JavaScript 和 Go 上还需要改进。对小型的单文件变更来说图本身的元数据开销可能超过直接读文件的成本——README 原文的原话是开销来自支持多文件分析的结构元数据。代码解析的自信度分了三个级别EXTRACTED 是从 AST 直接提取的硬证据INFERRED 是通过命名规范推断的AMBIGUOUS 是无法确认的。每条边上都标了浮点分数不会把推断当事实来展示。v2.3.7 是三天前发的版本修了 CodeQL 安全告警回滚了一个不稳定的 MCP 支持。项目总共有 713 次提交。README 提供了中文、日文、韩文和印地语版本中文开发者看起来没什么门槛。有网站、Discord 社区还有一个 44 秒的录屏演示可以看实际效果。什么样的团队适合用它大型 monorepo 是最佳场景——README 里提到一个案例27,700 多个文件被排除在审查上下文之外实际只读了大约 15 个文件。多语言项目、频繁做 PR 审查的团队、重视 Token 成本的团队都能从中受益。如果你的项目只有一个语言、文件数量不超过 100 个、或者很少做代码审查那么这可能不是你的刚需。项目地址 https://github.com/tirth8205/code-review-graph
用 AI 审代码的人都有过这种体验。让 Claude Code 看一个 PR它开始读文件——一个接一个越读越多。你盯着 Token 计数器往上涨但仔细一看它读进去的文件一大半跟这个 PR 没关系。code-review-graph 做了一件事给代码库建一张结构图谱让 AI 只读该读的部分。它不是又一个 AI 编程助手。它是给现有助手装上的精准上下文引擎。它不替代 Claude Code 或 Cursor而是让它们不再把整个仓库当上下文往里灌。怎么做到的理解它的原理只需要一句话用 Tree-sitter 把代码解析成 AST把函数、类、导入变成节点把调用关系、继承关系、测试覆盖变成边存进本地的 SQLite 文件。当你改了一个文件图会沿着边追踪——谁调了这个函数这个类的子类是谁哪些测试覆盖了这段逻辑这就是它说的爆炸半径。AI 只需要看爆炸半径内的文件而不是整个仓库。它的基准测试数据让人印象深刻。6 个仓库的中位数每次问题 Token 减少约 82 倍。fastapi 仓库的单次最佳成绩是 528 倍原本需要 95 万 Token 的上下文压缩到 2,169 个。在自己的仓库上跑也达到了 93 倍。即便是基准测试里表现最差的 httpx 仓库也有 38 倍的降幅。不过要注意528 倍是极端最佳情况不是日常典型值。README 自己也坦诚了这一点。实际使用非常简单。装完 Python 3.10 以上的环境两条命令就能跑起来pip install code-review-graph code-review-graph install code-review-graph buildinstall 命令会自动检测你装了哪些 AI 工具——Claude Code、Cursor、Codex、CodeBuddy Code、Gemini CLI、Copilot 等 16 个平台它都认识。build 命令开始解析代码库500 个文件的项目大概 10 秒完成。之后的增量更新更快一个 2,900 文件的项目重新索引不到 2 秒。因为是纯本地运行不需要任何外部数据库或云服务图谱数据就存在项目目录下的 SQLite 文件里。用它之后的工作流变成这样在 AI 助手里对项目说一句Build the code review graph for this project或者在 PR 中触发审查图就会返回爆炸半径和风险评分。AI 拿到的是精选过的文件列表而不是全仓库。跟同类方案比它的定位很清晰。LSP 语言服务器在单符号级别的精确度更高但每个语言要跑独立的守护进程code-review-graph 给你一个跨语言的持久化图。RAG 用相似度分块做检索它用 AST 解析出的结构化边做关联——这是两种完全不同的解题思路。grep 在单跳查找上更快但到了多跳场景调用者的调用者、测试关联图的能力就体现出来了。项目在 FAQ 里列了对比——Serena、codegraph、claude-context、repomix 都在列但没有给出每个竞品的 Star 数和 URL。这个对比更多是概念层面的区分。目前的限制也需要说清楚。影响分析的精确度 F1 分数是 0.714设计上偏保守会标记一些可能受影响的文件——换句话说会有误报。搜索质量的 MRR 只有 0.35正确结果通常在前四个里但排名不够精准。流检测的召回率只有 33%在 Python 和 PHP 上表现最好JavaScript 和 Go 上还需要改进。对小型的单文件变更来说图本身的元数据开销可能超过直接读文件的成本——README 原文的原话是开销来自支持多文件分析的结构元数据。代码解析的自信度分了三个级别EXTRACTED 是从 AST 直接提取的硬证据INFERRED 是通过命名规范推断的AMBIGUOUS 是无法确认的。每条边上都标了浮点分数不会把推断当事实来展示。v2.3.7 是三天前发的版本修了 CodeQL 安全告警回滚了一个不稳定的 MCP 支持。项目总共有 713 次提交。README 提供了中文、日文、韩文和印地语版本中文开发者看起来没什么门槛。有网站、Discord 社区还有一个 44 秒的录屏演示可以看实际效果。什么样的团队适合用它大型 monorepo 是最佳场景——README 里提到一个案例27,700 多个文件被排除在审查上下文之外实际只读了大约 15 个文件。多语言项目、频繁做 PR 审查的团队、重视 Token 成本的团队都能从中受益。如果你的项目只有一个语言、文件数量不超过 100 个、或者很少做代码审查那么这可能不是你的刚需。项目地址 https://github.com/tirth8205/code-review-graph
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
