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

產品需求文件（PRD）是一份簡短、以白話文撰寫的說明，描述你正在打造什麼、服務對象是誰、必須做到什麼，以及你要如何確認它運作正常。AI 能大幅加快撰寫速度：你給它粗略的筆記，它就能整理成結構化的章節、使用者故事與邊緣情況。你的工作是提供 AI 無法自行決定的事項，也就是目標、範圍與要排除的內容，並檢查 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 貼到對話中。使用 Plan 模式很適合 PRD：代理會閱讀它，提出一個方法與步驟清單，你可以在計畫頁籤中審閱；直到你按下 Build，它才會開始修改檔案。你也可以把應該一直適用的部分，例如受眾、品牌與規則，儲存為專案知識，這樣就不必在每次對話中重複說明。聊天文件說明了 Build、Plan 與 Ask 模式，而範本則能讓你在撰寫完整文件之前，先快速看到第一版可能的樣子。

常見問題