# GPT-5.6 Luna 代码审查只要半分钱，但安全漏洞让它不值这个价 **Summary:** 在 50 个 PR 基准测试中，GPT-5.6 Luna 每次审查花费 0.0041 美元，但仅发现 24 个安全漏洞中的 9 个，且有 24 项发现未能通过验证。我会用它做初步筛查，再根据代码风险升级审查。 - Canonical: https://markhuang.ai/zh/news/gpt-5-6-luna-review-attention-tax - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-14 - Section: News - Tags: GPT-5.6 Luna, GPT-6 Astra, AI 代码审查, 模型路由, 软件安全 - Source: [Entelligence](https://entelligence.ai/blogs/gpt-5.6-luna-vs-gpt-6-astra-is-a-1.20-model-good-enough-for-code-review) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![两台代码检查机器正在分拣金属代码块和破损的安全锁，便宜的扫描仪产生大量琥珀色警告，而精密扫描仪使用聚焦的蓝色光束](https://cdn.markhuang.ai/news/gpt-5-6-luna-review-attention-tax/hero.webp) *当廉价审查产生的噪音和遗漏消耗了本该节省的工程时间时，它就不再便宜了。* [Entelligence 拿 GPT-5.6 Luna 和 GPT-6 Astra 跑了同一批 50 个公开 pull request](https://entelligence.ai/blogs/gpt-5.6-luna-vs-gpt-6-astra-is-a-1.20-model-good-enough-for-code-review)。Luna 跑完一共花了 0.20 美元，折合每次审查 0.0041 美元，找到 69 个已验证的 bug。Astra 花了 5.66 美元，找到 92 个。 乍一看，Luna 显然是默认选择。但算起后续的人力成本，画面就不一样了。Luna 的 93 项发现里有 24 项没通过验证，Astra 的 96 项里只有 4 项没过。24 个安全漏洞，Luna 只抓到 9 个，Astra 抓到了 19 个。我会拿 Luna 做第一轮筛选，但不会让 token 价格来决定谁有最终拍板权。 ## 二十美分买到了覆盖范围，而非信心 测试用了 Cal.com、Sentry、Discourse、Keycloak 和 Grafana 各十个 pull request。两个模型拿到同样的 diff，跑的是一个只找 bug 的 prompt，覆盖正确性、安全性、并发性、资源使用和错误处理。底层仓库在 [AI Code Review Evals 组织](https://github.com/AI-Code-Review-Evals) 里公开。 Entelligence 把 Luna、Astra、GPT-5.6 Sol 和自家审查工具的结果汇总在一起。Astra 和 Sol 分别对照 diff 评判每个匿名问题，只有两边都认定问题存在才算通过。它们在 91% 的发现上意见一致，最终接受了 143 个不同的 bug。 这个基准测试没有列出每个 pull request 里的全部 bug，所以 143 只是个下限，不是召回率。Astra 本身也是裁判之一。要求 Sol 也同意能削弱这个优势，但没法完全消除。 ## 误报消耗的是人的时间 Luna 的 token 花费很少，但开发者花在上面的注意力可不少。这次测试里，开发者大约得拒掉它四分之一的发现。要是每个 pull request 都冒出一堆评论，人就会养成扫一眼就跳过的习惯。真正该看的警告，恰恰在这种时候最容易被漏掉。 这不是 Luna 独有的问题。2026 年一项[对 31,073 条智能体代码审查评论和开发者回应的研究](https://arxiv.org/abs/2607.03316)显示，56.3% 的评论被拒。研究看的是 CodeRabbit，所以这个数字不能直接拿来跟这次基准比。但它说明了一件事：光看命中率不够，还得把审查员的行为模式一起摆上台面。 GitHub 自己的[AI 安全功能使用指南](https://docs.github.com/en/code-security/responsible-use/security-and-quality-ai-features)也提到了检测不完整、误报、上下文不足和结果不确定等问题。一条评论生成只要几分之一美分，但开发者去排查可能就要花掉好几分钟。 ## 安全问题打破了性价比 比起总数 69 对 92，我更在意按类别拆开看。Luna 找到 39 个数据和逻辑 bug，Astra 找到 47 个；并发问题 Luna 10 个，Astra 13 个。差距最大的是安全漏洞：Luna 只抓到 9 个，Astra 抓到了 19 个。 Keycloak 这个仓库也暴露了同样的短板。Luna 在那里找到 6 个已验证的 bug，Astra 找到 14 个，而且 Luna 在 Keycloak 上的发现只有一半站得住脚。Entelligence 说，这些基准 pull request 大多改的是认证或权限逻辑。其中两个漏掉的分别是可复用恢复码和全局权限覆盖单个客户端拒绝的问题。影响面这么大的代码，“平均还行”可不够。 OpenAI 把[GPT-5.6 Luna](https://developers.openai.com/api/docs/models/gpt-5.6-luna)定位成成本敏感、高吞吐场景的模型，定价是每百万输入 token 0.20 美元，每百万输出 token 1.20 美元。[GPT-6 Astra](https://developers.openai.com/api/docs/models/gpt-6-astra)的价格则是 10 美元和 50 美元。Luna 在这个价位上确实提供了不错的覆盖面，但我不会让所有类型的代码都接受同样标准的覆盖。 > **Info:** > > 我会在模型开始审查之前就先把风险分好类。认证、授权、支付、密钥、数据删除和边界校验这类代码，应该直接走更强的审查通道——看的是这段代码能造成多大影响，而不是因为便宜的审查工具碰巧给了个不确定的结果。 ## 一个 diff 看不出它会牵连什么 两个模型只能看到 diff，别的什么都没有。没有仓库历史，没有调用图，也没有生产环境数据。比较是控制住了，但判断一个改动到底牵不牵涉登录流程或资金操作所需的上下文也没了。 我不会让 Luna 自己决定往哪送。外围系统应该知道哪些路径有安全负责人、哪些服务碰钱或身份信息，在模型写评论之前就把这些 diff 转给 Astra、安全工具或人工专家。 Luna 在工作流里还是有位置的。它找到了 25 个 Astra 漏掉的已验证 bug。两个模型一起跑，花 5.86 美元抓到 143 个里的 117 个；Astra 单跑花 5.66 美元抓到 92 个。我会把这种双模型审查用在特定改动上，也拿来抽查便宜通道漏了什么。 ## 一次运行是靠不住的承诺 Entelligence 用同样的设置对十个 pull request 重跑了两次。每个模型在这个子集的第一轮都找到 15 个已验证的 bug。Astra 两次重复各重现了 10 个；Luna 只重现了 7 个。样本不大，但这个波动已经够让人对"跑一次就下结论"的做法打问号了。 Entelligence 还查了公开代码有没有泄露进训练数据。这些 pull request 的时间跨度从 2013 年到 2025 年 7 月 25 日，都在两个模型公开的训练截止日期之前。基准测试里的缺陷是故意植入的，也就是说模型不可能"记住"那些具体的错误 diff。但周围的代码毕竟是公开的，模型见过正确的写法也可能间接受益。这个测试没法完全打消这个疑虑。 我把这个结果当成一次候选评估，跟我[讨论模型失败率](https://markhuang.ai/news/model-build-offs-need-failure-rates)时做的构建对比一个性质——它告诉我哪个模型值得在自家仓库上试一试，但试这一步不能省。 ## 我会如何花掉省下的钱 我会在常规 pull request 上跑 Luna，prompt 写得窄一点，要求每条发现都写清楚具体的故障路径。我会追踪被接受的评论，也会抽查那些"干净通过"的审查，看看后面有没有被更强的模型翻出 bug。 高风险路径不走这个默认流程。它们要上更强的模型、能跑的确定性安全检查，再加上靠谱的人。所谓"安全通道"我也会抽样复查，因为路由本身就可能出错——审查还没开始，分错类就已经出问题了。省下来的 token 预算应该花在验证上，而不是换来更大一堆评论。 ## 半分钱的审查仍然需要负责人 我会把 Luna 当侦察兵用。它足够便宜，能覆盖常规改动，也确实找到了 Astra 漏掉的真实 bug。但我不会让它碰认证和权限代码，也不会拿评论数量来衡量效果。 我真正想看的指标是每个被接受发现的成本，然后更难回答的问题：漏了什么？Entelligence 的数据说明 Luna 值得一试，但它的安全短板也意味着路由和审计是部署成本的一部分，省不掉。