ai-proj-helper/skills-req/req-prd-plugin/skills/SKILL.md

name, description

name	description
req-prd	产品设计与需求管理。用于 PRD 文档编写、需求分析、用户故事创建、功能设计和原型规划。当用户提到产品设计、PRD、需求文档、功能规划、用户故事相关任务时自动激活。

产品需求设计 Skill (req-prd)

概述

本技能用于辅助产品设计和需求管理工作，包括：

• PRD 文档编写与管理
• 需求分析与优先级排序
• 用户故事创建
• 功能设计与规划
• 与 ai-proj 任务系统集成

插件扩展：

• req-compare — 对比式 PRD 编写（系统平移/竞品借鉴时激活）
• req-prototype — UI 原型生成

客户原话原则（REQ-20260416-0017 P1-8）

编写 PRD 时必须包含「客户原始诉求」章节（模板 1.4），保留客户/业务方原话，不做 AI 加工。

为什么：

• 产品经理转述会失真（借鉴自 devflow-claude 的"客户场景"设计）
• 后续争议追溯时有据可查
• 团队成员看到原话能建立同理心

填写规范：

• 原话用 Markdown > 引用块 包裹，区分于 AI 加工内容
• 标注提出人、时间、出处（会议/邮件/聊天）
• 特殊约束（时间/合规/预算）必须保留

---

对比式 PRD 编写

系统平移、竞品借鉴、版本升级时，使用 req-compare 插件进行对比分析。 该插件包含完整的对比工作流、对比式 PRD 模板和竞品分析模板。

触发方式：当需求涉及参考系统时，req-prd 自动推荐激活 req-compare 插件。

---

PRD 文档模板

标准 PRD 结构

# [产品/功能名称] PRD

## 1. 概述
### 1.1 背景
[为什么需要这个功能？解决什么问题？]

### 1.2 目标
- 业务目标：[量化的业务指标]
- 用户目标：[用户能获得什么价值]
- 技术目标：[技术层面要达成什么]

### 1.3 成功指标
| 指标 | 当前值 | 目标值 | 衡量方式 |
|------|--------|--------|----------|
| ... | ... | ... | ... |

### 1.4 客户原始诉求 ⭐ 强制保留

> **重要**：记录客户/业务方提出需求时的**原始描述**，**不做 AI 加工、不总结、不转述**。
> 保留原话是为了后续溯源"我们当初为什么做这个"有据可查，避免产品经理转述失真。

- **场景1**（提出人：xxx / 时间：yyyy-mm-dd）：
  > "原始描述引用..."
- **场景2**：
  > "原始描述引用..."

**补充信息**（可选）：
- 会议/邮件/聊天记录链接
- 客户特殊约束（如"必须在 Q2 前上线"）

## 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 界面原型

> 使用 `/req prototype [REQ-ID]` 基于 PRD 自动生成 Stitch 原型。
> 生成后截图将自动回填到此章节。

[执行 `/req prototype` 后自动填充]

## 5. 技术要求
### 5.1 性能要求
- 响应时间：
- 并发量：
- 数据量：

### 5.2 安全要求
- 权限控制：
- 数据安全：

### 5.3 兼容性要求
- 浏览器：
- 设备：

## 6. 上线计划
### 6.1 里程碑
| 阶段 | 内容 | 完成标准 |
|------|------|----------|
| ... | ... | ... |

### 6.2 灰度策略
[灰度发布计划]

## 7. 验收标准 ⭐ 强制包含 VP 三件套

> **规则（源自 REQ-20260421-0002）**：每条 AC 必须附带 VP-Data / VP-Steps / VP-Pass，缺一项评审不通过。

### AC1: [验收条件标题]

**目标**：[一句话描述期望结果]

**VP-Data（前置测试数据）**：
- 环境：localhost / production（二选一，明确注明）
- 数据：[字段、值、状态，例如：需求状态=approved，关联任务 3 个，task_project_id 非空]
- 建数据方式：[curl localhost:8080/... 或 MCP 工具，禁止混用]

