官方技能 · 產品

從雜亂筆記寫 PRD

v1.0.0 · 2026 年 11 月 4 日 更新

把筆記、Slack 討論串和通話記錄整理成 PRD：問題和證據、目標和非目標、指標、Must／Should／Could 需求，並標出缺口。

可在 Claude、ChatGPT 和程式設計代理中使用。使用 Team 和 Business 方案時，我們改進官方技能後，你 Pod 裡的這個技能會自動更新。

適用情境

• 手上有某個功能的零散筆記或討論串，需要一份團隊能照著開發的 PRD
• 創辦人在通話或白板討論後請你「把這個寫下來」

你要提供的內容

• 筆記、討論串、逐字稿或客戶原話
• 目標使用者（選填）
• 期限或指標目標（選填）

你會得到的內容

一份 Markdown 格式的 PRD，包含問題、證據、使用者、目標、非目標、指標表、排好優先度的需求、待解問題、風險和缺口。

運作方式

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. 標出每個說法的來源 來自筆記的事實直接寫。你推論出來的內容都加上「[假設]」。輸入裡沒有的數字、日期或客戶名稱，絕不自己填上。

SKILL.md 檔案

完整檔案，就是你的 AI 讀到的內容。 下載檔案

---
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 個非目標。
- [ ] 筆記中的每個矛盾都列為待解問題。
- [ ] 主要指標有基準值和目標值，或兩者都標為待定。

## 常見錯誤

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

分享給你的團隊

把它加入 AI Skill Pod，團隊每個人（外包人員也包括在內）都能從自己的 AI 使用同一個版本。 看看和團隊分享 AI 技能的最佳做法

加入我團隊的 Pod

更新紀錄

• v1.0.0 · 2026 年 11 月 4 日 · First release.