---
name: write-mrd
description: 输入一个产品 idea（一句话或详细描述均可），自动生成图文并茂、结构完整的 MRD（市场需求文档），以 Markdown 格式保存到当前项目 markdown/ 目录，同时输出配套 SVG 图表文件。触发条件：用户提到"写 MRD"、"帮我写市场需求文档"、"生成 MRD"、"写产品市场需求"、"我有个产品想法"、"帮我把这个 idea 写成 MRD"、"市场需求文档模板"、"产品立项文档"、"帮我写需求文档"。即使用户只给出一句简短的产品描述如"我想做一个 XX 产品"，也应立即使用本 skill 生成 MRD。本 skill 面向产品经理、创业者、产品负责人，输出可直接用于团队评审和立项决策的专业文档。
---

# Write MRD Skill

将一个产品 idea 转化为结构严谨、图文并茂的 MRD（市场需求文档）。

---

## 工作流总览

```
用户输入 idea
      ↓
Step 1: 解析 idea，提炼核心问题与目标用户
      ↓
Step 2: 搜索行业背景 & 竞品信息（web search）
      ↓
Step 3: 构建 MRD 各章节内容
      ↓
Step 4: 生成 SVG 图表文件（至少 2 个）
      ↓
Step 5: 输出 Markdown 文件到 markdown/ 目录
```

---

## Step 1：解析 Idea

拿到用户输入后，在开始写作之前先做内部推理：

1. **核心问题识别**：这个产品要解决什么问题？谁有这个问题？
2. **目标用户推断**：根据 idea 描述，猜测目标用户群体（如有多个层次，区分 Primary/Secondary）
3. **市场方向判断**：to B / to C / to B2B2C？消费品还是工具类？
4. **阶段判断**：是 0→1 的新产品，还是已有产品的新功能？

如果 idea 过于模糊（少于 10 个字且无任何上下文），可以向用户追问一个关键问题：**"这个产品主要服务谁，解决他们在什么场景下的什么问题？"**；但如果能合理推断，应该直接开始写，在文档中标注推断假设。

---

## Step 2：背景调研（使用 Web Search）

在写作之前，必须使用 web search 搜索以下信息：

- **市场规模数据**：搜索 `[行业关键词] market size 2024 2025` 或中文 `[行业] 市场规模`
- **竞品信息**：搜索主要竞品的产品定位、用户评价、融资情况
- **行业趋势**：搜索最新的行业报告、政策变化、技术趋势
- **用户痛点**：搜索相关论坛、App Store 评论、社交媒体上的用户抱怨

> 如无网络条件，基于已知知识推理，但需在文档中明确标注"数据待验证"。

---

## Step 3：MRD 文档结构规范

### 3.1 文档头部（必填）

```markdown
# [产品名称] MRD

> [一句话核心洞察：为谁解决什么问题，产生什么价值]

| 属性 | 内容 |
|------|------|
| 文档版本 | v1.0 |
| 创建日期 | [当前日期] |
| 产品阶段 | 0→1 新产品 / 功能迭代 / 战略探索 |
| 目标市场 | [简短描述] |
| 文档状态 | 草稿 / 评审中 / 已批准 |
```

### 3.2 执行摘要（Executive Summary）

**格式要求**：不超过 200 字，必须包含：
- **核心问题**（1句话）：[目标用户] 在 [场景] 下面临 [痛点]
- **我们的解法**（1句话）：通过 [核心能力] 帮助 [目标用户] 实现 [结果]
- **市场机会**（量化）：目标市场规模 + 当前渗透率 + 增长趋势
- **成功标准**（3个指标）：上线 X 个月内达成 [指标1/指标2/指标3]

### 3.3 背景与战略对齐

必须回答以下问题：
- **为什么现在做？**（时机判断：市场拐点、技术成熟度、竞争窗口）
- **为什么我们做？**（差异化优势：我们有什么独特的资源/能力/数据）
- **不做的代价是什么？**（机会成本分析）
- **与公司/团队战略的对齐点**（对于独立创业者可忽略此项）

### 3.4 用户与市场分析（核心章节）

#### 3.4.1 目标用户画像（使用 JTBD 框架）

每个主要用户角色必须包含：

