---
name: prd-from-notes
description: 把雜亂的筆記、Slack 討論串、通話記錄或創辦人隨手寫下的想法，整理成產品需求文件（PRD）：問題和證據、使用者、目標和非目標、成功指標、Must／Should／Could 需求、待解問題和風險。遇到缺口會標出來，不會自行編造。適用於有人要從零散的筆記寫 PRD、規格書（spec）、一頁式說明（one-pager），或說「把這個寫下來，讓工程團隊可以開發」時。
---

# 從筆記寫 PRD

好的 PRD 讓工程師和設計師不用開會就能開始工作，也讓讀者看得出哪些是已知、哪些是猜測。先寫問題再寫解法，每項需求都連回問題，每個缺口都要明白標出來：藏住缺口的 PRD 會被做錯。

## 適用情境

- 手上有某個功能的筆記、Slack 討論串、通話記錄或客戶原話，需要一份 PRD。
- 創辦人在一通電話或一場白板討論後說「幫團隊把這個寫下來」。
- 有人想在決定要不要做之前，先看一份一頁的說明。
- 不適用於審查完成的 PRD：請用 spec-review。不適用於把工作拆成工單：請用 user-stories。

## 需要準備

- 原始材料：筆記、討論串、逐字稿、客戶原話、用文字描述的截圖。
- 筆記沒寫的話，這個功能是給誰用的。問一次；還是沒有時，寫「[假設：目標使用者]」。
- 已知的期限、限制或指標目標。沒有的話，目標值寫「[待定：尚未設定目標]」。

## 步驟

1. **找出問題和它的證據。** 回答 Marty Cagan 機會評估的第一個問題：這解決什麼問題？為誰解決？把問題寫成使用者現在做不到什麼，或這件事讓他們付出什麼代價。在底下列出證據：客戶原話、工單數量、輸掉的案子、數字。筆記裡沒有證據時，寫「筆記中沒有證據」，不要編一個理由。
2. **寫出使用者。** 一個主要使用者，最多 2 個次要使用者，每個都寫出問題發生時他們身處的情境。「小企業老闆」太廣；「第一次用手機開發票的老闆」才對。
3. **分開目標和非目標。** 目標是成果，不是功能。至少寫 2 個非目標；筆記裡討論過後放棄的東西都放這裡，免得有人再把它翻出來。
4. **設定成功指標。** 一個主要指標，問題解決時它會變動；再加 1 到 2 個不能變差的防護指標（guardrail）。每個都要有基準值和目標值；筆記沒給的話，寫「[待定：基準值]」和「[待定：目標值]」。
5. **用 Must／Should／Could（MoSCoW）寫需求。** Must＝沒有它，解法就不成立。Should＝很重要，少了會很痛，但有替代做法。Could＝有了更好，期限有風險時第一個被砍。Won't（這次不做）放進非目標，免得被悄悄加回來。每一行都要可以測試（「使用者可以匯出成 CSV」），不要模糊（「匯出很方便」）。Agile Business Consortium 的指南把 Must 控制在通常不超過 60% 的工作量；如果 Must 看起來超過這個比例，就寫明範圍太大，一次發布做不完。
6. **列出待解問題和風險。** 兩份筆記之間的每個矛盾都變成一個待解問題，並寫出雙方的立場。風險涵蓋可能讓功能失敗的因素：採用率、技術、法律、依賴其他團隊。筆記有寫負責人時，每項都標上負責人。
7. **標出每個說法的來源。** 來自筆記的事實直接寫。你推論出來的內容都加上「[假設]」。輸入裡沒有的數字、日期或客戶名稱，絕不自己填上。

## 輸出格式

