估 AI prototype 的時程要拆兩段：從零到可展示，從可展示到上線

用 AI 做 prototype，前半段快得有點不真實。大約一週就能交出一輪可操作的 prototype，連同概念樣板和 RWD 版面，複雜一點的專案 AI 費用約 200 美元，不含我自己的時間。後半段就沒這麼快了，權限、併發、扣款與退款流程、測試和可觀測性都得處理，prototype 才能上線。這些工作 AI 一樣幫得上忙，成本卻沒有跟著前半段一起掉下來。

估 prototype 的時程和報價，我會把「從零到可展示」和「從可展示到可上線」拆成兩段。前一段照 AI 工作流程實際的節奏報，後一段照過去把系統送上線的經驗報，不打 AI 折扣，驗證工作也逐項寫進去。

一、前半段：一週一個交付

我現在的 prototype 流程大概是這樣：

Claude Design   概念樣板，先對齊方向和視覺
Google Stitch   RWD 版面
SvelteKit       可以操作的原型
Claude Code     把原型轉成 Nuxt
自己 review     讀過一遍再交付

prototype 選 SvelteKit，主要是 Svelte 5 的 runes 把狀態和衍生值寫得很明確，$state、$derived、$effect 各自是什麼一看就知道。就我的使用經驗，AI 產生的程式也比較穩定，少了很多「這個變數改了到底會不會觸發更新」的猜測，細節寫在〈Svelte 5 的 runes：把響應式攤在桌上〉。

prototype 確認之後，再用 Claude Code 轉成 Nuxt。以前換框架幾乎等於重寫，現在這一步可以排進同一週。

到這裡，畫面、操作流程、假資料和主要的 happy path 都有了，客戶可以直接試用、提出修改意見，對齊需求比看規格書有效得多。這一段大約一週就能交付一輪，複雜專案的 AI 費用也大約 200 美元。

這段便宜了，很容易讓人以為整個專案都按同樣比例變便宜。prototype 能點、畫面完整，看起來像完成了八成，實際上上線需要的工作大多還沒開始。

二、後半段：成本落在驗證

之前做過一個最小化的遊戲商系統 prototype，功能做完、流程能跑之後，我先自己讀過一遍，修掉 6 個 High 等級的問題，分布在權限檢查、請求之間的狀態隔離、併發下的扣款與退款流程、金額檢查，以及比較敏感值的方式。

這 6 個問題在展示時一個都看不出來，demo 走的是 happy path，一次一個請求、金額正常、權限正確，畫面上不會有任何異狀。

修完之後再跑一輪 multi-agent review：46 個 agent 找出 16 個 finding，再讓另一組 agent 逐條反駁，最後剩 4 個成立，全部修掉。清單從 16 條縮到 4 條，要人逐條判斷的項目少了很多，不過被駁回的那 12 條是否真的不成立，還得另外抽查。驗證層的成本效益與漏報風險寫在〈AI code review 的帳怎麼算：找到的 bug、誤報和人的時間〉，這裡不重複。

有一部分扣款與退款的問題，要到 e2e 和整合測試才發現。我接上真的 PostgreSQL，起一個假的對方伺服器，再加上故障注入，讓對方逾時、回錯誤、重複回應，看扣款、退款和對帳在這些情況下還對不對。

當時寫的故障情境大概是這幾種：派彩和查詢狀態兩個 callback 都逾時，round 會停在 pending，之後背景 worker 用同一個 transaction id 重送，重送幾次最後都只能算一筆；e2e 跑到一半直接 kill 服務，重新啟動後要能從中斷點接著做；快取斷線時，kill switch 要 fail-closed，不能因為讀不到設定就放行。

e2e 本身也會騙人。同一秒內送出 body 和 path 都相同的請求，會撞上防重放的 nonce 檢查，看起來像程式壞了，其實是測試寫法的問題。示範用的 slot 遊戲結果是隨機的，e2e 也曾偶爾失敗，後來改成測試環境可以重播的 seed 才穩定下來，做法寫在〈遊戲 RNG 正式環境要猜不到、測試要能重播：在 Go 裡把兩件事切開〉。

單元測試的 mock 也能模擬逾時和錯誤，整合測試則會實際經過資料庫交易和網路呼叫，交易隔離、鎖和重試的時序都是真的。Review 靠讀程式碼推理，測試得讓系統實際跑一遍，兩者找到的問題不太一樣。

這次 prototype 做完之後，成本主要落在這些地方：

驗證要做人工 review、multi-agent review、e2e 與整合測試，每一層的結果都得有人判斷。
併發下的 race condition，還有重送和狀態轉移，demo 一次只送一個請求，通常不會刻意測到。
金流處理要顧上限、idempotency、退款和對帳，錯一次的代價遠大於多寫幾個測試。
可觀測性需要 log、metrics、trace，出事時才知道是哪一筆、在哪一步。
資料量和架構語意也得檢查，prototype 的假資料只有幾十筆，全表掃描完全感覺不到；AI 分批產生的模組，命名和語意也未必一致。

很多 review 意見和測試由 AI 產生，測試也交給 AI 執行，這一段它確實幫得上忙。但 finding 成不成立、測試失敗是程式錯還是測試錯，最後都要人判斷，這部分的時間沒有縮短多少。

