Vibe Coding 是什麼？什麼情況適合，什麼情況千萬不要

最近很常聽到 Vibe Coding 這個詞：不會寫程式的人，用 AI 做出了自己的 App；工程師用 AI，一個下午做完以前要一週的功能。

但也常聽到另一種聲音：AI 寫的程式漏洞百出、上線就出事、最後還是要工程師收拾。

兩種說法都是真的。關鍵在於：你用它來做什麼。

Vibe Coding 是什麼？

這個詞是 AI 研究者 Andrej Karpathy 在 2025 年 2 月提出的。他描述的是一種新的寫程式方式：完全順著感覺走，用講的告訴 AI 要什麼，接受它給的結果，甚至忘記程式碼本身的存在。

出錯了就把錯誤訊息貼回去給 AI，畫面不對就描述哪裡不對，整個過程幾乎不看程式碼。

後來這個詞的意思被用得越來越廣，泛指「主要靠 AI 寫程式」的開發方式。所以討論時最好先分清楚程度：

	純 Vibe Coding	AI 輔助開發	傳統開發
誰寫程式	AI	AI 寫，人審查	人
人看不看程式碼	幾乎不看	每段改動都看	自己寫
速度	最快	快	慢
品質掌控	低	高	高
需要的能力	會描述需求	會描述需求＋看得懂程式	會寫程式

我自己大部分時間是在「AI 輔助開發」這一格：AI 寫，但每一段改動我都會看過。

我的做法：把「Vibe」定義得更完整

不過我做的不只是「看過」而已。我覺得 Vibe Coding 能不能用得好，關鍵在於交代給 AI 的東西有多完整。我通常會在動手前，先把這幾件事講清楚：

我會交代的事	例子
要改的位置	直接給檔案路徑、PHP 檔名，甚至是哪一個 function
可以參考的地方	「這個功能的做法，可以參考某個路徑底下的某個功能」
做法、條件與檢查點	要怎麼實作、什麼條件下才執行、做完要檢查哪些結果
我的寫法習慣	例如時間一律用專案裡的特定方式處理，不要自己另外寫一套
資料的意義	哪幾個欄位代表什麼意思，直接給範例

最後一項特別重要。以會員系統為例，一個系統裡的「點數」可能就有五、六種：消費累積的點數、活動贈送的點數、即將到期的點數、已凍結的點數……如果只跟 AI 說「取得會員點數」，它只能用猜的，很可能抓錯欄位，而且看起來還能正常執行，最難發現。

所以我會直接告訴它，例如：

在 app/Services/MemberPointService.php 的 getAvailablePoints() 裡，
新增「排除 7 天內即將到期點數」的計算。

參考：app/Services/CouponService.php 的 getValidCoupons()，
到期判斷的寫法照那邊的方式處理。

資料說明（members_points 資料表）：
- point_type = 1：消費累積
- point_type = 2：活動贈送
- frozen_points：已凍結，不能使用
- expired_at：到期時間
可用點數 = 未過期、未凍結的點數總和

規則：
- 時間一律使用專案共用的時間處理方式，不要直接用 date()
- 不要修改其他 function 的回傳格式

檢查點：
- 寫完後列出你改了哪些檔案、哪幾行
- 補上單元測試，涵蓋「剛好第 7 天到期」的邊界情況

這樣做有兩個好處：

AI 寫出來的東西更準：它不用猜欄位、猜寫法，也比較不會改到不該改的地方。
Token 也更省：AI 不用為了找「點數在哪」翻遍整個專案，直接去指定的檔案改就好。這和〈Claude Code 省 Token 技巧〉講的是同一件事。

換句話說，Vibe Coding 不代表交代可以很隨便。你把需求定義得越完整，「憑感覺」的部分就越少，AI 的產出就越接近你自己寫的。寫法上的細節，可以參考〈Prompt 寫法實戰〉。

適合 Vibe Coding 的情境

