PRD 生成
將功能構想轉換為結構化的產品需求文件。
此技能的功能
將非正式的功能請求轉化為完整的 PRD，包含使用者故事、驗收標準、功能需求、成功指標與合規指引。產出結果可供工程團隊直接實作，並供利害關係人審查。
使用時機
在以下情況啟用此技能：
- 使用者想要記錄新功能或產品構想
- 出現如「寫一份 PRD」、「建立需求」、「記錄此功能」等用語
- 準備進行產品評審、利害關係人對齊或工程交接
- 使用者提及使用者故事、驗收標準或成功指標
- 需要將粗略構想正式化為結構化文件
情境偵測（關鍵 - 第一步）
在生成任何 PRD 內容之前，你必須先識別情境。
使用 AskUserQuestion 來判定是哪一種情境：
Q: 請選擇 PRD 生成場景
| 選項 | 說明 |
|---|---|
| 迭代更新 | 基於現有功能進行迭代優化 |
| 新功能 | 在現有產品上添加新模組 |
| 0-1 新產品 | 從零開始規劃全新產品 |
依情境蒐集背景資訊
識別情境後，依此表蒐集所需背景資訊：
| 情境 | 必要資訊 | 蒐集方法 |
|---|---|---|
| 迭代更新 | 1. 當前功能描述2. UI 狀態（截圖/HTML/連結）3. 迭代目標 | 使用者輸入 + 以 AskUserQuestion 確認 UI 狀態選項 |
| 新功能 | 1. 產品整體架構2. 設計規範（元件庫/互動模式）3. 入口位置 | 從 docs/product/ 讀取或由使用者提供 |
| 0-1 新產品 | 1. 產品背景與目標用戶2. 資源限制3. 參考產品 | 使用者輸入 + 競品分析 |
迭代更新的 UI 狀態蒐集方法： 當使用者選擇「迭代更新」時，詢問他們如何提供當前 UI 狀態：
- 截圖 - 使用者提供截圖，使用
mcp__zai-mcp-server__ui_to_artifact或mcp__4_5v_mcp__analyze_image - HTML 檔案 - 使用者提供本地 HTML 路徑，使用
Read工具解析 DOM 結構 - 線上連結 - 使用者提供 URL，使用
mcp__web_reader__webReader（無需登入）
步驟 0.5：資訊差距分析與 PRD 計畫（關鍵 — 硬性關卡）
硬性關卡：在完成此步驟且獲得使用者批准計畫之前，不得進入行業基準檢查或 PRD 生成階段。
顯式跳過協議（使用者明確拒絕互動時）：如果使用者明確禁止提問（例如「別問了，直接寫」），你可以跳過互動關卡 — 但之後你必須在輸出開頭加入一個假設聲明區塊，列出所做的每一項假設（情境、選擇/排除的章節、目標產品、關鍵預設值），讓使用者可以修正。假設聲明同時充當證據紀律的完整度清單：未確認資訊標【待確認】、無證據斷言標【未驗證】（見下文證據紀律），不得腦補填默認值。絕不可以在未告知的情況下跳過。
情境偵測與背景蒐集完成後：
-
差距分析：將使用者提供的資訊與此情境的「背景要求」進行比對。列出每一項缺失的必要欄位。同時檢查
docs/product/中是否有現有的感知數據（market-analysis.json, competitive-analysis, user-research.json, positioning.md）。 -
一次只問一個問題：對於每一項缺失項目，使用
AskUserQuestion並提供多選項向使用者提問。請勿將多個問題打包在同一則訊息中。缺失項目 範例問題 UI 截圖 「當前功能的介面狀態，你如何提供？」→ A. 已有截圖 B. 有 HTML 檔案 C. 有線上連結 D. 暫無，先跳過 競品列表 「需要分析哪些競品？」→ 多選 + 「其他」 目標用戶 「目標用戶是？」→ A. 已定義人物誌 B. 我口述你來整理 C. 需要先做用戶研究 參考產品 「有參考產品嗎？」→ A. 有，我來說 B. 你幫我搜尋業界標竿 C. 不需要參考 -
處理缺失素材：如果使用者說「我之後再提供截圖」或「先跳過」，則記錄哪些項目待補，並在 PRD 計畫中將其標記為
[待補充]。 -
生成 PRD 計畫：準備（但暫不顯示）PRD 計畫結構。下表顯示了帶有預設選擇的範本：
### 預計生成的 PRD 章節 | 章節 | 內容概要 | 選中 | 依賴狀態 | |:-----|:---------|:-----|:---------| | 第0章 行業對標分析 | 將研究 X 個標杆產品 | ✅ | 已完成 / [待補充] | | 第1章 項目概述 | 基於使用者描述展開 | ✅ | 已完成 | | 第2章 業務分析 | 目標用戶 X，痛點 Y | ✅ | 已完成 / [待補充] | | 第3章 功能需求 | [關鍵功能列表] | ✅ | 已完成 | | 第4章 非功能性需求 | 行業標準要求 | ✅ | 自動生成 | | 第5章 用戶體驗流程 | 基於功能推導 | ✅ | 需 UI 補充 | | 第6章 項目風險 | 基於功能複雜度 | ✅ | 自動生成 | | 第7章 合規建議 | 基於資料類型 | ❌ | 自動生成 | | 第8章 原型設計 | [原型連結] | ❌ | - | | 第9章 成功指標 | 基於目標推導 | ❌ | 自動生成 | ### 排除清單（不生成以下內容） - 技術方案 / 架構設計 — PRD 為產品需求文件，不包含技術實作細節 - API 介面定義 / 端點規格 — 由開發團隊在技術方案中另寫 - 資料庫表結構設計 — 不在產品需求範圍內注意： 上表使用預設選擇。實際的「選中」值將在步驟 4.5 中根據使用者對章節選擇的回應來填入。目前請勿向使用者展示此表。
4.5. 章節選擇（硬性關卡 — 在呈現 PRD 計畫之前）：
透過 AskUserQuestion 並使用多選功能向使用者呈現章節選擇。由於最多 4 個選項的限制，請分為 3 個連續問題。根據回應建立 selected_chapters（已選章節）和 excluded_chapters（排除章節）列表，並相應更新 PRD 計畫表的「選中」欄。
問題 1 — 核心章節（第 0-3 章）：
| 選項 | 預設 | 說明 |
|---|---|---|
| 第0章 行業對標分析 | ✅ 已選 | 研究標杆產品與最佳實踐 |
| 第1章 項目概述 | ✅ 已選 | 專案背景、目標、範圍 |
| 第2章 業務分析 | ✅ 已選 | 目標用戶、痛點、市場分析 |
| 第3章 功能需求 | ✅ 已選 | 功能列表、使用者故事、詳細需求 |
問題 2 — 延伸章節（第 4-7 章）：
| 選項 | 預設 | 說明 |
|---|---|---|
| 第4章 非功能性需求 | ✅ 已選 | 效能、安全性、可用性、相容性 |
| 第5章 用戶體驗流程 | ✅ 已選 | 使用者旅程、頁面流程圖 |
| 第6章 項目風險 | ✅ 已選 | 專案風險與因應策略 |
| 第7章 合規建議 | ⬜ 未選 | 合規指引與風險類別 |
問題 3 — 可選章節（第 8-9 章）：
| 選項 | 預設 | 說明 |
|---|---|---|
| 第8章 原型設計 | ⬜ 未選 | 原型連結與設計備註 |
| 第9章 成功指標 | ⬜ 未選 | 北極星指標、過程指標與結果指標 |
永久排除（不在選擇清單中，絕不生成）：
- 技術方案 / 架構設計 — PRD 不包含技術實作細節
- API 介面定義 — 介面文件由開發團隊另寫
- 資料庫表結構設計 — 不在產品需求範圍內
收集選擇後： 更新 PRD 計畫表的「選中」欄，反映使用者的選擇（✅ 為已選，❌ 為排除）。
-
使用者批准：使用
AskUserQuestion呈現 PRD 計畫（含章節選擇），並獲得明確批准：選項 說明 確認，依此章節方案生成 PRD 進入步驟 1 行業基準和步驟 2 PRD 生成 調整章節選擇 重新勾選要生成的章節 需要調整方案 修改 PRD 計畫後重新確認 我有更多資訊要補充 回到步驟 0.5 補充資訊，重新生成方案 先補充感知數據 調用 market-research / competitive-analysis
反模式：「我已有足夠資訊，直接生成吧」— 禁止。即使差距極小，也必須呈現計畫並獲得批准。
TUI 環境下的圖片處理指南
在終端機 (TUI) 環境下，使用者可以透過以下方式提供圖片：
方式一：本地檔案路徑（最簡單）
直接提供圖片的本地路徑，使用 Read 工具讀取：
# 使用者對話範例
"分析這個 UI 截圖: /Users/fh/Desktop/screenshot.png"
"當前介面: ~/Screenshots/ui-2025-03-12.png"
"參考圖片: ./docs/product/images/reference.png"
支援的路徑格式：
- 絕對路徑:
/Users/fh/Desktop/screenshot.png - 家目錄縮寫:
~/Screenshots/ui.png - 相對路徑:
./images/ui.png
支援的圖片格式： PNG, JPG, JPEG, WebP, GIF
方式二：線上圖片 URL
使用者將圖片上傳到圖床/雲端儲存後提供 URL：
# 使用者對話範例
"UI 截圖: https://i.imgur.com/xyz.png"
"參考圖: https://s3.aws.com/bucket/screenshot.png"
使用 mcp__4_5v_mcp__analyze_image 或 mcp__zai-mcp-server__ui_to_artifact 工具讀取遠端圖片。
推薦圖床：
- imgur.com (免費，無需註冊)
- GitHub (作為 issue 附件)
- 雲端儲存 (AWS S3, 阿里雲 OSS)
方式三：終端機截圖命令
引導使用者使用終端機截圖工具快速生成截圖：
macOS:
# 截取選定區域（互動式）
screencapture -i ~/screenshot.png
# 截取整個視窗
screencapture -w ~/screenshot.png
# 截取整個螢幕
screencapture ~/screenshot.png
Linux:
# ImageMagick (需先安裝: sudo apt install imagemagick)
import ~/screenshot.png
# gnome-screenshot (Ubuntu/GNOME)
gnome-screenshot -a -f ~/screenshot.png
#spectacle (KDE)
spectacle -r -o ~/screenshot.png
方式四：剪貼簿直接取得（macOS）
# 安裝 pngpaste 工具
brew install pngpaste
# 將剪貼簿的圖片儲存為檔案
pngpaste ~/screenshot.png
處理流程
當使用者提供圖片後：
- 本地路徑 → 使用
Read工具直接讀取 - 遠端 URL → 使用
mcp__4_5v_mcp__analyze_image或mcp__zai-mcp-server__ui_to_artifact - 分析圖片內容 → 提取 UI 結構、佈局、互動元素
- 生成 PRD → 基於圖片分析結果生成需求文件
行業基準檢查
完成情境偵測、背景蒐集與資訊釐清後：
- 使用者提供的基準（優先）：使用者指定的參考產品
- 代理輔助搜尋：基於情境關鍵字自動搜尋行業最佳實踐
- 提取最佳實踐：3-5 個基準互動模式/功能設計
- 在 PRD 中引用：引用基準解決方案，並說明採納/差異化的理由
搜尋關鍵字對應表：
| 情境 | 搜尋關鍵字 |
|---|---|
| 迭代更新 | "{功能名} 最佳實踐", "行業 {功能名} 設計" |
| 新功能 | "{產品類型} {模組名} 方案", "同類產品 {功能}" |
| 0-1 新產品 | "{行業} 產品框架", "{領域} 產品地圖" |
運作方式
生成流程確保 PRD 完整且可執行：
- 情境偵測 - 使用 AskUserQuestion 識別迭代/新功能/新產品
- 背景蒐集 - 根據情境類型收集必要資訊
- 資訊差距分析 - 識別遺漏資訊，一次只問一個問題
- 章節選擇 - 使用者選擇要生成的 PRD 章節（多選）
- PRD 計畫呈現 - 呈現帶有章節選擇的計畫，供使用者批准（硬性關卡）
- 行業基準研究 - 搜尋並提取最佳實踐（使用者指定 + 代理搜尋）
- 解析需求 - 將使用者的功能請求結構化為關鍵元件
- 收集背景資訊 - 讀取市場分析、競爭洞察、用戶研究
- 組裝章節 - 僅建立被選中的 PRD 章節，並提供適當細節
- 驗證完整度 - 根據品質標準檢查（僅限已選章節）
- 交付前自我審查 - 執行 PRD 預審尾門（章節自我檢查 + 利害關係人視角挑戰）；修正阻礙項目或標記【待確認】
- 生成輸出 - 寫入
docs/product/prd/{feature-name}-{date}-v{version}.md（含尾部「預審記錄」一節）
內容限制（硬性規則）：
在生成 PRD 內容之前，請注意：
- 僅生成使用者選擇的章節。完全跳過未選章節。
- 無論使用者輸入為何，一律不生成以下內容類型：
- 技術架構 / 實作細節
- API 端點定義或規格
- 資料庫綱要或表格設計
- 如果使用者的功能描述提及技術細節，將其歸納為功能需求，不揭露實作細節。
輸入參數
| 參數 | 類型 | 必填 | 說明 |
|---|---|---|---|
requirements | string | 是 | 要記錄的功能描述或使用者故事 |
target_audience | string | 否 | 目標用戶區隔或人物誌 |
context_refs | list | 否 | 要參考的相關背景檔案 |
證據紀律
- 遺漏資訊標記【待確認】：任何無法從輸入或上下文獲得的資訊，標記為【待確認】，不得腦補填默認值。
- 證據追溯【未驗證】：使用者需求/市場斷言必須追問證據來源；無證據的標記為【未驗證】並註明所需驗證方式。
- 完整度檢查關卡：正式輸出交付物前，先輸出資訊完整度清單（已確認 ✅ / 待確認 ⚠️ / 未驗證 ❓），經使用者確認後才生成正文。
與顯式跳過協議（步驟 0.5）的關係: 證據紀律是輸出紀律（資訊標註與交付前自查），顯式跳過是互動紀律（使用者明確拒絕互動時的降級處理），兩者互補不衝突。顯式跳過場景下完整度清單不免除 — 與「假設聲明」合併輸出，但不再等待使用者確認；假設聲明中的未確認資訊同樣依本節規則標註【待確認】/【未驗證】。
輸出結構
PRD 遵循以下結構（與標準 PRD 範本對齊）。重要：此範本顯示所有可能的章節。僅生成使用者選擇的章節。完全跳過未選章節。無論在任何情況下，都不得生成技術架構、API 規格或資料庫設計。
# [功能名稱] PRD
## 文件基本資訊
- **文件版本**: v1.0
- **建立日期**: YYYY-MM-DD
- **最後更新**: YYYY-MM-DD
- **文件狀態**: Draft/Review/Approved
- **建立人**: [使用者名稱]
- **審閱人**: [待定]
## 修訂記錄
| 版本 | 日期 | 修訂內容 | 修訂人 |
|:-----|:-----|:---------|:-------|
| v1.0 | YYYY-MM-DD | 初始版本 | [建立人] |
## 0. 行業對標分析
### 0.1 參考產品
| 產品 | 關鍵功能 | 採納/差異化 |
|:-----|:---------|:-----------|
| [競品A] | XXX | 採納其 XXX 模式，因為... |
| [競品B] | XXX | 差異化點在於... |
### 0.2 最佳實踐總結
- **互動模式**: [採用的行業標準互動模式]
- **核心差異化**: [本方案的獨特之處]
## 1. 項目概述
### 1.1 項目背景
[市場背景、競爭背景、用戶需求背景]
### 1.2 項目目標
#### 1.2.1 核心目標
- [可量化的核心目標]
#### 1.2.2 次要目標
- [支撐性目標]
### 1.3 項目範圍
#### 1.3.1 包含範圍
- [本次迭代/功能包含的內容]
#### 1.3.2 不包含範圍
- [明確不在本次範圍內的事項]
## 2. 業務分析
### 2.1 目標用戶
| 用戶角色 | 描述 | 核心需求 |
|:---------|:-----|:---------|
| 用戶A | [來自用戶研究] | XXX |
| 用戶B | [來自用戶研究] | XXX |
### 2.2 用戶痛點
| 痛點ID | 痛點描述 | 影響程度 |
|:-------|:---------|:---------|
| P-001 | XXX | 高/中/低 |
| P-002 | XXX | 高/中/低 |
### 2.3 市場分析
[行業趨勢、競爭格局、市場機會點]
## 3. 功能需求
### 3.1 核心功能列表
| 功能ID | 功能名稱 | 優先級 | 描述 |
|:-------|:---------|:-------|:-----|
| F-001 | XXX | P0/P1/P2 | XXX |
| F-002 | XXX | P0/P1/P2 | XXX |
### 3.2 使用者故事
#### US-1: [功能名稱]
**作為** [用戶角色]
**我希望** [功能描述]
**以便** [業務價值]
**驗收標準**:
- Given [前置條件]
- When [執行操作]
- Then [預期結果]
**優先級**: P0/P1/P2
**估算**: X Story Points
#### US-2: [功能名稱]
...
### 3.3 功能詳情
#### F-001: [功能名稱]
**描述**: [詳細功能描述]
**互動流程**:
1. 步驟一
2. 步驟二
3. 步驟三
**邊界情況**:
- 正常流程: ...
- 異常情況: ...
## 4. 非功能性需求
### 4.1 效能需求
- 頁面回應時間 < XXXms
- 支援 XXX 並發用戶
### 4.2 安全需求
- 數據加密儲存
- 用戶權限控制
### 4.3 可用性需求
- 系統可用性 > 99.9%
### 4.4 相容性需求
- iOS 14+, Android 10+
- 主流瀏覽器相容
## 5. 用戶體驗流程
### 5.1 用戶旅程
[關鍵用戶路徑描述]
1. 用戶進入 → 2. 執行操作 → 3. 達成目標
### 5.2 頁面流程圖
[頁面跳轉關係說明]
- 頁面A → 頁面B → 頁面C
## 6. 項目風險與應對
> 註：本節僅包含產品/業務風險，不包含技術實作風險（技術風險由開發團隊在技術方案中評估）
| 風險ID | 風險描述 | 機率 | 影響 | 應對措施 |
|:-------|:---------|:-----|:-----|:---------|
| R-001 | XXX | 高/中/低 | 高/中/低 | XXX |
| R-002 | XXX | 高/中/低 | 高/中/低 | XXX |
## 7. 合規建議
### 7.1 合規要點概述
[合規專家審查的關鍵要點摘要]
### 7.2 風險提示
| 風險類別 | 說明 | 建議 |
|:---------|:-----|:-----|
| 隱私合規 | [涉及用戶數據的處理方式] | [合規建議] |
| 內容合規 | [涉及的內容審核要點] | [合規建議] |
| 數據安全 | [數據儲存和傳輸要求] | [合規建議] |
| 第三方合規 | [依賴的第三方服務合規性] | [合規建議] |
### 7.3 合規報告附件
- [ ] 合規分析報告已附 (如果有，提供路徑)
- [ ] 等待合規審查 (如需要，安排合規專家評審)
[此處後續內容因翻譯而被截斷]