Vibe Coding 是什麼？用 AI 寫程式的完整運作方式與學習順序

前言

Vibe Coding 是用自然語言描述需求、讓 AI 產生程式碼的開發方式，你負責判斷，AI 負責打字。它把門檻從「會不會寫」換成「講不講得清楚」，程式本身沒有變簡單。這篇拆它實際怎麼運作、一般人能做出什麼、四個階段該照什麼順序學，以及三種最常見的翻車狀況。

Vibe Coding 是什麼，中文翻譯為什麼誤導人

中文圈常把 Vibe Coding 翻成「氛圍編程」或「感覺寫程式」，翻譯本身就把重點翻歪了。它真正的意思是：你用自然語言描述你要什麼，由 AI 生成程式碼，你的工作從「寫」變成「指揮跟驗收」。

差別在哪，用一個場景就講得完。以前你想做一個「每天早上把昨天的訂單整理成一張報表」的小工具，你得先會一種程式語言、知道怎麼連資料庫、知道怎麼排程。現在你打開一個 AI 工具，把上面那句話貼進去，它會回你一份可以跑的程式，你的工作變成看它跑出來的東西對不對、哪裡要修。

這件事變化最大的地方是門檻換了位置。門檻沒有消失，它從「語法」移到「表達」與「判斷」。你講不清楚要什麼，AI 就給你一個它猜的版本；你看不出來結果哪裡怪，你就會把一個有問題的東西當成完成品。

Karpathy 提出時指的是哪一種情境

這個詞是 Andrej Karpathy 在 2025 年 2 月講出來的，他是 OpenAI 共同創辦人，也做過 Tesla 的 AI 與自動駕駛視覺主管。他當時的原話大意是：有一種新的寫程式方式，你完全交給感覺、擁抱指數成長，甚至忘記程式碼的存在。

很多文章引用到這裡就停了，但有個前提常常被跳過：他描述的是「週末做小專案」的情境，不是拿來蓋一個要收錢、要放客戶資料的正式系統。他自己在同一段話裡提到，做這種東西的時候他甚至不看 diff，直接按接受。

後面會講到的三種翻車狀況，幾乎全部來自把「週末專案的做法」直接套到「要上線的東西」身上。

中文的翻譯讓這個誤會更嚴重。「氛圍編程」「感覺寫程式」聽起來像是不用動腦、跟著感覺走就會有東西跑出來，實際的體感完全不是那樣。真正在做的時候，你大部分時間在做的事是描述、檢查、判斷這段能不能收、要不要退回去重來。要說像什麼，比較像帶一個手很快但不會自己確認的新人，你省下打字的時間，全部拿去做驗收。

AI 輔助跟 Vibe Coding 差在決定權

市面上常把「用 AI 寫程式」全部混成一件事，實際上有三個層級，決定權的位置完全不同：

三者不是取代關係，是同一個人在不同情境會切換的三檔。我自己做官網的樣式微調會用第二檔，做一個全新的小工具會用第三檔，遇到牽涉金流或使用者資料的部分會退回第一檔自己看。

Vibe Coding 實際怎麼運作，一句話是怎麼變成能跑的程式

搞懂運作方式，你才會知道它為什麼有時候神準、有時候莫名其妙鬼打牆。

AI 看到的不只你打的那句話

你輸入的那句話，會跟一堆你看不到的東西一起被送進模型：目前打開的檔案內容、專案的資料夾結構、之前幾輪的對話、工具本身預設的系統指令。模型拿到這一整包之後，做的事情本質上是「根據前面所有內容，推測接下來最合理的字元」。

程式碼對模型來說跟中文句子沒有本質差別，都是有規律的符號序列。它之所以寫得出能跑的程式，是因為它讀過大量真實的程式碼，學到了「在這種情境下，通常會這樣寫」。

