/gen-prd - PRD 生成技能

技能 ID: gen-prd 技能名称: PRD 生成技能 版本: 2.0.1 描述: 基于领域知识库进行交互式需求分析，生成包含完整数据流的 PRD 文档

触发条件

• /gen-prd
• /prd
• 生成 PRD
• 生成需求文档

技能边界（防止误触发）

• 本技能仅当用户要「生成 PRD / 需求文档 / 需求分析」时触发。
• 不得在以下场景触发本技能：用户要「分析现有代码库」「分析项目结构」→ 应使用 analyze。

前置条件

• 用户已提供需求描述
• 领域知识库已准备就绪（skills/libs/domain-knowledge/）

核心增强：领域知识库驱动

本技能基于领域知识库（skills/libs/domain-knowledge/）进行增强，实现：

1. 领域识别与知识库加载 — 自动识别需求涉及领域，加载对应知识库
2. 结构化提问 — 基于知识库中的业务场景、核心实体、业务规则生成问题
3. 数据流推导 — 引用知识库中的典型数据流骨架，快速推导完整数据流
4. 反向验证 — 数据流逐条确认，AI 补充缺失环节

技能行为

阶段一：领域识别与知识库加载

分析用户需求描述，识别涉及领域并加载知识库：

【领域识别规则】

| 领域 | 核心关键词 | 关联关键词 | 知识库文件 |
|------|-----------|-----------|-----------|
| 积分 | 积分、积分系统、积分兑换、积分抵扣 | 签到、积分商城、会员积分 | domain-knowledge/points.md |
| 用户中心 | 用户、登录、注册、认证、权限 | 账号、密码、授权、SSO | domain-knowledge/user-center.md |
| 电商 | 商品、库存、购物车、电商、商城 | SKU、SPU、类目、品牌 | domain-knowledge/ecommerce.md |
| 订单 | 订单、下单、购物、交易 | 订单状态、履约、售后 | domain-knowledge/order.md |
| 支付 | 支付、退款、微信支付、支付宝 | 收银台、支付回调、对账 | domain-knowledge/payment.md |

【多领域识别】

当识别到多个领域时，按以下规则处理：
1. 确定主领域（用户描述的核心功能）
2. 确定关联领域（依赖或被依赖）
3. 按依赖顺序加载知识库：用户中心 → 电商 → 订单 → 支付 → 积分

【识别结果确认】

"根据您的需求描述，我识别到以下领域：

• 主领域：{领域名称}
• 关联领域：{领域列表}

是否正确？
A) 确认正确
B) 需要调整（请说明）
C) 暂不加载知识库"

阶段二：结构化提问（基于知识库）

基于加载的领域知识库，生成结构化问题：

【提问类型 1：业务场景提问】（必问）

来源：知识库「典型业务场景」表格
模板："您的{领域名称}需要支持哪些功能场景？（可多选）"

示例（积分领域）：
"您的积分系统需要支持哪些功能场景？（可多选）"
A) 签到得积分
B) 消费返积分
C) 邀请得积分
D) 任务得积分
E) 积分兑换商品
F) 积分抵扣订单
G) 积分过期处理
H) 其他（请说明）

【提问类型 2：核心实体提问】（按需追问）

来源：知识库「核心实体」表格
模板："关于{实体名称}，需要支持以下哪些能力？"

示例（积分账户）：
"关于积分账户，需要支持以下哪些能力？"
A) 单一账户（所有积分统一管理）
B) 多类型账户（不同来源积分分账户管理）
C) 积分冻结/解冻
D) 积分转赠
E) 以上都不需要

【提问类型 3：业务规则提问】（按需确认）

来源：知识库「业务规则模板」章节
模板："关于{规则名称}，请确认您的业务规则："

示例（积分过期规则）：
"关于积分过期，请确认您的业务规则："
A) 永不过期
B) 固定有效期（获得后 N 天过期）
C) 滚动有效期（每次使用后续期）
D) 年底清零
E) 按批次过期（先进先出）

【提问类型 4：集成点提问】（跨领域场景）

来源：知识库「常见集成点」章节
模板："您的{领域名称}需要与哪些系统对接？"

示例（积分系统集成）：
"您的积分系统需要与哪些系统对接？（可多选）"
A) 用户系统（获取用户信息）
B) 订单系统（消费返积分、积分抵扣）
C) 支付系统（支付成功触发积分）
D) 消息系统（积分变动通知）
E) 暂无对接需求

【提问数量控制】
- 必问问题：3-5 个（业务场景、目标用户、核心功能）
- 按需追问：2-3 个（根据用户选择追问）
- 单次提问：最多 5 个选项
- 总提问轮次：控制在 3-5 轮

阶段三：需求总结与技术栈推荐

【需求总结】

根据您的需求，我理解这是一个【系统类型】：

