code-review-graph：用本地图谱为 AI 编码工具省下九成上下文
MCP 和 CLI 的本地优先代码智能图。构建代码库的持久地图，以便 AI 编码工具仅读取重要内容，并在评论和大型存储库工作流程上进行基准上下文缩减。
秒懂
- 它是什么？
- code-review-graph 是一个本地优先的代码智能图谱，通过 Tree-sitter 解析仓库结构，再经由 MCP 协议向 AI 编码工具提供精准上下文。实测中它能把一次审查所需的上游 token 从 20 万降到约三千，但它的增量更新和平台适配也有自己的边界。
- 适合谁用？
- 适合在大型仓库上使用 AI 编码工具做代码审查的团队，尤其是那些已经受困于 token 消耗和上下文溢出的开发者。它不适合还在用小型项目、或对额外后台进程敏感的场合，因为增量更新依赖 watch 模式和钩子，且首次构建仍需要一次性解析。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 AI 审查时的 token 浪费
AI 编码工具在审查代码时，往往会反复读取仓库里的大量文件。仓库越大，浪费越明显。code-review-graph 的定位很直接：它先建一张代码结构图，然后在审查时只给模型返回与改动相关的文件。README 里的数字很能说明问题，在这个仓库上，208,821 个源码 token 被压缩到每个问题约 3,190 个 token。这不是基准测试的承诺，而是项目自己的测量。它服务的对象很明确，就是那些在大型仓库上使用 Codex、Cursor、Claude Code 这类工具的开发者。
Tree-sitter 解析加上图结构查询
工作流程分两步。第一步，仓库被 Tree-sitter 解析成 AST，然后存成图，节点是函数、类、导入，边是调用、继承、测试覆盖关系。第二步，审查时查询这张图，算出模型需要读的最小文件集合。关键机制是爆破半径分析，当某个文件变化时，图会追踪所有调用者、依赖者和相关测试，模型只读这些文件。增量更新则靠 diff 和 SHA-256 哈希，只有真正变化的文件才会被重新解析。这个设计把静态分析和图遍历结合起来，不是简单的文件列表，而是带依赖关系的上下文。
安装与配置：一条命令覆盖七个平台
安装走 PyPI，命令是 pip install code-review-graph，要求 Python 3.10 以上。装完后运行 code-review-graph install，它会自动检测你机器上装了哪些 AI 编码工具，然后为每个工具写好 MCP 配置，注入图感知的指令。如果想单独配置某个平台，可以用 --platform 参数指定 codex、cursor、claude-code、gemini-cli、antigravity、windsurf、zed 或 continue。安装后要重启编辑器才能生效。初始构建一个 500 文件的项目大约需要 10 秒，之后 watch 模式或钩子可以自动更新。卸载也有对称的设计，code-review-graph uninstall --dry-run 可以先预览所有动作，确认只删除自己拥有的文件。
增量更新的实测数据与它的代价
README 给出了一个具体数字：在约 3,000 文件的 django 项目上，编辑两个文件后，钩子路径上的重新索引大约 2.5 秒，其中约 1.4 秒是进程启动开销。无操作更新只花启动时间。这说明增量更新的瓶颈不在解析，而在进程拉起。但这有个隐含代价，增量更新依赖 watch 模式和钩子，如果没启用，每次还是得手动 build。另外，进程启动开销在频繁保存时会累积，对交互式编辑体验可能是个负担。这个数字是项目自己的测量，我无法独立验证，但它至少揭示了性能特征。
语言覆盖广，但 YAML 和 HCL 有明确边界
解析器覆盖了 Python、JavaScript/TypeScript/TSX、Go、Rust、Java、C/C++、C#、Ruby、Kotlin、Swift、PHP、Scala、Solidity、Dart、R、Perl、Lua、Objective-C、Shell、Elixir、Zig、PowerShell、Julia、GDScript、Nix、Verilog、SQL、Terraform 结构等。Jupyter 笔记本也在支持范围内。但有两个明确边界：通用 YAML 不当作源码处理，.hcl 文件只识别为文件节点，不做结构解析。这意味着如果你的仓库主要靠 YAML 配置表达逻辑，图谱的精度会大打折扣。Terraform 的 .tf 文件有结构支持，但纯 HCL 配置不行，这是个值得注意的取舍。
卸载设计：原子替换与只删自己的东西
卸载逻辑做得比较谨慎。它会把目标路径规范化到工作树根，拒绝非仓库目录。卸载时只移除 CRG 拥有的文件和条目，其他 MCP 服务器、钩子、技能和 JSONC 注释都不动。共享配置的修改用原子替换，写入失败时原文件保持完整。这避免了常见的卸载残留问题。命令行提供 --dry-run、--yes、--all-repos、--keep-data 等选项，其中 --keep-data 可以保留图数据库，只移除集成配置。对于需要回滚的场景，这个设计降低了风险。
替代方案：直接喂全文 vs 用图谱裁剪
最常见的替代做法是直接把整个仓库或相关文件作为上下文塞给模型，很多 AI 编码工具自带文件读取功能，但没有结构意识。另一种是使用基于检索的方案，比如 embedding 相似度搜索，它按语义相似度找文件，但不懂调用关系。code-review-graph 的差异在于它用的是静态图，能精确追踪调用者和依赖者，而不是靠语义猜测。代价是需要维护图，首次构建和后续增量更新都有开销。对小型仓库，直接喂全文可能更简单，图谱的优势只在仓库大到 token 成本明显时才能体现。
维护与许可证：MIT 下的社区响应节奏
项目使用 MIT 许可证，商用和修改都没有限制。最近的版本节奏是 v2.3.6 在 2026 年 6 月发布，v2.3.7 在 7 月，v2.3.8 在 8 月，大约每月一个版本。v2.3.6 的发布名是 community-response release，暗示项目会根据社区反馈调整方向。文档目录里有 FAQ、TROUBLESHOOTING、REPRODUCING 等，说明项目重视可复现的基准。但维护活跃度不能只看版本号，得看实际 issue 响应。对于依赖此工具的团队，建议在采用前查看 GitHub 上的 issue 关闭时间和最近提交内容。
编辑结论
适合在大型仓库上使用 AI 编码工具做代码审查的团队，尤其是那些已经受困于 token 消耗和上下文溢出的开发者。它不适合还在用小型项目、或对额外后台进程敏感的场合，因为增量更新依赖 watch 模式和钩子，且首次构建仍需要一次性解析。采用前先验证三件事：你的平台是否在 install 命令的支持列表里，仓库语言是否在 Tree-sitter 解析器覆盖范围内，以及你的编辑器能否在重启后正确加载 MCP 配置。MIT 许可证允许商用和修改，但维护节奏要看社区响应，v2.3.6 的发布名就写着 community-response，说明项目会跟着用户反馈走。
社区笔记