将一个产品 idea 转化为完整、可直接评审的 PRD（Product Requirements Document）。

工作流总览

用户输入 Idea
     ↓
Step 1: 信息补全 & JTBD 推演（不急于提问，先推断）
     ↓
Step 2: 搜索市场背景与竞品（web search）
     ↓
Step 3: 生成配套 SVG 图表（独立文件）
     ↓
Step 4: 生成完整 PRD Markdown 文件
     ↓
输出到 markdown/ 目录

Step 1：信息补全与 JTBD 推演

1.1 JTBD 框架推断用户痛点

1.2 五维推断清单

1.3 推断优先于询问

Step 2：搜索市场背景（使用 web_search）

Step 3：生成 SVG 图表

图表 A：产品功能架构图（必选）

图表 B：核心用户旅程图（必选）

展示用户从发现问题到完成目标的完整路径，必须包含异常路径。

图表 C（视产品类型选择其一）：

SVG 技术规范

viewBox="0 0 860 [适当高度]"
font-family="'PingFang SC', 'Helvetica Neue', Arial, sans-serif"
使用 defs 定义 linearGradient 和 filter shadow
配色方案：
  主色：#4f46e5（靛蓝）或 #0f766e（深青）
  成功/正向：#10b981（绿）
  警告/注意：#f59e0b（琥珀）
  错误/风险：#ef4444（红）
  辅助文字：#64748b
  背景：#f8fafc 或 white
每个图表包含：标题行 + 图例（如有）+ 内容 + 底部说明
SVG 必须独立保存为文件，在 Markdown 中用 ![说明](filename.svg) 引用

Step 4：PRD Markdown 文件结构

完整 PRD 模板

# [产品名称] PRD

> [一句话定位：这个产品为谁解决了什么问题，通过什么方式，预期带来什么价值]

**文档类型**：PRD（产品需求文档）
**文档状态**：草稿 / 评审中 / 已批准
**版本**：v1.0
**作者**：[PM 姓名]
**最后更新**：[日期]
**阅读时长**：约 X 分钟

---

## 一、执行摘要（Executive Summary）

[3-5句话的高管版摘要，包含：
- 我们在解决什么问题（问题规模）
- 我们的解决方案是什么（一句话）
- 成功后能带来什么商业价值（量化预期）]

---

## 二、问题定义

### 2.1 背景与现状

[市场背景，数据支撑，不超过200字。来自 Step 2 搜索结果]

### 2.2 用户痛点（JTBD 框架）

**当** [目标用户] **在** [使用场景] **时，**
他们需要 [完成某个任务/达到某个目标]，
但目前面临 [具体障碍]，
导致 [业务/用户体验影响，尽量量化]。

### 2.3 目标用户

**主要用户群体**：[描述]

**用户画像**：
- 人口属性：[年龄 / 职业 / 地域 / 数字化程度]
- 核心使用场景：[什么时候、在哪里、为什么用]
- 当前替代方案：[他们现在怎么解决这个问题]
- 最痛的三个点：[按严重程度排序]

### 2.4 市场机会

| 指标 | 数值 | 来源 |
|------|------|------|
| TAM（总可寻址市场） | | [来源] |
| SAM（可服务市场） | | [来源] |
| SOM（可获取份额） | | 推断 |
| 市场增长率 | | [来源] |

---

## 三、解决方案

### 3.1 产品定位

> 我们是 **[产品类型]**，帮助 **[目标用户]** **[核心价值主张]**，不像 **[竞品]**，我们 **[差异化]**。

### 3.2 功能架构

![功能架构图]([product-name]-architecture.svg)

*[一句话说明图的阅读方式]*

### 3.3 核心功能（MoSCoW 优先级）

> ⚠️ 注意：Must Have 应严格控制，"所有功能都是 Must"意味着 PRD 未完成取舍。

#### ✅ Must Have（MVP 必须包含，缺失则不可上线）

| 功能 | 用户故事 | 验收标准 | 优先级 |
|------|---------|---------|--------|
| [功能1] | As a [用户类型], I want [行为], so that [目的] | Given [前置条件] When [用户操作] Then [系统响应+性能指标] | P0 |

#### 🔶 Should Have（重要但 MVP 可简化版本交付）

| 功能 | 用户故事 | 优先级 |
|------|---------|--------|
| [功能] | As a [用户], I want [行为], so that [目的] | P1 |

#### 🔷 Could Have（有余力再做，不影响核心价值）

- [功能列表，简述即可]

#### ❌ Won't Have（本期明确不做——这行和上面同等重要）

| 功能 | 排除原因 |
|------|---------|
| [功能] | [资源限制 / 复杂度过高 / 非核心路径] |

### 3.4 核心用户旅程

![用户旅程图]([product-name]-user-journey.svg)

*[说明图中的关键决策节点和异常路径处理]*

### 3.5 非功能需求

| 维度 | 要求 | 验证方式 |
|------|------|---------|
| 性能 | [页面加载 ≤ Xms / P95 响应时间 ≤ Xms] | 压测 / 监控 |
| 安全 | [数据加密标准 / 合规要求] | 安全审计 |
| 可用性 | [99.X% Uptime SLA] | 监控告警 |
| 扩展性 | [支持 X 并发用户 / X QPS] | 架构评审 |
| 兼容性 | [支持的平台/浏览器版本] | 兼容性测试 |

---

## 四、竞品分析

[竞品对比，说明差异化优势。如生成了竞品矩阵 SVG，在此引用]

