四大黃金法則 (Vibe Coding)
Vibe Coding 不是「全部丟給 AI 然後 PR merge」，要有紀律。Appleboy 整理 Erik Schluntz Anthropic「Vibe coding in prod」演講後，把工程紀律歸納成四條法則。
一覽
| # | 法則 | 一句話 |
|---|---|---|
| 1 | Be Claude’s PM 法則 | 為 AI 提供完整上下文，把它當新員工而非工具 |
| 2 | 聚焦 Leaf Nodes 法則 | AI 大量寫 code 集中在不擴散影響的葉節點 |
| 3 | 核心由人嚴格 Review 法則 | Core 區塊兩位 reviewer 逐行讀 |
| 4 | 建立可驗證檢查點 法則 | 設計到讓 reviewer 不讀實作也能判斷正確 |
核心精神
「像 manager 管理領域專家」——軟體工程師是少數「習慣自己什麼都懂到底」的職業，但 AI 把編碼工作放大一個量級後，這份習慣變成包袱。借用其他職業的管理智慧：
| 角色 | 不懂實作但仍能驗證的方法 |
|---|---|
| CTO 對領域專家 | 寫驗收測試 (acceptance tests) |
| PM 對工程團隊 | 真的去用產品，確認行為符合預期 |
| CEO 對會計師 | 抽查自己懂的關鍵數據與切片 |
對應到 Vibe Coding：
- 像 CTO：設計可驗證的介面與測試
- 像 PM：真的把功能用起來，測 happy path 與錯誤路徑
- 像 CEO：抽查關鍵邊界、輸入輸出、效能數據
一個重要例外：技術債
人生中大部分要驗證的事情，都有不需要懂實作就能驗證的方法——但技術債目前沒有好方法在不讀程式碼的情況下衡量。
所以才需要把 Vibe Coding 聚焦在 leaf node（法則二）：把可能產生的技術債限制在不會擴散的角落。
法則之間的關係
法則一 (Be PM) ─┐
├─→ 法則二 (Leaf Nodes) — 限制爆炸半徑
法則三 (Core Review) ┤
├─→ 法則四 (Verifiable Checkpoints) — 抽象層驗證
─┘
法則一是輸入端（給 AI 上下文），法則二是空間限制（在哪做 vibe），法則三是品質門檻（core 由人 review），法則四是驗證機制（不讀實作怎麼信任）。
落地工具
四法則對應的工具與 SOP：
| 法則 | 對應工具 / SOP |
|---|---|
| 一：Be Claude’s PM | Plan-then-Execute SOP / Prompt 必備六元素 |
| 二：聚焦 Leaf Nodes | Leaf Node vs Core Code 分類標準 |
| 三：核心由人 Review | Code Review 準則 (AI 編程) / AI 編程 PR 模板 |
| 四：可驗證檢查點 | 可驗證性設計三支柱 / Vibe Coding TDD 三條 e2e 測試 |
動態調整
模型能力會持續變強。隨著新模型穩定性提升，core / leaf 的分界線會逐漸往 core 推進。Tech Lead 應每季重新檢視這個分類清單。
相關
- Vibe Coding — 上層概念
- Vibe Coding 團隊規範 — Appleboy 完整論述
- AI 編程角色責任矩陣 — 法則對應角色責任
- Vibe Coding Anti-Patterns — 違反四法則的常見錯誤