ai-proj-helper/skills-req/req-plugin/docs/prd-review-guide.md

PRD 评审方法论

评审 PRD 是需求流程中的关键质量关卡。

评审流程

1. 结构完整性检查 - 检查 PRD 是否包含所有必要章节
2. 需求清晰度评估 - 验证需求描述是否明确无歧义
3. 技术可行性分析 - 评估技术方案是否可实现
4. 数据模型验证 - 检查数据结构设计是否合理
5. API 设计审查 - 验证接口设计是否符合规范

PRD 评审检查清单

一、结构完整性检查

检查项	必须	说明
基本信息	✓	需求编号、标题、创建日期、作者
需求背景	✓	为什么需要这个功能
目标用户	✓	明确功能面向的用户群体
功能描述	✓	详细的功能需求说明
用户故事	○	As a... I want... So that...
数据模型	✓	数据库表结构设计
API 设计	✓	RESTful 接口定义
页面原型	○	界面布局和交互说明
非功能需求	○	性能、安全、可用性要求
验收标准	✓	明确的功能验收条件

✓ = 必须包含, ○ = 建议包含

二、需求清晰度评估（SMART 原则）

原则	检查点	示例
Specific	需求描述是否具体明确	❌ "支持搜索" → ✅ "支持按需求编号、标题模糊搜索"
Measurable	是否有量化指标	❌ "快速响应" → ✅ "响应时间 < 200ms"
Achievable	技术上是否可行	评估现有技术栈能否支持
Relevant	是否与业务目标相关	功能是否解决实际问题
Time-bound	是否有明确的时间范围	开发周期、上线日期

三、技术可行性分析

检查维度	评估内容
技术栈兼容性	现有技术栈是否支持所需功能
系统架构影响	是否需要修改现有架构
第三方依赖	是否引入新的外部依赖
性能影响	对系统性能的潜在影响
安全考量	是否存在安全风险
数据迁移	是否需要数据迁移方案

四、数据模型验证

检查项	说明
表结构设计	字段类型、约束、索引是否合理
关联关系	外键、多对多关系是否正确
命名规范	表名、字段名是否符合项目规范
扩展性	是否预留扩展字段
数据量预估	数据增长预估和存储方案
查询性能	常用查询是否有索引支持

五、API 设计审查

检查项	标准
RESTful 规范	URL 使用名词、HTTP 方法语义正确
响应格式	统一的响应结构 {success, data, message}
错误处理	明确的错误码和错误信息
分页设计	列表接口支持分页 ?page=1&page_size=20
参数验证	必填参数、类型、范围说明
版本控制	API 路径包含版本 /api/v1/...

评审意见模板

通过模板

✅ PRD 评审通过

【评审结论】
PRD 文档结构完整，需求描述清晰，技术方案可行，建议批准进入开发阶段。

【肯定之处】
- 需求背景阐述清晰
- 数据模型设计合理
- API 接口规范

【建议改进】（非阻塞）
- 建议补充性能测试用例
- 建议增加边界条件说明

【评审人】xxx
【评审时间】2026-01-24 10:00

驳回模板

❌ PRD 评审驳回

【驳回原因】
1. 数据模型缺少索引设计
2. API 接口缺少错误处理说明
3. 搜索功能需求描述模糊

【修改要求】
□ 补充数据表索引设计
□ 明确 API 错误码定义
□ 细化搜索功能的具体实现方式

【驳回人】xxx
【驳回时间】2026-01-24 10:00

常见驳回原因

类别	常见问题	改进建议
结构缺失	缺少数据模型或 API 设计	补充完整的技术设计章节
需求模糊	功能描述不够具体	按 SMART 原则重新描述
边界不清	缺少边界条件和异常处理	补充边界条件和错误场景
设计缺陷	数据模型或 API 设计不合理	重新设计并说明理由
范围过大	需求范围过大难以实现	拆分为多个小需求
验收不明	缺少验收标准	补充可验证的验收条件