Prd writer

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。

输出场景清单表：

| 编号 | 场景名称 | 触发条件 | 关联痛点 | 优先级 |
|------|---------|---------|---------|--------|
| 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 = 一个场景

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

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

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

Step 4: 编写场景验收条件

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

### S01: 邮箱注册

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

#### 验收条件

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

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

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

验收条件编写原则：

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

Step 5: 识别约束和边界

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

Step 6: 组装需求文档

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

# [产品名称] 需求文档

> 最后更新：[日期]

## 一、产品背景与目标
### 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 字段：

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

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