product-playbook 1.0.0

package/i18n/zh-CN/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-CN/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-CN/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-CN/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-CN/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 | 从历史失败经验中补充风险清单 |