Leaf Node vs Core Code

Vibe Coding 安全紀律的核心分類：哪些程式碼適合大量讓 AI 寫（leaf），哪些必須由人主導（core）。

Erik 的原話

Leaf nodes 是沒有東西依賴它們的部分。即使有技術債也沒關係，因為不會擴散。

「我們把那個 22k 行的變更集中在 leaf nodes，因為那裡即使有點技術債，也不會擴散。」

維度	Leaf Node（適合大量 Vibe Coding）	Core Code（須人類主導）
變更傳播範圍	只影響呼叫此模組的少數位置	被許多模組依賴
預期變動頻率	短期內不會再大改	持續演進、需可擴展
技術債容忍度	容忍少量技術債	不容忍技術債
典型例子	報表、轉檔、單一 endpoint、UI 元件、scripts、單次性遷移	Auth、Billing、Domain Model、Framework、Public API、Data Schema
失敗成本	區域性、可快速回滾	全系統性、影響使用者 / 資料
是否需嚴格 Review	抽查即可	逐行 review

問自己：「如果這段程式碼出錯，影響會擴散多遠？」——擴散越遠越屬於 core。

場景	Leaf 還是 Core？	為什麼
「使用者填完問卷自動寄感謝信」endpoint	Leaf	只服務這條流程，壞了補寄一次就好，沒有別的功能依賴它
所有 API 都會經過的 auth middleware	Core	一旦寫錯，輕則把合法使用者擋在門外，重則讓未授權請求拿到資料，整條產品線都被它牽動
後台報表轉 CSV	Leaf	一次性 / 區域性
Payment webhook 處理	Core	涉及金流、資料一致性
內部 admin 工具 UI	Leaf	影響面有限
共用 Framework 升級	Core	全產品連動
一次性資料遷移 script	Leaf	跑完就丟，失敗手動 retry
Data Schema 改動	Core	跨服務、不可逆

四法則中，法則二明確規定：

AI 大量生成的程式碼應集中在葉節點：utilities、單一頁面、單一 endpoint、報表、轉檔腳本、UI 元件

核心架構（authn、payment、orchestrator、共用 framework、資料 schema）必須由人主導，AI 僅作輔助

法則三規定 review 強度依此分類調整：

Code 類型	Reviewer 數	Review 深度
Core PR	至少 2 位（其中 1 位該模組 owner）	逐行閱讀
Leaf PR	至少 1 位	重點審查介面契約與測試，可不必逐行讀實作

模型能力會持續變強。隨著新模型穩定性提升，core / leaf 的分界線會逐漸往 core 推進。

Tech Lead 應每季重新檢視這個分類清單。

譬如 2024 年「auth middleware 改造」幾乎一定是 core；但 2026 年若 AI 已能高度可靠地產出符合規範的 auth code，可能可以放寬到 leaf（前提是測試覆蓋與監控到位）。

四大黃金法則 (Vibe Coding) 提到——人生中大部分驗證問題都有不讀實作的方法，但技術債目前沒有。

所以聚焦 leaf 不只是「降低錯誤爆炸半徑」，更是「把不可避免的技術債限制在不會擴散的角落」。