product-playbook 1.0.0

package/i18n/zh-TW/references/02b-jtbd.md

@@ -0,0 +1,125 @@
+# 階段一：Discovery — JTBD 分析
+
+## 1.3 JTBD（Jobs to Be Done）分析
+
+> 「分析的單位不是消費者，而是消費者試圖完成的那件工作。」— Clayton Christensen
+
+**JTBD 描述公式：**
+```
+[瞄準的顧客] + 想要在 [什麼工作情境 Job Context] + 完成 [什麼工作 Jobs]
+```
+
+範例：正在比較房貸方案的首購族，想要在深夜不方便聯絡銀行時，快速估算每月還款金額，以便向伴侶說明財務規劃。
+
+**JTBD 四種類型分析表：**
+
+```
+| JTBD 類型 | 定義 | Persona 1 | Persona 2 |
+|-----------|------|-----------|-----------|
+| 功能性工作（Functional Job） | 完成特定任務或達成功能性目標 | | |
+| 情感性工作（Emotional Job） | 感受或希望有什麼感受 | | |
+| 社交性工作（Social Job） | 希望在他人眼中呈現什麼形象 | | |
+| 工作情境（Job Context） | 在什麼情況下需要完成這份工作 | | |
+```
+
+**JTBD 深挖五問：**
+1. **根本問題**：用戶表達的需求背後，真正想解決的是什麼？
+2. **現行限制**：哪些解法因為某些條件限制被排除在外？
+3. **現行做法**：用戶現在用什麼方法應對？做了哪些 workaround？
+4. **差距**：現行做法哪裡無法令他們滿意？（這個差距就是你的機會）
+5. **理想解法**：如果限制消除，他們理想中的解法是什麼樣子？
+
+**Teresa Torres 用戶訪談最佳實踐：**
+- 聚焦在用戶過去的**實際行為**，而不是假設性的未來行為
+- 問「上一次你遇到這個問題時，你怎麼做的？」而不是「你希望有什麼功能？」
+- 最常見錯誤：問假設性問題、帶入解法偏見、沒有追問細節
+
+### 📝 JTBD 品質自檢清單
+
+Claude 產出 JTBD 後必須自我檢查（每項必須標記 ✅ 或 ❌，❌ 項目必須說明如何改善）：
+- [ ] 是否包含具體情境？（不是「隨時隨地」，而是「在深夜不方便聯絡銀行時」）
+- [ ] 是否聚焦在一個核心工作？（不是三個 Job 合併成一句）
+- [ ] 功能性/情感性/社交性工作是否都有識別？
+- [ ] 是否能用來判斷「這個解法有沒有解決這個 Job」？
+- [ ] 是否包含「現行做法」和「差距」？（差距 = 機會）
+- [ ] 深挖五問的 Q5 是否觸及情感動機/職業認同/心理恐懼？（非功能性描述）
+
+**執行規則（Hard Gate）**：
+- 必須逐項標記 ✅ 或 ❌，不允許保留空白 [ ] 或不說明的 ✅ 列表
+- 若所有項目都是 ✅，必須額外說明「這份分析最弱的一個環節是什麼，如何補強」
+- ❌ 常見問題：太抽象、太多 Job 合併、缺少情境、用產品功能替代 Job 描述、Q5 停在功能層面
+
+---
+
+### 🏢 B2B 產品專用深度要求
+
+**B2B 產品（含 B2B2C）必須完成以下分析：**
+
+#### 組織層級 Job 分析（必填，至少覆蓋 2 層）
+
+| 層級 | 說明 | 範例 |
+|------|------|------|
+| **Strategic Job** | 組織/管理層的跨部門需求 | 合規稽查、成本控制、人力資源優化 |
+| **Operational Job** | 流程/部門主管的協調需求 | 審批流程管理、跨部門資訊同步 |
+| **Task Job** | 個別使用者的日常操作需求 | 填寫表單、查詢狀態、匯出報表 |
+
+#### 買方（Buyer）vs 使用者（User）分析（必填）
+
+若買方與使用者不同人，必須分別分析其 JTBD：
+- **買方 Job**：影響採購決策的工作（ROI 說明、風險降低、合規要求）
+- **使用者 Job**：日常操作時需要完成的工作（效率提升、錯誤減少）
+- 若同一人，說明「為何此場景中決策者即使用者」
+
+#### 深挖五問 B2B 強化版
+
+深挖五問的 **Q5 必須到達以下任一層面**（舉例）：
+- ✅ 職業認同：「她怕在高層面前出糗，因為這份報表代表她部門的專業度」
+- ✅ 情感動機：「他想要在下屬面前展現自己掌握數字的能力」
+- ✅ 心理恐懼：「她最怕的是被稽核單位抓到流程漏洞，因為上次已經被警告過一次」
+- ❌ 不合格範例：「他需要一個更好的工具來提高效率」（停留在功能層面）
+
+#### 競品替代品分析（必填）
+
+列出目前使用者實際使用的替代方案：
+- 至少 2 個具名現行工具（如 Line/Excel/紙本/Email/口頭溝通）
+- 每個工具必須說明其「根本缺陷」：不是功能差，而是「為什麼這個缺陷被接受卻沒被解決」（組織慣性？切換成本？上級不在意？）
+
+### 📋 用戶訪談計畫模板
+
+```
+## 用戶訪談計畫
+
+**研究目標**：了解 [目標 Persona] 在 [Job Context] 中的 [具體問題]
+**受訪者篩選條件**：
+  - 必須在過去 [X 天/週] 內有過 [具體行為]
+  - 排除：[哪些人不適合，例如內部員工、已知的忠實用戶]
+
+**核心問題（5-7 題）**：
+1. 上一次你遇到 [問題] 時，可以帶我走一遍你是怎麼處理的嗎？（行為回溯）
+2. 在那個過程中，最讓你困擾/花最多時間的是哪個環節？（痛點定位）
+3. 你有試過其他方法嗎？為什麼用/不用？（現行替代方案）
+4. 如果那個環節可以變得更好，「好」對你來說是什麼樣子？（理想狀態）
+5. 這件事多久會發生一次？最近一次是什麼時候？（頻率和急迫性）
+6. 除了你以外，還有誰會受到這個問題的影響？（利害關係人）
+7. 如果要用 1-10 分評量這個問題的嚴重程度，你會打幾分？為什麼？（量化痛感）
+
+**追問策略**：
+  - 當受訪者說「通常我會...」→ 追問「上一次具體是什麼情況？」
+  - 當受訪者提到情緒 → 追問「那個感覺具體是什麼？」
+  - 當受訪者提到某個工具/方法 → 追問「是什麼讓你選擇這個方式？」
+
+**記錄格式**：
+  - 逐字稿 or 錄音
+  - 訪後 24 小時內標記：關鍵引言 / 痛點 / 驚喜發現 / 與假設不符之處
+```
+
+---
+
+## 📎 本階段的檔案整合提示
+
+如果使用者在此階段上傳了檔案，Claude 依據以下規則整合：
+
+| 上傳內容 | 整合到 | 整合動作 |
+|---------|-------|---------|
+| 用戶訪談逐字稿 / 錄音文字 | 1.1 Persona + 1.3 JTBD | 提取：用戶背景 → Persona 欄位；痛點 + 現行做法 → JTBD 深挖五問；情緒反應 → 情感性/社交性 Job |
+| 競品 App 截圖 | 1.3 JTBD（現行做法） | 識別為用戶的「現行替代方案」，分析 Workaround 和差距 |

