用 Claude 寫 PRD 和技術方案：先讓它採訪你，再分章節成稿，用標籤喂材料並核對驗收標準

本文根據 Claude 官方提示詞指南、Claude Code 官方文檔《Best practices》和幫助中心《How can I create and manage projects?》《Create and edit files with Claude》整理，資料核對於 2026-11-05。配圖為本站整理的示意圖，不是介面截圖。本站（bigolab.com）不是 Anthropic 官方網站。

適用於誰

• 需要寫 PRD、需求說明、技術方案的產品經理、開發者和創業者；
• 腦子裏只有想法，不知道文檔該怎麼搭的人；
• 想把 PRD 交給開發或交給 AI 編程工具去實現的人。

結論先說

1. 想法不清楚時，先讓 Claude 採訪你。官方在 Claude Code 最佳實踐裏給了這個做法：描述你想做的事，讓它不停提問，直到能寫出規格為止，再把規格寫進文件。這個思路放到聊天裏同樣好用。
2. 按章節寫，不要一次要全文：每章確認後再往下，前面的結論成為後面的輸入。
3. 材料用標籤分開：官方說 XML 標籤可以讓 Claude 清楚區分指令、背景、範例和輸入，減少誤解。
4. 驗收標準必須能被檢驗：官方在 Claude Code 裏反覆強調給 Claude「能判斷對錯的檢查」，PRD 裏對應的是可驗證的驗收標準。
5. 數字、競品資訊、政策依據由你核對，讓 Claude 缺資訊時留空並標註。

圖：本站根據 Claude 官方提示詞指南 整理的示意圖

一、先採訪，再成文

官方的原話思路是：你還沒想清楚時，不要硬着頭皮先寫，讓 Claude 提問，它會用選擇題問你沒有定下來的部分，直到答案足以寫出一份規格。

提示詞 1：需求採訪

text
我想做一個【產品 / 功能的一句話描述】，但還沒有想清楚。
請採訪我，直到你能寫出一份可以交給開發的 PRD。
規則：每次最多問 3 個問題，盡量用選擇題；優先問最影響方案的事：目標用戶是誰、要解決什麼問題、怎樣算成功（指標）、有哪些限制（時間、預算、技術、合規）、明確不做什麼。
當你認為資訊足夠時，告訴我，並列出你做出的假設讓我確認。

二、按章節寫 PRD

一份常見的 PRD 包含：背景與目標、用戶與場景、需求清單、功能細節、驗收標準、非功能要求、範圍之外、風險與待定事項。你的團隊有固定模板就用團隊的。

提示詞 2：把採訪結果整理成 PRD 提綱

text
基於我們剛才的對話，整理 PRD 提綱，每章寫出一句話的內容說明和你準備寫的要點。暫時不要寫正文。
章節：背景與目標、用戶與場景、需求清單（按優先級 P0/P1/P2）、功能細節、驗收標準、非功能要求、範圍之外、風險與待定事項。
對於對話裏沒有明確說明、你是自己假設的內容，標上【假設】。

提綱確認後逐章展開：

提示詞 3：展開某一章，寫可驗收的需求

text
請展開 PRD 的「需求清單」和「驗收標準」兩章。
<context>
【粘貼已確認的提綱、關鍵背景和約束】
</context>
要求：1）每條需求寫成「作為【用戶】，我希望【做什麼】，以便【得到什麼好處】」；2）每條需求至少配 2 條驗收標準，寫成「給定……當……則……」的形式，必須是別人看了能判斷通過與否的；3）凡是需要數字（時長、數量、比例）的地方，如果我沒提供就寫【待補：xxx】，不要自己定。

三、寫技術方案

技術方案的關鍵是「有選擇、有取捨」，而不是隻寫你一開始想到的方案。

提示詞 4：方案對比與評審

text
下面是需求和技術約束：
<requirements>
【粘貼 PRD 的核心需求】
</requirements>
<constraints>
【團隊技術棧、人力、時間、已有系統】
</constraints>
請給出 2 到 3 個可行的技術方案，用表格對比：實現思路、優點、缺點與風險、開發工作量（相對大小即可）、對現有系統的影響。
然後推薦一個，說明理由和適用前提；再列出 5 個需要在評審會上和團隊確認的問題。
不要編造我沒有提到的技術細節，不確定就寫出來問我。

