| name | prd-writing |
| description | 编写完整的 Product Requirements Document（PRD）时使用。适用于完整功能模块需求定义、需求评审材料、给下游工作流的交付包。优先输出可开发、可测试、可验收的 14 节标准 PRD。 |
PRD 编写
适用场景
- 完整功能模块的需求定义
- 需求评审准备
- 给项目经理/UI/API/开发交付的需求包
- 已有需求的补全和规范化
不适用场景
核心原则
- 先定义问题，再定义功能
- 可测试 > 详尽：每个功能必须有可验证的验收标准
- 明确非目标范围：防止需求膨胀
- 不规定技术方案：技术选择交给技术工作流
PRD 14 节标准结构
1. 背景和目标
- 为什么做这个？业务目标是什么？
- 不做会怎样？
2. 用户和场景
- 目标用户画像
- 使用场景（什么时候、在哪里、用什么设备）
- 用户当前的工作流和痛点
3. 问题定义
- 用户遇到什么问题？
- 问题造成什么损失？
- 现有解决方案为什么不够？
4. 目标和非目标
- 这次要解决什么（Goals）
- 这次不解决什么（Non-Goals）
- 后续版本可能做什么
5. MVP 范围
- 必须有（Must）：没有不能成立
- 应该有（Should）：影响体验但可后置
- 可以有（Could）：锦上添花
- 暂不做（Won't）：明确排除
6. 功能需求
- 功能清单（按优先级）
- 每个功能的具体描述
7. 用户故事
- 作为 [角色]，我希望 [动作]，以便 [价值]
- 每条故事用 INVEST 检查（见 [user-story](../user-story/SKILL.md)）
8. 业务规则
- 状态流转
- 计算逻辑
- 业务约束
9. 权限和角色
- 谁能做什么
- 字段级权限（如有）
- 租户/组织隔离（如有）
10. 异常场景
- 输入校验失败
- 权限不足
- 资源不存在
- 并发冲突
- 网络异常
- 空状态
11. 验收标准
- Given [前置条件] When [用户行为] Then [系统结果]
- 每个核心功能至少 1 条
- 主路径 + 异常路径
12. 指标和埋点建议
- 成功指标（参考 [heart-metrics](../heart-metrics/SKILL.md)）
- 埋点事件名 + 属性
- 复盘时间点
13. 风险和依赖
- 技术风险 / 业务风险 / 合规风险
- 外部依赖（第三方 API、审批、合作方）
- 内部依赖（其他工作流的产出）
14. 未决问题
- 需要进一步确认的点
- 不同方案的取舍
- 等待外部输入的事项
工作流程
1. 检查输入是否充足（用户/问题/价值/期望产物）
↓
2. 不充足则补问（不要硬写 PRD）
↓
3. 按 14 节结构逐节填充
↓
4. 每个功能点写用户故事 + 验收标准
↓
5. 检查异常场景是否覆盖
↓
6. 检查指标是否定义
↓
7. 检查未决问题是否标注
↓
8. 输出完整 PRD
↓
9. 转交下游工作流（按工作流主控的交接协议）
质量自检
□ 14 节是否都填了（不必每节很长，但不能空）
□ 目标用户和场景是否具体（不能只写"用户"）
□ 每个核心功能是否有 Given/When/Then 验收标准
□ 异常场景是否覆盖（权限/空/错/冲突）
□ 非目标范围是否写清楚
□ 是否定义了成功指标
□ 是否标注了未决问题
□ 是否避免规定技术方案
常见坑
- 节是齐的，内容是空的——每节都写一句话凑数，等于没写
- 目标和非目标混在一起——必须明确分开
- 业务规则用文字描述状态流转——状态多时用 Mermaid stateDiagram
- 验收标准只覆盖成功路径——异常路径也要有验收标准
- 指标定义模糊："提升用户体验" → 改成"7 日留存从 X% 到 Y%"
- 未决问题清单是空的——真实项目不可能没有未决问题
配套模板
templates/prd-template.md — 完整 14 节模板templates/requirement-brief-template.md — 简化版（适合 M 级任务）templates/requirement-review-template.md — 需求评审记录模板
与其他 skill 的协作
上游：
opportunity-tree → 提供机会和方案候选
positioning → 提供产品定位
pr-faq → 提供愿景
平行：
user-story → 拆解功能为用户故事（PRD 第 7 节）
mvp-scoping → 划分 MVP 范围（PRD 第 5 节）
heart-metrics → 定义指标（PRD 第 12 节）
下游：
整个 PRD 转交项目经理 / UI/UX / API / 开发工作流
