❯❯ 完結！從開源 Starter Kit 到十一月真實驗收：AI 規格流水線的終點與新起點
📍 流水線位置｜入口 → flow → 型別 → mock → 測試 → UI → vibe → 上線（終點，也是你的起點）
30 天前，Day 01 給自己立過驗收標準：如果寫到最後只留下一份個人流程展示，那這個系列就算失敗。今天正式交貨，不只公開完整的婚禮實戰專案，也把抽離業務邏輯後的自動化模板整包打包好！
這 30 天跑下來，背後支撐整套架構的想法其實就四件事：
1. 規格就是單一真理來源： 透過測試把它實體化，變成可執行的合約。
2. UI 怎麼彈性調整都可以： 但約束條件就在那，絕對不能跨過業務邏輯的底線。
3. 工程師負責情境判斷與劃定邊界： AI 則發揮它的強項，幫你高效率執行與翻譯。
4. 所有自動化機制： 說穿了，都只是為了強迫自己把「先想清楚再動手」當成預設動作。
系列裡聊過的雙軌入口、凍結機制、Gate 門禁閘門、Vibe 治理與單變數部署，都是為了把這四條原則落地成每天開工時自動運轉的流程。
當初承諾的三樣東西，今天一次結清：
婚禮專案的開源儲存庫已全數公開：PinyiW0/wedding-host。這不是為了寫文章特地做的 Demo 專案，而是這 30 天下來的所有實體資產：55 個 feature 規格檔、19 份 flow 架構圖、325 條 E2E 測試案例、18 個 .claude/skills/ 腳本、gate 自動化配置以及部署腳本。文章裡提過的每個 issue 和 commit，都可以在裡面找到紀錄。
至於 Claude Code 的日常操作 SOP（怎麼派工、什麼時候該停下來問人、改完怎麼驗、踩雷紀錄要寫回哪裡），我整理成了六份檔放進模板 Repo 的 .claude/ops/ 裡面。雖然正文沒獨立開篇講，但 README 都寫了導覽。
如果你或你的團隊想導入，不需要硬生生把 30 天文章讀完，建議直接照著適合你的痛點切入：
| 目前開發痛點 / 專案型態 | 建議切入章節 | 首波導入模組 |
|---|---|---|
| 前端開發頻繁等待後端 API | Day 10–11 | 介面合約型別＋Mock Server＋Typed Client（可獨立運作，短期顯現效益） |
| 想用 AI 協作，但又怕它亂改寫出 Bug | Day 14、Day 20 | 凍結的測試合約＋自動化 Gate 門禁（透過客觀驗證機制約束 AI 邊界） |
| 輕量專案，怕導入成本太高 | Day 29 | 僅採行前半段流程（規格 → 測試 → UI），避免過度治理的固定成本 |
最快的 4 步上手方式：
.claude/skills/（流程 SOP）與 spec/（規格入口）兩個目錄的結構搬進你的專案，這就是整條流水線的地基。.feature 檔，跑一次 /feature-to-flow，看第一份 flow 檔長出來，再決定要不要往下接型別、mock 與測試。.claude/skills/ 下的腳本均為純文字 SOP，翻譯成你手上工具的 prompt 或腳本即可。💡 小提醒：
這套流程是個邏輯容器而非死板模板，大家引入時一定要順著自己團隊的習慣與技術棧做彈性微調。
這套做法絕非終點，在實際運作時，我也發現了幾個很值得繼續攻克的課題：
團隊協作權限：
多人在同一專案協作時，規格凍結與覆寫權限到底該怎麼分配才不會亂？
複雜模組的知識庫化：
遇到複雜技術題（例如 SSE），目前是先靠 vibe 逃生門試錯，把經驗沉澱成 reference 知識庫，或者說自己的 domain context 知識庫，然後再讓 Agent 讀取。下一步我想把「知識庫先行」直接固定成流程裡的一環。
Skill 知識的時效性：
封裝在 Skill 裡的框架語法會過時。當框架改版時，如何讓 Skill 自動即時同步，避免 AI 用舊語法寫出看似正確但跑不動的程式碼。
我從來不覺得世界上有一套能放諸四海皆準的「萬能開發架構」。不論是早期三人小團隊的開發節奏、專職編寫 skill 的模式，或是開源架構的逐頁確認，只要適合當下的情境就是好方法。這 30 天展現的，不過是我在「單人開發、有嚴格交付期限、且未來要長期維護」這組約束下，所找出的當前最佳解。
專案開發條件會變，工具與團隊架構也會迭代。本系列最終交付的並非一套固定答案，而是這個習慣：先找出當下最適合的做法，並在環境改變時，有勇氣隨時回頭修正它。
所以這個 repo 不會停在今天的版本，它會跟著我之後的專案一起改。第一個想動的是「測試分級」：現在 pre-push 只要有檔案變動就全跑合約，一趟要花 5 到 6 分鐘，改個元件也全跑實在太重了，也很耗 token，加上現在模型越來越來厲害，有些設定我覺得也可以不用像之前一樣寫的那麼詳細，反而過多限制。目前我會確保合約品質不降級，但會再優化測試層級和順序。所以你現在 clone 到的只是當下的快照，不是最終定案。後續有做出來更好的版本，我會分享在我的技術部落格。
還記得 Day 01 丟給自己的那顆紅色炸彈嗎？十一月，它就要在真實世界裡炸開了！
30 天的文章雖然寫完了，但這套系統最重要的終極驗收才正要開始。接下來這段時間，我要用一個開發者最害怕、也最逃不掉的身份來測試它——甲方本人。座位圖要排的是我真實的親友，報到台要面對的是我真實的婚禮現場。這是最誠實、也最毫無退路的實戰測試。
說起來，這套 Workflow 一開始其實既不是為了婚禮，也不是為了寫文章。當初只是因為在公司裡跨部門規格老是跟其他人對不齊，急著想找個方法讓大家看著同一份真相溝通，才開始摸索 AI 流水線。一塊一塊試、一步一步接，某天回頭看，才發現它已經從輕量解決方法默默長成了一整套架構。
兩年前剛轉職做前端時，我每天都是看著各路前輩的文章苦讀，那時心裡常想：真的好厲害啊～！希望哪天自己也能寫出一篇能幫助別人的文章，年初定了目標今年要寫 20 篇，沒想到會在鐵人賽在這裡達成目標！還一口氣連寫了 30 篇，甚至最後要用它來接住自己的婚禮。
這條流水線挑戰到這裡劃下句點，程式碼全數過關、CI/CD Gate 也順利亮起綠燈。
接下來，我要暫時切換身份，去準備人生中最重要的一次「正式上線（PROD）」了！
祝福我們的婚禮零 Bug 圓滿落幕，也祝大家的 Code 都順利 Run 起來。
雖然這個系列結束了，但我對前端架構與 AI 協作的探索不會停下。之後我會繼續把實戰心得與技術沉澱整理在我的 Medium 部落格，歡迎大家追蹤交流！
謝謝你陪我走完這 30 天，我們下個圈子見！ ✨
📎 本篇證據｜wedding-host・Nuxt4-template-SDD・.claude/skills/・本系列全部 issue／commit 引用可回溯查證
iThome鐵人賽
看影片追技術