Vibe coding 做完就能上線？用詢價表的 8 個驗收情境，看懂原型與正式服務的差別

在預覽畫面輸入姓名、按下送出，螢幕跳出「已收到您的需求」。這張詢價表看起來完成了。但換一台電腦登入後，後台找不到紀錄；測試時看到的成功訊息，只是前端預先寫好的文字。

這是本篇的教學假設，卻能說明 AI 開發專案容易忽略的交付問題：畫面、資料與營運責任，必須一起被驗證。對不是每天讀程式的專案負責人而言，最有用的能力，是把「做好了」改寫成任何人都能重做的驗收情境。

把需求寫成輸入、狀態與證據

「做一個專業詢價表」會留下太多空白：哪些欄位必填？送出失敗要顯示什麼？誰看得到名單？一個人按兩次怎麼辦？先把這些決定寫下來，再要求 AI 實作，能減少開發過程自行猜測業務規則。

本例的交付規格是：訪客填寫公司、聯絡方式與需求，成功保存後取得案件編號；授權管理者可查看與處理；未授權訪客不能讀取他人的案件。通知信是另一個步驟，寄送失敗不應讓已保存的案件消失，也不應謊稱信件已送達。

八個情境，比八張漂亮截圖更能判斷交付

下面的範圍適用於這張簡單詢價表。涉及付款、醫療或其他高影響流程時，需要更完整的專業驗證，不能直接沿用這份表作為全部驗收。

不是每一列都要由同一個人執行。業務確認欄位與通知內容，產品負責人走主要流程，工程人員檢查服務端權限、保存與錯誤處理。只用介面隱藏按鈕，不能證明後端授權正確。

測試紀錄要讓下一個人可以重現

每次測試記下版本或提交識別碼、環境、測試角色、操作步驟、預期結果、實際結果與證據位置。案例資料用虛構公司與測試信箱，截圖避開真實個資。若 AI 回覆「測試通過」，要求附上實際執行的檢查與輸出；沒有跑的部分應列為未驗證。

GitHub 官方的 AI 程式碼審閱指引提醒，應檢查功能、需求脈絡與相依套件，也要留意模型為了通過檢查而刪除或略過測試的情況。〔1〕 本篇八情境則是針對詢價表整理的交付範例，並不是 GitHub 的認證流程。

一個有判斷力的追問是：「這個測試如果把功能故意改錯，會失敗嗎？」例如資料只存在瀏覽器記憶體時，重新載入後台的檢查應該抓得出來。若測試只是確認程式回傳成功字樣，可能只是重複程式自己的宣告。

先做一條完整路徑，再增加功能

先完成「填表 → 保存 → 後台查詢」這條小範圍流程，再增加通知、標籤或報表。這樣當資料不見時，問題範圍較小，也能把每一階段的基準保存下來。若同時加入登入、付款、會員分級與 AI 客服，驗收責任與故障原因會迅速交疊。

請 AI 修改時，附上問題重現步驟與應有行為，例如「手機漏填 Email 時，姓名被清空；請保留姓名並將焦點移到錯誤欄位」。這比「再專業一點」更容易得到可核對的修改。

上線計畫還要寫出故障時怎麼辦

正式開放前，確認誰接收異常、在哪裡看保存與通知紀錄、什麼情況暫停表單，以及如何回復。回復不是只把舊程式重新部署：若新版本已改了資料結構，舊程式是否還能讀取？期間收到的案件要如何保全與補處理？

這些問題可以用一張簡短交接單回答：發布版本、資料變更、已測範圍、未測範圍、監看人員、停止條件、回復步驟與演練結果。不要把「有備份」當成「確定可還原」；至少在適當的測試環境確認一次讀回與流程恢復。

何時需要從 Vibe coding 進入工程工作流？

當原型開始承接真實詢問、需要多人維護或跨系統連接，規格、版本、測試與審查就成為交付的一部分。若你已有第一版作品，卻說不清楚驗收與維運責任，可帶著這張表評估進階課程；若連使用者要完成什麼都尚未確認，先做小規模原型訪談會更合適。