產品需求文件範本（附完整實作範例，可直接複製）

產品需求文件範本（附完整實作範例，可直接複製）

最後更新：2026 年 7 月 28 日。

大多數產品需求文件範本頁面只丟給你一張空表格。Atlassian 的版本是四段說明文字，包著一張空白的成效指標表。Product School 的標題掛著「(with Example)」，內容卻沒有任何範例。下面這個 12 章節的 markdown 區塊就是完整範本，不用留信箱、可直接複製貼上。第 4 節接著把這 12 個章節全部填滿，做成一個完整的實作案例：一個用 LLM 讀取 PDF、把可疑項目轉給人工複核的客戶發票入口網站。先複製空白版，再讀填好的版本，最後寫你自己的。

重點摘要

• PRD 回答「要做什麼、為什麼做」；技術設計文件回答「怎麼做」。
• 12 個章節適用於任何規模的專案。單頁版就是同一份範本，只是列數變少。
• 非目標一定要寫下來。AI 編碼代理無法從「沒寫」推論出範圍。
• 驗收標準必須能被機器檢查：「p95 在 400ms 以內」，而不是「要快」。

你該用哪一種 PRD 格式？

依「誰會讀這份文件」來選格式，而不是看產品感覺有多大。單一功能交給自家工程師，用單頁版就夠。交給外部團隊的專案，需要完整的12 章節 PRD，因為驗收標準同時扮演簽核關卡。交給 AI 編碼代理的規格書，則需要把同樣的十二個章節切成階段。

大家常問的單頁版產品需求文件範本其實不是另一份文件。Lenny Rachitsky 廣為流傳的單頁版，在他的電子報裡附了真實範例，骨架完全相同，只是把繁文縟節拿掉了。單頁版不是不同的文件，就是同樣十二個章節，把空白列刪掉而已。

敏捷團隊也常問類似的問題,換個說法就是：PRD 撞上待辦清單之後還撐得住嗎？答案是撐得住，只要用單頁版：PRD 保留「為什麼」與邊界,工單保留實際的工作內容。

PRD 範本（可直接複製的 Markdown）

以下是完整的markdown版本,不用留信箱、可直接複製。貼到 Notion、Confluence、Google Docs、Linear、Word,或直接以 PRD.md 提交到 GitHub,讓它跟著程式碼一起版控。這個範本被要求過九種不同格式,markdown 是唯一一種貼到哪裡都不會壞掉的,也是唯一一種 AI 編碼代理能乾淨讀取的格式。

# PRD: [產品或功能名稱]

## 1. 標頭
- 負責人（產品）：
- 工程負責人：
- 設計負責人：
- 狀態：草稿 | 審查中 | 已核准 | 已上線
- 最後更新：
- 變更歷史：日期／作者／變更內容

## 2. 問題陳述
一段話。誰受影響、多常發生、目前的代價是什麼。不要出現解法用語。

## 3. 目標與成效指標
| 目標 | 指標 | 基準值 | 目標值 | 如何量測 | 日期 |
|---|---|---|---|---|---|

## 4. 非目標
以肯定句寫：「這個階段不包含 X。」

## 5. 使用者與角色
誰使用它、他們已經懂什麼、用什麼裝置、多常使用。

## 6. 使用者故事與驗收標準
身為 [角色]，我想要 [行動]，以便 [結果]。
- 假設 [情境]，當 [事件發生]，則 [可觀察的結果]。

## 7. 功能需求
編號列出。一行一項需求。可測試。句子裡不能出現「以及」。

## 8. 非功能需求
效能／安全性與租戶隔離／資料落地與保留／無障礙／可用性。

## 9. 相依性與整合
外部系統、API、憑證、由誰負責存取、前置時間。

## 10. 里程碑與階段規劃
| 階段 | 範圍 | 結案標準 | 目標日期 |
|---|---|---|---|

## 11. 待解問題與風險
| 問題或風險 | 負責人 | 需要回覆的期限 | 若無解答的影響 |
|---|---|---|---|

