AI PR 先查意圖、風險、驗證；過不了就別逐行救，直接重做。
你昨天用 coding-AI 寫的東西，今天才發現結果不對
你打開一個寫程式的 AI 助手生出來的 PR，50 行，嗯合理；120 行，欸也像那麼回事。變數名乾淨、註解乖巧、測試還補了兩個。結果你開始 review，第三個檔案就卡住：這裡為什麼改了重試？那邊為什麼少了上鎖？你越看越像在偵查犯罪現場。最煩的是，它不是爛到可以秒退，而是「大致看起來對，但我真的不敢 merge」。對啊，這才累。
真正累的不是程式碼多，是它看起來太像對的
AI PR 的麻煩點，不是它常常寫不出東西，而是它很會寫出「表面完成」的東西。格式像團隊風格，函式名像有想過，甚至會順手補測試。你第一眼很難把它當垃圾丟掉，於是被迫進入一行一行讀(line-by-line)的模式，時間就開始漏水。
Simon Willison 提過一個很準的觀察：假套件這種凸槌(hallucination,AI 一本正經亂講)反而沒那麼可怕，因為一跑就爆。真正危險的是「跑得起來但邏輯不對」。AI PR 的雷常常就在這裡：條件少一個、順序反了、錯誤重試太積極、資料沒上鎖(缺 row lock)。
所以 review AI PR，目標不該是「把每一行看懂」。那會把你拖進泥巴裡。比較實用的目標是：用 3 分鐘判斷它屬於「可修可 merge」還是「別救了，重做比較快」。
它是怎麼悄悄拖垮你的
第一種：它改到問題外圍。你本來只是要修付款狀態顯示，它順手整理 API 回傳、重命名欄位、改了錯誤處理。每個改動單看都合理，合起來卻讓 review 範圍膨脹。你不是在看一個小修補，你是在審一個迷你重構。
第二種：它補了測試，但測錯重點。AI 很會寫一切順利的劇本(happy path)：資料正常、回傳正常、使用者正常。可是真正會把線上服務(production)搞爛的，常常是兩個請求同時打架(race condition)、失敗後一直自動重試(retry storm)、資料沒上鎖(缺 row lock)、空值、重複請求、權限邊界。測試存在，不代表風險真的被蓋住。
第三種：它保留舊介面，偷偷改語意。函式名稱沒變，參數也沒變，但內部判斷從「沒有資料就跳過」變成「沒有資料就建立」。這種程式碼差異看起來小，實際上是商業邏輯換軌。CodeRabbit 2026-01 的研究也提到，AI PR 相比人寫 PR 出現更多邏輯錯誤；這類「像對的錯」，正是 review 最耗腦的地方。
3 步快篩(sanity check)：先判生死，再談修補
第一步：先問「這個 PR 到底承諾改什麼」。不要先看檔案，先看需求、PR 描述、測試名稱、主要程式碼差異。用一句話寫下它的契約：例如「取消訂閱後，不再寄續費提醒」。如果你寫不出這句話，或程式碼差異做了契約以外的重構，先打回縮範圍。AI PR 最怕邊修邊整理，因為 review 成本會暴增。
第二步：掃風險點，不掃美觀點。直接找資料寫入、權限判斷、時間條件、重試、快取、併發、外部 API、金流、通知。看到這些地方，就問三句：失敗會不會重複執行？兩個請求同時來會怎樣？舊資料或空資料會怎樣？如果 PR 碰到高風險區，卻沒有對應測試或保護，先不要陷入縮排和命名討論。
第三步：跑一個最小反例。不是跑完整測試就安心，而是自己挑一個最容易打臉它的情境。比如「重複點兩次」、「資料不存在」、「權限不足」、「API 超時後重試」。3 分鐘內造不出環境，也可以請 AI 寫程式助手反向生成反例測試：針對這個程式碼差異，列出最可能失敗的 5 個極端情境。你再挑最像真的那個跑。
最後設一個裁決線：三步都過，才進入局部一行一行讀；其中一步卡住，就別硬救。你可以留言：「請把 PR 縮到單一意圖、補上這個極端情境、移除非必要重構。」這不是龜毛，是省命。Ryz Labs 做過 6 個月測試，超過 10k 行的程式碼庫裡，寫程式 AI(coding-AI) 準確率會明顯下滑；範圍越散，你越不該用信仰 review。
拿走的一句話
AI PR 不要一開始就一行一行讀、照單全收，先用 3 步判斷它值不值得被 review。
