Vibe CodingVibe Coding

這個詞從哪裡來

Vibe Coding 是 OpenAI 共同創辦人 Andrej Karpathy 在 2025 年 2 月一則貼文裡提出的說法，用來描述一種新的寫程式方式：你用自然語言描述想要什麼，AI 生成程式碼並執行，你看結果、把錯誤訊息貼回去，一直重複這個過程——過程中「完全向 vibes 投降」，很少去讀、甚至不讀 AI 寫出來的程式碼。

這個詞很快從一句形容用法擴散成一整個現象的名稱，因為它精準描述了 AI Agent 類編程工具（例如 Claude Code、Cursor）普及之後，很多人實際在做的事。

定義

Vibe Coding 指的是一種開發模式：主要透過自然語言指令驅動 AI 產生、修改、執行程式碼，開發者判斷「對不對」的依據主要是程式跑起來的行為是否符合預期，而不是逐行閱讀並理解程式碼邏輯。

這和「AI 輔助寫程式」是程度上的差異，不是有沒有用 AI 的差異。幾乎所有工程師現在都會用 AI 生成部分程式碼，但傳統做法仍然會審查、理解每一段邏輯；Vibe Coding 把這一步大幅縮減，甚至跳過，把決策權更多交給「能不能跑」「感覺對不對」。

運作原理

典型的 Vibe Coding 迴圈是：

1. 描述意圖：用自然語言講你想要什麼功能或效果，不寫技術規格。
2. AI 生成並執行：AI Agent 產生程式碼，直接跑起來、甚至自己執行測試。
3. 看結果，不看程式碼：你看畫面、看行為，判斷符不符合預期，通常不會逐行審查產生的程式碼。
4. 回報問題，重複：不對的地方，把現象或錯誤訊息直接貼給 AI，讓它自己找出問題、修正，而不是自己動手除錯。

整個過程，人的角色比較像在「驗收」，而不是在「寫」。

為什麼它重要

在 AI Agent 能自己讀寫檔案、執行指令、看到錯誤自己修正之前，「靠感覺寫程式」不太可行——沒有人力氣夠好到不讀程式碼也能寫出能動的東西。Claude Code、Cursor 這類工具讓這件事第一次變得實際可行，也讓完全不懂程式的人第一次能做出真正能跑的軟體。

這件事的意義不只是「寫程式變快了」，而是把「做出一個能用的軟體」的門檻，從「會不會寫程式」大幅往下移，某種程度上移到「講不講得清楚需求、看不看得出結果對不對」。

實際例子

一位行銷人員週末做出一個內部小工具。 不懂任何程式語言，靠著描述「我要一個能把 Excel 資料轉成這種格式的網頁工具」，跟 AI 來回幾十次，做出一個同事在用的小工具——沒有讀過一行程式碼，也不需要。

工程師用 Vibe Coding 做原型驗證。 想快速驗證一個產品構想能不能成立，用 Vibe Coding 方式在幾小時內做出可以操作的原型給團隊看，驗證完之後如果方向對，再回頭用嚴謹的方式重寫成正式版本。

優點與挑戰

優點：

• 大幅降低「做出一個能用的東西」的門檻，不會寫程式也能動手做
• 原型驗證和探索性專案的速度快非常多
• 讓工程師從大量重複性的實作工作解放出來，把力氣放在判斷與設計上

挑戰／注意事項：

• 完全不讀程式碼，代表看不出安全性漏洞、效能問題、或是「暫時能動但埋了隱患」的寫法
• 長期維護困難——連自己都不知道程式碼裡發生了什麼，之後要改東西很難下手
• 幻覺在程式碼上的表現往往不是「跑不動」，而是「跑得動但邏輯有問題」，如果從不檢查，這類問題會一直藏著

最佳實踐

1. 一定要在 git 版控的環境下做，養成頻繁 commit 的習慣，出問題能隨時退回去
2. 依專案的重要性調整「不讀程式碼」的程度：個人小工具可以完全放手；牽涉真實使用者或資料的東西，至少該看過關鍵邏輯與資安相關的部分
3. 把驗收標準講清楚，不只是「能動」，包含異常情況該怎麼處理，AI 才知道要測到什麼程度
4. 定期讓 AI 或自己回頭檢查整體程式碼品質，避免長期累積技術債到無法維護的地步
5. 把 Vibe Coding 當成一種工具而不是唯一做法，原型驗證階段放手做，確定要長期經營的專案，找懂程式的人（或自己補足能力）認真檢視一次