AI Workflow Conduction

繁體中文

Home
English

繁體中文

Home
English

Appearance

AI-DLC：AI 增強開發生命週期 ​

傳統 SDLC 方法未能在關鍵決策點利用 AI 能力，導致需求不完整、遺漏邊界案例和知識孤島。AI-DLC 將 AI 作為主動參與者引入協作精煉會議，與 PM、RD、UX 和架構師並肩工作。

核心洞察： 當多元觀點同時挑戰假設時，需求品質會顯著提升。AI 增加了一個不知疲倦的參與者，能夠即時發現邊界案例、檢查一致性並維護完整的文件。

問題陳述 ​

現狀：順序式知識傳遞 ​

當前方法的痛點 ​

角色盲點後果
PM技術限制、API 限制不切實際的需求
RDUX 影響、用戶旅程缺口糟糕的用戶體驗
UX技術可行性、資料可用性無法實現的設計
架構師業務脈絡、優先順序權衡過度設計的解決方案
所有人邊界案例、錯誤情境生產環境 Bug

真實案例 ​

邊界案例覆蓋不足：

PM 寫道「用戶可以上傳個人頭像」。沒有人問：支援哪些檔案類型？最大檔案大小？上傳中途失敗怎麼辦？網路慢的用戶怎麼處理？這些都在 QA 或生產環境才被發現。

技術與業務錯位：

架構師為「可擴展性」設計微服務，卻不知道這個功能總共只服務 100 個用戶。過度設計浪費了數月時間。

UX 後期發現：

UX 設計了漂亮的多步驟精靈。RD 實作完成。測試時發現行動裝置用戶在第三步因為複雜的相機權限流程而放棄，這是之前沒人考慮到的。

提案：AI 參與的群體精煉 ​

目標狀態 ​

什麼是群體精煉？ ​

群體精煉 (Mob Elaboration) 是一個限時的協作會議，所有利害關係人（PM、RD、UX、架構師、AI）共同合作，將需求種子轉化為完整、可實作的規格。

群體精煉中的角色職責 ​

角色主要貢獻AI 增強
PM業務脈絡、優先順序、成功標準AI 挑戰假設、建議指標
RD技術可行性、工作量估算、API 設計AI 產生 API 草稿、識別整合點
UX用戶流程、互動模式、無障礙設計AI 浮現邊界案例、產生錯誤狀態
架構師系統影響、可擴展性、安全性AI 檢查與現有架構的一致性
AI文件、模式識別、完整性檢查即時綜合、情境產生

群體精煉會議結構 ​

會前準備（非同步，30 分鐘） ​

markdown
## 需求種子範本

### 功能名稱
[一句話描述]

### 業務脈絡
- 為什麼是現在？
- 誰提出的需求？
- 解決什麼問題？

### 初始範圍
- 必須有：
- 最好有：
- 不在範圍內：

### 已知限制
- 時程：
- 預算：
- 技術：

會議階段（總計 60-90 分鐘） ​

第一階段：脈絡對齊（10 分鐘） ​

PM 提出需求種子。AI 總結並提出釐清問題。

markdown
## AI 釐清檢查清單
- [ ] 用戶角色已定義？
- [ ] 成功指標已指定？
- [ ] 整合點已識別？
- [ ] 資料來源已確認？
- [ ] 錯誤處理已討論？

第二階段：多視角挑戰（30 分鐘） ​

每個角色從其視角挑戰需求。AI 促進並記錄。

AI 在挑戰期間的提示：

  • 「如果 [X] 失敗會發生什麼？」
  • 「這與現有的 [Y] 如何互動？」
  • 「用戶完成 [Z] 後的下一步是什麼？」
  • 「這與我們處理 [類似功能] 的方式一致嗎？」

第三階段：規格產生（20 分鐘） ​

AI 根據討論產生規格草稿。團隊審查並修訂。

markdown
## AI 產生的規格草稿結構

### 功能概述
[AI 從討論中綜合]

### 用戶故事
[AI 從 UX 討論中擷取]

### API 合約
[AI 從 RD 討論中草擬]

### 架構註記
[AI 從架構師輸入中擷取]

### 邊界案例 & 錯誤處理
[AI 從所有視角彙整]

### 測試情境
[AI 從需求產生]

### 開放問題
[AI 追蹤未解決項目]

第四階段：承諾 & 後續步驟（10 分鐘） ​

團隊確認範圍、指派負責人、必要時安排後續會議。

所需的 AI 代理能力 ​

會議期間 ​

能力目的範例
即時轉錄捕捉所有討論帶發言者標註的會議記錄
模式匹配浮現相關功能「這類似於我們在 Y 中處理 X 的方式」
一致性檢查標記矛盾「稍早 PM 說 A，但 RD 提到 B」
情境產生浮現邊界案例「如果用戶在 Y 發生時做 X 會怎樣？」
規格草擬產生文件API 合約、用戶故事、測試案例

