/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. 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. 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. 1. 匹配知识库中的数据流骨架

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

1. 2. 根据用户选择调整数据流

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

1. 3. 推导跨领域数据流

- 识别领域间的依赖关系 - 定义数据契约

【数据流推导示例】

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

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

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

【跨领域数据流示例】

订单 + 积分领域交叉：

| 数据流 | 起点领域 | 终点