GPT-5.6 Luna 每百万输入 token 收费 0.20 美元，每百万输出 token 收费 1.20 美元；GPT-6 Astra 则分别是 10 美元和 50 美元。在相同的 pull request 上，Luna 单次评审花 0.0041 美元，Astra 花 0.113 美元，相差 28 倍。上一篇我们对比了 Astra 与 GPT-5.6 Sol，这一次想弄清楚：如果每个 pull request 都交给最便宜的模型来评审，究竟会失去什么。

GPT-5.6 Luna 每百万输入 token 收费 0.20 美元，每百万输出 token 收费 1.20 美元。GPT-6 Astra 是 10 美元和 50 美元。在同一批 pull request 上，一次 Luna 审查花费 0.0041 美元，一次 Astra 审查花费 0.113 美元，相差 28 倍。

上一篇比较的是 Astra 和 GPT-5.6 Sol。这次我们想知道，如果每个 PR 都交给最便宜的模型，会失去什么。

简短回答

Luna 在 50 个 pull request 中找到 69 个已验证 bug，Astra 找到 92 个。Luna 整轮花费 0.20 美元，Astra 花费 5.66 美元。Luna 出错更多：93 条发现中有 24 条未通过验证，Astra 是 96 条中 4 条；24 个安全 bug 中 Luna 找到 9 个，Astra 找到 19 个。

我们的看法：在这个价位上，Luna 足以处理日常的正确性 bug，但我们不会让它单独审查认证或权限代码。

我们如何运行

设置沿用 Astra vs Sol 那篇，好让数字可比。

pull request 是 AI-Code-Review-Evals 组织里的 50 个公开基准 PR，Cal.com、Sentry、Discourse、Keycloak 和 Grafana 各十个。每个 PR 都在干净基线上引入了缺陷。

Luna 和 Astra 在相同 diff 上拿到相同提示。提示要求找正确性、安全、并发、资源和错误处理方面的 bug，排除风格、命名、文档和测试建议。每个模型返回结构化的发现。

验证方式与之前相同。对每个 PR，Astra、Sol、Luna 的发现以及公开的 Entelligence 审查评论汇成一个匿名列表。GPT-6 Astra 和 GPT-5.6 Sol 各自对照 diff 判断这个列表，合并重复项，判定每个问题是否是真 bug。只有两个裁判都认定为真，才算通过验证。两者在 91% 的发现上一致，143 个不同 bug 通过了双重认定。

加入 Luna 的发现改变了裁判看到的池子，所以所有内容都重新判断了一遍。Astra 的已验证数从上一篇的 91 变成这里的 92，Sol 从 107 变成 108。Astra 本身也是两个裁判之一，这可能略微偏向它。局限部分会谈到这一点。

结果

| | GPT-5.6 Luna | GPT-6 Astra | | --- | --- | --- | | 已验证 bug | 69 | 92 | | 提出的发现 | 93 | 96 | | 精确率 | 74% | 96% | | 50 个 PR 的总成本 | $0.20 | $5.66 | | 每个已验证 bug 的成本 | $0.0030 | $0.061 | | 每次审查平均耗时 | 23s | 36s | | 每次审查平均输出 token | 2,104 | 688 |

Luna 找到的已验证 bug 是 Astra 的 75%，花的钱只有 3.6%。按每个已验证 bug 算，Astra 贵 20 倍。

Luna 每次审查输出的 token 是 Astra 的 3.1 倍，却依然便宜得多，因为它的输出价格低 42 倍。它也更快，每次 23 秒对 36 秒。

团队最先感受到的是精确率差距。Luna 大约每四条评论就有一条是错的，Astra 是 96 条里错 4 条。已经会略过 AI 审查评论的开发者，面对四分之一是噪音的情况只会跳得更快。

Luna 落后在哪里

上一篇的读者要求按代码库和 bug 类型拆分结果，因为总体分数可能掩盖一个模型在某仓库表现好、在另一个仓库表现差。在这份数据上，拆分显示了 Luna 漏掉的 bug 来自哪里。

