Vibe Coding 是什麼？2026 中文完整教學：工具、範例與課程怎麼選

Vibe Coding 是用自然語言描述需求、讓 AI 產生程式碼的開發方式，你負責判斷，AI 負責打字。要學它照四個階段走：第一階段把需求講到 AI 聽得懂，第二階段看懂 AI 改了哪裡，第三階段學會存檔跟退回上一版，第四階段把做出來的東西上線。四個階段裡沒有一步要先學程式語法。

這篇文章會拆 Vibe Coding 把一句話變成程式的運作方式、一般人做得出什麼、工具怎麼挑，以及四個階段各自要練什麼。

Vibe Coding 是什麼

Vibe Coding 是用自然語言描述需求、讓 AI 產生程式碼的開發方式，你負責判斷，AI 負責打字。中文圈常把它翻成「氛圍編程」或「感覺寫程式」，這個翻譯會讓人以為跟著感覺走就好。實際上你的工作變成指揮跟驗收，門檻變成能不能把需求講清楚，程式本身並沒有變簡單。

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

你講不清楚要什麼，AI 就給你一個它猜的版本；你看不出來結果哪裡怪，你就會把一個有問題的東西當成完成品。

Vibe Coding 是誰提出的

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

他講這段話有個前提：他描述的是「週末做小專案」的情境，做的是自己玩的東西，沒有要收錢，也沒有客戶資料。他自己在同一段話裡提到，做這種東西的時候他甚至不看 diff，直接按接受。

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

英文原文的定義也把「隨便」寫了進去。Merriam-Webster 2026 年 9 月 15 日把 vibe coding 正式收進詞典，跟 AGI、compute 同一批，給的定義是「以有些隨便的方式、在 AI 協助下寫程式」，careless 這個字就寫在定義裡。詞典記錄的是大家怎麼用這個詞；實際要做出能用的東西，打字可以交給 AI 隨便打，驗收還是要仔細做。

AI 輔助跟 Vibe Coding 差在決定權

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

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

Vibe Coding 的流程是什麼

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 主要幫忙寫設定和資料轉換的邏輯，整套流程還是用 n8n 拉的。
• 一款能玩的遊戲：用 Godot 搭 Claude Code 做的戰棋卡牌手遊，這是四類裡面最吃「你講不講得清楚」的，因為遊戲規則的細節極多，描述漏一條，出來的行為就整個歪掉。

這四類的難度跟排列順序無關，看的是「你的需求有多少條規則」。做一個網站的頁面，規則大概十幾條，AI 一次就能抓到大部分；做一款遊戲的戰鬥系統，光是「攻擊力怎麼算」就能拆出十幾條，而且條與條之間會互相影響，這種你就得一次給一小塊，做完驗收再給下一塊。遊戲那類我做的是《夜影傭兵團》這款戰棋卡牌，可以直接線上試玩。

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

這四類都是我自己定規格、自己驗收，出錯也是我自己承擔，這種時候 Vibe Coding 省下來的時間最多。

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

下面幾種我不會整包交給 AI：

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

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

這四類作品的實際成品都在作品集，每一個都有做法說明。

看實際作品案例

Vibe Coding 工具該怎麼挑

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

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

三類的差別在你要做多少事：對話型要自己複製貼上程式碼，編輯器型要你指定改哪裡，代理型只要交代目標，讀檔、改檔、跑指令、看錯誤都由 AI 自己來。

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

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

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

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

Vibe Coding 該從哪裡開始學習

大部分人卡住是因為順序排錯。最常見的有兩種：一種是先花三個月把 JavaScript 語法學完才敢動手，但其實懂大概的概念就夠了，底層的程式碼現在 AI 都能寫得很好；另一種是第一個專案就做「會員登入＋線上付款」。這兩塊牽涉帳號安全和金流，出錯的代價高，AI 生出來的程式碼又多到看不懂，常常修好一個地方、另一個地方又壞掉，最後只能放棄。

照下面四個階段走，每個階段做完，都有一件你可以自己檢查有沒有過關的事：