關鍵在於它輸出的是「最合理的猜測」，不是「驗證過正確的答案」。它不會執行、不會測試，除非工具本身額外幫你跑。所以一段語法完全正確、看起來很專業、但邏輯是錯的程式碼，對模型來說是完全合理的輸出。

為什麼同一句話每次生出來的程式碼都不一樣

你可能遇過：同一個需求問兩次，給你兩個做法完全不同的版本。這是機率抽樣的正常結果。模型每一步都是在一堆候選字元裡挑，挑的過程帶隨機性，起手的第一個選擇不同，後面整段就會岔到另一條路。

實務上這件事有兩個影響。第一，你不能期待「重問一次會得到一樣的東西」，要留存的版本就要當下存起來。第二，卡住的時候換個說法重問，常常比在同一條路上一直催它修有效，因為你等於讓它重新抽一次。

上下文塞滿之後會發生什麼事

同一個模型、同一句話，在空專案跟在你既有專案裡給出的結果會差很多，差別就在上下文。你可以把上下文想成 AI 的短期工作記憶，它一次能塞進去的量有上限，超過就會開始遺漏前面的內容。

這解釋了幾個常見現象：聊到很後面它開始忘記你前面訂的規則、改 A 功能的時候把 B 功能弄壞、你明明講過的限制它又犯一次。都不是它故意的，是那段內容已經被擠出視窗了。

對應的做法是把重要的規則寫成專案內的設定檔，讓工具每次都自動讀進去，而不是靠你在對話裡重複講。這是我在自己專案裡最有感的一個改變，把「這個專案的框架有哪些慣例、哪些東西不准動」寫成固定檔案之後，同樣的錯誤重犯的次數明顯少掉。

另一個實務上很有用的習慣是分段開新對話。一個功能做完就開一輪新的，不要讓一條對話從早聊到晚。舊的內容留在裡面除了佔位置，還會干擾判斷，它會參考你三小時前已經放棄的做法。

為什麼 AI 會用很有自信的語氣寫錯程式

最讓人不習慣的一點是：AI 寫錯的時候，語氣跟寫對的時候一模一樣。它不會說「我不太確定這段對不對」，它會說「已經完成，這個做法可以正確處理你的需求」。

原因回到前面講的機率抽樣。模型輸出的是「看起來最合理的字」，而「有自信的說明」在訓練資料裡本來就是最常見的寫法。它沒有一個內建的機制去區分「我知道」跟「我猜的」。

這件事在兩種情況下特別危險。一種是它引用了不存在的東西，比如某個套件根本沒有那個功能、某個設定參數是它掰的，這種通常一跑就報錯，還算好處理。另一種是它用了一個真的存在、但不適合你這個情境的做法，程式跑得起來、結果也出得來，只是在某些條件下會算錯，這種要等到你發現數字不對才會抓到。

所以驗收的標準不能是「有沒有跑起來」，要是「結果對不對」。拿一組你已經知道正確答案的資料丟進去跑，比看它的說明可靠得多。

史丹佛大學 Neil Perry 等人做過一個實驗，把受試者分成有 AI 助手跟沒有的兩組寫程式。結果是有 AI 那組寫出來的程式碼明顯更不安全，而且他們比另一組更相信自己寫的是安全的。這個落差就是這一節在講的事：AI 的語氣會傳染，你會跟著它一起有信心。

一般人用 Vibe Coding 可以做出什麼

網路上的示範很愛用「五分鐘做一個網站」當標題，做出來的都是靜態頁面。實際的能力範圍比那個廣，但也有明確的天花板。

我用 Vibe Coding 做出來的四種範例

網站、自己用的小工具、自動化工作流、一款遊戲，這四類我都做過：

