代码审查是软件交付流水线上最后一道守门关卡，也是眼下大模型落地上最费钱的无底洞。当工程团队试图把全量 Pull Request 统统接进大模型时，随之而来的账单往往令人咂舌。AI 评测机构 Entelligence 最近公布了一组横向对比数据，直接击中了研发团队最敏感的神经：用极度廉价的 GPT-5.6 Luna 去跑 50 个开源项目的代码审查，总共只花了 0.20 美元，抓出了 69 个缺陷；而用旗舰模型 GPT-6 Astra，账单飙升到 5.66 美元，抓出 92 个缺陷。
表面上看，这是一个近乎奇迹的降本案例：只用 Astra 约 3.6% 的成本，就捞回了旗舰模型 75% 的有效缺陷，单个缺陷的捕获成本更是便宜了 20 倍。但工程决策向来没有免费的午餐，只要把账本往细了翻，这种省钱神话立刻就会露出代价昂贵的另一面。
算小账省了 API，算大账亏了工程师
许多团队看到低价模型，第一反应是直接把单价折算进流水线。OpenAI 的官方定价里，GPT-5.6 Luna 的每百万输入和输出 Token 标价为 0.20 美元与 1.20 美元，而 GPT-6 Astra 是 10 美元与 50 美元，输入和输出价差分别达到了 50 倍和 42 倍。如果单纯看 API 扣费，平均一次 Luna 审查只需 0.0041 美元，而 Astra 要花 0.113 美元，确实相差 28 倍。
然而在真实世界里，代码审查最贵的永远不是计算资源，而是工程师的注意力。
Luna 在 50 个 Pull Request 里一共提出了 93 条修改意见，其中有多达 24 条无法通过验证，精确度只有 74%。相比之下，Astra 提出的 96 条意见中仅有 4 条不符，精确度高达 96%。这意味着如果全面换用 Luna，研发人员每看四条 AI 留下的评论，就有一条是彻头彻尾的误报。
这种杂音会迅速引发严重的警报疲劳。当团队发现自动化工具频频胡言乱语，最自然的应对不是耐心纠错，而是连同真正有价值的警报一起闭眼滑过。为了省下每千次审查几十美元的 API 开销，换来的是高级工程师每天花费数十分钟逐一辨别误报，甚至直接忽略代码审查通知。
- 风险.API 账单的节约显而易见，但 26% 误报率造成的精力损耗隐蔽且昂贵。
更重要的是真实场景的算力隐藏成本。社区实测表明，Luna 必须在开启最高推理量的设置下，才能把误报率压制在可用区间；一旦放在低推理档位，在 Rust、TypeScript 和 SQL 代码库中的假阳性率便会急剧攀升。而根据 OpenAI 规则，长 Prompt 和缓存写入更有独立的计费区间。企图用最便宜的运行模式拿下可靠的代码审查，从一开始就是对复杂度的低估。
权限与安全：廉价模型的阿喀琉斯之踵
如果说普通的逻辑错误还能靠人工复核托底，安全缺陷上的偏科则是更致命的问题。
在 Sentry、Discourse 和 Grafana 这类偏业务逻辑与数据流的代码库中，Luna 的表现与 Astra 相差无几，捕获的缺陷只差两三个。但在负责身份认证与权限管理的 Keycloak 仓库中，断层出现了：Astra 找出了 14 个缺陷，Luna 只抓出了 6 个，审查精确度在这一场景下腰斩至 50%。
具体到全量缺陷分类上，Luna 在常规数据与逻辑漏洞上抓出了 39 个，逼近 Astra 的 47 个；但在 24 个安全与权限漏洞中，Luna 仅勉强捕获了 9 个，而 Astra 抓出了 19 个。
| 漏洞类型 | 缺陷总数 | GPT-5.6 Luna 捕获 | GPT-6 Astra 捕获 | 检出差距判断 |
|---|---|---|---|---|
| 业务逻辑与数据流 | 47 | 39 | 47 | 差距极小，小模型性价比突出 |
| 并发与时序问题 | 13 | 10 | 13 | 表现接近，常态排查基本堪用 |
| 安全与身份权限 | 24 | 9 | 19 | 断崖式落后，关键防线严重失守 |
这种分化揭示了模型底层能力的本质差异。第三方独立评估数据显示，Luna 在功能实现上的得分可以达到 70/100，但在代码审查维度仅有 38/100。写代码是顺着指令正向生成，审查代码却需要逆向推演时序、上下文依赖与攻击面。
Astra 抓出而 Luna 漏掉的 Keycloak 缺陷极具代表性：其一是联合恢复码在使用后从未被标记为已失效，导致可以无限次重复兑换；其二是全局查看权限意外覆盖了针对单个客户端设定的拒绝策略。在这类代码中，没有任何一行有明显的语法硬伤，只有在脑海中把整套权限状态机的转移逻辑完整跑一遍，才能看出破绽。
差的代码审查工具挑出语法瑕疵，好的代码审查工具防住毁灭性的隐性逻辑漏洞。
只给模型输入单纯的 Diff 补丁，原本就剥离了调用图与项目依赖关系。如果再配上推理深度不足的小模型，整个鉴权防护网在上线那一刻起就变成了筛子。
评测黑盒之外的数字幻觉
仔细剖析这次评测本身，也能发现不少值得警惕的方法论陷阱。
评测所依赖的 AI-Code-Review-Evals 黄金数据集，实际上包含 167 个经过人工确认的真实缺陷。而在本次测试中，汇总两家模型并经过交叉裁决后，进入池子的缺陷仅有 143 个。这意味着有 24 个以上的硬伤在最初就从所有模型的视野里滑落了，根本没有进入对比分母。
不仅如此，评测的裁判席是由 GPT-6 Astra 和 GPT-5.6 Sol 共同担任，只有两者都认可的缺陷才算数。让 Astra 既当参赛选手又当裁判之一，即便有 Sol 形成制衡，也难免带来隐性偏向。更关键的是，Entelligence 自身更广维度的测试显示，在所有被测仓库的生产环境真实缺陷中，其审查方案的综合 F1 分数仅为 47.2%。所谓 3 美厘抓出一个 Bug 的口号，很大程度上是在受限规则下跑出来的数字奇观。
单次运行的不稳定性同样显著。在十个 PR 的重复复测中，Astra 在全部重测中能稳定复现 67% 的缺陷，而 Luna 只有 47%。廉价模型如同一个注意力飘忽的质检员，这一次碰巧指出的问题，下一轮提交时可能就视若无睹。
告别二选一：分级门控才是工程解法
面对 28 倍的价格鸿沟与不可忽视的漏检风险，非黑即白的二选一并不是理性的工程态度。
在这组测试中，最具启发性的其实是一个衍生实验：如果让 Luna 和 Astra 在 50 个 Pull Request 上协同工作，Luna 能够凭借其独特的关注点抓出 25 个 Astra 错漏的逻辑问题，而两家联手能覆盖 143 个缺陷中的 117 个，覆盖率直接拉升到 82%。为此多付出的代价，仅仅是在 Astra 5.66 美元的账单上多加了 Luna 的 0.20 美元。
- 建议.将普查筛选与高危卡口分离，用路由机制替代单一模型的全量赌注。
古人讲「见微知著，防微杜渐」，在流水线工程里，最糟糕的策略是用高射炮打蚊子，或是让守门人打瞌睡。成熟的落地形态应当建立门控路由机制：普通的前端调整、文案变动或日常逻辑增改，完全可以由 Luna 这类廉价模型做快速普查；一旦提交路径触发了认证中心、加解密配置、鉴权规则或底层并发组件，系统便自动切入 Astra 这种重型模型进行深层推演。
技术演进的浪潮从来不是单向的参数碾压。学会把便宜的模型放在消耗注意力的边缘战场，把昂贵的旗舰钉死在关乎生死的关键隘口，远比单纯纠结那几美厘的 Token 标价要重要得多。