# Skill: PRD Writer

> 辅助撰写场景驱动的需求文档——从用户痛点出发，识别核心业务场景，为每个场景定义 GIVEN/WHEN/THEN 验收条件。场景编号将贯穿后续所有阶段。

## 触发条件

- 用户要求写需求文档、产品需求或 PRD
- 用户讨论产品定位、目标用户、功能需求
- 用户提到 "Phase 1"、"需求层"、"WHY"
- 当前处于项目的需求分析阶段

## 核心能力

1. 引导用户梳理产品定位和目标用户
2. 提炼用户痛点，建立因果链
3. 从痛点中识别和定义业务场景（分配 `S01`, `S02`... 编号）
4. 为每个场景编写 GIVEN/WHEN/THEN 验收条件
5. 排列场景优先级
6. 识别约束和"不做"清单
7. 生成符合 OpenLogos 规范的场景驱动需求文档

## 执行步骤

### Step 1: 理解产品定位

与用户确认以下核心问题（如果信息不足则主动追问）：

- **一句话定位**：这个产品是什么？为谁？解决什么问题？
- **目标用户画像**：具体到可以描述一个真实的人
- **核心目标**：产品要达成什么，用什么指标衡量成功

### Step 2: 提炼用户痛点

引导用户从以下维度梳理痛点：

- 用户当前是怎么做的？（现状）
- 做的过程中遇到什么困难？（痛点）
- 困难导致了什么后果？（影响）
- 用户期望怎么被解决？（期望）

**每条痛点必须有因果链**：因为 [原因] → 导致 [痛点] → 造成 [后果]

为每条痛点分配编号（`P01`, `P02`...），便于场景追溯。

### Step 3: 识别和定义场景

**场景是贯穿整个研发周期的锚。** 这一步至关重要。

从痛点和需求中提取业务场景。每个场景是一个**完整的用户操作路径**：

- **谁**在**什么情况下**触发
- 经过**什么步骤**（必须包含多个交互环节，不能只是单个 API 调用）
- 达到**什么业务成果**（用户可感知的价值）

为每个场景分配全局唯一编号（`S01`, `S02`...），这个编号将一路带到 Phase 2 和 Phase 3。

输出场景清单表：

```markdown
| 编号 | 场景名称 | 触发条件 | 关联痛点 | 优先级 |
|------|---------|---------|---------|--------|
| S01  | 邮箱注册 | 新用户首次访问 | P01 | P0 |
| S02  | 密码登录 | 已注册用户返回 | P01 | P0 |
| S03  | 忘记密码 | 用户无法登录 | P02 | P1 |
```

#### 场景粒度自检（必须通过）

生成场景清单后，运行以下 4 项测试。**任何一项不通过，必须重新组织场景后再继续。**

1. **单 API 测试**：如果一个场景只需要调用 1 个 API 就能完成，它不是场景——它是一个操作。应将其合并到更大的场景中。
2. **CRUD 测试**：如果场景清单中出现"创建X"、"查询X"、"更新X"、"删除X"作为 4 个独立场景，说明粒度过细。应按用户目标重新组织（例如用"负责人规划周任务"代替"创建任务"+"分配任务"+"更新任务"+"删除任务"）。
3. **业务价值测试**：用一句话描述场景完成后用户获得的价值。如果答案只是"数据被写入/读取/删除了"，说明缺少真正的业务目标——应合并到有明确目标的场景中。
4. **步骤数测试**：一个场景的主路径至少包含 3 个用户可感知的步骤。少于 3 个说明粒度过细。

#### ❌ 反模式：一个 API = 一个场景

```markdown
| S01 | 创建任务   | 用户点击"新建"   |
| S02 | 获取任务列表 | 用户打开页面     |
| S03 | 更新任务   | 用户编辑任务     |
| S04 | 删除任务   | 用户删除任务     |
→ 这是 API 清单，不是场景清单！
```

#### ✅ 正确：按业务目标组织场景

```markdown
| S01 | 团队负责人规划周任务 | 负责人登录 → 创建多个任务 → 设置优先级和截止日期 → 分配给成员 → 成员收到通知 |
| S02 | 开发者完成并交付任务 | 开发者查看待办 → 更新进度 → 标记完成 → 负责人收到通知并审核 |
| S03 | 负责人查看项目进度   | 负责人打开看板 → 按状态/成员筛选 → 导出周报 |
```

### Step 4: 编写场景验收条件

为每个 P0 和 P1 场景编写验收条件：

