# 估 AI prototype 的時程要拆兩段：從零到可展示，從可展示到上線 > AI 讓 prototype 從零到可展示便宜了很多，驗證、併發、金流處理與可觀測性的成本卻沒降那麼多。估時程和報價時，我會把可展示與可上線拆開算，後半段照過去上線的經驗估，不打 AI 折扣。 原文：https://sheng.page/posts/ai-prototype-to-production-cost/ · 發布：2026-10-22 · 作者：Sheng 用 AI 做 prototype，前半段快得有點不真實。大約一週就能交出一輪可操作的 prototype，連同概念樣板和 RWD 版面，複雜一點的專案 AI 費用約 200 美元，不含我自己的時間。後半段就沒這麼快了，權限、併發、扣款與退款流程、測試和可觀測性都得處理，prototype 才能上線。這些工作 AI 一樣幫得上忙，成本卻沒有跟著前半段一起掉下來。 估 prototype 的時程和報價，我會把「從零到可展示」和「從可展示到可上線」拆成兩段。前一段照 AI 工作流程實際的節奏報，後一段照過去把系統送上線的經驗報，不打 AI 折扣，驗證工作也逐項寫進去。 ## 一、前半段：一週一個交付 我現在的 prototype 流程大概是這樣： ```text Claude Design 概念樣板，先對齊方向和視覺 Google Stitch RWD 版面 SvelteKit 可以操作的原型 Claude Code 把原型轉成 Nuxt 自己 review 讀過一遍再交付 ``` prototype 選 SvelteKit，主要是 Svelte 5 的 runes 把狀態和衍生值寫得很明確，`$state`、`$derived`、`$effect` 各自是什麼一看就知道。就我的使用經驗，AI 產生的程式也比較穩定，少了很多「這個變數改了到底會不會觸發更新」的猜測，細節寫在〈[Svelte 5 的 runes：把響應式攤在桌上](/posts/svelte-5-runes-explicit-reactivity/)〉。 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、誤報和人的時間](/posts/ai-code-review-cost-benefit/)〉，這裡不重複。 有一部分扣款與退款的問題，要到 e2e 和整合測試才發現。我接上真的 PostgreSQL，起一個假的對方伺服器，再加上故障注入，讓對方逾時、回錯誤、重複回應，看扣款、退款和對帳在這些情況下還對不對。 當時寫的故障情境大概是這幾種：派彩和查詢狀態兩個 callback 都逾時，round 會停在 pending，之後背景 worker 用同一個 transaction id 重送，重送幾次最後都只能算一筆；e2e 跑到一半直接 kill 服務，重新啟動後要能從中斷點接著做；快取斷線時，kill switch 要 fail-closed，不能因為讀不到設定就放行。 e2e 本身也會騙人。同一秒內送出 body 和 path 都相同的請求，會撞上防重放的 nonce 檢查，看起來像程式壞了，其實是測試寫法的問題。示範用的 slot 遊戲結果是隨機的，e2e 也曾偶爾失敗，後來改成測試環境可以重播的 seed 才穩定下來，做法寫在〈[遊戲 RNG 正式環境要猜不到、測試要能重播：在 Go 裡把兩件事切開](/posts/rng-unpredictable-in-prod-replayable-in-tests/)〉。 單元測試的 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 工具鏈的厭世日記](/posts/it-builds-is-not-well-designed/)〉講的是同一件事：能跑、測試通過，只代表目前執行的測試沒有驗出失敗，設計合不合理還得另外看。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 的第一次實驗顯示體感速度和實測可能差很多，後續實驗還無法可靠估計加速幅度，不要用前半段的速度推估後半段。 - 報價拆兩段，第二段照過去上線的經驗估，並逐項寫明。 ## 延伸閱讀 - METR〈[Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)〉：2025 年 7 月的隨機對照實驗，完成時間增加 19% 與事前、事後預估的原始數字，頁首已標註結果過時並連到後續實驗。 - Joel Becker 等人〈[Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://arxiv.org/abs/2507.09089)〉：同一研究的論文版，含研究設計與經濟、ML 專家的預測。 - METR〈[We are Changing our Developer Productivity Experiment Design](https://metr.org/blog/2026-02-24-uplift-update/)〉：2026 年 2 月的後續實驗，57 位開發者的結果、信賴區間，以及 METR 認為資料不可靠的理由。 - Dimitri Mazmanov〈[Portal by Spotify cut my Claude Code token usage by 90%](https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90)〉：用較小的模型替 Claude Code 處理大量讀檔，量測方式，以及哪些工作沒辦法交出去。 > 想法與技術判斷出自 Sheng，和 Claude 一起起草 · 估算表為示意，無實測數字。