「Vibe coding」（氛圍程式設計）一詞為電腦科學家、OpenAI 共同創辦人安德烈．卡帕斯（ Andrej Karpathy ）在 2025 年 2 月提出。他在一則 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.」（有一種全新的寫程式方式，我稱之為氛圍程式設計，你完全沈浸在氛圍中，擁抱指數，忘記程式碼的存在。）
卡帕斯的觀點在於，隨著 LLM 能理解自然語言，開發者不必在乎程式語法，而能直接用人類語言來描述需求，讓 AI 產生程式碼，憑直覺驅動開發。
過去「不值得開發軟體所以用人工」的瑣事，現在可以靠vibe coding解決
若要為 vibe coding 下定義，我們可以說： Vibe coding 是一種強調直覺、快速驗證與臨時解決的開發方式，依賴 AI 工具修正錯誤、生成程式，並以「能運作即可」作為成功判準。
換句話說，它並不是軟體工程的替代品，而是存在於工程之外，處理的那些傳統流程「不值得」額外花錢解決，所以就使用人工的方式來解決。這些問題或許瑣碎，卻常常是企業效率的隱形殺手。vibe coding 讓這些小問題能被快速處理，而不至於演變成工作流程的長期阻塞。
過去，當開發者面對系統錯誤卻缺乏明確線索時，往往要靠經驗與直覺「猜」出問題根源，這種過程被比喻為在「通靈」或「觀落陰」 ：彷彿必須進入另一個世界，才能窺見程式背後的真相。
這種說法，反映出軟體開發中，工程師需要大量心智勞動去推敲與試探。相比之下，vibe coding 代表的是一個時代轉折。今天的工具能主動協助開發者解讀錯誤，甚至生成完整解法。
於是，折磨人的「通靈」，轉變成「vibe coding」的共創。兩者的異同，凸顯了從人類配合機器，到機器能理解人類語言的巨大躍進。
談到 vibe coding，最常被提及的案例，就是工程師遇到錯誤訊息時，整段丟給大語言模型（ LLM），讓 AI 自行推測並提供修正方案。這種做法看似隨意，卻正是 vibe coding 的精神所在： 與其執著於完整除錯，不如先快速取得可行解。
另一個典型場景，是在黑客松或快速原型開發中。傳統專案講求架構驅動，先設計藍圖再逐步落實；而 vibe coding 的邏輯則是「功能先行」，先做出能跑的東西，用來測試市場反應或推動內部討論。
更進一步， vibe coding 也是「先求有，再求好」的哲學。與其過度計較解決問題的姿態是否優雅，它更關心「問題能否被快速解決」。 這使 vibe coding 特別適合那些模糊、非典型的場景。例如臨時需要一個資料轉換工具，或行銷團隊想快速測試互動式頁面。這些情境不值得成立專案，卻在日常工作裡不斷出現。
vibe coding會否造成技術債？最好以沙盒思維孵化創意
許多人批評 vibe coding「難以除錯、難以維護」，但這些批評其實忽略了一點：vibe coding 從來就沒有打算移交或維護。它處理的是企業的 secondary issue（次要議題） ——那些沒有重要到企業要特地花錢、投入專案去解決，但卻一天到晚出現、影響效率的問題。
對企業而言，最大的疑慮在於 vibe coding 是否會擾亂秩序，甚至造成長期的技術債。若放任 vibe coding 的產出直接進入正式系統，確實可能有風險。企業需要為 vibe coding 畫定安全範圍，讓它成為創意的孵化器，而不是潛在的隱患，也就是應用「沙盒」的思維。
• 允許在實驗環境或內部專案中採用 vibe coding，但上線前必須重構；
• 設置低門檻的創新試驗區，讓員工嘗試各種小工具或自動化流程；
• 透過流程篩選，將其中有潛力的成果轉化為正式開發專案。
這樣一來，企業不需要「消滅 vibe coding」，而是「馴養 vibe coding」。vibe coding 並不是「錯誤的工程方法」，而是一種「非工程的方法」。對企業而言，它是一種低成本、高靈活度的創新策略。它能處理組織中的次要議題，強調先求有再求好的務實態度。唯有當我們正確認識並善用 vibe coding，給予合適的邊界與場域，它將成為補充正規工程的輔助力量，甚至成為創新與效率的泉源。
核稿編輯：張玉琦
