GPT-5.6 Luna 能胜任代码审查吗？
GPT-5.6 Luna vs. GPT-6 Astra: Is a $1.20 Model Good Enough for Code Review?
我们将 GPT-5.6 Luna 与 GPT-6 Astra 在 50 个公共代码审查基准上进行了实测。结果显示，Luna 的成本仅为 Astra 的 3.6%，但找到的已验证漏洞数量是后者的 75%。Luna 在常规逻辑错误上表现不错，但在安全敏感代码（如 Keycloak 的权限逻辑）上明显落后，且误报率较高。对于日常正确性检查，廉价模型已足够；但涉及认证或权限代码时，仍需更强大的模型把关。
Luna 在那个价格下足以应对日常的正确性漏洞，但我们绝不会让它独自审查认证或权限代码。
HN 评论区
151- nonethewiser
AI 应该用于代码审查，但不应直接集成到 CI 中。
你本来就应该有 2 名以上的开发者来审查大多数 PR。这些开发者绝对应该使用 AI。PR 作者也应该使用 AI。
但你不应该做的是将 AI 的输出直接灌入 PR，然后让 PR 作者去处理。这只是在 PR 审查流程中增加了噪音。AI 说的每一句话，PR 作者都需要验证其相关性、有用性等。在把结果抛给作者之前，必须由人来完成这一步。
你不会让一个代理审查 PR，然后直接把输出复制粘贴到 PR 里吧？
- jacobgold
IMHO，到 2026 年 9 月，任何专业程序员如果付得起钱，都应该使用 Codex 搭配 Astra/Sol，以及 Claude 搭配 Fable/Opus。
这些模型与我们真正期望的水平相比仍然糟糕透顶，但它们是目前最好的选择。
如果你能搞定每月 200 美元的订阅费，对大多数专业人士来说，这根本就不是钱的问题。
我几乎所有的工作流程现在都是：规划、生成、审查、规划、生成、审查、提交、推送。
我正在使用 Claude 或 Codex（或两者都用），它们现在都在“内联”执行所有测试，而不是通过 CI 动作等方式。
- InsideOutSanta
我只用中文模型做代码审查，因为你可以明确指示它们采取对抗性立场，积极寻找安全问题，而不用担心被拒绝。GLM-5.3 在这方面表现很棒，尽管在处理大型 PR 时可能会比较慢。
- StevenWaterman
每次 PR 审查多花 0.10 美元根本不算什么。哪家软件公司愿意为了省 10 美分而接受更差的审查结果和更少的漏洞发现？
- CharlieDigital
我发现只要满足几个条件，Luna 甚至 5.4-mini 在代码审查方面表现相当不错：
1. 多轮运行，仅针对 diff，且每次只输出少量发现。
2. 给它配备记忆功能，这样每一轮它都知道之前的发现，以便检查是否已修复。
3. 让它能访问编码了人工审查启发式规则的权威文档。我将这些暴露为工具调用，以便通过遥测进行追踪。
4. 运行多个审查员，每个都有明确的专注点。安全、性能、结构、数据库等。每个都是独立的提示和角色设定。此外，我们还有文件激活过滤器，确保前端 React 审查员不会在后端仅有变更时触发。
Luna 和 5.4-mini 在没有推理能力的情况下速度极快，几乎总能发现由 Opus 和 Fable 生成的代码中的问题。
供好奇者参考的默认提示（这些是默认部署的模板，但可自定义）。
性能：https://github.com/zeeq-ai/zeeq-app/blob/main/src/backend/Ze...
结构：https://github.com/zeeq-ai/zeeq-app/blob/main/src/backend/Ze...
（请记住，每个代理也有工具可以访问和引用外部文档。）
- gregwebs
他们声称 Luna 已经够好了，但其发现准确率只有 74%，而 Astra 是 96%。处理误报的成本很高。
我发现让 AI 作为流程的一部分进行自主审查是提升生产力的关键。我在多个阶段使用子代理（基于新上下文的审查），并配合明确定义的审查标准。使用 OpenAI 或 Claude 的 API 计费来做这件事非常昂贵。使用 Deepseek，或者 OpenAI/Claude 的折扣月度计划，可以像他们声称的 Luna 相比 Astra 的 28 倍那样获得折扣，同时保持更高的质量。
- rektomatic
误报确实有真实成本，尤其是当 AI 自己在读审查报告时。试想一下，如果你让 GPT-6 Astra 去审查一份报告，结果发现一堆误报，它就得消耗大量 token 去搞清楚状况。
- SwellJoe
我有一段时间非常虔诚地使用 Copilot Code Review，因为我的开源工作让我免费获得了访问权限（10 美元套餐），但它最近引入了一个巨大的反功能，导致随着时间推移复杂性急剧增加，而我当时没有足够关注这一点。随后的每个模型都看到了这个变更和变更日志中的解释，并误以为这是政策而非模型“脑残”导致的，结果演变成了一团我不得不借助优质模型和严密的人工监督才能解开的“分形混乱”。那是一个直接编辑服务配置文件的行政工具。Copilot 代码审查却决定它需要成为一个叠加服务，仅应用由我们配置 UI 创建的配置，完全独立于系统服务。随后其他 LLM“修复”的所谓“bug”，只是在这个糟糕的决定上不断打补丁（将服务绑定在一起，以便重启其中一个时随后重启另一个，确保文件间无冲突，当一条规则与另一条冲突时发出警告等）。因为修改额外服务根本不是该工具的设计用途，所以它显得非常 buggy，于是就有了大量的“修复”。我花了太长时间才意识到根本性的故障点。
我想表达的意思是，我犹豫是否要信任一个愚蠢的模型来做代码审查，因为我会变得自满，而当它建议一个看似合理的小改动时（LLM 非常……