AI 原型很漂亮，工程師卻做一個月？我拆解原型到落地開發的 5 個斷層

💡 核心結論速覽 (TL;DR)

• AI 原型不是半成品，是「另一種東西」：它證明的是「畫面長這樣、流程走得通」，不是「這個功能在真實資料、權限與流量下也成立」——這兩件事的工作量差距，常常就是那多出來的一個月。
• 五個斷層最花時間：狀態（空、錯誤、載入中）、真實資料、權限與角色、效能與規模、既有系統整合。原型幾乎都跳過這五塊，而它們才是開發的主體。
• 研究也對不上感覺：METR 隨機對照試驗中，資深開發者用 AI 的完成時間反而多了 19%，但他們自評「快了 20%」；DORA 2025 調查近 5,000 人，AI 採用率 90%，卻只有 24% 高度信任 AI 產出。
• 下一步：別停掉原型，改交付物。用文末那份「原型交接清單」把狀態、資料、權限、驗收條件補在原型旁邊，再送進排期——這比逼工程師「照著做」有效得多。

你有沒有經歷過這種會議：企劃拿出一個 AI 做的原型，滑順、有動畫、點下去真的會跳頁，全場都覺得「這不是快好了嗎」；三週後站會上，工程師還在講資料結構跟權限，畫面連一半都不像。然後空氣就安靜了。

先講結論：這通常不是誰在混，而是你們交付的東西根本不是同一種東西。AI 原型證明的是「長這樣、流程走得通」，正式開發要處理的是「在真實資料、真實權限、真實流量下也成立」。前者 AI 現在很擅長，後者 AI 幫得上忙但省不掉。

我帶產品團隊這些年，這種斷層每一年都在換皮出現：以前是設計師的 Sketch 稿，後來是 Figma 的高保真原型，現在是 AI 一句話生出來的可點擊 demo。工具越來越像成品，誤會就越來越深。這篇我想把中間那五個斷層一個一個拆開，順便給你一份我自己在用的交接清單。

AI 原型跟能上線的產品，到底差在哪？

差在「證明的對象不一樣」。AI 原型的任務是說服人——說服老闆這值得做、說服使用者這流程順；正式開發的任務是說服系統——說服資料庫、權限模組、金流、還有半夜三點的流量。

這件事拆開來看很清楚。我習慣用五組對照跟團隊對齊，開會時直接投出來，比吵三十分鐘有用：

• 資料：原型是寫死的假資料，永遠剛好放得下 → 開發要面對真實資料，會超長、會缺欄位、會是 null
• 狀態：原型只有「一切正常」那一種 → 開發要處理空狀態、載入中、逾時、失敗、部分失敗
• 權限：原型預設你是超級管理員 → 開發要做多角色、多層級，還要擋越權
• 整合：原型不接任何舊系統 → 開發要接既有帳號、金流、報表、稽核
• 驗收：原型「看起來對」就算過 → 開發要通過測試、資安、效能與可維護性

看懂這五組對照，你就知道為什麼「原型只花兩小時、開發要一個月」不是誰在灌水。原型做的是箭頭左邊，開發做的是箭頭右邊，而右邊的每一項都是真的要寫程式碼的。

這也是我在不會設計也能用 AI 做出 mockup 與使用者流程的那篇裡一直強調的：先決定 AI 要幫你畫「什麼」，比追求畫面漂不漂亮重要太多。畫面是最容易生的，也是最不值錢的那一層。

斷層一：AI 原型「看起來會動」是最騙人的一件事

可點擊，不等於有邏輯。這是我覺得最該先講的一條，因為它騙的不只是老闆，也騙企劃自己。

老實說我自己也栽過。有一次我把一個做得很順的可點擊 demo 直接丟進需求討論，心裡想著「這比我寫三頁規格清楚多了」。結果工程師第一個問題就把我問住：「這個列表沒有資料的時候長什麼樣？」 我愣了三秒才承認：原型裡永遠有資料，因為那些資料是我請 AI 一起生出來的。

接著是第二題、第三題：載入要不要骨架屏？打 API 失敗要顯示什麼？使用者按了送出但網路斷掉呢？這些在原型裡通通不存在，因為原型的世界裡沒有失敗。

