工作流程框架
開發框架問題
目前所有已知的 AI 開發框架均假設產品為：單一產品，單一團隊，少數人力構成
在不重新造輪子的規範下，需要擴展這些現有的規格驅動框架用來適應多產品，多端點，多角色的環境，在參考 AWS AI DLC 後產生了以下提案，部分情境已在附錄中的數個功能開發過程中實現，現在此用一窺全貌的方式說明其最後模樣：
多層級規格管理
為什麼需要多層級架構
單一規格文件無法同時滿足不同角色的需求。PM 關心業務價值與範圍，設計師需要使用者流程與視覺規範，工程師需要技術細節與介面契約。如果把所有資訊塞進同一份文件，結果是每個人都要從大量無關內容中篩選自己需要的部分。
多層級架構讓每個角色只需要閱讀與自己相關的規格層級。高階規格定義「做什麼」，各專業規格定義「怎麼做」。每一層都有明確的輸入來源與輸出成果，形成可追溯的規格鏈。當需求變更時，可以快速定位受影響的層級，而不是在單一巨型文件中搜尋。
層級結構
每一層級繼承並擴展前一層級：
| 層級 | 輸入 | 輸出 |
|---|---|---|
| 高階規格 | 討論過的業務意圖 | 功能需求、範圍、影響 |
| 設計文件 | 高階規格 | 架構決策、權衡、風險 |
| UX 規格 | 高階規格 | 使用者流程、設計符記、線框圖 |
| API 規格 | 高階規格 + API 原則 | 介面契約、綱要定義 |
| 後端規格 | 高階 + API 規格 | 實作設計、資料模型 |
| 前端規格 | 高階 + API + UX + 設計系統 | 元件架構、狀態管理 |
| 測試規格 | 以上所有 | 測試案例、驗收標準 |
簡化專案的規格層級
如果你的專案相對簡單——例如純後端服務、純前端應用，或單人全端開發——不需要完整採用所有層級。可以省略與專案無關的中間規格，例如：
- 純後端 API 服務：可省略 UX 規格、前端規格
- 純前端應用：可省略後端規格、API 規格（若使用第三方 API）
- 小型全端專案：高階規格直接對應實作，省略中間的專業規格
用多少層級，取決於專案實際需要什麼。
Agentic 產品開發流程架構
| 階段 | 說明 | 參與者 |
|---|---|---|
| 收到意圖 | 從業務或產品端收到需求意圖 | PM、業務 |
| 密集討論 | 2-3 天內完成所有關鍵決策的收斂 | 所有利害關係人 |
| 形成提案 | 產出經過規格審查的提案文件 | PM、Tech Lead、設計 |
| 產出規格 | 透過 OpenSpec 產出各類細部規格 | 各職能角色 + AI |
| 審核規格 | 各專業角色審查規格的正確性與可行性 | 各職能角色 |
| 根據規格實作 | AI 代理依據規格產出實作，人類審查 | 工程師 + AI |
關鍵：前期收斂
整個流程的核心在於前 2-3 天的密集討論。所有可能影響規格的利害關係人必須在此階段完成意見收斂，避免後期變更導致返工。
為什麼前期收斂不使用 AI？
根據 AI-DLC 的定義，前期收斂階段理論上應該有 AI 介入。但實際實驗後發現，AI 在上下文脈絡不夠清楚的情況下，會產出過度延伸的規格。
因此，在這個階段目前仍建議以人類的方式思考規格。這也是整個流程中，人類貢獻智慧最多、最密集的地方。
在這個密集討論意圖與提案的階段，每個人都會成為這個產品最核心的設計人員，每個人都跟產品息息相關。
標準工作流程模式
每個職能角色遵循一致的循環：
- 接收 - 從上游取得標準化規格
- 結合 - 與領域專屬脈絡合併（設計系統、API 原則、程式碼標準）
- 委派 - 提交給 AI 代理產生提案
- 審查 - 評估代理產出的正確性與品質
- 精煉 - 與代理反覆迭代直到可接受
- 歸檔 - 提交至版本控制作為單一事實來源
工作流程主題
本節涵蓋規格驅動開發中不同情境的特定工作流程：
| 主題 | 說明 |
|---|---|
| 需求種子內容 | 啟動 OpenSpec 變更提案所需的最小必要資訊 |
| 錯誤修復流程 | 依據錯誤是規格問題或實作問題來處理的工作流程 |
| API 設計流程 | 結合 AI 代理整合的 API-First 方法進行 API 規格 |
參考資料
- OpenSpec - 用於 AI 輔助工作流程的規格驅動開發框架
- Claude Code 文件 - CLAUDE.md 和 AI 指引檔案的官方文件
- shadcn/ui - 設計系統基礎的精美元件
- OpenAPI 規格 - RESTful API 的 API 描述格式
- Gherkin 語法 - Given/When/Then 情境規格格式