```markdown
### S01: 邮箱注册

- **触发条件**：新用户首次访问，点击注册
- **用户价值**：快速创建账号开始使用产品（← P01）
- **优先级**：P0
- **主路径**：用户填写邮箱和密码，提交后收到验证邮件，点击验证完成注册

#### 验收条件

##### 正常：完整注册流程
- **GIVEN** 用户未注册过，且在注册页面
- **WHEN** 用户填写有效邮箱和密码（≥8位），点击「注册」
- **THEN** 系统创建账号，发送验证邮件，页面显示「请查收验证邮件」

##### 异常：邮箱已注册
- **GIVEN** 邮箱 test@example.com 已注册
- **WHEN** 用户使用 test@example.com 尝试注册
- **THEN** 显示「该邮箱已注册，请直接登录」，不发送任何邮件

##### 异常：密码不符合要求
- **GIVEN** 用户在注册页面
- **WHEN** 用户填写有效邮箱但密码少于 8 位，点击「注册」
- **THEN** 显示「密码至少 8 位」，不提交请求
```

**验收条件编写原则**：

- 每个场景至少 1 个正常 + 1 个异常验收条件
- GIVEN 描述初始状态，要具体到可复现
- WHEN 描述用户操作，要精确到按钮级别
- THEN 描述期望行为，要具体到可验证
- 避免模糊词汇："快速"、"友好"、"合理" → 量化为具体指标

### Step 5: 识别约束和边界

- **技术约束**：技术栈限制、第三方服务限制
- **资源约束**：团队规模、时间窗口
- **"不做"清单**：明确列出本阶段不做的功能和场景，避免范围蠕变

### Step 6: 组装需求文档

按标准结构输出完整文档：

```markdown
# [产品名称] 需求文档

> 最后更新：[日期]

## 一、产品背景与目标
### 1.1 产品定位
### 1.2 核心目标
### 1.3 目标用户画像

## 二、用户痛点分析
### P01: [痛点名称]
因为 [原因] → 导致 [痛点] → 造成 [后果]
### P02: ...

## 三、场景总览
[场景清单表：编号 / 名称 / 触发条件 / 关联痛点 / 优先级]

## 四、核心场景详述
### S01: [场景名称]
[触发条件 + 用户价值 + 优先级 + 主路径 + 验收条件]
### S02: ...

## 五、约束与边界
### 5.1 技术约束
### 5.2 资源与时间约束
### 5.3 "不做"清单
```

## 输出规范

- 文件格式：Markdown
- 存放位置：`logos/resources/prd/1-product-requirements/`
- 文件命名：`<module>-{序号}-{英文名}.md`，如 `core-01-requirements.md`（从 `logos-project.yaml` 的 `modules[]` 读取当前模块，默认为 `core`）
- 每个场景必须可追溯到至少一个用户痛点
- P0/P1 场景必须有 GIVEN/WHEN/THEN（≥1 正常 + ≥1 异常）
- 场景编号全局唯一，将贯穿 Phase 2 和 Phase 3

## 实践经验

- **先宽后窄**：第一轮尽可能多地识别场景，然后在优先级排序时砍掉非核心的
- **场景 ≠ 功能，场景 ≠ API**：场景是"用户视角为达成业务目标而走过的完整路径"。一个功能（如"用户认证"）可能包含多个场景（注册、登录、找回密码）；一个场景（如"首次购买"）可能跨多个功能（浏览、加购、支付）。**绝不要将单个 CRUD 操作定义为独立场景。**
- **场景粒度**：Phase 1 阶段保持适中粒度。过细（"用户创建一条记录"）只是一次 API 调用，过粗（"用户使用产品"）无法验收。好的粒度是：一个场景能在 1-2 分钟内走完主路径，且至少包含 3 个不同步骤
- **验收条件是需求的精确表达**：如果写不出 GIVEN/WHEN/THEN，说明场景还没想清楚
- **异常场景同等重要**：用户不可能总是走正常路径，异常处理往往决定产品体验
- **"不做"清单是最难写的**：克制是产品经理最重要的能力
- **场景编号一旦分配不复用**：即使场景被废弃，编号也不回收，避免混淆
- **需求文档是活文档**：随着产品演进持续更新，通过 Delta 变更管理跟踪每次变化

## 推荐提示词

以下提示词可以直接复制给 AI 使用：

- `帮我写需求文档`
- `我要做一个 xxx 产品，帮我梳理需求`
- `帮我把这些想法整理成结构化的需求文档`
- `帮我给现有需求文档补充异常场景的验收条件`

## ⚠️ 收尾步骤（强制）：更新 resource_index

完成本 Skill 的所有文档产出后，**必须**将新生成的文档追加写入 `logos/logos-project.yaml` 的 `resource_index` 字段：

```yaml
resource_index:
  # ...已有条目...
  - path: logos/resources/prd/1-product-requirements/<文件名>.md
    desc: <产品名称>需求文档。涉及产品定位、痛点、核心场景、验收条件时必读。
```

**不执行此步骤将导致后续 AI 无法感知已完成的需求文档，影响整个开发链路的上下文质量。**