昨天講大型語言模型的基本機制，今天從火紅很久的詞 - Vibe Coding 開始講起。

Vibe Coding 是什麼? 能吃嗎?

Vibe Coding 是一種透過跟大型語言模型不斷對話後產生一個可以運行上線的產品。使用者可以在不需要任何的 AI 相關知識情況下，透過不斷打字輸入 prompt 給語言模型後，只需要不斷接受語言模型產生的程式，就可以有一個可以運作的 MVP (Minimal Valuable Product)

為什麼突然爆紅？

2025 年初，Andrej Karpathy（前 OpenAI、Tesla AI 負責人）在提出，他形容這種開發方式是：

「完全沉浸在氛圍裡，忘記程式碼的存在，甚至看都不太看 diff，只是一直跟 AI 對話、接受它的建議、複製貼上錯誤訊息、不太寫程式，卻在寫程式。」

透過打字即可讓語言模型產生一個可以顯示的 MVP，大幅降低許多人對程式碼的望之卻步，再加上社群媒體的不斷渲染，Vibe Coding 就此一炮而紅。

Vibe Coding 的典型工作流程

一個常見的 Vibe Coding 迴圈長這樣：

這個迴圈完全不需要使用者理解程式碼在寫什麼，只需要「描述想要的結果」跟「判斷結果對不對」。這也是為什麼 Karpathy 說「忘記程式碼的存在」——你操控的單位從「程式邏輯」變成了「自然語言意圖」。

聽起來很棒，那問題在哪？

1. 只是看起來可以用: 模型是在做「機率上最像對的」預測，不是「邏輯上驗證過的」推導 LLM 沒有真的「理解」你的商業邏輯，它只是根據訓練資料裡類似情境的模式去生成最可能符合的程式碼。這代表即使程式能跑，也不保證邏輯正確，尤其是邊界情況（edge case）、資安、資料驗證這類「看不出來哪裡錯，但真的會出事」的地方。

2. 無法維運: 使用者失去「看懂 diff」的能力，等於失去了唯一的品質守門員 當開發者完全不看程式碼，錯誤只能靠「執行結果對不對」來判斷。但很多問題不會馬上顯現：SQL Injection、權限控管漏掉、密鑰寫死在前端程式碼裡——這些在 demo 階段完全看不出來，卻是上線後的地雷。

3. 技術債: 每一輪對話生成的程式碼，可能跟前一輪的架構風格不一致，也可能為了「讓這次的錯誤消失」而寫出治標不治本的 patch。因為沒有人在做 code review，這些債務會安靜地堆疊，直到某天整個專案「AI 也修不動了」。

4. 不一定能上線:「能動」跟「該上線」是兩回事 Vibe Coding 特別適合做 MVP、Prototype、Demo，這些場景本來就容許粗糙。但如果同一套流程被直接用在正式產品、處理真實使用者資料，不一承擔得起成千上萬的流量使用。

那 Vibe Coding 到底該怎麼用？

比較務實的定位是：Vibe Coding 是「發散階段」的利器，不是「收斂階段」的解方。

想快速驗證一個點子能不能成立 → 適合
想做內部工具、一次性腳本 → 適合
想做正式產品的核心邏輯、金流、資安相關模組 → 建議還是要有人真正讀懂程式碼

也因此，越來越多工具（包含明天會提到的 Claude Code 等 Agentic Coding 工具）開始強調「保留使用者的掌控權」：讓你能看到 diff、能要求它先寫測試、能要求它解釋為什麼這樣改，而不是單純地「一直按 accept」。

這其實也呼應了昨天講的重點：LLM 是機率模型，不是真理生成器。它的輸出品質，很大程度上取決於你怎麼跟它互動、怎麼給它回饋、怎麼驗證它的結果——這件事在寫程式碼上，跟在寫文章、做決策上，本質是一樣的。

下一篇，我們會從 Vibe Coding 這種「純氛圍式對話」，進一步聊聊更結構化的 Agentic Coding：當 LLM 不只是回答問題，而是能自己規劃步驟、呼叫工具、驗證結果時，整個開發流程又會有什麼不同。