不讀 AI 產生的程式碼，只按 Accept All 來開發，現在通常稱為「Vibe Coding」。它的起步速度驚人，很多人認為一旦嘗試就很難回頭；但不讀程式碼的代價會在哪裡、以什麼方式出現，最好事先了解。
本文依序整理 Vibe Coding 的準確定義與優點、不讀程式碼實際會造成的三個問題，以及不用全部讀完也能降低事故的三個解法。
先從結論開始。
Vibe Coding 能讓起步速度快上 10 倍，但不讀程式碼，最後會把這份速度吐回來，變成維護成本。
如果是原型或自己使用的工具，非常值得一試。但若要提供服務給他人，或長期維護程式碼，情況就不同了。以下逐一說明原因。
Vibe Coding 究竟是什麼？
先說明這個術語。「Vibe Coding」一詞源自安德烈・卡帕西在 2025 年 2 月發表於 Twitter 的貼文。
核心很簡單：用自然語言告訴 AI 你想要什麼，由 AI 撰寫程式碼，而人不仔細閱讀那些程式碼。
卡帕西本人也說：「我總是按 Accept All，也不再讀 diff。」發生錯誤時，他會把錯誤訊息原封不動複製，再丟回給 AI。
順帶一提，Collins Dictionary 也將這個詞選為 2025 年的「年度詞彙」。
Vibe Coding 的本質與其說是「AI Coding」，不如說是「不讀程式碼」。即使使用 AI，只要把 diff 全部讀完，那就只是 AI 輔助開發，不是 Vibe Coding。
優點確實很明顯
Vibe Coding 受到歡迎是有原因的。
第一，啟動速度。 過去需要好幾天的專案初始設定，現在可縮短到幾十分鐘。直到畫面出現內容所需的時間會大幅縮短。
第二，補足弱項。 例如後端開發者用文字描述 CSS 版面並產出結果，能大幅降低進入不熟悉領域的門檻。
第三，心理障礙。 「先做出來再說」的想法變強，於是能真正開始碰觸一直拖延的點子。
問題在於，這份滿足感通常只維持到專案初期、程式碼還很少的時候。
不讀程式碼，實際會發生什麼事
當程式碼庫成長到一定程度，通常會出現三個問題。
1. 你會無法修正錯誤。 發生錯誤就直接交給 AI 的做法，會在 AI 修不好時一起卡住。因為從未讀過程式碼，根本無法判斷問題在哪裡。
2. 相同功能會出現在多個地方。 AI 常常記不住之前寫的程式碼，於是不斷重新建立相似函式。之後修好一個，其他的仍然原封不動。
3. 會出現不易察覺的安全漏洞。 最典型的例子，就是 API 金鑰直接寫進用戶端程式碼。AI 只照指示做，而人又沒有確認。
第三點最令人害怕。例如下面這種程式碼。
// AIAI 撰寫的程式碼 — 金鑰暴露在用戶端
let apiKey = "sk-live-abc123" // 直接放進 App 二進位檔
let url = URL(string: "https://api.example.com?key=\(apiKey)")!
URLSession.shared.dataTask(with: url).resume()這種程式碼一經發布，任何人都能看到金鑰。不讀 diff 就會漏掉這類問題。
那該怎麼辦？三個解法
幸好，不必回到「全部都讀」的做法，也有能大幅降低事故的方法。
解法 1：親自閱讀三個致命區域。 即使無法全部閱讀，也要先定義並檢查發生事故後難以挽回的部分。
// 至少親自確認這三項
// 1) 驗證與金鑰相關的程式碼
// 2) 付款與金錢相關的邏輯
// 3) 刪除或變更使用者資料的部分只顧好這三項，就能大幅降低發生重大事故的機率。
解法 2：閱讀 AI 的摘要，而不是程式碼。 如果不想讀程式碼，至少再要求一次：「請只摘要剛才撰寫的程式碼中，與安全性、金錢、資料刪除相關的風險」，然後閱讀摘要。不要在撰寫程式碼的工作階段，而是在新的工作階段，最好交給另一個 AI 審查，也能減少替自己寫的程式碼辯護的偏誤。
解法 3：人不讀，就讓機器讀。 在 pre-commit hook 加入 gitleaks 這類機密掃描器，就能在 commit 階段自動抓出上述的 API 金鑰暴露。把 linter 和測試加入 CI 也是同樣的原理。
三個解法的共同點是：降低閱讀成本，但不要讓驗證歸零。
所以，Vibe Coding 到底該不該做？
結論是「視情況而定」。
| 情況 | 推薦程度 | 原因 |
|---|---|---|
| 原型・Demo | 大力推薦 | 快速完成，丟掉也沒關係 |
| 自己使用的工具 | 推薦 | 即使壞掉，也只有自己困擾 |
| Side Project | 有條件推薦 | 閱讀核心邏輯 |
| 正式服務・團隊協作 | 不推薦 | 維護成本會吞噬速度優勢 |
關鍵在於：是完全不讀程式碼，還是只讀重要部分。
Q. 初學者也能用 Vibe Coding 學習開發嗎？ A. 它很適合體驗製作東西的樂趣。不過完全不讀程式碼，能力不太會進步。完成後可以問 AI：「你為什麼要這樣寫這段程式碼？」並養成閱讀習慣。
Q. AI 寫的程式碼，到底可以相信到什麼程度？ A. 能執行和安全是兩回事。可以相信 AI 讓它運作，但是否安全且可維護，必須由人或獨立的驗證機制確認。
總結來說，就是「速度交給 AI，判斷留給自己」。不必全部讀完，但完全不讀，總有一天會付出代價。只要把上述三個解法中的一個加入今天的專案，就能大幅降低代價。
再往前一步，還有一種稱為規格驅動開發（SDD）的方法論：在要求 AI 撰寫程式碼之前，先用文件確定需求。這是與 Vibe Coding 相反的做法，下一篇文章會詳細介紹。
參考資料
- Vibe coding - Wikipedia
- Not all AI-assisted programming is vibe coding (but vibe coding rocks) - Simon Willison