**核心功能**：
- 功能 1
- 功能 2
- 功能 3

**目标用户**：【用户类型】

**预期规模**：日活 X 万

**涉及领域**：{基于识别结果}

**集成需求**：{基于用户选择}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【技术栈推荐】

基于您的需求，我推荐以下技术栈方案：

**前端**：Vue 3 + Ant Design Vue
- 组件库丰富，开发效率高
- 适合企业级应用和中后台系统
- 与后端集成简单

**后端**：Spring Boot 3 + MyBatis-Plus
- 成熟稳定，生态完善
- 开发效率高，易于维护
- 支持快速迭代

【根据场景推荐】
- 如需 AI 能力：LangChain4j + LangGraph4j
- 如用户规模>10 万：Spring Cloud 微服务
- 如需实时通信：WebSocket + Redis

**数据库**：MySQL 8.0 + Redis
- MySQL：主从复制，读写分离
- Redis：缓存热点数据

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**请确认技术栈方案**：
A) 采用推荐方案
B) 调整技术栈（请说明）
C) 使用其他技术栈（请说明）

确认后我将进行数据流推导。

阶段四：数据流推导（基于知识库）

【数据流推导规则】

1. 匹配知识库中的数据流骨架
   - 从知识库「典型数据流骨架」章节匹配相关数据流
   - 根据用户选择的业务场景，选择对应数据流

2. 根据用户选择调整数据流
   - 保留数据流的骨架结构
   - 根据用户选择调整处理步骤

3. 推导跨领域数据流
   - 识别领域间的依赖关系
   - 定义数据契约

【数据流推导示例】

用户选择：签到得积分 + 连续签到奖励

原始数据流（来自积分知识库）：
┌─────────────────────────────────────────────┐
│ 数据流：签到获取积分                          │
│ 起点：用户签到请求                            │
│ 处理：校验→计算积分→入账→记录流水            │
│ 终点：更新账户余额                            │
│ 触发条件：每日首次签到                        │
└─────────────────────────────────────────────┘

调整后数据流：
┌─────────────────────────────────────────────┐
│ 数据流：签到获取积分（含连续签到奖励）        │
│ 起点：用户签到请求                            │
│ 处理：                                        │
│   1. 校验今日是否已签到                       │
│   2. 计算基础积分（10 积分）                  │
│   3. 计算连续签到奖励                         │
│      - 连续 7 天：+5 积分                    │
│      - 连续 30 天：+20 积分                  │
│   4. 积分入账                                 │
│   5. 记录流水（含过期时间）                   │
│   6. 更新连续签到天数                         │
│ 终点：更新账户余额                            │
│ 触发条件：每日首次签到                        │
└─────────────────────────────────────────────┘

【跨领域数据流示例】

订单 + 积分领域交叉：

| 数据流 | 起点领域 | 终点领域 | 数据内容 | 触发条件 |
|--------|---------|---------|---------|---------|
| 消费返积分 | 订单 | 积分 | 订单ID、用户ID、订单金额 | 订单支付成功 |
| 积分抵扣 | 积分 | 订单 | 用户ID、使用积分、抵扣金额 | 用户下单使用积分 |
| 积分撤销 | 订单 | 积分 | 订单ID、用户ID | 订单退款 |

阶段五：数据流反向验证

【数据流清单展示】

"根据您的需求，我梳理了以下核心数据流：

| 序号 | 数据流名称 | 起点 | 终点 | 触发条件 | 是否闭环 |
|------|-----------|------|------|---------|---------|
| 1 | 签到获取积分 | 用户签到 | 更新账户余额 | 每日首次签到 | ✓ |
| 2 | 消费返积分 | 订单支付成功 | 更新账户余额 | 订单支付回调 | ✓ |
| 3 | 积分兑换商品 | 用户兑换请求 | 更新账户余额 | 用户主动兑换 | ✓ |
| 4 | 积分过期处理 | 定时任务 | 更新账户余额 | 每日凌晨 | ✓ |
| ... | ... | ... | ... | ... | ... |

【逐条确认】

逐条展示数据流详情，请用户确认：

"【数据流 1：签到获取积分】

起点：用户签到请求
输入：userId, signInDate
处理流程：
  1. 校验今日是否已签到
  2. 计算基础积分（10 积分）
  3. 计算连续签到奖励
  4. 积分入账
  5. 记录流水（含过期时间）
输出：availablePoints + N
终点：更新账户余额
异常处理：已签到则提示"今日已签到"

请确认：
A) 确认正确
B) 需要调整（请说明）
C) 不需要这个数据流"

【缺失环节检测】

检测规则：
1. 用户选择的功能是否有对应数据流
2. 跨领域交互是否有数据流
3. 异常场景是否有数据流

"检测到您选择了'积分过期处理'，但尚未梳理对应数据流。是否需要补充？
A) 补充该数据流
B) 暂时不需要"

