Vibe coding

<image>

vibe coding（有譯氣氛編程、氛圍編程）是一種使用AI輔助的編程範式，程式設計師會用提示描述要處理的問題，提供給軟體開發專用的大型語言模型（LLM）。應用程式的原始碼是由大型語言模型產生，程式設計師的工作從原來的撰寫程式碼，改為指導AI產生程式碼，測試及優化程式碼。vibe coding的提倡者認為這甚至可以讓新手程式設計師在沒有以往軟體工程要求技能的情形下，可以產出軟體。批評者則指出，vibe coding所產生的軟體缺乏問責機制、難以維護，且更容易引入安全漏洞。此一詞語是由安德烈·卡帕斯在2025年2月提出，在3月時列在韋氏英語慣用法詞典的「slang & trending」名詞，並於2025年11月獲選為柯林斯英語詞典年度詞彙。

## 定義

<image>

電腦科學家安德烈·卡帕斯是OpenAI的共同創辦人，也曾任特斯拉的AI部門總監，他在2025年2月提出了「vibe coding」一詞。此概念是指依賴大型語言模型的程式撰寫方式，程式設計者用自然語言敘述，提供給大型語言模型，以此產生可運行的程式碼。卡帕斯敘述其開發方式是對話式的，用語音命令，由AI產生實際的程式碼：「這不太算是撰寫程式，我只是看一些東西，說一些話，執行它們，然後複製貼上而已，而且幾乎都可以運作。」

卡帕斯也承認目前vibe coding有其限制，AI工具不一定能理解出現的錯誤，也不一定可以修正，為了解決問題，他需要嘗試進行一些無關的變更，直到問題解決為止。他總結以當下的水平，此技術「用在throwaway weekend project（周末小作品）上還不錯」，也形容此技術「很有意思」。不過vibe coding的概念正成為一種趨勢，更加說明了卡帕斯從2023年起的主張「最新最熱門的程式語言是英文」，意味著大型語言模型的能力已可以讓人不需要為了讓電腦運作而學習特定的程式語言。

依照vibe coding的定義，其中的重要概念是，使用者完全接受AI產生的程式碼，不需要對其有完全的電腦科學理解。反之，AI研究者Simon Willison提到：「若你程式裡的每一行內容都是大型語言模型寫的，但你檢查和測試過並完全理解，在我看來這就不算是vibe coding，這只是把大型語言模型當成打字助理。」

## 使用情形和評論

《紐約時報》的記者Kevin Roose（他不是專業的程式設計者）用vibe coding創成數個小型的應用程式。他認為這些軟體是「針對個人的軟體」，是個人化、由AI產生的工具，可以處理特定的需求，例如一個名為LunchBox Buddy的應用程式，可以分析其冰箱裡的食物，建議可以選哪些食物打包當午餐。Roose也提出vibe coding讓非程式設計者可以開發可運作的軟體，但其成果多半是受限的，而且容易有錯誤。其中有一個AI生成的程式在電子商務平台上產生了假的評論。他認為vibe coding比較適合用在個人興趣的專案，不適合用在重要的專案，並注意到AI協助的程式設計可以讓個人開發一些以往需要一組工程師才能開發的軟體。AI專家Gary Marcus對此回應：生成LunchBox Buddy應用程式的演演算法，可能已在訓練時見過功能類似的程式碼，因此Roose的熱情是來自重製，而不是原創。

2025年2月的《商業內幕》提到，vibe coding已是矽谷的時髦術語。

Y Combinator在2025年3月指出，其2025年冬季的新創公司裡，其中25%的公司，AI生成程式的比例超過95%，開發方式轉向AI協助開發。

受到vibe coding的啟發，《經濟學人》於2025年6月提出「vibe valuation」一詞，用以形容創業投資公司在忽視年度經常性收入等傳統指標的情況下，對AI新創公司給出的高得離奇的估值。

2025年6月，AI學者吳恩達對「vibe coding」一詞提出異議，認為此名稱具有誤導性，讓人誤以為軟體工程師在使用AI工具開發應用程式時只是「隨感覺走」。

2025年7月，《華爾街日報》報導，vibe coding已被專業軟體工程師採用於商業用途。

2026年1月，據報導林納斯·托瓦茲使用Google Antigravity對其AudioNoise隨機數位音效生成器製作了視覺化工具。托瓦茲在專案的README文件中說明：「Python視覺化工具基本上是用vibe coding方式寫成的。」

