Metadata

name: prd-autogen-and-review
description: 一句话需求 → 结构化 PRD + 评审 Checklist。支持中英文、图表、JSON导出、多角色评审。

PRD 自动生成 + 需求评审 Skill

概述

本 Skill 将用户输入的一句话需求（中文或英文），自动展开为结构化的产品需求文档（PRD），并附带一份需求评审 Checklist，用于后续评审和验收。

支持三种增强模式：

图表模式：在 PRD 中自动生成 UML 用例图（SVG）
导出模式：输出结构化 JSON 数据，对接 CI/Notion/Jira
多角色评审模式：从 PM/DEV/QA 不同视角交叉评审

触发条件

当用户以以下任一模式请求时，自动触发本 Skill：

"做一个 PRD：..."
"帮我写个 PRD：..."
"需求：..."
"一句话需求：..."
"需求评审：..."
"帮我评审这个需求：..."
"generate PRD for ..."
"write a PRD: ..."
上述变体，或任何明确指向需求文档生成的请求

模式触发关键词：

"加图表" / "with diagram" / "UML" → 启用图表模式
"导出" / "export" / "JSON" / "CI" → 启用导出模式
"多角色" / "交叉评审" / "cross-review" / "多视角" → 启用多角色评审模式

Step 1: 解析输入需求

从用户输入中提取核心信息：

一句话需求原文 — 完整保留用户原始表述
需求类别 — 新功能 / 功能优化 / 系统重构 / 数据需求 / 流程需求
目标用户 — 若用户未提及，标注"待确认"并作为评审项
核心关键词 — 提取 3-5 个关键词
模式检测 — 检测是否含有模式触发关键词

如果输入过短（< 15 字）或过于模糊，先反问澄清再继续。

Step 2: 生成结构化 PRD

按以下结构输出 PRD（Markdown 格式）：

# PRD: [需求标题]

## 1. 背景与动机
- **业务背景**：为何做这个？（从一句话需求展开推理）
- **用户痛点**：解决什么具体问题？
- **预期价值**：完成后的业务/用户体验收益

## 2. 目标与范围
- **产品目标**：1-3 条清晰的 OKR 风格目标
- **在范围（In Scope）**：
  - [功能点 1]
  - [功能点 2]
- **不在范围（Out of Scope）**：
  - [明确排除项]
- **假设条件**：当前推理依赖的假设

## 3. 用户角色
| 角色 | 描述 | 核心诉求 |
|------|------|----------|
| [角色 1] | ... | ... |

## 4. 功能需求

### 4.1 核心流程
[用自然语言描述用户从开始到完成的主流程，分步骤列出]

### 4.2 详细功能列表
| # | 功能 | 优先级 (P0-P3) | 描述 | 验收标准 |
|---|------|---------------|------|---------|
| 1 | ... | P0 | ... | ... |

## 5. 非功能需求
- **性能**：响应时间、并发量等
- **安全**：权限、数据隐私等
- **可用性**：兼容性、可访问性等
- **可扩展性**：未来扩展考虑

## 6. 成功指标
- **北极星指标**：1 个
- **关键结果 / GT 指标**：2-3 个可量化指标

## 7. 风险与缓解措施
| 风险 | 影响 | 概率 | 缓解方案 |
|------|------|----------|------|
| ... | 高/中/低 | 高/中/低 | ... |

Step 3（可选）: 图表模式 — UML 用例图

当检测到用户请求中包含"加图表""UML""diagram"等关键词，或用户回复"加图表"时，额外生成 UML 用例图。

3.1 用例图内容

使用 Diagram Maker Skill（clean-svg 模式）生成 SVG 用例图，包含：

主角（Actor）：从 PRD 用户角色章节提取
用例（Use Case）：从功能列表提取核心功能，每个功能对应一个用例
关系：
- Actor → Use Case（关联）
- Use Case → Use Case（<<include>> / <<extend>>）
系统边界框：标出系统边界（System Boundary）

3.2 输出格式

## 8. UML 用例图

![用例图](prd_usecase_diagram.html)

| 元素 | 说明 |
|------|------|
| [Actor 1] | [定义] |
| [用例 1] | [对应功能] |