一個畫面在真實產品裡通常至少要處理五種狀態：

• ❶ 空狀態——第一次使用、沒有任何資料（新用戶看到的第一眼，往往決定他留不留）
• ❷ 載入中——要不要 skeleton、要不要 loading 文案
• ❸ 正常——原型唯一有畫的那一種
• ❹ 錯誤——失敗訊息寫什麼、能不能重試
• ❺ 極端值——資料超長、超多、名稱是 30 個字的公司全名

你只交一種，工程師就得自己猜四種。猜錯了，回頭改；改完你說「不是這個意思」，再改一次。那個「開發一個月還不像」的一個月，很大一塊就消耗在這裡。

你的下一步：把原型交出去之前，先把這五種狀態各寫一句話。不用畫，寫字就好——這是投報率最高的十分鐘。

斷層二與三：假資料和權限，AI 原型最省略、開發最花時間

假資料是原型的最大優勢，也是它最大的謊言。AI 生出來的示範資料有個特徵：它永遠剛好塞得進版面。名字兩到三個字、金額不會有小數第三位、日期一定是今年、清單剛好八筆不會分頁。

真實資料完全不長這樣。我看過的真實情況是：客戶名稱長到把整行擠爆、有三個欄位是空的因為那是十年前匯進來的舊資料、同一個手機號碼在系統裡對到兩個帳號。這些不是 bug，是資料本來的樣子，而工程師必須每一種都處理。

權限更隱形。原型預設你是神——什麼都看得到、什麼都能按。真實系統裡至少要回答三題：誰能看、誰能改、看不到的人按了會怎樣。最後一題最容易漏，也最容易變成資安事故。

我帶團隊時養成一個習慣：任何一個新畫面，我都會逼自己先寫一句「這頁在權限最小的那個角色眼裡長什麼樣」。寫得出來，這個需求才算想清楚；寫不出來，代表我還沒真的想過誰在用。

順帶一提，這也是為什麼我覺得 AI 在還原用戶訪談洞察那種事情上比生原型有價值得多——它幫你看見「誰在用、卡在哪」，而不是幫你把畫面畫得更亮。

斷層四與五：效能與整合，AI 原型交出去後那個月不是在寫畫面

如果你只記得這篇的一句話，我希望是這句：工程師那個月大部分時間不是在寫畫面，是在接東西。

效能這關，原型是完全免測的。原型只有八筆假資料，當然滑得順；真實情況可能是八萬筆，就得處理分頁、快取、索引，前端還要虛擬捲動。這些工作在畫面上「完全看不出來」，所以最容易被誤會成拖延。

整合這關更硬。一個新功能要活在既有系統裡，通常要接上帳號體系、權限模組、通知、報表、稽核紀錄，有時還有金流跟發票。AI 原型是在真空裡長出來的，它不知道你們公司三年前那套會員系統長什麼樣，也不知道那張表為什麼不能改欄位。

我通常會請團隊在排期前先把「要接幾個既有系統」數出來——這個數字比功能點數更能預測風險。至於工時怎麼估，我在把三種規模的需求丟給 ChatGPT 跟 Claude 重估的那次實測裡有寫得更細：需求越大，AI 越樂觀，中大型需求你得自己往上加 buffer。

你的下一步：排期會議上加一個欄位叫「外部相依」，把每個需求要碰的既有系統列出來。列完你會發現，時間都在那裡。

數據怎麼說？AI 讓交付變快，但也讓「感覺」失準

直接講結論：目前公開的幾份研究，指向的不是「AI 沒用」，而是「AI 放大你原本的樣子」——流程好的團隊變更好，混亂的團隊變更混亂。這句話是 DORA 2025 年度報告的核心框架，我覺得比任何工具評測都更值得貼在牆上。

三份來源放在一起看特別有意思：

那份 METR 的試驗我要特別誠實補一句：他們找的是 16 位對自己專案很熟的資深開源開發者、246 個真實任務，而且 METR 後來自己聲明這個結果應視為歷史結果，不必然反映現在的模型與工作流。所以請不要拿它去證明「AI 讓人變慢」——它證明的其實是更值錢的另一件事：人對自己速度的自評，會系統性偏樂觀。

