PRD标准化生成技能 (PM-PRD Skill)

将结构化的需求规格转化为符合标准化规范的PRD文档。这是产品经理工作流中的PRD生成环节——输入需求规格，输出可直接用于评审和开发的PRD。

核心理念

需求规格是输入，PRD是输出。

需求规格回答"做什么"（由 clarify skill 输出）
PRD回答"怎么做"（由本技能输出）
两者是上下游关系，不是重复劳动

标准化是关键。

每份PRD必须遵循统一的结构和格式
7大章节缺一不可
评审清单必须逐项通过

平台知识库是约束。

PRD中的功能设计必须符合平台现有能力
数据模型必须基于平台现有实体
接口设计必须遵循平台规范
UI设计必须符合平台设计规范（DESIGN-SPEC.md）

触发条件

当用户：

提供了需求规格，要求"生成PRD"
说"帮我写PRD文档"
说"把需求规格转成PRD"
提供了需求文档，要求按标准格式输出

输入

需求规格（由 clarify skill 输出的结构化需求规格）
平台名称（可选，用于加载知识库）
PRD模板（可选，自动选择最合适的模板）

输出

一份符合标准化规范的PRD文档（Product Requirements Document）。

工作流程

Step 0: 准备上下文

第一步：判断项目类型

| 类型 | 特征 | 处理方式 | | ----------- | ------------------------------- | ---------- | | 已有平台迭代 | 用户提到已有平台/产品名称，或上下文中已有平台信息 | 加载知识库，约束设计 | | 0-1 新项目 | "我想做一个 XX"、"帮我设计一个 XX 系统"、无已有平台 | 跳过知识库，通用设计 |

第二步：按类型执行

已有平台迭代 — 知识库加载流程（v3 分层路由）：

知识库位置：~/.miclaw/workspace/skills/platforms/{platform_name}/

按以下顺序加载，每一步只读必要的文件：

Step 0.1: 读 INDEX.md
  → 了解平台有哪些模块（模块列表 + 一句话描述）
  → 文件大小 < 1KB，必须全量读取

Step 0.2: 读 DESIGN-SPEC.md
  → 获取平台设计规范（色彩、字体、组件、交互）
  → PRD 阶段必读，确保 UI 设计符合平台规范
  → 文件大小 3-8KB，必须全量读取

Step 0.3: 根据需求规格中的模块归属，读取对应模块目录
  → 读 modules/{module}/features.md（功能清单）
  → 读 modules/{module}/rules.md（业务规则）
  → 读 modules/{module}/data.md（数据模型）
  → 读 modules/{module}/interfaces.md（接口规范）
  → 读 modules/{module}/ui.md（UI/交互规范）

Step 0.4: 如果涉及多个模块，读 CORE.md（跨模块规则）
  → 了解模块间依赖、通用权限模型、数据权限等

加载原则：

INDEX.md + DESIGN-SPEC.md 是必读的（PRD 阶段）
模块内文件按需求规格中的模块归属读取
CORE.md 只在跨模块需求时读取
不需要读 ROUTER.md（需求规格已经明确了模块归属）

加载后的知识库用于：

约束功能设计（基于 features.md 现有能力）
参考业务规则（基于 rules.md 现有规则）
复用数据模型（基于 data.md 现有实体）
遵循接口规范（基于 interfaces.md 现有接口）
符合 UI 规范（基于 DESIGN-SPEC.md 设计系统）

0-1 新项目：

确认产品定位 — 一句话了解用户想做什么类型的产品
跳过知识库加载 — 没有可加载的内容，不要浪费时间
直接进入 Step 1，使用通用设计规范

第三步：记录上下文标记

在后续流程中始终标记当前模式：

[迭代模式] — 有知识库支撑，设计受约束
[0-1模式] — 无知识库，通用设计

Step 1: 解析需求规格

读取用户提供的需求规格，提取以下信息：