三、AI 寫程式傾向加法

請 AI 修一個問題，它比較常繼續加判斷或 helper，讓包裝越疊越多，很少主動刪掉什麼或合併重複的邏輯。LLM 產出程式碼很快，該怎麼抽象卻未必有節制，這也是後半段貴的原因。

prototype 階段問題不大，能動就好，到了要上線的階段，新增的程式碼都得納入測試與上線後的監控。AI coding workflow 裡得留一些刪除與簡化程式碼的機會，像是功能合併之前設一道 refactor gate，先檢查有沒有可以刪除或合併的程式碼。

重複檢查也得定期做，AI 很容易在不同檔案寫出幾乎一樣的函式，要找出來合併。複雜度預算則是給模組或函式設上限，超過了先重構，再繼續加功能。

我自己做取捨的順序是 Security > Simplicity > Correctness > Performance，偏好用比較少的程式碼完成需求，能刪的先刪。這和〈能 build 不等於設計合理：JS 工具鏈的厭世日記〉講的是同一件事：能跑、測試通過，只代表目前執行的測試沒有驗出失敗，設計合不合理還得另外看。AI 讓「能跑」變得很便宜，這個差距也就更容易被忽略。

四、體感上的快不可靠

估時程也不能只憑感覺，自己覺得用 AI 變快了多少，未必等於實際快了多少。

METR 在 2025 年 7 月發表一個隨機對照實驗，找了 16 位資深開源開發者，在他們平均已經參與 5 年的成熟專案上完成 246 個任務。開始前，開發者預期 AI 能讓完成時間減少 24%；實驗結束後，他們自評 AI 讓時間減少了 20%；實際量到的是允許使用 AI 時，完成時間增加了 19%。

2026 年 2 月 24 日，METR 公布後續實驗：57 位開發者、800 多個任務。METR 對原參與者的估計寫成「speedup of -18%」，信賴區間 -38% 到 +9%，新招募的參與者是 -4%，信賴區間 -15% 到 +9%，兩個區間都跨過零。原文沒有另外定義正負號，前一次實驗用正值表示耗時增加，照同樣寫法，負值是耗時減少。METR 自己的說法是看得到一些加速的跡象，但證據很弱。

METR 也說這次的資料是 unreliable signal，原因之一是 30% 到 50% 的開發者表示，他們會選擇不提交某些任務，因為不想在不能用 AI 的情況下做。METR 認為這個估計比較可能是真實效果的下限，原研究頁面的頁首現在寫著「These results are out of date」，並連到這篇更新。

後續實驗受到樣本選擇偏差影響，還無法可靠估計加速幅度；第一次實驗裡，開發者事後自評的完成時間變化和實測差了將近 40 個百分點。成熟專案裡的工作，比較接近 prototype 的後半段，要顧既有架構、測試和別人的程式碼，用前半段的體感速度去推估後半段，風險就更大。

五、報價拆兩段

報價時，我會把兩段分開列，下表是示意：

階段	產出	主要成本	估法
從零到可展示	概念樣板、RWD 版面、可操作的 prototype	AI 費用、需求來回	照 AI 流程實際的節奏
從可展示到可上線	權限、併發、金流處理、測試、可觀測性	人判斷與驗證的時間	照過去上線的經驗，不打 AI 折扣

第二段要逐項寫進報價，讓對方知道 prototype 能點不代表接近完成。如果客戶只要第一段，例如拿 prototype 去募資或做內部提案，就照第一段報，清楚寫明系統還不能上線，日後要上線再另外估第二段。

模型分工可以省下一部分 AI 費用。Spotify 工程部落格今年 9 月有一篇文章，在 Claude Code 前面放一個較小的模型處理大量讀檔。作者在一個 Java monorepo 上跑了四個情境，比較 Claude 自己動手和改用小模型摘要或代寫時所需的 token，其中 bulk read 平均省了約 90%。算的是 Claude 端的 token，文中沒有交代小模型本身的用量。

同一篇也提到，推理和編輯沒辦法交給小模型，在作者的測試裡，小模型漏掉了一個 Claude 抓到的執行緒安全問題。這個案例省的是讀檔的 token，判斷對錯的工作還是得留給能可靠完成的模型，最後也還要有人看。

補充筆記

「從零到可展示」現在大約一週一輪，複雜專案的 AI 費用約 200 美元，這一段的成本確實降了很多。
prototype 之後的成本落在驗證、併發、金流處理、可觀測性與架構語意，6 個 High 等級問題在 demo 時一個都看不出來。
Multi-agent review 把 16 個 finding 篩到 4 個成立；有些扣款與退款問題，得接真資料庫、假對方伺服器，加上故障注入才測得出來。
AI 寫程式傾向加法，refactor gate、重複檢查和複雜度預算都得放進流程，留時間刪除與簡化程式碼。
METR 的第一次實驗顯示體感速度和實測可能差很多，後續實驗還無法可靠估計加速幅度，不要用前半段的速度推估後半段。
報價拆兩段，第二段照過去上線的經驗估，並逐項寫明。