2025 年 2 月，Andrej Karpathy（OpenAI 共同創辦人、前特斯拉 AI 總監）提出一個新詞：Vibe Coding。他的描述是完全順著感覺走、擁抱指數成長，忘記程式碼的存在。這個詞後來被 Collins 英語詞典選為 2025 年度詞彙。

一年過去，研究者開始替這種寫法算帳。結論大致是：做得出來很快，改得動很難。

Vibe Coding 跟「用 AI 寫程式」不一樣

很多人把兩者混為一談，其實差在一件事：你看不看程式碼。

  • AI 輔助寫程式：AI 產生程式碼，人還是會讀、會改、會審。
  • 純 Vibe Coding：人不讀程式碼，只看執行結果對不對，不對就叫 AI 再改。

Karpathy 自己一開始就說，這適合「用完即丟的週末專案」。問題是很多人拿它來做要長期維護的東西。

論文怎麼說：流動與債務的取捨

幾篇 arXiv 上的研究（其中一篇標題就叫〈Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use〉）提出一個說法：流動—債務權衡（Flow-Debt Tradeoff）。

前期你感受到的是「流動」——想到什麼、講一句話就做出來，非常順。但系統從原型走向正式產品時，累積的脆弱性會急速上升。研究歸納出三種典型的技術債：

  • 需求模糊：你只描述「要有什麼功能」，沒講安全、效能、可維護性，AI 也不會主動幫你想。
  • 架構拼湊：每次 prompt 都只解決眼前的問題，久了變成東一塊西一塊——論文舉的例子是同一個系統裡混用兩種登入機制，最後整合失敗；還有重複出現好幾份做同樣事情的工具檔。研究者把這叫「結構性熵增」。
  • 維護崩潰：看起來能跑，改一個地方整個垮掉，被形容成「紙牌屋程式碼」。

我自己的例子：一套線上排隊系統

2025 年 6 月，我用 AI 對話從零做過一套 QR Code 線上排隊系統：顧客掃碼取號，前端用 React，後端用 Firebase。我不是專業的前端工程師，整個過程幾乎都是用講的。

結果是做得出來，但過程遠比想像中長：光是開發對話就累積了將近 600 KB 的文字，卡最久的地方不是功能本身，而是「Firebase 的設定值去哪裡找」「環境變數怎麼在打包時注入」這類周邊問題。這正是論文講的流動—債務權衡：每一步都很快，但總路程很長，而且散落在幾十段對話裡，事後很難整理出完整的架構。

還有一個教訓：跟 AI 來回貼程式碼的時候，很容易把設定值一起貼進對話。Firebase 的前端金鑰本來就會出現在網頁原始碼裡，真正的防線是資料庫的存取規則和金鑰的使用限制——但這件事 AI 不會主動提醒你，你得自己知道要去設。

怎麼用才不會被帳單嚇到

  • 先分清楚用途：一次性的工具、內部小腳本、原型展示，放心 Vibe；要長期維護、有人付錢用、碰到個資的系統，就要讀程式碼。
  • 把非功能需求講出來：安全、權限、錯誤處理、效能，第一次就寫進需求裡，不要等出事才補。
  • 定期叫 AI 整理架構：每做完一段，請它畫出目前的資料結構與檔案分工，順便找出重複的程式碼。
  • 金鑰與設定值不要貼進對話：用變數名稱代替真實值。

小結

Vibe Coding 最大的價值，是讓不會寫程式的人也做得出東西；最大的風險，是做出來之後沒人看得懂。前期的「流動」是真的，後面的「債務」也是真的——差別只在你什麼時候開始還。

資料來源

  • Andrej Karpathy 2025 年 2 月的貼文；Collins English Dictionary 2025 年度詞彙
  • arXiv：〈Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use〉、〈Vibe Coding in Practice: Motivations, Challenges, and a Future Outlook — a Grey Literature Review〉
  • 本人開發對話紀錄（2025-06）

封面圖由 AI 生成。