• 第一階段：寫出一段描述，AI 照著做出來的就是你要的東西，不用來回改好幾輪
• 第二階段：AI 每次改完，你說得出它動了哪個檔案、做了什麼
• 第三階段：改壞的時候，你能退回上一個能跑的版本
• 第四階段：別人用自己的手機打開網址，就能用你做的東西

下面我會用自己用 Vibe Coding 建這個官網時實際發生的事當例子。

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

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

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

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

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

這個官網開工第五天，我把寫作原則（每頁一個主題、標題要包含關鍵字）寫進 CLAUDE.md 這個專案說明檔。AI 每次開工都會先讀這個檔，同樣的要求我就不用每次重講。

📖 延伸閱讀：AI 提示詞怎麼寫？2026 該淘汰的舊指令與新寫法。

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

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

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

📖 延伸閱讀：工程師術語白話解釋：用 AI 寫程式會遇到的 20 個開發行話。

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

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

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

我曾讓 AI 把服務頁的開頭區塊整個重做，改了 450 多行，後來決定用回舊版，一個指令就整段換回去。

📖 延伸閱讀：git 倉庫是什麼？AI 改壞專案時，commit、還原、分支怎麼救。

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

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

官網第一次部署到 Zeabur，在自己電腦上跑得好好的，上線就連續失敗兩次：一次是建置環境的設定不對，一次是啟動指令沒讀主機給的連接埠（PORT）。這兩個問題在本機都測不出來，所以上線是一個獨立的階段，要另外學。

📖 延伸閱讀：Vibe Coding 的 5 種常見資安漏洞：用 Claude Code 一次健檢全找出來

📖 延伸閱讀：2026 AI 網站部署怎麼做？不會寫程式也能讓網站真正上線。

Vibe Coding 課程該不該花錢上

免費資源已經夠把第一個東西做出來：Google AI Studio 的 vibe code 入口、YouTube 上 STEAM 教育學習網的二十幾堂入門課、各家工具的官方文件，都不用錢。卡住的多半是前面講的第一階段，需求講不清楚，這件事看影片學不會，要有人看你寫的描述、指出漏了哪一條。

付費課程值不值得，看它交付的是「做出一個能上線的東西」還是「把工具都介紹一遍」，後者免費影片就有。我自己帶過 12 週的訓練營，也接一對一教學，通常是手上已經有一個想做的東西、卡在某個階段的人來，一次把那個東西推過門檻，比從頭上一整套課省時間。

哪些東西你可以先不用學

下面這些，等你真的遇到再學就好：

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

Vibe Coding 會取代工程師嗎

AI 能取代的是打字那部分，判斷還是要人來做。

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

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

研究機構 METR 在 2025 年做了一場隨機對照實驗，找的是熟悉自己專案的資深開源開發者。這些人事前預期 AI 會讓自己快 24%，做完之後認為自己快了 20%，但實際測出來是慢了 19%。AI 在陌生的新專案上確實很快，但在你已經很熟的老專案上，溝通與驗收的成本會把省下來的打字時間吃掉。

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

常見問題 FAQ

Q1：Vibe Coding 教學該從哪一步開始？要先學程式嗎？

不用先學程式，先練把需求講清楚。這篇排的四階段順序是：第一階段把需求講到 AI 聽得懂，第二階段看懂 AI 改了哪裡，第三階段學會存檔跟退回上一版，第四階段把做出來的東西真的上線。門檻沒有消失，只是從語法移到了表達跟判斷。定義跟中文翻譯的問題，看第一節。

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

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

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

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

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

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

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

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

每週一封，AI 工具的新聞精選跟短評，不用自己追。

訂閱每週 AI 精選

參考資料

• 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?（術語定義與工具指南）
• Merriam-Webster，1,400 New Words and Definitions Added to Merriam-Webster（2026 年 9 月 15 日新聞稿，vibe coding 正式收錄）
• 維基百科，vibe coding（詞源與 Andrej Karpathy 的原始說法）