Vibe Coding 實戰五原則：讓 AI 寫程式不翻車的工作流
上一篇講了 Vibe Coding 是什麼，這篇進入實戰：為什麼同樣用 AI 寫程式，有人一個下午做出能用的工具，有人卡在報錯迴圈裡放棄？
差別是工作流。以下五個原則，是從大量翻車現場整理出來的。
這篇文章整理讓 AI 寫程式不翻車的五個實戰原則：小步迭代、先講驗收標準、報錯交給 AI 自己修、版本保護、修三次就砍掉重練，最後串成一個可以照跑的迴圈。適合已經開始用 AI 寫工具、卻常卡在報錯迴圈裡的人閱讀。
原則一：小步迭代，每步可驗收
一次只要求一個改動，看到結果再走下一步。
| 翻車寫法 | 穩定寫法 |
|---|---|
| 「做一個記帳 App，要能分類、統計、匯出、雲端同步」 | 「第一步：先做出輸入金額和分類的畫面，先不用存資料」 |
小步走看起來慢，實際上快——因為出錯時你立刻知道是剛剛那一步造成的，而不是在一千行程式裡大海撈針。
實際拆法長這樣。假設要做一個報價單產生器，我的迭代順序是：第一輪「做出輸入品項、單價、數量的表格畫面，先不用計算」；第二輪「加上自動加總和稅金計算」；第三輪「加一個匯出 PDF 的按鈕」；第四輪「把公司 Logo 和聯絡資訊放進 PDF 表頭」。每一輪都花三十秒驗收再走下一步。第三輪匯出的 PDF 如果是空白的，我馬上知道問題出在匯出功能，跟前兩輪無關——這就是小步迭代買到的除錯速度。
原則二：先講驗收標準，再讓 AI 動手
在請 AI 寫之前，先寫下「怎樣算完成」：
完成標準：1) 手機上按鈕夠大好按 2) 輸入非數字時顯示提醒，不會壞掉 3) 重新整理後資料還在
AI 拿到驗收標準，會主動處理你沒想到的細節；沒有標準，它只會交出「大概能跑」的程式。這一步就是 PM 的核心工作——把模糊的期待變成可檢查的條件。
有沒有標準，產出差多少？我做過對照實驗。同一個「記帳輸入頁」，不給標準的版本：輸入文字會算出 NaN、手機上按鈕小到誤觸、重新整理資料全消失。給了上面那三條標準的版本：AI 主動加了輸入檢查與提示文字、按鈕自己放大成整排寬、還用了本機儲存讓資料留得住——同一個模型、同一天、差別只有那三行字。驗收標準怎麼寫才算「可檢查」？口訣是有動作、有結果：「輸入 abc 按確認，會出現紅字提醒」可檢查；「介面要友善」不可檢查。寫不出可檢查版本的期待，代表你自己還沒想清楚，先想再下指令。
原則三：報錯交給 AI 自己修
遇到錯誤訊息，流程固定三步：
- 錯誤訊息原封不動全文貼回給 AI（不要自己摘要，你的摘要會丟掉關鍵線索）
- 加一句：「請解釋這個錯誤的原因，然後修正它」
- 如果同一個錯修兩次還在，換句話說：「請加上除錯輸出，先找出問題的根源再修」
「解釋原因」這半句很重要——它逼 AI 先診斷再動手，而不是亂槍打鳥地改。
來看一個真實回合。我的網頁按鈕按了沒反應，主控台一行紅字：Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')。整行貼回去加上「請解釋原因再修正」，AI 的回覆是：「程式在頁面載入完成前就嘗試抓取按鈕元素，所以抓到 null。修法：把 script 移到 body 結尾（或加上 DOMContentLoaded 事件）。」一次修好。如果我只貼「按鈕壞了」，它大概會重寫整顆按鈕——症狀描述會引導它亂猜，錯誤原文才會引導它診斷。這也是為什麼不要自己摘要：你覺得不重要而刪掉的那半行，常常就是病灶所在。
原則四：能動的版本就是資產，立刻保存
每次功能正常運作，就存一份快照（另存新檔、或學會用 Git 之後 commit）。鐵則是：
重點：永遠保留一個「現在就能用」的版本。
改壞了就回到上一個快照重來。沒有這條保護網，一次失敗的修改就可能毀掉整個下午的成果——這是新手放棄的最大原因，而它完全可以避免。
我自己的教訓：有一次只想「把配色改成深色模式」，這種小改動誰會存檔？結果 AI 重排版面時順手刪掉了一段計算邏輯，工具直接報廢，而我上一份存檔是三小時前。從此我的規矩是：存檔的判斷標準不是「改動大不大」，而是「現在的版本能不能動」。能動，就值得保存；檔名用最笨的流水號加功能描述，例如 quote-03-加稅金.html，壞掉時一秒就知道要回到哪裡。
原則五：修三次修不好，砍掉重練
反直覺但有效：同一個問題讓 AI 修了三次還在，不要繼續修。開一個全新的對話，把需求重新描述一次（這時你已經比第一次清楚得多），讓 AI 從乾淨的狀態重寫。
原因：長對話裡 AI 會被自己之前的錯誤方向「污染」，越修越歪。重開對話等於換一個沒有包袱的工程師。配合原則四，你砍掉的只是壞掉的分支，不是全部進度。
被污染的對話長什麼樣子，經歷過一次就認得：我曾經請 AI 修「匯出 CSV 中文變亂碼」，第一次它改編碼，沒效；第二次它重寫匯出函式，亂碼還在，而且欄位順序跑掉了；第三次它開始建議我「換一個瀏覽器試試」——當 AI 開始把問題推給環境，就是該重開的訊號。我開了新對話，只貼上需求和最新版程式碼，加一句「匯出的 CSV 要讓 Excel 直接開啟時中文正常顯示」，一次解決（它在新對話裡直接用了 BOM 標頭，前一個對話三次都沒想到）。
我的經驗：舊對話裡唯一值得帶走的是教訓，不是程式碼。
第六個隱藏原則：動手前，先讓 AI 複述計畫
五原則之外，還有一個我用得越來越多的進階動作：在需求講完之後、AI 動手之前，加一句——
先不要寫程式。先告訴我：你打算怎麼做、分成幾步、有哪些我可能沒想到的風險或選擇。
AI 的回覆會像這樣：「我計畫分三步:1) 表單畫面 2) 計算邏輯 3) 本機儲存。需要你先決定的事：資料只存在這台裝置可以嗎？換手機就看不到了。另外金額要支援小數點嗎？」——看到了嗎，它在動手前就抓出兩個你沒想過的需求漏洞。三十秒的確認，省掉的是做完才發現方向錯誤的整個下午。這招在需求比較複雜、或你自己也不太確定要什麼的時候，價值最高：便宜的修正永遠發生在寫程式之前。
常見翻車 FAQ
問：小步迭代要來回那麼多次，不會比較慢嗎？
答：單看打字次數，會。但算總帳不會——一次到位的大需求，翻車後的除錯時間遠超過多打幾輪訊息。經驗法則：需求越模糊，步子要越小；你對成品想像越清楚，一次可以餵越多。
問：驗收標準到底要寫幾條、寫多細？
答：三到五條就夠，挑「壞掉最痛」的寫：資料會不會消失、錯誤輸入會不會弄壞畫面、目標裝置上能不能操作。寫超過十條通常代表範圍太大，該拆專案而不是寫更多標準。
問：為什麼是修三次，不是五次、十次？
答：三次是經驗值，不是定律。背後的邏輯：第一次修不好可能是訊息不足，第二次修不好可能是方向錯誤，第三次還修不好，幾乎可以確定對話已經被污染。繼續耗下去的期望值，低於重開的成本。
問：用 Cursor、Claude Code 這類 AI 編輯器，五原則還適用嗎？
答：適用，而且更重要。編輯器自動化程度高，等於 AI 一步能改更多東西——沒有驗收標準和版本保護，翻車只會翻得更大。差別只在工具：存快照變成 Git commit，重開對話變成清空上下文重來。
問：我每次都照原則做，為什麼還是會卡？
答：檢查你卡的是「程式問題」還是「需求問題」。原則處理的是前者；如果你發現自己反覆改需求、推翻昨天的決定，那不是工作流的問題，是你還沒想清楚要做什麼——回去把一句話需求和驗收標準重寫一遍，通常就通了。
迴圈檢核表
動手前：
- 這一步的需求，一句話講得完嗎？
- 驗收標準寫了嗎？每條都「有動作、有結果」?
- 複雜需求，有先讓 AI 複述計畫嗎？
每輪迭代：
- 這輪只改一件事？
- 驗收過了嗎？過了就立刻存快照
- 檔名看得出版本和功能嗎？
卡關時：
- 錯誤訊息是原文貼回，不是自己摘要？
- 有要求「先解釋原因再修」?
- 同一個問題第三次了嗎？是的話，重開對話，只帶需求和最新能動的版本
把五原則串成一個迴圈
這個迴圈就是 Vibe Coding 的核心工作流——你會發現它和帶一個新人工程師的方法幾乎一樣：講清楚、小步驗收、保留退路。
想在一天內把這套流程完整練起來、現場做出自己的工具？來上「AI 助航 Vibe Coding」工作坊，我們從零開始陪你完成第一個作品。