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

概述

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

使用方式

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

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

审查流程

第一步：解析文档

1. 扫描目标目录，识别所有文档文件
2. 运行 parse_docs.py 将 docx/xlsx 转为可读文本：

   python .claude/skills/review-prd/parse_docs.py "<文档目录路径>"

1. 脚本会在目标目录下生成 _parsed/ 子目录，包含所有解析后的文本文件
2. 对于 .md 文件，直接用 Read 工具读取
3. 对于图片文件（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 数组，每个问题包含：

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

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

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

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

严重程度定义

审查原则

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

来源与更新

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