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、只感受結果。」

（此段為作者改寫自 Karpathy 原推文精神、非逐字翻譯、亦非直接引用原文。）

關鍵字是 ─ 「不讀 code」。

這跟以前的「AI 輔助寫 code」最大差別 ─ 以前你會 review AI 給的 code、看懂再用。Vibe Coding 是你完全跳過 review、只看「跑起來像我想要的嗎」。

這個姿態有它的應用場景、也有它致命的盲點。

---

它為什麼紅

因為它讓「不會寫程式的人」第一次能用程式做出東西。

以前的世界：

• 有想法 → 學程式 6-12 個月 → 開始寫 → 上線
• 失敗率高、真正靠純自學撐過來的只是少數 ─ 多數開發者其實是靠課程、社群或他人協助才走完這段路

Vibe Coding 的世界：

• 有想法 → 開 Cursor → 用自然語言描述 → 兩小時後有原型
• 不需要會寫程式

這是真的革命。我們第一次看到 ─ 「會打字 + 會描述需求」就能做出東西。

---

優點 vs 致命缺點

Vibe Coding 的優點

• 原型速度：以前 1 週、現在 2 小時
• 降低想法→實作門檻：不會寫程式也能試
• 探索式開發：邊做邊改方向、超低成本
• 不被工程細節綁住：先驗證再優化
• 適合 throwaway 工具 / 內部 script

Vibe Coding 的致命缺點

• 不讀 code = 不知道有 bug
• 沒測試 → 改一個壞十個
• 沒架構 → 第 100 個 prompt 後混亂
• 安全漏洞看不到（沒人在 review）
• 沒人能接手、離職就死
• AI 自信錯誤 → 跟真錯誤分不出來
• 長期維護成本明顯偏高、且隨規模攀升

看出規律了嗎？

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 個訊號：

1. 有人開始付錢用 ─ 不管多少、收到第一筆錢、就要切換姿態
2. 用戶超過 10 人 ─ bug 開始影響別人
3. 你開始不敢動 code ─ 改一個 prompt 壞 3 個地方
4. 它連到外部系統 ─ DB / API / 付費機制、責任變大
5. 你需要新人接手 ─ 哪怕只是讓朋友幫忙

這 5 個訊號出現任 1 個 ─ 把 Vibe Coding 出來的 code 當 prototype 重新整理：

• 讀過每一段
• 不懂的問 AI 解釋
• 補測試（至少 1 個）
• 補 README
• 用 git 認真 commit

這段「重新整理」通常會發現 30-50% 的 code 要重寫。這不是失敗、這是正確的工程流程。

---

3 個實際使用心法

01 給 AI 看「原型 → 產品」的差別

在 .cursorrules 或 prompt 開頭加入：（.cursorrules 已是 legacy 格式、Cursor 建議改用 .cursor/rules/ 目錄下的 .mdc 檔）

# 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 是你的入場券、不是終點。

---

延伸閱讀 ─ AI 時代工程師系列

• Vibe Code 救援完整 SOP ─ 把 AI 寫的爛 code 變成可維護產品
• AI 給你 code、給不了你軟體 ─ 14 個分水嶺檢查清單
• Cursor 12 個技巧 ─ 從會用到用得好
• AI 會取代工程師嗎?2026 年的誠實答案
• AI 時代工程師完整指南(總綱)