## 12. 附錄與連結
設計稿、研究資料、競品筆記、先前的工單、合約。

十二個章節依序是：標頭、問題陳述、目標與成效指標、非目標、使用者與角色、使用者故事與驗收標準、功能需求、非功能需求、相依性與整合、里程碑與階段規劃、待解問題與風險、附錄。

PRD 該包含什麼？12 個章節,以及各自的弱版本

一份產品需求文件應該包含問題陳述、可量測的目標、明確的非目標、使用者角色、附驗收標準的使用者故事、功能與非功能需求、相依性、里程碑、附負責人的待解問題,以及變更歷史。其他一切都算附錄。每一行的檢驗標準,就是 ISO/IEC/IEEE 29148:2018 對一般需求的要求：可驗證、無歧義、單一。

大多數 PRD 都在同樣三個地方沒通過這個檢驗。

有兩個章節值得多花一點心思。

非功能需求是範圍悄悄膨脹的地方。效能、租戶隔離、資料落地、保留期限、無障礙、可用性：每一項都是有成本的工程決策，卻不會出現在使用者故事裡。把安全性寫在這裡,而不是隨便帶過,並且用我們的上線前安全檢查清單當作核對清單來源。如果這個專案有 AI 元件,正式上線就緒的需求也該寫在這裡,而不是留到一個永遠排不進行程的「強化」階段：我們用的是PoC 到正式上線檢查清單這一版。

待解問題需要三欄，不是一欄。問題、負責人、需要回覆的期限。沒有負責人的問題,等於沒有人在做決定,而它會在第六週變成一個變更請求冒出來。值得一提的是：PRD 是你決定自建而非採購之後才會寫的東西。如果問題陳述讀起來還是像一張功能購物清單,代表採購還是自建的決定其實還沒真正做出來。

實作範例：一份填好的發票入口網站 PRD

以下是一個完整的實作範例，12 個章節全部填好。案例：一個為中型物流公司做的客戶發票入口網站。客戶上傳 PDF 發票，LLM 擷取項目明細，系統比對訂單記錄找出不符，任何不確定的項目都會送進人工複核佇列。技術棧：Next.js、Supabase/Postgres,加上一個 LLM 擷取步驟。你可以複製它、印出來、匯出成 PDF,隨你需要。

# PRD: 客戶發票入口網站，第一階段

## 1. 標頭
- 負責人（產品）：客戶端營運總監
- 工程負責人：Techsy 交付負責人
- 設計負責人：Techsy 產品設計師
- 狀態：已核准開發
- 最後更新：2026-07-28
- 變更歷史：
  - 2026-07-14 / 產品 / 初稿
  - 2026-07-21 / 工程 / 為 6.2 加上信心門檻規則
  - 2026-07-28 / 產品 / 把 ERP 回寫移到非目標

## 2. 問題陳述
營運人員以電子郵件收到客戶的 PDF 發票，並手動重新輸入訂單系統。
發票量超過每週 300 張，平均處理時間約 6 分鐘，
約有 4% 帶有鍵入錯誤，且只在月結對帳時才被發現。
每一次更正都要重跑一遍流程,還要再打一通電話。

## 3. 目標與成效指標
| 目標 | 指標 | 基準值 | 目標值 | 如何量測 | 日期 |
|---|---|---|---|---|---|
| 縮短手動處理時間 | 平均處理時間 | 6 分鐘 | 90 秒以內 | 營運儀表板，每週中位數 | 2026-11-01 |
| 降低鍵入錯誤 | 對帳時被更正的發票比例 | 4% | 1% 以內 | 財務月結報表 | 2026-12-01 |
| 控制複核負擔 | 轉入人工複核的比例 | n/a | 25% 以內 | 入口網站佇列指標 | 2026-11-01 |

## 4. 非目標
這個階段不支援多幣別發票、ERP 回寫、客戶端自助退貨單,
或行動應用程式。擷取只涵蓋 PDF。
紙本發票照片與低於 200 DPI 的掃描檔會在上傳時被拒絕,
並顯示原因說明。

