iT邦幫忙

2026 iThome 鐵人賽

DAY 11
1
Claude AI

今晚來點 Claude Skills:產品開發者的 AI 工作流系列 第 11 篇

Day 11 - 用 Claude Code 從需求卡生成 PRD 初稿, 一句話變成 PRD

  • 分享至 

  • xImage
  •  

一句話變成 PRD

Day 11 - 用 Claude Code 從需求卡生成 PRD 初稿,一句話變成 PRD

如何將一張精準的需求卡片,快速展開為跨職能團隊皆能順暢對齊的產品需求文件(PRD)初稿?

方向明確的需求卡片需要進一步具體化,才能讓工程與設計團隊步調一致。
這就像建築師繪製房屋施工藍圖,將屋主對「明亮通風客廳」的期待,精確標示出樑柱尺寸、採光窗位置、電路管線與驗收標準。

產品需求文件(PRD, Product Requirements Document)是詳述產品功能目標、使用者流程、邊界條件與成功指標的基準規範文件。

核心概念拆解

從輸入到 PRD 初稿再到人工決策
一份兼具嚴謹度與協作彈性的 PRD,仰賴三大支柱的精確落實:

  • 問題與證據基礎:像建築的地基,問題與證據基礎是確保所有開發行為皆源自真實使用者阻礙的事實依據。
  • 主流程與功能代碼:像房間的走道動線與結構編號,主流程與功能代碼(如 FR-01)是使用者完成操作的連續步驟與功能規格標記。
  • 驗收指標與界外範疇:像工程驗收尺規與安全圍籬,驗收指標與界外範疇是確認產品如期達成目標並精確框定交付範圍的判定準則。

在撰寫 PRD 初稿時,團隊可以在以下兩種方案間靈活選擇:

  • 方案 A(簡單有效):單頁極簡規格書(One-pager PRD)。原因在於結構輕巧且閱讀成本極低,適合快速推進的小型功能迭代。
  • 方案 B(高效有用):結構化完整 PRD 框架。原因在於完整串聯需求代碼、假設驗證與邊界條件,適合需要跨團隊精準交付的關鍵核心模組。

執行規則

請依循以下四個動作動詞步驟產出 PRD 初稿:

① 載入已確認的需求卡資料:匯入目標使用者、情境、問題與待驗證項目。
② 展開核心流程與功能清單:依序賦予功能專屬編號(如 FR-01 起算),標明對應理由。
③ 明確標註假設與待確認缺口:將所有推測性判斷清楚標示為【假設】或【待確認】。
④ 定義成功衡量指標與界外範疇:確立指標的計算方式與分子分母,列出本期保留項目。

結構化示範:功能需求卡片

FlowBoard 團隊依據 RC-01 需求卡,將功能清單結構化為三張功能需求卡片:

① 功能規格卡:FR-01 新成員首登起始引導

  • 需求內容:新成員首次進入工作區首頁時,介面顯著呈現起始引導區塊。
  • 支撐理由:確保成員進入後能立即看見具體的下一步操作動向。
  • 當前狀態:草案規格

② 功能規格卡:FR-02 任務導航主要行動

  • 需求內容:當成員具備已被指派的任務時,提供前往該任務的核心操作按鈕。
  • 支撐理由:引導成員迅速連結真實工作,展開首次有價值的操作。
  • 當前狀態:草案規格

③ 功能規格卡:FR-03 替代指引內容呈現

  • 需求內容:當成員指派任務數量為零時,呈現聯繫管理者獲取指派的引導說明。
  • 支撐理由:引導成員建立聯繫,保持流程的順暢銜接。
  • 當前狀態:待決決策(待團隊確認具體文案流程)

提示詞設計(Prompt)

角色:
你是協助整理產品規格的編輯助手。請只依據輸入資料產出 PRD 初稿。

輸入:
【產品情境卡】
【RC-01 需求卡】
【資源限制與兩週 MVP 範疇】

任務:
① 結構化梳理核心問題、目標、界外範疇與使用者操作情境。
② 將需求展開為主要流程、功能需求清單與待確認決策。
③ 建立專屬需求代碼(FR-01 起算),以利後續工程追溯。
④ 訂定可觀測的成效指標定義草案。

規則:
① 保持輸入資料的事實邊界,推測事項標記為【假設】。
② 資料缺口一律標記為【待確認】。
③ 明確區分 MVP 核心範疇與界外範疇。
④ 條列需要人工團隊裁決的關鍵事項。

輸出:
包含摘要、問題與證據、目標與界外範疇、使用者情境、主要流程、
功能需求卡片清單、成功指標草案、系統限制、待決問題與人工決策建議。

範例輸出與核心價值

### 摘要與核心目標
為首次進入工作區的新成員提供起始引導,協助迅速定位並完成第一件工作任務。

### 主要流程
接受團隊邀請 → 首次載入工作區首頁 → 瀏覽起始引導提示 → 開啟指派任務 → 完成操作。

### 成功指標草案
7 日任務啟用率 = 加入工作區後 7 日內至少完成一項任務的新成員數 ÷ 同期符合納入條件的新成員總數。

這份初稿的核心價值在於:如實暴露尚未決定的問題,讓團隊在動土前看清真實規格缺口,保持敏捷對齊。

人類需要檢查什麼

請團隊在會議中逐一核對以下四個驗證問題:

① 輸入的事實證據是否足夠支撐此 PRD 的功能規模?
② 規格草案中是否標記所有推測性假設與待確認缺口?
③ 開發範疇是否在兩週 MVP 資源限制之內?
④ 成功指標是否具備清晰的計算公式、納入標準與觀測期間?

把規則封裝成 Claude Code Skill

建立 .claude/skills/prd-draft/SKILL.md:

---
name: prd-draft
description: 根據已核准的需求卡產生 PRD 初稿,完整保留證據、假設、界外範疇與待決問題。
---

請依循以下指引產出 PRD 初稿:
① 列出輸入內容中的事實、假設與待確認項目。
② 依序輸出問題陳述、核心目標、界外範疇、主流程、功能清單與指標。
③ 每項關鍵功能皆指派專屬編號(如 FR-01)。
④ 保留所有需人工決策的段落清單。

執行指令:

/prd-draft 請讀取 docs/requirements/REQ-001.md,產生 PRD 初稿並列出不可直接採用的段落。

執行後,終端機清楚呈現 PRD 內容與待人工確認的缺口清單:

Claude Code 依 REQ-001 產出 PRD 初稿,並列出六處不可直接採用的段落
截圖展示了規格生成的嚴謹性:模型主動列出六處待確認項目,提醒團隊針對推測數值與業務政策進行人工審核。

今天的產出物

Day 11 小結:先補證據,再做決定
今天帶走的核心重點是一套結構化 PRD 初稿生成框架:

  • 將抽象需求展開為帶有編號(FR-01)的具體功能清單。
  • 確立界外範疇與成功指標草案,鎖定兩週 MVP 的交付焦點。
  • 主動暴露假設與待確認項目,使初稿成為團隊凝聚共識的討論藍圖。

參考資料


上一篇
Day 10 - 用 Claude Code 整理優先級,但把決策留給人
下一篇
Day 12 - 用 Claude Code 審查 PRD 規格真的可開發?
系列文
今晚來點 Claude Skills:產品開發者的 AI 工作流 共 15 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言