【完成确认】

所有数据流确认后：
"数据流梳理完成！共梳理 X 条数据流，已形成闭环。

是否继续生成 PRD 文档？
A) 继续生成 PRD
B) 还需要调整数据流"

阶段六：生成 PRD 文档

写入强制规范（空仓库 / 新项目 P0，执行前必读）

1. 路径约定：默认输出 docs/prd/YYYY-MM-DD-{project-name}.md（或用户指定的 --output 路径）。父目录为 docs/prd/。
2. 先建目录再写文件：在写入任何文件之前，必须确保父目录存在。若 docs/ 或 docs/prd/ 不存在，必须先创建（例如在支持文件操作的环境中使用「创建目录」能力，等价于 mkdir -p docs/prd），禁止因目录不存在而仅在对话中展示 PRD 正文却不落盘。
3. 必须真实写入：完成澄清与内容生成后，必须将完整 PRD 写入上述 Markdown 文件；禁止仅用「正在生成…」话术代替实际文件创建。
4. 失败处理：若当前环境无法创建目录或写入文件，应明确告知用户「无法写入磁盘」并给出可手动创建的命令（如 mkdir -p docs/prd）与目标路径，而不是假装已生成。

正在生成 docs/prd/YYYY-MM-DD-{project-name}.md...

✅ PRD 已生成，包含：
- 项目背景与目标
- 功能列表（X 个核心功能，X 个辅助功能）
- **核心数据流与闭环**（X 条数据流，已验证闭环）
- 用户故事（X 个）
- 验收标准
- 非功能性需求（基于领域知识库约束条件）
- 推荐技术栈（已确认）

接下来可以进行系统设计，使用 `/gen-design` 开始。

**自动继续**：若本会话由 start 进入且平台支持技能链调用，应输出「即将为您执行 /gen-design；若需暂停请说「暂停」。」并**代为调用 gen-design**（传入本 PRD 路径）；否则输出「是否需要现在开始？」由用户确认后再执行。

领域知识库使用规范

知识库文件位置

skills/libs/domain-knowledge/
├── points.md          # 积分领域
├── user-center.md     # 用户中心领域
├── ecommerce.md       # 电商领域
├── order.md           # 订单领域
└── payment.md         # 支付领域

知识库使用方式

技术栈推荐规则

默认推荐（擅长技术栈）

**前端**：
- 框架：Vue 3.x（组合式 API）
- UI 库：Ant Design Vue 4.x
- 状态管理：Pinia
- 路由：Vue Router 4.x
- HTTP 客户端：Axios

**后端**：
- 框架：Spring Boot 3.x
- ORM：MyBatis-Plus 3.5.x
- 安全：Spring Security + JWT
- 文档：Knife4j（Swagger 3）
- 工具：Lombok, Hutool

**数据库**：
- 关系型：MySQL 8.0
- 缓存：Redis 6.x
- 搜索引擎：Elasticsearch（可选）

**部署**：
- 容器：Docker
- 编排：Kubernetes（大规模）
- CI/CD：Jenkins/GitLab CI

技术栈选择决策树

需求分析 → 技术栈推荐

1. 用户规模？
   - <1 万 → 单体架构（Spring Boot）
   - 1-10 万 → 单体 + 读写分离
   - >10 万 → 微服务（Spring Cloud）

2. 是否需要 AI 能力？
   - 是 → LangChain4j + LangGraph4j
   - 否 → 标准技术栈

3. 前端类型？
   - 企业级/中后台 → Vue 3 + Ant Design
   - C 端/H5 → Vue 3 + Vant
   - 复杂交互 → React + Ant Design

4. 特殊需求？
   - 实时通信 → WebSocket
   - 大数据 → Elasticsearch
   - 高并发 → Redis 集群

PRD 文档模板

详见 templates/prd-template.md

核心章节「核心数据流与闭环」必须包含：

## 5. 核心数据流与闭环（必填）

### 5.1 数据流清单

| 数据流编号 | 数据流名称 | 起点 | 终点 | 经手模块/服务 | 是否闭环 |
|------------|------------|------|------|---------------|----------|
| DF-001 | {名称} | {起点} | {终点} | {模块} | 是/否 |

### 5.2 数据流详情

#### DF-001：{数据流名称}

- **起点**：{触发条件}
- **输入**：{输入数据}
- **处理流程**：
  1. ...
  2. ...
- **输出**：{输出数据}
- **终点**：{结束状态}
- **异常处理**：{异常场景}

### 5.3 数据闭环验证

| 闭环 | 起始数据 | 终止数据 | 验证结果 |
|------|---------|---------|---------|
| {名称} | {起始} | {终止} | ✓ 已闭环 |

输出文件

docs/prd/YYYY-MM-DD-{project-name}.md

