什麼是 Vibe Coding？白話解說

Vibe coding 是用白話文描述你想要的東西給 AI，執行它產出的結果，並根據成果而不是程式碼來引導開發的方式。你負責判斷 App 好不好用：按鈕能不能按、頁面看起來對不對，然後要求修改，直到它符合你的需求為止。這個詞是 AI 研究員 Andrej Karpathy 在 2025 年 2 月於 X 上的一篇貼文中提出的，他在文中描述自己順著感覺寫程式、忘記程式碼的存在。

這個詞的由來

Karpathy 是 OpenAI 的創始成員之一，也曾擔任 Tesla 的 AI 負責人。他用這個詞來形容自己製作小型週末專案的方式：和 AI 寫程式工具對話，不看變更的差異就接受它的修改，遇到錯誤訊息就貼回去，直到能用為止。他明確表示，這種方式適合拋棄式的專案。

這個詞之所以流行，是因為它為許多人已經在做的事情取了名字。幾個月內，它就被用來指稱從興趣專案到新創原型的各種開發方式。柯林斯英語詞典更把「vibe coding」選為 2025 年的年度詞彙。如今，它被寬泛地用來指任何由 AI 撰寫程式碼、由人用白話文指揮的建置工作。

如果你要用 AI 建置，為什麼這很重要

對不寫程式的人來說，vibe coding 正是 AI App 建置工具有用的原因。創辦人可以在一個下午就測試一個點子；小型企業主可以建置原本永遠付不起外包費用的預約表單或庫存追蹤工具；設計師則能把設計稿變成可以點擊操作的東西。

但這個定義本身就帶著一個警告。「忘記程式碼的存在」在程式碼只需要今天為你一個人運作時，是沒問題的。但當 App 要儲存客戶資料、處理付款，或需要長期持續運作時，就沒那麼適合了。掌握這條界線在哪裡，是你在 vibe coding 中能學到最有用的一件事。

日常生活的比喻

想像你請營造商裝修廚房，而不是自己畫設計圖。你說：「窗戶下面要一個長檯面，開放式層架，冰箱放在門邊」，然後每天傍晚走進去看看做好的部分，再說要改哪裡。

這種方式對格局和外觀很有效，因為你站在房間裡就能判斷。但對牆後面的部分，效果就沒那麼好了：電線、水管，以及瓦斯管線是否符合規範。這些不是看一眼就能看出來的，而且問題可能要等到出事才會顯現。細心的屋主仍然會請人來檢查。

Vibe coding 也是一樣。畫面就是看得到的房間，安全性、資料處理和程式碼的組織方式，則是牆後面的電線。

Vibe coding 的實際樣貌

假設你想做一個簡單的工具，用來追蹤哪些客戶已經付清發票。

你從頭到尾都沒有打開過任何程式檔案。但請注意第 3 步：在真正儲存任何資料之前，App 看起來已經完成了。Vibe coding 獎勵那些能像使用者一樣測試，並且能精確描述所見內容的人。

好處

• 速度快。 幾分鐘或幾小時就能有可以運作的第一版，而不是幾週。
• 嘗試想法的成本低。 你可以做出三個版本，然後留下能用的那一個。
• 直接掌控。 最懂問題的人親自塑造產品，需求不會在轉交給開發人員的過程中流失。
• 從實作中學習。 許多人只要觀察 AI 建置的過程並追問原因，就能逐漸理解 App 各部分如何組合，例如前端與後端、資料庫以及 API。

真正的風險

這些並不是避開 vibe coding 的理由，而是 vibe 無法替你檢查的事情。

你看不見的安全漏洞

一個 App 可能看起來完美無缺，卻讓任何登入的使用者讀取其他人的所有紀錄，或在訪客瀏覽器執行的程式碼中暴露密鑰。以你自己的身分點來點去時，這些問題都不會出現。常見的問題包括伺服器端缺少權限檢查、把 API 金鑰放在前端程式碼中，以及表單接受任何輸入。

沒有人理解的程式碼

如果沒有人讀過程式碼，就沒有人知道它是如何組織的。規模小的時候還可以接受。隨著 App 成長，每次修改都可能弄壞不相關的部分，而 AI 有時會為了修好一個錯誤而製造另一個錯誤。許多經過數月 vibe coding、從未審查過的 App，往往比慢慢打造的 App 更難修改。

不知道什麼才算「完成」

AI 會很樂意告訴你某件事已經修好了。只有測試才能告訴你是否真的修好。跳過測試的人，最後得到的功能在示範時運作正常，但遇到真實資料就失敗：名字很長、欄位是空的、兩個人同時預約同一個時段。

隱藏的依賴與成本

AI 建置的 App 通常會連接外部服務，例如電子郵件服務商、付款處理商與 AI API。每一個都有自己的帳號、金鑰、限制與帳單。在上線前，要先清楚你的 App 依賴哪些東西。

常見的誤解

如何負責任地進行 vibe coding

幾個習慣就能涵蓋大部分的風險：

1. 保持小幅修改。 一次一個需求，一個修改，然後測試。模糊又龐大的需求，只會得到模糊又龐大的結果。
2. 使用檢查點。 在嘗試有風險的操作之前，確保你能還原到上一個可以運作的版本。
3. 請 AI 解釋。 「這個修改做了什麼？可能會弄壞什麼？」這些問題成本很低，卻能發現很多問題。
4. 以陌生人的身分測試。 以第二位使用者登入，並嘗試看看第一位使用者的資料。
5. 不要把密鑰放進程式碼或對話中。 API 金鑰應放在環境變數或專案的 secrets 中。
6. 在真實使用者出現前審查。 對於涉及付款或個人資料的 App，請依照安全檢查清單進行，或請開發人員幫忙檢視。

向你的 AI 建置工具要求什麼

以下提示可以把 vibe 轉為檢查：

• 「在建置之前，先告訴我你的計畫，以及這個 App 會儲存哪些資料。」
• 「列出這個 App 儲存或傳送使用者資料的每一個地方。」
• 「已登入的使用者能看到或修改其他人的紀錄嗎？請檢查伺服器端的程式碼，而不只是頁面。」
• 「瀏覽器中執行的程式碼裡，有沒有看得到的 API 金鑰？」
• 「如果兩個人在同一時間送出這個表單，會發生什麼事？」
• 「請摘要最近三次修改的內容。」

如需更多範例，請參閱如何為 AI App 建置工具撰寫提示；當出錯時，可參閱如何除錯 AI 建置的 App。

在 Mythex 中做 Vibe Coding

Mythex 是一款為這種工作方式打造的AI App 建置工具：你在對話中描述 App，代理程式在即時預覽中撰寫並執行程式碼，然後你可以把它發佈到公開網址。有幾項功能是專門針對上述風險設計的。規劃模式會讓代理程式在碰任何檔案之前先擬定做法，詢問模式只回答問題而不編輯任何內容，而每次成功的回合都會儲存一個檢查點，讓你可以還原。Pro 方案可以開啟完整的程式碼編輯器，也可以在你希望開發人員審查時匯出專案或同步到 GitHub。對話文件說明了各種模式與檢查點，如果面對空白頁面不知從何開始，範本可以提供起點。

常見問題