CodeRabbit vs Greptile vs Bugbot vs Diamond：你买的是一份评论预算

一览

四个会评审 PR 并在上面留评论的工具。以下为 2026 年 8 月的公开信息。

Cursor 于 2025 年 12 月 19 日宣布收购 Graphite，这就是上表里有两行共用一个归属方的原因——这件事的分量比它看上去大，下文会回到它。

三种计费形态，每一种买来一种不同的行为

2026 年，这个品类的定价不再是脚注。Bugbot 在 6 月扔掉 40 美元席位改为纯按量；Greptile 在 3 月改成含 50 次评审的席位、之后每次一美元；CodeRabbit 保留了带上限的席位，并加了一个把上限抬高的更贵档位；Diamond 干脆没有单独价格，因为它随平台一起来。这不是同一根轴上的四个点，而是对"一次评审值多少钱"这个问题的三种不同回答。

带上限的席位让上限成为产品。边际评审在触顶之前是免费的、触顶之后是不可能的，于是压力落在配给与铺开上——哪些仓库接上了、哪些人有席位——而失效模式是某个团队在忙碌的周四耗尽额度后，干脆整个服务把机器人关掉。按次计费把这一切反转：每个 PR 都是一次采购，于是团队开始按分支、按体量、按标签设闸，而失效模式是一条悄悄把自动依赖升级排除在外的规则——而有意思的回归恰恰藏在那里。捆绑则彻底隐藏了价格，这很省心，直到你意识到自己是通过选择一套 PR 工作流来选择代码评审器的。

三者都没有给评论定价。每个工具计费的对象是评审、席位或平台；而真正被消耗的资源，是一个开发者读完一段话并判断它对不对。那才是稀缺投入，它没有计量，也正因如此，两个标价相同的工具在实际成本上可以差一个数量级。

席位与计价表在哪里交叉

把公开价格拉成曲线，交叉点落在一个应当改变你答案的位置上。在每人每月大约二十次评审以下，按量的那个是全场最便宜的，席位看起来像多付；越过之后两条线反转，一支忙碌的团队在按次计费下付得比两种席位都多，而且拿不到任何量级折扣。这个交点并不奇特——一位开发者每天开一个 PR 就正好落在那儿——这意味着这道算术是真正吃劲的，而不是一个舍入差；同时也意味着，团队习惯一变，答案就翻面。

二阶效应比一阶更糟。按量计费不只是在高量时更贵，它还改变了什么会被评审，因为迟早会有人写下那条把小 PR 或机器人分支排除在外、以便压低账单的规则。而依赖升级和一行配置改动，恰恰是评审器最能挣回身价的地方，也恰恰是成本规则第一个删掉的东西。如果你走按量，就按全量覆盖做预算、一道闸都别设——一旦你开始为了控成本而修剪输入集合，席位不但更便宜，而且更好。

准确率数字互相打架，而且大多有作者

把证据摊开说。Greptile 发布过一份跑分：在 Sentry、Cal.com、Grafana 等项目的五十个 PR 上，Greptile 抓到 82% 的植入缺陷，CodeRabbit 是 44%——而在同一次运行里，Greptile 产生了十一个误报，CodeRabbit 是两个。另一份 2026 年的对比却把 Greptile 描述成两者中更沉默的那个，只在有把握时才说话。一份第三方汇总把 Diamond 记作每个 PR 0.62 条评论、Bugbot 0.91 条，是全场最克制的，同时又给 Diamond 打出 18% 的缺陷发现率。而 Martian 的一项独立研究，把 CodeRabbit 排在十个工具之首。

这些不可能都在描述同一件事。它们确实不是：语言构成、仓库规模、缺陷是植入的还是自然发生的、样式类评论算不算发现、以及记账那个人心里的"误报"是什么意思——这些都不同。尤其是植入缺陷的跑分，天然奖励一个被调得多疑的工具，因为缺陷确定在那儿；而生产仓库奖励的恰恰相反，因为通常它不在。仅这一处方法论差异，就足以在两个工具都没有变化的情况下把排名掀翻。

贯穿其中的不变量，是这个权衡的形状，而不是任何工具在其上的位置。这个市场里的每一个评审器都落在从"安静而漏掉东西"到"吵闹而常常说错"的那条曲线上，而厂商在版本之间沿这条曲线移动的速度，远快于跑分被重跑的速度。一个两个季度前跑出的数字描述的是一份已不复存在的配置。把这些公开数字当作"这个权衡很陡"的证据——这确实有用——而不要当作排名。