3.3 SVG 示例模板

<!-- 用例图骨架 -->
<svg viewBox="0 0 800 500">
  <!-- 系统边界 -->
  <rect x="200" y="80" width="400" height="340" class="zone" rx="8"/>
  <text x="400" y="105" class="small" text-anchor="middle">系统边界</text>

  <!-- Actor（火柴人简化） -->
  <circle cx="80" cy="200" r="16"/>
  <line x1="80" y1="216" x2="80" y2="270"/>
  <line x1="48" y1="240" x2="112" y2="240"/>
  <line x1="80" y1="270" x2="48" y2="310"/>
  <line x1="80" y1="270" x2="112" y2="310"/>
  <text x="80" y="335" class="label" text-anchor="middle">用户</text>

  <!-- 用例椭圆 -->
  <ellipse cx="360" cy="160" rx="100" ry="24" class="node process"/>
  <text x="360" y="165" class="label" text-anchor="middle">一键登录</text>

  <!-- 关联线 -->
  <line x1="96" y1="240" x2="260" y2="160" class="edge"/>
</svg>

3.4 布局建议

Actor 放系统边界左侧（最多 3 个 Actor 纵向排列）
用例椭圆在系统边界内从左到右、从上到下排列
目标：5-9 个用例，每个用例文字 ≤ 8 个字
优先使用 cian-svg 模式，输出 .html 文件

Step 4（可选）: 导出模式 — JSON 结构化数据

当用户要求"导出""JSON""CI"时，在标准 PRD 输出后额外附加 JSON 结构化数据。

4.1 输出 JSON 格式

{
  "prd": {
    "title": "",
    "version": "v0.1",
    "generated_at": "ISO-8601"
  },
  "background": {
    "business_context": "",
    "pain_points": [],
    "expected_value": ""
  },
  "goals": [
    { "id": "G-001", "objective": "", "type": "OKR" }
  ],
  "scope": {
    "in_scope": ["..."],
    "out_of_scope": ["..."],
    "assumptions": [
      { "text": "...", "risk_level": "high|medium|low" }
    ]
  },
  "user_roles": [
    { "id": "UR-001", "name": "", "description": "", "core_need": "" }
  ],
  "features": [
    {
      "id": "F-001",
      "name": "",
      "priority": "P0|P1|P2|P3",
      "description": "",
      "acceptance_criteria": "",
      "depends_on": []
    }
  ],
  "non_functional": {
    "performance": "",
    "security": "",
    "availability": "",
    "scalability": ""
  },
  "success_metrics": {
    "north_star": "",
    "key_results": ["..."]
  },
  "risks": [
    {
      "id": "R-001",
      "description": "",
      "impact": "high|medium|low",
      "probability": "high|medium|low",
      "mitigation": ""
    }
  ],
  "review_checklist": {
    "completeness": [
      { "item": "...", "status": "pass|fail|warn", "note": "" }
    ],
    "consistency": [...],
    "feasibility": [...],
    "testability": [...],
    "discussion_items": [...]
  }
}

4.2 输出方式

在 PRD 正文后用代码块输出：

[完整 JSON 数据]

也可以应请求写入文件：

prd-[slug].json（结构化评审数据）
prd-[slug].md（Markdown PRD 文档）

Step 5（可选）: 多角色评审模式

当用户要求"多角色""交叉评审""多视角""cross-review"时，在标准 Checklist 之外，额外从 5 个角色视角输出评审。

5.1 五个评审视角

角色	关注点	评分标准（1-5）
PM（产品经理）	需求完整性、价值对齐、用户价值	价值驱动、无遗漏
Dev（开发）	技术可行性、实现成本、系统影响	技术合理、范围可控
QA（测试）	可测试性、边界覆盖、验收标准	可测、可判定、无模糊
Design（设计）	交互复杂度、一致性、用户体验	合理、可落地、一致
Security（安全）	数据隐私、权限、合规风险	合规、无泄漏、有防护

5.2 输出格式

## 多角色评审报告

### 👤 PM 视角 — 评分: 4/5
**正向**：
- 需求背景清晰，用户痛点明确
- 核心功能与目标对齐

