---
name: prd-business-unit
description: 根据用户描述的业务场景，生成完整的企业级 PRD 文档，并为每个业务单元生成可在浏览器中打开的 HTML 交互原型页面。PRD 包含：文档背景与目标、角色权限、业务流程总览（多层级业务单元的流转关系与触发条件）、每个业务单元的详细规格（输入/输出/步骤/业务规则/异常处理），以及每个业务单元对应的系统页面交互要求（含 ASCII 线框图、字段规格、操作逻辑、状态流转）。当用户提到"写PRD"、"需求文档"、"业务单元"、"业务流程"、"审批流"、"操作流程"、"帮我整理需求"、"画原型"、或者描述一个或多个角色在系统中协作完成某项业务目标时，请主动使用此 skill。即使用户没有明确提到 PRD，只要他们在描述业务场景、系统需求、或流程设计，就应触发此 skill。
---

# PRD 文档生成（业务单元驱动）

你的任务是将用户描述的业务场景整理成一份结构清晰、内容可落地的 PRD 文档，**并为每个业务单元生成对应的 HTML 交互原型页面**。

PRD 围绕**业务单元**组织——"某个角色在某个时间点，基于特定输入，完成一项具体业务动作，产出标准输出"。一个 PRD 通常包含多个业务单元，业务单元之间有层级关系和流转关系。

---

## 第一步：信息收集

动手之前确认以下信息（描述中已有的无需追问）：

1. **业务单元数量与层级**：涉及几个业务单元？是平级流程节点，还是有主流程/子流程之分？
2. **参与角色**：谁参与了这个流程？各自负责哪些环节？
3. **分支判断**：流程中是否有条件分支（如审批通过/驳回）？
4. **系统范围**：涉及哪些系统或应用？
5. **特殊规则**：是否有金额上限、时效要求、合规约束等业务规则？
6. **输出目录**：询问用户希望把文件保存到哪个目录，默认保存到当前目录下的 `prd-output/` 文件夹。

---

## 第二步：输出 PRD 文档（Markdown）

将完整 PRD 保存为 `prd-output/PRD_[流程名称].md`，按以下章节结构输出。

---

### 第一章：文档背景

```
## 一、文档背景

### 1.1 项目背景
[说明业务背景：当前存在什么问题或诉求，为什么要做这件事]

### 1.2 目标与范围
**目标**：[本次 PRD 要解决的核心问题，1-3条]
**范围**：[覆盖的业务范围；明确不在范围内的内容]

### 1.3 术语说明
| 术语 | 说明 |
|------|------|
| [术语] | [定义] |
```

---

### 第二章：角色与权限

```
## 二、角色与权限

| 角色名称 | 职责描述 | 主要操作权限 |
|----------|----------|--------------|
| [角色名] | [该角色在本流程中的职责] | [可执行的操作] |
```

---

### 第三章：业务流程总览

#### 3.1 业务单元层级结构

一个 PRD 中的业务单元按三层组织：

```
L1 业务流程（整体流程名称）
 ├── L2 业务单元组（按角色或阶段分组）
 │    ├── L3 业务单元（具体操作节点，动词+名词）
 │    └── L3 业务单元
 └── L2 业务单元组
      └── L3 业务单元
```

**输出格式**：

```
## 三、业务流程总览

### 3.1 层级结构

**L1 流程**：[流程名称] — [一句话目标]

| 层级 | 编号 | 名称 | 负责角色 | 节点类型 |
|------|------|------|----------|----------|
| L2 | 1 | [阶段名称] | — | — |
| L3 | 1.1 | [业务单元名称] | [角色] | 开始节点 |
| L3 | 1.2 | [业务单元名称] | [角色] | 中间节点 |
| L2 | 2 | [阶段名称] | — | — |
| L3 | 2.1 | [业务单元名称] | [角色] | 中间节点 |
| L3 | 2.2 | [业务单元名称] | [角色] | 结束节点 |
```

> L2 是逻辑分组，L3 才是实际的业务单元。流程不超过4个业务单元时，L2 层可省略。

#### 3.2 流程图