```markdown
# PRD：[功能名稱]

**撰寫者：** [姓名] · **狀態：** 草稿 · **最後更新：** [日期]

## 問題
[2 到 4 句：使用者現在做不到什麼，以及這讓他們付出什麼代價。]

**證據**
- [客戶原話、數量或資料，附來源]

## 使用者
- **主要：** [誰，在什麼情境]
- **次要：** [誰，在什麼情境]

## 目標
- [成果]

## 非目標
- [這次發布不做什麼；知道原因的話寫出原因]

## 成功指標
| 指標 | 類型 | 基準值 | 目標值 |
|---|---|---|---|
| [指標] | 主要 | [數值或待定] | [數值或待定] |
| [指標] | 防護 | [數值或待定] | [不得低於……] |

## 需求
| # | 需求 | 優先度 | 備註 |
|---|---|---|---|
| R1 | [可測試的敘述] | Must | [來源或假設] |

## 待解問題
- [問題] — [負責人，如果知道]

## 風險
- [風險] — [因應方式或「尚無」]

## 筆記中的缺口
- [開發前團隊必須決定、但筆記沒有的內容]
```

## 範例

**輸入（節錄）：**

> Slack，何佩珊（客服）：這週有 3 位客戶問，能不能邀請他們的會計師，但不用多付一個席次的錢。
> 通話記錄，邱建宏（創辦人）：「唯讀席次？也許免費。我還不想做角色權限。」
> 蘇柏翰（工程）：每個寫入的 API 端點都要加權限檢查，大概要 2 週。

**輸出：**

```markdown
# PRD：給會計師的免費唯讀席次

**撰寫者：** [姓名] · **狀態：** 草稿 · **最後更新：** [日期]

## 問題
客戶如果不付一個完整席次的錢，就沒辦法讓會計師查看他們的帳。

**證據**
- 一週內 3 位客戶提出要求（何佩珊，客服，Slack）。

## 使用者
- **主要：** 每個月需要會計師檢查數字的帳號擁有者。
- **次要：** 會計師，只查看、從不修改。

## 目標
- 擁有者不用多付席次費，就能讓外部的檢查者取得存取權限。

## 非目標
- 完整的角色和權限系統（邱建宏：「我還不想做角色權限」）。
- 會計師的修改權限：席次只能唯讀（邱建宏：「唯讀席次？」）。

## 成功指標
| 指標 | 類型 | 基準值 | 目標值 |
|---|---|---|---|
| 擁有 1 個以上唯讀席次的帳號數 | 主要 | 0 | [待定：目標值] |
| 付費席次數 | 防護 | [待定：基準值] | 不下降 |

## 需求
| # | 需求 | 優先度 | 備註 |
|---|---|---|---|
| R1 | 擁有者可以用電子郵件邀請某人成為唯讀使用者 | Must | 何佩珊收到的要求 |
| R2 | 唯讀使用者不能建立、修改或刪除任何東西 | Must | 蘇柏翰：每個寫入端點都要檢查 |
| R3 | 唯讀席次不計入計費 | Must | 邱建宏：「也許免費」（待確認） |
| R4 | 擁有者可以移除唯讀使用者 | Should | [假設] |

## 待解問題
- 席次是免費，還是用較低的價格？邱建宏說「也許免費」。 — 邱建宏
- 每個帳號可以有幾個唯讀席次？ — 沒有討論到

## 風險
- 付費使用者為了省錢，把同事降成唯讀。 — 考慮每個帳號設上限

## 筆記中的缺口
- 沒有採用率的目標。
- 沒有提到會計師第一次登入時會看到什麼。
- 沒有提到客戶現在怎麼把帳交給會計師。
```

## 寄出前檢查

- [ ] 問題段落寫出了使用者和代價，而且完全沒提到解法。
- [ ] 每個數字、名字和引句都出現在輸入中；其他內容都標上「[假設]」或「[待定]」。
- [ ] 每項需求都可以測試且有優先度；Must 項目看起來占工作量 60% 以下。
- [ ] 至少有 2 個非目標。
- [ ] 筆記中的每個矛盾都列為待解問題。
- [ ] 主要指標有基準值和目標值，或兩者都標為待定。

## 常見錯誤

- 把解法寫進問題（「使用者需要唯讀角色」）。問題是哪裡痛，不是你要做什麼。
- 把兩個人的意見分歧輕輕帶過。兩邊都引用，並保持待解。
- 寫「使用者滿意度」這種沒辦法衡量的指標。寫出你會去計算的事件或數字。