prd-template

name: prd-templatelanguage: zh-TWdescription: "按經過驗證的產品經理模板結構撰寫產品需求文件（PRD）。當被要求寫 PRD、產品規格、功能說明或新功能、新產品的需求文件時使用。產出完整的 PRD：問題陳述、使用者故事、功能需求、技術考量和成功指標。"

prd-template 的繁體中文翻譯，英文版本為規範版本。

PRD 模板

這個技能幫助按行業最佳實踐撰寫專業的產品需求文件。

它在流程中的位置：主線的中間

產品決策主線的第二步：/assumption-mapper → prd-template → /rice-prioritisation → /roadmap-narrative。它從 /assumption-mapper 接收風險最大的假設（如果那一步執行過，讀它的圖譜，而不是重新猜風險），並把 PRD 的成功指標交給 /rice-prioritisation：那個有基線的數字會成為 RICE 的 Impact。共享術語（問題陳述、假設、成功指標、來源標註）統一定義在 docs/craft/product-decisions.md；請嚴格使用。

迴圈

PRD 由外而內撰寫：永遠先問題、後方案，分四個階段。第一階段是承重牆：建立在模糊問題上的 PRD，從頭到尾再精緻也是錯的。

1. 鎖定問題陳述。 一句話：誰、在什麼時候、有什麼問題，以及放任不管的代價。不出現任何方案用語。下面的一切都必須向它歸結。 完成標準： 問題陳述獨立成立，沒有提到任何功能，陌生人也能看出"解決了"是什麼意思。
2. 給成功指標定基線。 證明問題已解決的那一個數字，附當前基線和算作成功的變化幅度。把上游 /assumption-mapper 的風險作為待定問題帶到這裡，而不是默默押注。 完成標準： 指標有基線（或明確標註為沒有基線），並且它衡量的是問題，而不是活動。
3. 起草各部分，每一部分向上追溯。 填寫下面的模板，讓每條需求和故事都追溯到問題陳述；追溯不到的刪掉。給事實標註來源：猜的數字是 [hunch]，要標出來。 完成標準： 每條需求都追溯到問題陳述，每個聲稱的事實都帶有 [data] / [hunch] / [assumption]。
4. 交接。 寫明成功指標和計劃項，讓 /rice-prioritisation 能用這個指標給 Impact 打分，而不是重新發明一個。 完成標準： PRD 寫明瞭 /rice-prioritisation 打分所需的指標和範圍，無需再問。

所需輸入

如未提供，請向使用者詢問：

• 功能或產品名稱
• 要解決的問題（從使用者的角度）
• 目標使用者（角色、場景、想完成什麼）
• 成功指標（你怎麼知道它奏效了？）
• 範圍（MVP 還是完整願景：什麼在範圍內，什麼不在）
• 關鍵干係人（誰需要審閱和批准）

從大腦讀取 / 寫入大腦

如果存在 professional-brain（brain/），用它，而不是詢問你已經有的背景：

• 先讀： context.md（產品、指標定義、語氣）、knowledge/strategy.md（產品方向）、相關的 hypotheses/ 和對應的 entities/ 功能檔案。執行 python3 ../professional-brain/scripts/brain_query.py ./brain "<feature>" 獲取有依據的事實，並把它們的來源標註帶進 PRD（不要把 [hunch] 當作確定的需求）。
• 之後寫： 把功能儲存為或寫入 entities/<feature>.md，把範圍決策記入 decisions/，把新的假設加入 hypotheses/。每條都標註來源。

延伸材料

這個技能附帶兩份支援檔案，可用時請使用：

• templates/prd-skeleton.md：可填寫的 PRD 骨架，每個部分都有"好的樣子"提示。當使用者想自己完成文件而不是生成草稿時，從它開始。
• references/success-metrics-guide.md：成功指標部分的校準：四項指標測試、標準的採用 / 結果 / 業務 / 護欄指標組合，以及常見陷阱。撰寫或審閱指標表時參考。

模板結構

每份 PRD 都應按順序包含以下部分：

1. 概述

• 問題陳述：我們在解決什麼問題？（2 到 3 句）
• 方案概要：我們要做什麼的高層描述（2 到 3 句）
• 成功指標：如何衡量成功（3 到 5 個關鍵指標）

2. 背景

• 為什麼是現在：為什麼現在是合適的時機？
• 戰略對齊：它如何與公司目標對齊？
• 使用者研究摘要：研究的關鍵洞察（如適用）

3. 使用者故事與使用場景

格式："作為 [使用者型別]，我想要 [行動]，以便 [好處]"

• 包含 3 到 7 個主要使用者故事
• 每個故事都加上驗收標準

4. 需求

功能需求：

• 必須有（P0）
• 應該有（P1）
• 最好有（P2）

非功能需求：

• 效能預期
• 安全考量
• 無障礙要求

