如何讓 AI 程式寫得更慢，但更正確：多模型 PR 審查，讓 Bug 機率壓到最低

📄完整原文· 由 trafilatura 自動擷取1534 字

前微軟資深工程師 Nolan Lawson 用 Claude、Codex、Cursor Bugbot 三個模型同步審查 PR，交叉驗證將誤報率壓到接近零。（前情提要：Claude Code 宣布每週 Token 使用上限增加 50%！為期兩個月 Anthropic 搶佔開發者生態）（背景補充：Stripe 啟動 AI Agent 全自動支付測試：透過 x402 支援 Base 鏈 USDC 付款）們知道 AI coding 的優勢是「快速產出大量程式碼」，但是正確度就有待商榷。前微軟、Salesforce 資深工程師 Nolan Lawson 最近在部落格記錄了一套新的工作流程：他用多個大型語言模型同步審查每一個 pull request（程式碼合併請求，簡單來說就是每一次把新程式碼送進專案的動作），目的是交叉驗證找出真實的 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 的實際結果是：程式碼輸出量（行數）沒有增加，反而常常挖出既有的舊 bug，被迫去寫 unit tests（單元測試，簡單來說就是針對每一個小功能單獨驗證的自動化測試），修舊問題的時間往往遠多於推進新功能。這不是他預期的結果，但從另一個角度看，這是程式碼基礎健康度正在被系統性補強的訊號。 Lawson 把這種工作方式稱為「更有質感的 vibe coding」，謹慎、有方法論、以品質為導向。開發工具的普及通常把「速度」放在賣點最前面，但工程師真正要解決的問題，從來不只是速度。每一行程式碼都有它的維護成本，都有它出問題的機率。用 AI 把程式寫得更慢，但讓每一行程式碼存活更久、出問題的機率更低。

資料狀態✓ 已擷取全文閱讀原文（動區 BlockTempo）

🔍歷史類似事件· 關鍵字 + 標的比對1 則

2026-05-15

Raindrop Workshop 用 Codex 幫你的 AI Agent 自動找 bug 並修復（免費開源）

相似度 120%關鍵字 bug同分類 zh

💡 目前用關鍵字 + 標的比對（MVP）· 之後會升級為 embedding 語意搜尋

原始資訊

ID：f2feed2ef3

來源：動區 BlockTempo

發佈：2026-05-26 03:34:37

分類：zh_news · 導出分類 zh

標的：未指定

社群投票：+0 / −0 · ⭐ 0 重要 · 💬 0 留言