```
[角色A] ──► 1.1 [业务单元名称]（开始节点）
                  │
                  │ 触发条件：[提交后自动流转给…]
                  ▼
[角色B] ──► 1.2 [业务单元名称]
                  │
                  ├─ [条件A：审批通过] ──► 2.1 [业务单元名称]
                  └─ [条件B：审批驳回] ──► 返回 1.1（修改后重新提交）
[角色C] ──► 2.1 [业务单元名称]（结束节点）
```

---

### 第四章：业务单元详情

每个 L3 业务单元独立输出一节，L2 分组作为小标题分隔。每节末尾注明对应的 HTML 原型文件名。

````
## 四、业务单元详情

---
## [L2编号] [L2分组名称]
---

### [L3编号] [业务单元名称（动词+名词）]

#### 基本信息

| 字段 | 内容 |
|------|------|
| **业务单元名称** | [动词+名词] |
| **业务单元描述** | [1-2句话，说明核心工作内容和业务价值] |
| **节点类型** | [开始节点 / 中间节点 / 结束节点] |
| **负责角色** | [角色名称] |
| **触发条件** | [来自哪个上游单元、满足什么条件、由谁触发] |
| **输入** | [输入物1；输入物2] |
| **输出** | [输出物1；输出物2] |
| **流转规则** | [完成后流转到哪；若有分支，分别说明各分支条件] |

#### 步骤说明

| 步骤 | 步骤名称 | 简要说明 |
|------|----------|----------|
| 步骤1 | [步骤名] | [简要说明] |
| 步骤2 | [步骤名] | [简要说明] |

#### 业务规则

**步骤1**：[进入条件 + 数据来源 + 处理逻辑]
**步骤2**：[数据来源 + 处理规则 + 输出去向]

**异常处理**：
- [异常情况]：[处理方式及责任人]

#### 页面交互要求

**对应页面**：[页面名称]

**页面线框图**：

```
┌─────────────────────────────────────────────────┐
│  [页面标题]              [单据编号]  [状态标签]  │
├─────────────────────────────────────────────────┤
│  ◉ 步骤1  ──  ○ 步骤2  ──  ○ 步骤3              │
├─────────────────────────────────────────────────┤
│  ┌── 基本信息 ──────────────────────────────┐   │
│  │  字段A：[输入]    字段B：[下拉▼]         │   │
│  └──────────────────────────────────────────┘   │
├─────────────────────────────────────────────────┤
│         [取消]    [保存草稿]    【提 交】         │
└─────────────────────────────────────────────────┘
```

**字段规格**：

| 字段名 | 控件类型 | 是否必填 | 数据来源/默认值 | 校验规则 |
|--------|----------|----------|-----------------|----------|
| [字段名] | [输入框/下拉/日期/数字/文件上传/只读] | 是/否 | [来源说明] | [校验规则] |

**操作逻辑**：
- **[操作名]**：
  1. 前置校验：[校验项]
  2. 校验通过：[执行动作]
  3. 执行结果：[状态变更；通知对象]
  4. 失败反馈：[报错文案]

**状态流转**：

| 当前状态 | 触发操作 | 目标状态 | 操作角色 |
|----------|----------|----------|----------|
| [状态] | [操作] | [状态] | [角色] |

**系统提示**：
- 成功：[提示文案]
- 错误：[触发条件 + 提示文案]

> 📄 对应 HTML 原型：`prototypes/[编号]-[页面名称].html`

#### 补充信息

| 字段 | 内容 |
|------|------|
| **标准文件** | [适用制度/规范] |
| **标准工时** | [预计耗时] |
| **使用系统** | [涉及的系统] |
| **交付标准** | 质量：[描述]<br>时效：[时效要求] |
| **能力要求** | [所需人员能力] |
| **所属业务流程** | [上层流程名称] |

---
````

---

## 第三步：为每个业务单元生成 HTML 原型

PRD Markdown 文件写完后，为每个 L3 业务单元生成一个独立的 HTML 原型文件，保存到 `prd-output/prototypes/` 目录下，文件名格式：`[编号]-[业务单元名称].html`（如 `1.1-提交费用报销单.html`）。

同时生成一个 `prd-output/prototypes/index.html` 作为所有原型的导航入口页。

### HTML 原型规范