5. 設計與使用者體驗

• 設計稿或線框圖連結
• 關鍵使用者流程
• 邊界情況和錯誤狀態

6. 技術考量

• 架構影響
• 對其他系統的依賴
• 技術風險及應對

7. 實施計劃

• 第一階段（MVP）：第一版包含什麼
• 第二階段：接下來做什麼
• 第三階段：未來的增強

8. 待定問題

• 仍需做出的決定
• 需要諮詢的干係人
• 需要的研究

9. 附錄

• 研究連結
• 相關文件
• 競品分析

寫作指南

語氣：清晰、簡潔、可執行 讀者：工程師、設計師、干係人 長度：功能 3 到 6 頁，產品 8 到 12 頁

最佳實踐：

• 用具體例子，而不是抽象描述
• 寫"為什麼"，而不只是"是什麼"
• 讓需求可測試
• 連結到支援材料
• 隨決策更新

好 PRD 的標準

✅ 要：

• 從使用者的角度寫
• 包含具體的成功指標
• 處理邊界情況
• 連結到研究和資料
• 明確寫出取捨

❌ 不要：

• 寫實現細節（那是技術規格）
• 假設每個人都有背景
• 讓需求含糊不清
• 跳過"為什麼"
• 忘記無障礙

評分量表（0 到 40）

交付前給這個技能的任何產出打分；32 分以上才算可以交付。

品質檢查

• 問題陳述從使用者的角度寫（而不是公司的）
• 成功指標具體、可衡量
• 使用者故事包含驗收標準
• 需求可測試（不含糊）
• 明確列出待定問題
• 實施計劃區分了 MVP 和後續階段

反模式

• 不要從公司的角度寫需求：每條需求都必須追溯到使用者需要
• 不要寫"系統應該很快"這樣含糊的需求：每條需求都必須可測試
• 不要把 MVP 和後續階段混為一談：明確第一版包含什麼、不包含什麼
• 不要讓成功指標只是沒有基線的百分比：寫明當前狀態和目標
• 不要跳過待定問題：未解決的假設就是風險；把它們擺出來是產品經理的工作

PRD 開頭示例

# PRD：多渠道客服工作臺

## 概述

**問題陳述**：客服團隊目前用三個獨立的工具處理來自郵件、線上聊天和社交媒體的客戶諮詢，導致回覆延遲、重複勞動和客戶體驗不一致。平均每位客服每天要浪費 2.3 小時在工具之間切換、手動追蹤對話記錄。

**方案概要**：建設一個統一工作臺，把所有渠道的客戶諮詢彙集到同一個介面，跨渠道保留對話記錄，並根據客服的專長和空閒情況智慧分配。

**成功指標**：
- 平均響應時間從 4 小時降到 1 小時
- 工具切換時間減少 80%（從 2.3 小時降到 0.5 小時以內）
- 客戶滿意度從 3.8 提升到 4.5（滿分 5 分）
- 客服人效提升 35%

## 背景

**為什麼是現在**：過去 6 個月客戶滿意度下降了 15%，主要原因是響應慢。我們最大的競爭對手上季度推出了統一客服工作臺，銷售通話中已經頻繁聽到。客服團隊年流失率達 45%，"工具太複雜"是最常被提到的不滿之一。

**戰略對齊**：這與公司第一季度"客戶留存提升 10%"的目標，以及客服團隊"平均處理時長降低 25%"的 OKR 對齊。

**使用者研究摘要**：我們訪談了 12 位客服，觀察了 20 小時的客服工作。關鍵發現：
- 客服 35% 的時間花在查詢以往互動的背景上
- 65% 的升級是因為缺少對話記錄
- 客服把工具切換評為每天最大的不滿（痛點 9.2 / 10）
- 當前客服體驗的 NPS 為 -12

## 使用者故事與使用場景

**US1：統一收件箱**
作為客服，我想在一個地方看到所有客戶諮詢，以便不錯過緊急請求，並能有效排出優先順序。

驗收標準：
- 收件箱顯示來自郵件、聊天和社交媒體的諮詢
- 諮詢按優先順序排序（緊急、高、普通、低）
- 客服可以按渠道、客戶或狀態篩選
- 新諮詢到達時實時更新

**US2：跨渠道背景**
作為客服，我想看到完整的對話記錄，無論來自哪個渠道，以便給出一致、有依據的回覆，而不必讓客戶重複說明。

驗收標準：
- 時間線檢視按時間順序顯示所有互動
- 每次互動顯示渠道、時間和內容
- 客戶檔案顯示基本資訊和賬戶資訊
- 可以檢視以往的問題和解決方案

[繼續寫滿 5 到 7 個使用者故事……]

示例觸發語

• “寫一份 PRD。”
• “替這個功能寫產品需求文件。”
• “寫功能規格說明。”
• “替新功能寫需求文件。”