目录与写入：见上文「阶段六」—— 写入前必须保证 docs/prd 存在，且必须将文件写入磁盘。通用约定汇总见 SKILLS-FILE-OUTPUT.md。

示例对话

示例：积分系统（多领域交叉）

用户：/gen-prd 我要做一个电商积分系统

AI: 分析您的需求描述，我识别到以下领域：

    • 主领域：积分系统
    • 关联领域：用户中心、订单、支付

    是否正确？
    A) 确认正确
    B) 需要调整

用户：A

AI: 好的，已加载积分、用户中心、订单、支付领域知识库。

    让我了解一些关键信息：

    1. 目标用户是谁？
       A) 企业内部员工
       B) C 端消费者
       C) B 端商家

    2. 您的积分系统需要支持哪些功能场景？（可多选）
       A) 签到得积分
       B) 消费返积分
       C) 邀请得积分
       D) 任务得积分
       E) 积分兑换商品
       F) 积分抵扣订单
       G) 积分过期处理
       H) 其他（请说明）

    3. 关于积分过期，请确认您的业务规则：
       A) 永不过期
       B) 固定有效期（获得后 N 天过期）
       C) 滚动有效期（每次使用后续期）
       D) 年底清零

    4. 您的积分系统需要与哪些系统对接？（可多选）
       A) 用户系统（获取用户信息）
       B) 订单系统（消费返积分、积分抵扣）
       C) 支付系统（支付成功触发积分）
       D) 消息系统（积分变动通知）
       E) 暂无对接需求

    5. 预期用户规模？
       A) 日活<1 万
       B) 日活 1-10 万
       C) 日活>10 万

用户：1-B, 2-ABEFG, 3-B（有效期1年）, 4-ABCD, 5-B

AI: 根据您的需求，我理解这是一个面向 C 端消费者的电商积分系统：

    **核心功能**：
    - 签到得积分
    - 消费返积分
    - 积分兑换商品
    - 积分抵扣订单
    - 积分过期处理（有效期1年）

    **集成需求**：
    - 用户系统：获取用户信息
    - 订单系统：消费返积分、积分抵扣
    - 支付系统：支付成功触发积分
    - 消息系统：积分变动通知

    **预期规模**：日活 1-10 万

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

    **推荐技术栈**：...（略）

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

    **请确认技术栈方案**：
    A) 采用推荐方案
    B) 调整技术栈

用户：A

AI: 现在进行数据流推导...

    根据您的需求，我梳理了以下核心数据流：

    | 序号 | 数据流名称 | 起点 | 终点 | 触发条件 | 闭环 |
    |------|-----------|------|------|---------|------|
    | 1 | 签到获取积分 | 用户签到 | 更新账户余额 | 每日首次签到 | ✓ |
    | 2 | 消费返积分 | 订单支付成功 | 更新账户余额 | 订单支付回调 | ✓ |
    | 3 | 积分兑换商品 | 用户兑换请求 | 更新账户余额 | 用户主动兑换 | ✓ |
    | 4 | 积分抵扣订单 | 用户下单 | 更新账户余额 | 用户选择积分支付 | ✓ |
    | 5 | 积分过期处理 | 定时任务 | 更新账户余额 | 每日凌晨 | ✓ |
    | 6 | 订单退款积分撤销 | 订单退款 | 更新账户余额 | 订单退款回调 | ✓ |

    【数据流 1：签到获取积分】

    起点：用户签到请求
    输入：userId, signInDate
    处理流程：
      1. 校验今日是否已签到
      2. 计算基础积分（10 积分）
      3. 积分入账
      4. 记录流水（过期时间：1年后）
    输出：availablePoints + N
    终点：更新账户余额

    请确认：
    A) 确认正确
    B) 需要调整（请说明）
    C) 跳过确认，直接生成 PRD

用户：C

AI: 正在生成 docs/prd/2026-03-02-ecommerce-points-system.md...

    ✅ PRD 已生成，包含：
    - 项目背景与目标
    - 功能列表（5 个核心功能，3 个辅助功能）
    - **核心数据流与闭环**（6 条数据流，已验证闭环）
    - 用户故事（12 个）
    - 验收标准
    - 非功能性需求（含积分领域约束条件）
    - 推荐技术栈（已确认）

    接下来可以进行系统设计，使用 `/gen-design` 开始。
    是否需要现在开始？

相关技能

• start: 入口技能，本技能的前置技能
• gen-design: 系统设计，本技能的后续技能
• gen-coding-specs: 在 gen-code 之前生成 docs/coding-specs/（建议在 gen-design 与 validate 之后执行，见 SKILL-VALUE-CHAIN.md）
• domain-knowledge: 领域知识库，本技能的知识来源

版本历史

本技能是 AI Speckits 技能体系的需求分析阶段，基于领域知识库增强。