## 5. 使用者與角色
- 營運人員（主要，6 人）：整天處理例外佇列，
  對業務有深入了解，只用桌機。
- 客戶端應付帳款窗口（外部，約 140 個帳號）：上傳發票，
  對帳號設定的摩擦容忍度很低。
- 財務經理（次要）：拉取月結報表，需要逐張發票的
  稽核軌跡。

## 6. 使用者故事與驗收標準
6.1 身為客戶端應付帳款窗口，我想要上傳發票 PDF，以便
不用再寄信等回覆。
- 假設一份 20 MB 以內、200 DPI 或以上的 PDF，當我上傳它，
  則入口網站在 5 秒內回傳參考編號並顯示「處理中」。

6.2 身為營運人員，我想要低信心度的擷取結果被擋下，以便
沒有任何錯誤的資料被自動核准。
- 假設一份已解析的發票，當任一項目的擷取信心度
  低於 0.85，則這張發票轉入複核佇列，且絕不
  自動核准。

6.3 身為營運人員，我想要在同一個畫面看到不符之處，以便
不用打開訂單系統就能處理。
- 假設一張發票已比對到訂單，當任一項目的數量或單價
  與訂單記錄不同，則入口網站並排顯示兩邊的數值,
  並標示出差異。

6.4 身為財務經理，我想要篩選發票，以便
完成月結。
- 假設在發票清單畫面，當我依廠商、日期區間與狀態篩選，則
  結果在 400ms p95 內回傳，空狀態顯示「清除
  篩選」。

## 7. 功能需求
1. 上傳只接受 PDF，最大 20 MB，一次一個檔案。
2. 擷取回傳廠商、發票編號、日期、幣別，以及項目明細
   （含數量、單價與總價）。
3. 每個項目明細帶有一個介於 0 到 1 之間的信心分數。
4. 比對以採購單號將擷取的發票與未結訂單對照。
5. 例外項目依最舊優先排入佇列，可指派給單一營運人員。
6. 每一次狀態變更都要寫入稽核紀錄，含操作者、時間戳、
   變更前的值。
7. 已核准發票以 CSV 批次匯出給財務系統。

## 8. 非功能需求
- 效能：發票清單 p95 在 400ms 以內。擷取在上傳後
  90 秒 p95 內完成。
- 安全性與租戶隔離：每個租戶在資料庫列層級強制隔離。
  客戶絕不能讀到其他客戶的發票。每次發布以自動化
  測試驗證。
- 資料落地與保留：文件儲存於歐盟境內。原始檔案保留 7
  年，擷取結果保留 90 天。
- 無障礙：佇列完全可鍵盤操作，符合 WCAG 2.2 AA 對比度。
- 可用性：每月 99.5%，於工作時段提供支援。

## 9. 相依性與整合
- 訂單記錄：唯讀的 Postgres 複本。存取權由客戶端 IT 負責，
  憑證需在 2026-08-15 前備妥。
- LLM 擷取供應商：合約與資料處理協議須在
  開發開始前簽署。
- 電子郵件通知：沿用現有交易型郵件供應商，寄件網域
  由客戶驗證。

## 10. 里程碑與階段規劃
| 階段 | 範圍 | 結案標準 | 目標日期 |
|---|---|---|---|
| P1 | 上傳、擷取、信心門檻分流 | 端到端跑完 50 張真實發票，佇列比例 25% 以內 | 2026-09-19 |
| P2 | 訂單比對與不符畫面 | 20 個測試案例正確標示不符 | 2026-10-10 |
| P3 | 稽核軌跡、CSV 匯出、報表 | 財務在入口網站完成一個月結 | 2026-11-01 |