而這正好解釋了開頭那個場景。企劃覺得「快好了」，工程師覺得「還早」，兩邊都沒說謊，只是一個在看畫面、一個在看系統。

至於 GitClear 的重複碼統計，我自己的解讀是：它量到的不是「AI 寫得爛」，而是「複製貼上變便宜了」。當生成一段相似的程式碼只要三秒，重構的動機就會下降——這在我用 AI agent 跑自動化時也有同感，方便到某個程度，人就懶得回頭整理了。

那 AI 原型還值得做嗎？值得，但要換一種交付物

值得，而且我完全不建議退回「先寫三十頁規格再說」的老路。原型最大的價值是把爭論提早：與其在開發第三週才發現流程設計錯了，不如在第一天就用一個能點的東西吵完。

但要改的是「你交出去的是什麼」。同樣是原型工具，用途其實差很多：

我對 Lovable 這類工具的實際判斷寫在實測三個原型之後那篇；工程端要選哪一把刀，則可以看Cursor 跟 GitHub Copilot 的比較。把兩端分清楚，你就不會再期待「原型直接改一改就能上線」。

適合誰：需要對齊流程、要說服利害關係人、要在一天內驗證方向的 PM 與企劃。
不適合誰：要接既有帳號／金流／稽核的功能、有法遵或資安要求的模組、以及「原型直接上線」的期待。
成本怎麼看：原型的成本不是訂閱費，是「被當成規格之後的返工時間」——那才是真正貴的部分。

我的 AI 原型交接清單：讓原型不再變成爭吵的起點

先說最重要的一句話：AI 原型不是需求文件。它是需求文件的插圖。真正要交出去的是「原型 + 這六件事」，缺一項，工程師就得替你猜一項。

這是我自己在用的清單，直接抄去改成你們團隊的版本：

• ❶ 這個畫面要幫使用者完成哪一件事——一句話，只能一件。寫不出來代表需求還沒收斂。
• ❷ 五種狀態各一句——空、載入、正常、錯誤、極端值。不用畫，文字即可。
• ❸ 資料從哪來——哪些欄位是既有的、哪些要新建、哪些可能是空的。
• ❹ 誰能看、誰能改——列出角色，並註明權限不足時的行為（隱藏？灰掉？跳提示？）。
• ❺ 要接哪些既有系統——帳號、通知、報表、金流、稽核，數量就是風險指標。
• ❻ 驗收條件——什麼情況算做完。寫成可以打勾的句子，不要寫「順暢好用」。

清單看起來很土，但它解決的是一個很現實的問題：原型會讓人以為「已經溝通過了」。實際上原型只溝通了外觀，這六題才是內容。我把它們寫在原型旁邊之後，最明顯的變化是站會上「這不是我要的」這句話出現頻率大幅下降。

另一個容易被忽略的角色問題是：這份清單到底該誰寫？我的看法是 PM 寫前四項、工程師補第五項、兩邊一起定第六項——這條線怎麼劃，我在AI 時代 PM 工作邊界正在消失那篇談得更完整。當 AI 把「產出」變便宜，PM 的價值就會全部集中到「判斷」上。

你的下一步：下次交原型時，附上這六題的答案。如果你發現有兩題以上答不出來，那不是文件問題，是需求還沒想清楚——這時候該退回去想，而不是催工程師開工。

什麼情況我會直接跳過 AI 原型？

有三種情況，我會勸團隊別浪費那半天。

第一，改動很小的既有功能。加一個篩選條件、調一個排序，做原型的時間比工程師直接改還久，而且原型還可能跟現有畫面對不上，反而製造誤會。

第二，主要複雜度在後端的需求。對帳、排程、資料同步這類東西，畫面就三個按鈕，難的全在看不見的地方。這時候該做的是流程圖跟資料流，不是可點擊 demo。