```
用户角色卡
─────────────────────────────────────────
角色名称：[给用户一个有画面感的昵称]
人口特征：年龄 / 职业 / 收入段 / 地域
使用场景：[具体的时间、地点、触发事件]

JTBD 三层任务：
  功能性任务：[他们实际要完成什么行动]
  情感性任务：[他们希望在过程中感受到什么]
  社会性任务：[他们希望在他人眼中呈现什么]

期望结果（验收标准来源）：
  - [可量化的成功标准 1]
  - [可量化的成功标准 2]

现有替代方案的缺陷：
  - [当前他们怎么解决这个问题]
  - [这个方案哪里让他们失望]
─────────────────────────────────────────
```

#### 3.4.2 市场规模

必须包含 TAM / SAM / SOM 三层拆解，每层给出数字来源或推导过程。

**TAM（理论最大市场）**：所有可能有此需求的用户 × 人均年付费意愿  
**SAM（可服务市场）**：我们能实际触达并服务的子集  
**SOM（可获取市场）**：未来 12-18 个月实际能拿到的份额

**呈现方式**：使用 ASCII 或 Mermaid 图表可视化三层关系。

#### 3.4.3 竞品分析

**必须包含**：
- 竞品对比矩阵（Markdown 表格）
- 竞品定位地图（使用 SVG 或 ASCII 二维坐标图）
- 每个竞品的"失败边界"（他们在哪个场景下让用户失望）
- 我们的差异化定位（1句话：我们是"为[目标用户]服务的[类别]，区别于竞品的是[差异化]"）

**竞品对比维度**：根据产品类型选择 5-7 个最关键的维度，避免"大而全"的无意义对比。

### 3.5 核心需求（功能需求章节）

#### 3.5.1 需求场景（User Stories）

格式：`作为 [用户角色]，我希望 [完成某个行动]，以便 [实现某个结果]`

**每个 User Story 必须包含**：
- 验收标准（AC）：2-4 条具体可测试的标准
- RICE 评分：Reach × Impact × Confidence / Effort
- MoSCoW 分类：Must Have / Should Have / Could Have / Won't Have

#### 3.5.2 非功能需求

必须覆盖以下维度（根据产品类型选择相关项）：

```
性能需求：页面加载 < X 秒 / 接口响应 < X ms / 并发支持 X 用户
可用性：SLA X% 可用性 / 故障恢复时间 < X 分钟
安全与合规：数据加密标准 / 用户隐私合规（GDPR/个人信息保护法）
扩展性：支持 X 倍用户增长无需重构
国际化：支持语言 / 时区 / 货币
无障碍：WCAG 合规等级
```

#### 3.5.3 优先级矩阵（使用 MoSCoW）

**必须**明确列出 "Won't Have (This Version)" 的内容——这是 MRD 最容易被忽视但最有价值的部分。

### 3.6 约束与里程碑

```
技术约束：
- 必须使用 / 禁止使用的技术栈（如有）
- 必须集成的第三方服务
- 数据迁移 / 兼容性要求

资源约束：
- 团队规模与角色
- 预算范围（可用区间或相对描述）
- 时间硬限制

里程碑规划：
│ 里程碑  │ 目标              │ 时间    │ 关键指标  │
│ MVP     │ 验证核心假设      │ +8周    │ [指标]   │
│ V1.0    │ 满足主流用户场景  │ +16周   │ [指标]   │
│ V1.5    │ 扩大用户规模      │ +24周   │ [指标]   │
```

### 3.7 核心假设清单（重要）

**每个假设必须包含**：假设内容、验证方式、风险等级（高/中/低）、验证截止时间。

至少包含以下类型的假设：
- 用户行为假设（使用频率、付费意愿、渠道偏好）
- 市场假设（竞争格局稳定性、市场增长速度）
- 技术假设（实现可行性、第三方 API 可靠性）
- 商业假设（变现路径、单位经济模型）

### 3.8 成功指标与监控

定义三个层次的指标：

**北极星指标（1个）**：最能代表产品核心价值的单一指标，例如"每用户每周完成的[核心任务]次数"

**驱动指标（3-5个）**：支撑北极星指标的先行指标

**护栏指标（2-3个）**：确保在优化北极星指标时不损害的底线指标（如用户留存、NPS、崩溃率）

### 3.9 附录

- 用研摘要（访谈对象、核心发现）
- 关键数据分析（漏斗数据、竞品数据来源）
- 待决事项（Open Questions）清单
- 名词解释（Glossary）

---

## Step 4：SVG 图表生成规范

