Vibe Coding
為什麼重要
深度解析
Karpathy 最初的描述刻意帶有挑釁意味：以語音輸入取代打字、完全不看 diff 就對每項建議變更按下「全部接受」，再把錯誤訊息貼回模型，直到錯誤消失。去除挑釁元素後，工作流程很簡單——描述、生成、執行、回應——人類扮演產品經理與測試人員，而非作者。這種做法在 2025 年變得可行，並不是因為 AI 突然能撰寫程式碼——AI 程式編寫助手早已這麼做了數年——而是底層大型語言模型的能力已足以在多輪迴圈中維持整個小型專案的一致性。短短幾個月內，這個詞便傳出科技圈，出現在主流媒體與 Collins Dictionary 年度詞彙候選名單中，並成為概括「哪些人能建構軟體」這項真實轉變的預設用語。
讓它成為可能的工具
程式編寫助手加入代理模式後，Vibe Coding 才真正變得實用。Cursor、GitHub Copilot 與 Windsurf 等工具不再逐行自動完成，而能同時編輯多個檔案、建立新檔案、執行 shell 命令與程式、讀取輸出並反覆修改——這正是 Vibe Coder 想委派的迴圈。較長的上下文視窗讓模型能同時掌握整個小型專案的程式碼，而更出色的指令遵循能力，則代表即使只粗略描述意圖，通常也能產生可執行的結果。Devin 等自主性更高的工具將相同概念推進一步：取得任務描述後，只需極少監督便可長時間持續工作。
Vibe Coding 最適合的情境
最適合的情境，是有用但可拋棄的軟體：週末專案、個人工具、一次性資料指令碼、原型、示範和內部儀表板。Karpathy 自己描述的是可拋棄的週末專案——若以人工撰寫，投入的心力會超過回報，過去根本不值得動手。對不會程式設計的人而言，吸引力更加直接：教師、行銷人員或小型企業主可以描述一款小型應用程式，並在一個下午內取得可運作的版本；以往必須聘請開發人員或自行學習程式設計。資深工程師則以相同模式處理樣板程式碼、移轉及黏合程式碼，這些工作的解法形態明確，逐行閱讀的額外價值有限。在這些情境中，細微錯誤的代價都不高，因此省略審查步驟是合理取捨。
審查債與安全債
風險就是相同選擇的另一面。模型可能幻覺出不存在的函式庫函式、選用已淘汰的 API，或錯誤設定身分驗證；如果沒有人查看 diff，這些錯誤就會直接發布。AI 安全研究人員一再發現，AI 生成程式碼存在相當比例的漏洞——包括注入漏洞、缺少授權檢查與硬式編碼的機密資訊——2025 年也發生一連串事件，匆忙透過 Vibe Coding 打造的應用程式在正式環境中洩露使用者資料或 API 金鑰。還有一項更緩慢的結構性成本：無人完全理解的程式碼庫很難除錯，一旦規模超過模型上下文視窗所能容納的範圍，連 AI 都會開始做出不一致的變更。批評者將最糟糕的這類輸出歸為AI 垃圾內容——程式碼看似合理，大致可以執行，卻悄悄腐化。
它不等於 AI 輔助程式設計
常見的誤解，是認為 Vibe Coding 只是所有 AI 輔助程式設計的新名稱。事實並非如此。這個詞特別指放棄審查步驟：如果程式碼由模型撰寫，但你已讀過、理解內容並願意承擔責任，那只是工具更加完善的一般 AI 輔助開發——Simon Willison 等作者很早就清楚而明確地劃出這條界線。相反的誤解，是認為人類毫無貢獻。實務上，優秀的 Vibe Coding 本身也是一項技能：精確描述意圖、知道下一步該提出什麼要求，以及辨識輸出是否有問題，都十分重要；因此，這種做法與提示詞工程和上下文工程有所重疊。
專業團隊實際上怎麼用
多數專業團隊最後會採用混合模式。原型以 Vibe Coding 製作——快速、可拋棄，只在意示範效果——任何要進入正式環境的內容則接受正常審查，以測試與 CI 作為安全網，取代前期逐行閱讀的部分工作。常見界線在於風險：內部工具與指令碼可自由採用，但身分驗證、付款及任何接觸使用者資料的功能，無論如何撰寫都必須由人類仔細檢查。資深開發人員通常最能受益於這種方式，因為他們的直覺能迅速找出看來不對的輸出；初階開發人員若太早依賴它，則可能發布自己無法解釋或修正的程式碼。許多團隊最後採用的思考模式，是將生成程式碼視為一名速度極快但粗心的初階同事所提交的 pull request——內容有用且值得歡迎，卻永遠不能在未讀的情況下合併。