产品需求文档

prd

分类通用

作者Alireza Rezvani

许可MIT

评分4.40/5

使用8.3K

/prd

为 $ARGUMENTS 生成一份简洁且经过证据验证的产品需求文档 (PRD)。

用法

bash

/prd <feature-or-problem>

$ARGUMENTS 是功能、计划或问题陈述。如果为空，在执行任何操作前请先询问。

第一阶段 —— 强制提问（起草前）

逐一进行提问，不要批量提问。每个答案将对应 PRD 的必要章节。

1. 问题 (Problem) —— 这解决了用户的什么问题？你如何证明该问题存在？（证据：支持工单、访谈原话、漏斗数据 —— “CEO 想要”不算证据。）
2. 用户 (User) —— 具体是谁遇到了这个问题？（细分群体、角色、痛点频率。“所有人”不是有效答案。）
3. 指标 (Metric) —— 如果方案奏效，哪个单一数值会发生变化？变化多少？在何处衡量？
4. 替代方案 (Alternatives) —— 用户目前如何应对？为什么现有方式不够好？
5. 非目标 (Non-goals) —— 哪些相关需求被明确排除在 v1 版本之外？

起草门控（硬性拒绝）

如果问题 1（问题）、2（用户）或 3（指标）的答案未知、循环论证或为“以后再决定”，则拒绝起草 PRD。 相反，请输出待解决的问题以及获取答案的最廉价方式（例如：5 场客户访谈、一次漏斗查询、一次伪门测试）。没有问题、用户和指标的 PRD 只是一个功能愿望，而非需求文档。

第二阶段 —— 起草（必要章节清单）

每份 PRD 必须包含以下所有章节 —— 在末尾输出清单并勾选：

[ ] 问题陈述（包含 Q1 的证据）

[ ] 目标用户与细分群体（来自 Q2）

[ ] 目标与明确的非目标（来自 Q5）

[ ] 用户故事及验收标准 (Acceptance Criteria)

[ ] 成功指标 + 阈值 + 衡量来源（来自 Q3）

[ ] 考虑过的替代方案 / “不做任何处理”的基准线（来自 Q4）

[ ] 范围、依赖项及时间线假设

[ ] 开放性问题与风险

篇幅控制在 2 页左右。使用仓库模板作为骨架。

第三阶段 —— 优先级挂钩（可选）

如果用户有多个候选功能，在确定 PRD 之前，提议使用 RICE 评分法进行排序：