**技术要求**：
- 纯 HTML + CSS + 原生 JavaScript，无需任何外部依赖，可直接用浏览器打开
- 使用中文界面，字体使用系统字体栈：`-apple-system, "PingFang SC", "Microsoft YaHei", sans-serif`
- 响应式布局，最小支持 1280px 宽度
- 配色使用企业中台风格：主色 `#1677ff`（蓝），背景 `#f5f5f5`，卡片背景 `#ffffff`，边框 `#d9d9d9`

**每个原型文件必须包含**：

1. **顶部导航栏**
   - 左侧：系统名称（来自用户描述，默认"业务管理系统"）
   - 中间：当前页面名称
   - 右侧：当前角色名称 + 头像占位符

2. **流程进度条**（如果该流程有多个节点）
   - 显示完整流程路径，当前节点高亮蓝色，已完成节点显示勾，未到达节点置灰

3. **页面主体内容**（根据业务单元类型选择布局）：

   **填写/申请类页面**：
   - 卡片式分区（基本信息区、明细列表区、附件区等）
   - 表单字段按字段规格渲染（输入框、下拉选择、日期选择器、数字输入、文件上传按钮）
   - 动态明细列表支持"添加行"和"删除行"交互
   - 必填字段用红色星号 `*` 标注
   - 底部金额汇总区（如有）

   **审批/复核类页面**：
   - 上半部分：申请内容只读展示（灰色背景区分）
   - 中间：完整审批意见区域（带上方审批历史时间线）
   - 下半部分：审批意见输入框 + 操作按钮

   **列表/工作台类页面**：
   - 顶部筛选条（状态筛选、日期筛选、关键词搜索）
   - 数据表格（带分页、操作列）
   - 状态标签用不同颜色区分（待处理=橙色、进行中=蓝色、已完成=绿色、已驳回=红色）

4. **底部固定操作栏**
   - 次要操作（取消、保存草稿）在左，主操作（提交、审批通过等）在右
   - 主操作按钮使用主色蓝，危险操作（驳回、删除）使用红色
   - 按钮点击后触发对应的模拟交互（弹出确认框、显示成功提示、表单校验等）

5. **交互行为**（用 JavaScript 实现）：
   - 表单必填校验：点击主操作按钮时，高亮未填写的必填字段，字段下方显示红色错误提示
   - 确认弹窗：重要操作（提交、审批通过、驳回）弹出模态框确认，显示关键信息摘要
   - 成功反馈：操作成功后顶部显示绿色 Toast 提示，3秒后消失
   - 动态明细：点击"添加行"插入新行，点击删除图标移除该行，自动重新编号
   - 金额联动：明细金额变化时，汇总金额实时更新

### index.html 导航页规范

导航页展示所有业务单元的卡片，每张卡片包含：
- 业务单元编号和名称
- 负责角色和节点类型（用不同颜色标签）
- 一句话描述
- "查看原型"按钮（跳转到对应 HTML 文件）

卡片按 L2 分组展示，每组有标题分隔。顶部显示流程名称和整体流程进度图（可点击跳转对应原型）。

---

## 写作标准

### 层级划分原则
- L2 按"阶段"或"角色域"来划：申请阶段、审批阶段、执行阶段
- L3 是最小可执行单元，命名用"动词+名词"，粒度为"一个角色、一次连贯操作、一个明确产出"
- 超过 8 个 L3 单元时，优先检查是否能合并

### 触发条件的写法
说清三件事：**来源**（哪个上游单元）、**条件**（无条件 or 满足X才触发）、**方式**（系统自动推送 or 人工进入）

### 业务规则的写法
围绕数据流，每条规则说清"从哪来 → 怎么处理 → 往哪去"：

❌ `审核申请内容`  
✅ `从报销单读取申请金额，与预算系统中部门当期可用余额对比；申请金额 ≤ 可用余额时可直接审批；超出时触发超预算提醒`

### HTML 原型的定位
原型是**可交互的视觉规格说明**，不是最终 UI 设计稿：
- 布局和控件类型要准确反映字段规格表的内容
- 交互要能演示核心操作路径（填写→提交→成功反馈）
- 样式保持整洁专业，不需要精细打磨视觉细节