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

概述

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

使用方式

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

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

审查流程

第一步：解析文档

运行 parse_docs.py 将 docx/xlsx 转为可读文本：

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

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

严重程度定义

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

审查原则

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

来源与更新

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