[AI 分享] AI 讓 PR 暴增，如何讓審查跟上？

[AI 分享] AI 讓 PR 暴增，如何讓審查跟上？

摘要 : 以自動檢查、AI 審查和人工審查三層把關，降低 PR 積壓，並讓每次審查改善下一次的工作流程。

內容:

AI 寫程式越來越快，許多團隊卻發現 PR 堆得比人能審的還快。Matt Pocock 在 AI Engineer Paris 分享了一套做法：不要只替開發流程踩油門，也要建立能維持品質的「煞車」。否則，自動產出的程式碼越多，團隊越可能被品質不佳的 PR 淹沒。

他的第一個主張是三層把關。底層是 lint、型別檢查與測試等自動檢查；中層是 AI 審查，找出測試未涵蓋的問題並檢視整體結構；最上層才由人審查。前兩層越扎實，人工需要處理的問題就越少。

但 CI 顯示綠燈，不代表程式碼可以合併。Matt 提醒，AI 可能寫出只重複實作內容、直接檢查原始碼文字順序，或把真正可能出錯的部分全部 mock 掉的測試。這些測試看似通過，卻沒有驗證真正的行為。改善方法之一，是把複雜實作藏在簡單介面後面，讓測試透過介面驗證結果，而不是緊盯內部細節；他也為改善程式碼架構製作了對應的 Skill。

第二層的關鍵，是讓寫程式的 AI 與審查的 AI 分工。寫程式的 AI 已經要找資料、修改檔案和除錯，不必再承擔大量團隊規範。規範可以整理在 coding-standards.md，交給獨立的審查 AI 讀取。Matt 建議審查 AI 發現明確問題時直接修改並 commit，只有需要人判斷的地方才留言。

到了人工審查，重點是讓人快速掌握風險與變更目的。Matt 建議在 PR 中標示合併風險：多數變更像「雙向門」，出問題仍可退回；寄送大量郵件、資料遷移或可能造成資料遺失的變更，則更接近難以回頭的「單向門」，必須審得更謹慎。PR 也可以用流程圖或示意圖輔助說明，讓審查者更快理解為什麼這樣改。

最後，人工審查不只是檢查這一次的程式碼，也是在改善產生程式碼的系統。Matt 提出的 Retro Skill 會回顧 AI 工作紀錄、PR 與審查意見，找出值得新增的自動檢查、需要更新的團隊規範，以及 AI 查找資料和使用工具時的阻礙。目標是不要對不同 PR 重複提出同一個意見，讓這次審查的收穫，成為下次開發前就能發揮作用的規則。

若要開始實作，可以先做好 lint、型別檢查與行為測試；接著建立 coding-standards.md，讓獨立的 AI 審查並修正 PR；最後在每個 PR 說明合併風險，定期回顧審查紀錄，持續把常見問題轉成檢查與規範。