在規格審查會中，要怎麼讓大家迅速達成關鍵決策？
這就像火箭發射前的聯合檢查。指揮官、導航員、工程師各自看著自己的儀表板，只要看到紅燈亮起，立刻一起討論並拍板解決。
產品規格審查就是跨職能團隊一起看文件、抓風險、做決定的過程。
① 多角審查視角（Multi-Perspective Review）：
精確定義：結合產品、設計、工程與測試四種專業視角，全方位檢視產品規格的完整性與可行性。
② 審查提問清單（Review Question List）：
精確定義：包含問題編號、專業視角、文件依據、潛在影響以及建議回答者的一覽清單。
③ 決策記錄卡（Decision Record）：
精確定義：白紙黑字寫明拍板決策、選擇原因、執行負責人與完成期限的正式記錄。
先確保聚焦重大決策，再提升跨職能協同效率。
① 同步全員逐條朗讀審查：簡單有效。全體成員在會議中共同閱讀條文並提出問題，適合團隊初期磨合階段。
② 異步提問結合會中決策：高效實用。會前由工具產出問題清單並指派負責人，會議時間專注處理核心待確認項目，大幅縮減同步會議耗時。
① 啟動四重視角提問：依序從產品價值、介面體驗、系統技術與測試邊界進行全面盤點。
② 綁定文件依據編號：為每項提問標註原始需求 ID 與對應條文，確保所有討論皆有所本。
③ 標記待確認項目責任人：將每個待解問題指定給對應的專業角色，由人類負責人做出決策。
④ 產出正式決策卡片：記錄最終決策、採用原因、完成時限與影響範圍，同步更新規格文件。
依據 FlowBoard 規格需求，梳理出五項核心審查提問卡片：
① 審查項目 R-01（產品視角）
② 審查項目 R-02（設計視角）
③ 審查項目 R-03（工程視角）
④ 審查項目 R-04（測試視角）
⑤ 審查項目 R-05（資料視角）
透過上述卡片，團隊在會前即可掌握具體討論焦點。此外，會議前建議執行一次「反向追溯」：由每個驗收情境回推原始需求，再由需求連結商業目標。若驗收情境具備重試機制，PRD 就必須對應定義異常狀態，確保規格前後一致。
會中針對核心阻塞議題完成拍板，產出決策卡片：
決策卡片 D-01
- 對應項目：R-01、FR-02
- 拍板決定：第一項任務取「到期日最早者」；同日建立者依建立時間依序排列。
- 採納理由：充分運用現有欄位，排序規則具備高度可解釋性。
- 待確認技術細節：確認既有查詢機制支援穩定排序。
- 執行負責人與期限：產品經理、工程師／展示日前完成
角色：你是一位專業的規格審查主持助手，專門協助團隊梳理問題與風險。
輸入資料：
【貼上 PRD、需求 ID、使用者故事、驗收標準、限制條件與待確認問題】
執行步驟：
① 啟動四重視角提問：依序從產品價值、介面體驗、系統技術與測試邊界展開檢核。
② 標記文件依據：每項提問必須精確標註對應的需求 ID 與文字段落；缺少條文時標示「外部待查」。
③ 指派回答角色：為每項問題指定最適合回答的專業角色，評估待決問題的潛在影響。
④ 整理關鍵阻塞清單：合併重複提問，標示優先處理的前三項核心阻塞議題。
輸出格式：
審查 ID／專業視角／對應需求 ID／文件依據／提問內容／潛在影響／建議回答者／目前狀態
透過規格審查提示詞，工具產出結構清晰的議題卡片，將長篇條文轉化為條理分明的待決策清單。這項做法的核心價值在於讓會議跳脫單向的條文宣讀，把全員精力集中於高風險項目的裁決與共識凝聚。
① 提問內容有沒有切中真實業務與技術？
② 風險評估客不客觀？
③ 有沒有漏掉資安、隱私等關鍵領域？
④ 每項決定是不是都由真正的負責人親自確認？
建立檔案路徑：
.claude/skills/prd-review/SKILL.md
設定 YAML 內容：
---
name: prd-review
description: 從產品、設計、工程與 QA 視角檢查 PRD 和驗收標準，整理問題、依據、負責人與決策狀態。
---
請從產品、設計、工程與測試四重視角檢視規格文件。
每個問題皆附上對應條文、潛在影響、建議回答者與狀態：open、answered 或 blocked。
保留全部待確認問題，交由專業負責人拍板裁決。
在 Claude Code 中執行指令：
/prd-review 請讀取 PRD、US-01 與驗收條件，主持一次四角色規格審查。
實際執行截圖說明：
執行完成後，輸出完整保留開放討論的 open 問題清單，精確標示待確認的責任角色，讓團隊在會議中逐一聚焦解決。
今天產出一份跨職能審查提問清單、決策記錄卡格式與已確認的排序決策 D-01。由 AI 整理問題，由人類拍板定案，讓規格審查真正發揮推進專案的效果。
iThome鐵人賽
看影片追技術