採訪、對比這類需要多步推理的任務，可以考慮選擇能力更強的模型或開啟思考功能，模型的區別見 /guides/claude-models-compare。

四、讓 Claude 當挑剔的評審者

寫完以後，讓它從另一個角度檢查。注意官方的提醒：被要求挑毛病的審查者總會找到點什麼，所以要限定範圍，說明只報告影響正確性或交付的問題。

提示詞 5：評審 PRD

text
請以開發負責人的身份評審下面的 PRD：
<prd>
【粘貼 PRD】
</prd>
只報告以下幾類問題：1）需求之間互相矛盾；2）驗收標準無法判斷通過與否；3）開發時一定會問、但文檔裏沒有回答的問題；4）明顯遺漏的異常情況。
每個問題註明所在章節，沒有問題的類別寫「未發現」。不要提文風和排版方面的意見。

五、用項目管理長期文檔

PRD 往往要多次迭代。官方說明項目（Projects）有知識庫，你可以上載文檔、文本文件，項目內所有對話都能使用；還有項目指令，對項目裏每個對話生效；每個文件最大 30MB。把產品背景、術語表、已定稿的 PRD 放進知識庫，新的功能需求就可以在同一個項目裏討論，不必每次重新交代。注意官方說項目裏不同對話之間的上下文不共享，新結論要自己補進知識庫。項目用法見 /guides/claude-projects-guide。

要得到 Word 文件，需要開啟 Settings > Capabilities 裏的 Code execution and file creation（新版介面叫 Create and edit files），然後讓 Claude「把這份 PRD 生成 Word 文件」。官方說明它能創建 Word、Excel、PowerPoint 和 PDF，每個文件最大 30MB，你需要檢查並調整輸出。

如果這份 PRD 是要交給 AI 編程工具去實現的，可以把驗收標準整理成清單，放進項目的 CLAUDE.md 或規格文件，思路見 /guides/claude-code-best-practices。

圖：本站根據官方提示詞指南整理的示意圖

寫 PRD 的幾個容易忽略的地方

• 先寫「不做什麼」：範圍之外一章經常被省略，卻能擋掉後期大部分扯皮。讓 Claude 幫你列出「看起來相關、但這一期不做」的功能，再由你刪減。
• 把成功指標寫成數字：比如「註冊轉化率提升多少」，這類數字只有你的業務知道，Claude 不應該替你編。在提示詞裏寫明「沒有數據就留空」。
• 異常和邊界：網絡斷開、權限不足、數據為空、重複提交，這些情況往往是開發返工的來源，可以單獨讓 Claude 按功能逐個檢查一遍。
• 術語統一：同一個概念全文只用一個名字。把術語表放進項目知識庫，讓它寫作時遵守。

常見問題

Q：Claude 寫出來的需求很空泛怎麼辦？

通常是因為輸入太少。回到採訪環節，補充用戶場景、現有流程和具體數字，再讓它改寫。

Q：能直接寫出可以開發的詳細方案嗎？

可以得到底稿。涉及你們系統的真實情況，例如數據庫結構、接口約定，要把相關材料給它，否則它只能給出通用方案。

Q：額度消耗大嗎？

長文檔加多輪修改消耗較快，規則見 /guides/claude-usage-limits。經常寫文檔可以了解 /chongzhi/claude-pro，價格和額度以官方頁面當前顯示為準。

相關教學

• /guides/claude-projects-guide：項目怎麼用
• /guides/claude-write-official-document-report-summary：寫公文和報告
• /guides/claude-code-best-practices：Claude Code 官方最佳實踐

參考資料

• Claude 開發者文檔：Prompting best practices — https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• Claude Code 文檔：Best practices for Claude Code — https://code.claude.com/docs/en/best-practices
• Claude 幫助中心：How can I create and manage projects? — https://support.claude.com/en/articles/9519177-how-can-i-create-and-manage-projects
• Claude 幫助中心：Create and edit files with Claude — https://support.claude.com/en/articles/12111783-create-and-edit-files-with-claude