類別 4：商業與生產力 5 / 6
初階 Guide 23 Business Product Requirements

產品需求文件

用 Claude 建立結構化的 PRD — 用戶故事、驗收標準、技術需求和成功指標。

2026年3月25日 10 min read

你將學到什麼

  • 如何使用 Claude 從粗略的功能想法快速起草完整、結構化的 PRD
  • 如何撰寫帶有適當驗收標準的用戶故事，讓工程師可以據此開發
  • 如何定義成功指標和邊界情況，防止範圍蔓延和模糊性

使用情境

產品需求文件（PRD）是產品經理和工程團隊之間的合約。當它含糊或不完整時，工程師構建了錯誤的東西，QA 錯過了關鍵案例，發布因為需要澄清而延遲。當它徹底且精確時，團隊可以有信心地快速移動。

挑戰在於撰寫一個好的 PRD 需要大量時間——研究問題空間、訪談利害關係人、思考邊界情況，並將產品思考翻譯成工程就緒的規格。大多數 PM 在同時管理路線圖、利害關係人會議和 sprint 典禮時做這件事。

Claude 大幅加速了這個過程。你帶來產品思考——用戶洞見、業務理由、優先順序。Claude 帶來結構性嚴謹——完整的用戶故事格式、驗收標準清單、你需要回答的技術問題，以及成功指標框架。結果是一份初稿，資深 PM 需要 4-6 小時才能完成，現在大約 30 分鐘可以完成。

這適用於新功能 PRD、改版規格、外部開發者的 API 文件，以及內部工具需求。

逐步指南

第一步：從問題開始，而不是解決方案

最常見的 PRD 錯誤是在清晰地表達問題之前就從解決方案開始（「我們想要構建 X」）。請 Claude 幫助你先撰寫問題陳述，這為整個文件提供錨點。

提示：

「我想為一個新功能撰寫 PRD。我們正在解決的問題是：[用 2-3 句話描述用戶問題]。受影響的用戶是 [描述人物角色——職稱、他們試圖完成什麼、目前的解決方案]。幫我撰寫一個在 1-2 段中捕捉『誰、什麼、為什麼』的簡潔問題陳述。」

這也作為一個有價值的對齊工具——如果問題陳述與你的工程主管或設計夥伴不共鳴，你應該在撰寫任何需求之前解決那個分歧。

第二步：生成帶有驗收標準的用戶故事

問題清晰後，Claude 可以幫助你將其翻譯成正確結構化的用戶故事。標準格式是：「作為 [人物角色]，我想 [行動]，以便 [好處]。」但真正的價值在於驗收標準——必須為真的具體條件，才算故事完成。

提示：

「根據這個問題陳述，為這個功能撰寫 5-7 個用戶故事。對於每個故事：

  • 使用『作為 / 我想 / 以便』格式
  • 使用 Gherkin 格式（給定 / 當 / 然後）撰寫 3-5 個驗收標準
  • 將每個故事標記為必須有、應該有或最好有（MoSCoW 優先排序）
  • 標記任何太大的故事，應該拆分成子故事」

Claude 將以正確的粒度返回故事，並標記需要拆解的史詩——這是初級 PM 需要多年才能直觀掌握的技能。

第三步：定義功能和非功能需求

除了用戶故事之外，完整的 PRD 還捕捉功能需求（系統必須做什麼）和非功能需求（必須做得多好——效能、安全性、可訪問性、可擴展性）。

提示：

「根據這些用戶故事，生成：

  1. 功能需求的編號清單（必須存在的系統行為）
  2. 非功能需求清單——包括效能基準（例如，頁面載入在 X 秒以內）、可訪問性標準（WCAG 2.1 AA）、安全需求（身份驗證、數據處理）和可擴展性預期
  3. 如果這個功能觸及外部系統，任何 API 或整合需求
  4. 數據需求——需要存儲什麼數據、存儲多長時間，以及帶有什麼訪問控制」

這個部分通常是最被忽視的，也是最可能在實作中造成問題的。Claude 將浮現你沒有想到要指定的需求。

第四步：定義成功指標和測量計劃

沒有成功指標的需求是希望，而不是目標。對於你構建的每個功能，你應該知道如何衡量它是否解決了問題。

提示：