## 11. 待解問題與風險
| 問題或風險 | 負責人 | 需要回覆的期限 | 若無解答的影響 |
|---|---|---|---|
| 一張發票出現兩個採購單號時，以哪一個為準？ | 客戶端營運總監 | 2026-08-08 | 比對邏輯卡住 |
| 12 個最大客戶寄來的是掃描檔還是原生 PDF？ | 交付負責人 | 2026-08-08 | 信心門檻可能設錯 |
| 7 年保留期限是否已與客戶法務確認？ | 客戶端財務經理 | 2026-08-22 | 儲存設計與成本會改變 |
| 每週 300 張發票的擷取成本 | 交付負責人 | 2026-09-05 | 單位經濟效益未知 |

## 12. 附錄與連結
匿名化樣本發票集（40 個檔案）、訂單資料表結構、
現行處理時間研究、上傳與佇列的 Figma 流程圖、已簽署的工作說明書。

裡面有四個決定值得特別點出來，因為偷懶的版本每一個都要花真金白銀。

第 3 節，基準值。「6 分鐘」不是裝飾。沒有基準值，你根本不知道這件事有沒有奏效，六個月後大家在會議上為此吵架卻沒有數據可以憑依。偷懶的版本「提升效率」，讓這個專案根本無法被證偽。

**第 4 節，非目標。**ERP 回寫在 2026-07-28 移入非目標，因為它在一次審查會議中被想當然地認定要做。把它寫成非目標只花了一行字，卻省下了一場範圍爭論。

**第 6.2 節，信心門檻。**這是我們自己第一版草稿最常漏掉的規則。少了它，系統會自動核准原本該由人審核的發票，正好把第 3 節承諾的時間節省全部抵銷。

**第 11 節，負責人。**每一個待解問題都有名字和日期。這一欄就是「一份文件」跟「一張沒人負責的待辦清單」之間的差別。

PRD 告訴你要做什麼，不會告訴你要花多久或多少錢，那是另一件事：參見界定專案範圍。而一個沒寫下來的非目標，就是有人遲早會做出來的功能。

要怎麼寫一份 AI 編碼代理真的能照著做的 PRD？

給 AI 編碼代理看的 PRD 要用明確換簡潔。代理沒有走廊上聽來的背景資訊，沒有共同的歷史，也沒有直覺去判斷你明明沒說但顯然不是那個意思。四條規則涵蓋了大部分的差異，這些是我們自己在協作開發中，觀察哪些規格成功、哪些失敗歸納出來的。

**1. 以肯定句寫非目標。**人類會從「沒寫」推論出範圍。代理不會。「這個階段不要加入身分驗證」必須明明白白寫成一句話，否則驗證功能就會被做出來、測試完，然後交還給你。

**2. 依階段切分工作量。**一份 40 頁的巨大文件，只會產出一個自信滿滿、鋪得很開、卻半對半錯的合併請求。把 PRD 切成代理能在一次有限的執行回合內完成的段落，每一段有自己的結案標準。

3. 讓驗收標準可被機器檢查。「快」不是一項需求，是一種心情。「發票清單端點的 p95 在 400ms 以內」是代理在寫功能之前就能先寫成測試的東西。

4. 把檔案路徑和技術棧限制寫進文件裡，而不是丟在聊天視窗。聊天的上下文會在工作階段之間蒸發，規格書不會。這也是為什麼 Claude Code 的計畫模式重要：它會讀取你的檔案並提出計畫，在你核准之前不會動手改任何東西，而當計畫是拿來對照一份寫下來的規格書、而不是你對自己要求的記憶時，那個核准步驟就有用得多。

以下是把發票入口網站切成一個代理能在一次執行中完成的階段。

# 開發任務：發票上傳與擷取（第 3 階段中的第 1 階段）

## 技術棧限制（不得替換）
Next.js 15 App Router、TypeScript、啟用列層級安全的 Supabase Postgres，
Vercel 部署。若需新增相依套件，須先詢問。

