DotMD
下載 Mac 版

Markdown PRD 範本：複製後填寫即可。

產品需求文件（PRD）最容易維護的方式，是放在程式碼旁邊的 .md 檔案。這份範本簡短，使用編號需求與可檢查的驗收條件，並寫成 AI 代理程式可以據以開發的形式。

下載 Mac 版

需要 macOS 14 或以上版本。閱讀免費；編輯與審閱為一次付費。

快速解答

好的 PRD 會寫明問題、目標與不在範圍內的事項，然後列出編號需求，並附上可以檢查的驗收條件。把它存成 prd.md 或 docs/prd/feature-name.md，複製下方範本，以平實的句子填寫每個區段。

# PRD: <Feature name>

## 1. Problem
## 2. Goals
## 3. Non-goals
## 5. Requirements
## 6. Acceptance criteria

·

範本

把它複製到新檔案，並替換所有角括號中的內容。只有在你確定不適用時才刪除區段，並寫「none」而不是留空，讓讀者知道這部分有被考慮過。

# PRD: <Feature name>

Status: Draft | In review | Approved
Owner: <name>
Last updated: <date>

## 1. Problem
Who has the problem, what it is, and what it costs them today.
One short paragraph. No solution here.

## 2. Goals
- <Outcome 1, measurable>
- <Outcome 2, measurable>

## 3. Non-goals
Things this work will NOT do, so nobody builds them by accident.
- <Not in scope 1>
- <Not in scope 2>

## 4. Users and scenarios
- As a <role>, I want <action>, so that <benefit>.
- As a <role>, I want <action>, so that <benefit>.

## 5. Requirements
Number each one so it can be referenced in plans and tests.
- R1. The system must <behavior>.
- R2. The system must <behavior>.
- R3. The system should <optional behavior>.

## 6. Acceptance criteria
- [ ] R1: Given <state>, when <action>, then <result>.
- [ ] R2: Given <state>, when <action>, then <result>.

## 7. Edge cases and errors
- <Empty state>
- <Invalid input>
- <Network or permission failure>

## 8. Data and interfaces
- Data stored or changed: <fields, formats, migrations>
- APIs or screens affected: <names>

## 9. Success metrics
- <Metric>: from <baseline> to <target> by <date>.

## 10. Rollout and rollback
- Release plan: <flag, staged, all at once>
- How to turn it off if it goes wrong: <step>

## 11. Open questions
- [ ] <Question> (owner: <name>)

## 12. Context for the agent
Files to read first: <paths>. Constraints: <stack, style, limits>.

為什麼這樣寫

給 AI 代理程式的 PRD 與給人的 PRD 任務相同，只是猜測的空間更小。人會在走廊上問你是什麼意思，代理程式則會用它最好的猜測填補空白，然後繼續做下去。

  • 非目標是防止範圍蔓延最便宜的保護。除非告訴代理程式不要，它會加上「貼心的」額外功能。
  • 編號需求（R1、R2）讓計畫、測試與審查留言都能指向同一件事。
  • 以待辦清單核取方塊撰寫的驗收條件，會變成可以逐項勾掉的待辦清單。語法請見 Markdown 待辦清單。
  • 邊界情況是產生的程式碼最先失敗的地方：空資料、錯誤輸入、斷線。
  • 回復迫使你在上線前就想好如何撤銷這次變更。

如何填寫

  1. 寫問題，不要寫解法

    如果你無法在不提到某個功能的情況下描述問題，那個功能就只是猜測。說明誰受到影響，以及現在發生了什麼事。

  2. 讓每個目標都可衡量

    「更快的結帳」只是願望。「結帳時間中位數低於 30 秒」才是目標。

  3. 把需求寫成行為

    「檔案大於 10 MB 時，系統必須顯示錯誤」可以測試。「良好的錯誤處理」不行。

  4. 每個需求配一個條件

    使用 Given、when、then。如果你寫不出檢查方式，這個需求就太模糊。

  5. 以未解決的問題作結

    為每一項指定負責人。代理程式應該針對這些問題發問，而不是自己決定。

圖表有助於說明流程與狀態；檔案中的 Mermaid 區塊容易修改。請見 Mermaid 流程圖語法。

把 PRD 交給 AI 代理程式

讓代理程式去讀檔案，而不是把內容貼給它：「請讀 docs/prd/export.md 並提出計畫；先不要寫程式碼。」先要求計畫，對照編號需求檢查，再讓它開發。PRD、計畫與任務清單通常是三個獨立的檔案。PRD 說明做什麼與為什麼，計畫說明怎麼做，任務則是各個步驟。

專案通用的規則（指令、風格、資料夾）不要放在 PRD，而是放在 CLAUDE.md 或 AGENTS.md，讓 PRD 只包含這項功能特有的內容。

常見錯誤

  • 偽裝成問題的解法。「我們需要一個下拉選單」不是問題。
  • 沒有非目標。附近的一切都變成範圍內。
  • 不可能失敗的需求。如果沒有任何測試可能讓它失敗，它就什麼也沒說。
  • 沒人再讀的 PRD。隨著進度更新狀態與未解決的問題。
  • 小變更卻寫十頁。只要一天就做完的功能，半頁就夠了。

產品經理可以在 DotMD 中把 PRD 當作渲染後的文件來閱讀與審查，並在確切的段落上留言。閱讀免費；編輯與審查請見價格。

關於 Markdown PRD 範本的常見問題

PRD 範本包含哪些內容？

問題、目標、非目標、使用者情境、編號需求、驗收條件、邊界情況、資料與介面、成功指標、上線與回復，以及未解決的問題。

為什麼用 Markdown 寫 PRD？

Markdown 檔案放在程式碼旁邊，在 Git 中有易讀的歷史，AI 代理程式容易讀取，也能像其他檔案一樣被審查與修改。

檔案應該取什麼名稱？

單一產品用 prd.md，有多個時用 docs/prd/feature-name.md。一個檔案只放一項功能。

PRD 與規格有什麼不同？

PRD 從使用者的角度說明要做什麼與為什麼。規格或計畫則說明會怎麼做。把它們分開，讓每一份都能單獨審查。

更多問題

其他文章

AI 規格審查檢查表 CLAUDE.md 與 AGENTS.md 的差異 Markdown 待辦清單 Mermaid 流程圖

指南

規格驅動開發 註解 Markdown 速查表