先把结论摆上桌：同一套提示词、同样 50 个公开基准 PR，便宜的 GPT-5.6 Luna 抓出 69 个经验证的真实 bug，贵的 GPT-6 Astra 抓出 92 个，账单是 0.20 美元 对 5.66 美元。这不是一场跑分表演，而是 Entelligence 做的一次成本敏感型代码评审对照实验。28 倍的价差，换来 33% 的召回提升，以及从 74% 跳到 96% 的精度。问题随之而来——多出来的那 23 个 bug，值不值五个多美元？
价差 28 倍，差的到底是什么
五十个 PR，一套提示词，没有花活
Entelligence 的实验设计很朴素：挑 50 个公开基准 PR，给两个模型一模一样的提示词，然后数结果。没有提示词工程的花招，没有针对某一方特调的上下文，也不给谁开小灶。这种"裸测"的价值在于，它衡量的不是哪家的 prompt 写得巧，而是模型本体在代码评审任务上的真实下限。不少对比文章恰恰栽在这里——把提示词调优的收益算进模型能力，结论就没法迁移了。50 个 PR 样本谈不上大，但足够看出两个价格档位在召回与精度上的分布差异，而不是一个孤零零的分数。
69 与 92：召回曲线的真实形状
数字很直白。Luna 找到 69 个经过验证的 bug，Astra 找到 92 个，差距 23 个，约 33% 的召回提升。听起来不算惊天动地——直到把成本放进去算。跑完这 50 个 PR，Luna 只花了 0.20 美元，Astra 花了 5.66 美元。召回从 69 涨到 92，价格涨了 28 倍。这笔账对不同规模的团队意味完全不同：一天跑几十个 PR 的个人项目，0.20 美元几乎等于免费；每天几百上千个 PR 的平台团队，5.66 美元会迅速变成需要预算审批的固定开支。
精度 74% 意味着什么
精度那一栏才是真正的分水岭。Luna 74%，Astra 96%。换算成体感：Luna 每报出四条问题，就有一条是噪音。代码评审的误报跟搜索结果的误报完全不是一回事——开发者会认真读每一条评论，被打扰四次里有一次白读，耐心消耗得非常快。96% 听着接近可用，可那剩下的 4% 同样会准时出现在最忙的人眼前。精度不是锦上添花的加分项，它直接决定这个工具能不能被长期留在 CI 流程里。
误报的账单，比调用费用更难算
开发者信任是有限资源
API 账单每月都能看到，信任的流失没有发票。一个评审机器人前两周表现不错，第三周开始持续报出无关痛痒的风格问题和误判的逻辑问题，团队就会条件反射地滑过它的评论。到这一步，它哪怕抓到了真正的空指针，也没人看了。这就是误报的隐性成本——不体现在美元上，体现在整个团队对自动化的容忍度上。74% 和 96% 的差距，落到日常里就是"要不要再信它一次"的频率差异。
每个美元抓到几个 bug
换个算法会更清楚。Luna 用 0.20 美元换 69 个有效发现，约合每 0.003 美元一个 bug。Astra 用 5.66 美元换 92 个，单次有效发现接近 0.06 美元，贵了将近 20 倍。光看这几个数，结论似乎是闭眼选便宜的那个。可镜头拉近一点：那 92 个里有 23 个是 Luna 完全漏掉的。漏掉的 bug 一旦流进生产环境，修复成本的量级是评审阶段的一百倍起步。成本对比从来不是单价比单价，而是单价乘以漏检后果之后再比。
高价模型该被安排在哪一段流水线
所以真问题不是"用哪个"，而是"在哪个环节用哪个"。一个务实的排布是：每笔提交先过便宜模型，让它快速筛掉显性问题；只有当改动牵扯核心模块、支付逻辑或数据迁移时，才把 diff 交给高价模型跑第二轮。这样绝大多数流量停在廉价档，昂贵的精度只花在真正烧钱的地方。工程上这叫分级处理，跟缓存策略、索引策略是同一套思路——把贵的算力用在刀刃上，而不是平均撒出去。
把评测做厚：按仓库、按类别切开看
不同代码库，难度本来就不一样
整体召回率会掩盖很多东西。一个模型在样板化严重、风格统一的仓库里可能表现亮眼，换到历史悠久、约定混乱的老项目就立刻掉链子。Entelligence 按仓库分层看结果，这一步看着朴素，实际是把"模型好不好"拆成了"模型在哪类代码上好不好"。对准备选型的技术负责人来说，后者才是可操作的信息——你不需要知道它在全球的平均分，你需要知道它在你那三个主力仓库上什么水平。
bug 类型决定模型表现
按类别切开，往往能看到更剧烈的不均衡。空指针、边界条件、资源泄漏、并发竞态、权限校验遗漏，这些类型对模型的要求天差地别。有的靠模式匹配就能拿下，有的必须做跨文件调用链推理。整体 74% 的精度，很可能意味着它在你最关心的那一类是 90%，在你不太在乎的地方只有 55%。类别维度的分层，是把平均值还原成决策依据的唯一办法。
可复现的脚本，比一张排行榜管用
这次对比最值得抄走的其实不是结论，是方法本身。公开基准 PR、统一提示词、可复现脚本、按仓库与类别分层——这套组合让任何人都能在自己的代码库上跑一遍，而不是等别人给一个跟自己无关的分数。模型榜单的寿命通常只有几周，下一版发布就全部作废。一套跑在自己仓库上的评测脚本却能跟着模型迭代反复使用。把评测能力攥在自己手里，比选对某一代模型重要得多。
给团队的一张选择清单
双档并行不是折中，是策略
看到 0.20 对 5.66，很多人的第一反应是"那就用便宜的"。这个判断下得太快。更稳的做法是承认两档模型各有适用面：低价模型承担高频、低风险的常规评审，高价模型在关键变更上兜底。这不是和稀泥，而是承认工程系统本来就该按风险分级配置资源。真要把这条抄回去，就写进 CI 配置里，别只写在某个人的记忆里。
把人工复核留在关键路径上
96% 的精度依然不是 100%。代码评审这件事，最后签字的人还是人。模型的价值在于把人的注意力从"找问题"迁移到"判断问题重不重要"。这层迁移能不能做成，取决于两件事：误报率够不够低，以及工具能不能把发现按严重程度排好序。74% 精度的模型报三十条，人得看三十条；96% 精度的模型报十条，人看十条就能拍板。省下的不是模型调用费，是工程师的时间，而后者才是真正的大头。
模型迭代太快，别把架构焊死在价格上
几个月前还只属于旗舰档的能力，会一路下沉到便宜档。今天 0.20 美元做不到的事，下一代小模型很可能顺手就做了。所以架构上必须留出换模型的余地：把评审逻辑和模型调用解耦，切换供应商或版本只需要改一个配置项。绑死在某个价格档位上的流水线，会在下一次模型发布时变成技术债。可替换性，比当下的性价比更值得投资。
