👁 90 次阅读
2026 年 10 月，AI 代码评审这个品类正经历一次集体改姓：Cursor 在 5 月把 Bugbot 从『$40 一席』改成按用量计费，GitHub 在 6 月 1 日起把 Copilot 代码评审改为 AI credits 加 Actions 分钟数双计费。计价方式在变，但有一个工具仍然把自己包装成『按席位的固定价』卖——CodeRabbit。这也是本次评测最值得拆穿的地方：它的席位价看起来像定价，实际上里面塞了三套完全没写在营销页上的额度。
先把结论放前面。CodeRabbit 是这个品类里技术最扎实的一个：完整仓库克隆到沙箱、评审代理自己写 shell 命令做跨文件追踪、四家代码托管平台原生支持，这在竞品里几乎是独一份。它的问题不在能力，在你看不见的三处墙：小时级滚动配额、没人公开宣传的公平使用降级、以及 150 到 300 个文件的硬上限。三者都不在定价页上，但三者都能让你的团队在实际使用中直接卡住。
一、三个『没人写在营销页上』的额度
1. 免费版其实不评审你的私有仓库
这是最容易误判的一条。CodeRabbit 官方文档确实写了免费版覆盖公开和私有仓库、无需信用卡，读起来像『私有仓库也免费』。但文档同一节明确限定：PR 路径只输出 summary（摘要），完整评审只在 VS Code 扩展和 CLI 两条路上给免费版开放，且免费档完全没有 bot 聊天。
这意味着如果你只在一个免费 GitHub 账号上看 PR 里 CodeRabbit 评论的质量，你评估的根本不是这个产品的正身——你评估的是一段摘要。这个误判会直接导致两种错误决策：以为它不够用而不买，或者买了才发现免费版已经在 IDE 里跑得挺好。
2. 『每小时』和『滚动周期』是两回事
官方文档（docs.coderabbit.ai/management/plans）的表述是：所有限额按开发者执行，跑在滚动时间窗口上，且是滚动额度而非一次性配额——你可以一小时把额度一次用光，新的额度随着旧记录滑出窗口逐步恢复，而不是整点重置。
具体数值：Essentials 每小时 5 次 PR 评审、Team 10 次、Advanced 12 次，IDE 与 CLI 各有独立额度，单次评审文件上限分别为 150 和 300。
这里有个数据源不一致值得单独说明：devshot.co 依据官方 changelog 记录的是 5 / 8 / 10 / 12（Essentials / Team / Advanced / Enterprise），而官方当前文档与多家第三方评测记录的是 5 / 10 / 12。按官方文档的时点取值应为后者，但这也恰好说明这个品类的限额参数变动频繁，签合同前必须以当时抓取的官方文档为准。
3. 公平使用政策：60 次之后每小时只剩 1 次
这是最隐蔽的一层。据 officebook.dev 的实测记录，CodeRabbit 的每小时上限会随最近 7 天的评审量自动下滑，且这一分层机制在营销材料中没有出现在显眼位置：Essentials 在 0 到 29 次时为 5 次/小时，30 到 39 次降到 4 次，40 到 49 次为 3 次，50 到 59 次为 2 次，达到 60 次之后每小时只剩 1 次。
官方文档的措辞是：当某个开发者身份达到近期评审使用量的第 95 百分位及以上时，系统会逐步拉长后续评审的间隔。也就是说这不是一次性封禁，而是渐进降速——你甚至很难从账单上发现它发生。
4. 文件上限是一道真墙，不是价格问题
单次评审最多处理 150 个文件（Essentials）或 300 个文件（Team 及以上）。而一旦单次评审超过 300 个文件，官方文档直接写明：该评审通过按用量计费也『不支持』。
这句话的分量容易被忽略。它意味着大重构、数据库迁移、生成代码批量改动这三类最需要第二双眼睛的改动，恰恰是 CodeRabbit 在 300 文件处直接失明的地方。而且这不是『加钱就能过』的问题——多付钱只能让你在超出档位限额但仍在 300 文件以内时继续评审。对 monorepo 来说，这是本评测里最可能真正咬人的限制。
二、钱：2026 年的档位改名，与那个隐性账单
先处理一个非常容易查错的价格问题。2026 年官方把档位名整体换过：旧 Pro 现在是 Essentials，旧 Pro Plus 现在是 Team，原有订阅是就地改名，不是重开。Lite 和 Pro Legacy 在 2026 年 6 月 8 日停止销售，所以现在新买的人，Essentials 就是入口档。
官方定价页（coderabbit.ai/pricing）与官方文档双源一致：
| 档位 | 年付（每开发者/月） | 月付 | 单评审文件上限 | Chat 额度 | MCP 连接 |
|---|---|---|---|---|---|
| Essentials（旧 Pro） | $24 | $30 | 150 | 50 | 5 |
| Team（旧 Pro+） | $48 | $60 | 300 | 100 | 15 |
| Advanced | $72 | 未列出月付 | 300 | 100 | 20（据评测） |
| Enterprise | 定制报价 | — | 300 | 100 | 20 |
注意 Advanced 这一档：官方文档只写了『$72 年付』，没有列出月付价格；月付 $90 来自第三方评测。同时 Advanced 是第一个提供持续安全监控（Continuous pull request security review）的档位，Essentials 和 Team 都没有这项。
然后是那个隐藏账单。官方文档把 CodeRabbit Security Scan 和 CodeRabbit Agent 单独归为『按需产品』，明确写的是『单独计费，不含在基础档位内』，各自有独立的用量定价与资格门槛。第三方实测给出的口径是：超额评审 $0.25 每文件，CodeRabbit Agent $0.40 每分钟。也就是说，席位费之外还有两个独立的计费通道，Agent 那个是分钟级计费的——用得多了，这部分账单的波动性远大于席位费。
还有一个容易踩的：按 officebook.dev 的实测，2026 年好几个新功能被放在 Team 而不是 Essentials 后面，所以你预算的年度数字经常是 $48 而不是 $24。
同一批开发者，六家工具各要多少钱
以下价格来自 devshot.co 与 cubic.dev 在 2026 年 9 到 10 月的整理，均为年付口径、税前、每开发者每月。两家站点自身都是竞品厂商的评测页，因此本文按『公开第三方整理价』引用，而非官方原价：
| 工具 | 档位 | 单价 | 10 人 | 50 人 | 计费性质 |
|---|---|---|---|---|---|
| Bito | Team | $12/席 | $120 | $600 | 按席，5000 行内含后 $5/千行 |
| CodeRabbit | Essentials | $24/开发 | $240 | $1200 | 按开 PR 的开发者 |
| CodeRabbit | Team | $48/开发 | $480 | $2400 | 按开 PR 的开发者 |
| Greptile | Pro | $30/席 | $300 | $1500 | 按席 + 50 额度/席，$1/额度 |
| GitHub Copilot | Pro | $10/席 | $100 | $500 | 按席，免费档不含 PR 评审 |
| Graphite | Team | $40/席 | $400 | $2000 | 按席，评审不限次 |
这张表最值得看的不是绝对值，而是三种计费模型的分歧点。CodeRabbit 只按『创建 PR 的开发者』计费，只读代码的人和做评审的人免费，席位可转让；Greptile 按席位加额度计，超额按作者个人而非池化收取，但允许把 flex 上限设到 $0，超出就跳过评审；Copilot 最便宜但免费档不包含 PR 评审，Business 与 Enterprise 席位另定价。
结论很明确：如果账单应该跟着人数走而不是跟着评审量走，CodeRabbit 的模型更稳；如果有少数几个人会开大量 PR、或者智能体批量开 PR，那就得先算两边的账单，不要只看单价。
三、它到底抓得住几个 bug：四组数据，四种算法
这个品类最大的坑是数据不可比。同样是『抓 bug 准确率』，四组数字用的完全不是同一种算法，直接放一起比是误导：
| 数据源 | 测试集 | 关键结果 | 判定方式 | 时间 |
|---|---|---|---|---|
| CodeRabbit 官方（Sonnet 5.5 文） | 13 个最难已知 bug | 命中 6 个，可执行精确率 41.2% | 独立评审三方投票，多数 PASS 才计 | 2026-09-28 |
| Martian Code Review Bench | 17,717 个打分 PR | CodeRabbit F1 61.1%／召回 58.0%／精确 64.6%；Greptile 精确 80.0%／召回 49.6% | 连续更新的公开排行榜 | 2026-08-31 读 |
| dev.to 独立研究（izgorodin） | 146 个已合并 PR，82 个有发现 | 281 条发现，约 3.4 条/PR，误报率 2.3% | 只数发现、误报与延迟，不分级 | 2026 |
| Greptile 自家 benchmark | 50 个真实 bug | Greptile 捕获 82%，CodeRabbit 44%／误报仅 2 个 | 只计捕获，明确不把误报算进去 | 2025-07 |
读法要点有三条。
第一，CodeRabbit 官方那组数据自己都承认样本太小——官方原文写的是『13 个案例是小集合，我们在文中反复说明』。41.2% 是可执行精确率，分母是所有可执行评论，不是召回率。
第二，Greptile 那组数据比 CodeRabbit 官方那组晚了一年多，而且明确不把误报计入捕获率。所以『44% 对 82%』这个对比，比的是两个不同的东西。
第三，Martian 的公开排行榜是目前最有参考价值的一组：17,717 个 PR 的打分量级，而且持续更新。在这组数据里 CodeRabbit 召回率最高（58.0% 对 Greptile 的 49.6%），但精确率明显落后（64.6% 对 80.0%）。这组数字直接指向本评测的核心分歧——如果你的团队会忽略噪音评论，Greptile 的精确率更重要；如果漏改的代价更高，CodeRabbit 的召回更重要。
另有一组安全维度数据来自社区整理的第三方基准（OpenSSF CVE Benchmark 口径）：CodeRabbit 安全准确率 59.39%／F1 36.19%，即约 41% 的真实漏洞漏检。该数字未找到官方直接来源，仅作口径参考，不建议作为采购依据。
延迟：最慢的，慢到 40 分钟
officebook.dev 引用的独立研究显示：CodeRabbit 平均 9.5 分钟，P95 为 41.3 分钟，是该项研究中测的四个工具里最慢的。
这个数字的实际含义很具体：如果你的团队依赖评审反馈才能继续开发下一个 PR，40 分钟的 P95 意味着相当一部分情况下评审会成为一个真实的等待点。9.5 分钟的中位数听着还好，但 P95 才是决定工作流体感的数字。
噪音：默认配置是吵的，而且不是默认值
关于噪音的批评跨平台高度一致——Reddit、Hacker News、G2 都指向同一件事。Reddit 上有用户直接写：每份评审里都有好评论，但大部分是误报，团队通常得加过滤规则才敢用；curatorbits.com 的自测（其自己仓库上跑 CodeRabbit，无联盟关系）把『信号/噪音』这一项打 3.3/5，是所有维度里最低的，总分 4.3/5。该站的实测结论也点出了边界：在小而范围清晰的 PR 上误报很少，大 PR 才会明显变吵变慢。
官方给的解法是三个噪音档位：Quiet、Chill 和 Assertive，另有『1 到 2 个 commit 后自动暂停评审』的开关。但关键细节是：那个修噪音的 Quiet 档是 2026 年 7 月 2 日才发的，而且不是默认档。也就是说你装上去的默认状态就是吵的，得自己去找设置。
四、技术层面它凭什么：不是模型在 diff 里乱跑
The AI Engineer（Paolo Perrone，2026-06-20）做过一篇架构拆解，观点很关键：CodeRabbit 卖的是『AI 代码评审员』，听起来像一个模型读你的 diff 然后留评论，但模型只是最不重要的部分。绝大多数工作发生在它之前——克隆仓库、映射变更触及范围、跑 lint、读 CI 日志、拉取团队历史评审偏好。
CEO Harjot Gill 的原话大意是：这不像别家那种 agentic loop，它更像一条管线，大量精力花在上下文准备上。评审代理在沙箱里自己写 shell 命令（cat、grep、ast-grep）做调查，而不是调用预定义工具接口——好处是没有工具 schema 要维护。架构上分四个并行代理：Review、Verification、Chat、Pre-Merge Checks，跑在全仓库克隆的沙箱执行环境里。
这套设计的价值在于它解决了一个真实痛点，The AI Engineer 用 2026 年的例子讲得很清楚：2 点 20 分值班电话响，结账功能报空指针，指向昨天合并、拿到两个点赞、绿灯全过的那个 PR。diff 看着无害，是个支付 helper 的小重构，但改了一个下游调用方还依赖的返回类型——而那个调用方在 diff 之外的第三个文件里，没人打开过。两个评审都漏了。
这正是 CodeRabbit 试图覆盖的区间：评审跳读，而真正贵的 bug 藏在 diff 不显示的文件里。官方的过滤链路描述是『验证 → 去重 → 过滤』后才发布评论，即你看到的是过完管线之后的数量，但仍然每条都得人读。
另一个平台覆盖上的硬优势：CodeRabbit 是唯一同时原生支持 GitHub、GitLab、Azure DevOps 和 Bitbucket 的主要工具。反过来说，Greptile 支持 Gitea 和 Perforce 但不支持 Azure DevOps，所以仓库在 Azure DevOps 的团队在这里就没有别的选择；反之跑 Gitea 或 Perforce 的团队只能选 Greptile。
自托管方面，据 dev.to 对两家官方文档的对照：CodeRabbit 自托管仅限 Enterprise 且要求 500 席位以上，可由自己的模型提供商驱动；Greptile 的 Enterprise 含气隙部署与自定义 LLM 提供商，无席位下限，文档建议 Docker Compose 安装规模在 100 开发者以内。如果你的代码必须留在内网且团队不到 500 人，这个差异直接决定选型。
五、数据与信任：一笔必须算的旧账
2025 年 1 月 24 日，研究者通过构造一个包含恶意 .rubocop.yml 的 PR，让 CodeRabbit 在分析时加载并执行了任意 Ruby 代码，在生产服务器上拿到远程代码执行权限。据 Kudelski Security Research Center 的披露记录，这次利用泄露了 ANTHROPIC_API_KEYS、PostgreSQL 主机名账号密码、以及 CodeRabbit GitHub App 的私钥——而后者意味着对约 100 万个仓库的写访问权限，包括私有仓库。
时间线是：2025 年 1 月 24 日披露，CodeRabbit 立即禁用 Rubocop、轮换密钥，1 月 30 日确认修复。漏洞本身 6 天内补完，但公开披露报告直到 2025 年 8 月 19 日才发布——修复与公开之间隔了大约 7 个月。
安全姿态方面，CodeRabbit 官方安全页的表述是：代码在评审期间加密，评审后不存储，SOC 2 Type II 每年审计，并明确声明『从不用客户代码训练模型』。对比 Greptile：官方条款允许在去标识化后使用客户数据训练，但可 opt-out，自托管部署下除非配置否则不训练。如果你的公司政策不允许代码被用于训练，这一条必须逐项核对供应商的 DPA，而不是看定价页。
2026 年下半年的功能节奏
| 时间 | 功能 | 形态 |
|---|---|---|
| 2026-07-02 | Quiet 噪音档位 | 修复默认噪音，非默认值 |
| 2026-07-16 | Fix CI（可代推 commit） | Beta，GitHub |
| 2026-07 | Security Agent 整库扫描 | Beta，独立 14 天试用，单独计费 |
| 2026-08-03 | fix-ci commit 命令 | — |
| 2026-08-19 | Azure DevOps 支持 | Fix CI 扩平台 |
值得注意的是，Advanced 档才包含持续安全监控（含严重性、可利用性、可达性判断），Essentials 与 Team 都没有。所以如果你买它的理由是安全，价格不是 $24 而是 $72。
六、结论：三种人，三条明确答案
第一，公开开源项目：直接用免费版。官方写明公开仓库评审永久免费，14 天 Advanced 试用也无需信用卡。这条不需要犹豫。
第二，单人开发者或小团队：不要买。付费版的边际收益在低评审量下抵不过席位成本，IDE 与 CLI 的免费路径已经够你用了。
第三，5 到 50 人、有持续 PR 流、且仓库跨平台（尤其用 Azure DevOps）：Essentials 值得试，但要带着三个前置条件评估——先确认仓库的平均 PR 文件数是否接近 150 的上限，确认你们的 PR 合并节奏不会在 7 天内突破 60 次触发降速，确认需要 Team 档的功能（单元测试生成、合并冲突解决、CI 修复）是否值得从 $24 跳到 $48。
明确不适合的两种情况：monorepo 或经常有大文件数改动的仓库，300 文件硬墙会让你在最需要评审的地方失明；CI 等待时间敏感的团队，41.3 分钟的 P95 会成为真实瓶颈。这两种情况下，先把 Greptile 的 14 天试用装到同一个仓库，让两个工具评审同一批 PR。
最后给一套能自己验证的方法，直接取自 Greptile 自己的 benchmark 设计：取 5 个真实修 bug 的 PR，把它们引入 bug 的 commit 反向开成新 PR，让两个工具都跑一遍。给每条评论标记为『真实 bug』『错误断言』『噪音』，并记录确认耗时。两周后你有三个属于自己代码库的数字：5 个已知 bug 抓了几个、每个 PR 几条错误断言、每条评论几分钟。厂商的图表替代不了这三个数字。
回到开头那句话：AI 代码评审工具的本质是压缩首轮时间，不是替代判断。CodeRabbit 是这条赛道上把技术做最扎实的一个，但它把真实约束藏在了三层没人写的额度后面。买它之前，先花两小时读完那份 rate limits 文档——那是这个产品唯一诚实的地方。