prd-writer

# PRD Writer（輕量版）— 施工藍圖等級的產品需求文件 ## 設計理念 一份好的 PRD 不是「思考文件」，而是「施工藍圖」。判斷標準很簡單： - 工程師看完能直接開發，不需要回頭問 PM「這個情況怎麼處理？」 - QA 看完能直接寫測試案例，不需要猜測邊界條件 - UAT 時不會出現「我以為是這樣」的分歧 這個 skill 的存在就是為了確保每份 PRD 都達到這個標準。 ## 文件結構 PRD 應包含以下層次，根據產品複雜度可以增減，但核心四件事（AC、複雜度、畫面狀態、Out of Scope）不可省略： ``` 1. 產品概述與目標 2. 功能規格（每個功能點） ├── 功能描述 ├── 規則/邏輯 ├── 驗收標準（AC） ← 必要 └── Out of Scope ← 必要 3. User Flow / 畫面規格 ├── 每個畫面的狀態列舉 ← 必要 ├── 頁面跳轉條件 └── API 呼叫時機 4. 風險與對策 5. MVP 路線圖 └── 複雜度標注（非工時估算） ← 必要 6. 成功指標（KPIs） ``` --- ## 核心標準一：驗收標準（Acceptance Criteria） 每個功能點都必須附上驗收標準。這是 PRD 從「想法」變成「可執行規格」的關鍵。 ### 格式 使用 **Given / When / Then** 三段式，每條 AC 搭配 **Edge Case** 說明： | 規則 | Given / When / Then | Edge Case | |------|---------------------|-----------| | [規則名稱] | **Given** [前置條件，含具體數值]<br>**When** [觸發事件]<br>**Then** ① [結果 1] ② [結果 2] ③ [結果 3] | • [邊界情境 1]<br>• [邊界情境 2]<br>• [邊界情境 3] | ### 撰寫原則 寫 AC 的時候，腦中要想著三個人： 1. **工程師**：他需要知道確切的觸發條件和預期行為。「帳戶淨值 ≤ $95,000」比「虧損太多」有用一千倍。 2. **QA**：她需要知道邊界條件。週末跳空怎麼辦？多筆訂單同時觸發呢？這些如果不寫，測試的時候才發現就來不及了。 3. **客服**：他需要知道系統會做什麼，這樣才能回答用戶的問題。「訂單被拒絕，返回 NEWS_WINDOW 錯誤碼」比「系統會處理」清楚太多。 ### 具體要求 - **Given** 中必須包含具體數值或狀態（不是「某個帳戶」，而是「$100,000 帳戶」或「帳戶狀態 = Active」） - **When** 必須是可觀測的事件（不是「用戶做了什麼不好的事」，而是「即時淨值 ≤ $95,000」） - **Then** 使用編號列出所有系統行為，順序即執行順序 - **Edge Case** 列出至少 2-3 個邊界情境，特別是： - 兩個規則同時觸發時的優先級 - 時區/日期邊界的處理 - 資料不完整或異常時的降級行為 ### 範例 ``` | 日虧損 -5% | **Given** 當日開盤淨值 = $100,000 **When** 即時淨值（含未實現損益）≤ $95,000 **Then**...