alibaba/open-code-review

如果你已经有模型 API，并且想要结构化、可重复的评审输出而不是自由对话式的 Agent，Open Code Review 值得花时间试试。它的卖点是精确率和 token 消耗，而不是召回率，接入前先校准预期。

解决什么问题

开发者做完一个分支，通常想要两件事：对 diff 再过一遍找出缺陷，以及把问题定位到评审者能直接处理的行。让通用编程 Agent 来做，小改动还行，改动一大，Agent 往往只挑部分文件看，报出的位置也会偏移。结果是评审看起来全面，实际悄悄漏了文件。Open Code Review 改变的是分工：由工程逻辑决定哪些文件进入评审、评论挂在哪一行，模型只负责判断问题是什么。最后得到一份逐行报告，或者可以喂给其他工具的 JSON。

有什么不同

它的设计是混合式的。确定性的步骤处理不能出错的部分——筛选文件、生成 diff、把评论锚定到行；Agent 负责理解和判断。一个固定流水线加一次范围很窄的模型调用，比调一整段自然语言 skill 更容易排查问题，这也是作者给出的拆分理由。

README 自带的 benchmark 声称，在相同底层模型下相比 Claude Code，精确率和 F1 明显更高，token 只消耗约 1/9，同时明确承认召回率更低，是刻意用召回换精确 项目 README。这应视为厂商自己的测量，而非独立结论。独立证据较少：一位评论者在 2026-06-05 用早期版本跑了某个公开 benchmark 50 个 PR 中的 10 个，报告召回不错（约 74%），但精确率很差（约 12%），F1 只有 20% 左右 早期评测反馈。维护者随后回复说，该版本有一个关键工具调用异常，会导致误报偏高，已经复现并修复 维护者回复。目前没有新的独立复跑，真实场景下的误报率仍是未知数——而这恰恰决定评审者会不会继续开着它。

谁值得试

适合：想把代码评审变成可脚本化步骤的团队，比如在 CI 里做分支区间评审、把 JSON 报告交给另一个 Agent、或者对没有可用 diff 的历史目录做整文件扫描。workspace、分支区间、单 commit 和 scan 几种模式覆盖了这些场景，长评审还支持恢复会话。不适合：指望它替代人工评审，或者指望它什么问题都找出来的人。文档承认召回率较低，所以一份干净的评审报告不能当作改动没问题的证明；只用一个模型、没有 API key 也不想用委派模式的个人开发者，则没法跑出第一次评审。如果你已经有一个订阅模型的 Agent，不妨先对比一下 token 账单和输出格式，再决定要不要多引入一个工具。

使用条件与边界

需要 Git 2.41 或更新版本，因为 diff、代码搜索和仓库操作都依赖它。除非使用委派模式，否则必须先配置好 LLM 提供商，所以持续成本是模型用量，而不是 CLI 本身。安装方式包括 npm、安装脚本、GitHub Release 二进制或从源码构建，参见安装文档和配置文档，其中说明支持 OpenAI 与 Anthropic 兼容的端点。

日常维护比首次安装更重要。评审质量取决于你接的模型，以及内置规则集（NPE、线程安全、XSS、SQL 注入等）；规则或提示词更新后，应重新检查输出，而不是假设结果稳定。精确优先于召回的取舍，也意味着调整阈值或规则是一项持续工作，不是一次性设置。

HotRepo 点评

HotRepo 在 2026-07-27 至 2026-10-27 之间记录了 18 个上榜日；最近三个上榜日的平均日增为 +256 star，而此前三个上榜日为 +2,906 star——这只是记录到的上榜日，并非连续每日序列。热度在回落，但这和评审质量关系不大。采纳前真正需要确认的，是维护者所说修复之后，它在你自己的仓库上的误报率，因为精确率才决定开发者会不会继续把它开着。