什麼時候該 Vibe，什麼時候該工程化？一條光譜看懂
關於 AI 寫程式，網路上有兩派人吵個不停。一派說：「Vibe 出來的東西都是沙上城堡，遲早塌。」另一派說：「都什麼時代了還在寫規格，先做出來再說。」
我在課堂上被問過無數次「哪一派才對」，而 Addy Osmani 在《Beyond Vibe Coding》第一章給了我看過最乾淨的答案：兩派都對，因為那不是兩個陣營，是同一條光譜的兩端。你不需要選邊站，需要的是知道自己現在該站在哪裡——以及什麼時候該移動。
我之前在〈原型到生產〉用這條光譜當開場，這篇把光譜本身講透：兩端各是什麼、各自優化什麼、怎麼判斷該掛哪一擋。
這篇文章整理了《Beyond Vibe Coding》的光譜：prompt-first 與 plan-first 兩端各優化什麼、動手前的四個換擋問題，以及高手的混合駕駛法。適合在「先做出來」與「先寫規格」之間搖擺、想知道手上任務該掛哪一擋的人閱讀。
光譜的一端：prompt-first 的 Vibe Coding
Vibe coding 這個詞是 AI 先驅 Andrej Karpathy 創的，定義是 prompt-first：用自然語言描述你要什麼，讓 AI 填滿空白，跳過事前規劃，對話著把東西長出來。Karpathy 自述的工作方式很傳神：建議全部接受、diff 不再細看、錯誤訊息整段複製貼回去、修不掉的 bug 就繞過去——「完全交給 vibes」。
這種開法的威力是真的。書裡舉的例子：有人想做一個計算逐字稿字數、估算閱讀時間的小網頁，跟 AI 描述想法，幾分鐘就有可動原型，再說一句「加上 PDF 匯出」，十分鐘內上線。更誇張的案例：一位沒有程式背景、被裁員的行銷人，用 AI 做了上百個小工具，衝上 Product Hunt 排行榜。門檻降到這麼低，改變的不只是速度，是誰能做軟體這件事本身。
但代價也是真的。你把大量決定交給了 AI，可能得到一份「晴天能跑」但地基是沙的程式碼——書裡的形容是紙牌屋，平常看起來穩固，壓力一來整個塌。另一個隱性代價是「prompt 自己進死角」：沒有事前藍圖，AI 可能替你選了一條你根本不想走的技術路線，等你發現，要嘛硬掰回來，要嘛將就住下去。
光譜的另一端：plan-first 的 AI 輔助工程
另一端，Osmani 稱為 AI-assisted engineering：先寫下要做什麼、限制條件、怎樣算驗收通過——哪怕只是一張簡短的任務清單或一頁迷你規格——再讓 AI 在邊界內動手。書裡的例句很具體：「元件要顯示分析卡片清單、支援日期篩選、有重新整理與匯出按鈕、要處理錯誤、要符合我們的設計規範。」意圖先講清楚了，AI 的產出就不是驚喜，是一份「合格請求的產物」。
關鍵差別在於：AI 的創造力被規格綁住了。這聽起來像缺點，其實是這一端的全部意義——你要的不只是能動的程式碼，是高品質、能活很多年的程式碼。
書裡的比喻我認為值得背起來：vibe coding 是高速探索載具，能快速帶你離開既定道路，適合探勘；AI 輔助工程是火車，要先鋪軌（計畫），但更可能安全抵達既定目的地。他還給了第二組比喻：前者像即興爵士，邊演奏邊發現曲子的形狀；後者像古典作曲，主題先寫好，即興只發生在小節之內。
兩端優化的東西不一樣，期待也該不一樣
讀懂這條光譜的鑰匙，是看清兩端在優化不同的目標。
Vibe coding 優化短期速度:「今晚要跑起來，驗證這個想法行不行。」AI 輔助工程優化持續速度:「要快，但這段程式碼要能在系統裡活好幾年，別人要能接手。」前者能動就滿意，後者在乎乾淨到可以被蓋上去。
期待也要跟著調整。選 vibe 模式，你要預期被驚喜——AI 會用你沒想過的做法、你不熟的工具，樂趣和學習都來自這裡；但也要預期顛簸，最後那段難走的路是你的。選工程模式，預期更「無聊」也更實際：AI 替你省時間、偶爾給靈感，但驗證的時間是預算內的固定支出，不是意外。
重點：書裡還有一個很多人需要的提醒，我直接翻譯：「Vibe coding 不是低品質工作的藉口。它應該是解法的起點，不是終點。」
換擋判斷：動手前先答四個問題
那實際上怎麼選？我把書中散落的判斷依據，整理成四個問題，動手前花三十秒回答：
- 用途：這是在驗證想法，還是在做正式功能？
- 壽命：用完即丟，還是會一直用？
- 使用者：只有我，還是有別人？
- 資料：假資料，還是真實資料？
四個答案組合出你的擋位：全部偏左（驗證、即丟、自己、假資料），放心 vibe，享受那個十分鐘的魔法；任何一題偏右，就往工程端移一格——先寫驗收條件、要求 AI 解釋產出、補錯誤處理；偏右的題目越多，鋪的軌道就要越長。
換擋流程
拿我自己的三個東西對照，剛好落在三個擋位。會議成本計算機：用完即丟、自己用、假資料，純 vibe，十幾分鐘的事，鋪軌道反而是浪費。選賽道機器人：本來是 vibe 出來的玩具，後來決定放給社群用，我就補走右邊的路——逐段改寫提示詞、定義什麼輸入該擋掉。pbtw.tw 這個站：第一晚是 vibe，現在每次改版前先寫驗收清單，因為它的壽命是「一直活著」，使用者是「所有讀者」。同一個人，三種擋位，沒有矛盾。
高手的開法：混合駕駛與自然升檔
光譜最實用的推論是：會開兩種載具的人，贏過只會開一種的。書裡描述了兩種混合駕駛法。
第一種是微劑量 vibe：在一個照規格進行的工程任務裡，遇到無關緊要的小零件——「幫我生一個格式化日期的小函式」——暫時切進 vibe 模式拿了就走，再立刻切回工程模式整合與驗證。探索的快，紀律的穩，各取所需。
第二種是專案級換擋：用一陣 vibe 暴衝把雛形撞出來，確認方向對了，再切換成工程模式紮實化。重點是換擋要「真的換」。
注意：很多人卡在中間：拿著 vibe 出來的東西繼續 vibe 著修，卻期待工程級的品質，那是最差的組合，我在〈70% 問題〉寫過那種一步前進兩步後退的泥沼。
書裡還有一個觀察讓我點頭如搗蒜：隨著經驗累積，開發者會自然從 vibe 端往工程端漂移。蜜月期誰都想用一句話把整個應用「聊」出來；摔過幾次後，你開始把問題拆小再餵給 AI、先寫幾行偽碼或註解再請它補完——書裡的講法是，從「prompt 藝術家」變成「樂團指揮」。我在課堂上看著學員走過同一條曲線：第一週的作品都是暴衝出來的，第四週交出來的東西，開頭都多了一段自己寫的需求描述。沒有人規定要這樣，是翻過車的人自己長出來的。
常見問題
問：我是非工程師，只會 vibe，不會「工程化」，怎麼辦？
答：工程化的核心不是寫程式，是「先想後做、做完驗證」。寫下要什麼、怎樣算通過、請 AI 解釋產出、找人試用——這些你都做得到。光譜的右端對非工程師不是禁區，是檢查清單。
問：團隊裡有人愛 vibe、有人堅持規格，整天吵，怎麼辦？
答：把爭論從「哪種方法對」改成「這個任務在光譜哪裡」。探索性原型讓 vibe 派開車，核心功能讓工程派鋪軌，規則寫成團隊共識。吵方法是信仰之爭，吵擋位是工程討論。
問：AI 越來越強，以後是不是全部都能 vibe?
答：書的判斷是兩端會互相靠近：vibe 會長出護欄，工程會更流暢，理想是在整條光譜自由移動。但「想清楚要什麼、驗證對不對」不會消失——那從來不是 AI 的工作。
問：換擋會不會浪費掉之前 vibe 出來的東西？
答：不會白費。原型的價值在「證明這條路可行」，不在程式碼本身。換擋時把它當規格說明書——它已經替你回答了「要做什麼」，這是最貴的那個問題。
如果你還沒開過左端的探索載具，建議先去體驗那個十分鐘的魔法，再回來讀一次這篇，你會對「換擋」有完全不同的體感。「AI 助航 Vibe Coding」課程就是這樣設計的：新手上路帶你 vibe 出第一個工具，進階路線教你鋪軌——兩種載具，都該在你的車庫裡。
這篇文章萃取自我的筆記〈書摘筆記|Beyond Vibe Coding(Addy Osmani)〉(/note-beyond-vibe-coding-osmani/)