• 對外的網站：包含文章系統、訂閱表單、作品集頁面，這種需求最成熟，AI 產出的品質也最穩定，完整流程見不會寫程式怎麼用 AI 做出自己的網站。
• 自己用的小工具：像是把貼過來的 HTML 洗掉多餘格式、台股自選股的健檢清單，這類「只有我一個人用、規格我自己說了算」的東西，是 Vibe Coding 投報最高的區塊。
• 自動化工作流：把 GA4 跟 Search Console 的數字每週自動整理成報表、競品動態每週自動彙整。這類需求裡 AI 主要幫的是設定與資料轉換的邏輯，不是整套系統。要讓它會回答問題而不只是搬資料，得再接一層知識庫，做法見客服機器人怎麼建。
• 一款能玩的遊戲：用 Godot 搭 Claude Code 做的戰棋卡牌手遊，這是四類裡面最吃「你講不講得清楚」的，因為遊戲規則的細節極多，描述漏一條，出來的行為就整個歪掉。

這四類的難度不是照上面的順序遞增。真正影響難度的是「你的需求有多少條規則」。做一個網站的頁面，規則大概十幾條，AI 一次就能抓到大部分；做一款遊戲的戰鬥系統，光是「攻擊力怎麼算」就能拆出十幾條，而且條與條之間會互相影響，這種你就得一次給一小塊，做完驗收再給下一塊。

另外一個常被低估的類別是「改別人做好的東西」。網路上有現成的開源專案，你想改成自己要的樣子，這種情境下 AI 的表現通常比從零開始還好，因為它有一份可以參考的架構。想省時間的話，先找有沒有類似的東西可以改，比直接從空白開始快很多。

共同點是：規格由我自己定、驗收由我自己來、出錯的後果我自己承擔。這三個條件成立的時候，Vibe Coding 省下來的時間最多。

哪幾種東西我不會整包交給 AI

反過來，有幾種東西我不會整包交給它：

• 牽涉金流、身分驗證、個資儲存的部分。不是 AI 寫不出來，是寫錯的代價你賠不起。
• 要接進公司既有系統、規格由別人定的整合案。這種案子的難點在溝通與規格釐清，不在打字。
• 需要長期維護、會有別人接手的專案。你自己看不懂的程式碼，交接的時候就是災難。

判斷方式很單純：如果這個東西壞掉，是你自己重做一次就好，還是會有人受害？前者放心交給 AI，後者要自己看過每一行。

小工具變成團隊流程，歡迎洽詢

看 n8n 自動化服務

Vibe Coding 工具該怎麼挑

工具每個月都在換，記住分類比記住名字有用。目前市面上的東西可以分成三類，差別在「誰主導、AI 能碰到多少東西」。

對話型、編輯器型、代理型各適合誰

對話型就是 ChatGPT、Claude 這種網頁聊天框，你把需求打進去、它給你程式碼，再自己複製貼上，門檻最低但來回最花時間。編輯器型像 Cursor、GitHub Copilot，AI 住在你的程式編輯器裡，看得到整個專案，你指定它改哪裡。代理型像 Claude Code、Replit Agent，你只交代一個目標，它自己讀檔案、改檔案、跑指令、看錯誤訊息再修。

畫面長什麼樣子這件事，光靠文字描述最難講清楚。Claude Design 怎麼用那篇講的就是把設計稿交出去、再讓 Claude Code 接手實作的那一段。

我自己的用法是後兩類混著用：要精準改一個地方用編輯器型，要從零長出一個功能用代理型。第一類我現在幾乎不用了，因為複製貼上的來回本身就是最花時間的部分。

挑工具前該問自己哪三個問題

與其比功能表，不如問自己三個問題：

1. 你看不看得懂它寫的東西？看不懂就別用代理型，它一次改十個檔案你根本不知道發生什麼事。
2. 你的東西要不要上線給別人用？只有自己用，挑順手的就好；要給別人用，優先選能看到完整修改紀錄的。
3. 你願意每個月付多少錢？免費方案幾乎都有額度限制，用得順的話很快會撞到；先用免費的確認自己真的會持續用，再決定付費。