## AI編程工具

vibe coding的普及離不開AI輔助編程工具的快速發展。這些工具將大型語言模型集成到集成開發環境（IDE）或獨立應用中，使開發者可以直接以自然語言描述需求並生成可運行的程式碼。

### 專用AI程式碼編輯器

- Cursor — 基於VS Code的AI程式碼編輯器，內置Composer功能，可透過自然語言對話生成和修改程式碼。卡帕斯在提出vibe coding概念時即使用Cursor Composer搭配Sonnet模型。
- Replit AI Agent — 雲端IDE平台，提供AI代理功能，可根據自然語言描述自動構建和部署應用程式。2025年Y Combinator報告顯示其冬季批次中有25%的初創公司代碼庫中AI生成比例超過95%，其中不少使用Replit等平台。
- Q138457287 — Anthropic推出的AI編碼代理工具，可在終端中直接與Claude對話，由AI自主完成編寫、測試和提交代碼等任務。
- Windsurf（Codeium）— AI驅動的IDE，支援多文件編輯和智能程式碼補全。
- Cline — VS Code的開源擴展，允許開發者直接在編輯器中與AI代理協作。

### AI編碼助手

- GitHub Copilot — 微軟旗下GitHub推出的AI編程助手，自2021年發布以來成為最廣泛使用的AI編碼工具之一。它可嵌入VS Code、JetBrains等主流IDE，根據上下文自動生成代碼建議。
- Amazon Q Developer（前身為CodeWhisperer）— 亞馬遜雲服務推出的AI編程助手，支持多語言代碼生成和安全漏洞掃描。
- Google Gemini Code Assist — Google推出的AI編碼助手，深度集成於Google Cloud和VS Code等環境。

### 通用AI聊天機器人

ChatGPT、Claude、Gemini等通用大型語言模型也常被用於vibe coding。開發者將需求以自然語言描述提供給這些模型，將生成的程式碼複製到開發環境中運行和調試。這種方式雖不如專用工具高效，但降低了入門門檻。

## 批評

### 代碼質量與安全問題

vibe coding引發了外界對程式理解與問責機制的疑慮。開發者可能在沒有完全理解其功能的情形下就採用AI生成的程式碼，因而導致未被偵測到的錯誤、缺陷或安全漏洞。此作法適合用在軟體原型或卡帕斯一開始提到的「throwaway weekend project」，但部分專家認為將其用於專業情境存在風險，因為在這些情境中，對程式碼的深入理解，對於軟體調試、維護及資訊安全至關重要。《Ars Technica》引用Simon Willison的說法：「用vibe coding進行量產代碼庫的開發，很明顯是有風險的。我們軟體工程師大部份的工作是和已有系統的演進有關，而底層程式碼的品質以及可理解性非常重要。」

2025年5月，瑞典vibe coding應用程式Lovable爆出安全漏洞：在1,645個由Lovable所建立的網路應用程式中，有170個存在允許任何人存取個人資料的安全缺陷。

2025年10月，資安公司Veracode發布研究，發現過去三年間大型語言模型在生成可運行代碼方面有顯著進步，但所生成代碼的安全性整體並未提升；更大規模的模型在生成安全代碼方面也不比小模型更好。OpenAI推理模型帶來了小幅安全改善，但其他推理模型則未見此改善，且改善幅度遠不及功能生成能力的提升。

2025年12月，資安研究員Etizaz Mohsin發現vibe coding平台Orchids的安全缺陷，並於2026年2月向BBC新聞記者展示了入侵過程。

2025年12月，CodeRabbit針對GitHub上470個開源拉取請求進行分析，發現由生成式AI共同撰寫的代碼，相較於人工撰寫的代碼，約多出1.7倍的「重大」問題，包含更高比例的邏輯錯誤（錯誤的依賴關係、有缺陷的控制流程）、配置錯誤（多出75%）與安全漏洞（多出2.74倍），以及較多的可讀性問題。

2025年7月，SaaStr創辦人記錄了其使用vibe coding的負面經歷：Replit的AI代理在被明確告知不可做任何變更的情況下，仍刪除了正式環境的資料庫。

