AI 讓原型變容易，驗收就不能再靠感覺

AI 最迷人的地方，是它讓第一版很快出現。

有時候快到有點不合理。你描述一個 app，補幾句限制，等它跑完，畫面出來了，資料也接上了，甚至有一點像真的產品。

這當然是進步。

麻煩也在這裡：以前你花三天慢慢寫出來的東西，途中會被迫理解很多細節。資料怎麼流、權限怎麼過、錯誤怎麼處理、哪些地方其實只是硬撐。現在第一版可能在你還沒完全理解系統時，就已經看起來像完成了。

所以我覺得 vibe coding 或 coding agent 真正改變的，不只是寫 code 的速度。

它改變的是「工作交付」的速度。

一旦交付變快，驗收就不能再靠感覺。

能跑，不等於可以收

很多 AI 做出來的原型，會卡在一個很尷尬的狀態。

它不是假的。它真的能跑。登入頁可能會動，表單可以送出，後台也看得到資料。你把它錄成 demo，觀眾不一定看得出問題。

可是能跑只代表有一條 happy path。

它不代表陌生人可以放心使用。也不代表 secrets 沒有被亂放，auth 沒有繞過，資料庫規則沒有開太寬，第三方套件沒有奇怪風險，錯誤處理不是一碰就裂。

這是原型和服務之間最容易被 AI 模糊掉的線。

以前原型很粗糙，你比較容易知道它還只是原型。現在原型長得太像產品，反而需要更硬的驗收標準。

我會把這件事想成四個很小的 gate。

不是大型公司的流程文件。小團隊也用得上的那種。

第一個 gate：證據

Agent 說 done，沒有意義。

比較有意義的是：它改了什麼、為什麼改、跑過哪些命令、測過哪些路徑、哪些地方沒測、哪些判斷只是推測。

這些東西聽起來很無聊，但它們決定 reviewer 要不要重新把整個工作做一次。

如果 agent 交回來的是一包 diff，加上一句「已完成」，人類接手時其實很痛苦。你要猜它的意圖，要猜它有沒有跑測試，要猜它是不是只把錯誤訊息消掉，還要猜它有沒有在某個設定檔裡留下一個將來會爆的 workaround。

好的 agent 交付，應該像一個可以被驗收的 work item。

改了哪些檔案。跑了哪些檢查。哪個檢查失敗了。為什麼沒有修。哪裡需要人看。

有了這些證據，人類才有機會做真正的判斷。

沒有證據，驗收就會變成看心情。

第二個 gate：資料

只要你的 app 要讓陌生人帶資料進來，遊戲規則就變了。

一個自己用的 prototype，跟一個公開服務，不是同一種東西。前者壞掉，多半是你自己重來。後者壞掉，可能是別人的 email、照片、付款資訊、私密內容或工作資料被你搞丟。

所以 AI 做出第一版之後，不要急著問能不能部署。

先問資料會去哪裡。

誰可以讀？誰可以寫？身份驗證是真的，還是看起來有登入而已？API 有沒有直接信任前端傳來的 user id？環境變數是不是被放進 client bundle？log 裡有沒有敏感資料？儲存桶是不是開成 public？備份在哪裡？刪除資料是不是真的刪，還是只是 UI 不顯示？

這些問題不新。

但 AI 會讓它們更容易被跳過，因為畫面太快就能做出來。

尤其對獨立開發者來說，最危險的時刻不是「我知道這只是 demo」。最危險的是「看起來差不多了，先丟給幾個人用看看」。

幾個人用看看，就是公開服務的開始。

第三個 gate：維護

AI 很會幫你把東西接起來。

可是產品不是只要接起來。

它還要能被改、被 debug、被還原、被轉交給三個月後的自己。

這裡的 gate 很樸素。版本控制乾不乾淨？主要流程有沒有測試？錯誤有沒有留下足夠 log？部署出問題能不能 rollback？資料有沒有備份？依賴套件有沒有鎖版本？設定檔有沒有被拆成開發和正式環境？README 有沒有寫到足以讓下一個人重跑？

