法則二：聚焦 Leaf Nodes，遠離核心架構
四大黃金法則 (Vibe Coding) 第二條。把 AI 大量產出的 code 限制在「即使有點技術債也不會擴散」的地方。
Erik 原話
我們把那個 22k 行的變更集中在 leaf nodes，因為那裡即使有點技術債，也不會擴散。
規範要求
✅ AI 大量生成的程式碼應集中在葉節點：
- utilities / 單一頁面 / 單一 endpoint / 報表 / 轉檔腳本 / UI 元件 / 一次性遷移 script
❌ 核心架構（authn / payment / orchestrator / 共用 framework / 資料 schema）必須由人主導，AI 僅作輔助
判斷標準
詳見 Leaf Node vs Core Code。摘要：
| 維度 | Leaf | Core |
|---|---|---|
| 變更傳播範圍 | 少 | 多 |
| 技術債容忍度 | 容忍 | 不容忍 |
| 失敗成本 | 區域性、可回滾 | 全系統性 |
判斷小技巧：問「如果這段 code 出錯，影響會擴散多遠？」
為什麼這條這麼重要
四大黃金法則 (Vibe Coding) 提到一個重要例外——技術債目前沒有不讀程式碼就能驗證的方法。
所以 vibe coding 必須在空間上限制，把不可避免的技術債限制在不會擴散的角落。否則 AI 寫了 1000 行 leaf code 還行，寫了 100 行 core code 沒被嚴格 review 就可能害死整個系統。
動態邊界
Tech Lead 應每季重新檢視 core / leaf 分類清單。
模型能力會持續變強，新模型穩定性提升後，core / leaf 分界線會逐漸往 core 推進。
落地工具
- Leaf Node vs Core Code — 完整分類標準
- 每個團隊應維護自己的「Core 模組清單」（譬如 IT vault 內 Wiki_刪檔處理SOP 是 core wiki 維護工具）
- PR 模板（AI 編程 PR 模板）要求標示 leaf / core
跟法則三的關係
法則二（在哪做 vibe）跟法則三（review 強度怎麼分）是配對的：
法則二 (空間限制) ──→ 法則三 (review 配比)
Leaf → 大量 vibe Leaf → 抽查 / 重點審介面
Core → 限制 vibe Core → 兩位 reviewer 逐行
違反時的常見症狀
- ❌ 「這個 PR AI 寫了 5000 行，主要動 auth middleware」→ 應該停下來
- ❌ 「重構整個 framework，AI 全自動寫」→ 應該停下來
- ❌ 「Data schema migration AI 自己做」→ 應該停下來
- ✅ 「補 50 個 utility function，AI 寫，我抽查」→ OK
- ✅ 「新 endpoint，AI 寫實作 + 測試，我 review 介面」→ OK
相關
- Vibe Coding / 四大黃金法則 (Vibe Coding)
- Leaf Node vs Core Code — 分類標準
- Be Claude’s PM 法則 — 法則一
- 核心由人嚴格 Review 法則 — 法則三（配對使用）
- 建立可驗證檢查點 法則 — 法則四
- Vibe Coding Anti-Patterns — 違反時的反模式