❯❯從 22 Commits 極簡小案到 Full-Stack SaaS：三大專案的 AI SDD 流程裁剪與「逃生門」實戰

📍 流水線位置｜入口 → flow → 型別 → mock → 測試 → UI → vibe → 上線（跨專案回望）

一套 Workflow 如果只在單一專案上跑得動，那很可能只是運氣好、剛好湊巧適合而已。這個系列雖然用婚禮專案當主線，但這套 AI SDD 管線，最早是在三個規模與型態完全不同的專案裡，一步步磨出來的。

把這三個專案拉出來對照，最能最直觀地展現這套流程在不同情境下的靈活性與真實限制。

公司的運動影像專案：流程的出生地

這套 workflow 的第一版，是在公司的運動科技專案二期建立起來的。基於業務保密，這裡僅討論影響流程設計的關鍵特徵與規模數據。

這個專案具備兩個主要特徵：

1. 獨立後端團隊：邊界由外部控制
API 規格由後端主導維護與更新。Day 05 的「api-spec 優先」與 Day 13 的 Sync 模式，都是為了應對「規格由外部控制」的場景而設計，Day 13 的 sync 實測也是在此專案執行。相反地，在自己包辦前後端的婚禮專案裡，就不需要這套高成本的協調機制。

2. 包含串流與 SSE：高不確定性技術題
這類需求的特徵是前期規格難以一次到位，需要透過實際嘗試來摸索邊界。如果硬要把這種不確定性高的新功能塞進「規格 → 測試 → 實作」的標準流程，開發一定會嚴重卡關。因此這部分採用 vibe 模式：先手動嘗試並確定行為穩定，再透過 vibe 測試將行為固定下來。

當時的直播模組即採用這種模式開發：主體功能 3 天內搞定、2 天後隨 v1.0.0 發布，3 週後再補上瀏覽器相容性的修正。規格先行的節奏無法支援這種調整速度，但 vibe 模式可以，前提是最後必須補上測試以鎖定行為。

換句話說，vibe 在這裡多了一個身分：它是主流程旁邊的「逃生門」，規格暫時定不下來的題目先從這裡繞出去做，做穩了再補測收編。主流程處理標準需求，逃生門處理不確定性需求，這個雙軌設計就是在此專案中調整出來的。

在開發規模與效益對比上：

• 專案一期： 三人團隊、傳統模式開發，共計 108 個 Commit。
• 專案二期： 由我一人獨立承接（含 UI 設計），導入這套流程初版後，在一個月內高效交付 17 個 Squash PR 與 5 大模組。

晴天娃娃：小到流程比產品重

光譜的另一端是 Day 02 提及的晴天娃娃，這是一個開發時程僅 6 個工作天、共 22 個 commit 的小型專案。

這小專案直接撞上了流程的天花板：業務邏輯明明超簡單，卻要硬走定義 Flow、建合約、凍結 Spec 一整套，管理成本根本划不來。當時測 OpenSpec 覺得繁瑣，說白了就是流程強度開過頭，開銷比開發收益還大。

這種小案子最務實的做法，就是只留「規格 → 測試 → UI」前半段核心，能確定功能沒寫爛就好。至於 Vibe 治理、Sync 機制還有自動化 CI/CD 管線？全部砍掉，沒必要為了走完流程而走流程。

婚禮 SaaS：完整 workflow 的實戰戰場

婚禮專案是「單人 Full-Stack、長期維護、業務邏輯明確」，這正好是這套 AI SDD 管線最能發揮戰力的場景！所以這裡沒有任何裁剪，雙軌入口、凍結 Spec、Vibe 治理到單變數部署，全套模組直上。

直接看數字：55 個 feature 檔收斂成 19 條 flow 與 114 支 endpoint 檔；29 個前端頁面被 325 條 E2E 測試精準鎖死；上線前 4 週整整跑了 250 多個 commit。管線裡的每一個 stage 都有明確交付，沒有一步是在做白工。

三大專案對照表

說到底，這套流程絕不是什麼通用的銀彈，能不能隨專案規模彈性剪裁，才是工程師真正的功力。

看完適用場景，明天我們來算算現實的：這套 AI SDD 管線，到底幫我省下了多少時間跟人力成本？

📎 本篇證據｜PinyiW0/TeruTeru（晴天娃娃，公開，openspec/ 目錄可查）・公司案涉保密不附連結（時程與規模屬口述層級）・wedding-host（公開：55 feature／19 flow／114 端點／325 條 e2e 皆可對 repo 清點）