每份 MRD **必须包含至少 2 个 SVG 图表**，优先生成以下类型：

### 4.1 必选图表

**图表 A：竞品定位地图（二维坐标）**
- X轴：根据产品特点选择最关键的差异化维度（如"价格：低→高"）
- Y轴：另一个关键维度（如"功能复杂度：简单→专业"）
- 在坐标系上标注各竞品位置和我们的目标位置
- 文件命名：`[product]-competitive-map.svg`

**图表 B：用户旅程 / 核心流程图**
- 展示用户完成核心任务的步骤
- 标注每个步骤的情感曲线（开心/中性/痛点）
- 标注我们的产品介入点
- 文件命名：`[product]-user-journey.svg`

### 4.2 可选图表（根据产品类型选择）

- TAM/SAM/SOM 同心圆图（to C 产品必选）
- 功能优先级矩阵（Impact vs Effort 四象限）
- 商业模式画布简化版
- 系统架构概念图（to B 产品建议包含）

### 4.3 SVG 制作规范

```
尺寸：viewBox="0 0 800 500"（宽图）或 "0 0 600 600"（方图）
字体：font-family="'PingFang SC','Helvetica Neue',Arial,sans-serif"
配色方案：
  主色调：#4F46E5（靛蓝）
  辅色1：#16A34A（绿）
  辅色2：#EA580C（橙）
  辅色3：#BE185D（粉红）
  背景：#F8FAFC 或深色 #0F172A
  文字：#111827（深）/ #6B7280（次）/ white（反色）
```

每个 SVG 文件保存到 `markdown/` 目录，在 Markdown 中用 `![描述](filename.svg)` 引用。

---

## Step 5：输出文件规范

### 目录结构

```
markdown/
├── [product-name]-mrd.md          ← 主 MRD 文档
├── [product-name]-competitive-map.svg    ← 竞品定位图
├── [product-name]-user-journey.svg       ← 用户旅程图
└── [product-name]-[其他图表].svg         ← 其他图表（如有）
```

### 文件命名

- 主文档：`[product-name]-mrd.md`，全小写，连字符分隔
- SVG：`[product-name]-[chart-type].svg`

### 文档质量自检清单

在输出前对照检查：

- [ ] 执行摘要是否在 200 字内，包含问题/解法/机会/成功标准？
- [ ] 用户画像是否包含 JTBD 三层任务分析？
- [ ] 市场规模是否给出 TAM/SAM/SOM 三层且有数字？
- [ ] 竞品分析是否包含"失败边界"而非只有功能对比？
- [ ] 每个 User Story 是否有 AC 验收标准？
- [ ] 是否明确列出"Won't Have"的内容？
- [ ] 核心假设清单是否包含用户/市场/技术/商业四类假设？
- [ ] 是否包含至少 2 个 SVG 图表且正确引用？
- [ ] 成功指标是否包含北极星指标/驱动指标/护栏指标三层？
- [ ] 文件是否已存储到 `markdown/` 目录？

---

## 写作风格规范

**语言**：
- 简洁直接，避免空话（"用户体验友好"不是需求，"操作步骤不超过 3 步"才是）
- 量化优先：凡是能量化的地方都给出数字
- 假设透明：凡是推断而非确认的数据，标注"待验证"

**结构**：
- 每个章节开头用 1-2 句话说明"这一章回答什么问题"
- 使用表格组织对比信息，使用代码块组织模板内容
- 图表优先于文字描述（能用图说清楚的不用段落）

**常见错误清单（避免）**：
- ❌ 把解决方案写成问题陈述
- ❌ 用户画像只有人口属性，没有行为和任务
- ❌ 竞品分析只列功能，不分析定位和失败边界
- ❌ 需求列表没有优先级，或所有需求都是 P0
- ❌ 没有"Won't Have"章节
- ❌ 假设隐藏在正文中，没有显式列出
- ❌ 成功指标只有一个层次

---

## 触发示例

以下都应触发本 Skill：

- "帮我写个 MRD，我想做一个 AI 驱动的个人财务管理 App"
- "我有个想法：给独立开发者做一个客服自动化工具，帮我生成 MRD"
- "产品想法：B2B SaaS，帮中小企业做供应链协同，需要 MRD"
- "写 MRD：一个帮助远程团队做异步视频沟通的产品"
- "我想做一个结合 AI 的健身计划生成器，帮我写市场需求文档"