**VP-Steps（验证步骤）**：
1. [工具 + 操作，例如：agent-browser open http://localhost:3000/xxx]
2. [检查指标，例如：eval `document.querySelector('.xxx').textContent`]
3. [确认值，例如：返回值包含"期望字符串"]

**VP-Pass（通过判定）**：
- ✅ [具体期望值，例如：eval 返回数组长度 = 3]
- ✅ [第二个判定条件]
- ❌ [明确的不通过条件，例如：仅靠代码分析得出结论 = 不通过]

---

### AC2: [第二条验收条件]

**目标**：...

**VP-Data**：...

**VP-Steps**：...

**VP-Pass**：
- ✅ ...
- ❌ ...

## 8. 风险评估
| 风险 | 影响 | 概率 | 应对措施 |
|------|------|------|----------|
| ... | 高/中/低 | 高/中/低 | ... |

## 9. 附录
- 相关文档链接
- 参考资料

---

需求优先级框架

RICE 评分法

维度	说明	评分范围
Reach (触达)	影响多少用户	1-10
Impact (影响)	对用户的影响程度	0.25-3
Confidence (信心)	估算的置信度	0-100%
Effort (工作量)	需要的人天数	实际工作量

计算公式: RICE = (Reach × Impact × Confidence) / Effort

优先级定义

优先级	含义	处理方式
P0	阻塞性需求	必须立即处理
P1	核心需求	本迭代必须完成
P2	重要需求	尽量本迭代完成
P3	优化需求	有余力时处理

---

需求粒度判断（REQ-20260416-0017 P1-12）

创建需求前，AI 必须先对标题做粒度预判。 借鉴 devflow-claude /req:split。

核心问题

"这个需求完成后，用户能感知到一个完整的功能变化吗？"

• 能 → 粒度合适
• 不能（太大或太小）→ 需调整

粒度参考表

标题示例	粒度	建议
"用户积分系统"（含规则+查询+兑换+排行）	太大	拆为 4 个需求
"用户积分-积分规则管理"（含 CRUD+校验）	合适	直接创建
"用户积分-新增积分接口"（仅一个 API）	太小	合并到功能级需求，或用任务（task）
"用户积分-新增 model 层"（按技术层拆）	错误	按功能拆，不按技术层拆

AI 自动检测规则

标题过宽信号（建议拆分）：

• 含"系统"/"模块"/"平台"/"管理"等宏观词
• 描述中功能点 > 5 个
• 预估涉及文件 > 15 个

标题过窄信号（建议合并或改 task）：

• 含"新增XX接口"/"修改XX字段"/"加一个按钮"
• 单个 CRUD 操作
• 预估涉及文件 ≤ 2 个

错误拆分信号（按技术层拆了）：

• 标题含"model 层"/"service 层"/"handler 层"/"前端样式"
• 同一业务被拆为"后端接口"和"前端页面"两个独立需求

执行时机

1. 创建需求时（/req new 或 create_requirement）：检查标题，给出建议
2. 编辑需求时：功能清单超 8 项时提醒"是否应拆分"
3. 独立评估：用 /req split <标题> 预判粒度

三种输出

1. 粒度合适 → 正常创建
2. 建议拆分 → 列出子功能建议，用户确认后批量创建
3. 建议改 task/QUICK → 提示"这个用任务更合适"

已有需求扩展功能的决策

"去掉这个新功能点，原需求还能独立交付吗？"

• 能 → 新建需求
• 不能 → 修改原需求（/req edit）

场景	建议
新功能是原需求的自然延伸	修改原需求
新功能可独立上线	新建需求
原需求已完成/归档	必须新建
原需求开发中，新增会影响已有代码	新建（防范围蔓延）

前后端拆分规则

✅ 正确:
  REQ-001 用户积分规则管理-后端（含 CRUD 全部接口）
  REQ-002 用户积分规则管理-前端（含 CRUD 全部页面）

❌ 错误:
  REQ-001 用户积分规则-新增接口
  REQ-002 用户积分规则-查询接口
  REQ-003 用户积分规则-修改接口

---

用户故事编写

标准格式

作为 [用户角色]，
我想要 [功能/目标]，
以便 [获得的价值/原因]。

验收标准：
- 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_requirement → approve/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. 评审验证

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

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

---

竞品分析

竞品分析模板已移至 req-compare 插件。涉及竞品对比时自动激活。

---

产品指标体系

北极星指标选择

产品类型	典型北极星指标
电商	GMV / 订单量
SaaS	MRR / 活跃用户数
社交	DAU / 消息数
工具	完成任务数 / 使用时长

指标分层

北极星指标
    ├── 一级指标（核心业务指标）
    │   ├── 二级指标（过程指标）
    │   │   └── 三级指标（功能指标）

常用指标

类型	指标	计算方式
获客	新用户数、获客成本	注册数 / 推广费用
激活	激活率、首日留存	完成核心动作 / 注册数
留存	次日/7日/30日留存	回访用户 / 新增用户
收入	ARPU、付费率	收入 / 用户数
传播	推荐率、K因子	邀请数 / 用户数

---

设计检查清单

PRD 完整性检查

• 背景与目标明确
• 用户群体定义清晰
• 功能需求完整
• 验收标准可测试（每条 AC 附带 VP-Data / VP-Steps / VP-Pass）
• 异常情况已考虑
• 性能要求已定义
• 上线计划合理
• 风险已评估

交互设计检查

• 用户流程完整
• 边界情况处理
• 错误提示友好
• 反馈及时
• 操作可撤销
• 符合用户习惯

非功能需求检查

• 性能要求已量化（响应时间、并发量）
• 安全需求已明确（权限、数据保护）
• 兼容性要求已定义（浏览器、设备）
• 可用性目标已设定

技术方案可行性检查在 design 阶段由 req-design 技能完成。

---

常用工具

原型设计

• Stitch (Google AI) — 集成在 /req prototype，自动从 PRD 生成原型
• Figma — 手动精细设计
• Sketch
• Axure

流程图

• draw.io
• ProcessOn
• Mermaid (Markdown)

数据分析

• Metabase
• Google Analytics
• Mixpanel

项目管理

• ai-proj (内部)
• JIRA
• Linear

---

最佳实践

1. 需求先行 - 先理解问题，再设计方案
2. 用户视角 - 始终从用户角度思考
3. 数据驱动 - 用数据验证假设
4. 迭代优化 - 小步快跑，持续改进
5. 跨团队协作 - 早期与技术、设计团队对齐
6. 文档沉淀 - 及时记录决策和变更

---

安全与合规

• 用户隐私保护 (GDPR/个人信息保护法)
• 数据安全分级
• 敏感操作审计
• 权限最小化原则

---

Memory 隔离规则（强制，源自 devflow-claude 借鉴）

规则：本 skill 涉及模板/文档产出的命令禁止受 auto-memory 影响产出物。

禁止行为

1. 不得根据 memory 中的偏好跳过或合并 PRD 模板章节
2. 不得用 memory 里的历史需求/项目内容填充当前 PRD
3. 不得根据 memory 反馈调整 PRD 章节顺序、表格列数、标题层级
4. 不得读取 ~/.claude/projects/*/memory/ 辅助生成 PRD 正文

允许行为

• memory 可影响交互风格（提问详略、确认节奏、语气）
• memory 可指导命令选择（如根据用户习惯推荐先走 req-compare 还是 req-prd）
• memory 可影响非产出文本（如对话中的说明）

Why

auto-memory 设计用于跨会话建立用户画像。但 PRD/需求文档是正式产出物，必须由模板结构 + 当前输入决定，不能因 memory 中的偏好自作主张调整结构，否则会导致：

• 模板章节漂移（用户不知道为什么这次少了一章）
• 历史项目内容污染（张冠李戴）
• 产出不可复现

How to apply

执行 /req prd / PRD 编写 / 需求描述生成等命令时：

• 仅读取：模板文件、用户当前输入、引用的已有需求文档
• 不读取：memory 目录下的任何文件
• 产出前自检：章节数量和顺序与模板完全一致

参考：devflow-claude 的 plugins/req/commands/_common.md 同名规则。