各家工具的定位、免費方案與價格帶我另外整理過一份完整比較，需要挑具體某一款的話直接看那篇：2026 AI 寫程式 10 款 AI Coding 工具比較。

Vibe Coding 教學該從哪裡開始

大部分人卡住是因為順序排錯。跑去先學 JavaScript 語法，學了三個月，結果 Vibe Coding 根本用不到那些；或是一開始就想做一個要收錢的產品，做到一半整個崩掉。

照下面這個順序走，每一階段都有可以驗收的成果。

第一階段先把需求練到講得清楚

這是唯一一個「不學會就什麼都做不出來」的能力。同樣要一個報表工具，講「幫我做一個報表」跟講「讀取這張試算表的 A 到 D 欄，把同一個客戶的訂單金額加總，結果寫到新的分頁，每週一早上八點自動跑一次」，得到的東西天差地遠。

練習方法很土但有效：把你要的東西寫成一段話，然後自己讀一次，問自己「如果我是一個完全不認識我的外包，我看得懂要做什麼嗎」。看不懂就補到看得懂。

一段能用的描述通常包含四個東西：資料從哪來、要做什麼處理、結果放到哪、什麼時候跑。四個裡面漏掉任何一個，AI 都會自己補一個它覺得合理的版本，然後你會拿到一個「能跑但不是你要的」成品。

還有一件很多人沒意識到的事：把限制講出來，跟把需求講出來一樣重要。「不要改到其他檔案」「不要換掉現在用的框架」「不要幫我加我沒要求的功能」這幾句話，能擋掉大半的意外。AI 預設是熱心的，你沒禁止的事它就有可能做。

描述的結構、該給什麼資訊、怎麼避免它自由發揮，這部分我單獨寫過：AI 提示詞怎麼寫？2026 該淘汰的舊指令與新寫法。

第二階段學會看懂 AI 動了什麼

你不需要會寫，但你需要看得懂它在幹嘛。至少要能分辨：這段是在讀資料還是在寫資料、這個錯誤訊息在說什麼、它剛剛動的是哪個檔案。

這階段最快的方式是每次它改完東西，你花三十秒看它的說明，遇到不懂的名詞就直接問它「這是什麼意思」。累積兩個星期，大部分常見的術語就都碰過了。

常見的開發行話我整理成一篇白話對照：工程師術語白話解釋：用 AI 寫程式會遇到的 20 個開發行話。

第三階段學會存檔，也學會退回去

這是我認為最被低估的一階段，也是最多人吃虧的地方。AI 改壞東西每天都在發生。你需要一個「回到十分鐘前那個能跑的版本」的方法。

沒有這個能力，你遲早會遇到一次改到全壞、又回不去的狀況，然後整個專案重做。學會之後，你反而敢讓 AI 大膽改，因為壞了隨時能退回去。

怎麼存、怎麼還原、分支要怎麼用：git 倉庫是什麼？AI 改壞專案時，commit、還原、分支怎麼救。

第四階段讓做出來的東西真的上線

做出來只在自己電腦上跑的東西，跟一個別人打開網址就能用的東西，中間隔著部署、網域、環境變數這幾關。很多教學停在前者就結束。

這階段的東西一次搞懂就終身受用，後面每個專案都是重複同一套流程：2026 AI 網站部署怎麼做？不會寫程式也能讓網站真正上線。

哪些東西你可以先不用學

省下來的時間比學什麼更重要。以下這些，等你真的撞到再學就好：

• 完整的程式語言語法。你需要的是看懂，不是默寫。
• 演算法與資料結構。除非你要處理大量資料的效能問題，一般小工具用不到。
• 框架的完整文件。AI 比你熟，你只要知道你的專案用了哪一套。

Vibe Coding 最常在哪三種狀況翻車

「翻車」這個詞在中文圈已經跟 Vibe Coding 綁在一起了，每個月都有人在搜。會有這麼多人搜，代表這件事發生得很頻繁。

