Vibe Coding 是什麼？
完整解析 + 5 種人該怎麼用
Vibe Coding 是 2025 年 Andrej Karpathy 提出的新詞、半年內紅遍開發者圈。這篇拆給你看 ─ 它真的是什麼、為什麼紅、優點、致命缺點、5 種人各自該怎麼用。用對是工具、用錯是廢墟。
※ 「Vibe Coding」一詞由 Andrej Karpathy 於 2025 年提出。本文為觀念整理與實用建議、非官方定義權威。
它不是什麼
先把幾個誤解打掉：
- 不是「用 AI 寫 code」 ─ 那是廣義概念、早就存在
- 不是「Cursor 的功能」 ─ Cursor 只是工具、Vibe Coding 是使用方式
- 不是「不寫 code 就有產品」 ─ 它是一種編程姿態、不是奇蹟
它真正是什麼
Vibe Coding 是一種編程姿態：
「把寫 code 的過程、變成跟 AI 對話。
人描述意圖、AI 寫 code、跑跑看、不對就再描述。
人完全不讀 code、只感受結果。」
關鍵字是 ─ 「不讀 code」。
這跟以前的「AI 輔助寫 code」最大差別 ─ 以前你會 review AI 給的 code、看懂再用。Vibe Coding 是你完全跳過 review、只看「跑起來像我想要的嗎」。
這個姿態有它的應用場景、也有它致命的盲點。
它為什麼紅
因為它讓「不會寫程式的人」第一次能用程式做出東西。
以前的世界：
- 有想法 → 學程式 6-12 個月 → 開始寫 → 上線
- 失敗率高、能撐過自學的人不到 5%
Vibe Coding 的世界：
- 有想法 → 開 Cursor → 用自然語言描述 → 兩小時後有原型
- 不需要會寫程式
這是真的革命。我們第一次看到 ─ 「會打字 + 會描述需求」就能做出東西。
優點 vs 致命缺點
✅ Vibe Coding 的優點
- 原型速度：以前 1 週、現在 2 小時
- 降低想法→實作門檻：不會寫程式也能試
- 探索式開發：邊做邊改方向、超低成本
- 不被工程細節綁住：先驗證再優化
- 適合 throwaway 工具 / 內部 script
❌ Vibe Coding 的致命缺點
- 不讀 code = 不知道有 bug
- 沒測試 → 改一個壞十個
- 沒架構 → 第 100 個 prompt 後混亂
- 安全漏洞看不到（沒人在 review）
- 沒人能接手、離職就死
- AI 自信錯誤 → 跟真錯誤分不出來
- 長期維護成本是普通軟體的 5-10 倍
看出規律了嗎？
Vibe Coding 在「從 0 到 1」階段是神器。
Vibe Coding 在「從 1 到 100」階段是災難。
Vibe Coding 給你速度。
工程紀律給你可維護性。
這兩件事不衝突、但你要知道什麼時候切換。
5 種人 ─ 你該怎麼用
① 完全不會寫程式、有想法的 founder / PM / 創作者
✅ 強烈建議用
這是 Vibe Coding 最甜的應用場景。你以前要找工程師 / 外包 / 花 6 個月學程式才能做出來的東西、現在 1 週內可以原型出來、拿去驗證有沒有人要。
建議 ─ 限制 scope：只做「驗證假設」用、不要真的拿去服務客戶。原型驗證完、找真工程師重寫。
② 想學程式的初學者
⚠️ 看怎麼用
雙面刃。
用對 ─ Vibe Coding 出來的 code 自己讀、查 AI「為什麼這樣寫」、邊用邊學 ─ 比看教科書快 10 倍。
用錯 ─ 完全靠 AI 寫、自己什麼都沒學到。3 個月後想換工具不會、想理解錯誤訊息不會 ─ 變成「AI 操作員」、不是工程師。
③ 工程師快速做 side project / 內部工具
✅ 強烈建議用
最被低估的應用 ─ 工程師寫「給自己用的小工具」、用 Vibe Coding 最有效率。
這些工具不上線、沒外部用戶、壞了自己修、根本不用工程紀律。能 100% 享受 Vibe Coding 的速度。
例如：CSV 處理、log 解析、定時 script、爬蟲、自動化工作流程。
④ 工程師做 production 系統
❌ 千萬不要
這是最危險的誤用。
Production 系統會被真實用戶用、會有資料庫、會處理錢 / 個資、會持續維護 12 個月以上。Vibe Coding 出來的 code 在這個場景 ─ 6 個月內一定爆炸。
替代方案 ─ 用 AI 加速、但用「讀 code、寫測試、有架構」的姿態。我那篇「14 個分水嶺檢查清單」就是寫給這個族群的。
⑤ 設計師 / Marketer 想做 prototype 證明概念
✅ 完美應用場景
你不是要做產品、你是要做「能 demo 的東西」說服老闆 / 客戶 / 投資人。
Vibe Coding 在這場景無敵 ─ 你的目的是「讓對方看到」、不是「它能 scale」。
建議 ─ Demo 完誠實講「這是原型、不是產品」、避免讓對方誤以為已經能上線。
什麼時候該停止 vibe、開始嚴肅工程
這是最關鍵的判斷。給你 5 個訊號：
- 有人開始付錢用 ─ 不管多少、收到第一筆錢、就要切換姿態
- 用戶超過 10 人 ─ bug 開始影響別人
- 你開始不敢動 code ─ 改一個 prompt 壞 3 個地方
- 它連到外部系統 ─ DB / API / 付費機制、責任變大
- 你需要新人接手 ─ 哪怕只是讓朋友幫忙
這 5 個訊號出現任 1 個 ─ 把 Vibe Coding 出來的 code 當 prototype 重新整理：
- 讀過每一段
- 不懂的問 AI 解釋
- 補測試（至少 1 個）
- 補 README
- 用 git 認真 commit
這段「重新整理」通常會發現 30-50% 的 code 要重寫。這不是失敗、這是正確的工程流程。
3 個實際使用心法
01 給 AI 看「原型 → 產品」的差別
在 .cursorrules 或 prompt 開頭加入：
# Current phase This project is in PROTOTYPE phase ─ optimize for speed, OK to skip tests/types/error handling. When we move to PRODUCTION: - I will explicitly say "let's harden this for production" - Then add tests, types, proper error handling, logging
這樣 AI 知道你現在在哪個階段、給的 code 風格會匹配。
02 用 git tag 標記「vibe 結束 / 工程開始」
當你決定切換姿態：
git tag -a "v0.1-vibe-end" -m "End of vibe phase, beginning serious engineering" git push --tags
這個 tag 是你 6 個月後回頭看「當初哪段是亂寫的」的記號。
03 把非 vibe 的事分開做
Vibe Coding 不適合的事：
- 登入 / 認證
- 付款
- 個資處理
- API 對外暴露
這些功能 ─ 不要用 vibe 寫。即使整個 project 在 vibe phase、這幾個 module 要用「讀 code + 測試 + review」的方式做。
一個 project 不需要全部都 vibe 或全部都嚴肅。混合使用才是 sweet spot。
最後一個觀念
Vibe Coding 不是「取代工程師」、是「降低試錯成本」。
它讓更多人能試、更多想法能驗證、更多有 sense 的 idea 浮上來。
真正稀缺的、從來不是「會寫 code」、是「知道該寫什麼」。
這個年代最大的機會 ─ 不是 vibe 出一個 SaaS 然後月入百萬（那是廣告話術）、是用 vibe 把你的想法降低到 1 週就能驗證、然後找 5 個真用戶、把他們的反饋變成「值得認真工程的東西」。
Vibe Coding 是你的入場券、不是終點。