Bagaimana membuat program AI berjalan lebih lambat, tetapi lebih akurat: melakukan review PR dengan banyak model, sehingga peluang bug ditekan seminimal mungkin

前微軟資深工程師 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，被迫去寫單元測試（簡單來說就是針對每一個小功能單獨驗證的自動化測試），修舊問題的時間往往遠多於推進新功能。

這不是他預期的結果，但從另一個角度看，這是程式碼基礎健康度正在被系統性補強的訊號。

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

開發工具的普及通常把「速度」放在賣點最前面，但工程師真正要解決的問題，從來不只是速度。每一行程式碼都有它的維護成本，都有它出問題的機率。用 AI 把程式寫得更慢，但讓每一行程式碼存活更久、出問題的機率更低。