很多人會覺得這些東西打斷創作速度。

我反而覺得，它們是 AI 原型能不能留下來的關鍵。

如果一個 app 只能在 agent 剛跑完的那台機器上成立，那它還不是服務。它是一段正在冷卻的表演。

這不是說每個 side project 都要一開始就做滿 production checklist。那太重，也不現實。

比較合理的做法是分級。

自己玩，可以鬆一點。給朋友試用，要開始看 auth、資料和錯誤處理。要收真實使用者資料，就不能再用 demo 標準驗收。

標準可以很小，但不能沒有。

第四個 gate：歸屬

AI 交付的工作，最後還是人要接受。

這句話很普通，可是現在很容易被忘記。

因為 agent 會自己跑、自己修、自己解釋、自己把結果整理得像一個完成品。看起來越完整，人越容易順手收下。

但如果沒有人能說清楚為什麼可以收，那就不該收。

我會問幾個很直接的問題。

誰委託了這個工作？原本允許它改哪些範圍？它有沒有超出範圍？誰看過結果？如果明天出問題，誰負責處理？如果現在拒絕，這個結果會被丟掉、縮小重做，還是留下來慢慢補？

拒絕路徑很重要。

一個人類同事交來的 patch，你可以要求修改，可以退回，可以說這個方向不對。Agent 的結果也應該一樣。

不要因為它已經跑了很久、改了很多檔案，就讓自己不好意思拒絕。

產出成本不是驗收理由。

小團隊可以先用一張 acceptance card

我不覺得每個小團隊都需要立刻導入正式治理。

更實際的起點，是每次把比較大的事情交給 agent 前，先寫一張 acceptance card。

內容可以很短：

• 這次交付物是什麼

• 哪些檔案或功能算範圍內

• 哪些東西明確不能碰

• 完成後必須留下哪些證據

• 至少要跑哪些檢查

• 哪些資料或權限需要特別看

• 什麼情況下只能算 demo，不能上線

• 誰有權接受或拒絕

這張卡不是為了漂亮。

它的作用是逼你在開始前先承認：什麼叫完成，什麼叫還不行。

如果 acceptance card 寫不出來，通常不是 AI 還不夠強，而是任務本身還太模糊。這時候比較適合請 agent 做探索、列方案、做小範圍 spike，不適合直接交付一個「可以上線」的東西。

人類都不知道怎麼驗收的任務，不要交給 agent 自己往前衝。

真正的問題不是能不能做出來

接下來一段時間，我們會看到更多 agent 變得像可以委派工作的同事。

它們會更會寫 code，更會讀 repo，更會跑測試，更會把一個模糊需求推到可互動的狀態。

這很好。

但也代表 builder 要練的能力會換位置。

以前最難的是從零開始做出第一版。現在第一版變便宜了，最難的會變成：你知道怎麼接受它嗎？

不要只問 agent 能不能把 app 做出來。

問它留下了哪些證據。問資料會不會出事。問這份 code 三個月後能不能維護。問誰負責收下它。問什麼情況下你會拒絕。

如果這些問題回答不出來，那它就算能跑，也還只是 demo。

AI 可以讓原型變快。

但把原型變成可以交付的東西，還是人的工作。

Source notes

• Axios, "AI agents are here for real this time", 2026-06-25, www.axios.com/2026/0...

• The Verge, "Read this before you vibe-code another app", 2026-06-23, www.theverge.com/ai-...

• TechRadar, "Vibe coding guide: How to transition from AI generation to live deployment", 2026-06-23, www.techradar.com/pr...

• arXiv, "Detecting AI Coding Agents in Open Source: A Validated Multi-Method Census of 180 Million Repositories", 2026-06-23, arxiv.org/abs/2606.2...

• arXiv, "Coding with Enemy: Can Human Developers Detect AI Agent Sabotage?", 2026-06-04, arxiv.org/abs/2606.0...