三種最常見的失控怎麼發生

第一種是改 A 壞 B。你請它加一個功能，它為了讓新功能能跑，順手改了三個別的檔案，其中一個是你上禮拜才調好的。你當下不會發現，因為你只測了新功能。擋法是每次改完，把之前會用到的主要流程重跑一次，不要只測你剛加的東西。

第二種是它跟你說做好了，但根本沒做。模型的輸出是「最合理的回應」，而「我已經完成了，功能運作正常」在對話裡就是很合理的回應，不論它到底有沒有做。擋法只有一個：自己實際打開來點一次，不要用它的自我回報當驗收。

第三種是越修越亂。同一個問題修不好，你一直催，它一層一層疊補丁上去，到最後那段程式碼沒有人看得懂，包括它自己。擋法是設一個停損：同一個問題來回超過三次還沒解決，就退回上一個能跑的版本重新描述需求，不要繼續疊。

這三種不是個人體感。Stack Overflow 2025 開發者調查訪了 49,000 多人，被票選為最大挫折的第一名就是「AI 給的答案幾乎對、但不完全對」，66% 的人選；第二名是「debug AI 產生的程式碼更花時間」，45%。同一份調查裡，信任 AI 準確度的人只剩不到三成。

更完整的失敗類型與實測案例在這篇：AI 寫程式的缺點有哪些？8 個 AI 生成程式碼的致命問題。

資安問題為什麼要等出事才發現

前面三種你至少會發現，資安問題不會。程式跑得好好的，網站也開得起來，問題要等到出事那天才會浮上來。

AI 生成的程式碼常見幾個狀況：把金鑰直接寫在程式裡、資料庫的存取權限開得太寬、表單沒有做輸入檢查。這些在「只有我自己用」的階段完全不影響使用，一旦公開就是洞。

東西要給別人用之前，資安檢查是不能跳的一關。五種最常出現的漏洞跟怎麼一次找出來：Vibe Coding 的 5 種常見資安漏洞。

哪些動作一定要有人確認才能執行

Vibe Coding 不等於全自動。有幾個節點必須有人按下確認，不能交給 AI：

• 任何會對外送出的動作，寄信、發文、推播訊息。
• 任何會刪除或覆蓋既有資料的操作。
• 任何牽涉付款、退款、帳號權限的邏輯。

我自己做的自動化流程裡，只要涉及對外發送，一律留一道人工核准的閘門，AI 負責產出草稿，我看過才送。這一步會慢個幾分鐘，但省掉的是把錯誤內容發給整份名單的風險。

實作上的做法是把流程切成兩段：前半段 AI 產草稿並丟到一個我看得到的地方，後半段等我按確認才真的執行。這樣做的好處是即使 AI 那段完全失控，也停在我這一關，不會直接送出去。

最慢發作的一種翻車在三個月後

這種不會有錯誤訊息，也不會有人受害，但它會在三個月後咬你一口。你做了一個很好用的工具，用了半年，某天需要改一個小地方，打開來發現完全想不起來當初為什麼這樣寫。

這件事在產業層級也看得到。程式碼分析公司 GitClear 追蹤 2020 到 2024 年超過兩億行的程式碼變更，發現複製貼上的行數比例增加了將近五成、2024 年來到 12.3%，而「把舊程式碼搬動、整併」這種重構行為的比例明顯下滑。翻成白話就是：新的東西一直加，舊的東西沒人整理。

擋法不是把程式碼看懂，是把「為什麼」留下來。每次做完一個段落，用一兩句話寫下這段在做什麼、當初為什麼選這個做法，放在專案裡。這件事花不到五分鐘，但半年後回來的你會很感謝。

這也是為什麼「AI 幫我寫的我看不懂沒關係」這個說法只在一種情況成立：這個東西你用完就丟。只要它會活超過一個月，你就得留下足以讓自己回想起來的線索。

