多數人以為，能不能寫出一個能跑的 App，關鍵在懂不懂程式語言。這個假設在 2025 年開始鬆動——有人示範一種做法，完全不看程式碼，只靠一句接一句的自然語言描述，就讓電腦把程式碼寫出來、跑起來，變成一個真的能用的 App。這個做法很快有了一個名字，叫做 vibe coding。
vibe coding 是什麼，其實不難懂。你用日常語言把想要的功能講給 AI 聽，AI 直接生成並執行程式碼，你不必逐行檢查它寫了什麼，就是這套做法的核心。這聽起來像一句流行的網路用語，但它已經被字典正式收錄成詞條，代表它不是說著玩的行話，而是已經被認證進入主流語彙的技術趨勢字。
先從這個詞怎麼冒出來、又是怎麼從一則貼文變成正式詞彙講起，再一一拆開它跟傳統寫程式、AI 輔助寫程式之間真正的差別在哪裡。
Vibe Coding 是什麼？
vibe coding 最早不是學術定義，而是一則社群貼文。2025 年 2 月，AI 研究者 Andrej Karpathy（特斯拉前 AI 總監、OpenAI 創始團隊成員之一）在貼文裡寫下：「有一種新的寫程式方式，我稱之為 vibe coding，你完全臣服於這股氛圍，擁抱指數成長，忘記程式碼本身的存在。」
他描述自己的實際做法，是用語音輸入工具講出需求，搭配 Cursor 這款編輯器裡的 Composer 功能與 Claude 的 Sonnet 模型生成程式碼，看到能接受的結果就直接全部採用，連程式碼的差異都不再細看。有些地方 AI 修不好，他就乾脆繞過去，還說這種做法對做完即丟的週末專案還算過得去。
這段貼文原本只是隨手分享，卻很快擴散開來，從工程師社群裡的一句戲稱，變成媒體、開發工具、招聘市場都在用的正式說法。真正讓它從社群戲稱變成公認用語的，是兩個具名字典的動作。
2025 年 3 月，Merriam-Webster（韋氏詞典）把 vibe coding 列入「俚語與新造詞」觀察名單，定義為一種新近出現的說法，指單純告訴 AI 程式你想要什麼，就能寫出程式碼、做出網頁或 App 的做法。到了 2025 年 11 月，柯林斯詞典（Collins Dictionary）更進一步，把 vibe coding 選為當年度代表詞彙，官方定義它是一種新興的軟體開發方式，利用 AI 把自然語言轉換成電腦程式碼。一個詞能在不到一年內被兩個字典先後收錄，說明它已經不是小圈子的行話，而是被主流語言認可、讀者真的會搜尋、也真的該搞懂的新趨勢用語。
Vibe Coding 與傳統寫程式的三個關鍵差異
不少人會把打開 ChatGPT 請它生成一段程式碼，也叫成 vibe coding，其實這兩件事分屬同一條光譜上完全不同的位置。知名開發者 Simon Willison（長期關注 AI 輔助程式設計、也是 Django 框架共同創辦人之一）在 2025 年 3 月的一篇文章裡特別點出這個誤用。他發現很多人把所有 AI 輔助寫程式的做法都叫 vibe coding，這樣的說法反而稀釋了這個詞原本的意思，也讓外界對 AI 輔助程式設計產生錯誤印象。他認為關鍵的判準從來不是有沒有用 AI，而是使用者有沒有審查、測試、真正看懂 AI 生成出來的東西。以下三種模式，剛好對應這條光譜的三個端點。
傳統寫程式：先學語法，一行一行寫
在 AI 介入之前，寫程式的起點是先學會一套程式語言的語法與邏輯，變數怎麼宣告、迴圈怎麼寫、資料怎麼串接，每一行程式碼都是工程師自己敲出來，也由自己逐行確認對不對。需求要轉換成能跑的程式，中間每一步都是人工完成、人工審查，出錯了也得自己回頭除錯。這是最傳統、也最耗學習時間的模式，拿來當對照組，能更清楚看出後面兩種模式差在哪裡。
AI 輔助寫程式：AI 幫忙寫，工程師仍逐行審查
目前多數專業工程師實際在用的，其實是中間這一種模式。用 GitHub Copilot 這類工具讓 AI 先寫出一段程式碼草稿，工程師再逐行看懂、測試、修改，確認沒問題才真正採用。責任始終在工程師身上，AI 只是加快了寫的速度，沒有取代懂的責任。
Willison 給自己訂的原則說得很直接：「任何一行程式碼，如果沒辦法向別人解釋清楚它在做什麼，我就不會把它提交進版本庫。」這也是判斷一件事算不算 vibe coding 最實用的一條分界線。
Vibe Coding：你負責描述，AI 負責生成與除錯
到了 vibe coding，角色徹底換了一邊。你不再是寫程式的人，而是描述需求、看結果、再用下一句話繼續調整的人。AI 生成的程式碼如果跑出錯誤，修正的方式也不是自己打開程式碼去除錯，而是把錯誤訊息或不滿意的地方，用自然語言講給 AI 聽，讓 AI 自己去改。
Karpathy 在他那則定義貼文裡形容得很直接，他不再讀程式碼的差異，遇到 AI 修不好的地方，乾脆直接繞過去。這正是非工程師也能寫出一個 App 這件事背後真正的機制，當你不再需要看懂程式碼，懂不懂寫程式就不再是能不能把想法做出來的唯一門檻。這股改變，如今擴散的規模比想像中大。
Vibe Coding 已經擴散到多大規模？
這股改變的規模，已經不只是個人專案的玩票。要看懂它有多普遍，得先分清楚兩種完全不同的數字，一種在量 AI 生成的程式碼佔了整個專案多少比例，另一種在量有多少工程師正在使用 AI 寫程式的工具，兩者問的不是同一件事。
先看第一種。Y Combinator 合夥人 Jared Friedman 在 2025 年 3 月公開受訪時提到，他們現役的 W25 新創批次裡，約有四分之一的新創，程式碼庫有高達 95% 是由 AI 生成，這個比例不含單純匯入函式庫的部分，是實際比對人工撰寫與 AI 生成後得出的結果。對這群新創來說，vibe coding 已經不是輔助，而是主要的寫程式方式。
第二種數字看的是採用率，不是生成比例。Gartner 在 2024 年 4 月的預測指出，到 2028 年會有 75% 的企業軟體工程師使用 AI 程式碼助手，而在 2023 年初，這個比例還不到一成；短短半年多後的 2023 年第三季，已經有 63% 的組織開始試驗或導入這類工具。這份預測根據的是 598 位大型企業軟體工程主管的調查，由 Gartner 分析師 Philip Walsh 具名發布。這裡讀的是有多少工程師在使用 AI 工具的比例，跟前面 AI 生成了多少程式碼是兩回事，不能混著看。
現役開發者的日常使用率，印證了這條採用曲線已經不是預測，而是現在進行式。JetBrains 在 2025 年 10 月發布的《State of Developer Ecosystem 2025》報告，調查了 194 個國家共 24,534 名開發者，結果 85% 的人已經常態使用 AI 工具寫程式，62% 依賴至少一項 AI 編程助手。新創的極端案例、企業的成長曲線、開發者整體的日常習慣，三個角度指向同一個結論：這已經是主流採用中的做法，不是還在實驗階段的玩票。曲線這麼陡，這中間 AI 實際做了什麼事，才讓一句話真的變成一個能跑的 App？
從一句話到一個能跑的 App，AI 在背後做了三件事
拆開來看，這其實是一個不斷循環的迴圈，大概分成三個階段。
第一步是理解需求。你用日常語言描述想要的功能，AI 要先把這段話翻譯成程式邏輯，這句話要做成什麼畫面、需要存取哪些資料、按下按鈕之後該發生什麼事。輸入的方式不只是打字，Karpathy 自己描述的做法就是用語音輸入工具講出需求，再讓 AI 接手。
第二步是生成與執行。AI 直接把整段程式碼寫出來，而且不只是寫，還會直接執行、跑起來，讓你馬上看到結果，一個網頁畫面、一個能點的按鈕，或是一段錯誤訊息。
第三步是回饋與修正。畫面跑出來如果不對，你不需要打開程式碼去找哪一行錯了，只要用下一句話告訴 AI「顏色太暗」、「按下去沒反應」，AI 就會照這句話回頭修改，再重新執行一次給你看。這個迴圈可以一直重複，直到結果符合你要的樣子。
現在能承接這套迴圈的工具不少，像 Cursor、GitHub Copilot、Replit、Lovable、v0、Claude Code 這類編輯器或平台，做的都是同一件事，把自然語言輸入、程式碼生成、執行回饋這三步串起來，差別在介面設計與適合的場景，這裡不逐一比較誰更好用。真正該問的問題，反而是這件事能做到什麼程度，不寫程式，真的能做出一個能用的 App 嗎？
不寫程式，真的能做出一個能用的 App 嗎？
Karpathy 心目中適合 vibe coding 的，本來就是做完即丟的週末專案，像個人專案、原型測試、內部小工具，或是拿來驗證一個點子能不能成立。這類東西就算壞了，頂多重新來過，不會有人因此受害。前面提到 YC 新創批次裡程式碼幾乎全由 AI 生成的案例，多半也落在這個先做出來驗證、之後再說的階段。
但如果你想的是一個要正式上線、要處理金流或個人資料、要對外服務真實使用者的產品，情況就不一樣了。有一項研究結果，直接打破了一個常見的假設，那就是用了 AI 工具，做事一定更快。
AI 安全研究機構 METR 在 2025 年做過一項實測，找來 16 位平均有 5 年經驗的開源開發者，讓他們用當時最新的 AI 工具完成 246 項真實任務。這些開發者原本預期 AI 會讓他們快上 24%，結果實測下來反而慢了 19%。
連對程式碼本來就熟悉、懂得怎麼審查的資深工程師，套用 AI 工具都不保證更快更好，對完全不懂程式碼、也看不出 AI 哪裡寫錯的人來說，這中間的落差只會更明顯。做出一個「看起來能動」的 App，跟做出一個「正式上線也扛得住」的 App，兩者之間還有一段不容易跨過去的距離。
Vibe Coding 有哪些容易被忽略的風險？
這些風險之所以容易被忽略，原因很直接，當你不審查、也看不懂 AI 生成的程式碼，問題不會在當下被發現，而是留到之後才會顯現出來，甚至造成實際損害。目前已經有幾份具名研究，把這件事量化成具體數字。
第一類是資安漏洞。資安公司 Veracode 在《2025 GenAI Code Security Report》裡測試了超過 100 個大型語言模型生成的程式碼，結果 45% 的樣本存在安全風險，涵蓋 OWASP 列出的前十大常見漏洞類型。
雲端安全聯盟（Cloud Security Alliance）在 2026 年 4 月的一份研究筆記裡，進一步彙整了這個趨勢的走向。喬治亞理工學院的 Vibe Security Radar 計畫，追蹤到跟 AI 編碼工具有關、已被公開歸類的資安漏洞，從 2026 年 1 月的 6 件、2 月的 15 件，增加到 3 月的 35 件，短短兩個月成長將近六倍。
另一份 2025 年由德州大學聖安東尼奧分校、奧克拉荷馬大學與維吉尼亞理工大學研究團隊發表的學術研究，分析了超過 57 萬筆 AI 生成的程式碼樣本，發現約 20% 引用了根本不存在的軟體套件，而且這些幻覺出來的套件名稱有一定的重現性。同樣的提示詞重複問十次，43% 的幻覺套件名稱會每一次都重複出現。這代表攻擊者能預先把幻覺套件名稱搶先註冊成真的套件、植入竊取帳密的程式碼，等開發者的 AI 工具把它悄悄裝進系統。資安研究員 Bar Lanyado 早在 2023 年就示範過這條路徑真的行得通：他把 AI 幻覺出來的套件名稱「huggingface-cli」註冊成一個內容空白、不含任何程式碼的佔位套件，三個月內就被下載超過三萬次。這個示範版本沒有植入任何惡意程式碼，卻證明了只要真的有人惡意搶注這類幻覺套件名稱，可能波及的下載規模有多大。
第二類是程式碼品質的長期趨勢。程式碼分析機構 GitClear 研究了 2020 到 2024 年間、超過 2.11 億行的程式碼變更，發現重構，也就是把程式碼整理得更精簡、更好維護，占變更程式碼的比例，從 2021 年約 25% 一路降到 2024 年不到 10%，重複程式碼的比例反而成長了大約四倍。
這代表 AI 確實讓寫出能動的程式碼變快了，但沒人回頭整理、精簡的部分也在同步累積。這正是「看起來能動」不等於「安全、可維護」的原因，程式能跑，不代表它背後的邏輯乾淨、沒有漏洞，也不代表半年後還有人看得懂、改得動。
風險有多大，終究要看你拿它做什麼。個人專案改壞了重寫一次就好，但一旦是要接觸金流、個資、對外服務真實使用者的產品，這些看不見的漏洞跟技術債，才是真正該提前正視的部分。
vibe coding 真正改變的，是能不能把一個想法做出來這件事的門檻。過去這扇門的鑰匙是懂不懂程式語言，現在多了一把新鑰匙，叫做懂不懂得怎麼跟 AI 描述需求。對從來沒寫過程式的人來說，這是真實存在的機會，不是行銷話術。
但同一年，字典把這個詞收進正式語彙的時候，資安圈也才剛開始追蹤它帶來的漏洞怎麼一路往上爬。這兩件事同時發生，說明這股風潮還在快速成形，還沒有一套穩定的規則可以遵循。與其問「這會不會取代工程師」，不如先問自己「手上這個想法，適合拿去做原型驗證，還是真的要扛得住上線後的責任」。想清楚這一點，才知道 vibe coding 對你來說，現在能派上什麼用場。