John Qiu
dcdae8c636
- Add publish-plugin: marketplace publish + Feishu bot notification - Rewrite init.sh: SSE-first, fixed prod API, remove env selection - Update CLAUDE.md, README.md, claude-config.yaml - Update skills: req-plugin, req-prd-plugin, pull-request-plugin - Delete sync-skills.sh (obsolete) - Delete deprecated plugins: skills-ops/*, skills-projects/*, old skills-dev/req duplicates - Regenerate marketplace.json (27 plugins) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
771 lines
17 KiB
Markdown
771 lines
17 KiB
Markdown
---
|
||
name: req-prd
|
||
description: 产品设计与需求管理。用于 PRD 文档编写、需求分析、用户故事创建、功能设计和原型规划、PRD 评审。当用户提到产品设计、PRD、需求文档、功能规划、用户故事、PRD 评审相关任务时自动激活。
|
||
---
|
||
|
||
# 产品需求设计 Skill (req-prd)
|
||
|
||
## 概述
|
||
|
||
本技能用于辅助产品设计和需求管理工作，包括：
|
||
- PRD 文档编写与管理
|
||
- **参考对象对比式 PRD 编写**（核心能力）
|
||
- 需求分析与优先级排序
|
||
- 用户故事创建
|
||
- 功能设计与规划
|
||
- 与 ai-proj 任务系统集成
|
||
|
||
---
|
||
|
||
## 参考对象对比式 PRD 编写
|
||
|
||
当进行**系统平移、功能迁移、竞品借鉴**时，应采用对比分析法编写 PRD，确保新系统功能完整且有所改进。
|
||
|
||
### 适用场景
|
||
|
||
| 场景 | 说明 | 示例 |
|
||
|------|------|------|
|
||
| 系统平移 | 旧系统迁移到新技术栈 | 酷采2.0 → 酷采3.0 |
|
||
| 功能借鉴 | 参考竞品功能设计 | 参考飞书设计协作功能 |
|
||
| 版本升级 | 基于当前版本优化 | V1.0 → V2.0 重构 |
|
||
|
||
### 对比分析工作流
|
||
|
||
```
|
||
1. 确定参考对象
|
||
├── 识别参考系统（可以是多个）
|
||
├── 获取访问权限（测试环境、源代码）
|
||
└── 明确对比目标
|
||
|
||
2. 参考对象分析
|
||
├── 功能调研（前端页面操作）
|
||
├── 数据模型分析（数据库表结构）
|
||
├── 业务逻辑分析（后端代码）
|
||
└── API 接口分析
|
||
|
||
3. 对比分析
|
||
├── 功能对比表（保留/优化/新增/废弃）
|
||
├── 数据模型对比（字段映射、新增字段）
|
||
├── 技术架构对比
|
||
└── 用户体验对比
|
||
|
||
4. PRD 编写
|
||
├── 背景说明（明确参考来源）
|
||
├── 功能需求（标注来源与变更）
|
||
├── 数据设计（标注字段来源）
|
||
└── 实现建议
|
||
```
|
||
|
||
### 对比式 PRD 模板
|
||
|
||
```markdown
|
||
# [功能模块名称] PRD
|
||
|
||
## 1. 文档概述
|
||
|
||
### 1.1 文档信息
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| 文档名称 | [模块名称] 需求文档 |
|
||
| 版本 | V1.0 |
|
||
| 创建日期 | [日期] |
|
||
| **需求来源** | **[参考系统名称] 平移/借鉴** |
|
||
| **参考系统** | **[参考系统访问地址]** |
|
||
|
||
### 1.2 背景说明
|
||
本需求文档基于 **[参考系统]** 的 [模块名称] 功能分析，将其平移至 [目标系统]。
|
||
|
||
**参考系统信息**：
|
||
- 系统地址：[URL]
|
||
- 技术栈：[技术栈描述]
|
||
- 源码位置：[源码路径]（如有）
|
||
|
||
---
|
||
|
||
## 2. 参考系统分析
|
||
|
||
### 2.1 功能截图
|
||
[插入参考系统功能截图]
|
||
|
||
### 2.2 数据模型（参考系统）
|
||
```sql
|
||
-- 参考系统表结构
|
||
CREATE TABLE [表名] (
|
||
-- 从源代码/数据库提取
|
||
);
|
||
```
|
||
|
||
### 2.3 API 接口（参考系统）
|
||
| 接口 | 方法 | 说明 |
|
||
|------|------|------|
|
||
| /api/xxx | GET/POST | [描述] |
|
||
|
||
### 2.4 业务逻辑（参考系统）
|
||
- 核心业务规则摘要
|
||
- 数据校验规则
|
||
- 状态流转逻辑
|
||
|
||
---
|
||
|
||
## 3. 功能对比分析
|
||
|
||
### 3.1 功能对比表
|
||
| 序号 | 功能 | 参考系统 | 目标系统 | 变更类型 | 说明 |
|
||
|------|------|----------|----------|----------|------|
|
||
| 1 | [功能1] | ✅ | ✅ | 保留 | 直接平移 |
|
||
| 2 | [功能2] | ✅ | ✅+ | 优化 | [优化内容] |
|
||
| 3 | [功能3] | ❌ | ✅ | 新增 | [新增原因] |
|
||
| 4 | [功能4] | ✅ | ❌ | 废弃 | [废弃原因] |
|
||
|
||
### 3.2 数据模型对比
|
||
| 参考系统字段 | 目标系统字段 | 类型 | 变更 | 说明 |
|
||
|--------------|--------------|------|------|------|
|
||
| id (varchar) | id (bigint) | PK | 优化 | 改用自增ID |
|
||
| company_id | tenant_id | FK | 重命名 | 统一租户字段 |
|
||
| -- | created_by | bigint | 新增 | 审计字段 |
|
||
|
||
### 3.3 技术架构对比
|
||
| 层次 | 参考系统 | 目标系统 |
|
||
|------|----------|----------|
|
||
| 后端框架 | [如: Spring Boot] | [如: Go Gin] |
|
||
| 前端框架 | [如: Vue 2] | [如: React 18] |
|
||
| 数据库 | [如: MySQL] | [如: PostgreSQL] |
|
||
|
||
---
|
||
|
||
## 4. 目标系统设计
|
||
|
||
### 4.1 功能清单
|
||
| 序号 | 功能 | 优先级 | 来源 | 说明 |
|
||
|------|------|--------|------|------|
|
||
| 1 | [功能] | P0 | 平移 | 从参考系统平移 |
|
||
|
||
### 4.2 数据模型（目标系统）
|
||
```sql
|
||
-- 目标系统表结构（基于对比分析设计）
|
||
CREATE TABLE [表名] (
|
||
id BIGINT PRIMARY KEY,
|
||
-- 字段设计...
|
||
);
|
||
```
|
||
|
||
### 4.3 API 设计（目标系统）
|
||
| 接口 | 方法 | 说明 | 参考接口 |
|
||
|------|------|------|----------|
|
||
| /api/v1/xxx | GET | [描述] | 参考 /api/xxx |
|
||
|
||
### 4.4 业务规则
|
||
- [ ] 规则1（沿用参考系统）
|
||
- [ ] 规则2（优化调整）
|
||
|
||
---
|
||
|
||
## 5. 实现建议
|
||
|
||
### 5.1 开发顺序
|
||
1. 数据模型迁移
|
||
2. 后端 API 实现
|
||
3. 前端页面开发
|
||
4. 数据迁移脚本
|
||
|
||
### 5.2 注意事项
|
||
- 参考系统中 [xxx] 逻辑需要特别注意
|
||
- 新系统中需改进 [xxx] 问题
|
||
```
|
||
|
||
---
|
||
|
||
### 参考对象分析工具
|
||
|
||
#### 1. 前端分析
|
||
```bash
|
||
# 启动浏览器调试模式（macOS）
|
||
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
|
||
--remote-debugging-port=9222 \
|
||
--user-data-dir=/tmp/chrome-debug
|
||
|
||
# 访问参考系统，截图、分析交互
|
||
```
|
||
|
||
#### 2. 后端代码分析
|
||
```bash
|
||
# 搜索相关模型
|
||
grep -r "class.*Model" --include="*.java" /path/to/legacy/
|
||
|
||
# 搜索相关控制器
|
||
grep -r "@Controller\|@RestController" --include="*.java" /path/to/legacy/
|
||
```
|
||
|
||
#### 3. 数据库分析
|
||
```sql
|
||
-- 查看表结构
|
||
SHOW CREATE TABLE table_name;
|
||
|
||
-- 查看字段注释
|
||
SELECT COLUMN_NAME, COLUMN_COMMENT
|
||
FROM information_schema.COLUMNS
|
||
WHERE TABLE_NAME = 'table_name';
|
||
```
|
||
|
||
---
|
||
|
||
### 示例：酷采3.0标签管理模块
|
||
|
||
以下是基于酷采2.0平移的标签管理模块对比分析示例：
|
||
|
||
#### 参考系统（酷采2.0）
|
||
|
||
**数据模型**：
|
||
```sql
|
||
-- 酷采2.0 prd_product_label 表
|
||
CREATE TABLE `prd_product_label` (
|
||
`id` varchar(64) NOT NULL,
|
||
`label_name` varchar(256) DEFAULT NULL,
|
||
`company_id` varchar(64) DEFAULT NULL,
|
||
`input_user_id` varchar(64) DEFAULT NULL,
|
||
`input_user_name` varchar(64) DEFAULT NULL,
|
||
`input_time` datetime DEFAULT NULL,
|
||
`update_user_id` varchar(64) DEFAULT NULL,
|
||
`update_user_name` varchar(64) DEFAULT NULL,
|
||
`update_time` datetime DEFAULT NULL,
|
||
`version` bigint(20) DEFAULT 0,
|
||
`is_delete` tinyint(1) DEFAULT 0,
|
||
`status` tinyint(1) DEFAULT 1,
|
||
`remark` varchar(512) DEFAULT NULL,
|
||
`sort_no` int(11) DEFAULT 0,
|
||
PRIMARY KEY (`id`)
|
||
);
|
||
```
|
||
|
||
**代码位置**：
|
||
- 后端: `cool_lining/module-provider/.../dao/model/prd/PrdProductLabel.java`
|
||
- 前端: `ln_admin/src/views/module/prd/product_label/`
|
||
|
||
#### 目标系统（酷采3.0）设计
|
||
|
||
**数据模型对比**：
|
||
| 酷采2.0 | 酷采3.0 | 变更 |
|
||
|---------|---------|------|
|
||
| id (varchar) | id (bigint) | 改用自增ID |
|
||
| company_id | tenant_id | 统一租户标识 |
|
||
| input_user_id | created_by | 简化字段命名 |
|
||
| input_time | created_at | 统一时间字段 |
|
||
| is_delete | deleted_at | 改用软删除时间戳 |
|
||
|
||
---
|
||
|
||
## PRD 文档模板
|
||
|
||
### 标准 PRD 结构
|
||
|
||
```markdown
|
||
# [产品/功能名称] PRD
|
||
|
||
## 1. 概述
|
||
### 1.1 背景
|
||
[为什么需要这个功能？解决什么问题？]
|
||
|
||
### 1.2 目标
|
||
- 业务目标：[量化的业务指标]
|
||
- 用户目标：[用户能获得什么价值]
|
||
- 技术目标：[技术层面要达成什么]
|
||
|
||
### 1.3 成功指标
|
||
| 指标 | 当前值 | 目标值 | 衡量方式 |
|
||
|------|--------|--------|----------|
|
||
| ... | ... | ... | ... |
|
||
|
||
## 2. 用户分析
|
||
### 2.1 目标用户
|
||
[用户画像描述]
|
||
|
||
### 2.2 用户痛点
|
||
1. [痛点1]
|
||
2. [痛点2]
|
||
|
||
### 2.3 用户场景
|
||
[场景描述]
|
||
|
||
## 3. 功能需求
|
||
### 3.1 功能清单
|
||
| 功能 | 优先级 | 描述 | 验收标准 |
|
||
|------|--------|------|----------|
|
||
| ... | P0/P1/P2 | ... | ... |
|
||
|
||
### 3.2 功能详细说明
|
||
#### [功能1]
|
||
- 功能描述：
|
||
- 触发条件：
|
||
- 业务规则：
|
||
- 异常处理：
|
||
|
||
## 4. 交互设计
|
||
### 4.1 用户流程
|
||
[流程图或步骤描述]
|
||
|
||
### 4.2 界面原型
|
||
[原型链接或描述]
|
||
|
||
## 5. 技术要求
|
||
### 5.1 性能要求
|
||
- 响应时间：
|
||
- 并发量：
|
||
- 数据量：
|
||
|
||
### 5.2 安全要求
|
||
- 权限控制：
|
||
- 数据安全：
|
||
|
||
### 5.3 兼容性要求
|
||
- 浏览器：
|
||
- 设备：
|
||
|
||
## 6. 上线计划
|
||
### 6.1 里程碑
|
||
| 阶段 | 内容 | 完成标准 |
|
||
|------|------|----------|
|
||
| ... | ... | ... |
|
||
|
||
### 6.2 灰度策略
|
||
[灰度发布计划]
|
||
|
||
## 7. 风险评估
|
||
| 风险 | 影响 | 概率 | 应对措施 |
|
||
|------|------|------|----------|
|
||
| ... | 高/中/低 | 高/中/低 | ... |
|
||
|
||
## 8. 附录
|
||
- 相关文档链接
|
||
- 参考资料
|
||
```
|
||
|
||
---
|
||
|
||
## 需求优先级框架
|
||
|
||
### RICE 评分法
|
||
|
||
| 维度 | 说明 | 评分范围 |
|
||
|------|------|----------|
|
||
| Reach (触达) | 影响多少用户 | 1-10 |
|
||
| Impact (影响) | 对用户的影响程度 | 0.25-3 |
|
||
| Confidence (信心) | 估算的置信度 | 0-100% |
|
||
| Effort (工作量) | 需要的人天数 | 实际工作量 |
|
||
|
||
**计算公式**: `RICE = (Reach × Impact × Confidence) / Effort`
|
||
|
||
### 优先级定义
|
||
|
||
| 优先级 | 含义 | 处理方式 |
|
||
|--------|------|----------|
|
||
| P0 | 阻塞性需求 | 必须立即处理 |
|
||
| P1 | 核心需求 | 本迭代必须完成 |
|
||
| P2 | 重要需求 | 尽量本迭代完成 |
|
||
| P3 | 优化需求 | 有余力时处理 |
|
||
|
||
---
|
||
|
||
## 用户故事编写
|
||
|
||
### 标准格式
|
||
|
||
```
|
||
作为 [用户角色]，
|
||
我想要 [功能/目标]，
|
||
以便 [获得的价值/原因]。
|
||
|
||
验收标准：
|
||
- Given [前置条件]
|
||
- When [用户行为]
|
||
- Then [预期结果]
|
||
```
|
||
|
||
### 示例
|
||
|
||
```
|
||
作为 仓库管理员，
|
||
我想要 扫码快速入库，
|
||
以便 提高入库效率、减少手动输入错误。
|
||
|
||
验收标准：
|
||
- Given 已有采购单且货物到达
|
||
- When 扫描货物条码
|
||
- Then 自动匹配采购单并显示入库确认界面
|
||
```
|
||
|
||
### INVEST 原则检查
|
||
|
||
| 原则 | 含义 | 检查点 |
|
||
|------|------|--------|
|
||
| I - Independent | 独立的 | 故事间无依赖 |
|
||
| N - Negotiable | 可协商 | 非固定规格 |
|
||
| V - Valuable | 有价值 | 交付业务价值 |
|
||
| E - Estimable | 可估算 | 能估算工作量 |
|
||
| S - Small | 足够小 | 可在迭代内完成 |
|
||
| T - Testable | 可测试 | 有明确验收标准 |
|
||
|
||
---
|
||
|
||
## 与 ai-proj 集成
|
||
|
||
### 需求管理工具
|
||
|
||
使用 ai-proj MCP 工具管理需求：
|
||
|
||
```bash
|
||
# 创建需求
|
||
mcp__ai-proj__create_requirement
|
||
- title: "需求标题"
|
||
- description: "需求描述"
|
||
- category: feature/bug/improvement/documentation/other
|
||
- priority: low/medium/high
|
||
- projectId: 项目ID
|
||
|
||
# 查看需求列表
|
||
mcp__ai-proj__list_requirements
|
||
- status: draft/pending/reviewing/approved/rejected/archived
|
||
- priority: low/medium/high
|
||
|
||
# 需求与任务关联
|
||
mcp__ai-proj__link_tasks_to_requirement
|
||
- requirementId: 需求ID
|
||
- taskIds: [任务ID列表]
|
||
```
|
||
|
||
### 任务分解流程
|
||
|
||
1. **创建需求** → `create_requirement`
|
||
2. **需求评审** → `submit_requirement` → `approve/reject_requirement`
|
||
3. **分解任务** → `create_task` / `create_subtask`
|
||
4. **关联任务** → `link_tasks_to_requirement`
|
||
5. **跟踪进度** → `get_requirement_tasks` / `get_requirement_statistics`
|
||
|
||
### 文档管理
|
||
|
||
```bash
|
||
# 创建 PRD 文档并关联任务
|
||
mcp__ai-proj__create-and-attach
|
||
- taskId: 任务ID
|
||
- content: PRD 文档内容 (Markdown)
|
||
- title: 文档标题 (可选)
|
||
|
||
# 更新 PRD 文档
|
||
mcp__ai-proj__update_task_document
|
||
- taskId: 任务ID
|
||
- content: 更新后的内容
|
||
|
||
# 导出 PRD 到文件
|
||
mcp__ai-proj__export_task_document_to_file
|
||
- taskId: 任务ID
|
||
```
|
||
|
||
---
|
||
|
||
## 功能设计流程
|
||
|
||
### 1. 需求收集
|
||
|
||
```
|
||
输入：
|
||
- 用户反馈
|
||
- 业务需求
|
||
- 数据分析
|
||
- 竞品分析
|
||
|
||
输出：
|
||
- 需求池（ai-proj 需求列表）
|
||
```
|
||
|
||
### 2. 需求分析
|
||
|
||
```
|
||
方法：
|
||
- 5W1H 分析法
|
||
- 用户访谈
|
||
- 数据验证
|
||
|
||
输出：
|
||
- 需求文档
|
||
- 优先级排序
|
||
```
|
||
|
||
### 3. 方案设计
|
||
|
||
```
|
||
内容：
|
||
- 功能架构
|
||
- 交互流程
|
||
- 界面原型
|
||
- 技术方案
|
||
|
||
输出：
|
||
- PRD 文档
|
||
- 原型设计
|
||
```
|
||
|
||
### 4. 评审验证
|
||
|
||
```
|
||
评审维度：
|
||
- 业务价值
|
||
- 技术可行性
|
||
- 资源评估
|
||
- 风险评估
|
||
|
||
输出：
|
||
- 评审结论
|
||
- 修改意见
|
||
```
|
||
|
||
---
|
||
|
||
## 竞品分析模板
|
||
|
||
### 分析框架
|
||
|
||
```markdown
|
||
# [竞品名称] 分析
|
||
|
||
## 1. 产品概述
|
||
- 定位：
|
||
- 核心功能：
|
||
- 目标用户：
|
||
|
||
## 2. 功能对比
|
||
| 功能 | 我们 | 竞品A | 竞品B |
|
||
|------|------|-------|-------|
|
||
| 功能1 | ✅/❌/部分 | ... | ... |
|
||
|
||
## 3. 优劣势分析
|
||
### 优势
|
||
1. ...
|
||
|
||
### 劣势
|
||
1. ...
|
||
|
||
## 4. 可借鉴点
|
||
- ...
|
||
|
||
## 5. 差异化策略
|
||
- ...
|
||
```
|
||
|
||
---
|
||
|
||
## 产品指标体系
|
||
|
||
### 北极星指标选择
|
||
|
||
| 产品类型 | 典型北极星指标 |
|
||
|----------|----------------|
|
||
| 电商 | GMV / 订单量 |
|
||
| SaaS | MRR / 活跃用户数 |
|
||
| 社交 | DAU / 消息数 |
|
||
| 工具 | 完成任务数 / 使用时长 |
|
||
|
||
### 指标分层
|
||
|
||
```
|
||
北极星指标
|
||
├── 一级指标（核心业务指标）
|
||
│ ├── 二级指标（过程指标）
|
||
│ │ └── 三级指标（功能指标）
|
||
```
|
||
|
||
### 常用指标
|
||
|
||
| 类型 | 指标 | 计算方式 |
|
||
|------|------|----------|
|
||
| 获客 | 新用户数、获客成本 | 注册数 / 推广费用 |
|
||
| 激活 | 激活率、首日留存 | 完成核心动作 / 注册数 |
|
||
| 留存 | 次日/7日/30日留存 | 回访用户 / 新增用户 |
|
||
| 收入 | ARPU、付费率 | 收入 / 用户数 |
|
||
| 传播 | 推荐率、K因子 | 邀请数 / 用户数 |
|
||
|
||
---
|
||
|
||
## 设计检查清单
|
||
|
||
### PRD 完整性检查
|
||
|
||
- [ ] 背景与目标明确
|
||
- [ ] 用户群体定义清晰
|
||
- [ ] 功能需求完整
|
||
- [ ] 验收标准可测试
|
||
- [ ] 异常情况已考虑
|
||
- [ ] 性能要求已定义
|
||
- [ ] 上线计划合理
|
||
- [ ] 风险已评估
|
||
|
||
### 交互设计检查
|
||
|
||
- [ ] 用户流程完整
|
||
- [ ] 边界情况处理
|
||
- [ ] 错误提示友好
|
||
- [ ] 反馈及时
|
||
- [ ] 操作可撤销
|
||
- [ ] 符合用户习惯
|
||
|
||
### 技术方案检查
|
||
|
||
- [ ] 技术可行性验证
|
||
- [ ] 性能影响评估
|
||
- [ ] 扩展性考虑
|
||
- [ ] 安全性审查
|
||
- [ ] 兼容性测试
|
||
|
||
---
|
||
|
||
## 常用工具
|
||
|
||
### 原型设计
|
||
- Figma
|
||
- Sketch
|
||
- Axure
|
||
|
||
### 流程图
|
||
- draw.io
|
||
- ProcessOn
|
||
- Mermaid (Markdown)
|
||
|
||
### 数据分析
|
||
- Metabase
|
||
- Google Analytics
|
||
- Mixpanel
|
||
|
||
### 项目管理
|
||
- ai-proj (内部)
|
||
- JIRA
|
||
- Linear
|
||
|
||
---
|
||
|
||
## 最佳实践
|
||
|
||
1. **需求先行** - 先理解问题，再设计方案
|
||
2. **用户视角** - 始终从用户角度思考
|
||
3. **数据驱动** - 用数据验证假设
|
||
4. **迭代优化** - 小步快跑，持续改进
|
||
5. **跨团队协作** - 早期与技术、设计团队对齐
|
||
6. **文档沉淀** - 及时记录决策和变更
|
||
|
||
---
|
||
|
||
## 安全与合规
|
||
|
||
- 用户隐私保护 (GDPR/个人信息保护法)
|
||
- 数据安全分级
|
||
- 敏感操作审计
|
||
- 权限最小化原则
|
||
|
||
---
|
||
|
||
## PRD 评审方法论
|
||
|
||
PRD 评审是需求流程的关键质量关卡。
|
||
|
||
### 评审流程
|
||
|
||
```
|
||
PRD 提交 → 结构检查 → 清晰度评估 → 技术可行性 → 数据模型 → API 审查 → 结论
|
||
```
|
||
|
||
### 结构完整性检查
|
||
|
||
| 检查项 | 必须 | 说明 |
|
||
|--------|:----:|------|
|
||
| 基本信息 | ✓ | 编号、标题、日期、作者 |
|
||
| 需求背景 | ✓ | 为什么需要这个功能 |
|
||
| 目标用户 | ✓ | 面向的用户群体 |
|
||
| 功能描述 | ✓ | 详细功能需求 |
|
||
| 数据模型 | ✓ | 数据库表结构 |
|
||
| API 设计 | ✓ | RESTful 接口 |
|
||
| 验收标准 | ✓ | 验收条件 |
|
||
| 用户故事 | ○ | As a... I want... |
|
||
| 页面原型 | ○ | 界面布局 |
|
||
| 非功能需求 | ○ | 性能、安全 |
|
||
|
||
### 需求清晰度（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 评审通过
|
||
|
||
【结论】文档完整，需求清晰，方案可行，建议批准。
|
||
【肯定】需求背景清晰、数据模型合理、API 规范
|
||
【建议】（非阻塞）补充性能测试用例
|
||
【评审人】xxx 【时间】2026-xx-xx
|
||
```
|
||
|
||
**驳回**：
|
||
```
|
||
❌ PRD 评审驳回
|
||
|
||
【原因】
|
||
1. 数据模型缺少索引
|
||
2. API 缺少错误处理
|
||
3. 搜索需求描述模糊
|
||
|
||
【修改要求】
|
||
□ 补充索引设计
|
||
□ 明确错误码
|
||
□ 细化搜索实现
|
||
|
||
【驳回人】xxx 【时间】2026-xx-xx
|
||
```
|
||
|
||
### 常见驳回原因
|
||
|
||
| 类别 | 问题 | 建议 |
|
||
|------|------|------|
|
||
| 结构缺失 | 缺数据模型或 API | 补充技术设计 |
|
||
| 需求模糊 | 描述不具体 | 按 SMART 重写 |
|
||
| 边界不清 | 缺异常处理 | 补充边界条件 |
|
||
| 设计缺陷 | 模型/API 不合理 | 重新设计 |
|
||
| 范围过大 | 难以实现 | 拆分为多需求 |
|
||
| 验收不明 | 缺验收标准 | 补充验收条件 |
|