「幫我為這個功能定義成功指標。業務目標是 [提高留存 / 減少流失 / 提高參與度 / 減少支援量等]。我應該追蹤哪些主要、次要和護欄指標？我如何衡量採用率？成功在發布後 30 天、90 天和 6 個月是什麼樣的？格式化為測量框架表格。」

Claude 將建議分層指標結構——主要指標（這是否改變了業務目標的指針）、次要指標（成功的領先指標），以及護欄指標（發布這個後不應該變得更差的事情）。

第五步：浮現邊界情況和未解問題

Claude 在 PRD 撰寫中最有價值的用途之一是系統性地浮現在工程開始之前需要解決的邊界情況和未解問題。

提示：

「審閱這份 PRD 草稿並識別：

  1. 驗收標準未涵蓋的邊界情況和錯誤狀態
  2. 開發開始前需要利害關係人輸入的未解問題
  3. 對其他團隊或系統的依賴（數據、平台、設計、法律、安全）
  4. 我做出的可能是錯的並且會改變需求的假設 按如果不解決最可能造成問題的順序列出。」

這相當於資深工程師的「你有沒有想過當……」對話——但它在 sprint 開始之前發生，而不是在中途。

提示範本

我需要為以下功能/產品撰寫一份 PRD：

功能名稱：[名稱]
問題陳述：[這解決什麼用戶問題？誰會遇到它？他們目前的解決方案是什麼？]
業務目標：[這驅動什麼結果？留存、收入、效率等？]
目標用戶：[描述主要人物角色]
範圍：[什麼明確在範圍內？什麼明確在範圍外？]
已知限制：[技術限制、時程、預算、平台、合規需求]
依賴關係：[其他團隊、系統或外部因素]

請創建一份完整的 PRD，包括：
1. 問題陳述（2 段）
2. 目標和非目標
3. 5-8 個作為 / 我想 / 以便格式的用戶故事，每個帶有：
   - 給定 / 當 / 然後格式的 3-5 個驗收標準
   - MoSCoW 優先排序標籤
4. 功能需求（編號清單）
5. 非功能需求（效能、可訪問性、安全性、可擴展性）
6. 帶有測量時程的成功指標表格（主要、次要、護欄）
7. 未解問題和依賴關係
8. 開發開始前需要定義的邊界情況

格式化為結構化的 Markdown 文件，可以粘貼到 Notion 或 Confluence。

技巧與最佳實踐

  1. 使用 Claude 為你拒絕的功能撰寫 PRD — 當你拒絕功能請求時，與 Claude 一起撰寫一頁的「反 PRD」解釋原因——它解決的問題、為什麼現在不是正確的時機，以及什麼證據會改變決定。這讓你免於 6 個月後進行同樣的對話。

  2. 請 Claude 為每個故事撰寫「完成定義」 — 除了驗收標準之外，請 Claude 起草在故事關閉之前必須驗證的條件清單：撰寫了單元測試、更新了文件、工具化了分析事件、完成了設計 QA。這成為你的 sprint 品質門。

  3. 從驗收標準生成測試案例 — 撰寫驗收標準後，與 Claude 分享並問：「將這些驗收標準轉換成 QA 測試案例，包括正常路徑、負面測試和邊界情況測試。」你的 QA 團隊會感謝你的。

  4. 使用 Claude 即時捕捉範圍蔓延 — 當有人在 sprint 中途提議添加到功能時，將 PRD 和新請求貼入 Claude，問：「這個新請求是否在當前範圍內？如果是，它落在哪個驗收標準下？如果不是，起草一段我可以用來將其推遲到待辦事項中的話。」

  5. 進行「會出什麼問題」工作階段 — PRD 完成後，問 Claude：「如果這個功能發布並未能解決問題，最可能的 3 個原因是什麼？我們現在可以在 PRD 中添加什麼來降低這些風險？」這個對抗性審查在問題成為事後檢討之前捕捉它們。

動手試試

拿一個你目前正在進行或規劃的功能——可以是小的，比如改進一個表單或添加一個篩選器。撰寫一段描述它解決的用戶問題的話。然後使用上面的提示範本將其給 Claude 並請求完整的 PRD。獲得草稿後，具體查看「未解問題」部分。你已經解決了其中多少問題？有多少代表可能在開發中造成問題的真實模糊性？這個比率將告訴你實際上你有多準備好開始構建。