Day 12 - 用 Claude Code 審查 PRD 規格真的可開發？

什麼是 PRD 可開發性審查？

這就像是太空船發射前的壓力測試。在工程師開始寫程式前，把規格文件裡藏著的模糊地帶通通抓出來，確保系統遇到狀況時不會直接掛掉。

核心概念拆解

盤查時要看六個地方：
① 對象判定：精確定義誰能用、誰不能用。
② 觸發時機：搞懂使用者做了什麼動作，系統才啟動。
③ 狀態涵蓋：把讀取中、資料空白、網路慢、權限不夠的畫面都想好。
④ 邊界限制：訂出數字上限，像是最多能打幾個字、檔案多大。
⑤ 使用者控制：讓使用者能自己按重試、略過或返回。
⑥ 成果可觀測性：確定這個功能怎麼去追蹤數據和驗收。

在執行規格審查時，團隊可以在以下兩種方案間進行取捨：

• 方案 A（簡單有效）：工程設計快速走查。直接召集雙方口頭對齊主要流程，適合步調極快且介面變動小的改版。

• 方案 B（高效有用）：六維度結構化缺口審查清單。逐項窮舉極端狀態與邊界條件，能確保複雜功能在進入 Sprint 前完全具備可執行性。

執行規則

請依循以下四個動作動詞步驟盤點 PRD 缺口：

① 審視對象與觸發條件：確認新成員資格判定與首登觸發時機之精確定義。
② 窮舉各種介面與網路狀態：盤點載入中、空白資料、操作成功、網路延遲與權限受限之回饋機制。
③ 替換所有模糊形容詞彙：將「快速」、「適度」等抽象文字轉化為可度量的具體數據指標。
④ 標定決策責任歸屬角色：為每一個待決缺口指派負責協調的 PM、設計師或工程師。

結構化示範：四項規格缺口卡片

以下為教學用模擬案例中，經由審查浮現的四項關鍵規格缺口卡片：

① 規格缺口卡：Q-01 FR-01 對象身分定義模糊

• 關聯需求：FR-01 新成員起始引導
• 具體缺口：「新成員」定義尚待具體化，訪客或既有成員重新登入時之處置方式待明確。
• 潛在影響：可能導致既有成員重複收到起始引導。
• 決策歸屬：PM 與工程負責人共同確立判斷規則。

② 規格缺口卡：Q-02 FR-02 任務載入逾時狀態待補

• 關聯需求：FR-02 前往任務主要行動
• 具體缺口：若網路連線延遲或任務資料讀取超時，介面反饋方式待定義。
• 潛在影響：使用者可能面對卡頓畫面。
• 決策歸屬：設計師與工程負責人共同協同補齊重試機制。

③ 規格缺口卡：Q-03 FR-03 缺少任務之替代指引待定

• 關聯需求：FR-03 缺少指派任務之引導
• 具體缺口：成員進入工作區尚待指派任務時的介面內容與聯繫動線待決。
• 潛在影響：成員面臨缺少具體操作指引之情境。
• 決策歸屬：PM 與設計師共同確立引導文案。

④ 規格缺口卡：Q-04 指標納入與計算條件需補齊

• 關聯需求：成功指標草案
• 具體缺口：完成任務之精確事件代碼與異常帳號排除條件待補齊。
• 潛在影響：成效追蹤資料難以精準重現。
• 決策歸屬：PM 與數據分析師共同定案。

提示詞設計（Prompt）

角色：
你是產品規格審查助手。請審查下列 PRD，提供結構化缺口清單。

輸入：
【貼上 PRD 規格文件】

審查維度：
① 核心目標與界外範疇之一致性。
② 需求之適用對象與觸發條件精確度。
③ 載入中、資料空白、成功、異常、權限受限與重複操作之完整性。
④ 模糊形容詞（如快速、友善、適量）轉化為具體數據度量。
⑤ 驗收完成條件與明確待決問題。

規則：
① 聚焦於文字中呈現之規格缺口。
② 遇到資訊待補之處，標註為【待補充資料】。
③ 明確指出各項缺口建議由誰負責決策（PM／設計／工程）。

輸出：
依序輸出：缺口卡片清單（編號、需求 ID、缺口描述、潛在影響、決策負責人）、
優先處理的三大關鍵阻礙與理由。

範例輸出與核心價值

經過缺口審查後，原本模糊的條目被修訂為具備高度可開發性的規格條目：

FR-01 新成員提示（修訂版）
- 適用對象：首次加入該工作區且已啟用帳號之成員。
- 觸發時機：接受邀請後首次成功載入工作區首頁。
- 介面行為：頁面顯著呈現起始引導區塊與一項主要操作。
- 結束條件：成員完成第一項任務，或主動選取略過提示。
- 排除對象：訪客身分、既有成員更換瀏覽器登入。
- 待決問題：略過後重新呼叫引導之操作入口。

這項審查的核心價值在於：在開發前消除歧義，將空白與推測轉化為具體決策，確保工程開發順暢推進。

人類需要檢查什麼

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

① 各種異常狀態（載入延遲、資料為零）是否皆有清晰的介面引導？
② 邊界數值（字數上限、超時秒數）是否已具備可落地的明確定義？
③ 使用者是否保有自主略過或重新呼叫說明的操作選項？
④ 產品、設計與工程負責人是否對各自負責的規格區塊達成共識？

把規則封裝成 Claude Code Skill

建立 .claude/skills/prd-completeness/SKILL.md：

---
name: prd-completeness
description: 檢驗 PRD 的對象、觸發、狀態、邊界、控制與觀測性，產出結構化缺口清單。
---

請依循以下步驟進行規格審查：
① 盤查正常流程、資料為零、載入中、逾時、權限受限與重複操作。
② 每個缺口標註關聯 PRD 段落、潛在風險、決策負責人與建議補充項目。
③ 將實作架構選擇與產品業務決策清楚區隔。

執行指令：

/prd-completeness 請檢查 docs/prd/flowboard-onboarding.md，依六種問題分類輸出缺口。

執行後，終端機詳細呈現前半段的正常路徑、資料為零與載入中狀態分析：

輸出的後半段詳細標記需要工程與設計共同確認的項目，確保職能分工明確：

截圖展示了結構化審查的力量：所有隱藏的盲點在進入 Sprint 前被逐一標定，使 PRD 真正具備可開發性。

今天的產出物

今天帶走的核心重點是一套PRD 可開發性審查體系：

• 掌握六大維度（對象、觸發、狀態、邊界、控制、觀測）的盤查重點。
• 將模糊語句轉化為可驗證、可落地的精確邊界規格。
• 為每個待決缺口指派專屬決策角色，加速跨職能協同交付。

參考資料

• Atlassian：How to create a product requirements document