write-prd

star 8.5k

输入一个产品 idea（一句话或详细描述均可），自动生成图文并茂、结构完整的 PRD（产品需求文档），以 Markdown 格式保存到当前项目 markdown/ 目录，同时输出配套 SVG 图表文件。触发条件：用户提到"写 PRD"、"帮我写需求文档"、"生成 PRD"、"写产品需求文档"、"写商业需求文档"、"我有个产品想法"、"帮我把这个 idea 写成文档"、"PRD 模板"、"产品立项文档"、"产品需求"、"功能需求文档"。即使用户只给出一句简短的产品描述如"我想做一个 XX 产品"，也应立即使用本 skill 生成 PRD。本 skill 面向产品经理、创业者、产品负责人，输出可直接用于团队评审和立项决策的专业文档，深度整合 JTBD 用户洞察框架、MoSCoW 优先级方法论和北极星指标体系。

digoal By digoal schedule Updated 6/9/2026
play_arrow Run Skill in Manus View GitHub

name: write-prd description: 输入一个产品 idea（一句话或详细描述均可），自动生成图文并茂、结构完整的 PRD（产品需求文档），以 Markdown 格式保存到当前项目 markdown/ 目录，同时输出配套 SVG 图表文件。触发条件：用户提到"写 PRD"、"帮我写需求文档"、"生成 PRD"、"写产品需求文档"、"写商业需求文档"、"我有个产品想法"、"帮我把这个 idea 写成文档"、"PRD 模板"、"产品立项文档"、"产品需求"、"功能需求文档"。即使用户只给出一句简短的产品描述如"我想做一个 XX 产品"，也应立即使用本 skill 生成 PRD。本 skill 面向产品经理、创业者、产品负责人，输出可直接用于团队评审和立项决策的专业文档，深度整合 JTBD 用户洞察框架、MoSCoW 优先级方法论和北极星指标体系。

Write PRD Skill

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

核心理念：PRD 是团队在不确定性中的共同契约。它的价值不在于格式，而在于把 WHY → WHAT → HOW → MEASURE 四个维度讲清楚。

工作流总览

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

Step 1：信息补全与 JTBD 推演

拿到用户的 idea 后，不要立刻问问题，先做推演：

1.1 JTBD 框架推断用户痛点

用以下格式在内部推断，不要直接展示给用户：

当 [目标用户] 在 [特定场景] 时， 他们需要 [完成某项工作/达到某个目标]， 但目前面临 [具体障碍]， 导致 [可量化的业务/体验影响]。

1.2 五维推断清单

  1. 目标用户：谁会用这个产品？主用户 vs. 次要用户区分
  2. 核心痛点：用 JTBD 格式描述，不是"用户想要功能"，而是"用户想完成什么任务"
  3. 商业模式：产品如何盈利？服务于什么更大的商业目标？
  4. 差异化：和竞品相比，核心的差异化价值主张是什么？
  5. 成功指标：什么数字能证明这个产品成功了？（北极星指标）

1.3 推断优先于询问

  • 如果信息足够推断，直接进入 Step 2
  • 在 PRD 中用 [待确认] 标注推断字段
  • 如需询问，一次性问不超过 3 个最关键的问题后再执行

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

搜索以下信息，充实 PRD 背景章节：

  1. 市场规模：[产品领域] market size 2024/2025
  2. 主要竞品：[产品类型] top competitors features comparison
  3. 行业趋势：[用户痛点] trends [当前年份]
  4. 参考案例：[类似产品] success failure case study

搜索后提炼关键数据点，填入 PRD 对应章节。

Step 3：生成 SVG 图表

必须生成以下至少 2 个 SVG 图表，保存到 markdown/ 目录：

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

展示核心功能模块及其层级关系。

  • 文件名：[product-name]-architecture.svg
  • 风格：分层色块 + 箭头，清晰展示模块间关联
  • 必须包含：用户层、功能层、数据层（或类似的三层结构）

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

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

  • 文件名：[product-name]-user-journey.svg
  • 风格：横向流程 + 状态标注 + 情绪曲线（可选）
  • 必须包含：触发点、关键节点、决策分叉、异常处理、成功终态

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

  • 竞品对比矩阵（有明确竞品时）：[product-name]-competitor-matrix.svg
  • 数据流图（技术型/数据型产品）：[product-name]-data-flow.svg
  • 商业模式关键要素（B端/平台类产品）：[product-name]-business-model.svg

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 文件结构