在 Sentry、Discourse 和 Grafana，Luna 与 Astra 相差在两个已验证 bug 以内。Cal.com 差距更大，21 对 30。Keycloak 差距最大：Luna 找到 6 个已验证 bug，Astra 是 14 个，而且 Luna 在 Keycloak 上的发现只有 50% 站得住，Astra 是 93%。

Keycloak 是身份与访问管理服务器，它的多数基准 PR 修改认证和权限逻辑。bug 类别的拆分也指向同一方向。

我们按根因给每个已验证 bug 打了标签。GPT-5.6 Sol 不在本次比较的两个模型之列，它依据书面定义一次性标完 143 个 bug。标签与基准数据一起提交，任何人都可以核对。

在数据与逻辑 bug 这一最大类别中，Luna 找到 39 个，Astra 47 个。并发是 10 对 13。安全方面，Luna 找到 24 个中的 9 个，Astra 找到 19 个。

Astra 抓到、Luna 漏掉的两个 Keycloak bug：

• 联邦恢复码从未被标记为已使用，因此同一个恢复码可以被多次使用。

• 一个全局视图权限覆盖了在个别客户端上设置的拒绝权限。

这两个在单独任何一行上看都不像有问题，只有推演变更后权限模型允许什么，才能发现。

Luna 抓到而 Astra 漏掉的

Luna 也找到了 Astra 漏掉的 bug。143 个已验证 bug 中，44 个两个模型都找到，48 个只有 Astra 找到，25 个只有 Luna 找到。

25 个 Luna 独有的 bug 里，16 个是数据与逻辑 bug，4 个是并发 bug。在 Discourse，重复发送退订请求会不断降低用户的通知等级。在 Sentry，一个并发 bug 替换了不健康的工作线程，却没有停掉旧线程。

在每个 pull request 上同时跑两个模型，可以发现 143 个已验证 bug 中的 117 个（82%），总花费 5.86 美元。也就是在 Astra 的 5.66 美元之上再加 Luna 的 0.20 美元，多换 25 个已验证 bug。

读者要求我们检查的内容

模型是不是只是记住了修复？

有读者指出这些仓库是公开的，基准 bug 的修复可能就在提交历史里。在修复落地之后训练的模型，可能是在回忆已经见过的补丁。建议的测试是按日期拆分 PR，看排名在每个模型训练截止之后做出的变更上是否成立。

这个基准做不了这种拆分。我们查了每个 PR 背后的提交日期，范围从 2013 年到 2025 年 7 月 25 日。20 个来自 2025 年，没有一个晚到两个模型的截止日期之后，截止后组会是空的。

风险比听起来小，因为这些缺陷是为基准特意加进 PR 的，每个 diff 里的确切 bug 不是模型可能训练过的提交。不过周围代码是旧的、公开的，知道正确版本长什么样的模型会有优势。要正确测试这一点，需要比模型更新的 pull request，这个基准提供不了。

模型会不会重复找到同样的 bug？

另一位读者要求用相同设置重跑一些 PR。我们每个代码库挑了两个 PR，每个模型再跑两次。

第一次运行时，Astra 在这十个 PR 上有 15 个已验证 bug。10 个在两次重跑中都再次出现，14 个至少出现一次。Luna 也有 15 个。7 个在两次重跑中都出现，12 个至少出现一次。

样本很小，只能当作粗略参考。模型在一次运行中找到的 bug，下一次可能漏掉，这适用于上面所有单次运行的数字，而 Luna 比 Astra 更常这样。

没人标记的 bug 呢？

第三个要求是追踪假阴性，也就是所有模型都漏掉的真实 bug。要衡量这个，需要每个 PR 中 bug 的完整列表，基准没有公布。

我们可以给出一个下界。26 个已验证 bug 被 Luna 和 Astra 双双漏掉，只被 Sol 或 Entelligence 审查器抓到。其中两个是上一篇提到的 Discourse 安全 bug：一个使用子串匹配的 postMessage 来源检查，以及一个跟随重定向越过主机白名单的远程抓取。真实的漏掉数量更高，因为没有任何审查者标记的 bug 永远不会进入池子。

比较的局限

• 除了十个重复的 PR，每个模型对每个 PR 只审查一次，重复运行显示结果会在运行之间波动。

