二月 16, 2026 | 網站建置知識
AI-Driven Development Flow：7 個階段重新定義軟體開發流水線
傳統流水線的問題
大多數軟體團隊的開發流水線長這樣：
Backlog → Doing → Code Review → QA → Done
這條流水線有一個根本假設：「Doing」階段是人在寫 code。所以 Code Review 是在看人寫的 code，QA 是在測人寫的功能。
但當 AI 接管了「寫 code」這件事後，整條流水線的假設都變了：
- AI 生成的 code 表面上都很漂亮，傳統的 code style review 變得沒意義
- AI 可能會「幻覺」——引用不存在的 API、編造不存在的 library
- AI 生成速度太快，Review 來不及消化
- 沒有機制區分「改個按鈕顏色」和「改 DB schema」的風險差異
AI-Driven Development Flow 重新設計了整條流水線，加入了 AI 時代特有的品質把關機制。
新的流水線：7 個階段
完整的 AI-Driven Development Flow 長這樣：
Backlog → Spec Ready → AI Generate → Self Review → Risk Gate → PO Review → Done
跟傳統流水線相比，新增了三個關鍵階段：Spec Ready（取代模糊的 DoR）、Self Review（全新）、Risk Gate（取代一刀切的 Code Review）。
接下來逐一拆解每個階段。
階段一：Backlog
| 角色 | 職責 | 層級 |
|---|---|---|
| PO | 管理需求優先序 | 主要 |
Backlog 階段跟傳統做法差異不大。PO 負責維護需求的優先序，確保團隊永遠在做最重要的事。
但有一個重要的變化：因為 AI Flow 的交付速度大幅提升，PO 需要更頻繁地更新 Backlog 的優先序——不是每兩週一次，而是每天確認。
階段二：Spec Ready（原 DoR）
| 角色 | 職責 | 層級 |
|---|---|---|
| Sr. Engineer | 撰寫 AI 可執行的技術規格 | 主要 |
| Engineer | 協助拆解任務、定義測試條件 | 支援 |
| PL / Tech Lead | 審核架構約束條件、標記風險等級 | 把關 |
| PO | 確認驗收標準 | 把關 |
這是整條流水線最重要的階段。
傳統的 DoR（Definition of Ready）通常只確認「需求夠清楚、可以開始做了」。但在 AI Flow 裡，Spec Ready 的標準高得多——它必須是 AI 可直接執行的技術規格。
一份合格的 Spec 包含：
- 精確的 API endpoint 定義與參數規格
- 要使用的現有 service、pattern、和架構約束
- 邊界條件的處理方式
- 風險等級標記（Low / Med / High）
- 自動測試的驗收條件
💡 核心公式：Spec 品質 = AI 產出品質 = Review 負擔輕重
工程師的新核心能力不再是「能不能寫出好 code」，而是「能不能把需求轉化為 AI 能精確執行的 Spec」。
階段三：AI Generate（原 Doing）
| 角色 | 職責 | 層級 |
|---|---|---|
| Engineer | 操作 AI 工具、給 prompt、調整產出方向 | 主要 |
| AI | 生成程式碼、測試、文件 | 執行 |
| 自動化 | 自動跑 lint / test / security scan | 自動 |
這個階段取代了傳統的「Doing」（手動寫 code）。但請注意：工程師不是按一個按鈕等結果。
AI Generate 是一個工程師和 AI 的協作過程：
- 工程師把 Spec 餵給 AI
- AI 生成第一版產出
- 工程師快速判斷：方向對不對？Pattern 對不對？
- 不滿意 → 調整 prompt，告訴 AI 哪裡需要改 → 重新生成
- 滿意 → 自動化跑 lint / test / security scan
- 全部通過 → 進入下一階段
工程師在這裡的角色是導航員，持續引導 AI 往正確的方向走，而不是放手讓 AI 自己跑。
💡 這是工程師和 AI 的協作過程，不是放手讓 AI 自己跑。
階段四：Self Review（全新階段）
| 角色 | 職責 | 層級 |
|---|---|---|
| Engineer | 用 checklist 審核自己操作 AI 生成的產出 | 主要 |
| 自動化 | AI 輔助偵測常見問題（幻覺、安全性） | 輔助 |
這是 AI Flow 特有的全新階段，傳統流水線裡沒有對應物。
核心理念是：你操作 AI 生成的東西，你要先自己確認品質。這不是偷懶的 Review，而是有系統的品質檢查。
Self Review Checklist
每次 Self Review 都要跑這份 Checklist：
- AI 引用的 library / API 真的存在嗎？ — AI 最常見的幻覺就是引用不存在的套件
- 邏輯正確性 — 不只是能跑，是跑對。特別注意邊界條件
- 與現有架構一致嗎？ — AI 不一定了解你的專案慣例
- 有沒有 hardcoded 值或安全風險？ — AI 常常把測試用的假資料留在程式碼裡
- 測試覆蓋率夠嗎？ — 確認自動測試能抓到未來的 regression
💡 Self Review 能攔截 70% 的低級問題，不浪費後面 reviewer 的時間。
階段五：Risk Gate（原 Peer + PL Review）
這是 AI Flow 裡最具創新性的設計。
傳統的 Code Review 是「一刀切」——不管你改了什麼，都要走同樣的 Review 流程。這導致了兩個問題：改個按鈕顏色要等兩天 Review，改個 DB schema 也只是同樣的 Review 等級。
Risk Gate 根據風險等級自動分流，讓審核資源用在刀口上：
Low Risk — 自動通過
| 項目 | 說明 |
|---|---|
| 範例 | UI 微調、文案修改、config 變更 |
| 審核方式 | 自動化測試全部通過 → 直接進 PO Review |
| 工程師角色 | 不需介入 |
| 處理時間 | 數分鐘 |
Med Risk — Peer Review
| 項目 | 說明 |
|---|---|
| 範例 | 新功能、API 變更、業務邏輯修改 |
| 審核方式 | 另一位工程師進行 Peer Review |
| 工程師角色 | 作為 Reviewer 審核同事的 AI 產出 |
| 處理時間 | 數小時 |
High Risk — 雙重把關
| 項目 | 說明 |
|---|---|
| 範例 | DB schema、安全性、核心架構、金流、認證 |
| 審核方式 | Sr. Engineer 深度審核 + PL 架構層級審核 |
| 工程師角色 | 資深工程師 + PL 雙重把關 |
| 處理時間 | 半天至一天 |
Risk Gate 的分流是在 Spec Ready 階段就決定的——PL 在審核 Spec 時就標記了風險等級。這代表整個審核流程在任務開始前就已經規劃好了。
階段六：PO Review（原 PO Review）
| 角色 | 職責 | 層級 |
|---|---|---|
| PO | 功能驗收 — 頻率從 Sprint 尾改為隨到隨審 | 主要 |
| Engineer | Demo 展示、回答 PO 問題 | 支援 |
PO Review 的本質沒變，但頻率大幅提升。傳統模式下，PO 通常在 Sprint 結束時才看到完成品。在 AI Flow 裡，PO 每天都在驗收。
這代表：
- 回饋循環從 2 週縮短到 1 天
- 方向錯誤能更早被發現
- PO 對產品的掌控度大幅提升
通過 → Done。不通過 → 回到 Spec 重新定義，而不是讓工程師在錯誤的方向上繼續做。
階段七：Done
Done 就是 Done。功能已驗收、測試已通過、可以上線。
在 AI Flow 裡，Done 是每天都在發生的事，不是兩週才發生一次。
工程師角色轉變總結
整條流水線看下來，工程師的角色在每個階段都發生了根本性的轉變：
| 階段 | 傳統角色 | AI Flow 新角色 |
|---|---|---|
| Spec Ready | 看需求就開始寫 code | 寫 Spec（定義 AI 該做什麼） |
| AI Generate | 手動開發 | 操作 AI 生成 + 即時判斷品質 |
| Self Review | （不存在） | 先自己 Review AI 的產出 |
| Risk Gate | 被別人 Review | 作為 Reviewer 審核別人的 AI 產出 |
| PO Review | Sprint 結束才 Demo | 隨時 Demo 給 PO |
最大的轉變是：工程師從「被 Review 的人」變成了「Review 的人」。在傳統模式下，工程師寫完 code 等別人來 Review。在 AI Flow 裡，AI 寫 code，工程師負責 Review AI 的產出，同時也 Review 同事操作 AI 產出的結果。
如何開始導入？
不建議一次全面切換。以下是漸進式導入的建議：
第一步：先導入 Self Review Checklist
不管你現在用什麼流程，只要團隊有在用 AI 工具生成 code，就立刻導入 Self Review Checklist。這是投入最少、效果最明顯的改變。
第二步：導入 Risk Gate 分級
在現有的 Code Review 流程上，加入風險等級標記。Low Risk 的 PR 走快速通道，High Risk 的 PR 加入更嚴格的審核。
第三步：強化 Spec Ready 標準
開始要求每個任務在「開始做」之前，都有一份 AI 可執行的 Spec。這需要團隊建立 Spec 模板和撰寫規範。
第四步：調整每日節奏
把 Review 集中到固定時段，把 Spec 時間保護起來。這是最後一步，也是影響最大的一步。
結語：流水線設計反映你對品質的態度
AI-Driven Development Flow 不只是換了幾個階段名稱。它反映了一個根本性的思維轉變：在 AI 時代，生產不是瓶頸，品質才是。
當 AI 可以在幾秒內生成 code，決定團隊效率的不再是「寫得多快」，而是「審得多好」、「Spec 寫得多精確」、「風險分得多準確」。
這條新的流水線，把工程師從「code 生產者」變成了「品質守門員」和「AI 導航員」。這不是降級，而是升級——你的價值從「手速」升級成了「腦力」。
