AI 產出的程式碼量爆炸，人力 review 成了瓶頸——但把 AI review 直接開下去，多半只會換來一堆雜訊。 2026 年真正有效的做法是一條分層 pipeline：AI 做「第一審」把明顯問題攔在人眼之前，人做「最終審」專注架構、業務邏輯、跨系統影響。
核心方法：Two-Tier + 風險分層
最扎實的一手數據來自 Cloudflare 的生產系統（2026 年 3–4 月 131,246 次審查、48,095 個 MR）：依 diff 規模與敏感度分流審查強度，不對每個 PR 一視同仁——
- Trivial（≤10 行）→ 2 個 agent，約 $0.20
- Lite（≤100 行）→ 4 個 agent，約 $0.67
- Full（>100 行或觸及
auth/、crypto/等敏感路徑）→ 7+ 個 agent，約 $1.68
中位成本 $0.98、cache hit 85.7%、平均只產出 1.2 個發現（刻意保守）、break-glass 僅 0.6%（Cloudflare）。
分工原則：AI 管客觀低層級（風格、常見 bug、安全掃描、lint、去重分級）；人管主觀高層級（架構、業務邏輯是否正確、產品的「為什麼」、最終核准責任）。
Best practices
- 主動降噪，把「不要標記什麼」寫進 prompt。Cloudflare 在每個 agent 的 prompt 放「NOT to Flag」段落，安全 agent 只報「可被利用的具體危險」，排除理論性風險。
- 給全倉庫上下文而非只看 diff（型別、模組相依、提交歷史）；跳過生成檔／lockfile；防 PR 描述被當指令（prompt injection）。
- Policy gate 分級：critical 且高信心（硬編碼憑證、SQLi，近乎零誤報）→ 阻擋合併；warning → 非阻擋留言；break-glass 要留痕。
- 對 AI 生成的碼，審查應更久而非更快——它的失敗模式更隱晦，等速審查等於蓋橡皮章。
- 追蹤指標：cycle time、缺陷逃逸率、接受率（≥50% 才算可信）、override 率。
工具（2026）
- CodeRabbit（多平台、Martian 獨立 benchmark F1 第一、precision ~49%）、Greptile（code graph、跨檔案）、Cursor Bugbot（精準度佳、綁 IDE 座位）、GitHub Copilot code review（GitHub 原生、已達平台 20%+ 審查量）、Anthropic Code Review for Claude Code（多代理，官方稱 substantive comment 從 16% 升到 54%、>1000 行 PR 有 84% 有發現、<1% 被標為誤報，blog）。
- 大廠內部：Microsoft 覆蓋 >90% PR、600K+ PR/月；Google AutoCommenter usefulness 54–74%。
陷阱（證據常與行銷相反）
- 雜訊過載 → 警示疲勞 → 忽略所有評論。最透明的實測：Lychee 一個月 CodeRabbit 稽核，約 28% 純雜訊，但也抓到人類漏掉的 zip-slip 與 IDOR（lycheeorg）。
- 審查時間可能不減反增：METR RCT 顯示允許用 AI 反而讓完成時間 +19%（arXiv:2507.09089）；Meta A/B 給審查者看 AI 建議 +5.5%（arXiv:2507.13499）。
- 框架效應失明：只要在描述裡暗示「已審查過」，GPT-4o-mini 漏洞偵測率從 97.2% 崩到 3.6%（arXiv:2603.18740）。
- Rubber-stamping：Intercom 自曝 19% PR 無人審就自動核准（fin.ai）。
主張 vs 可佐證
- 可佐證：Cloudflare 架構數字（一手）；雜訊／低召回率普遍（多篇學術，最佳模型 precision 僅 16.65%、arXiv:2509.01494）；框架效應、審查時間增加。
- 不可佐證：各家「82%／95.88% 抓取率」是廠商自評，DeepSource 用相同資料重跑把 Greptile 82% 打成 45%；「9 誤報換 1 真 bug」「40% 忽略」屬查無來源的引用漂白。這個領域還沒有「AI code review 界的 SWE-bench」。
review 只是把關的一環——上游先寫清楚見 Spec-Driven，配套的自動化測試見 測試生成，發現 bug 後的根因追查見 系統化除錯。多 agent 平行審查的成本結構見 成本與路由。整體工程判斷見 Engineering AI Coding Methodology。