Files
ai-proj-helper/skills-req/req-prd-plugin/skills/SKILL.md
John Qiu 712063071c refactor: 通用技能按类别拆分为独立目录
skills/ → skills-dev(9), skills-req(10), skills-ops(4),
skills-integration(8), skills-biz(4), skills-workflow(7)

generate-marketplace.py 改为自动扫描所有 skills-* 目录。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-14 11:31:58 +10:30

14 KiB
Raw Blame History

name, description
name description
req-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 模板

# [功能模块名称] 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 数据模型(目标系统)

-- 目标系统表结构(基于对比分析设计)
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. 后端代码分析

# 搜索相关模型
grep -r "class.*Model" --include="*.java" /path/to/legacy/

# 搜索相关控制器
grep -r "@Controller\|@RestController" --include="*.java" /path/to/legacy/

3. 数据库分析

-- 查看表结构
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

数据模型

-- 酷采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 结构

# [产品/功能名称] 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 工具管理需求:

# 创建需求
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_requirementapprove/reject_requirement
  3. 分解任务create_task / create_subtask
  4. 关联任务link_tasks_to_requirement
  5. 跟踪进度get_requirement_tasks / get_requirement_statistics

文档管理

# 创建 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. 评审验证

评审维度:
- 业务价值
- 技术可行性
- 资源评估
- 风险评估

输出:
- 评审结论
- 修改意见

竞品分析模板

分析框架

# [竞品名称] 分析

## 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/个人信息保护法)
  • 数据安全分级
  • 敏感操作审计
  • 权限最小化原则