當 AI coding agent 開始能幫你改檔、跑測試、開 PR，code review 的問題會變得不一樣。
傳統 review 主要問：
- code 品質好不好？
- 有沒有 bug？
- 測試有沒有過？
- 是否符合團隊慣例？
AI-generated PR 還要多問一層：agent 是不是在正確任務、正確範圍、正確權限下完成這個修改？
這個問題很重要。因為 AI PR 最大的風險，不一定是 code 寫得很爛，而是它看起來合理、測試也過，卻悄悄偏離原始任務。
為什麼 AI PR 不能只用傳統 review？
人類工程師開 PR 時，reviewer 通常可以假設幾件事：
- 作者理解需求背景
- 作者知道自己為什麼改這些檔案
- 作者有責任感與團隊脈絡
- 作者能回答「為什麼不這樣做」
AI agent 不一定有這些脈絡。它可能只是根據 prompt、repo context、測試錯誤與局部推理產生一個可行 diff。
所以 AI PR 要多檢查：
- 它是否真的解決原始 issue？
- 它是否改了不該改的檔案？
- 它是否為了讓測試通過而削弱測試？
- 它是否繞過安全檢查？
- 它是否新增過大的抽象？
- 它是否用錯團隊既有 pattern？
- 它是否在沒必要時改了 API contract？
傳統 review 看「結果」。AI PR review 還要看「行為軌跡」。
第一層：任務對齊檢查
先不要看 code 美不美。第一步先看 PR 是否對齊原始任務。
| 檢查項目 | 要問的問題 |
|---|---|
| 原始 issue | PR 是否直接解決 issue 描述的問題？ |
| Acceptance criteria | 每個驗收條件是否都有對應變更或測試？ |
| 範圍 | diff 是否只碰必要檔案？ |
| 非目標修改 | 是否順手重構、改格式、改命名、改 unrelated logic？ |
| 缺口 | PR 是否承認哪些地方沒處理？ |
如果 PR 一開始就沒有對齊任務，後面 code 寫得再漂亮都沒用。
AI agent 很容易做「看似有幫助」但偏離目標的事，例如：
- 順手重構整個檔案
- 改掉跟 bug 無關的命名
- 把問題繞到另一層
- 新增一個過大的 helper
- 修改測試期待值而不是修邏輯
這些都要先擋下來。
第二層：Diff 範圍檢查
AI PR 最常見的問題之一，是改太多。
不是每個大 diff 都錯，但大 diff 一定要有理由。
Review 時可以問：
- 這個檔案為什麼需要改？
- 是否有更小的修正方式？
- 是否把不相關 formatting 混在同一個 PR？
- 是否改到 public API、schema、migration、config？
- 是否新增依賴？
- 是否刪除舊邏輯？
建議把檔案分成三類：
| 類型 | Review 態度 |
|---|---|
| 預期內檔案 | 正常 review |
| 可疑檔案 | 要求 agent 或作者解釋為什麼需要改 |
| 高風險檔案 | 需要資深工程師或 owner review |
高風險檔案通常包括：
- auth
- payment
- permission
- database migration
- production config
- secrets
- deployment
- security policy
- logging／audit
- billing
AI agent 不是不能碰高風險檔案，而是不能在沒有明確批准與 owner review 的情況下碰。
第三層：測試證據檢查
AI agent 很會說「測試已通過」，但 reviewer 不能只看這句話。
要看它跑了什麼測試、為什麼跑這些測試、哪些測試沒有跑。
最小測試證據應該包含：
- 執行了哪些命令
- 測試結果摘要
- 哪些測試與這次變更直接相關
- 沒有跑哪些測試，原因是什麼
- 是否新增或修改測試
- 新測試是否真的會在 bug 存在時失敗
AI PR 最危險的測試問題包括：
- 只跑單一 happy path
- 修改測試期待值來配合錯誤邏輯
- 刪掉 flaky test 但沒說明原因
- mock 掉真正該測的行為
- 只測 implementation detail，不測使用者可觀察結果
- 沒有測 edge case
一個簡單規則：如果 PR 是修 bug，應該先有能重現 bug 的測試；如果是新功能，應該有驗收條件對應測試。
第四層：安全與權限檢查
AI coding agent 的安全風險，不只在 prompt injection，也在它產出的 diff。
Review 時要特別看：
- 是否放寬權限判斷？
- 是否新增過度寬鬆的 CORS、network、file access？
- 是否把錯誤吞掉，讓安全檢查失效？
- 是否把 secret 寫進檔案、log 或測試 fixture？
- 是否新增不必要的外部依賴？
- 是否改變 authentication 或 authorization flow？
- 是否降低 rate limit、validation、sanitization？
- 是否讓使用者輸入更接近 shell、SQL、HTML、URL、file path？
AI PR 對安全最常見的壞習慣，是為了讓功能跑起來而「放寬限制」。
例如：
- 暫時跳過 permission check
- catch error 後直接 return success
- 把 validation 改成 optional
- 用 broad allowlist 取代精準規則
- 把 timeout 拉長但沒處理根因
這些改動看起來像修 bug，其實可能是在移除防線。
第五層：可維護性檢查
AI agent 常常能寫出可執行 code，但不一定寫出好維護的 code。
Review 時可以看：
- 是否遵守既有命名與檔案結構？
- 是否重複造輪子？
- 是否新增過度抽象？
- 是否把 business logic 放錯層？
- 是否讓函式變得太長？
- 是否讓錯誤處理更混亂？
- 是否把 domain concept 改成模糊通用名稱？
- 是否讓未來 debug 更難？
AI 產出的 code 有時會「局部合理、全局彆扭」。
它在單一檔案看起來可以，但放進整個系統就不順。
這也是為什麼 repo owner review 很重要。AI 可以讀 codebase，但不一定理解團隊多年累積的設計取捨。
建議要求每個 AI PR 附上 Trust Brief
工程團隊可以要求 agent 或使用者在 PR description 裡附上一段 trust brief。
格式可以很簡單：
## AI Trust Brief
任務來源：
- issue / ticket：
- 原始需求：
變更範圍：
- 修改檔案：
- 未修改但檢查過的檔案：
- 高風險區域：
測試證據：
- 已執行命令：
- 新增測試：
- 未執行測試與原因：
風險與假設：
- 主要風險：
- 需要 reviewer 特別確認：
- 未完成項目：這不是形式主義。它會迫使 agent 產出可 review 的上下文，也讓 reviewer 不用從零開始猜它做了什麼。
AI PR Review Checklist
可以把這份清單放進團隊 PR template。
任務
- PR 是否對齊原始 issue？
- 是否有明確 acceptance criteria？
- 是否有超出任務範圍的變更？
- PR description 是否說明未完成項目？
Diff
- 是否只改必要檔案？
- 是否有不相關 formatting？
- 是否新增依賴？
- 是否改到 public API、schema、config？
- 是否刪除既有行為？
測試
- 是否有對應測試？
- 測試是否真的覆蓋 bug 或需求？
- 是否跑過相關 test、lint、type check？
- 是否有未跑測試的合理原因？
- 是否改壞既有測試意義？
安全
- 是否放寬權限？
- 是否碰到 secrets？
- 是否新增外部 network 或 file access？
- 是否改變 auth、payment、billing、audit？
- 是否降低 validation 或 sanitization？
維護
- 是否符合團隊 pattern？
- 是否引入過度抽象？
- 是否讓錯誤處理更清楚？
- 是否讓未來 debug 更容易？
- 是否需要 owner review？
結論：AI PR 的重點不是更快合併，而是更清楚驗收
AI coding agent 可以大幅提高產出速度，但 review 流程如果沒有升級，團隊只是把成本從「寫 code」轉到「檢查 code」。
好的 AI PR review 應該做到三件事：
- 確認 agent 沒有偏離任務
- 確認 diff 可測、可維護、可回滾
- 確認高風險操作被看見、被批准、被記錄
AI-generated PR 不該被特別放水，也不該被全部拒絕。它需要的是更明確的證據包。
當每個 AI PR 都能清楚交代任務、範圍、測試、風險與限制，AI coding agent 才會真的變成工程團隊的生產力，而不是 reviewer 的新負擔。