AI Team 部分驗證
此流程的群體精煉（Mob Elaboration）方法已在部分專案中試驗。多層級規格管理已整合至現有工作流程。
功能開發流程
本文件描述功能開發的完整流程，說明 AI-DLC (AI-Driven Development Life Cycle) 的群體精煉如何整合到工作流程框架中的多層級規格管理體系。
前期收斂階段
在進入規格細化之前，必須先經過前期收斂階段。這是整個流程中人類貢獻智慧最多、最密集的地方。
| 階段 | 說明 | 參與者 |
|---|---|---|
| 收到意圖 | 從業務或產品端收到需求意圖 | PM、業務 |
| 密集討論 | 2-3 天內完成所有關鍵決策的收斂 | 所有利害關係人 |
| 形成提案 | 產出經過規格審查的提案文件 | PM、Tech Lead、設計 |
| 產出規格 | 透過 OpenSpec 產出各類細部規格 | 各職能角色 + AI |
關鍵：前期收斂
整個流程的核心在於前 2-3 天的密集討論。所有可能影響規格的利害關係人必須在此階段完成意見收斂，避免後期變更導致返工。
為什麼前期收斂不使用 AI？
根據 AI-DLC 的定義，前期收斂階段理論上應該有 AI 介入。但實際實驗後發現，AI 在上下文脈絡不夠清楚的情況下，會產出過度延伸的規格。
因此，在這個階段目前仍建議以人類的方式思考規格。這也是整個流程中，人類貢獻智慧最多、最密集的地方。
在這個密集討論意圖與提案的階段，每個人都會成為這個產品最核心的設計人員，每個人都跟產品息息相關。
與工作流程框架的關係
AI-DLC 群體精煉流程
| 階段 | 說明 | 產出 |
|---|---|---|
| 需求種子 | 經過群體精煉會議的密集討論 | 細化過的初步規格 |
| AI 展開 | 透過 AI 將初步規格展開 | 規範化的規格文件 |
前期收斂產生初步規格（需求種子），再透過 AI 展開轉化為規範化規格文件，經規格審查後形成高階規格，最後進入工作流程框架的多層級規格管理流程。
實務時程範例
以下是一個典型功能開發的逐日時程，展示各角色在不同階段的參與：
時程總覽
逐日詳細說明
| 天數 | 階段 | 活動 | 參與者 | 產出 |
|---|---|---|---|---|
| Day -5~-1 | 會前準備 | PM 撰寫需求種子文件，各角色準備相關資料 | PM, RD, UX, 架構師 | 需求種子、各自的準備資料 |
| Day 0-2 | 群體精煉 | 舉行群體精煉會議，密集討論 | PM, RD, UX, 架構師 | 初步規格（細化過的需求） |
| Day 3 | AI 展開 | AI 將初步規格展開為規範化文件 | AI, RD | 規範化規格文件 |
| Day 4 | 規格歸檔 | 審查並歸檔高階規格 | PM, RD | 版本化的高階規格 |
| Day 5-6 | Web UX 分支 | 產生 Web UX 規格與線框圖 | UX, AI | Web UX 規格、設計符記 |
| Day 5-6 | App UX 分支 | 產生 App UX 規格與線框圖 | UX, AI | App UX 規格、設計符記 |
| Day 5-6 | API 分支 | 產生 API 規格與 OpenAPI | RD, 架構師, AI | OpenAPI 文件 |
| Day 5-6 | 設計分支 | 產生技術設計文件 | 架構師, AI | 架構決策、技術設計 |
| Day 7-9 | Web 前端實作 | 根據 Web UX + API 規格開發 | Web 前端 RD, AI | Web 前端程式碼 |
| Day 7-9 | App 前端實作 | 根據 App UX + API 規格開發 | App 前端 RD, AI | App 前端程式碼 |
| Day 7-9 | 後端實作 | 根據 API + 設計文件開發 | 後端 RD, AI | 後端程式碼 |
| Day 10-11 | 測試驗收 | QA 執行驗收測試 | QA, AI | 測試報告 |
| Day 10 | Code Review | 審查程式碼 | RD, TL | 審查意見、核准 |
| Day 12 | 完成 | 合併至主分支、部署準備 | RD, 維運 | 可部署版本 |
各角色參與時間分布
關鍵里程碑
| 里程碑 | 時間點 | 確認項目 | 負責人 |
|---|---|---|---|
| 需求種子完成 | Day 0 | 業務脈絡、範圍、限制皆已記錄 | PM |
| 高階規格核准 | Day 2 | 所有參與者達成共識、邊界案例已識別 | PM, RD, UX, 架構師 |
| 規格分支完成 | Day 4 | Web UX/App UX/API/設計規格已歸檔 | 各分支負責人 |
| 開發完成 | Day 7 | 程式碼完成、單元測試通過 | RD |
| 驗收完成 | Day 10 | QA 驗收通過、Code Review 核准 | QA, TL |
傳統 SDLC 的問題
順序式知識傳遞
各角色的盲點
| 角色 | 盲點 | 後果 |
|---|---|---|
| PM | 技術限制、API 限制 | 不切實際的需求 |
| RD | UX 影響、用戶旅程缺口 | 糟糕的用戶體驗 |
| UX | 技術可行性、資料可用性 | 無法實現的設計 |
| 架構師 | 業務脈絡、優先順序權衡 | 過度設計的解決方案 |
| 所有人 | 邊界案例、錯誤情境 | 生產環境 Bug |
AI-DLC 解決方案：群體精煉
核心洞察： 當多元觀點同時挑戰假設時，需求品質會顯著提升。AI 增加了一個不知疲倦的參與者，能夠即時發現邊界案例、檢查一致性並維護完整的文件。
目標狀態
階段一：會前準備
需求種子
在群體精煉會議前，PM 準備需求種子文件：
## 需求種子：[功能名稱]
### 業務脈絡
- 為什麼是現在？
- 誰提出的需求？
- 解決什麼問題？
### 初始範圍
- 必須有：[核心功能]
- 最好有：[加分功能]
- 不在範圍內：[明確排除]
### 已知限制
- 時程：
- 預算：
- 技術：
### 成功指標
- [可量化的成功標準]參與者準備
| 角色 | 會前準備 |
|---|---|
| PM | 準備需求種子、業務脈絡 |
| RD | 熟悉相關程式碼、技術限制 |
| UX | 準備用戶旅程、競品參考 |
| 架構師 | 評估系統影響、現有架構 |
| AI 代理 | 載入 CLAUDE.md、現有規格、API 文件 |
階段二：群體精煉會議
會議流程
人類在會議中的角色
群體精煉會議是人類貢獻智慧最密集的地方。每個角色帶來獨特的視角：
| 角色 | 職責 | 貢獻 |
|---|---|---|
| PM | 業務脈絡守護者 | 確保需求對齊業務目標、釐清優先順序 |
| RD | 技術可行性把關 | 評估技術限制、提出替代方案 |
| UX | 用戶體驗倡導者 | 確保用戶旅程完整、識別體驗痛點 |
| 架構師 | 系統完整性守護 | 評估架構影響、確保一致性 |
為什麼強調人類角色？
在這個密集討論意圖與提案的階段，每個人都會成為這個產品最核心的設計人員，每個人都跟產品息息相關。
AI 在此階段僅作為輔助記錄與整理，不參與決策。所有關鍵決策都由人類做出。
階段三：規格分支
群體精煉產出高階規格後，進入工作流程框架的多層級規格管理：
各分支的標準工作流程
每個分支遵循接收 → 結合 → 委派 → 審查 → 精煉 → 歸檔模式：
| 分支 | 接收 | 結合 | 委派 |
|---|---|---|---|
| Web UX | 高階規格 | Web 設計系統、品牌指南 | AI 產生 Web UX 規格草稿 |
| App UX | 高階規格 | App 設計系統、平台規範 | AI 產生 App UX 規格草稿 |
| API | 高階規格 | API 設計原則 | AI 產生 OpenAPI 草稿 |
| 設計 | 高階規格 | 架構原則、技術棧 | AI 產生設計文件草稿 |
| 後端 | API 規格 + 設計文件 | 程式碼規範 | AI 輔助實作 |
| Web 前端 | Web UX 規格 + API 規格 | Web 設計系統元件 | AI 輔助實作 |
| App 前端 | App UX 規格 + API 規格 | App 設計系統元件 | AI 輔助實作 |
| QA | 所有規格 | 測試策略 | AI 產生測試案例 |
階段四：AI 輔助實作
開發迴圈
AI 代理的開發協助
| 任務 | AI 可協助 | AI 不應做 |
|---|---|---|
| 撰寫程式碼 | 根據規格產生初稿 | 自行決定架構方向 |
| 除錯 | 分析錯誤訊息、建議修復 | 忽略根本原因 |
| 重構 | 依指示改善程式碼結構 | 大幅改變設計 |
| 測試 | 產生測試案例 | 跳過測試直接標記完成 |
階段五：審查與驗收
Code Review 流程
Review 重點
| 面向 | 檢查項目 |
|---|---|
| 規格對齊 | 是否符合群體精煉產出的規格？ |
| 邊界案例 | 是否處理了規格中列出的邊界案例？ |
| 正確性 | 邏輯是否正確？ |
| 安全性 | 有無注入風險？權限檢查是否完整？ |
QA 驗收
驗收測試來源直接來自群體精煉產出：
完成定義 (Definition of Done)
| 類別 | 條件 |
|---|---|
| 規格 | 群體精煉規格中所有驗收條件已滿足 |
| 程式碼 | 已合併至主分支、CI 全綠 |
| 測試 | 單元/整合/E2E 測試通過，邊界案例已覆蓋 |
| 審查 | Code Review 核准 |
| 驗收 | QA 驗收通過 |
| 文件 | 必要文件已更新、歸檔至版本控制 |
適用情境
完整群體精煉適用於
- 有多個利害關係人的新功能
- 跨多個系統的功能
- 高風險或高能見度的功能
- 需求不明確的功能
輕量版流程
對於定義明確的小型功能，可使用：
- 迷你精煉：PM + RD + AI（30 分鐘）
- 直接委派：PM 撰寫需求種子，AI 產生規格草稿，RD 審查
常見問題
「2-3 天密集討論」是指所有人連續開會 2-3 天嗎？
不是。 「2-3 天」是指決策收斂的時間窗口，而非連續會議時間。實際運作方式：
| 活動 | 時間 | 形式 |
|---|---|---|
| 會前準備 | Day -5 ~ -1 | 非同步，各自準備 |
| 群體精煉會議 | Day 0 | 同步，2-4 小時 |
| 非同步精煉 | Day 0-2 | 非同步，文件評論、Slack 討論 |
| 最終收斂會議 | Day 2 | 同步，1-2 小時 |
核心同步時間約 4-6 小時，分散在 2-3 天內。
利害關係人分散在不同時區怎麼辦？
混合同步/非同步模式：
- 識別時區重疊窗口：找出所有關鍵參與者都能參加的 2-3 小時時段
- 非同步優先討論：在會前透過文件收集各方意見與關注點
- 錄影補充：同步會議錄影，讓無法參加的人補看並書面補充意見
- 分段會議：若完全無重疊時段，考慮拆成兩場會議，由 PM 作為橋樑
關鍵：確保每位關鍵決策者都有機會在決策定案前表達意見。
關鍵角色（如法務、資安）只能參加 2 小時怎麼辦？
專家時段規劃：
| 策略 | 做法 |
|---|---|
| 預先書面輸入 | 會前發送聚焦問卷，收集該領域的關鍵限制與考量 |
| 專屬時段 | 在會議中保留專屬 30-60 分鐘給關鍵專家 |
| 代理出席 | 指定團隊中熟悉該領域的人作為會議代理，會後與專家確認 |
| 會後審查 | 預留 24-48 小時給專家審查初步規格並提出異議 |
實務建議：
- 法務、資安等專業角色通常關注特定面向，不需要全程參與
- 事先準備「給專家的摘要文件」聚焦其關注領域
- 明確告知會議中會決定的事項，讓專家知道哪些需要他們輸入
「來不及參與但有否決權」的角色如何處理？
分層決策權機制：
具體做法：
- 會前預對齊：在群體精煉前，由 PM 個別與否決權角色進行 30 分鐘預對齊
- 明確授權：取得「在 X 條件下可以先進行」的有條件授權
- 保留審查窗口：規格產出後給予 24-48 小時異議期
- 升級機制：若異議期後才有反對意見，需要走變更管理流程
警示：如果某個有否決權的角色連 30 分鐘預對齊都無法安排，這通常是組織問題而非流程問題。應向上反映協調。
現實中很難讓所有人同時空出時間，有什麼替代方案？
務實的替代策略：
| 情況 | 替代方案 |
|---|---|
| 只有 2-3 人能同時到 | 使用迷你精煉 + 非同步審查循環 |
| 核心成員完全無法同步 | 純非同步精煉（需延長至 5-7 天） |
| 緊急功能無法等 | 限縮範圍，先做 MVP 版本的群體精煉 |
非同步群體精煉流程：
注意：非同步模式會顯著增加溝通成本和收斂時間。建議僅在不得已時使用，並在事後安排 30 分鐘同步會議做最終確認。
如何判斷哪些功能需要完整群體精煉、哪些可以簡化？
決策矩陣：
| 條件 | 完整群體精煉 | 迷你精煉 | 直接委派 |
|---|---|---|---|
| 利害關係人 | ≥ 4 人/部門 | 2-3 人 | 1 人（PM 即可決定） |
| 跨系統影響 | ≥ 3 系統 | 1-2 系統 | 單一系統內 |
| 不確定性 | 需求模糊、多種可能 | 大致清楚、少量待確認 | 完全清楚 |
| 風險等級 | 高（影響營收、安全、合規） | 中 | 低 |
| 預估工時 | ≥ 2 週 | 3-10 天 | ≤ 3 天 |
經驗法則：
- 若你無法在 5 分鐘內向 RD 說清楚要做什麼，就需要至少迷你精煉
- 若有任何人說「這個我們得問一下 XX」，就需要把 XX 拉進來
- 若答案是「看情況」多於「確定是 X」，就需要更完整的精煉
「避免後期變更」是指功能永遠不能改嗎？
不是。 「避免後期變更」指的是在單次功能開發週期內，應以定案會議的決策為主。這不是說功能永遠不能演進。
正確理解：
| 時機 | 建議做法 |
|---|---|
| 週期內 | 遵守定案決策，避免中途推翻 |
| 發布後 | 收集回饋，納入下次週期規劃 |
| 緊急情況 | 走緊急變更流程（見下方） |
為什麼週期內要穩定？
- AI 已根據規格開始執行，中途變更造成大量返工
- 團隊已分配資源，變更影響其他排程
- 頻繁變更會摧毀「前期收斂」的價值
市場情況真的變了（如競爭對手發布新功能），怎麼處理？
先問三個問題：
- 緊急程度：這個變化是否影響本次發布的核心價值？
- 範圍影響：調整是否會影響超過 30% 的已規劃工作？
- 時間餘裕：距離原定發布還有多少時間？
決策矩陣：
| 情況 | 建議做法 |
|---|---|
| 不影響核心價值 | 記錄下來，納入下個週期 |
| 影響核心但範圍小（< 30%） | 召開迷你精煉調整 |
| 影響核心且範圍大（≥ 30%） | 考慮暫停當前週期，重新定案 |
實務建議：
大多數「市場變化」沒有想像中緊急。問自己：
「如果我們晚兩週回應，會發生什麼？」
如果答案是「其實影響不大」，就放到下個週期。
法規變更、安全漏洞等不可抗力情況的流程是什麼？
不可抗力變更流程：
不可抗力類型與對應方式：
| 類型 | 範例 | 處理方式 |
|---|---|---|
| 阻斷性法規 | GDPR 生效前必須合規 | 暫停功能開發，全力處理合規 |
| 安全漏洞 | CVE 高危漏洞 | 獨立緊急修復分支，不混入功能開發 |
| 第三方 API 變更 | 供應商 API 廢棄 | 評估影響範圍，決定是否暫停或平行處理 |
| 硬體/基礎設施 | 雲端服務商停止支援 | 納入技術債處理，通常不影響功能開發 |
關鍵原則：不可抗力變更應該獨立追蹤，不要混入原本的功能規格中。
有沒有「緊急變更」的快速通道？
有。 但需要滿足條件並遵循流程：
啟動條件（至少滿足一項）：
- [ ] 安全漏洞（CVSS ≥ 7.0）
- [ ] 法規合規期限
- [ ] 核心功能完全無法使用
- [ ] 已承諾客戶的關鍵時程
快速通道流程：
| 步驟 | 時間 | 說明 |
|---|---|---|
| 1. 提出緊急申請 | 即時 | 向 PM Lead 或 Tech Lead 說明情況 |
| 2. 影響評估 | 30 分鐘內 | 評估對當前開發週期的影響 |
| 3. 授權決策 | 1 小時內 | PM Lead + Tech Lead 共同決定是否啟動 |
| 4. 迷你精煉 | 1-2 小時 | 最小必要人員快速定案 |
| 5. 執行 | 依情況 | 可能需要暫停或調整原進度 |
| 6. 事後記錄 | 完成後 | 記錄變更原因、影響、學習點 |
快速通道的代價：
警示：如果快速通道使用頻率超過每月 1 次，這通常表示：
- 前期收斂不夠完整
- 利害關係人未被充分納入
- 或者專案本身風險過高，需要重新評估
如何區分「合理的需求演進」和「不當的後期干擾」？
判斷標準：
| 面向 | 合理的需求演進 | 不當的後期干擾 |
|---|---|---|
| 資訊來源 | 新數據、用戶回饋、市場變化 | 「我突然想到」、「老闆說」 |
| 時機 | 發布後的回饋循環中提出 | 開發進行中突然插入 |
| 範圍 | 有明確邊界，可獨立評估 | 模糊、不斷擴大 |
| 提出者 | 原定案會議的參與者 | 未參與定案的人 |
| 決策過程 | 願意走正式流程 | 想繞過流程直接改 |
處理方式：
實務話術：
「這個想法很好，我們記錄下來。由於團隊已經根據定案開始執行，建議我們先完成這個版本，收集回饋後在下個週期一起評估。這樣我們可以有更完整的資訊做決定。」
核心原則：尊重已經投入的工作，但不拒絕好的想法——而是把它放到正確的時機處理。
多層級規格的維護成本會不會成為新的瓶頸？
重新理解多層規格：這是樹的結構，不是文件負擔。
核心洞察：
| 傳統理解 | 正確理解 |
|---|---|
| 7 層規格 = 7 倍維護成本 | 樹幹 + 枝幹 = 結構投資 |
| 規格是「額外文件」 | 規格是「骨架」 |
| 維護規格 vs 寫程式碼 | 沒有骨架，葉子長不穩 |
沒有 API 規格，AI 生成的前後端程式碼不會自動對齊。 沒有 UX 規格，AI 生成的 UI 不會符合設計意圖。 「多層規格」是讓 AI 能穩定產出的結構投資。
一個中型功能實際需要維護多少份規格？
不是每個功能都需要 7 層。 這 7 層是最大可能範圍：
| 功能類型 | 實際需要的規格 | 層數 |
|---|---|---|
| 純後端 API | 高階 → API → 後端 | 3 層 |
| 純前端調整 | 高階 → UX → 前端 | 3 層 |
| 全端功能 | 高階 → UX → API → 前端 + 後端 | 5 層 |
| 複雜跨平台 | 完整 7 層 | 7 層 |
更重要的是：規格是「生成」的，不是「手寫」的
傳統模式：人寫高階 → 人寫 UX → 人寫 API → 人寫程式碼
↓ ↓ ↓ ↓
(耗時) (耗時) (耗時) (耗時)
AI 模式： 人寫高階 → AI 生成 UX → AI 生成 API → AI 生成程式碼
↓ ↓ ↓
人審查 人審查 人審查
(快速) (快速) (快速)維護成本主要是「審查 AI 生成的內容」，人類只需維護高階規格。
需求變更時，需要同步更新多少份規格？
原則：從最高受影響層級更新，向下重新生成。
各層變更頻率：
| 層級 | 變更頻率 | 說明 |
|---|---|---|
| 樹幹（高階規格） | 很少 | 業務意圖穩定後很少變 |
| 枝幹（API/UX/設計） | 偶爾 | 主要在開發初期調整 |
| 葉子（實作/測試） | 頻繁 | 但重新生成成本低（AI 生成） |
實務經驗：大多數變更只影響「葉子」層級，不需要動到「樹幹」和「枝幹」。
誰負責確保規格間的一致性？是人工還是自動化？
混合模式：自動化檢查 + 人工判斷
| 一致性類型 | 檢查方式 | 工具 |
|---|---|---|
| API 規格 vs 實作 | 自動化 | OpenAPI 驗證、CI 檢查 |
| UX 規格 vs 實作 | 半自動 | 視覺回歸測試 + 設計審查 |
| 規格間術語一致 | AI 輔助 | AI 比對 + 人工確認 |
| 業務邏輯一致性 | 人工 | 規格審查會議 |
責任歸屬：
關鍵原則：
- 能自動化的一定自動化（API 合約驗證）
- 不能自動化的用 AI 輔助標記可疑處
- 最終判斷權在人類（PM/Tech Lead/UX Lead）
如果規格維護真的成為瓶頸，有什麼簡化策略？
診斷：先確認瓶頸在哪
| 症狀 | 可能原因 | 解法 |
|---|---|---|
| 「寫規格太花時間」 | 沒有善用 AI 生成 | 讓 AI 生成初稿，人只審查 |
| 「規格太多記不住」 | 層級切分過細 | 合併相關規格，減少文件數 |
| 「規格常常過時」 | 更新流程不清 | 明確觸發條件和責任人 |
| 「規格間不一致」 | 缺乏自動化檢查 | 導入 CI 驗證 |
簡化策略：
- 合併層級：小功能可以把 UX + 前端規格合併、API + 後端規格合併
- 跳過非必要層：純 Bug Fix 可以只有高階描述 + 直接改程式碼
- 漸進式細化：先粗略規格快速開發，穩定後再補充細節
- 規格模板化：建立團隊模板，減少每次從零開始的成本
最後提醒：
如果「寫規格」感覺是負擔，通常代表：
- 沒有善用 AI 生成（應該是審查，不是撰寫）
- 或者功能本身不需要這麼多層級（過度規範化）
規格的目的是讓 AI 產出更穩定，如果規格本身成為瓶頸，就失去意義了。 請務實地選擇適合功能複雜度的規格層級。
反模式
1. AI 作為決策者
問題： 將決策推給 AI 而非人類判斷。
正確做法： AI 提供選項並浮現權衡。人類做決定。
2. 跳過群體精煉
問題： 複雜功能直接開始實作，沒有多視角精煉。
正確做法： 複雜功能必須經過群體精煉產生高階規格。
3. 規格視為定案
問題： 將群體精煉產生的規格視為不可變更。
正確做法： 規格是活文件，發現問題時召開迷你精煉更新。
4. 跳過規格分支
問題： 高階規格直接跳到實作，不經過 UX/API/設計分支。
正確做法： 遵循多層級規格管理，每個分支產生對應規格。
相關文件
- 工作流程框架 - 多層級規格管理與標準工作流程模式
- AI-DLC 群體精煉提案 - 詳細的群體精煉方法論
- API 設計流程 - API 分支的詳細流程
參考資料
- AI-Driven Development Life Cycle (AWS) - AWS 對 AI 增強 SDLC 的方法
- OpenSpec - 規格驅動開發框架
- Mob Programming - 群體編程基礎實踐