package/i18n/zh-TW/references/02c-ost-journey.md

@@ -0,0 +1,65 @@
+# 階段一：Discovery — OST + Journey Map
+
+## 1.4 機會解法樹（Opportunity Solution Tree / OST）
+
+**適用於：完整模式 / 高完整性**
+
+OST 從產品目標出發，系統化連結機會和解法：
+
+```
+[產品目標 / Desired Outcome]
+    │
+    ├── [機會 1：用戶痛點或需求]
+    │       ├── [解法 1a]
+    │       └── [解法 1b]
+    ├── [機會 2：用戶痛點或需求]
+    │       └── [解法 2a]
+    └── [機會 3：用戶痛點或需求]
+            └── [解法 3a]
+```
+
+核心原則：
+- 目標（Outcome）是可衡量的結果，不是功能或產出
+- 機會（Opportunity）來自用戶研究，而不是內部腦力激盪
+- 解法（Solution）對應機會，不要跳過機會直接討論解法
+- 先廣後深：先列出所有機會，再逐一探索解法
+
+## 1.5 User Journey Map
+
+**適用於：完整模式 / 高完整性 / 產出對象為設計師**
+
+**Step 1：概覽表**
+
+```
+**[Persona名] — 任務：[任務描述]**
+
+| 階段 | 核心行為 | 情緒 | 關鍵痛點 |
+|---|---|---|---|
+| [階段1] | [一句話描述主要行為] | [情緒 + emoji] | [最重要的那個痛點] |
+```
+
+**Step 2：逐段展開細節**
+
+```
+> **階段：[階段名稱]**
+> - **Doing（行為）**：[這個階段用戶實際做了什麼]
+> - **Thinking（想法）**：[用戶腦中在想什麼，盡量用第一人稱口語]
+> - **Feeling（感受）**：[情緒狀態及原因]
+> - **Stakeholder（關係人）**：[這個階段涉及哪些人]
+> - **Problem（痛點）**：[具體的困難或不滿]
+```
+
+**Step 3：Grouping**
+- 如果階段太細碎，合併成更大的階段群組
+- 統整每個階段的痛點，標記哪些是核心痛點
+
+---
+
+## 📎 本階段的檔案整合提示
+
+如果使用者在此階段上傳了檔案，Claude 依據以下規則整合：
+
+| 上傳內容 | 整合到 | 整合動作 |
+|---------|-------|---------|
+| 白板 / 手繪流程圖 | 1.5 Journey Map | 辨識流程後轉化為結構化表格；保留原始情緒標記 |
+| 用戶行為數據（CSV） | 1.4 OST + 1.5 Journey Map | 用數據佐證哪些行為路徑最常見、哪些階段流失最多 |

