Vibe 出來的東西，離「能給別人用」還有多遠？《Beyond Vibe Coding》的答案

這篇文章整理了 Addy Osmani《Beyond Vibe Coding》從原型到生產的路線圖，包含五道關卡、審查原則與上線後的維運紀律。適合已經能 vibe 出自己用的工具、想讓它「能給別人用」的人閱讀。

你大概有過這個時刻：用 AI 做了一個小工具，自己用得很順。某天同事看到，說「欸，可以也給我用嗎？」你爽快答應，當晚開始心虛——別人輸入奇怪的東西會怎樣？資料存在哪？壞掉誰修？

那句「可以給我用嗎」，就是原型與生產的分水嶺。自己用，叫原型；給別人用，叫產品。中間隔著一整套工程。

Google Chrome 的工程主管 Addy Osmani 在《Beyond Vibe Coding: From Coder to AI-Era Developer》(O'Reilly)整本書回答的，就是這條分水嶺怎麼跨。他前一本書診斷了「70% 問題」——AI 帶你走七成的路，最後三成卡到懷疑人生（我寫過白話拆解：〈70% 問題〉）。這本書更進一步：那三成不是「再多 prompt 幾次」能補的，它需要的是工程——結構、審查、安全、測試、部署。

這篇聚焦書裡「從原型到生產」的路線圖，並用我重建 pbtw.tw 的經驗對照。那段距離比想像中遠，但路線清楚，大部分關卡非工程師也走得完。

先認清自己在光譜的哪一端

書的第一章先畫了一條光譜。一端是 vibe coding：先 prompt、後實作，跳過事前規劃，跟 AI 對話著把東西長出來。另一端是 AI 輔助工程：先寫下要做什麼、限制條件、怎樣算驗收通過，再讓 AI 在邊界內動手。

Osmani 的比喻：vibe coding 是高速探索載具，能快速帶你離開既定道路；AI 輔助工程像火車，要先鋪軌道（計畫），但更可能安全抵達目的地。

兩者沒有誰高誰低，差別在優化目標：vibe coding 優化短期速度——「今晚要跑起來驗證想法」;AI 輔助工程優化持續速度——「要快，但這段程式碼要能活好幾年」。書裡一句話值得抄下：vibe coding 不是低品質的藉口，它是起點，不是終點。

所以動手前先回答兩個問題：這個東西要活多久？誰會用它？「用完即丟、只有我用」，放心 vibe;「會一直用、別人也用、碰真實資料」，你就站到了光譜另一端，下面的關卡一道都不能跳。

「能動」到「能給別人用」的五道關卡

書的第六章專門講原型轉生產，我把它整理成五道關卡。此時 AI 的角色要切換：從「快速噴功能」變成「輔助提質」——你出題，它打下手。

關卡一：結構重整。原型常是一個檔案打天下，改一處動全身。轉生產要拆模組、把資料處理和畫面分開；甚至可把原型當參考資料，開新專案重練。書裡說得直白：原型的價值是「證明這條路可行」，不是程式碼本身。

關卡二：錯誤處理與邊界情況。原型只顧晴天劇本。逐一檢查：網路斷了會怎樣？輸入是空的會怎樣？這步 AI 幫得上大忙，直接問：「這個功能有哪些錯誤情況？該怎麼處理？」它列清單，你逐條補。

關卡三：安全體檢。書中引述的大規模分析發現，約 25% 到 33% 的 AI 生成程式碼含潛在安全弱點——寫死的金鑰、沒參數化的資料庫查詢、過鬆的權限、把內部錯誤訊息直接吐給使用者。這些弱點會釀成什麼事，我在〈Vibe Coding 資安指南〉整理過五個風險點，可拿來當體檢表。

關卡四：測試。請 AI 為核心邏輯生成測試案例，自己跑過；更重要的是找一個真人（最好不熟電腦）實際用一輪，Demo 品質陷阱通常在這步現形。

關卡五：文件與待辦清單。原型階段所有「暫時做法」——假資料、跳過的驗證、寫死的設定——要列成清單，不然一個月後你自己都忘了哪些是假的。

流程總覽

這五道關卡我完整走過一次。pbtw.tw 這個站，最早的版本就是 vibe 出來的——一個晚上，能看、能點、我很滿意。但從「我的原型」走到「對外的正式站」，時間幾乎都花在看不見的地方：快取怎麼設，才不會改了內容讀者還看到舊版；版本怎麼管，才能在改壞時一鍵退回；每次更新前的驗收清單要檢查哪些頁面、連結。這些事 AI 一行都沒少幫我寫，但每項「要做這件事」的決定，都是人下的。原型那一晚，回頭看就是書裡說的那 70%——而且是比較簡單的 70%。

審查：把 AI 的程式碼變成「你的」程式碼

重點：第五章和第八章反覆敲打同一件事：不要合併你看不懂的程式碼。

Osmani 給了一面紅旗：被問到「這段為什麼這樣寫」，答案是「AI 寫的，應該沒錯」。解法是請 AI 逐段解釋，解釋到你能用自己的話複述為止；還是不懂，就請它用你懂的方式重寫。

書裡的黃金法則有三條跟審查直接相關，非工程師也照做得來：AI 產出的變更獨立 commit，與手動修改分開，方便回溯；小步提交，一次一個改動，審得動也退得回；所有程式碼過同一套驗收，不因為「跑起來沒報錯」就放行，要拿原始需求逐條對。這幾條和我整理過的〈Vibe Coding 實戰五原則〉幾乎重疊，因為大家翻的車都長一樣。

書裡有個說法我很喜歡：AI 時代的開發者越來越像編輯——AI 是多產但需要盯的寫手，你的價值在判斷該留、該改、該整段退稿。

上線不是終點：給別人用，就要養它

注意：第八章後半講部署與維運，一句話總結：AI 讓你寫得更快，所以更需要護欄——更短時間產出更多程式碼，等於更大的待稽核表面積。

書裡列的做法都是經典工程紀律：小步發布（先給少數人，沒事再全開）、永遠有回滾計畫、上監控（出錯要有人知道，不是等使用者抱怨）、金鑰交給密鑰管理服務、定期回頭稽核。還有一條常被忽略：工具要有人認領。建的人離開了，工具還在跑、還握著資料和權限，就成了沒人敢關的殭屍應用。

這段我讀得特別有感，因為它正是我兩個身分交會的地方。做資安出身，我看過太多「能動」就上線的東西後來變成破口；教 Vibe Coding，我又親眼看著學員十分鐘做出工具時眼睛發光。兩件事不矛盾——矛盾的是中間沒有橋。這正是課程開出「安全上雲版」路線的原因：新手上路教你把工具做出來，安全上雲教你把工具安全地交出去——部署、權限、金鑰管理，正是第八章在講的事。

常見問題

問：我不是工程師，這五道關卡真的做得到嗎？
答：大部分可以。錯誤處理、測試、待辦清單，都能「問對問題」讓 AI 代勞，你負責出題和驗收。做不到的是安全體檢的最後把關——這關建議找懂的人看過，或至少照五個風險點自查一輪；碰真實個資與正式系統的，不要跳過。

問：原型要不要乾脆砍掉重練？
答：兩種都行：小工具通常邊重構邊補測試就夠；原型已亂到改一處壞三處，就開新專案、把原型當「規格說明書」重練。判斷標準：修 bug 的時間是否已超過重做的時間。

問：讓 AI 檢查自己寫的程式碼，可行嗎？
答：可行而且該做，但只能當第一層。「掃描這段程式碼的安全問題」「有哪些邊界情況沒處理」都是好提示詞。但 AI 的自信一向超過它的可靠，最後一層驗證——跑起來測、找真人用、對照需求——還是人的事。

問：多小的工具才可以不走這些關卡？
答：回到那兩個問題：只有你用、用完即丟，放心 vibe。「會一直用」或「別人也用」其中一個成立，至少走錯誤處理和安全體檢兩關；兩個都成立，五關全走。

那段距離，是可以教的

這本書給我最大的收穫：原型到生產的距離，不是天分，是清單。每道關卡都有明確步驟、可照抄的提示詞、可判斷的驗收標準——也就是說，它學得會。

如果你已經能 vibe 出自己用的工具，下一步想讓它「能給別人用」，我的「AI 助航 Vibe Coding」課程把這條路拆成新手上路、講師版、安全上雲三條路線。工具要給別人用、要碰真實資料的，直接看安全上雲版——它教的就是這篇第三關之後的所有事。

這篇文章萃取自我的筆記〈書摘筆記|Beyond Vibe Coding(Addy Osmani)〉(/note-beyond-vibe-coding-osmani/)