| 维度 | 我们 | 竞品A | 竞品B |
|------|------|-------|-------|
| 核心功能 | | | |
| 目标用户 | | | |
| 定价模式 | | | |
| 差异化 | ✅ | | |

---

## 五、成功指标

### 5.1 北极星指标（North Star Metric）

> **[唯一最重要的指标名称]**：[具体计算口径]
>
> 选择理由：[为什么这个指标能同时反映用户价值和商业价值]

### 5.2 分层指标体系

**输入指标**（你能直接影响的）：

| 指标 | 基线 | 目标值（3个月） | 观测周期 |
|------|------|--------------|---------|
| [核心功能使用率] | | | 周 |
| [核心流程完成率] | | | 周 |
| [用户留存率] | | | 月 |

**护栏指标**（不能因为优化北极星而损害的底线）：

| 指标 | 红线 |
|------|------|
| 错误率 | ≤ X% |
| 投诉率 | 不高于基线 |
| 核心链路可用性 | ≥ 99.X% |

### 5.3 实验设计

- **A/B 测试方案**：[实验组 vs. 对照组的划分逻辑]
- **最小可检测效果（MDE）**：[能检测到多大的指标变化]
- **实验周期**：[X 周，需避开节假日和大促干扰]
- **灰度策略**：5% → 20% → 50% → 100%
- **回滚条件**：[出现什么数据信号（具体数字）立即停止并回滚]

---

## 六、执行计划

### 6.1 范围边界

**In Scope（本期包含）**：
- [功能/能力列表]

**Out of Scope（本期不做——和功能清单同等重要）**：
- [明确排除的功能，及原因：资源/复杂度/战略优先级]

### 6.2 里程碑

> 里程碑 = 可验证的交付物，不是时间点

| 阶段 | 可验证交付物 | 时间节点 | 负责人 |
|------|------------|---------|--------|
| Discovery 完成 | 用研报告通过 + 竞品分析输出 | [日期] | PM |
| 设计评审通过 | 高保真原型 + 核心流程走通 | [日期] | Design |
| 技术方案确认 | 架构评审 + 技术风险识别 | [日期] | Tech Lead |
| MVP 开发完成 | 核心 P0 功能通过 UAT | [日期] | 全团队 |
| 灰度上线 | 5% 用户 + 监控正常 | [日期] | PM + Dev |
| 全量上线 | 指标验证通过 | [日期] | PM |

### 6.3 资源需求

| 角色 | 工作量（人天） | 主要职责 |
|------|-------------|---------|
| 产品经理 | | 需求管理、跨团队协调、指标追踪 |
| 设计师 | | 原型设计、交互规范 |
| 前端工程师 | | |
| 后端工程师 | | |
| 测试工程师 | | 测试方案、UAT |

---

## 七、风险评估

| 风险类型 | 具体风险描述 | 可能性 | 影响程度 | 应对方案 |
|---------|------------|--------|---------|---------|
| 技术风险 | [如：第三方 API 稳定性] | 中 | 高 | [降级方案 + SLA 协议] |
| 市场风险 | [如：竞品抢先上线] | 低 | 高 | [差异化策略] |
| 资源风险 | [如：关键工程师离职] | 低 | 中 | [文档化 + 知识转移] |
| 合规风险 | [如：数据隐私合规] | 低 | 极高 | [法务提前介入] |
| 假设失效风险 | [如：用户访谈结论有偏差] | 中 | 高 | [MVP 快速验证 + 预设回滚] |

---

## 八、干系人与审批

### 8.1 RACI 矩阵

| 事项 | PM | 工程 | 设计 | 运营 | 法务 | 管理层 |
|------|----|----|------|------|------|------|
| 需求确认 | R | C | C | C | I | A |
| 技术方案 | C | R | I | | | I |
| 设计评审 | A | C | R | C | | I |
| 上线决策 | R | C | C | C | C | A |
| 数据验收 | R | C | | C | | I |

*R=负责执行 A=最终拍板 C=需要咨询 I=需要知会*

### 8.2 审批记录

| 干系人 | 角色 | 意见摘要 | 签字日期 |
|--------|------|---------|---------|
| | | | |

---

## 九、附录

### 9.1 关键假设清单

> [待确认] 标记的字段，上线前需确认

| 编号 | 假设内容 | 验证方式 | 状态 |
|------|---------|---------|------|
| A1 | [如：用户愿意为此付费] | 用户访谈 / MVP 验证 | 待确认 |

### 9.2 术语表

| 术语 | 定义 |
|------|------|
| [专有名词] | [定义] |

### 9.3 参考文档

- [ ] 用户研究报告：[链接]
- [ ] 竞品分析报告：[链接]
- [ ] 技术可行性评估：[链接]
- [ ] 数据分析报告：[链接]
- [ ] 法务合规意见：[链接]

### 9.4 修订历史

| 版本 | 日期 | 修改内容 | 修改人 |
|------|------|---------|--------|
| v1.0 | [日期] | 初始版本 | |

写作质量核查清单

WHY 层（问题定义）

WHAT 层（功能规格）

HOW 层（执行计划）

MEASURE 层（成功指标）

图表质量

整体文档

特殊场景处理

场景 A：用户只给了一句话 idea

直接推演所有信息，用 [待确认] 标注推断字段，生成完整文档后告知用户哪些需要补充确认。

场景 B：用户给了详细描述

提取关键信息直接填充模板，搜索市场数据补充背景章节，无需打断流程问问题。

write-prd

Write PRD Skill