package/i18n/zh-TW/references/03-define.md

@@ -0,0 +1,118 @@
+# 階段二：Define（定義）— 收斂問題
+
+> **注意：各模式應執行哪些步驟，以 SKILL.md 中「各模式步驟序列」為權威定義。以下僅供參考。**
+
+**完整模式 / 高完整性 → 全做（2.1 ~ 2.4）**
+**中完整性 → 2.1 + 2.3 + 2.4**
+**快速模式 / 低完整性 → 只做 2.3（一個核心 HMW）**
+
+在進入此階段前，確認產品核心三問：Who is it for? / Why build it? / What is it?
+
+## 2.1 痛點彙整表
+
+從所有 Persona 和 User Journey Map 中提取痛點：
+
+```
+| 編號 | 痛點描述 | 來源 Persona | 出現在哪個階段 | 影響程度（高/中/低） | 出現頻率（高/中/低） |
+|---|---|---|---|---|---|
+| P1 | | | | | |
+| P2 | | | | | |
+```
+
+## 2.2 April Dunford 的產品定位框架（Positioning）
+
+**適用於：中/高完整性 / 產出對象為老闆/業務/行銷**
+
+定位不是口號，而是決定你在哪裡競爭、為誰競爭：
+
+```
+| 定位要素 | 問題 | 你的答案 |
+|---------|------|---------|
+| 競爭替代品 | 如果你的產品不存在，用戶會用什麼？（真實答案，不是你認為的競爭對手） | |
+| 獨特屬性 | 你有哪些是競爭替代品沒有的功能或特性？ | |
+| 對用戶的價值 | 這些獨特屬性對用戶帶來什麼實際價值？ | |
+| 目標市場特徵 | 哪些用戶最在意這些價值？（越具體越好） | |
+| 市場類別 | 你的產品最好被放在哪個市場框架下看待？（框架決定競爭標準） | |
+```
+
+最常見的定位錯誤：
+- 把功能當成定位（「我們有 AI！」不是定位）
+- 定位太模糊，覆蓋所有人等於不覆蓋任何人
+- 以自己認為的競爭對手為參照，而不是用戶實際的替代方案
+
+### 📝 Positioning 品質自檢清單
+- ✅ 「競爭替代品」是否來自用戶視角？（用戶真的會用什麼替代，不是你認為的競對）
+- ✅ 「獨特屬性」是否是競爭替代品做不到或做不好的？（不是你有別人也有的東西）
+- ✅ 「對用戶的價值」是用戶語言還是產品語言？（「節省 2 小時」vs「AI 驅動自動化」）
+- ✅ 「目標市場」是否夠具體到能找到這些人？
+- ✅ 五個定位要素之間是否邏輯一致？
+- ❌ 常見問題：獨特屬性和價值之間斷裂、市場類別選錯導致被錯誤標準評判
+
+## 2.3 HMW（How Might We）問題轉化
+
+將痛點轉化為 HMW 問題，同時結合 JTBD 視角確認每個 HMW 背後對應的工作類型：
+
+```
+| 痛點編號 | 痛點 | 對應 JTBD 類型 | HMW 問題 |
+|---|---|---|---|
+| P1 | [痛點描述] | 功能性 / 情感性 / 社交性 | 我們可以如何... |
+| P2 | [痛點描述] | | 我們可以如何... |
+```
+
+HMW 粒度原則：
+- 太大（「如何讓用戶更開心」）→ 沒有方向感
+- 剛好（「如何讓用戶在 60 秒內完成第一次設定」）→ 有約束又有空間
+- 太小（「如何改按鈕顏色」）→ 限制了可能性
+
+### 📝 HMW 品質自檢清單
+- ✅ 是否有明確的約束條件？（不是完全開放式）
+- ✅ 是否保留了足夠的解法空間？（不是指向唯一解）
+- ✅ 是否能直接對應到一個 JTBD 或痛點？
+- ✅ 團隊看到這個 HMW 是否能開始發想解法？
+- ❌ 常見問題：太大（等於重述願景）、太小（等於指定解法）、多個問題混在一起
+
+**範例：**
+- ❌ 太大：「我們可以如何讓用戶更滿意？」
+- ✅ 剛好：「我們可以如何讓首購族在 3 分鐘內算出自己負擔得起的房貸金額？」
+- ❌ 太小：「我們可以如何在首頁加一個房貸計算機？」
+
+## 2.4 機會評估表
+
+對 HMW 問題進行優先排序：
+
+```
+| HMW 問題 | 影響 Persona | Persona 規模 | 用戶影響（1-5） | 商業價值（1-5） | 可行性（1-5） | 總分 | 優先級 |
+|---|---|---|---|---|---|---|---|
+| | [列出受影響的 Persona] | [大/中/小] | | | | | |
+```
+
+**評分量尺定義：**
+
+| 分數 | 用戶影響 | 商業價值 | 可行性 |
+|------|---------|---------|--------|
+| 1 | 少數人偶爾不便 | 間接且長期才可能有回報 | 需要全新技術或大量未知研究 |
+| 2 | 部分用戶偶爾遇到 | 可能間接帶動部分指標 | 需要顯著的新能力建設（3+ 個月） |
+| 3 | 核心 TA 定期遇到 | 對關鍵指標有正面影響 | 需要一些新開發但技術上可行（1-3 個月） |
+| 4 | 大量用戶頻繁遇到 | 直接推動用戶增長或留存 | 現有團隊能力範圍，需 2-4 週 |
+| 5 | 大量用戶每天無法完成核心任務 | 直接驅動營收或大幅影響北極星指標 | 現有團隊兩週內可完成 |
+
+**Shreyas Doshi 的機會成本思維：**
+
+不要問「這個功能的 ROI 是多少？」，而是問：
+
+> 「如果我把資源投入 A，我放棄了投入 B 的機會。我確定 A 比 B 更值得嗎？」
+
+ROI 思維讓你評估單個機會是否值得；機會成本思維讓你在所有機會之間做出更好的選擇。
+
+**0-to-1 聚焦提醒：** 完成機會評估後，建議只選**一個最高優先級的 HMW 問題**作為 MVP 核心。（Facebook：大學生→高中生→所有人；個人主頁→相片→動態牆）
+
+---
+
+## 📎 本階段的檔案整合提示
+
+| 上傳內容 | 整合到 | 整合動作 |
+|---------|-------|---------|
+| 競品截圖 / 競品分析報告 | 2.2 Positioning | 填入「競爭替代品」和「獨特屬性」欄位；比對差異化 |
+| 市場報告（PDF） | 2.4 機會評估 | 用市場數據佐證 Persona 規模和商業價值評分 |
+| NPS / 滿意度調查數據 | 2.1 痛點彙整 | 用真實分數替代假設性影響程度和頻率 |
+| 客服 / Support ticket 彙整 | 2.1 痛點彙整 + 2.3 HMW | 統計痛點頻率；從高頻 ticket 直接轉化為 HMW |

