AI Code Review
如何用 AI 幫我處理
每天要面對的 Code Review
從 review 壓力，到整理出一套 PR 輔助審查方法
DevOps Taiwan Meetup #78
Hannah Yang
如何用 AI 幫我處理
這場分享會怎麼走
痛點
PR 變多
review 壓力變大
標準
MUST / SHOULD / MAY
先定義值得處理的常見問題
工作流
工具放在 review 前
先處理常見問題
邊界
AI 負責提醒與整理
團隊負責判斷與取捨
02
先從最明顯的感覺開始
AI 讓 PR 數量變多，但 Reviewer 沒有變多
產出速度變快，品質把關的責任卻沒有一起消失，反而壓力更大了
03
壓力，全部卡在 review 這一關
品質把關的責任沒有消失，只是換了位置
04
Code Review 本來就有三個問題
AI 加進來後，這些問題只會更明顯
05
PR 變多、變更變大 review 壓力，卡在 取捨 這關
品質責任沒有消失，每一則評論都要判斷值不值得處理
06
Code Review 的價值沒有變
Trunk-based Development - Continuous Code Review
回饋要盡早發生，拒絕或要求修改要基於公開且客觀的理由
確認需求
改動是否真的解決問題，邊界是否合理
if ($order->paid()) {
return $refundService->refund($order);
}
Reviewer
已出貨訂單也允許退款嗎？這裡需要確認需求邊界
留下脈絡
讓後續維護的人看得懂當時的取捨
// legacy mapping 先保留
// mobile v2 下線後移除
return $this->mapLegacyStatus($status);回饋有依據
把風險、影響與建議說清楚
- Log::info('failed', ['email' => $user->email]);
+ Log::info('failed', ['user_id' => $user->id]);
Reviewer
這裡會把 email 寫進 log，屬於 PII，建議改用 user_id
07
最大的轉折
AI 不是不會講，是太會講
問題不是看不到風險，而是不知道哪些值得留下
PR · diff
public function group($orders)-
$g = [];-
foreach ($orders as $o) {-
$g[$o->status][] = $o;+
return $orders+
->groupBy('status');可讀性這段可以更清楚都有道理
效能這裡可能 N+1都有道理
測試建議補一下測試都有道理
安全性注意輸入驗證都有道理
架構考慮拆出 service都有道理
命名命名再想想都有道理
少講一點，講對地方
08
同樣是建議
差別在於，作者看完能不能處理
不容易處理
只有方向，沒有判斷
都已經用 Laravel 了，
可以查一下 Collection 裡面有沒有什麼好用的 function，
才不會寫一堆 foreach
可以查一下 Collection 裡面有沒有什麼好用的 function，
才不會寫一堆 foreach
?
要不要改
?
不改會怎樣
?
要改成什麼
可以處理
有分級，有依據，有下一步
[SHOULD] 手動分組邏輯可以改用 Collection 方法
問題
foreach 手動整理資料，Collection 的 groupBy 可以表達同樣意圖
影響
手動累加陣列讓分組意圖不明顯，也增加後續維護成本
建議
改用 groupBy 表達分組邏輯，讓程式碼更接近資料處理的意圖
✓
要不要改
SHOULD
✓
不改會怎樣
維護成本
✓
要改成什麼
groupBy
09
工具限制
通用工具卡住的不是掃描能力，而是判斷標準
app/Services/RefundService.php
AI review
bug
security
performance
test?
public function refund(Order $order) {
return $this->refundGateway->refund($order);
}
AI Reviewer
這裡看起來缺少退款失敗情境的測試
同樣是缺測試
工具不知道權重
team-review-rules.yml
Team standard
MUST
核心付款流程
不能 merge，錯誤會直接影響金流
SHOULD
內部一次性匯出工具
可以先合併，但要留下後續補測試任務
10
踩過的坑
讓 AI 審得準，比審得快難多了
01
脈絡亂猜
「這段邏輯有漏洞，應該一起修正」
但其實 PR 只是在做 coding style 調整
02
不知道要不要改
「這裡可以改善錯誤處理」
文字敘述缺乏「不改的話，會有什麼影響？」
03
誤報太多
「這邊要進行權限檢查」
但其實 route middleware 已經處理過
信任度
逐步下滑
信任歸零
快不是重點
準才會被採用
11
目標縮小
讓 AI 不再追求「完整 review」，只留值得處理的評論
01
留下評論
✓
↓
出現在 PR 上
依據明確、能直接行動
MUST
禁止在 log 中記錄 PII
02
先補脈絡
?
↩
回 PR 描述
看起來重要，但證據不夠
不要急著留言
待補脈絡
payload 是否真的含識別資料
03
合併降噪
同一根因 ×3
↓
1
收斂成一條
同一段程式碼的同一個根因
不要拆成多則通知
同一根因
timeout、失敗提示、refund 例外
04
收斂輸出
✕
↓
忍住，不發出去
信心度低、又偏風格喜好
不要變成正式評論
MAY
變數名稱可以更清楚
最後值得處理的評論
MUST
避免在 log 中記錄 PII
payload 可能包含 email，請遮蔽或改記匿名欄位
SHOULD
補上退款失敗情境測試
合併 timeout 與失敗提示風險，補一組 gateway timeout 測試
12
評論分級
用 MUST / SHOULD / MAY 說清楚處理期待
RFC 2119：用來表達「要求強度」的語彙
MUST
功能錯誤
安全風險
PII log
違反明確底線
不修，就不能 Merge
SHOULD
測試缺口
可維護性
團隊一致性
不修，要說明理由
MAY
設計取捨
風格偏好
需要更多脈絡
不修，也不擋 Merge
13
把團隊標準變成工具能力
標準只存在文件裡，很容易在 review 現場被遺忘
團隊標準
安全底線
PII 不能進 log
測試底線
金流失敗路徑要補測試
取捨空間
命名偏好不能擋 merge
工具判斷條件
MUST
違反明確底線，不修就不能 Merge
SHOULD
影響品質與維護性，不修要說明理由
MAY
偏好或取捨，不修也不擋 Merge
輸出結果
MUST
避免記錄使用者識別資料
這段 log 可能包含 email，請遮蔽後再寫入
SHOULD
補上付款失敗情境測試
這次有新增錯誤分支，建議補一組 timeout 測試
MAY
變數名稱可以再短一點
只有風格偏好，保留討論，不進正式評論
14
工具化
把團隊標準，變成工具能力
其中「審查順序」拆成幾層 —— 降低認知負荷
1
全貌
→
2
架構
→
3
邏輯
→
4
品質
→
5
整理評論
先全貌，再架構、邏輯、品質，最後才整理評論 —— 不會一開始就陷進命名跟風格
15
工具應該放在 review 開始之前
先掃掉常見問題，讓 reviewer 專注在高價值的判斷
Human Review 開始
送 PR 前
自審
先檢查明顯問題、缺測試、錯誤處理與團隊規範
PR 開出後
補第一輪風險
只留下高信心、能行動、merge 前值得處理的問題
團隊成員
高價值判斷
需求、架構、風險接受與最後合併判斷回到人身上
16
健康的工作流
把它串成一個工作流
1
完成功能
作者寫功能與基本測試
作者
2
送審前自審
查找明顯 Bug、測試缺口、規範
作者使用工具
3
修 MUST / SHOULD
使用工具輔助修正
MAY 保留在報告
4
補上最後的建議
PR 開出後，只補高信心問題
作者使用工具
5
Human Review
需求、架構、風險、merge
團隊成員17
導入節奏
不要一開始就全自動
信任，是慢慢累積出來的
01
先做提醒
常見問題、測試缺口、團隊規範，先產生摘要
不要急著發 PR comment
02
結構化
每則評論都有分級、問題、影響、建議
開始看出工具常在哪裡誤判
03
考慮流程化
信任足夠後，再評估要不要接進送審前檢查
不是一開始就做
信任度
建立起來
18
邊界
AI 能幫忙，但不替團隊做決策
AI 可以指出違規，但例外是否成立要由團隊決定
案例一
SendReceiptMail::dispatchSync($order);AI: MUST→團隊: MUST
寄信必須改成非同步
request 不能被寄信卡住，這是團隊既有底線
案例二
$request->validate(['reason' => 'required']);AI: MUST→團隊: SHOULD
應該改用 FormRequest
團隊即有寫法為使用 FormRequest，
但內部一次性操作可以例外，但要寫清楚理由
案例三
final class OrderController extends ControllerAI: SHOULD→團隊: MAY
Controller 是否要加 final
沒有團隊規範時，先當可以討論的項目，
不直接變成擋 merge 的要求
工具的限制，守住界線
只有 MUST / SHOULD 才變正式評論
找不到依據，不硬發
信心不夠，回互動確認
19
重點回顧
最後，留三個重點
01
評論多，不代表品質好
有價值的，是高信心、能行動、merge 前值得處理的
02
標準，要先說清楚
MUST / SHOULD / MAY 幫作者理解期待，也避免把個人偏好放大成 merge 的阻礙
03
人，仍然負責取捨
要不要 merge、要不要例外、要不要改標準，由團隊決定
20
如果團隊自己都說不清楚，什麼問題一定要改
AI 只會把這個模糊放大
21
反過來說
將標準整理清楚，AI 超好用
22
我的答案不是
用 AI 取代 Code Review
23
真正的答案是
先把團隊標準說清楚
再讓 AI 執行已經說清楚的部分
24
Q&A
謝謝大家
如果你也在團隊裡導入 AI review，歡迎一起交流
25
等待更久
PR 開出去之後，大家都很忙，review 容易卡住
重複檢查
缺少測試、錯誤處理、命名慣例，每次都要再提醒一次
標準不一致
同一個問題，有人會擋，有人會放