文件命名：[product-name-en]-prd.md（英文小写，连字符分隔）

完整 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 层（问题定义）

  • 是否用 JTBD 格式（当/在/需要/面临/导致）写出用户痛点？
  • 用户痛点是否有具体数字支撑（用研数据 or 市场数据）？
  • 是否明确区分了"用户问题"和"解决方案"（别把功能写成痛点）？
  • 市场机会是否覆盖 TAM/SAM/SOM 三层？

WHAT 层（功能规格）

  • Must Have 功能是否严格克制（不超过 5 个核心功能）？
  • 所有 Must Have 是否有 Given/When/Then 验收标准？
  • 验收标准是否包含性能指标（数字，不是"快速"）？
  • 是否写了 Won't Have 并注明原因？
  • MoSCoW 是否有真正的分层（不全是 Must）？

HOW 层（执行计划）

  • 用户旅程图是否覆盖了异常路径（不只是 Happy Path）？
  • 里程碑是否是"可验证交付物"而非"时间点"？
  • 非功能需求是否包含性能、安全、可用性、扩展性？
  • 是否有明确的 Out of Scope？

MEASURE 层（成功指标）

  • 是否定义了唯一的北极星指标？
  • 是否区分了输入指标和护栏指标？
  • 所有指标是否有基线值和目标值（数字）？
  • A/B 测试方案是否包含回滚条件（具体触发数字）？

图表质量

  • 架构图是否展示了三层结构（用户/功能/数据）？
  • 用户旅程图是否有异常路径处理？
  • SVG 是否单独保存为文件并在 Markdown 中正确引用？
  • 每张图是否有标题和简短说明？

整体文档

  • 执行摘要能否让不懂背景的人 1 分钟内理解核心价值？
  • 所有 [待确认] 字段是否在文档中明确标注？
  • 是否有清晰的 RACI 和审批链条？
  • 风险评估是否覆盖技术、市场、资源、合规、假设失效五个维度？

特殊场景处理

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

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

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

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

场景 C：用户要求简版 PRD（1-2页）

只生成以下核心章节：

  • JTBD 问题定义（必须）
  • Must Have 功能 + 验收标准（必须）
  • 北极星指标（必须）
  • 里程碑（必须）
  • 省略：竞品分析、RACI、附录

场景 D：B 端产品 PRD

  • 竞品分析部分增加"购买决策链分析"（谁付钱/谁决策/谁使用）
  • 成功指标加入客户成功指标：NPS / Churn Rate / ARR
  • 用户旅程区分"购买旅程"和"使用旅程"两条线

场景 E：内部工具 PRD

  • 简化市场分析（替换为"内部现状分析"）
  • 增加"效率提升量化"章节（ROI 测算）
  • 指标侧重内部 ROI 和工时节省

场景 F：Agile 团队 PRD

  • 强调"活文档"属性：标注当前 Sprint 范围
  • 功能章节按 Epic → Story 层级组织
  • 里程碑对应 Sprint 而非月份

输出文件清单

生成完成后，markdown/ 目录应包含：

markdown/
├── [product-name]-prd.md              ← 主文档
├── [product-name]-architecture.svg   ← 功能架构图（必选）
├── [product-name]-user-journey.svg   ← 用户旅程图（必选）
└── [product-name]-*.svg              ← 其他可选图表

触发示例

以下均应触发本 Skill：

  • "帮我写一份 PRD，产品是一个帮助设计师管理灵感的 App"
  • "我想做一个企业内部的知识库系统，帮我出一份需求文档"
  • "有个 idea：给餐厅做一个 AI 点餐助手，帮我写成 PRD"
  • "写个 PRD 模板"
  • "产品立项需要一份产品需求文档，我们要做 XX"
  • "帮我把这个产品想法整理成文档，方便跟团队对齐"
  • "我想做个 XX，帮我写 PRD"
  • "用 JTBD 框架帮我写需求文档"
Install via CLI
npx skills add https://github.com/digoal/blog --skill write-prd
Repository Details
star Stars 8,499
call_split Forks 1,915
navigation Branch main
article Path SKILL.md
Occupations
Network And Computer Systems Administrators
More from Creator
digoal
digoal Explore all skills →