/write-prd

/write-prd -- 产品需求文档

创建结构清晰的 PRD（产品需求文档），对齐干系人并指导开发。接受从模糊想法到详细简报的任意形式输入。

Invocation（调用示例）

/write-prd 面向企业客户的 SSO 支持
/write-prd 用户在用户引导第 3 步流失——我们需要解决这个问题
/write-prd [上传简报、调研文档或战略文件]

Workflow（工作流程）

Step 1：理解功能

接受以下任意形式的输入：

• 功能名称（"SSO 支持"）
• 问题陈述（"企业客户一直要求集中式身份认证"）
• 用户诉求（"用户希望将数据导出为 CSV"）
• 模糊想法（"我们应该对用户引导流失做些什么"）
• 上传的文档（简报、调研报告、Slack 讨论串、邮件）

Step 2：收集背景信息

以对话方式询问——优先问最重要的问题，边聊边补充细节：

1. 用户痛点：这解决了什么问题？谁在经历这个问题？痛苦程度如何？
2. 目标用户：哪些用户群体？规模多大？他们现在的替代方案是什么？
3. 成功指标：如何判断是否成功？搞定这个会带动哪些指标变化？
4. 约束条件：技术约束、时间线、合规要求、对其他团队的依赖？
5. 已有方案：之前尝试过吗？市场上有哪些现有解决方案？
6. 范围偏好：完整方案还是分阶段交付？

如果用户提供了含背景信息的文档，提取可用内容，只问缺失的部分。

Step 3：生成 PRD

应用 create-prd 技能，生成 8 节文档：

## 产品需求文档：[功能名称]

**作者**: [用户]
**日期**: [今天]
**状态**: 草稿
**干系人**: [如已知]

### 1. 执行摘要
[2-3 句话：做什么、为谁做、为什么现在做]

### 2. 背景与上下文
[问题空间、前期调研、市场背景、发起缘由]

### 3. 目标与成功指标
**目标**（成功的样子）：
1. [具体可衡量的目标]
2. [...]

**非目标**（明确不在范围内）：
1. [我们不做什么，以及原因]
2. [...]

**成功指标**：
| 指标 | 当前值 | 目标值 | 衡量方式 |
|------|--------|--------|---------|

### 4. 目标用户与细分市场
[服务对象、用户画像、细分市场规模]

### 5. 用户故事与需求

**P0 — 必须有**：
| # | 用户故事 | 验收标准 |
|---|---------|---------|

**P1 — 应该有**：
| # | 用户故事 | 验收标准 |
|---|---------|---------|

**P2 — 可以有/未来版本**：
| # | 用户故事 | 验收标准 |
|---|---------|---------|

### 6. 解决方案概述
[高层次方案、关键设计决策、技术方案（如已知）]

### 7. 待解问题
| 问题 | 负责人 | 截止日期 |
|------|-------|---------|

### 8. 时间线与分阶段计划
[里程碑、依赖项、分阶段计划（如适用）]

Step 4：评审与迭代

生成后提供：

• "需要我收紧范围吗？我可以挑战哪些 P1 应该降级为 P2。"
• "需要我**对这份 PRD 做事前剖析（Pre-mortem）**吗？"
• "需要我将其拆解为面向工程团队的用户故事吗？"
• "需要我创建干系人更新通知来推广这份 PRD 吗？"

将 PRD 保存为 Markdown 文件到用户工作区。

Notes（注意事项）

• 对范围要有主见——一份范围清晰的 PRD 优于一份包罗万象但模糊的 PRD
• 如果想法太大，主动建议分阶段，只规格化第一阶段
• 非目标和目标同样重要——它们防止范围蔓延
• 成功指标必须具体："改善 NPS"不好，"90 天内将 NPS 从 32 提升至 45"才好
• 待解问题应该是真正未解决的——不要把能从上下文回答的问题也列进去
• 如果用户提供了调研数据，将洞察融入背景章节并注明来源