官方技能 · 產品

從雜亂筆記寫 PRD

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

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

加入我團隊的 Pod

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

適用情境

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

你要提供的內容

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

你會得到的內容

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

運作方式

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

分享給你的團隊

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