## 可以新增或編輯的檔案
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## 不得觸碰
- lib/auth/*（驗證功能在第 2 階段上線；現在不要加入登入流程）
- app/(marketing)/ 底下的任何東西
- 現有的 orders 資料表結構。只能讀取，絕不可遷移。

## 驗收標準（先把這些寫成測試）
1. POST /api/invoices 對非 PDF 回傳 415，對超過 20 MB 的檔案回傳 413。
2. 任一項目明細的信心度低於 0.85 時，將 invoice.status 設為 'review'，
   絕不設為 'approved'。
3. 每一次新增紀錄都要寫入含 actor_id、action、created_at 的稽核列。
4. GET /api/invoices?vendor=&from=&to=&status= 在 10,000 筆
   種子資料上於 400ms 內回傳。

## 這一階段不涵蓋的範圍
訂單比對、不符畫面、CSV 匯出、電子郵件通知。

跟人類版本相比，改變了三件事：出現了檔案路徑、出現了禁止觸碰清單，驗收標準從句子變成了斷言。交給哪一個代理，其實沒有大家想的那麼重要，不過在你決定之前，編碼代理比較值得一讀。把需求和專案規則放在不同的檔案裡：Cursor rules 和 CLAUDE.md 放慣例與工具設定，PRD 放要做什麼。如果你想在一開始就用 AI 協助產出範圍，而不是拿現成的範圍給它消化，那是另一套工作流程。至於擷取這一步本身,模型選擇與評測迴圈本身就是一項獨立的AI 整合工作。

PRD 交給外部團隊時會發生什麼變化

PRD 交給代理商或外包團隊時，它就不再只是一份對齊文件，而變成了合約語言。內部團隊靠兩分鐘的對話就能解決的模糊之處,在這裡會變成一張有價格的變更請求。PMI 的 Pulse of the Profession 發現47% 失敗的專案，原因出在不準確的需求管理。這正是這份文件存在的全部理由。

在這種情境下，有三個章節的份量特別重。驗收標準會變成簽核關卡，因此必須能被非工程背景的人觀察與確認。待解問題需要客戶端有名有姓的負責人，因為供應商無法替客戶回答，只會繞過這個缺口去做。而變更歷史不再只是官僚紀錄：它是「什麼時候誰同意了什麼」的紀錄，也是發生爭議時大家第一個會去翻的東西。

我們看過不只一次出錯的那句話,大概是某個版本的「使用者可以匯出他們的資料」。沒有人寫清楚是什麼格式。對我們來說最貴的一次，就是最後匯出成 CSV，但客戶原本想要的是印有他們品牌的格式化 PDF 發票包，重做一次燒掉了大約一週沒人估過的工程時間。老實說，問題出在文件本身，不是交付過程。一條驗收標準原本五分鐘就能抓出來：假設有一個匯出請求，當檔案產生時，則它是符合指定版面的 PDF。一條非目標寫下來也能從另一個方向抓出這個問題。所以現在這是我們探索階段的一條規則：任何掛在「匯出」「報表」或「通知」這類名詞上的需求，在工作說明書簽署之前，都要附上格式、觸發條件與一個實作範例。

這也是我們執行網頁應用程式開發的大部分工作內容：在任何人動手寫程式之前,把客戶規格裡模糊的那一半變成可測試的條文。

r/ProductManagement 對 PRD 範本到底怎麼說

搜尋 product requirements document template reddit，你會在 r/ProductManagement 上一再看到同樣的抱怨：範本膨脹。沒人讀的 PRD。因為範本有那個標題所以填了內容，而不是因為真的有人需要那些內容。開案第二天就過時、被 Slack 討論串默默取代的文件。這是對大多數範本的公允批評，包括這個搜尋詞排名前十結果中好幾個。

我們的做法：與其填一堆沒內容的章節，不如直接刪掉。角色描述如果使用者很明顯，放最前面。附錄放第二順位。里程碑可以留在追蹤工具裡就好。唯一我們從不刪的是非目標，因為它是唯一一個你做的工作越多、內容反而越短的章節，也是唯一一個能穩定防止你在第六週吵起來的章節。

關於作者

Mert Batur Gurbuz，Techsy.io 共同創辦人。學經歷：Techsy.io 共同創辦人、伯明罕大學。LinkedIn

Mert Batur Gurbuz 是 Techsy.io 的共同創辦人，團隊為 B2B 客戶打造 AI 代理、自動化系統與語音／SDR 管線。他就讀於伯明罕大學，撰寫關於 Techsy 團隊在正式生產環境中實際使用的 LLM 工具鏈的文章。

常見問題

什麼是產品需求文件？

產品需求文件（PRD）陳述一個團隊要做什麼、為什麼做：問題、目標與其指標、非目標、對象是誰，以及定義「完成」的需求。它刻意排除實作細節，那屬於工程之後才寫的技術設計文件。

怎麼寫產品需求文件？

從問題陳述開始，並且拒絕在裡面使用解法用語。加上可量測的目標，附基準值與目標日期，再寫非目標。填入使用者角色、附 Given/When/Then 驗收標準的使用者故事、功能與非功能需求、相依性、里程碑，以及附負責人的待解問題。

PRD 應該包含什麼？

十二個章節：含變更歷史的標頭、問題陳述、目標與成效指標、非目標、使用者與角色、附驗收標準的使用者故事、功能需求、非功能需求、相依性與整合、里程碑與階段規劃、待解問題與風險，以及附錄。不屬於這些的內容，大概就不算需求。

PRD 應該多長？

單一功能一到兩頁，產品階段三到五頁，交給外部團隊、驗收標準要當簽核關卡時則五到八頁。長度取決於要記錄多少決策，而不是產品的規模。空白的章節該刪掉，而不是硬填。

PRD 跟 BRD 一樣嗎？

不一樣。商業需求文件（BRD）陳述組織想要的商業成果與其周邊限制，通常在選定解法之前寫。PRD 描述的是實現這個成果的產品：使用者、行為、驗收標準、非目標。在較小的公司裡，BRD 常常就只是問題陳述那一段。

敏捷團隊還會寫 PRD 嗎？

會，通常以單頁版形式。待辦清單保留工作內容，但工單很不擅長保留「為什麼」、非目標與成效指標。完全略過 PRD 的團隊，往往會在專案進行到第三個衝刺左右，重新發明出一個叫做「context」的 Confluence 頁面。

可以用 markdown 寫 PRD 嗎？

Markdown 是最適合的格式。它能乾淨貼進 Notion、Confluence、Google Docs 和 Linear，能以 PRD.md 跟程式碼一起在 Git 中版控，能在合併請求裡正確顯示差異，也是唯一一種 AI 編碼代理讀取時不會丟失結構的格式。上面那份範本正是基於這些理由才用 markdown 寫成。

怎麼為 AI 編碼代理寫 PRD？

在你平常會簡短帶過的地方，寫得明確。以肯定句陳述非目標，因為代理無法從「沒寫」推論出範圍。把文件切成能在一次執行中完成的階段。把驗收標準寫成附數字的斷言。指名代理可以編輯的檔案，以及不能碰的檔案。

PRD 和技術設計文件有什麼差別？

PRD 回答「什麼」和「為什麼」：問題、使用者、行為、驗收標準、非目標。技術設計文件回答「怎麼做」：架構、資料模型、API 合約、考慮過的取捨。通常產品擁有前者，工程擁有後者，設計文件應該讀起來像是對 PRD 的回應。

PRD 該由誰負責，產品、工程，還是客戶？

產品負責這份文件與其中的決策。工程負責可行性回饋與非功能需求。在代理商專案裡，客戶負責問題陳述、目標，以及所有關於他們自身業務的待解問題。整份文件由大家共同負責，通常意味著最後沒有人真正維護它。

總結

三件事值得帶走。範本只有填好之後才有用，所以複製實作範例的形狀，而不是空白版的形狀。非目標是這份文件裡每個字性價比最高的章節,也是大家最先跳過的一個。而寫成可測試斷言的驗收標準，能同時服務兩種讀者：簽核交付的工程師，以及寫測試的代理。

如果你正在寫一份要交給外部團隊的 PRD，想在它變成合約之前找人幫忙看看、標出模糊的地方，我們很樂意幫你讀一遍。那正是我們在自家網頁應用程式開發上跑的同一套流程。