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 [前置條件，含具體數值]When [觸發事件]Then ① [結果 1] ② [結果 2] ③ [結果 3]	• [邊界情境 1]• [邊界情境 2]• [邊界情境 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** ① 所有持倉立即市價平倉
                     ② 當日禁止新開倉
                     ③ 挑戰狀態 → Failed
                     ④ 發送失敗通知 Email + Dashboard 彈窗 |
             • 跨日隔夜持倉的跳空缺口：以新日開盤淨值重新計算基準
             • 多筆訂單同時觸發：平倉順序以 ticket ID 遞增為準
             • 週末跳空低於 -5%：以週一開盤第一個 tick 觸發 |

---

核心標準二：複雜度標注（取代工時估算）

規則

PRD 正文中絕對不要寫工時估算（「3-5 人天」、「0.5 人天」這類數字）。原因：

• 工時估算是工程師的職責。PM 在 PRD 裡寫了數字，工程師會覺得被預設了結論，容易產生摩擦。
• 不同團隊、不同技術棧，同樣的功能開發時間可以差 3-5 倍。PRD 裡的數字很快就會過時。
• 更好的做法是標注「技術複雜度」，讓工程師在 Sprint Planning 時自行估算。