Vibe Coding
由 Andrej Karpathy 最早提出的 AI 編程模式，核心是**「忘記程式碼存在」**——信任 AI 完成一整塊工作，只透過抽象層（規格、測試、輸入輸出）驗證，不讀完每一行。
Karpathy 原文定義（2025-02 X 貼文）
“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
關鍵在「忘記程式碼存在」這七個字。
出現背景
2024–2025 年 AI coding 工具（Cursor / Claude Code / Copilot）快速成熟，讓沒有系統性 coding 基礎的人也能「感覺像在開發」。Vibe Coding 是對這個現象的命名，不是方法論倡導——Karpathy 同時也強調它的侷限。
兩種視角逐漸成形：
- Hobbyist 原意（Karpathy 視角）：完全投降給 AI、不讀 code、能跑就好——適合 side project / 玩具
- 工程紀律視角（Erik Schluntz / Anthropic）：在 leaf node 場景配合工程紀律可生產可控——詳見 Vibe Coding 團隊規範 的 四大黃金法則
本 entity 整合兩個視角。
三種 AI 編程狀態（只有一個是真 Vibe）
| 狀態 | 描述 | 是否 Vibe Coding |
|---|---|---|
| AI 輔助寫 code | 用 Claude Code / Copilot 補完，工程師逐行 review | ❌ |
| 緊密回饋迴圈 | 持續一行一行盯著 AI 看 | ❌ |
| 真正 Vibe | 信任 AI 完成大塊工作，只透過抽象層驗證 | ✅ |
為什麼必須「不讀每行」？
Erik Schluntz 在 Anthropic「Vibe coding in prod」演講用了一個到位的類比：
早期使用編譯器的人會去讀組合語言確認沒問題，但這做法沒辦法 scale。最終你必須信任系統——挑戰只在於：「如何在不讀組合語言的情況下，仍然能負責任地交付產品？」
我們現在面對 AI 編程，正處於早期編譯器的階段。
為什麼非管不可：指數成長
Anthropic 內部追蹤的關鍵數字——AI 能完成的任務長度，每 7 個月翻倍一次：
| 時間點 | AI 能一次處理的任務量等級 |
|---|---|
| 現在 | 一天的工作量 |
| 一年後 | 一週的工作量 |
| 兩年後 | 數週到一個月 |
| 二十年後 | 「電腦快了一百萬倍」的世界 |
對個人決策意義不大（短期可選擇不用 AI），但對團隊：當 AI 可一次產出一週工作量時，仍堅持逐行審閱的人會直接變成團隊瓶頸。
「Embrace the exponential」常被誤解成「假設模型會變好一點點」。Erik 強調：模型會變得比預期還快地變強，不該用「兩倍好」準備未來，要用「百萬倍好」準備自己。
Hobbyist 原意 vs 工程紀律視角
| 維度 | Hobbyist Vibe（Karpathy 原意） | 工程紀律 Vibe（Vibe Coding 團隊規範） |
|---|---|---|
| 立場 | 放手給 AI、能跑就好 | 信任 AI 但建立可驗證檢查點 |
| 對 code 理解 | 刻意放棄 | 介面層必懂、實作可不讀 |
| 適用場景 | side project / 玩具 | Leaf node 生產系統 |
| 失敗處理 | 重 prompt 或丟掉 | 法則三 review + 法則四 stress test |
| 跟 Boris Cherny 13 條心法 | 對立（他主張 professional 必須 review） | 整合（leaf 可放，core 必 review） |
註：Boris Cherny 13 條心法跟工程紀律視角的 Vibe Coding 是相容的——core / leaf 二分法剛好調和「主導 vs 放手」的張力。詳見 反饋循環 概念。
Hobbyist Vibe 的侷限與風險
如果完全沒有任何工程紀律：
- 遇到 bug 時難以 debug（不懂底層）
- 產生的 code 技術債高
- 安全性漏洞風險（Vibe Coding Anti-Patterns 第 11 條：禁止對 secrets / payment / auth 做 vibe）
- 不適合需要維護的長期產品
→ 這就是為什麼團隊環境必須配合 四大黃金法則 (Vibe Coding) 才能 vibe。
但要有紀律：不是所有程式碼都該 Vibe
Vibe Coding 不等於「全部丟給 AI 去寫，然後 PR 直接 merge」。需要工程紀律支撐，落到 四大黃金法則 (Vibe Coding)：
- Be Claude’s PM 法則 — 為它提供完整上下文
- 聚焦 Leaf Nodes 法則 — 遠離核心架構
- 核心由人嚴格 Review 法則 — Core 區塊兩位 reviewer 逐行
- 建立可驗證檢查點 法則 — Reviewer 不讀實作也能信任
跟 Compounding Engineering 的關係
Compounding Engineering 是「AI 加速軟體開發」的廣義趨勢，Vibe Coding 是其中一種實作模式（特定於「信任 AI 寫大塊」的場景）。
跟其他 AI 編程詞彙的關係
| 詞彙 | 跟 Vibe Coding 的差異 |
|---|---|
| AI-assisted coding | 包含 vibe + 非 vibe 兩種 |
| Pair programming with AI | 指逐行盯（非 vibe） |
| Agent-native 開發者技能 | 廣義的 AI 協作能力，vibe 是其中一個能力 |
| 3A 架構 | 系統架構視角，vibe 是工作流視角 |
何時該用 / 不該用
✅ 適合 Vibe：
- Leaf nodes（utility / 單一 endpoint / UI / 一次性 script）
- 已有完整測試覆蓋的場景
- 失敗成本可承受、可快速回滾
❌ 不適合 Vibe：
- 核心架構（auth / billing / framework / data schema）
- 跨多模組的重構
- 不熟的 codebase 第一次接觸
- 高風險業務邏輯
相關
- Vibe Coding 團隊規範 — Appleboy 整理的完整 SDLC 規範（本概念來源）
- 四大黃金法則 (Vibe Coding)
- Leaf Node vs Core Code
- 可驗證性設計三支柱
- Plan-then-Execute SOP
- Vibe Coding Anti-Patterns