每个 PR 的评论条数，才是决定它能否活下来的那个数

一个评审机器人真正的预算以开发者秒计，而它真正的失败不是漏掉一个缺陷。它是第三个月的某个周二：一位资深工程师不再读机器人的评论，接着所有人都不读了，然后漏掉的缺陷也不再重要，因为抓到的那些本来也没人会看。这场崩塌几乎完全由"有多少比例的评论值得一读"驱动——这也是为什么那些报道发现率的汇总，同时也在报道 AI 评审评论中很大一部分谈的是样式而非逻辑：人们反应的是这个比例，不是召回率。

这与我们那篇代码评审智能体从建设面得出的结论相同：精确率就是产品，而唯一有意义的生产指标是采纳率。它也解释了一个否则会显得奇怪的事实：全场最克制的两个工具，正是被一家编辑器公司拥有的那两个。当评审器的评论就出现在开发者本来就待着的那个产品里、紧挨着代码时，一条被无视的评论的可见程度，是一条被无视的 GitHub 讨论所不具备的，而"保持安静"的动机也就更强。

两个实际推论。第一，如果工具允许，自己给评论量封顶——每个 PR 硬性三到五条、按最坏优先排序，比任何置信度阈值都更好，因为在一次大重构上它会优雅退化，而一个不设上限的评审器会产出四十条注记然后被原封不动地关掉。第二，衡量驳回，不衡量检出。这里每个工具都能告诉你它产出了多少发现；几乎没有一个会告诉你其中有多少是被解决而不是被驳回的，而那个比值就是全部的健康信号。

四个里已经有两个是同一个东家

Cursor 在 2025 年 12 月收购了 Graphite，并表示两个产品短期内继续独立运营。就算照单全收，这个市场也已经和当时不同了：在这个区间里最克制的那一端——也就是一支被吵闹机器人烫过手的团队最想挑东西的那一端——只剩下两个产品和一家公司。Bugbot 和 Diamond 不是同一个工具（一个是绑在编辑器上的 diff 评审器，另一个绑在堆叠式 PR 工作流上），但它们是一份路线图和一个定价部门，而 6 月把 Bugbot 改成按量计费的那种决定，通常是会扩散的。

两个方向的暴露不同。选 Bugbot，就把评审质量绑在一家主业是编辑器的公司身上——在这个编辑器正是你团队用的那款时这没问题，在它不是的那一年就别扭了。选 Diamond，则是把它绑在一套 PR 工作流上：Graphite 的价值主张是堆叠式 diff，为了拿到评审器而采用它，等于采用了一套分支模型。Greptile 是最明确地把"不绑定编辑器"当卖点在卖的那一个，而在一家有三种编辑器、还有一队编码智能体在开 PR 的公司里，这是一条真实属性。CodeRabbit 则是独立的通才，平台覆盖最广，作为机构安全解的履历也最长。

以上都不构成回避某个工具的理由。它构成的理由是：把集成做浅——这几个都以 GitHub App 或 check 的形式挂上去，也以同样的方式摘下来；一个如此年轻、并购又如此频繁的品类，不是那种值得把工作流围着它建起来的品类。

什么时候选哪个

真正能回答这个问题的流程既无聊又要两周：在同一个仓库上并行跑两个，覆盖每一个 PR，不设成本闸门、不做调优。然后为每个工具数三件事——产出的评论数、导致代码改动的评论数、被驳回的评论数。赢家是第二个数更高、第三个数更低的那个；而这套算术不会像任何人的跑分，因为它是在你的代码库上、用你的语言、按你团队对"被告知一条命名规范"的容忍度量出来的。

延伸阅读

本站相关：

• 代码评审智能体——从建设面论证评审机器人为的是精确率而非召回率。
• 后台编码智能体——这些工具如今要评审的额外 PR 都是从哪来的。
• 评估编码智能体——为什么一个跑分属于测试编排而不属于模型。
• 单位经济学——把按次价格和按结果价格摆在一起看。

信息来源：

• Cursor —— Graphite 加入 Cursor
• Cursor —— Bugbot 面向团队与个人的变更
• Greptile 定价
• Greptile 发布的 AI 代码评审跑分