Vibe Coding 會取代工程師嗎

會被取代的是打字，不是判斷。

Vibe Coding 把「把想法變成程式碼」這段的成本壓到很低，但它沒有降低另外幾件事的難度：判斷要做什麼、判斷做出來的東西對不對、判斷什麼時候該收手。這三件事目前還是人的工作，而且需求變多了，因為產出的東西變多了。

比較實際的變化是：能把想法自己做出來的人變多了，而「只會照規格打字」的價值變低了。對不會寫程式的人來說這是機會，對已經在寫程式的人來說，價值會往架構設計跟判斷力那端移動。

有一個數字值得放在心上。研究機構 METR 在 2025 年做了一場隨機對照實驗，找的是熟悉自己專案的資深開源開發者。這些人事前預期 AI 會讓自己快 24%，做完之後認為自己快了 20%，但實際測出來是慢了 19%。AI 在陌生的新專案上確實很快，但在你已經很熟的老專案上，溝通與驗收的成本會把省下來的打字時間吃掉。這也呼應前面那句：真正值錢的是判斷，不是產出速度。

這個題目我另外寫過完整的看法：AI 會取代工程師嗎？會被取代的是打字，不是判斷。

常見問題 FAQ

Q1：Vibe Coding 是什麼？中文翻譯為什麼容易誤導？

Karpathy 提出這個詞時，指的是把決定權整個交給 AI，你只描述要什麼、看結果決定收不收，中間的程式碼不逐行看。中文常翻成「氛圍寫程式」，聽起來像隨興亂做，其實它跟一般 AI 輔助寫程式差在決定權，不是差在態度。AI 輔助是你主導、AI 補手；Vibe Coding 是 AI 主導、你驗收。門檻沒有消失，只是從語法移到了表達跟判斷。

Q2：Vibe Coding 跟一般的 AI 輔助寫程式差在哪？

差在誰主導產出。AI 輔助是你寫、AI 幫你補完後半段，你還是要會語法；Vibe Coding 是你描述、AI 產生整段甚至整個專案，你負責驗收。前者加速既有的開發流程，後者讓原本不會寫程式的人也能做出東西。

Q3：用 Vibe Coding 做出來的東西可以拿來做生意嗎？

可以，但有條件。牽涉金流、使用者個資、身分驗證的部分要自己看過或找人看過，不能整包交給 AI。內部工具、行銷用的頁面、自動化流程這類自己承擔後果的東西，直接上沒問題。分界點是「壞掉的時候有沒有別人會受害」。

Q4：AI 一直修不好同一個問題怎麼辦？

設停損。同一個問題來回超過三次還沒解決，就退回上一個能跑的版本，重新用不同的說法描述需求。繼續催它修只會讓補丁越疊越多，最後那段程式碼會變成沒人看得懂的狀態。這也是為什麼要先學會存檔跟還原。

Q5：免費工具夠用嗎，什麼時候該付費？

先用免費的把第一個東西做出來，確認自己真的會持續用再付費。免費方案的限制通常在額度，做小工具或原型不太會撞到；當你開始做需要跑很多輪、或是要處理整個專案的東西時，就會明顯感覺到不夠。那個時候再付錢，不會浪費。

團隊自動化流程委託建置

聊聊你的流程需求

參考資料

• METR，Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（2025 年 7 月，隨機對照實驗）
• Neil Perry、Megha Srivastava、Deepak Kumar、Dan Boneh（史丹佛大學），Do Users Write More Insecure Code with AI Assistants?（CCS '23）
• Stack Overflow，2025 Developer Survey：AI 章節（49,000 份以上回覆）
• GitClear，AI Developer Productivity & Code Quality Research（程式碼重複率與重構比例的長期追蹤）
• Google Cloud，What is vibe coding?（術語定義與工具指南）
• 維基百科，vibe coding（詞源與 Andrej Karpathy 的原始說法）