如何用 AI 撰寫產品需求文件（附免費範本）

產品需求文件（PRD）是一份簡明、以平實語言寫成的說明，講述你正在建造什麼、服務對象是誰、它必須做什麼，以及你如何判斷它是否運作正常。AI 令撰寫 PRD 快得多：你提供粗略的筆記，它便會整理成結構化的章節、用戶故事和邊緣情況。你的工作是提供 AI 無法自行決定的部分，即目標、範圍，以及哪些內容要剔除，並核對它加入的內容。

本指南涵蓋 PRD 應包含的內容、用任何 AI 助手逐步起草的方法、每個章節的提示，以及一份可以直接複製的填寫式範本。

PRD 的用途（及非其用途）

PRD 要回答四個問題：

1. 為何要建造這個？要解決什麼問題，為了誰？
2. 第一版必須做到什麼？
3. 暫時不會做什麼？
4. 我們如何知道它成功了？

PRD 不是技術設計，不會說明應該用哪個資料庫或框架，那些屬於另一份技術規格（如你需要的話）。它也不是營銷簡報或商業計劃書。PRD 只專注於產品的行為，這正是它對各方都有用的原因：設計師、開發人員、負責簽批的持份者，或把它轉化為程式碼的 AI 應用程式生成器，都能從中受惠。

誰需要 PRD

• 獨立創辦人，希望在範圍失控之前就先把它控制住。
• 小型團隊，需要一個地方記錄「我們已達成的共識」。
• 聘請自由工作者或代理機構的人，因為清晰的 PRD 能令報價更準確。參閱 聘請開發人員或用 AI 建造。
• 用 AI 開發的人，因為 PRD 的用戶故事和數據清單，比沒有結構的願望清單更適合作為提示。

AI 擅長什麼，又不擅長什麼

最常見的失誤，正是上表倒數第二行的反面情況：AI 會自信地用看似合理的猜測填補空白，去描述你的用戶。凡是 AI 寫出關於用戶、市場規模或使用行為的內容，都應視為有待核實的問題，而不是既定事實。

第一步：把你知道的全部寫下來

在輸入任何提示之前，先寫下粗略的筆記，用條列式即可。內容應涵蓋：

• 問題是什麼，用一至兩句話，從用戶的角度描述。
• 誰有這個問題。要具體：「擁有 10 至 40 位客戶的自由工作記帳員」，而不是「小型企業」。
• 他們現在用什麼方法處理（試算表、電郵，或一個他們不喜歡的工具）。
• 能讓第一版算是成功的一個結果。
• 你已經知道自己不會做的事。
• 硬性限制：期限、預算、必須能在手機上使用、必須與你現有的某個工具整合。

如果你還未與有此問題的人交談，請先做這一步。如何驗證應用程式構思 提供了一個實用的做法。以猜測為基礎的 PRD，只是一份格式精美的猜測。

第二步：請 AI 提供初稿

把你的筆記貼上，並要求它按固定結構撰寫草稿。以下是一個行之有效的提示：

以下是我對某產品的筆記。請把它們整理成產品需求文件，並且嚴格使用這些章節：摘要、問題、用戶、目標與成功指標、範圍（納入／剔除）、附驗收準則的用戶故事、數據、權限、邊緣情況、待解決問題。文件長度請控制在兩頁以內。請勿虛構有關用戶或市場的事實，若我的筆記未有說明，請把相關問題寫在「待解決問題」之下。

最後一項指示十分重要。要求 AI 把未知的事項列入「待解決問題」，而不是自行填補，能產生誠實得多的草稿。

第三步：逐節收緊內容

逐節審閱草稿。以下的跟進提示會有幫助：

問題與用戶

請用一至兩句話，從用戶的角度重寫問題陳述。不要包含解決方案的字眼。

如果問題陳述提到了你的產品，那它描述的其實是解決方案，而不是問題。

目標與成功指標

請為第一版建議三個成功指標，能讓我在首月以少量用戶衡量。每個指標都請說明我會如何衡量。

挑選一至兩個。「二十位記帳員在一個月內每週使用」是可以衡量的；「提升生產力」則不能。

範圍

請列出本 PRD 中所有可以延後到之後版本、而不會破壞核心流程的內容。

AI 工具往往會加入功能。這個提示正好令它反過來做。要狠下心：大部分第一版 PRD 都太大了。什麼是 MVP 解釋了為何較小的第一版更能讓你學到東西。

用戶故事與驗收準則

請把每項需求寫成用戶故事（「作為[用戶]，我想[行動]，以便[結果]」），並附上兩至四條以「假如／當／則」（Given / When / Then）形式寫成的驗收準則。

