# Prd Writing

> 编写完整的 Product Requirements Document（PRD）时使用。适用于完整功能模块需求定义、需求评审材料、给下游工作流的交付包。优先输出可开发、可测试、可验收的 14 节标准 PRD。

- Skill: `zhaoxuya520/prd-writing` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add zhaoxuya520/prd-writing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaoxuya520/prd-writing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: zhaoxuya520 (https://skillmd.com/u/zhaoxuya520)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhaoxuya520/prd-writing

---


# PRD 编写

## 适用场景

- 完整功能模块的需求定义
- 需求评审准备
- 给项目经理/UI/API/开发交付的需求包
- 已有需求的补全和规范化

## 不适用场景

- 高不确定需求（应先用 [opportunity-tree](../opportunity-tree/SKILL.md) 探索）
- 单个功能点的小修小补（应直接用 [user-story](../user-story/SKILL.md)）
- 战略级愿景对齐（应先用 [pr-faq](../pr-faq/SKILL.md)）

## 核心原则

1. **先定义问题，再定义功能**
2. **可测试 > 详尽**：每个功能必须有可验证的验收标准
3. **明确非目标范围**：防止需求膨胀
4. **不规定技术方案**：技术选择交给技术工作流

## PRD 14 节标准结构

```text
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. 未决问题
    - 需要进一步确认的点
    - 不同方案的取舍
    - 等待外部输入的事项
```

## 工作流程

```text
1. 检查输入是否充足（用户/问题/价值/期望产物）
   ↓
2. 不充足则补问（不要硬写 PRD）
   ↓
3. 按 14 节结构逐节填充
   ↓
4. 每个功能点写用户故事 + 验收标准
   ↓
5. 检查异常场景是否覆盖
   ↓
6. 检查指标是否定义
   ↓
7. 检查未决问题是否标注
   ↓
8. 输出完整 PRD
   ↓
9. 转交下游工作流（按工作流主控的交接协议）
```

## 质量自检

```text
□ 14 节是否都填了（不必每节很长，但不能空）
□ 目标用户和场景是否具体（不能只写"用户"）
□ 每个核心功能是否有 Given/When/Then 验收标准
□ 异常场景是否覆盖（权限/空/错/冲突）
□ 非目标范围是否写清楚
□ 是否定义了成功指标
□ 是否标注了未决问题
□ 是否避免规定技术方案
```

## 常见坑

1. **节是齐的，内容是空的**——每节都写一句话凑数，等于没写
2. **目标和非目标混在一起**——必须明确分开
3. **业务规则用文字描述状态流转**——状态多时用 Mermaid stateDiagram
4. **验收标准只覆盖成功路径**——异常路径也要有验收标准
5. **指标定义模糊**："提升用户体验" → 改成"7 日留存从 X% 到 Y%"
6. **未决问题清单是空的**——真实项目不可能没有未决问题

## 配套模板

- `templates/prd-template.md` — 完整 14 节模板
- `templates/requirement-brief-template.md` — 简化版（适合 M 级任务）
- `templates/requirement-review-template.md` — 需求评审记录模板

## 与其他 skill 的协作

```text
上游：
  opportunity-tree → 提供机会和方案候选
  positioning → 提供产品定位
  pr-faq → 提供愿景

平行：
  user-story → 拆解功能为用户故事（PRD 第 7 节）
  mvp-scoping → 划分 MVP 范围（PRD 第 5 节）
  heart-metrics → 定义指标（PRD 第 12 节）

下游：
  整个 PRD 转交项目经理 / UI/UX / API / 开发工作流
```