• Astra 既是参赛者，又是两个裁判之一。要求 Sol 也同意能减少偏差，但不能消除。

• 每个 PR 都早于两个模型的训练截止日期，所以读者要求的日期拆分在这里无法实现。

• 两个模型只看到 diff，没有别的。它们没有仓库历史、调用图或生产数据。

• 已验证数量是现存 bug 的下界，基准没有完整的 bug 列表可供对照。

diff 无法告诉模型的事

在这个基准上，一个便宜模型在多数变更上表现不错，在认证和权限代码上表现很差。单凭 diff，模型不知道自己审查的是哪一类变更。

知道一个文件位于授权路径上、一个函数从登录流程中被调用、或者类似变更上个季度造成过事故，决定了应该多仔细地审查一个变更。Entelligence code review 用完整仓库上下文审查 pull request，并把生产行为反馈到后续审查中，这正是只靠 diff 的模型缺少的信息。

对编码 agent，Entelligence Model Router 把常规步骤发给更便宜的模型，把更难的步骤发给更强的模型。更早的 Terminal-Bench 对比讲了这在 agent 任务上的实际表现。

在自己的代码上运行

1. 从你的仓库收集 30 到 50 个已合并、后来需要修复的 pull request。

2. 用相同提示跑一个便宜模型和一个昂贵模型。

3. 用不是这两个模型之一的裁判验证发现，或者让裁判加人工抽查一部分。

4. 按仓库和 bug 类别拆分结果，因为平均值会掩盖弱点。

5. 重跑少量 PR，看结果波动有多大。

6. 比较每个已验证 bug 的成本，并单独查看漏掉代价高昂的那些类别。

常见问题

GPT-5.6 Luna 适合做代码审查吗？

对一般正确性 bug，它在这个基准上接近 Astra。Luna 找到 39 个数据与逻辑 bug，Astra 是 47 个，成本只是一小部分。对安全敏感的代码它落后很多，24 个安全 bug 中找到 9 个，Astra 找到 19 个。

Luna 比 Astra 每次审查便宜多少？

在这些 pull request 上，一次 Luna 审查花费 0.0041 美元，一次 Astra 审查花费 0.113 美元，约便宜 28 倍。按每个已验证 bug 算，Luna 是 0.0030 美元，Astra 是 0.061 美元。

Luna 比 Astra 更吵吗？

是的。Luna 的发现 74% 通过验证，Astra 是 96%，所以大约每四条 Luna 评论就有一条站不住。

应该两个模型都跑吗？

同时跑能找到 143 个已验证 bug 中的 117 个，50 个 pull request 总共花费 5.86 美元，而单跑 Astra 是 92 个。多出来的 bug 是否值得多出来的噪音，取决于你的团队如何处理审查评论。

可以复现吗？

可以。pull request 是公开的，提示、原始模型输出、裁判裁决、bug 类别标签、重复运行和评分脚本都随结果一并提交。

总结

Luna 以不到 4% 的成本找到了 Astra 四分之三的已验证 bug。它在认证和权限代码上落后最多，而那里漏掉一个 bug 的代价往往最大。让大多数变更走便宜审查、对安全敏感的变更给予更多审视，可以利用这个取舍，但前提是得知道哪些变更是哪些。

方法论：50 个来自 AI-Code-Review-Evals 的公开 pull request，由 GPT-5.6 Luna 和 GPT-6 Astra 用同一个只找 bug 的提示审查，2026 年 9 月。Luna、Astra、GPT-5.6 Sol 的发现以及公开的 Entelligence 审查评论按 PR 汇总，由 GPT-6 Astra 和 GPT-5.6 Sol 分别判定；只有两个裁判都同意的 bug 才计数。bug 类别由 GPT-5.6 Sol 标注。十个 pull request 每个模型审查了三次。价格方面，Luna 为每百万 token 0.20/1.20 美元，Astra 为 10/50 美元。

围绕「便宜的 AI 代码审查模型够不够用」这场讨论，社区总体并不买「按美元/发现 bug 数算性价比」的账，分歧核心是：便宜模型的漏报与误报代价是否被低估，以及审查质量到底由模型、流程还是人类判断决定。

认为便宜模型完全够用

