GPT-5.6 Luna vs GPT-6 Astra：1.2美元模型做Code Review够用吗

GPT-5.6 Luna vs GPT-6 Astra：1.2美元模型做Code Review够用吗 | 前端进阶之旅

Full translation

完整中文译文

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 都走最便宜的模型，你会牺牲什么。

Luna 在 50 个 Pull Request 中找到了 69 个经核实的 Bug。Astra 找到了 92 个。Luna 全程花费 $0.20，Astra 花费 $5.66。Luna 的错误更频繁，93 个发现中有 24 个未通过 Astra 的核实，而 Astra 96 个发现中只有 4 个未通过；Luna 找到了 24 个安全 Bug 中的 9 个，Astra 找到了 19 个。

我们的判断：在这个价格下，Luna 对于日常正确性 Bug 已经足够好，但我们不会让它独自评审认证或权限相关代码。

我们复用了 Astra vs Sol 文章的设置，所以数据可以对照。

这些 Pull Request 是 AI-Code-Review-Evals 组织中的 50 个公开基准 PR，分别来自 Cal.com、Sentry、Discourse、Keycloak 和 Grafana 各 10 个。每个 PR 都在一个干净的 base branch 上引入了缺陷。

Luna 和 Astra 在同样的 Diff 上收到同样的 Prompt。Prompt 要求找出正确性、安全性、并发、资源和错误处理方面的 Bug，不涉及样式、命名、文档和测试建议。每个模型返回结构化的发现。

核实流程与之前相同。对于每个 Pull Request，Astra、Sol、Luna 和公开的 Entelligence 评审意见全部放入一份匿名列表。GPT-6 Astra 和 GPT-5.6 Sol 各自独立根据 Diff 对该列表做出判断，合并重复项并决定每个问题是否真的是 Bug。只有两个评判都认为是真实的 Bug 才计入核实。两人在 91% 的发现上达成一致，143 个不同的 Bug 同时通过了两方评判。

将 Luna 的发现加入后，评判者看到的池子变了，所以所有内容重新评判了一遍。Astra 的核实数量从上篇文章的 91 上升到这里的 92，Sol 从 107 上升到 108。Astra 同时也是两个评判者之一，这可能对它略有偏斜。限制一节会讨论这一点。

	GPT-5.6 Luna	GPT-6 Astra
Verified bugs	69	92
Findings raised	93	96
Precision	74%	96%
Total cost, 50 PRs	$0.20	$5.66
Cost per verified bug	$0.0030	$0.061
Mean time per review	23s	36s
Mean output tokens per review	2,104	688

Luna 以 Astra 3.6% 的成本找到了其 75% 的已核实 Bug。每个已核实 Bug，Astra 成本高 20 倍。

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

你的团队会首先感受到精确度上的差距。大约每四个 Luna 评论中就有一个是错的，而 Astra 在 96 个里只错了 4 次。原本已经在浏览 AI 评审意见的开发者，当四分之一的评论都是噪音时，会浏览得更加敷衍。

Luna 落后在哪里

上篇文章的读者要求我们按代码库和 Bug 类型拆分结果，因为一个总分可能掩盖某个模型在一个仓库表现好而在另一个表现差的情况。在这个数据上，拆分结果揭示了 Luna 的漏报来源。

在 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 个。并发方面 Luna 找到 10 个，Astra 13 个。安全方面 Luna 找到 9 个（共 24 个），Astra 找到 19 个。

Astra 捕获而 Luna 漏掉的两个 Keycloak Bug：

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

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

单独看任何一行都没有问题。只有推导出变更后权限模型允许什么，才能发现它们。

Luna 捕获而 Astra 漏掉的 Bug

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。这是 Luna 的 $0.20 加上 Astra 的 $5.66，换来 25 个额外的已核实 Bug。

读者要求我们验证的内容

模型是否只是记住了修复方案？

一位读者指出这些仓库是公开的，基准 Bug 的修复可能已经在它们的历史中存在。在这个修复之后训练的模型可能是在回忆它已经见过的补丁。建议的测试方法是按日期拆分 Pull Request，看在各模型的训练截止日期之后的变更上，排名是否仍然成立。

我们无法在这个基准上运行这个拆分。我们拉取了每个 PR 背后的提交日期，范围从 2013 年到 2025 年 7 月 25 日。其中 20 个来自 2025 年，但没有足够新的能落在任一模型的截止日期之后。cutoff 之后的组会是空的。

