如何让 AI 程序写得更慢，但更正确：多模型 PR 审查，让 Bug 机率压到最低

前微软资深工程師 Nolan Lawson 用 Claude、Codex、Cursor Bugbot 三个模型同步審查 PR，交叉验证將誤报率壓到接近零。
（前情提要：Claude Code 宣布每週 Token 使用上限增加 50%！为期两个月 Anthropic 搶佔开发者生態）
（背景補充：Stripe 啟动 AI Agent 全自动支付測試：透过 x402 支援 Base 链 USDC 付款）

本文目錄

Toggle

• LLM 天生擅长找 bug
• 多模型審查的交叉验证逻辑
• 速度下降，品质上升

我們知道 AI coding 的優勢是「快速产出大量程式碼」，但是正確度就有待商榷。前微软、Salesforce 资深工程師 Nolan Lawson 最近在部落格記錄了一套新的工作流程：他用多个大型语言模型同步審查每一个 pull request（程式碼合併请求，簡單来说就是每一次把新程式碼送进專案的动作），目的是交叉验证找出真实的 bug，而不是快速输出更多程式碼。

这套流程让他的程式碼产出量沒有增加，但程式碼品质明顯改善。

LLM 天生擅长找 bug

Anthropic 今年啟动的 Glasswing 计畫（Mythos 系统的公开更新）提供了这套逻辑直接的资料基礎。

这套系统让 LLM agents 大規模掃描真实的开源程式碼。結果是：在掃描超过 1,000 个开源專案后，系统估算发现 6,202 个高嚴重性或关鍵性漏洞，總计 23,019 个漏洞（含低嚴重性）。其中，由獨立资安公司逐一验证的 1,752 个漏洞裡，90.6% 被確认为真实问題，62.4% 屬於高嚴重性或关鍵性等級。

这些數字说明了一个根本转變：找 bug 不再是瓶頸，验证和修補才是。

Anthropic 在研究报告中明確寫道：「软體安全的进展，曾经受限於找漏洞的速度，现在受限於验证、揭露、修補的速度。」換句話说，AI 已经把问題的瓶頸从「发现」推进到了「處理能力」。

多模型審查的交叉验证逻辑

Lawson 的核心做法，是让多个不同廠商的模型同时跑 PR 審查，而不是依賴單一模型。

他的工具組合包括 Claude code、OpenAI 的 Codex，以及 Cursor Bugbot，三者同步对同一个 pull request 进行完全獨立的審查，再彙整所有結果，按照 critical（关鍵）、high（高）、medium（中）、low（低）四个嚴重性等級排列输出。

这个多模型交叉验证的设计有一个关鍵特性：單一模型容易誤报，但多个来自不同訓練资料和架構的模型同时指向同一个问題，誤报率就会大幅降低，覆蓋率同时提升。用 Lawson 自己的说法：「誤报率接近零，找到的 bug 覆蓋率很高。」

他的決策流程相当明確。所有 critical 和 high 的问題必須先修；medium 和 low 則要个別評估「修復成本」和「实际影響」的比例，不夠值得的直接跳过，不浪费开发资源；如果一个 PR 的 critical 问題太多，整个直接放棄重做，而不是在有根本问題的基礎上持续打補丁。

Lawson 的 PR 審查技術核心，来自一篇分析多模型在 code review 表现的研究：投入的模型越多樣，输出的最終报告越準確，背后的原理是「多元模型去偏差」，不同訓練背景的模型对同一段程式碼产生的偏见方向不同，多數投票可以有效过濾掉單一模型的盲点。

速度下降，品质上升

用了这套流程之后，Lawson 的实际結果是：程式碼输出量（行數）沒有增加，反而常常挖出既有的舊 bug，被迫去寫 unit tests（單元測試，簡單来说就是針对每一个小功能單獨验证的自动化測試），修舊问題的时间往往远多於推进新功能。

这不是他预期的結果，但从另一个角度看，这是程式碼基礎健康度正在被系统性補強的訊號。

Lawson 把这種工作方式稱为「更有质感的 vibe coding」，謹慎、有方法論、以品质为導向。

开发工具的普及通常把「速度」放在卖点最前面，但工程師真正要解決的问題，从来不只是速度。每一行程式碼都有它的維護成本，都有它出问題的机率。用 AI 把程式寫得更慢，但让每一行程式碼存活更久、出问題的机率更低。