情境	為什麼適合
驗證想法的原型	重點是快速確認「這個點子行不行」，程式碼之後本來就可能重寫
個人小工具、一次性腳本	只有自己用，壞了也只影響自己，例如整理檔案、轉換格式
內部展示用的 Demo	讓老闆或客戶看到概念，不是正式上線
學習新技術	先讓 AI 做出能動的版本，再回頭看懂它怎麼寫
小遊戲、互動頁面	規模小、沒有敏感資料，出錯的影響很有限

像這個網站遊戲廳裡的小遊戲，就是在 AI 協助下完成的，很適合這種開發方式：規模小、沒有個資、玩壞了重新整理就好。

千萬不要純 Vibe Coding 的情境

情境	為什麼危險
金流、付款	一個邏輯錯誤就可能多扣錢、少收錢
帳號、登入、權限	權限檢查漏一個地方，別人就能看到不該看的資料
個資與客戶資料	資料外洩的後果和法律責任都很嚴重
公司長期維護的核心系統	沒人看得懂的程式，之後誰也不敢改
多人協作的大型專案	每個人各自 vibe，風格和架構會一團亂

不是說這些系統不能用 AI 開發，而是不能「不看程式碼」地開發。

Vibe Coding 常見的五個風險

安全漏洞：AI 很常寫出「能動」但不安全的程式，例如把 API 金鑰直接寫在前端、沒有檢查使用者權限、SQL 查詢沒有防注入。
看不懂就修不了：程式一出問題，AI 修不好的時候，你也不知道從何下手。專案越大，這個問題越嚴重。
越改越亂：一直請 AI「再加一個功能」「再修一下」，程式碼會疊床架屋，最後連 AI 也改不動。
亂裝套件：AI 可能引入不必要、過時，甚至不存在的套件。
隱藏成本：專案變大之後，AI 每次都要讀更多程式碼，Token 用量和等待時間都會上升。

安全使用 Vibe Coding 的守則

如果你想享受 Vibe Coding 的速度，又不想踩雷，可以照這幾點做：

用 Git，小步提交：每完成一個能動的小功能就 commit 一次，改壞了隨時能退回。
先規劃再動手：大功能先讓 AI 提出做法，確認方向再開始寫。
讓 AI 寫測試：請它順便寫測試，之後每次修改都跑一次，確認沒把舊功能改壞。
機密資訊放環境變數：API 金鑰、密碼絕對不要寫在程式碼裡。
把規則寫進專案說明檔：例如在 CLAUDE.md 寫下「所有資料庫查詢都要用參數化查詢」「所有 API 都要檢查登入狀態」，讓 AI 每次都遵守。做法可以參考〈Claude Code 省 Token 技巧〉。
上線前找懂的人審查：原型可以 vibe，要給客戶用之前，一定要有工程師看過。

一個實用的流程是：

Vibe Coding 做出原型
  → 確認點子可行
  → 工程師審查（或重寫）關鍵部分
  → 補上測試、資安檢查
  → 正式上線

我的看法：「做出來」變便宜了，「做對、做穩」變值錢了

很多工程師擔心 Vibe Coding 會讓自己失業。我的看法剛好相反。

Vibe Coding 讓「做出一個能動的東西」的成本大幅下降，以前要一週，現在一個下午。但「做對、做穩、做安全」這件事，並沒有因此變簡單，反而因為能動的程式變多了，更需要有人把關。

所以工程師的價值正在移動：

以前比較值錢	現在越來越值錢
寫程式的速度	拆解需求、設計架構
記得語法和 API	判斷 AI 寫的程式對不對
自己從頭寫完	審查、測試、資安把關
熟悉某個框架	理解業務、知道什麼值得做

對不會寫程式的人來說，Vibe Coding 是很棒的驗證想法的工具；對工程師來說，它則是讓你把時間花在更有價值的地方。

真正該擔心的，不是 AI 會寫程式，而是只會寫程式。