常見情境決策表 (Vibe Coding)
不知道某個任務適不適合 Vibe Coding？查表。本決策表是 Vibe Coding Anti-Patterns 的正面對照——前者列「絕不能」，本表列「該怎麼選」。
決策表
| 情境 | 建議做法 | 理由 |
|---|---|---|
| 想加一個新的內部報表 | ✅ 適合 Vibe Coding | Leaf node，影響面有限 |
| 想重構支付流程 | ❌ Core code，AI 僅輔助、人主導 | 聚焦 Leaf Nodes 法則 / Vibe Coding Anti-Patterns |
| 想寫一次性資料遷移腳本 | ✅ 適合 Vibe Coding，驗證腳本要嚴謹 | Leaf 但失敗難回滾，需 soak test |
| 想換掉 ORM | ❌ 不適合單純 Vibe Coding，需架構設計 RFC | 影響面廣、跨模組 |
| 想加個 UI 表單 | ✅ 適合 Vibe Coding | 典型 leaf node |
| 想改 auth middleware | ❌ Core code，逐行 review | 安全核心 |
| 想加一個 cron job 跑 24 小時 | ✅ 可 Vibe Coding，但必須有 soak test | 建立可驗證檢查點 法則 |
| 修一個小 bug | ✅ 可 Vibe Coding，但仍需測試覆蓋該 bug | 防 regression |
| 想引入新框架 | ❌ 屬於架構決策，須先 RFC | 全產品連動 |
| 不熟的 codebase 想加新功能 | ⚠️ 先做探索 SOP，再進入 vibe coding | 陌生 Codebase 探索 SOP |
| 處理使用者 PII / 金流 | ❌ 必須人主導，core code 等級 review | 法務 / 合規風險 |
| 寫個小 game / side project | ✅ 隨意 vibe code | 本規範不強制（個人專案） |
三個信號
| 信號 | 偏向 |
|---|---|
| 失敗成本可承受？ | ✅ Vibe |
| 影響面只有單一模組？ | ✅ Vibe |
| 已有完整測試覆蓋的 reference 實作？ | ✅ Vibe |
| 涉及 secrets / payment / auth？ | ❌ Core |
| 跨多個模組？ | ❌ Core |
| 需要架構決策（譬如換 framework）？ | ❌ RFC 先 |
| 不熟悉這個 codebase？ | ⚠️ 先探索 |
決策樹
Q1: 涉及 secrets / payment / auth / PII？
✅ 是 → 強制 Core code，人主導
❌ 否 → Q2
Q2: 跨多個 core 模組？
✅ 是 → 強制 Core，或拆成多個 leaf PR
❌ 否 → Q3
Q3: 屬於架構決策（換 framework / DB / ORM）？
✅ 是 → 先 RFC，本規範不適用
❌ 否 → Q4
Q4: 對這個 codebase 熟嗎？
❌ 不熟 → 先做 [[陌生 Codebase 探索 SOP]]
✅ 熟 → Q5
Q5: 失敗成本可承受 + 可快速回滾？
✅ 是 → Vibe Coding 適合
❌ 否 → 至少加 soak test + Module Owner review
跟其他工具的關係
| 工具 | 角色 |
|---|---|
| Vibe Coding Anti-Patterns | 「絕不能」清單（11 條） |
| Leaf Node vs Core Code | 分類維度的詳細展開 |
| 聚焦 Leaf Nodes 法則 | 法則層的規範 |
| Code Review 準則 (AI 編程) | Reviewer 用此表判斷 PR 是否合理 |
| 本表（決策表） | 操作層的快速查找 |
動態演進
⚠️ 表格內容會隨模型能力變化。譬如：
- 「想換掉 ORM」現在不適合 vibe，未來模型有夠 reliable 的 schema migration 能力時可能放寬
- 「想加一個 cron job 跑 24 小時」現在 OK 但要 soak test，未來可能放寬到「跑 30 分鐘 unit test 即可」
→ Tech Lead 每季重檢決策表（AI 編程角色責任矩陣 的 Tech Lead 責任）。
違反時的常見症狀
- ❌ 「我以為 cron 是 leaf，沒做 soak test」→ 沒查決策表
- ❌ 「想換 ORM 直接 vibe」→ 違反「需 RFC」分類
- ❌ 「處理 PII 的 endpoint 用 vibe」→ 違反「core code 等級」分類