❯❯ ROI 結帳：3 人×3 月 vs 1 人×1 月，以及時間真正的流向

📍 流水線位置｜入口 → flow → 型別 → mock → 測試 → UI → vibe → 上線（結帳）

前面講了 27 天的方法論，今天我們來把效益好好量化、算一次總帳。
先把三個專案的基礎資料整理如下：

標題那句「省下的四分之三」，指的是對照一期與後續兩個專案的整體投入。這個數字不是從上表某一格直接算出來的：單比時程，一季到一個月是縮短約三分之二；若換算人月（3 人×約 3 個月對上 1 人×1 個月），省下的又遠超過四分之三。取「四分之三」，是把時程、人力與範疇差異放在一起衡量後，比較保守的一種講法。

這個數據對比的前提與侷限

不過，直接拿這幾組數據對照並不完全公平，有幾個變數需要先釐清。

首先，二期並非完全從零開始，它是建立在一期的領域知識上，我對業務邏輯已經相當熟悉；同時二期的需求範疇也不等同於將一期完整重寫。至於婚禮專案，雖然是全新開發，但因為需求完全屬於我自己，省去了大量跨角色溝通與確認的成本。因此「四分之三」並非嚴謹的實驗室對照結果，而是我個人跨三個專案後的體感估算。儘管它不能作為精確的統計數字，但產能大幅提升的方向是確定的。

另一方面，這套流程本身也有建置成本。撰寫 skill、調整規範、釐清邊界情況都是前置投入。以 Day 17 介紹過的 /feature-to-ui 這支 skill 為例，主文包含 185 行，詳細規則則延伸了 2966 行。婚禮專案能跑出 4 週交付的飆速，正是因為基礎設施已經全部建立好。

至於每個模組燒了多少 Token、回了幾輪 Prompt？這筆帳我拿不出來。開發當下沒有留這些紀錄，事後也不想硬湊一個數字，所以我能給的是上面那些查得到的結構數字。比起這些計費數字，我更有感的是：真正貴的從來不是 Token，而是規格沒想明白、帶領 AI 走彎路重跑的折磨。

省下的時間去哪了？

比起開發速度的提升，這套流程更根本的改變，是時間結構的重組。

過去傳統開發，九成時間都在埋頭寫 Code，需求與規格只能邊寫邊猜。規格沒梳理清楚就急著開工，後續改需求、重構所浪費的時間，往往是當初的數倍。

導入流程後，寫程式碼的邊際成本被極致壓縮。大部分的時間轉而投入在：

- 動手前把需求問清楚
- 把規格與介面合約定義穩定
- 跨職能對齊概念與邊界

當前期規格越明確，AI 工具執行的準確度就越高，後續修改的頻率隨之下降，進一步釋放出更多時間。

以 Day 12 的契約健檢為例，當時我不急著開發新功能，而是專注於將前端 mock API 的寫入與讀取邏輯進行全面交叉對帳。過程中發現了 7 個「資料寫入後並未真正保存」的隱性缺陷。那時候畫面因為前端 local state 的掩護看起來一切正常，但只要重新整理資料就會丟失，連 94 支 e2e 測試也未能察覺。如果照舊有的節奏趕進度，這些未爆彈保證一路藏到正式上線才炸開。

自動化流程將工程師的工作重心拉向了上游。省下來的時間，最終都轉化為「在動手前先把問題想清楚」的思考成本。產出的功能數量很容易被視覺化，但前期把需求定義正確所帶來的隱性價值，才是決定專案能否穩定運行的關鍵。

如何向團隊推薦這套模式？

如果你考慮在團隊中導入類似的模式，比起強調「能節省多少時間」，不如先觀察團隊目前的日常時間分配：大家現在大概花多少比例的時間，在動手前把「確定要做什麼」這件事徹底定義清楚？

如果這個比例偏低，代表專案現在每天都在用「重構」跟「改需求」來填補前期規格的不明確成本。這套流程的真正價值，不是單純追求 AI 生成程式碼的速度，而是透過機制把「想清楚再動手」設為預設路徑。在沒有定義 flow 前就無法產生型別，沒有型別就建立不出 mock。它透過流水線的限制，強迫開發過程必須先經歷思考。

這筆效益帳整理到這裡。有了數據作為參考後，更需要留意流程適用範圍的邊界。明天會接續討論：在哪些情境與架構下，這套流程並不適用。

🎒 最小一步｜記錄你這週「確定要做什麼」和「動手做」的時間比。那個比例，就是這整個系列想幫你翻轉的東西。
📎 本篇證據｜一期 commit 密度（2025-07~09 密集期）・二期 v1.0.0 發版紀錄（皆屬公司案，涉保密不附連結）・wedding-host git log（6/20 起四週）