**关注点**：
- ⚠️ Out of scope 列表偏少，可能需要更多排除项
- 成功指标中流失率降低 40% 缺乏基线数据

### 👨‍💻 Dev 视角 — 评分: 3/5
**正向**：
- 功能拆分粒度合理，验收标准可量化

**关注点**：
- ⚠️ **阻塞项**：运营商 SDK 接入需确认商务合同
- ⚠️ 假设条件中"运营商接口可用性 99.9%"无 SLA 支撑

### 🧪 QA 视角 — 评分: 4/5
**正向**：
- 异常场景覆盖完整（双卡/降级/无网）
- 验收标准可判定、可测试

**关注点**：
- ⚠️ 双卡手机兼容性需增加真机测试机型覆盖

### 🎨 Design 视角 — 评分: 4/5
**正向**：
- 核心流程路径清晰（3 步登录）

**关注点**：
- ⚠️ 降级方案（短信验证码）的界面切换动效未定义
- 国际区号选择器参考系统通讯录 UI 规范

### 🔒 Security 视角 — 评分: 4/5
**正向**：
- 手机号加密传输、Token JWT + RSA

**关注点**：
- ⚠️ 运营商取号过程中是否存在中间人攻击风险？
- 用户授权弹窗的隐私协议需法务审核

---

### 综合评分

| 角色 | 评分 | 阻碍项 |
|:----|:---:|:------:|
| PM | 4/5 | 0 |
| Dev | 3/5 | 1 (⚠️ 阻塞) |
| QA | 4/5 | 0 |
| Design | 4/5 | 0 |
| Security | 4/5 | 0 |
| **综合** | **3.8/5** | **1 阻塞项** |

> 🟢 综合通过（无致命阻塞项，所有 ⚠️ 可在评审后 3 个工作日内关闭）

5.3 评分规则

5分：无任何问题，可直接进入开发
4分：有少数非阻塞建议项，开发同时跟进
3分：有 1 个或以上阻塞项，需评审后关闭才能开始开发
2分：需求严重不完整或不可行，需重新梳理
1分：需求不可理解或现有信息完全无法评估

Step 6: 输出交付

根据模式组合，最终交付包含：

模式	内容	格式
⬜ 标准模式	PRD + Checklist	Markdown
📊 图表模式	PRD + Checklist + UML 用例图	Markdown + HTML/SVG
🔧 导出模式	PRD + Checklist + JSON 结构化数据	Markdown + JSON
👥 多角色评审	PRD + 多角色评审报告	Markdown
🎯 全模式	PRD + Checklist + UML + JSON + 多角色评审	Markdown + HTML/SVG + JSON

如果输出较长，分块交付或写入本地文件：

📄 **PRD：[需求标题]**
[PRD 主体]

---

📊 **[可选] UML 用例图**
[图 / 文件链接]

---

🔧 **[可选] JSON 结构化数据**
```json
...

👥 [可选] 多角色评审报告 ...

📋 需求评审 Checklist ...


---

## 边界与约束

- 如果输入过于模糊（< 15 字），必须反问澄清至少一个关键点再生成
- 对于技术性需求，标注"技术方案需进一步确认"
- 对于涉及外部系统/API 的需求，自动添加"外部依赖确认"评审项
- 对于涉及资金/支付的需求，自动添加"合规性/法务评审"提醒
- PRD 中的风险假设必须显式标注 ⚠️
- 不处理非产品需求（如营销文案、运营活动、代码 bug 修复等明确非 PRD 场景）
- 图表模式下，UML 用例图元素控制在 5-9 个，避免图表过密
- 多角色评审模式下，每个角色输出不少于 2 条关注点

## 文件引用

本 Skill 不依赖外部文件。辅助工具：
- Diagram Maker Skill（diagram-maker）— 用于生成 UML SVG 用例图
- 导出模式生成的 JSON 文件可写入 workspace 供 CI 调用

## 版本

- v1.0: 标准模式（PRD 生成 + 评审 Checklist）
- v1.5: 图表模式（UML 用例图）+ 导出模式（JSON）+ 多角色评审模式

prd-autogen-and-review

安装技能