这个风险比听起来要小，因为这些 PR 中的缺陷是专门为基准而添加的，所以每个 Diff 中的确切 Bug 不是模型可能训练过的提交。不过周围代码是旧的、公开的，而知道正确版本长什么样的模型是有优势的。要正确测试这一点需要比这些模型更新的 Pull Request，而这个基准无法提供。

模型是否会重复找到同一个 Bug？

另一位读者要求我们用相同的设置重新运行一些 PR。我们每个代码库各选了 2 个 PR，每个模型再跑两次。

从第一次运行，Astra 在这 10 个 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 真实数量更高，因为没有任何评审者标注的 Bug 永远不会进入池子。

本次对比的限制

除那 10 个重复的 PR 外，每个模型对每个 PR 只评审了一次，而重复运行表明结果在每次运行之间会有浮动。

Astra 既是参赛者也是两个评判者之一。要求 Sol 同意可以减少偏斜，但无法消除。

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

两个模型都只看 Diff，不看其他任何东西。它们没有仓库历史、调用图或生产数据。

核实数量是存在的 Bug 的下限，基准没有完整的 Bug 列表来对比。

Diff 没有告诉模型什么

在这个基准上，便宜模型在大多数变更上表现良好，在认证和权限代码上表现很差。仅凭一个 Diff 本身无法告诉模型它正在评审哪种类型的变更。

知道某个文件处于授权路径上、某个函数从登录流程中被调用，或者类似的变更上季度曾引发过事故，这些信息决定了变更应该被审查得多仔细。Entelligence 代码评审用完整的仓库上下文来评审 Pull Request，并将生产行为反馈到后续评审中——这正是只有 Diff 的模型所缺失的信息。

对于编码 Agent，Entelligence Model Router 将常规步骤发送到更便宜的模型，将更难的任务发送给更强的模型。我们之前的 Terminal-Bench 对比涵盖了这在 Agent 任务上的表现。

用你自己的代码跑这个

从你的仓库中收集 30 到 50 个合并后需要修复的 Pull Request。

用相同的 Prompt 运行一个便宜模型和一个贵模型。

用一个不是这两个模型之一的评判者核实发现，或者让评判者和人工共同检查一个样本。

按仓库和 Bug 类型拆分结果，因为平均数会掩盖弱点。

重新跑几个 PR 来看结果浮动有多大。

比较每个已核实 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 评论中就有一个站不住脚。

应该同时跑两个模型吗？

同时运行两个模型在 50 个 Pull Request 上找到了 143 个已核实 Bug 中的 117 个，花费 $5.86，而单独使用 Astra 找到了 92 个。额外的 Bug 是否值得额外的噪音，取决于你的团队如何处理评审意见。

我能复现这个吗？

可以。Pull Request 是公开的，Prompt、原始模型输出、评判裁决、Bug 类型标注、重复运行和评分脚本都随本文一起提交。

Luna 以不到 4% 的成本找到了 Astra 四分之三的已核实 Bug。它在认证和权限代码上落后最多，而这类 Bug 漏报的代价往往是最高的。一个能廉价评审大多数变更、同时对安全敏感的变更给予更仔细审查的方案可以利用这个权衡，但它需要知道哪些变更是哪些。

了解 Entelligence 如何用完整的仓库上下文评审 Pull Request。

方法论：50 个来自 AI-Code-Review-Evals 的公开 Pull Request，由 GPT-5.6 Luna 和 GPT-6 Astra 使用相同的仅查 Bug Prompt 进行评审，时间为 2026 年 9 月。Luna、Astra、GPT-5.6 Sol 和公开 Entelligence 评审意见的发现按 Pull Request 汇总后，由 GPT-6 Astra 和 GPT-5.6 Sol 分别评判；一个 Bug 只有在两个评判者都同意时才计入核实。Bug 分类由 GPT-5.6 Sol 标注。10 个 Pull Request 每个模型评审三次。价格为 Luna $0.20/$1.20 每百万 token，Astra $10/$50 每百万 token。

GPT-6 Astra 比 GPT-5.6 Sol 每个已核实 Bug 成本高 1.6 倍 ›

我们在 $5M 融资下让你的工程团队实现自动驾驶

观看我们的发布视频

这个 AI 工程师会评审每个 Pull Request 对照你的事故历史、监控生产，并在出问题时自我修复。同类 Bug 不会再次上线。

联系我们的团队，了解 Entelligence 如何帮助工程领导者全面了解迭代表现、团队洞察和产品交付。