需求概述 — 背景、目标、目标用户
功能范围 — 包含什么、不包含什么
功能描述 — 每个功能的详细说明
数据需求 — 核心数据、统计指标
权限要求 — 查看权限、操作权限
非功能需求 — 性能、兼容性
依赖与风险 — 依赖项、风险点

如果需求规格不完整：

缺少关键信息 → 向用户确认，不要自己编造
有推断项 → 检查是否合理，需要时向用户确认
有未确认项 → 使用默认值，但在PRD中标注

Step 2: 选择PRD模板

根据需求类型选择合适的PRD模板：

| 需求类型 | 推荐模板 | 说明 | | ----- | ------- | --------- | | 新功能开发 | 标准PRD模板 | 完整7章节 | | 功能优化 | 精简PRD模板 | 重点在变更部分 | | 数据相关 | 数据PRD模板 | 强调数据模型和统计 | | 对接集成 | 集成PRD模板 | 强调接口和数据流转 |

Step 3: 生成PRD内容

按照标准化规范生成PRD，确保每个章节都符合要求。

关键约束（迭代模式下）：

功能设计：必须基于平台现有能力，不能凭空设计
数据模型：必须复用平台现有实体，新增字段要说明原因
接口设计：必须遵循平台接口规范
UI设计：必须符合 DESIGN-SPEC.md 中的设计规范：
- 颜色使用平台色板中的颜色
- 字体使用平台规定的字体和字号
- 组件使用平台组件库中的组件
- 交互遵循平台交互规范
- 布局遵循平台栅格系统

Step 4: 评审清单检查

在输出PRD之前，必须按照评审清单逐项检查：

## PRD评审清单

### 需求背景
- [ ] 是否清晰描述了需求产生的背景？
- [ ] 是否说明了当前存在的痛点/优化点？
- [ ] 是否与业务目标对齐？

### 需求目标与收益风险
- [ ] 核心目标是否明确且可衡量？
- [ ] 预期收益是否具体？
- [ ] 风险是否已识别并给出应对措施？

### 名词解释
- [ ] 是否有专业术语需要解释？
- [ ] 名词解释是否准确？

### 需求范围
- [ ] 功能范围是否清晰界定？
- [ ] 是否说明了不包含的内容？
- [ ] 优先级是否明确？

### 流程与状态
- [ ] 核心流程是否完整？
- [ ] 状态流转是否清晰？
- [ ] 异常流程是否考虑？

### 功能描述
- [ ] 每个功能是否都有清晰的描述？
- [ ] 交互设计是否详细？
- [ ] 边界情况是否考虑？
- [ ] 功能是否按页面/模块分组（非平铺）？

### 数据埋点需求
- [ ] 是否需要数据埋点？
- [ ] 埋点方案是否明确？
- [ ] 统计指标是否清晰？

如果检查不通过：

回到 Step 3 补充相关内容
不要输出不完整的PRD

Step 5: 输出PRD

生成最终的PRD文档，包含：

文档头部 — 标题、版本、作者、日期、状态
7大章节 — 按标准化规范组织
评审清单 — 附在文档末尾
变更记录 — 记录本次生成的变更

保存位置：

默认：docs/prd-{需求简称}.md
或用户指定的路径

PRD标准化规范

文档结构

# {产品/功能名称} PRD

> 版本：v1.0
> 作者：{姓名}
> 日期：{YYYY-MM-DD}
> 状态：草稿 / 评审中 / 已确认
> 关联平台：{平台名称}
> 涉及模块：{模块名}

---

## 1. 需求背景

### 1.1 业务背景
{描述业务现状、市场环境、用户痛点}

### 1.2 需求来源
{需求提出方、需求背景}

### 1.3 项目价值
{对业务、用户、技术的价值}

---

## 2. 需求目标与收益风险

### 2.1 核心目标
{主要目标，可量化的指标}

### 2.2 预期收益
{业务收益、用户收益}

### 2.3 风险与应对
| 风险 | 影响 | 应对措施 |
|------|------|----------|
| {风险1} | {影响} | {措施} |

---

