AI code review 的帳怎麼算：找到的 bug、誤報和人的時間

curl 的維護者 Daniel Stenberg 對 AI 產生的漏洞報告抱怨已久。2025 年 5 月他公開說，專案還沒看過任何一份靠 AI 協助寫出來、而且成立的安全報告。這些報告寫得很像回事，格式完整、語氣篤定，維護者得一份一份讀完、重現、回覆，最後發現是假的。

同年 9 月，情況出現另一面。安全研究員 Joshua Rogers 用了好幾套 AI 程式碼掃描工具去掃 curl，整理後送出大量回報，到 10 月初已經有大約 50 個修正因此合併。Stenberg 的評價是「Actually truly awesome findings」，也說大部分是靜態分析器那種小錯和小瑕疵，但還是值得修，其中幾個發現相當厲害。他的結論是：「Powerful tools in the hand of a clever human is certainly a good combination.」

再過幾個月，2026 年 1 月底，curl 還是結束了 bug bounty。Stenberg 的說法是送件品質崩掉了，明顯的垃圾很多，連看起來不像 AI 寫的也變差，他們必須避免被淹沒。

同樣是 AI 找 bug，一邊是幾十個真的修正，一邊是讓維護者吃不消的噪音，模型能力差不了那麼多，差別在分辨真假的工作落在誰身上。Rogers 自己先篩過，送出去的是他判斷過的東西；匿名的大量送件則把篩選成本整個丟給了維護者。在團隊裡導入 AI code review，算的也是同一筆帳。

一、成本主要不在 token

導入 AI review 的時候，最容易看到的成本是 API 費用，最容易忽略的是人花在判斷每一條意見上的時間。

2025 年 ICSE 有一篇業界研究〈Automated Code Review In Practice〉，在一家公司導入以 Qodo PR Agent 為基礎的自動 review，涵蓋十個專案、238 位工程師，重點分析其中三個專案的 4,335 個 PR，有 1,568 個經過自動 review。結果有 73.8% 的自動 review 意見被處理（resolved），多數工程師認為程式碼品質有小幅改善。代價是 PR 平均關閉時間從 5 小時 52 分拉長到 8 小時 20 分，工程師也回報了錯誤的 review、不必要的修改和不相關的意見。

這組數字好壞都有，七成多的意見有人處理，代表工具講的東西多半有點道理；關閉時間多了兩個半小時，代表每一條意見都要有人讀、想、回應，不管它最後有沒有用。「被處理」也不等於「找到 bug」，其中有多少是真正會出事的問題，論文摘要沒有拆開。

二、一個粗略的算式

把一次 AI review 的帳拆開，大概是這樣：

效益 = 找到的真問題數 × 每個問題如果漏到線上的代價
成本 = 模型費用 + 意見總數 × 每條意見的人工判斷時間 × 人力成本
     + 被誤報帶偏的修改（改了不該改的東西）

意見總數乘上判斷時間這一項，通常比模型費用大得多。用一組假設的數字算一次（以下數字是示意，沒有出處）：一次 review 產生 40 條意見，其中 8 條是真的問題，精確率 20%；每條意見平均要 6 分鐘判斷，總共 4 小時。8 個真問題裡如果有 1 個是會造成資料錯誤的 bug，這 4 小時很值得；如果 8 個都是命名和格式，這 4 小時多半拿去寫程式比較划算。

所以「AI review 值不值得」沒辦法一概而論，取決於兩個比例：精確率決定人要讀多少廢話，真問題的嚴重程度決定讀完值不值得。

三、多加一層驗證

既然人工判斷最貴，一個直覺的做法是讓模型先自己篩：一組 agent 負責找問題，另一組 agent 針對每一條發現去反駁，試著證明它不成立，反駁不掉的才交給人。

用上面的假設數字延伸：40 條意見各派 3 個驗證 agent，多跑 120 次模型；篩完剩 12 條，其中 7 條是真的。人工判斷從 40 條降到 12 條，時間從 4 小時降到大約 1 小時 12 分，精確率從 20% 升到接近 60%。代價有兩個，一是模型費用變成好幾倍，二是有 1 個真問題在驗證階段被誤殺了。

第二個代價比較容易被忽略，驗證 agent 也會錯，它可能因為看不到完整的呼叫鏈、或被一段看似合理的防護程式碼說服，就把真問題判成不成立。加了驗證層以後，人看到的清單短了很多，被拿掉的那些也就真的沒人看了。比較穩的做法是定期抽查被駁回的項目，至少知道這一層誤殺的比例大概多少。

這個做法什麼時候划算，可以直接從算式看：人工判斷時間的節省，要大於多出來的模型費用加上誤殺的期望損失。人力貴、意見量大、精確率原本很低的時候最划算；本來意見就不多，或者人本來就要逐行看的程式碼，多一層驗證只是多花錢。

四、哪些程式碼值得這樣審

從「漏到線上的代價」這一項反推，值得投入的地方很具體：

動到錢、權限、資料一致性的程式碼，例如扣款、對帳、授權檢查，一個 bug 的代價遠大於多跑幾輪模型。
併發、重送、狀態轉移這類人工 review 容易漏的地方，模型對「如果這兩個請求同時進來」這種問題的耐心比人好。
沒人深入看過的舊程式碼，或者大批 AI 產生、人只掃過一眼的程式碼。

反過來，格式、命名、文件措辭這類問題，交給 linter 和 formatter 比較便宜，也不需要人判斷。

五、怎麼知道它有沒有用

不記錄就只剩感覺。最低限度可以對每一條 AI 意見記下：最後判定成立還是不成立、嚴重程度、判斷花了多久、如果成立是誰修的。累積幾十個 PR 之後，就能算出自己團隊的精確率和每個真問題的平均成本，而不是引用廠商的數字。

也值得拿同一批 PR 對照人工 review：AI 找到、人沒找到的有哪些，人找到、AI 沒找到的又有哪些。Rogers 那次測試也提到，他用的幾套工具都沒抓到另一個專案裡一個已知的無窮迴圈 bug，工具之間、工具和人之間，盲點都不一樣。

補充筆記

同樣是 AI 找 bug，curl 從被噪音淹沒到合併約 50 個修正，差別在分辨真假的成本由誰負擔。
主要成本是人判斷每一條意見的時間，業界研究裡 PR 關閉時間多了兩個半小時。
效益看兩個比例：精確率決定要讀多少廢話，真問題的嚴重程度決定讀完值不值得。
加一層反駁式驗證能提高精確率、省人工，代價是模型費用倍增和誤殺真問題；要定期抽查被駁回的項目。
錢、權限、併發、狀態轉移的程式碼最值得投入；格式和命名交給 linter。
每條意見記下成立與否、嚴重度和判斷時間，算出自己團隊的數字。