2026年5月，rsync更新至3.4.3版後，多名使用者回報無法執行增量備份。使用者發現自3.4.1版起，已有數十個由「tridge and claude」共同提交的git提交紀錄，顯示Anthropic的Claude參與了開發過程。一名使用者因此在GitHub上發起標題為「Please Do Not Vibe Fuck Up This Software」的議題，引發廣泛討論，並蔓延至Reddit等社群媒體，掀起對AI生成代碼被納入關鍵開源基礎設施的爭議。

### 代碼可維護性與技術債務

vibe coding有可能使代碼長期難以維護，進而積累技術債務。

2025年初，GitClear發布了一項針對2020年至2024年間共2.11億行代碼變更的縱貫分析。研究發現：代碼重構的比例從2021年的佔變更行數25%下降至2024年的不足10%；代碼重複的量約增加四倍；複製貼上的代碼首次在二十年來超越了移動的代碼；代碼翻轉率（即剛合併的代碼不久後便被重寫）也幾乎翻倍。

2025年9月，《Fast Company》報導，「vibe coding宿醉」正在到來，資深軟體工程師紛紛反映在處理AI生成的代碼時陷入「開發地獄」。

資安公司SecurityScorecard執行長亞歷山大．亞姆波爾斯基（Aleksandr Yampolskiy）在LinkedIn上發文表示vibe coding催生出一種新工作「Vibe Coding清理專員」（Vibe Coding Cleanup Specialist），其職責在於，為AI生出的雜亂程式碼善後，解決各種AI生成程式存在的Bug或缺陷。

### 任務複雜性與開發者生產力

生成式AI能夠處理基本演演算法等簡單任務，但在面對涉及多個檔案、文件不足的程式庫或安全關鍵代碼等較為新穎、複雜的程式設計問題時，往往力不從心。

2025年7月，評估前沿模型的組織METR進行了一項隨機對照試驗，讓16名富有經驗的開源開發者在成熟的代碼庫中完成246項任務。結果顯示，使用2025年初的AI工具反而使完成時間增加了19%，而參與者在任務開始前預測AI將使完成時間縮短24%。

2026年5月，《華爾街日報》報導了OpenClaw AI代理系統核心Pi編程框架背後的工程師Mario Zechner與Armin Ronacher對即將到來的「vibe slop（vibe濫用）」危機的警告。他們指出，企業正以長期問題換取短期生產力提升，包括程式錯誤、服務中斷、安全漏洞與技術債務的累積。Zechner表示：「基礎設施正在崩潰，軟體現在也比以前更加漏洞百出。我們可以再這樣撐幾個月，甚至幾年，但最終這些問題都會追上我們。」

### 對開源軟體的影響

2026年1月，多所大學的學者共同發表論文《Vibe Coding Kills Open Source》，認為vibe coding對開源軟體生態系統產生了負面影響。作者指出，vibe coding使用量的增加降低了使用者與開源維護者的互動，對維護者造成隱性損失：「vibe coding透過降低使用及建構現有代碼的成本來提高生產力，但同時也削弱了許多維護者賴以獲益的使用者參與度。當開源軟體只能透過直接使用者互動來變現時，vibe coding的大量採用會降低進入門檻與共享意願，減少開源軟體的可用性與品質，即使生產力有所提升，整體福祉仍可能下降。」此外，作者也指出開源維護者傳統上還能從工作中獲得社群認可、聲譽與就業前景等無形收益，這些亦可能受到波及。從機制上來看，大型語言模型傾向於在訓練資料中出現頻率較高的大型既有程式庫，從而使軟體開發趨於同質化，使較新的開源工具更難以獲得關注；此外，語言模型也不會向維護者提交有用的錯誤報告。

2026年2月，GitHub承認低品質AI生成的貢獻大量湧入，已使開源維護者不堪負荷，並將此現象比喻為開源界的永久九月。GitHub列舉了已受影響的案例，包括cURL專案因AI生成的安全報告大量增加而終止了漏洞懸賞計畫，以及部分專案（如Ghostty）轉為僅接受受邀貢獻。GitHub平台因此引入了新的維護者管理功能，包括限制只有協作者才能建立拉取請求、作為人群管控手段的臨時限制倉庫活動，以及橫幅、置頂議題留言等溝通工具。

## 外部連結

- AI 寫程式新流派的 Vibe Coding 是什麼？開發者需知的操作技巧、技能轉變
- 不寫程式碼也能開發產品！Vibe Coding是什麼？3款好用AI工具＋6步驟教學一次看