package/i18n/zh-TW/references/04a-prfaq.md

@@ -0,0 +1,106 @@
+# 階段三：Develop — PR-FAQ（Working Backwards）
+
+## 3.1 Amazon 的逆向工作法（Working Backwards / PR-FAQ）
+
+先寫產品新聞稿，強迫你從用戶結果出發：
+
+```
+## [產品名稱] 發布新聞稿
+
+**標題**：[用戶能得到什麼？一句話]
+**副標題**：[解決了什麼問題、為誰解決]
+
+**正文第一段（Aha Moment）**：
+[描述用戶體驗這個產品的那個「哇啊！」時刻]
+
+**痛點描述**：
+[用戶現在面臨什麼問題？現行解法為什麼不夠好？]
+
+**解法描述**：
+[我們的產品如何解決這個問題？（描述體驗，不要列功能清單）]
+
+**用戶引言**：
+"[一位目標用戶說的話，代表真實的情感反應]"
+
+**FAQ（最難回答的問題）**：
+Q：[最難回答的問題]
+A：[誠實的回答]
+```
+
+> 如果你無法把新聞稿寫得讓人興奮，代表這個產品方向可能有問題，需要回頭重新定義問題。
+
+### 📝 PR-FAQ 品質自檢清單
+
+Claude 產出 PR-FAQ 後必須逐項標記 ✅ 或 ❌，❌ 項目必須說明如何改善：
+- [ ] 標題是否從用戶角度出發？（「用戶能做到 X」vs「我們推出了 Y 功能」）
+- [ ] 第一段是否能讓讀者在 10 秒內理解「這為什麼重要」？
+- [ ] 痛點描述是否來自真實用戶場景？
+- [ ] 解法段第一句是否以用戶感受/場景開頭（非功能動詞）？
+- [ ] 用戶引言是否像真人會說的話？
+- [ ] FAQ 是否包含了對比現有工具的尖銳質疑？
+
+**執行規則（Hard Gate）**：
+- 必須至少找出 1 個「內部張力」或「值得迭代的地方」，不得全部 ✅ 宣告完成
+- 若所有項目都通過，額外說明「這份 PR-FAQ 最脆弱的假設是什麼」
+- Amazon PR-FAQ 的品質是靠找到問題，不是確認沒問題
+- ❌ 常見問題：標題像產品公告不像新聞、解法段變成功能列表、FAQ 都是容易回答的問題
+
+---
+
+### ✍️ 解法段落（Body）寫作規則
+
+**解法段第一句禁止以功能描述起頭。**
+
+❌ 禁止範例：
+- 「備料通讓你一鍵輸入菜單自動計算食材」
+- 「系統會自動根據菜單生成採購清單」
+- 「點擊『生成清單』按鈕即可完成備料規劃」
+
+✅ 正確範例：
+- 「現在，陳師傅週五下午只需 10 分鐘，就能確認週末備料的每一個細節」
+- 「張主任不再需要在週五下午翻三份 Excel 才能確定食材夠不夠」
+
+**公式**：先寫用戶感受/具體情境 → 然後才說「這是因為 [產品機制]」帶出功能。
+
+---
+
+### ❓ FAQ 尖銳質疑標準
+
+**至少 1 個 FAQ 必須是：「為什麼不繼續用 [現有工具]？」**
+
+回答格式要求：
+1. **先正面承認現有工具的優點**（不能否定它）
+2. **然後說明 gap**（不是功能不足，而是根本的場景缺口）
+
+❌ 禁止回答模式：「現有工具功能不足，我們更強大」
+✅ 正確回答模式：
+> 「Excel 確實能記錄數字，廚師也早就會用。問題是每次週末前的計算需要重新填表、重新換算，花 1 小時不是因為笨，是因為這個問題就是這麼複雜。備料通省的不是 Excel 技能，是每次都要重頭算的心理負擔。」
+
+**範例（虛構產品 — 房貸計算 App）：**
+
+```
+## MortgageSnap 讓首購族 3 分鐘搞懂自己買得起什麼房
+
+**副標題**：不用跑銀行、不用等試算表回覆，深夜也能和伴侶一起看清楚每月還款數字
+
+**正文第一段（Aha Moment）**：
+小陳在深夜滑完一輪 591，看到心動的房子但不知道自己到底負擔得起。他打開 MortgageSnap，
+拍了房屋頁面截圖，App 自動抓出總價、坪數，30 秒內顯示三種貸款方案的每月還款金額。
+他把結果分享給太太，兩人終於有了同一份數字基礎來討論。
+
+**痛點描述**：
+首購族在比較房貸時，需要在多家銀行之間手動輸入條件、等待回覆，
+深夜想算個數字卻找不到方便的工具，結果常常是用 Excel 亂算或直接放棄。
+
+**解法描述**：
+MortgageSnap 讓你拍下任何房屋資訊，自動提取關鍵數據，即時比較各銀行方案，
+並生成一份可分享的報告讓家人一起討論。
+
+**用戶引言**：
+「終於不用在半夜等銀行回電話了。三分鐘就能跟老婆說清楚每個月要還多少錢。」
+
+**FAQ**：
+Q：市面上已經有很多房貸計算機了，這有什麼不同？
+A：現有計算機需要你自己輸入利率、年限等參數，但大多數首購族根本不知道這些數字。
+MortgageSnap 的差異在於自動帶入各銀行真實方案，用戶只需要提供房價和自備款。
+```