• 单次审查多花一毛钱根本不算问题，没有哪家软件公司会为了省这点钱接受更差的审查、放过更多 bug（较多人）
• 便宜模型在只跑 diff、多轮循环、按角色拆分（安全、性能、结构、数据库）并配合文档与记忆时表现相当好，甚至能查出更强模型写出的问题（较多人）
• 任何模型都能提供价值，连小型本地模型也值得认真回应其意见（少数人） > 关键在于把便宜模型要关注的范围收窄，它们反而做得更好，大模型只负责综合与补漏。（@jbellis）
• 用便宜模型还是贵模型取决于代码本身的价值（少数人）

认为单价对比掩盖了漏报与误报的真实成本

• 文章只算「每个真 bug 的成本」，却忽略 Luna 漏掉 Astra 找到的 23 个问题、又报了 24 个假问题，约三分之二准确率意味着人还要花大量精力排掉噪音（高赞）
• 误报不是免费的：当另一个 AI 再去读这份审查、逐个验证假阳性时，会额外烧掉大量 token（较多人）
• 74% 与 96% 的准确率差距，落到日常工程里就是团队要不要把审查结果当基础工作的差别（较多人）
• 按绝对金额算，好模型的成本相对 bug 与人类注意力的代价依然很低，多花的钱远小于多得的价值（较多人）

认为审查的关键不在模型智能，而在上下文与流程

• 把最强智能用来做代码审查像请大厂 CTO 来给你审 PR，是杀鸡用牛刀；审查更多是文化上下文问题（较多人）
• 真正的变量是工具链（harness）：模型能不能用 shell 读仓库、拿到构建产物和项目说明，比模型档次更能决定效果（较多人）
• AI 该用在审查里，但不该把输出直接灌进 CI 和 PR：作者和至少两名审查者各自用 AI，再由人筛选后才呈现给作者，否则只是往流程里加噪音（较多人）
• 有团队转向「先脚本收集上下文、再让 agent 出意见」，但承认评论墙已经难以持续，下一步得让 agent 自己按人类意见改代码（少数人）
• 按变更复杂度选模型是常见做法：局部改动用便宜模型，深层或高风险改动才上更贵的（较多人）

对基准本身的怀疑

• 只比「发现 bug 总数」没有意义，便宜模型也能堆出海量低价值加固建议，应该比各自找到多少严重/高/中等级问题（较多人）
• 缺少「AI 味」指标：真正的问题不是漏 bug，而是报出一堆蠢问题，照着改就会把错误的地方过度工程化（较多人）
• 厂商卖代码审查服务，然后说便宜货适合入门、强力货适合进阶，这种结论天然可疑（少数人）

有价值的补充

• 有人的教训是，一次被模型误导的小改动会随时间演化成层层叠加的补丁，因为后续模型会把它当成既定策略而非错误；而且 AI 写的文字很容易让人走神，一批看似合理的建议里藏一条错的很难发现，问题的根源是人的松懈而非模型。
• 开源权重模型在同一套子代理与技能模式下，通常只能找到闭源强模型栈的四分之一到一半问题，还常漏掉最关键的那些；在隐私受法律强制约束的场景里，这种差距是实打实的。
• 有团队的实测结论是「便宜模型 + 多轮 + 多角色聚焦 + 人类评审规则文档化」这条路可行，配合无推理模式速度极快。
• 有人的经验是便宜模型在复杂代码库上做微小改动时，看不到非平凡的连带影响。

有价值的补充

• 多代理对抗式审查的成熟形态是：一个可配置的协调者做综合，下面挂六个各自专精（如代码复杂度）的小模型子代理，跨厂商组合。
• 使用 Anthropic 或 OpenAI 的包月订阅，可以在保持更高质量的同时拿到与便宜模型相近的实际折扣。
• 中文模型做审查有一个现实优势：可以直接要求它持对抗立场主动找安全问题，而不必担心被拒答，代价是大 PR 上速度较慢。

值得注意的一条玩笑

• 有人把这类结论总结为「卖代码审查的公司说便宜的可卡因适合入门用户，强力的可卡因才配得上高级用户」——代表了不少人对厂商自带基准的不信任。