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 寫程式」全部混成一件事，實際上有三個層級，決定權的位置完全不同：

做法	誰在產出程式碼	你要會什麼	你負責的事	適合的產出
傳統寫程式	你自己逐行寫	語法、框架、除錯	從設計到實作全包	任何規模
AI 輔助（Copilot 型）	你寫，AI 補完後半段	語法要看得懂	接受或拒絕每一段補完	加速既有開發
Vibe Coding	AI 產生整段甚至整個專案	把需求講清楚、看得懂結果	describe、驗收、判斷何時收手	原型、內部工具、小型產品

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

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，後者要自己看過每一行。

Vibe Coding 工具該怎麼挑

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

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

類型	代表工具	誰主導	AI 看得到什麼	適合誰	弱點
對話型	ChatGPT、Claude	你	只有你貼過去的內容	還沒裝開發環境、想先試水溫	改到第三個檔案就開始亂
編輯器型	Cursor、GitHub Copilot	你	整個專案，但你指定範圍	看得懂程式碼、要精準控制	要自己知道該改哪裡
代理型	Claude Code、Replit Agent	AI	整個專案，自己讀自己改	要從零長出一個完整功能	動的範圍最大，不看就是全交出去

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

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

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

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

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

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

Vibe Coding 教學該從哪裡開始

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

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

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

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

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

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

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

描述的結構、該給什麼資訊、怎麼避免它自由發揮，這部分我單獨寫過：AI 提示詞怎麼寫？5 個重點讓答案更準確。

第二階段學會看懂 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 嗎？

可以，而且建議直接開始。你需要的第一個能力是把需求講清楚，那是可以邊做邊練的。不要先跑去上三個月的語法課，那些內容你在 Vibe Coding 的過程中用不到大半。真正該補的是看懂結果跟存檔還原這兩項，遇到再補。

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 的原始說法）