法則三：核心區塊由人嚴格 Review

四大黃金法則 (Vibe Coding) 第三條。Review 強度依 Leaf Node vs Core Code 分類調整——core 要嚴，leaf 可寬。

規範要求

觸及核心區塊的 PR

要求	細節
Reviewer 數	至少 2 位
必含	該模組的 owner
Review 深度	逐行閱讀
PR 描述	需明確標示 AI 產出範圍 vs 人類審閱範圍

觸及 leaf node 的 PR

要求	細節
Reviewer 數	至少 1 位
Review 深度	重點審查介面契約與測試，可不必逐行讀實作

為什麼 Core 要兩位 reviewer

單人 review 對 AI 大量產出不夠：

AI 可能寫出看起來合理但細節錯誤的 code（hallucination 在實作層）
一位 reviewer 可能受 AI prose 帶風向（confirmation bias）
兩位獨立 reviewer 提供 cross-check

模組 owner 必含的理由：owner 知道這模組過去踩過的雷、隱性 invariants、跨模組假設——這些 AI 不可能完全 capture 在 prompt 內。

為什麼 Leaf 可以放寬

法則二已經把 leaf 的 blast radius 限制了：

失敗成本區域性、可回滾
短期不會再大改，技術債容忍

所以 leaf review 重點轉向「介面契約與測試」——只要介面合理、測試覆蓋夠，實作有點髒沒關係（反正不會擴散）。

落地工具

工具	角色
AI 編程 PR 模板	強制標示 AI 範圍 vs 人類範圍、leaf vs core
Code Review 準則 (AI 編程)	詳細 review checklist
GitHub CODEOWNERS	自動指派 module owner 為 reviewer
Branch protection rules	強制 2 位 reviewer for core paths

跟法則四的關係

法則三規定強度，法則四規定內容：

法則三：誰看、看多深
法則四（建立可驗證檢查點法則）：reviewer 看什麼才能信任

兩者配對：法則四的可驗證性設計三支柱（介面 / 測試 / 可觀測性）讓 reviewer 在 leaf 場景能高效抽查（而非逐行）。

違反時的常見症狀

❌ 「core PR 一位 reviewer 5 分鐘 approve」→ 沒做到逐行
❌ 「PR 沒標示 AI 範圍」→ Reviewer 不知道哪些要嚴看
❌ 「leaf PR 兩位 reviewer 都逐行讀」→ 浪費時間，沒按法則調整
❌ 「core 改但 owner 不在 reviewer list」→ 缺 cross-check

跟既有 SDLC 整合

此法則不取代既有 PR 流程，是疊加上去的「AI 產出特殊處理」：

原有 PR 流程
  + AI 範圍標示
  + Core / Leaf 標示
  + Core 需 owner + 兩位 reviewer 逐行

相關