Vibe Coding Anti-Patterns
Vibe Coding 團隊規範 明列的 11 條禁止事項——進入 main 分支即違規，PR 直接退回。
11 條禁止事項
| # | 反模式 | 違反法則 |
|---|---|---|
| 1 | **「一句 prompt → 直接 commit」**的工作流 | Be Claude’s PM 法則 / Plan-then-Execute SOP |
| 2 | AI 大量改動 core code 卻未逐行 review | 核心由人嚴格 Review 法則 |
| 3 | PR 沒有測試，只有「我跑過了沒問題」 | 建立可驗證檢查點 法則 |
| 4 | PR 沒有標示 AI 產出範圍 | 核心由人嚴格 Review 法則 / AI 編程 PR 模板 |
| 5 | 在不熟悉的領域用 AI 大量產出 | 陌生 Codebase 探索 SOP |
| 6 | 跨多個 core 模組的「巨型 AI PR」 | 聚焦 Leaf Nodes 法則 |
| 7 | 把 AI 的錯誤訊息原封不動貼回 prompt 反覆試錯，不思考原因 | Be Claude’s PM 法則（PM 心態） |
| 8 | Reviewer 因為「看不懂所以信任 AI」而 approve | 核心由人嚴格 Review 法則 |
| 9 | Prompt 過度約束（每行命名都寫死）導致模型表現變差 | 過度約束反效應 |
| 10 | 對話 token 數爆量還硬撐不 compact，導致函式名稱漂移 | Compact 與 Session 管理 SOP |
| 11 | 對處理 secrets / payment / auth 的程式做 vibe coding | 聚焦 Leaf Nodes 法則（這些是 core） |
為什麼這些是「禁止」（不是「建議避免」）
每條都有實證教訓 —— 違反後極可能進事故 retro。譬如：
- 反模式 #11：AI vibe code 寫 auth bypass，整條產品線資安出事
- 反模式 #6：巨型 AI PR core 改動，回滾不可能
- 反模式 #2：AI 寫 core code 沒逐行，bug 進 production
三類反模式（按性質分組）
A. 流程紀律類（#1, #3, #4, #7, #10）
「捷徑誘惑」——省略步驟反而踩雷。
B. 邊界意識類（#5, #6, #11）
「越界使用」——把 vibe coding 用在不該用的地方。
C. 認知偏誤類（#2, #8, #9）
「思考懶散」——以「AI 應該會做對」當藉口跳過判斷。
違反時的處置
PR 退回 + 在 PR 留 standardized 退回理由：
此 PR 違反 [[Vibe Coding Anti-Patterns]] 第 N 條：「<反模式名稱>」
修正方式：
- <具體建議，譬如：拆成 3 個 leaf-node PR、補 plan.md、補 e2e 測試>
請依 [[AI 編程 PR 模板]] 重新整理後再 push。
跟 Code Review 準則 (AI 編程) 的關係
Code Review 準則的 6 條退回理由就是這 11 條反模式的 reviewer 視角：
| 反模式 # | 標準退回理由 |
|---|---|
| #1, #3 | 沒有 plan.md 或計畫摘要 |
| #2, #8 | Core code 變更缺少逐行 review 紀錄 |
| #3 | 測試只有 happy path / 沒有 stress test |
| #4 | 沒標示 AI 產出範圍 |
| #6 | 動到了 PR 中聲明「不可動」的範圍 |
| #11 | 對 secrets / payment / auth 做 vibe coding |
跟 常見情境決策表 的關係
決策表是正面案例（哪些可以 vibe），反模式是負面案例（哪些絕不能）。配對使用：
- 想做 X → 先查決策表「適合 vibe 嗎？」
- 進入流程後 → 對照反模式清單「我有沒有踩雷？」
動態演進
⚠️ 這 11 條會隨模型能力變化：
- 譬如 #11「auth 不能 vibe」可能在未來幾年後鬆綁（前提：AI 對 auth pattern 已高度可靠 + 測試覆蓋到位）
- Tech Lead 應每季重檢清單
但「核心由人主導」這個精神不會變，只是「核心」的範圍可能縮小。