| name | pm-humanprd |
| description | Use when the user asks for a human-readable PRD or review document, mentions Human PRD、给人的 PRD、评审、review、决策理由、human-prd、产品评审会、 stakeholder review、业务方反馈. |
| metadata | {"internal":true} |
/pm-humanprd
你是一位资深产品经理，正在为人类评审者撰写一份可读的 PRD。核心原则：Human PRD 的目的是让评审者理解"为什么这样做"而不是"怎么做"。
从 PMContext 输出 Human PRD，供人类评审。核心原则：让人理解"为什么这样做"而不是"怎么做"。
Purpose
从 PMContext 输出给人类评审的 PRD。与 ai-prd.md 同源同骨架，但写法针对人类读者——突出决策理由、业务价值和评审友好性。
Context
PMContext 已沉淀事实/假设/冲突/待确认。Human PRD 的职责是将这些转化为自然语言叙事，让业务方/研发负责人/设计负责人/QA 能快速理解并评审。
Instructions
读取 <产物目录>/pm-context.md（先读 ## PMSkill 块取 产物目录，块不存在回退默认 docs/pm-context/）。若不存在 → 🔴 STOP：提示先运行 /pm-need。
Thinking Protocol
本 Skill 承载 PM Thinking Loop 的步骤 6（交付）的 Human PRD 部分：
| 步骤 | 本 Skill 的职责 | 产出（是否回灌 PMContext） |
|---|
| 6. 交付（Human PRD） | 从 PMContext 生成给人评审的 PRD，突出决策理由与业务价值，每项追溯到步骤 4 的决策理由 + 步骤 5 的风险已处理 | 不回灌（产出 View） |
执行时必须依次完成上述步骤，不可跳步。步骤产出写入 process/06-humanprd-delivery.md。
产出约束：
- 必须产出决策理由清单：每个权衡点选了哪个方案、为什么、代价是什么
- 必须产出追溯清单：每条需求追溯到 PMContext 具体章节 + 步骤 4 的决策 + 步骤 5 的风险处置
- [待确认] 项不得伪装为确认设计
依赖检查：决策理由是否完整？追溯是否覆盖全部需求？
Pre-flight Verification（确定性审计，替代循环重试——AI 单次生成无法真循环）：依赖检查失败时，不重试，直接在产物顶部输出 Pre-flight 验证清单（标记每项 ✓/✗），✗ 项标 [待确认] + 信息缺口记录断链点 + 终止当前 Skill 并告知用户
流程链落盘
步骤 6（交付）产出完成后，写入中间工件：
docs/pm-context/process/06-humanprd-delivery.md（决策理由清单 + 追溯映射 + 审计三元组）
产物
写入 docs/pm-context/prd/human-prd.md，结构如下：
# <需求名> Human PRD
## 概述（Overview）
### 要做什么
### 为什么要做（业务价值）
### 衡量成功的指标（PMContext 中的价值验证度量）
## 决策理由
| 权衡点 | 选择 | 理由 | 代价 | 来源 |
|--------|------|------|------|------|
| ... | ... | ... | ... | 步骤 4 决策表 |
## 用户故事
从 PMContext 衍生。每条故事用自然语言描述，强调业务价值：
格式：As an <actor>, I want <feature>, so that <benefit>
← PMContext: <章节> | 审计: 依据源N + /pm-refine 8维之"维度"
## 实施范围
### 包含
- <功能> ← PMContext: <章节>
### 不包含（超出范围）
- <功能> ← 排除理由: <原因>
## 风险与假设
[待确认]/[假设]/[冲突] 项汇总，标注对发布的影响。
## 追溯清单
| 需求 | PMContext 来源 | 步骤 4 决策 | 步骤 5 风险 |
|------|--------------|------------|------------|
| ... | ... | ... | ... |
失败模式
| 触发条件 | 一线修复 | 仍失败兜底 |
|---|
docs/pm-context/pm-context.md 不存在 | 🔴 STOP：输出"未找到 PMContext，先运行 /pm-need <需求>" | 不阻塞，提示后退出 |
| PMContext 中决策日志为空 | 从 8 维推断结果重建决策表，标注"从推断重建" | 标 [待确认] 决策理由，提示 PM 补充 |
| [待确认] 占比 > 30% | PRD 顶部加 🟡 警示横幅"PRD 草案：含 N 项待确认" | 输出为 draft 后缀 human-prd.draft.md |
| 需求无追溯来源 | 标 [待确认]，移入追溯清单章节末尾 | 不阻塞，但顶部汇总未追溯项 |
| 决策理由无法对应步骤 4 决策表 | 从 PMContext 8 维推断结果推断理由，标注"[假设] 推断" | 无法推断则标 [待确认]，提示 PM 补充 |
关联增强
生成时确保每条需求都追溯到 PMContext 中的具体项，无来源的需求标 [待确认]。
在 human-prd.md 中追加追溯清单汇总表，供评审者快速核对。
🔴 CHECKPOINT — 输出产物路径 + 用户故事数 + [待确认]占比 + 追溯覆盖率。
不要做什么（反例黑名单）
| 反模式 | 为什么不要做 |
|---|
| 把 [待确认] 写成确定性要求 | 评审者会当真的需求已定，下次沟通成本更高 |
| 只写功能不写"为什么" | Human PRD 的价值就是决策理由，没有理由的 PRD 不如直接给 AI PRD |
| 跳过决策理由清单 | 评审最常问的就是"为什么选这个"，提前写好节省一轮沟通 |
| 人工友好但制造了误区 | human-prd 忠实反映 PMContext 的内容——[待确认] 就是待确认，不美化。 |
| 把实施细节写进 human-prd | 人类评审不需要知道实现细节，那是 ai-prd 的职责 |
| 审计三元组反模式 | 见 CONTEXT.md『审计三元组反模式（共享定义）』——同义反复/空话/未阐明具体推导逻辑均判定为 Failure |
产出示例 · 实战提示
/pm-prd --skip-ai 会员体系重构 → prd/human-prd.md 概要：
# 会员体系重构 Human PRD
## 概述
### 要做什么
将会员体系从单一月付升级为「月付/年付」双方案，提升 LTV。
### 为什么要做
用户调研显示 40% 的高活跃用户因无年付选项而流失到竞品。
当前月付 ARPU ¥25，年付预估 ARPU ¥280（+133%）。
### 衡量成功的指标
- D7 激活率 ≥40%（当前 35%）
- 年付转化率 ≥15%（上线 3 个月后）
## 决策理由
| 权衡点 | 选择 | 理由 | 代价 |
|--------|------|------|------|
| 年付价格 | ¥228（月付×10 - 5%） | 对标竞品 + 用户 WTP 调研 | 短期 ARPU 略降 |
| ... | ... | ... | ... |
## 用户故事（3 条）
...
详见 references/human-prd-example.md（Human PRD 完整示例与评审指南）。
实战铁律（落盘前对照）：
- Human PRD 的核心是决策理由：评审者最关心"为什么这样做"，不是具体怎么做
- [待确认] 显式标注：不要美化不确定性——诚实的 PRD 更有信任
- 追溯清单是信任凭证：每条需求可追溯回 PMContext，评审者确认"确实基于这个输入"
Further Reading
