John Qiu
22107fa7b8
新建 req-prototype 技能，支持基于 PRD 自动生成 Stitch UI 原型。 同步 req-review、req-workflow 技能到仓库，并更新 req、req-prd 中的 原型相关引用。 REQ-20260320-0005 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
125 lines
3.5 KiB
Markdown
125 lines
3.5 KiB
Markdown
---
|
||
name: req-review
|
||
description: PRD 评审方法论。用于需求评审、PRD 文档审查、评审意见编写。当执行 /req review 或需要评审 PRD 文档时使用。
|
||
---
|
||
|
||
# PRD 评审方法论
|
||
|
||
PRD 评审是需求流程的关键质量关卡。
|
||
|
||
## 评审流程
|
||
|
||
```
|
||
PRD 提交 → 结构检查 → 清晰度评估 → 技术可行性 → 数据模型 → API 审查 → 结论
|
||
```
|
||
|
||
## 结构完整性检查
|
||
|
||
| 检查项 | 必须 | 说明 |
|
||
|--------|:----:|------|
|
||
| 基本信息 | ✓ | 编号、标题、日期、作者 |
|
||
| 需求背景 | ✓ | 为什么需要这个功能 |
|
||
| 目标用户 | ✓ | 面向的用户群体 |
|
||
| 功能描述 | ✓ | 详细功能需求 |
|
||
| 数据模型 | ✓ | 数据库表结构 |
|
||
| API 设计 | ✓ | RESTful 接口 |
|
||
| 验收标准 | ✓ | 验收条件 |
|
||
| 用户故事 | ○ | As a... I want... |
|
||
| 页面原型 | ○ | 如有 Stitch 原型则必审：布局合理性、与 PRD 描述一致性 |
|
||
| 非功能需求 | ○ | 性能、安全 |
|
||
|
||
## 需求清晰度（SMART 原则）
|
||
|
||
| 原则 | 检查点 |
|
||
|------|--------|
|
||
| **S**pecific | 描述是否具体明确 |
|
||
| **M**easurable | 是否有量化指标 |
|
||
| **A**chievable | 技术上是否可行 |
|
||
| **R**elevant | 是否与业务目标相关 |
|
||
| **T**ime-bound | 是否有时间范围 |
|
||
|
||
**示例**：
|
||
- ❌ "用户可以搜索需求"
|
||
- ✅ "用户可按编号精确搜索、按标题模糊搜索、按状态筛选，结果分页显示"
|
||
|
||
## 技术可行性
|
||
|
||
| 维度 | 评估内容 |
|
||
|------|----------|
|
||
| 技术栈兼容 | 现有栈是否支持 |
|
||
| 架构影响 | 是否需修改架构 |
|
||
| 第三方依赖 | 是否引入新依赖 |
|
||
| 性能影响 | 潜在性能问题 |
|
||
| 安全考量 | 安全风险 |
|
||
|
||
## 数据模型验证
|
||
|
||
| 检查项 | 说明 |
|
||
|--------|------|
|
||
| 表结构 | 字段类型、约束、索引 |
|
||
| 关联关系 | 外键、多对多 |
|
||
| 命名规范 | 符合项目规范 |
|
||
| 扩展性 | 预留扩展字段 |
|
||
| 查询性能 | 常用查询有索引 |
|
||
|
||
## API 设计审查
|
||
|
||
| 检查项 | 标准 |
|
||
|--------|------|
|
||
| RESTful | URL 用名词，HTTP 方法语义正确 |
|
||
| 响应格式 | `{success, data, message}` |
|
||
| 错误处理 | 明确的错误码 |
|
||
| 分页 | `?page=1&page_size=20` |
|
||
| 版本控制 | `/api/v1/...` |
|
||
|
||
## 界面原型检查（如有）
|
||
|
||
当 PRD 包含 Stitch 生成的原型时，评审人应检查：
|
||
|
||
| 检查项 | 说明 |
|
||
|--------|------|
|
||
| 页面覆盖 | 原型页面覆盖了 PRD 中描述的主要功能 |
|
||
| 布局一致 | 布局与 PRD 功能描述一致（无遗漏关键元素） |
|
||
| 交互合理 | 导航、表单、操作按钮逻辑合理 |
|
||
| 数据展示 | 列表、详情、表单字段完整 |
|
||
|
||
## 评审结论模板
|
||
|
||
**通过**：
|
||
```
|
||
✅ PRD 评审通过
|
||
|
||
【结论】文档完整，需求清晰，方案可行，建议批准。
|
||
【肯定】需求背景清晰、数据模型合理、API 规范
|
||
【建议】（非阻塞）补充性能测试用例
|
||
【评审人】xxx 【时间】2026-xx-xx
|
||
```
|
||
|
||
**驳回**：
|
||
```
|
||
❌ PRD 评审驳回
|
||
|
||
【原因】
|
||
1. 数据模型缺少索引
|
||
2. API 缺少错误处理
|
||
3. 搜索需求描述模糊
|
||
|
||
【修改要求】
|
||
□ 补充索引设计
|
||
□ 明确错误码
|
||
□ 细化搜索实现
|
||
|
||
【驳回人】xxx 【时间】2026-xx-xx
|
||
```
|
||
|
||
## 常见驳回原因
|
||
|
||
| 类别 | 问题 | 建议 |
|
||
|------|------|------|
|
||
| 结构缺失 | 缺数据模型或 API | 补充技术设计 |
|
||
| 需求模糊 | 描述不具体 | 按 SMART 重写 |
|
||
| 边界不清 | 缺异常处理 | 补充边界条件 |
|
||
| 设计缺陷 | 模型/API 不合理 | 重新设计 |
|
||
| 范围过大 | 难以实现 | 拆分为多需求 |
|
||
| 验收不明 | 缺验收标准 | 补充验收条件 |
|