第三，方向根本還沒定。這是最常見的浪費——用 AI 一口氣生五個漂亮版本，結果因為每個都很完整，反而更難砍。方向未定時，紙筆或一張流程圖的殺傷力比高保真原型小，砍起來也不心疼。

反過來說，有一種情況我一定會做：要說服不熟產品的利害關係人時。對非產品背景的人來說，看得到的東西才叫存在。這時候原型的說服力，抵得過十頁文件。

FAQ 常見問題

AI 原型可以直接當規格文件交給工程師嗎？

不建議。原型只描述了「一切正常時長什麼樣」，缺少狀態、資料來源、權限與驗收條件。實務上比較安全的做法是「原型 + 六題交接清單」一起交：原型負責溝通外觀與流程，清單負責溝通邏輯與邊界。少了清單，工程師就得替你猜，而猜錯的返工時間通常遠大於你寫清單的時間。

AI 原型跟 vibe coding 出來的東西，能不能直接改成正式產品？

看它要不要進既有系統。如果是全新的獨立小工具、沒有敏感資料、使用者不多，直接長成正式產品是可行的。但只要牽涉既有帳號、金流、報表或稽核，通常會需要重寫——因為原型是在真空環境長出來的，它不知道你們公司的舊系統有哪些限制。判斷方法很簡單：先數「要接幾個既有系統」，超過兩個就別期待能沿用。

工程師說「這個做不出來」，是真的做不出來，還是不想做？

我的經驗是，九成情況他講的其實是「這個做得出來，但代價你可能不想付」。與其爭論可行性，不如換一個問法：「如果要做，最貴的是哪一塊？有沒有便宜八成的版本？」 這個問法會把對話從立場拉回取捨，通常十分鐘內就能找到雙方都能接受的縮小版。

PM 該不該自己學著用 AI 把原型做到能跑？

該學，但目標要設對。學會做原型的價值不在於「我也能寫程式了」，而在於你會開始感受到哪些需求便宜、哪些昂貴——這種手感會直接改善你的排期跟砍需求能力。真正的分水嶺是：你能不能在做完原型後，誠實說出「這個 demo 沒處理的是哪五件事」。答得出來，你就從展示者升級成判斷者了。

寫在最後：把原型當對話的開始，不是結論

回到開頭那個安靜下來的會議室。我後來慢慢學會，那個沉默不是誰理虧，而是兩邊拿著不同的地圖在對同一個地址。企劃的地圖畫的是使用者怎麼走，工程師的地圖畫的是系統怎麼撐。少了中間那份清單，兩張地圖永遠對不起來。

AI 讓畫地圖變得極便宜，這是好事——但便宜的是畫，不是對。原型從來就不是用來結束討論的，它是用來讓討論提早、吵得具體一點。我自己這幾年最大的轉變，是不再追求「交出去的原型有多完整」，而是追求「交出去之後，對方要問的問題有多少已經被我先回答了」。

如果你也在做這種轉換——從「把東西做出來」變成「把判斷交出去」——那我把這幾年的整套思路寫成了一本書。《AI 產品設計大師》裡談的就是 AI 時代產品人怎麼從需求、原型一路走到落地，包含這篇沒空展開的需求收斂與跨部門對齊那幾塊。想再往下挖的話，可以去看看。

喜歡這類把 PM 日常拆開來講的內容，可以訂閱我的部落格，會不定期收到信。

💡 追劇族延伸閱讀：整天在拆流程與斷層，下班總得讓腦袋放空。想知道 WeTV、愛奇藝、Disney+ 到底該訂哪一個才不會白花錢？我把大陸劇平台在台灣的合法追劇完整評比整理好了，選片單的邏輯跟選工具其實意外地像。

另外兩篇同樣是「AI 到底幫得上什麼忙」的實測：我用 AI Agent 一天把個人網站從定位做到上線，還有AI agent 自己刪檔那幾起真實災難與我的五道防線——後面那篇會讓你更懂工程師為什麼謹慎。

參考資料

• METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• METR — We are Changing our Developer Productivity Experiment Design
• DORA — State of AI-assisted Software Development 2025
• Google — How are developers using AI? Inside Google's 2025 DORA report
• GitClear — AI Copilot Code Quality Research