氛圍程式設計（Vibe Coding）

在實踐中

這個詞不是本站造的，也不是「用 AI 輔助寫程式碼」的泛稱。Karpathy 在 2025 年 2 月提出它時是帶著讚許的，指的是一種很具體的模式，場景是隨手寫完就丟的週末專案：跟模型說話、接受它給的改動、跑起來，從不開啟那個檔案。它的定義性特徵不是「程式碼由 AI 寫」，而是「沒有人讀過」。一個逐行評審、測試、真正讀懂了每一行生成程式碼的工程師，是在用 AI 寫程式碼，而不是在氛圍程式設計。柯林斯詞典把它評為 2025 年年度詞彙——這足以說明，這種做法早已遠遠溢位了它被造出來時那個週末專案的語境。

氛圍程式設計比批評者預期的更好用，難辦的正是這一點。第一版是真的能跑——表單能提交、測試能過、CI 全綠——因為「自洽」恰恰是程式碼模型最擅長的事。綠色的 CI 證明不了的是：這套系統只做了它被允許做的事。而只要沒有什麼需要改，這道缺口就一直看不見。代價出現在第一次修改：問題不再是「能不能做出來」，而是「我改了這裡，還有什麼會跟著動」——而且找不到作者可問，因為作者是一次無狀態的會話，幾個月前就結束了。這種「對自己正在執行的系統失去解釋能力」的累積，就是理解債。

這些都不是在論證人應該退回去手寫實現——那場比賽在成本上已經結束了。它論證的是 AI 交回來的東西是什麼形狀。一個返回八千行實現的提示詞，和一個返回四十行帶型別應用定義的提示詞，輸入端的「氛圍」是一樣多的——但只有其中一個，交回來的東西人還讀得動、審得了、擔得起責。ObjectStack 就是為第二種形狀做的：程式碼仍然由 AI 寫，而產物小到「沒人讀過」不再是預設結局。