# Review Prd

> 以开发视角审查产品需求文档，识别需求不清晰、交互场景遗漏、逻辑冲突、异常处理缺失等问题，输出结构化 Excel 报告

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

---


# 审查产品需求文档（PRD Review）

## 概述

以开发者视角系统性审查产品需求文档，找出在实际开发中会导致返工、歧义或遗漏的问题。支持 Wiki 导出的混合格式文档（docx、xlsx、md、图片）。

## 使用方式

用户调用：`/review-prd <文档目录路径>`

如果用户未提供路径，询问文档目录位置。

## 审查流程

### 第一步：解析文档

1. 扫描目标目录，识别所有文档文件
2. 运行 `parse_docs.py` 将 docx/xlsx 转为可读文本：
   ```bash
   python .claude/skills/review-prd/parse_docs.py "<文档目录路径>"
   ```
3. 脚本会在目标目录下生成 `_parsed/` 子目录，包含所有解析后的文本文件
4. 对于 `.md` 文件，直接用 Read 工具读取
5. 对于图片文件（png/jpg），用 Read 工具查看（多模态），理解 UI 原型和流程图

**优先级**：如果存在 `converted_markdown/` 目录，优先读取其中的 md 文件作为主文档，docx 作为补充参考。

**多版本文档处理**：

- 同一文档可能存在多个日期版本（如 PRD文档1014、1016、1018、1203），**只读取最新版本**
- 通过文件名中的日期后缀识别版本，取日期最大的为最新版
- 字段规则 Excel 同理，只读取最新版本
- parse_docs.py 的 `--latest` 参数可自动去重，只解析每组文档的最新版本

### 第二步：建立文档全景

读完所有文档后，先梳理：

- 系统包含哪些模块/功能
- 各模块之间的关系和数据流向
- 核心业务流程是什么
- 涉及哪些角色和权限
- 哪些功能标注了"本期暂不实现"或"待讨论"（单独记录，不作为问题但需在报告中标注）

### 第三步：四维审查

逐模块、逐功能进行以下四个维度的审查：

#### 维度一：需求清晰度

- 功能描述是否有歧义，开发能否直接实现
- 业务规则是否明确（如：字段必填/选填、长度限制、格式要求）
- 边界条件是否定义（如：最大数量、超时时间、并发处理）
- 状态定义是否完整（如：枚举值是否列全、状态流转图是否有）
- 术语是否一致（同一概念是否用了不同名称）

#### 维度二：交互场景完整性

- 页面跳转逻辑是否完整（从哪来、到哪去）
- 按钮操作后的反馈是否说明（成功/失败提示）
- 操作按钮操作前是否有防呆措施（如：删除前确认弹窗提醒）
- 表单提交的校验规则是否明确
- 列表的排序、筛选、分页规则是否说明
- 弹窗/抽屉的触发条件和关闭行为是否定义
- 批量操作的场景是否覆盖（部分成功/部分失败如何处理）
- 权限不足时的交互是否定义
- 大数据量场景的交互是否考虑（导入/导出进度、列表性能）

#### 维度三：逻辑一致性

- 同一字段在不同文档/模块中的定义是否一致
- 状态流转是否有矛盾（如：A文档说可以从X到Y，B文档说不行）
- 业务规则在不同场景下是否冲突
- 数据流向是否闭环（创建的数据是否有对应的查看/编辑/删除）
- 跨模块引用的数据是否对齐

**交叉校验方法**（重点）：

- 将字段规则 Excel 中的字段定义（必填/选填、类型、校验规则）与 PRD 文档中的描述逐一比对
- 检查不同送检单之间共有字段的定义是否一致
- 检查配置中心的配置项是否与样本中心/分析中心的引用对齐
- 检查提示语 Excel 中的提示文案与 PRD 中描述的提示是否一致

#### 维度四：异常处理覆盖

- 网络异常、接口超时的处理是否说明
- 并发操作冲突的处理（如：两人同时编辑）
- 数据不存在或已被删除时的处理
- 权限变更后的处理（操作中途权限被收回、角色被禁用）
- 必要的确认操作是否有（如：删除前确认）
- 数据回滚/撤销机制是否需要
- 会话过期时未保存数据的保护
- 外部系统对接的异常处理（如 HIS 推送失败、重复推送）

### 第四步：生成报告

将所有发现的问题整理为 JSON 数组，每个问题包含：

```json
{
  "id": 1,
  "module": "所属模块名",
  "type": "需求清晰度|交互场景完整性|逻辑一致性|异常处理覆盖",
  "severity": "高|中|低",
  "description": "问题的具体描述",
  "source": "问题出处（文档名+章节/页码）",
  "suggestion": "给产品的修改建议"
}
```

将 JSON 写入临时文件，然后运行：

```bash
python .claude/skills/review-prd/generate_report.py "<JSON文件路径>" "<输出Excel路径>"
```

默认输出路径为文档目录下的 `PRD审查报告_YYYYMMDD.xlsx`。

## 严重程度定义

| 级别 | 含义                 | 示例                                                          |
| ---- | -------------------- | ------------------------------------------------------------- |
| 高   | 会导致开发阻塞或返工 | 核心流程缺失、逻辑矛盾、关键字段未定义、空章节影响开发        |
| 中   | 开发可推进但需确认   | 边界条件不明确、交互细节缺失、术语不一致、字段规则与PRD不一致 |
| 低   | 建议优化             | 描述可更清晰、建议补充说明、文档格式问题                      |

## 审查原则

- **站在开发者角度**：每个问题都要问"如果我来实现，这里够不够清楚？"
- **不做产品决策**：只指出问题和缺失，不替产品做选择
- **给出具体位置**：每个问题都要标注出处，方便产品定位
- **建议要可操作**：建议应该具体，而不是"请补充说明"
- **避免吹毛求疵**：聚焦真正影响开发的问题，不纠结文档格式
- **交叉比对优先**：字段规则 Excel 与 PRD 的不一致是高频问题，务必逐一比对
- **标注延期功能**：对"本期暂不实现"的功能不提问题，但在报告备注中记录，避免遗漏

## 来源与更新

- GitHub: https://github.com/songsunny00/MySkills/tree/main/skills/review-prd