prd

產品需求文件（PRD）

概述

設計完整、可上線的產品需求文件（PRD），銜接商業願景與技術執行。此技能適用於現代軟體系統，確保需求清楚定義。

使用時機

在以下情況使用此技能：

• 開始新產品或功能開發週期
• 將模糊想法轉化為具體技術規格
• 定義 AI 驅動功能的需求
• 利害關係人需要統一的專案範圍「單一事實來源」
• 使用者要求「寫一份 PRD」、「記錄需求」或「規劃功能」

---

操作流程

第一階段：探索（訪談）

在撰寫 PRD 之前，你必須詢問使用者以填補知識缺口。不要假設背景。

詢問內容：

• 核心問題：為什麼現在要建置這個？
• 成功指標：如何知道它有效？
• 限制條件：預算、技術棧或截止日期？

第二階段：分析與範圍界定

綜合使用者的輸入。識別相依性與隱藏複雜度。

• 繪製使用者流程。
• 定義非目標以保護時程。

第三階段：技術草稿

使用下方的嚴格 PRD 結構產生文件。

---

PRD 品質標準

需求品質

使用具體、可衡量的標準。避免「快速」、「簡單」或「直覺」。

# 模糊（不好）
- 搜尋應該快速且回傳相關結果。
- UI 必須看起來現代且易於使用。

# 具體（好）
+ 搜尋必須在 200 毫秒內回傳 10k 筆記錄的資料集結果。
+ 搜尋演算法在基準評估中必須達到 >= 85% 的 Precision@10。
+ UI 必須遵循 'Vercel/Next.js' 設計系統，並達到 100% 的 Lighthouse 無障礙分數。

---

嚴格 PRD 結構

你必須遵循以下確切結構來輸出：

1. 執行摘要

• 問題陳述：1-2 句說明痛點。
• 解決方案：1-2 句說明修正方式。
• 成功標準：3-5 個可衡量的 KPI。

2. 使用者體驗與功能

• 使用者人物誌：這是為誰設計的？
• 使用者故事：As a [user], I want to [action] so that [benefit].
• 驗收標準：每個故事的「完成」定義項目清單。
• 非目標：我們不建置什麼？

3. AI 系統需求（如適用）

• 工具需求：需要哪些工具和 API？
• 評估策略：如何衡量輸出品質與準確性。

4. 技術規格

• 架構概述：資料流程與元件互動。
• 整合點：API、資料庫與驗證。
• 安全與隱私：資料處理與合規。

5. 風險與路線圖

• 階段性推出：MVP -> v1.1 -> v2.0。
• 技術風險：延遲、成本或相依性失敗。

---

實作指南

務必（總是）

• 定義測試：對於 AI 系統，指定如何測試與驗證輸出品質。
• 迭代：提供草稿並針對特定部分徵求意見。

避免（不要）

• 跳過探索：在沒有先問至少兩個釐清問題之前，絕不撰寫 PRD。
• 虛構限制：如果使用者未指定技術棧，請詢問或標記為 TBD。

---

範例：智慧搜尋系統

1. 執行摘要

問題：使用者在大型儲存庫中難以找到特定文件片段。
解決方案：一個智慧搜尋系統，提供直接答案並附上來源引用。
成功：

• 減少 50% 的搜尋時間。
• 引用準確度 >= 95%。

2. 使用者故事

• 故事：作為開發者，我想用自然語言提問，這樣我就不用猜關鍵字。
• 驗收標準：
  • 支援多輪釐清。
  • 回傳程式碼區塊並附上「複製」按鈕。

3. AI 系統架構

• 所需工具：codesearch、grep、webfetch。

4. 評估

• 基準：用 50 個常見開發者問題進行測試。
• 通過率：90% 必須符合預期引用。