面對分類好的問題群，團隊最需要將痛點清晰轉譯為可研討的基準。
需求卡片的核心價值在於精準區隔「使用者遭遇的困擾」與「工程實作的解法」：
在整理需求卡片時，團隊可以依據專案階段權衡以下兩種方案：
請依循以下四個動作動詞步驟產出需求卡片：
① 界定具體使用者與觸發時機：明確指明卡片適用的角色身分與特定操作時刻。
② 描述問題本質與期待成果：說明使用者遭遇的操作阻礙，以及希望達成的理想目標狀態。
③ 引用原始回饋證據編號：連結至少兩則具備明確 ID 的回饋原文，確保論述有所依據。
④ 標明界外範疇與候選方向：明確界定本次保留項目，並將潛在解法記錄於候選欄位。
以下為依據上一篇分群成果產出的結構化需求卡片示範：
① 卡片編號與名稱：RC-01 工作任務指引卡
② 目標使用者：首次登入且已有被指派工作的團隊成員
③ 觸發情境：接受邀請後，準備開始參與專案工作的時刻
④ 核心問題：面對眾多畫面資訊，難以辨識哪些任務需要自己優先處理
⑤ 期待成果：迅速找到第一件相關工作，並清楚理解後續步驟
⑥ 模擬證據：引述 F03（找不到同事指派任務）、F11（花十分鐘才找到）、F32（難以判定哪則通知需處理）
⑦ 影響範圍：新成員首次工作階段，實際人數規模待統計確認
⑧ 候選方向：提供相關工作入口、加入專案脈絡提示（保留設計彈性）
⑨ 界外範疇：維持現有全域導覽架構；維持主管指派流程現況
⑩ 待驗證項目：首登已具備任務的成員比例、各裝置操作表現一致性
⑪ 潛在風險：過度突顯單一任務導致專案整體脈絡被遮蔽
背景：
FlowBoard 是教學用虛構 B2B SaaS，當前研究題目為新成員啟用體驗。
任務：
① 針對指定的使用者回饋問題群，產出結構化需求卡片。
② 優先引用原始證據 ID，再展開問題陳述與期待成果。
③ 詳列界外範疇與候選方向，保持問題與解法的獨立性。
④ 列出待驗證項目與潛在風險。
輸入：
【產品情境卡】
【回饋分群表與 F01–F50 原始回饋】
規則：
① 聚焦於使用者當下的困擾與期待達成的目標。
② 保持模擬數據的原始樣貌，保留推論界線。
③ 每張卡片引用至少 2 筆原始回饋編號。
④ 潛在解法統一歸入「候選方向」欄位。
⑤ 待確認事項統一記錄於「待驗證項目」。
輸出：
每張卡片依序包含：卡片編號、目標使用者、觸發情境、核心問題、期待成果、
模擬證據、影響範圍、候選方向、界外範疇、待驗證項目、潛在風險。
卡片產出完成：RC-01 首登任務辨識
核心成果摘要：
- 需求核心：協助具備指派任務的新成員迅速聚焦第一件核心工作。
- 證據追溯：關聯 F03、F11、F32 三筆真實痛點發言。
- 方案邊界：保留引導入口與通知提示等候選方向，待團隊共同研討。
這張需求卡片的核心價值在於：促使跨職能團隊在動工前看見相同的問題邊界，讓工程師、設計師與產品經理在相同的證據基礎上展開深度對話。
請團隊在會議中逐一核對以下四個驗證問題：
① 需求描述是否純粹專注於問題與成果，保留解法的探索空間？
② 每項問題陳述是否皆能追溯至明確的原始回饋編號？
③ 界外範疇是否清晰界定，以確保開發資源高度聚焦？
④ 待驗證項目是否具備具體的探索行動與負責成員？
建立 .claude/skills/requirement-card/SKILL.md：
---
name: requirement-card
description: 將已核對的使用者問題群轉化為可討論的需求卡片，保留證據編號、界外範疇與候選解法。
---
請依循以下指引產出卡片：
① 每張卡片完整包含：卡片編號、目標使用者、觸發情境、核心問題、期待成果、證據 ID、待驗證項目、界外範疇。
② 候選解法獨立放置於專屬欄位，保持問題描述的客觀性。
③ 依據既有輸入資料標示證據編號，維持資料來源的可追溯性。
執行指令：
/requirement-card 請把問題群 CL-01 轉成一張需求卡，並指出哪些欄位仍缺資料。
執行後，終端機精準產出帶有證據 ID 的需求卡片：
截圖清楚呈現每個論述皆掛著來源回饋編號，讓團隊隨時能夠追溯至最原始的發言情境。
今天帶走的核心重點是一套可追溯需求卡片規範：
iThome鐵人賽
看影片追技術