驗收準則就是日後你用來測試的核對清單。「假如某時段已被預約，當另一位客戶查看日曆，則該時段不會顯示」是可以測試的；「預約功能運作良好」則不能。

邊緣情況與權限

針對每個用戶故事，列出在以下情況會發生什麼：數據為空、輸入無效、網絡緩慢或請求失敗，以及用戶不應有權限卻嘗試存取的情況。

這正是 AI 發揮所長之處。它能迅速找出人們容易忽略的空白狀態和權限漏洞。

第四步：以懷疑的態度審閱

再把整份文件通讀一次，並檢查：

• 每項關於用戶的陳述，都來自你或研究，而非 AI。
• 範圍中的剔除部分，至少與納入部分一樣長。
• 每個用戶故事都有別人無須問你也能測試的驗收準則。
• 數據一節列出了應用程式保存的每一類記錄，以及誰可以看見。
• 待解決問題都有負責人和日期。
• 沒有混入技術內容，除非那是真正的限制（「必須能離線使用」是需求；「使用 Redis」則不是）。

然後把文件交給一位會使用或開發這個產品的人，請他指出不清楚的地方。他提出的問題，就是你的漏洞所在。

填寫式 PRD 範本

把以下內容複製到文件中，並替換方括號內的文字。如果某個章節確實不適用，請刪除。

產品名稱：[名稱] 負責人：[負責決策的人] 狀態：[草稿／審閱中／已達成共識] — 最後更新：[日期]

1. 摘要

[兩至三句：這是什麼、為誰而設，以及主要成果。]

2. 問題

[從用戶角度描述的問題。他們現在如何處理，以及為何這樣令他們困擾。]

3. 用戶

4. 目標與成功指標

• 目標：[第一版必須達成的成果]
• 指標：[如何衡量，以及目標數值]
• 非目標：[人們可能以為這個版本會做、但其實不會做的事]

5. 範圍

第一版包含：

• [功能]
• [功能]

第一版不包含：

• [功能，以及為何可以延後]
• [功能，以及為何可以延後]

6. 用戶故事

**故事 1：**作為[用戶]，我想要[行動]，以便[結果]。

• 假如[情境]，當[行動]，則[結果]。
• 假如[情境]，當[行動]，則[結果]。

**故事 2：**作為[用戶]，我想要[行動]，以便[結果]。

• 假如[情境]，當[行動]，則[結果]。

7. 數據

8. 權限

[誰可以登入、有哪些角色，以及每個角色可以查看和更改什麼。]

9. 邊緣情況

• [空白狀態：尚未有數據時顯示什麼]
• [無效輸入：電郵錯誤或欄位缺漏時會怎樣]
• [存取：有人打開不應有權限的頁面時會怎樣]

10. 整合與限制

[付款、電郵、現有工具、期限、預算，以及必須支援的裝置。]

11. 待解決問題

從 PRD 到提示

一份好的 PRD 幾乎可以直接轉化為 AI 應用程式生成器的提示：

• 摘要、用戶與數據表，成為你的第一個提示。
• 每個用戶故事，成為一個跟進提示。
• 每條驗收準則，成為你在預覽中測試的項目。
• 「第一版不包含」清單，就是你暫時不去要求的功能。

逐個故事建造，並在進入下一個之前檢查其驗收準則，會比把整份 PRD 貼上、要求一次過完成所有功能可靠得多。如何為 AI 應用程式生成器撰寫提示 更詳細地介紹了提示的寫法。

常見錯誤

• 把解決方案寫成問題。「用戶需要儀表板」是解決方案；「擁有人在不逐一打開的情況下，無法得知哪些發票已逾期」才是問題。
• **沒有「範圍以外」一節。**沒有它，每次討論都會重新打開範圍。
• **讓 AI 虛構用戶。**AI 編造的人物角色看起來很真實，但其實並不存在。
• **無法衡量的指標。**如果你無從計算，它就不是指標。
• **從不更新。**一份與你正在建造的內容不再相符的 PRD，比沒有還糟。請保留「最後更新」日期，並在決定有變時修改。

在 Mythex 中使用 PRD

如果你在 Mythex 中開發，可以把 PRD 直接貼到對話中。PRD 很適合在計劃模式下使用：代理會閱讀它，提出一個方案和步驟清單，你可以在計劃分頁中審閱；只有當你按下建造，它才會開始修改檔案。你也可以把應該一直適用的部分（對象、品牌、規則）儲存為專案知識，這樣就無須在每次對話中重複輸入。聊天文件 說明了建造、計劃和詢問模式；而 範本 則是快速看到第一版可能模樣的方法，然後再撰寫完整文件。

常見問題