## 3. 名词解释

| 名词 | 解释 |
|------|------|
| {名词1} | {解释} |

---

## 4. 需求范围

### 4.1 功能范围

#### 包含
| 功能模块 | 功能点 | 优先级 | 说明 |
|----------|--------|--------|------|
| {模块} | {功能} | P0/P1/P2 | {说明} |

#### 不包含
- {不包含的功能1}
- {不包含的功能2}

### 4.2 用户范围
{目标用户、使用场景}

---

## 5. 流程与状态

### 5.1 核心流程
{主要业务流程，可用流程图描述}

### 5.2 状态流转
{状态变化规则，可用状态图描述}

### 5.3 异常流程
{异常场景处理}

---

## 6. 功能描述

### 6.1 {页面/模块名称 1}

#### 6.1.1 页面概述
{页面用途、入口}

#### 6.1.2 功能点 1：{功能名称}
- **功能描述**：{详细说明}
- **交互设计**：
  - {交互细节1}
  - {交互细节2}
- **业务规则**：
  - {规则1}
  - {规则2}
- **边界情况**：
  - {边界1}
  - {边界2}
- **UI规范**（基于 DESIGN-SPEC.md）：
  - 按钮：{使用 Primary/Secondary 类型，尺寸 {sm/md/lg}}
  - 颜色：{使用平台色板中的 {颜色名}，色值 {hex}}
  - 字体：{使用 {字号名}，{字号值}}
  - 组件：{使用平台组件库中的 {组件名}}

#### 6.1.3 功能点 2：{功能名称}
- **功能描述**：{详细说明}
- **交互设计**：{交互细节}
- **业务规则**：{规则}
- **边界情况**：{边界}
- **UI规范**：{规范}

### 6.2 {页面/模块名称 2}

#### 6.2.1 页面概述
{页面用途、入口}

#### 6.2.2 功能点 1：{功能名称}
- **功能描述**：{详细说明}
- **交互设计**：{交互细节}
- **业务规则**：{规则}
- **边界情况**：{边界}
- **UI规范**：{规范}

---

## 7. 数据埋点需求

### 7.1 埋点方案
{埋点方式、埋点工具}

### 7.2 埋点事件
| 事件名称 | 触发条件 | 参数 | 说明 |
|----------|----------|------|------|
| {事件1} | {条件} | {参数} | {说明} |

### 7.3 统计指标
| 指标名称 | 计算方式 | 展示位置 |
|----------|----------|----------|
| {指标1} | {计算方式} | {位置} |

---

## 附录

### 评审清单
{附上Step 4的评审清单，逐项打勾}

### 变更记录
| 版本 | 日期 | 变更内容 | 作者 |
|------|------|----------|------|
| v1.0 | {日期} | 初始版本 | {姓名} |

使用示例

示例1：基于需求规格生成PRD

用户提供：

需求规格：订单管理模块增加批量导出功能平台：小爱工作台

Agent（Step0 知识库加载）：

1. 读 INDEX.md → 平台有 10 个模块，订单管理是其中之一
2. 读 DESIGN-SPEC.md → 获取设计规范（色彩、字体、组件、交互）
3. 读 modules/order/features.md → 现有功能：订单列表、订单详情、批量发货
4. 读 modules/order/rules.md → 现有规则：订单状态流转、权限控制
5. 读 modules/order/data.md → 现有实体：Order、OrderItem
6. 读 modules/order/interfaces.md → 现有接口：订单列表、订单详情
7. 读 modules/order/ui.md → 现有页面：订单列表页、订单详情页

Agent（Step1-5）：

基于需求规格和平台知识库，我来生成PRD文档...

[生成符合标准化规范的PRD]

PRD已生成，包含：

需求背景：基于订单管理模块现状

功能设计：复用现有 Order 实体，新增导出接口

UI设计：遵循平台设计规范（按钮用 Primary，表格行高 48px）

数据埋点：导出操作埋点

评审清单已逐项检查通过。

示例2：需求规格不完整