package/i18n/zh-TW/references/04b-solutions.md

@@ -0,0 +1,269 @@
+# 階段三：Develop — 解法設計與優先排序
+
+## 3.2 平行原型原則（Parallel Prototyping）
+
+同時發展多個平行方案，不要只設計一個解法就急著執行：
+
+```
+| HMW 問題 | 解法 A（保守/漸進） | 解法 B（平衡） | 解法 C（大膽/顛覆） |
+|---|---|---|---|
+| [HMW1] | | | |
+```
+
+三個解法品質門檻：
+- 解法 A 是否比現有做法明顯更好？
+- 解法 C 是否真的能解決核心 JTBD？
+- 三個解法是否真的不同，還是只是同一個想法的微調？
+
+## 3.3 Shreyas Doshi 的 Pre-mortem（事前驗屍）
+
+**適用於：中/高完整性 / 產出對象為工程師/自己內部規劃**
+
+選定解法之前，假設它已經失敗：
+
+```
+假設：我們選擇了解法 X，並在 [時間] 後宣告失敗。為什麼它失敗了？
+
+| 失敗原因 | 發生可能性（高/中/低） | 可預防性（高/中/低） | 預防措施 |
+|---------|----------------------|---------------------|---------|
+| | | | |
+```
+
+**安全性失敗情境**（必須至少考慮一項，特別是涉及用戶資料的產品）：
+
+```
+| 安全性風險 | 發生可能性 | 可預防性 | 預防措施 |
+|-----------|-----------|---------|---------|
+| 用戶資料洩漏（資料庫入侵、API 未授權存取） | | | |
+| 帳號被大量盜用（暴力破解、credential stuffing） | | | |
+| API 被濫用（無 rate limiting、爬蟲大量存取） | | | |
+| XSS / CSRF 攻擊導致用戶受害 | | | |
+| 敏感資料意外暴露（secrets 進版控、日誌記錄密碼） | | | |
+```
+
+> 如果產品不涉及用戶認證或敏感資料，可標記「不適用」並說明原因。
+
+## 3.4 Gibson Biddle 的 GEM 優先排序模型（Netflix）
+
+```
+| 功能 | G（Growth 用戶增長） | E（Engagement 用戶黏著） | M（Monetization 商業獲利） | 整體優先級 |
+|------|---------------------|------------------------|--------------------------|-----------|
+| | | | | |
+```
+
+**Impact / Effort Matrix：**
+
+```
+| 功能 / 解法 | 影響力（高/中/低） | 所需投入（高/中/低） | 象限 |
+|---|---|---|---|
+| | | | Quick Win / Strategic / Fill-in / Avoid |
+```
+
+## 3.5 RICE 量化優先排序
+
+**適用於：高完整性 / 產出對象為資料科學家/老闆**
+
+```
+RICE 分數 = (Reach × Impact × Confidence) / Effort
+
+| 功能 | Reach（影響用戶數/月） | Impact（0.25/0.5/1/2/3） | Confidence（%） | Effort（人月） | RICE 分數 |
+|------|----------------------|------------------------|----------------|--------------|----------|
+| | | | | | |
+```
+
+**Impact 量尺定義：**
+| 分數 | 等級 | 判斷依據 |
+|------|------|---------|
+| 3 | 極高（Massive） | 根本性改變用戶體驗；直接解決核心 JTBD |
+| 2 | 高（High） | 顯著改善用戶體驗；對北極星指標有明確正面影響 |
+| 1 | 中（Medium） | 有感的改善；對部分用戶或部分場景有幫助 |
+| 0.5 | 低（Low） | 微小改善；nice-to-have |
+| 0.25 | 極低（Minimal） | 幾乎感覺不到差異；只是維護性質 |
+
+**Confidence 判斷參考：**
+- 100%：有量化數據支持（A/B 測試、用戶數據）
+- 80%：有質化數據支持（用戶訪談、競品驗證）
+- 50%：有合理假設但未驗證
+- 20%：純粹直覺或猜測
+
+> 「不要優先排序功能（features），要優先排序問題（problems）。功能是解法，在你確認了問題的優先級之後才有意義。」— Shreyas Doshi
+
+## 3.6 User Story 表
+
+**適用於：產出對象為工程師**
+
+```
+| 編號 | User Story | 驗收標準 | 優先級 |
+|---|---|---|---|
+| US1 | 身為[Persona]，我想要[功能]，以便[價值] | | |
+```
+
+---
+
+## 📄 PRD 產出格式（產出對象為工程師時使用）
+
+當使用者說「產出 PRD」或「產出給工程師的文件」時，整合前面所有相關步驟，產出以下完整格式：
+
+```
+# [產品名稱] Product Requirements Document
+
+**版本**：v[X.X]　**日期**：[日期]　**作者**：[PM 名稱]
+**狀態**：草稿 / 審閱中 / 已核准
+
+---
+
+## 1. 背景與目標
+
+**問題陳述**：[從 HMW 問題轉化，一段話說明為誰解決什麼問題]
+**目標 Persona**：[哪個 Persona]
+**核心 JTBD**：[Target Customer] + 想要在 [Job Context] + 完成 [Job]
+**成功指標**：[North Star Metric + Hero Metric]
+
+---
+
+## 2. 解決方案概述（來自 PR-FAQ）
+
+**產品一句話描述**：[PR-FAQ 標題]
+**Aha Moment**：當用戶完成 [行為]，他們體驗到核心價值
+**產品定位**：[April Dunford 定位摘要，若有執行]
+
+---
+
+## 3. 功能範圍
+
+### MVP 必須有
+| 功能 | 說明 | 優先級 | 備註 |
+|------|------|--------|------|
+| | | P0 | |
+
+### V2 加入
+| 功能 | 說明 | 優先級 | 備註 |
+|------|------|--------|------|
+| | | P1 | |
+
+### 明確不做（Not Doing List）
+| 不做的事 | 不做的理由 |
+|---------|-----------|
+| | |
+
+---
+
+## 4. 使用者故事（User Stories）
+
+| 編號 | As a... | I want to... | So that... | 驗收標準 | 優先級 |
+|------|---------|-------------|------------|---------|--------|
+| US-001 | [Persona] | [行為] | [價值] | - [ ] 條件1 | P0 |
+
+---
+
+## 5. 功能規格
+
+> 對每個 P0 功能，說明以下內容：
+
+### [功能名稱]
+- **描述**：[這個功能做什麼]
+- **觸發條件**：[什麼情況下觸發]
+- **正常流程**：[步驟 1 → 2 → 3]
+- **例外流程**：[錯誤情境、邊界條件]
+- **驗收標準**：
+  - [ ] [可測試的具體條件]
+  - [ ] [可測試的具體條件]
+
+---
+
+## 6. 技術考量
+
+**已知技術限制**：[列出工程師需要知道的約束]
+**依賴項目**：[第三方服務、API、其他功能的前置條件]
+**效能要求**：[載入時間、併發量等，若有]
+**安全性要求**：[資料保護、權限等，若有]
+
+---
+
+## 7. 風險與假設（來自 Pre-mortem）
+
+| 風險 | 可能性 | 影響 | 預防措施 |
+|------|--------|------|---------|
+| | 高/中/低 | 高/中/低 | |
+
+**核心假設**：[需要驗證的假設，若不成立則需重新評估方向]
+
+---
+
+## 8. 里程碑與時程
+
+| 里程碑 | 目標日期 | 包含內容 |
+|--------|---------|---------|
+| Alpha | | [最小可測試版本] |
+| Beta | | [有限用戶測試] |
+| Launch | | [正式上線] |
+
+---
+
+## 9. 開放問題（Open Questions）
+
+| 問題 | 負責人 | 預計解答日期 |
+|------|--------|------------|
+| | | |
+```
+
+---
+
+## 🗂️ 開發文件產出（按需觸發）
+
+### 流程圖（Mermaid 語法）
+
+當使用者說「產出流程圖」時，根據 User Story 和功能規格，產出 Mermaid flowchart：
+
+```mermaid
+flowchart TD
+    A[使用者進入] --> B{已登入？}
+    B -- 是 --> C[顯示主畫面]
+    B -- 否 --> D[跳轉登入頁]
+    C --> E[完成核心動作]
+    E --> F[到達 Aha Moment]
+```
+
+產出時涵蓋：主要使用流程 / 關鍵分支判斷 / 錯誤情境
+
+### DB Schema（Mermaid ERD 語法）
+
+當使用者說「產出 DB schema」時，根據 MVP 功能範圍，產出 Mermaid erDiagram：
+
+```mermaid
+erDiagram
+    USER {
+        int id PK
+        string name
+        string email
+        datetime created_at
+    }
+    PRODUCT {
+        int id PK
+        string name
+        int owner_id FK
+    }
+    USER ||--o{ PRODUCT : "owns"
+```
+
+產出時說明：主要實體 / 關聯關係 / 關鍵欄位（FK、索引建議）
+
+### UI Wireframe（HTML 線框圖）
+
+當使用者說「產出 UI wireframe」時，以 HTML + 內聯 CSS 產出低保真線框圖，涵蓋：
+- 核心頁面（根據 User Story 判斷需要幾個頁面）
+- 使用灰階配色，不用品牌色
+- 標注每個元素的功能說明
+- 標注 Aha Moment 發生的位置
+
+---
+
+## 📎 本階段的檔案整合提示
+
+| 上傳內容 | 整合到 | 整合動作 |
+|---------|-------|---------|
+| 既有 PRD / 需求文件 | 3.7 MVP | 提取既有功能清單，作為 MVP 邊界判斷的參考 |
+| 技術架構文件 | 3.5 RICE（Effort） | 用真實技術複雜度評估 Effort 分數 |
+| 設計稿截圖 / Wireframe | 3.2 平行原型 + UI Wireframe | 作為解法的視覺參考；識別已有設計和需新設計的部分 |
+| 工程師估時文件 | 3.5 RICE + 3.7 MVP | 用真實估時替代假設性 Effort；調整 MVP 範圍 |
+| 過去版本的 Postmortem | 3.3 Pre-mortem | 從歷史失敗經驗中補充風險清單 |