經過前面 17 天，我們已經掌握了各種 AI 工具的使用，也體驗了不同的開發模式。現在要進入筆者心心念念的 AI-DLC Sprint 核心環節了！

今天要談的是整個 Sprint 的第一環：PRD（Product Requirements Document）規格撰寫。這個環節為什麼重要？因為它決定了後面所有 AI 能不能正確理解你要做什麼。

還記得之前跟大家分享過，我在傳統開發流程中最痛苦的就是需求討論。好不容易寫完 PRD，每個人的理解還是不一樣：

• PM 說的「快速」= 使用者體驗要流暢
• 老闆理解的「快速」= 明天就要上線
• 工程師實作的「快速」= 能動就好，效能之後再優化
• 客戶期待的「快速」= 按下去立刻有反應

這就是為什麼我要發展 AI-DLC Sprint，讓 AI 來當這個翻譯官！

AI-DLC Sprint 的 PRD 新思維

在我的 AI-DLC Sprint 中，PRD 不再是那種沒人想看的厚重文件，而是：

1. AI 的溝通語言

不是寫給人看的，是寫給 AI 看的。既然後面所有環節都要 AI 協作，那 PRD 就要用 AI 能精準理解的方式來寫。

2. 活的知識載體

PRD 會隨著專案演進不斷更新，而且每次更新都會自動同步到所有相關環節。不再有「文件過期」的問題。

3. 自動化的起點

一份好的 PRD，可以自動產生：

• User Stories（下一篇會講）
• UI Wireframe（Day 20）
• Test Cases（Day 21）
• 甚至初版程式碼（Day 22）

AI PM 的三步驟魔法

Step 1：讓 AI 來問你問題（而不是你寫文件）

這是我最得意的發現！與其痛苦地盯著空白文件不知道怎麼開始，不如讓 AI 來採訪你：

# 我常用的 AI PM 初始化 Prompt

你現在是一位資深產品經理，要幫我釐清產品需求。
請用以下順序來問我問題，每次只問一個類別，等我回答後再繼續：

1. 核心問題
   - 你想解決什麼問題？
   - 現在的痛點有多痛？（1-10分）
   - 不解決會怎樣？

2. 用戶輪廓
   - 誰會用這個產品？
   - 他們現在怎麼解決這個問題？
   - 他們願意付多少錢解決？

3. 成功定義
   - 怎樣算成功？
   - 有什麼可以量化的指標？
   - 最小可行產品要有哪些功能？

根據我的回答，幫我生成一份結構化的 PRD。

Step 2：根據開發模式調整 PRD 結構

這是 AI-DLC Sprint 的精髓 - 同樣的需求，不同開發模式要不同的 PRD 寫法：

TDD 模式（測試先行）

當品質是第一優先時：

#### TDD 版 PRD 重點
1. 測試情境
   - Happy Path 測試案例
   - Edge Cases 列表
   - 錯誤處理場景
   
2. 預期行為
   - Given-When-Then 描述
   - 測試資料集
   - Mock 資料規格

BDD 模式（行為驅動）

當要跟非技術人員溝通時：

#### BDD 版 PRD 重點
1. 使用者故事場景
   Feature: 使用者登入
   Scenario: 成功登入
     Given 我在登入頁面
     When 我輸入正確的帳號密碼
     Then 我應該看到首頁
     
2. 業務價值描述
   - 為什麼用戶要這個功能
   - 帶來什麼商業價值
   - 成功的用戶行為是什麼

DDD 模式（領域驅動）

當系統很複雜時：

#### DDD 版 PRD 重點
1. 領域模型
   - 核心領域概念
   - Bounded Context 劃分
   - 聚合根定義
   
2. 領域語言字典
   - 業務術語 = 技術術語對照
   - 領域事件清單
   - 不變規則（Invariants）

Step 3：AI 幫你查漏補缺

寫完初版 PRD 後，最重要的是讓 AI 幫你檢查：

# PRD 完整性檢查 Prompt

請檢查這份 PRD 並回答：
1. 有哪些重要但沒提到的部分？
2. 有哪些可能的風險沒考慮到？
3. 有哪些地方可能造成理解歧義？
4. 如果你是工程師，還需要知道什麼才能開始開發？

請列出具體的改進建議。

我的獨門密技：多版本 PRD 策略

這招超好用！同一個需求，我會讓 AI 生成三個版本：

版本對比法

# 多版本生成 Prompt

基於剛才的需求討論，請生成三個版本的 PRD：

1. MVP 版（7天內要上線）
   - 只保留核心功能
   - 可以用現成工具組合
   - 允許手動操作的部分

2. 標準版（1個月開發期）
   - 包含主要功能
   - 良好的使用者體驗
   - 基本的自動化

3. 理想版（不限時間預算）
   - 完整功能
   - 極致的用戶體驗
   - 全面自動化與智能化

用表格比較這三個版本的：
- 功能差異
- 開發成本
- 技術難度  
- 預期效益
- 風險等級

這樣做的好處是：

1. 老闆看到成本差異，會比較理性
2. 團隊可以階段性交付，壓力較小
3. 隨時可以根據資源調整目標

實戰演練

今天筆者的另一個系列有提到如何在實際產品中撰寫實際的 PRD，有興趣可以參考：AI-Driven Development 實戰篇：30 天 Side Project 開發全紀錄：Day 4 - AI-DLC Sprint 實戰：MenuBar Todo 的 PRD 速成魔法

PRD 的 AI 升級檢查表

我整理了一個檢查表，確保 PRD 真的能被 AI 理解並轉化：

基本要素

• [ ] 有明確的問題陳述（Problem Statement）
• [ ] 有可量化的成功指標（Success Metrics）
• [ ] 有具體的用戶場景（User Scenarios）
• [ ] 有優先級排序（Priority）
• [ ] 有時程預估（Timeline）

AI 友善要素

• [ ] 使用結構化格式（JSON/YAML/Markdown）
• [ ] 專有名詞有明確定義
• [ ] 範例資料完整

可執行要素

• [ ] 可以直接轉成 User Story
• [ ] 可以生成測試案例
• [ ] 可以產生 API 規格
• [ ] 可以製作 Wireframe
• [ ] 可以估算開發時間

實際效益（真實數據）

自從我開始用這套方法後：

時間節省

• 傳統 PRD：2-3 天的會議 + 撰寫
• AI-DLC PRD：30-45 分鐘搞定
• 節省 93% 時間

品質提升

• 需求變更次數：從平均 5-6 次降到 1-2 次
• 理解偏差：從 40% 降到不到 5%
• 文件更新：自動同步，不再有版本問題

目前是在個人開發跟小團隊上嘗試，希望未來有機會導入到大團隊中

今天的重點回顧

1. PRD 是 AI-DLC Sprint 的靈魂：它決定了後面所有 AI 協作的品質
2. 讓 AI 問你，而不是你寫文件：用對話的方式產生 PRD 更自然
3. 不同開發模式要不同 PRD：SDD 重規格、TDD 重測試、BDD 重行為、DDD 重領域
4. 多版本策略超好用：MVP、標準、理想三版本，讓決策更理性
5. 檢查表很重要：確保 PRD 真的能被 AI 使用

明天預告

明天要進入 Day 19：AI Scrum Master - User Story 拆解的藝術

我會分享如何讓 AI 把一份 PRD 自動拆解成：

• 完美切分的 User Story
• 自動估點（而且蠻準的）
• Dependencies 自動識別
• Sprint 容量最佳化分配

最精彩的是，我會展示如何把 4 小時的 Sprint Planning 壓縮到 15 分鐘！