Vincent5588 Wiki

Code Review 準則 (AI 編程)

閱讀時間約 4 分鐘

Code Review 準則 (AI 編程)

Vibe Coding 場景下，Reviewer 的具體行為準則。Reviewer 不是在檢查 AI 的工作，是在檢查送 PR 的人有沒有做好 PM 的工作。

核心心態轉變

從 「檢查 code」 → 「檢查 PR author 是否盡到 PM 責任」。

  • code 細節由 author 跟 AI 自驗
  • reviewer 的價值在於檢查流程紀律 + 抽象層正確性
  • core code 仍要逐行 review，但目的是抓邏輯錯誤而非寫法

Review 重點順序（6 步）

#重點失敗即退回
1PR 描述是否完整✅
2計畫與實作是否一致✅
3變更範圍是否符合 leaf / core 分類✅
4介面與測試是否清楚✅
5Core code 區塊逐行檢視邏輯✅
6Leaf node 區塊抽查、重點看測試與邊界(彈性)

標準退回理由

直接複製貼給 author：

退回理由對應 Anti-Pattern
沒有 plan.md 或計畫摘要Vibe Coding Anti-Patterns
Core code 變更缺少逐行 review 紀錄#2
沒有 stress test，但這是長時間執行的服務#3
測試只有 happy path#3
動到了 PR 中聲明「不可動」的範圍#6
測試太綁實作細節，不是 e2e 等級#9

留言對比

✅ 好的 review

這支 cron 屬於長時運行，但只看到 unit test。
能補一個跑 30 分鐘的 soak test 嗎？我們才能在
不讀完整邏輯的情況下信任它。

特徵：

  • 點出問題類型（缺 stress test）
  • 給法則依據（長時運行需 soak test，符合 建立可驗證檢查點 法則）
  • 給具體修補建議（30 分鐘 soak test）

❌ 壞的 review

LGTM

（PR 有 800 行 AI 產出且觸及 core）

特徵：

  • 沒檢查 AI 範圍標示
  • 沒做 core code 逐行 review
  • 反模式 #8「看不懂所以信任 AI」典型案例

不同變更類型的 review 強度

依 Leaf Node vs Core Code 分類：

類型Reviewer 數深度重點
Core PR至少 2 位（含 module owner）逐行邏輯正確 / 邊界 / 跨模組 invariants
Leaf PR至少 1 位抽查介面契約 / 測試覆蓋 / 邊界

詳見 核心由人嚴格 Review 法則。

Module Owner 否決權

AI 編程角色責任矩陣 規定 Module Owner 對「觸及自己模組的 AI PR」有否決權——即使其他 reviewer 已 approve。

Reviewer 流程內遇到 Module Owner 退回應尊重判斷，不該繞過或施壓 approve。

跟其他工具的關係

工具角色
AI 編程 PR 模板Author 填寫的輸入；reviewer 用此驗證流程紀律
Vibe Coding Anti-Patterns退回理由的 reference
常見情境決策表 (Vibe Coding)判斷「這個變更該不該允許 vibe」
AI 編程角色責任矩陣reviewer 角色的詳細責任

違反時的常見症狀

  • ❌ 「LGTM」approve core PR → 反模式 #8
  • ❌ 看不懂直接 approve → 應退回讓 author 補 plan + 測試
  • ❌ 跳到實作細節 review，沒先查 PR 描述 → 流程錯
  • ❌ Leaf PR 也逐行讀 → 浪費時間
  • ❌ Core PR 沒找 Module Owner → 失守門員

相關

關係圖譜

反向連結