所需知識 ​

實施路線圖 ​

第一階段：試點（第 1-2 週） ​

目標： 與志願團隊進行 2-3 場群體精煉會議。

交付物：

  • [ ] 會議引導指南
  • [ ] 各階段 AI 提示範本
  • [ ] 回饋收集範本
  • [ ] 會議錄影與分析

第二階段：工具建置（第 3-4 週） ​

目標： 建立有效 AI 參與的工具。

交付物：

  • [ ] 群體精煉專用 AI 代理配置
  • [ ] 即時轉錄整合
  • [ ] 規格範本產生
  • [ ] 會議產出物儲存

第三階段：流程整合（第 5-6 週） ​

目標： 將群體精煉整合到標準開發流程。

交付物：

  • [ ] 更新 PRD 流程，複雜功能需要群體精煉
  • [ ] 排程範本與節奏
  • [ ] 成功指標儀表板
  • [ ] 所有角色的培訓材料

第四階段：持續改進（持續） ​

目標： 根據結果迭代。

交付物：

  • [ ] 每月會議效能回顧
  • [ ] 根據回饋改進 AI 提示
  • [ ] 從成功會議建立模式庫
  • [ ] 跨團隊知識分享

CLAUDE.md 整合 ​

加入專案 CLAUDE.md：

markdown
## 群體精煉

### 會議參與
參與群體精煉會議時：
- **脈絡**：載入相關 CLAUDE.md、現有規格和 API 文件
- **角色**：促進討論、浮現缺口、產生文件
- **產出**：完整規格草稿含情境和測試案例

### 引導提示
精煉期間主動探詢：
- 邊界案例：「如果 [X] 失敗/逾時/回傳空值會怎樣？」
- 一致性：「這與現有的 [Y] 功能如何對齊？」
- 完整性：「用戶完成 [Z] 後會發生什麼？」
- 資料：「[資料點] 從哪裡來？」

### 規格產生
精煉後產生：
1. 從 PM 輸入綜合的功能概述
2. 從 UX 討論提取的用戶故事
3. 從 RD 討論草擬的 API 合約
4. 從架構師輸入捕捉的架構註記
5. 從所有視角彙整的邊界案例
6. 涵蓋正常路徑和錯誤的測試情境

### 知識來源
群體精煉脈絡載入：
- `CLAUDE.md` - 專案慣例
- `docs/specs/` - 現有功能規格
- `docs/api/` - API 文件
- 程式碼庫中相關功能實作

成功指標 ​

指標之前目標如何測量
需求完整性~60%>90%審核規格中遺漏的邊界案例
後期範圍變更高-50%追蹤開發開始後的範圍變更
需求相關 Bug~30% 的 Bug<10%按根因標記 Bug
首次實作時間數天數小時測量規格到程式碼的時間差
跨角色對齊低高會後調查

常見問題 ​

何時應該使用群體精煉？ ​

適用於：

  • 有多個利害關係人的新功能
  • 跨多個系統的功能
  • 高風險或高能見度的功能
  • 需求不明確的功能

跳過於：

  • 簡單的 Bug 修復
  • 定義明確的小型增強
  • 純技術重構
  • 單一負責人的功能

如何處理遠端參與者？ ​

  • 使用螢幕共享的視訊會議
  • AI 即時轉錄
  • 專門記錄員捕捉非語言線索
  • 所有參與者需要非同步預讀

利害關係人在會議中意見不合怎麼辦？ ​

  1. AI 記錄雙方立場
  2. PM 對業務優先順序做最終決定
  3. 架構師對技術方法做最終決定
  4. 未解決項目標記待升級
  5. 會議繼續，記錄分歧

這與傳統會議有何不同？ ​

傳統會議群體精煉
輪流發言協作建構
會後記錄即時 AI 文件
單一視角產出多視角綜合
需要後續會議會議中完成規格
知識孤島共享理解

應避免的反模式 ​

1. AI 作為決策者 ​

問題： 將決策推給 AI 而非人類判斷。

解決方案： AI 提供選項並浮現權衡。人類做決定。

2. 無準備的會議 ​

問題： 利害關係人未閱讀需求種子就參加會議。

解決方案： 必須非同步預讀。AI 在會議開始時測驗理解程度。

3. 缺少視角 ​

問題： 在缺少所有角色代表的情況下開會。

解決方案： 最低出席要求。關鍵角色缺席則改期。

4. 規格視為定案 ​

問題： 將產生的規格視為不可變更。

解決方案： 規格是活文件。定期審查和更新週期。

相關提案 ​

相關： 持續脈絡清理 | 返回： 提案概覽

參考資料 ​