---
name: prd-writer
description: "产品需求文档(PRD)撰写工具。引导用户从模糊想法到完整PRD，通过递归追问深挖需求细节，输出专业的.docx格式文档。当用户提到写PRD、需求文档、产品需求、功能设计、需求规格说明书、方案文档时使用。也适用于用户有半成品文档需要补全、或需要整理散乱需求时。即使用户只说'帮我整理一下这个需求'也应触发。"
---

# PRD 撰写指南

## 依赖 Skills

本 skill 需要配合以下 skill 使用：
- **docx** — Word 文档生成能力（生成 .docx 文件必需）
- **docx-chinese-fix** — 中文文档生成防护规则（中文 PRD 必需，防止中文引号导致 JS 语法错误）

如果这两个 skill 未安装，Phase 5 输出 .docx 时可能失败或出现编码问题。

## 核心理念

PRD 的本质是把用户脑中的产品想法转化为开发团队可执行的需求文档。这意味着：

1. **所有需求必须来自用户，不替用户做业务假设。** 你不知道用户的业务规则——猜出来的需求上线必出错。
2. **站在产品经理的位置。** 定义"做什么"和"为什么"，不定义"怎么实现"。接口的 URL、数据库表结构、前端组件选型留给开发团队。
3. **输出 .docx 文件。** 最终交付物是专业排版的 Word 文档，不是 Markdown。

## 模式判断

| 用户意图 | 模式 |
|---------|------|
| "我要写一个新的 PRD" / 从零开始描述产品想法 | **新建模式** |
| "帮我补全/整理这个需求文档" / 已有半成品 | **补全模式** |
| "帮我收集一下这个领域的背景资料" / 先调研 | **调研模式** |

判断不了就问："你是要从零写 PRD、补全已有文档、还是先做领域调研？"

---

## 新建模式

### Phase 0: 领域背景收集

写 PRD 前先确保理解业务领域。纯工具类产品（计算器、文件转换）可跳过。

**0.1** 问用户一句话描述要做什么产品/功能，判断涉及哪个业务领域。

**0.2** 检查是否已有该领域的知识：
- 查看 `<当前工作目录>/docs/prd-knowledge/` 下是否有对应领域文件
- 用户是否提供了竞品文档、行业报告、现有系统文档？
- 是否有 MCP 工具可以搜索相关知识库？
- 当前对话中是否已包含业务上下文？

如果已有领域知识文件，读取后直接进入 Phase 1。

**0.3** 如果背景不足，向用户要：
- 相关的竞品截图或文档
- 现有系统的业务流程说明
- 目标用户群体的描述

从提供的资料中提取：业务对象和概念、专业术语、关联模块、用户角色。记录到当前项目的 `docs/prd-knowledge/<领域名>/<模块名>.md`，后续追问时参考。

**知识存储结构：**
```
docs/prd-knowledge/
├── 财务一体化/              # 领域目录
│   ├── _index.md            # 领域总览（模块清单、通用术语、模块间关联）
│   ├── 财务报表.md          # 模块知识
│   └── 总账管理.md
├── 供应链/
│   ├── _index.md
│   └── 采购管理.md
└── ...
```
- 按领域分目录，领域下按模块分文件
- 每个领域有 `_index.md` 记录模块清单、通用术语和模块间关联
- 目录不存在时自动创建
- 知识跟着项目走，换项目时是干净的

**不提取具体业务规则**——规则在 Phase 1 中通过追问获取。

---

### Phase 1: 需求深挖

目标：把模糊的产品想法拆解到每个功能点都有明确的用户故事、数据来源和异常处理。

**1.1 启动问题（必问）：**
1. **这个产品/功能要解决什么问题？** 用户痛点是什么？不解决会怎样？
2. **目标用户是谁？** 有几类角色？各自的核心诉求？
3. **给一个最典型的使用场景** —— 从用户打开到完成任务，端到端走一遍
4. **成功长什么样？** 上线后怎么衡量这个功能成功了？（引导用户想指标）
5. **明确不做什么？** 哪些看起来相关但这次不做的？（越早划清边界越好，避免做着做着范围膨胀）

注意：不要一次性把所有问题倒给用户。先问最重要的 1-2 个，根据回答追问，像对话而不是填表。

**1.2 递归追问 —— 三维度结构化：**

对每个功能点/流程步骤，必须明确回答以下三个问题后才算完成：

| 维度 | 追问 | 完成标准 |
|------|------|----------|
| **数据来源** | 这个信息从哪来？ | 已明确为：用户输入 / 系统查询 / 第三方接口 / 固定配置 |
| **业务规则** | 怎么判断/怎么计算/怎么流转？ | 已明确为：固定规则（列出规则）/ 用户选择 / 系统自动（说明依据） |
| **异常处理** | 数据缺失/冲突/超限怎么办？ | 已明确为：默认值 / 报错提示 / 降级方案 / 人工介入 |

**追问方式：**
- 每轮列出当前已识别的功能点，标注哪些维度已明确 ✅、哪些待追问 ❓
- 只问待追问的，已明确的不重复
- 用户说"AI 自行判断"的，在 PRD 中标注"系统根据上下文自动判断"，不编造具体规则

**1.3 识别子模块：** 如果某个功能点足够独立且复杂（如审批流程、权限体系），标记为子模块，同样执行三维度追问。

**1.4 终止检查：** 结束 Phase 1 前输出完整的功能点检查表：

```
## 需求完整性检查

| # | 功能点 | 数据来源 | 业务规则 | 异常处理 |
|---|--------|---------|---------|---------|
| 1 | 用户注册 | ✅ | ✅ | ✅ |
| 2 | 订单创建 | ✅ | ❓待确认计价规则 | ✅ |
| 3 | 支付流程 | ✅ | ✅ | ❓待确认超时处理 |
```

所有功能点三个维度都 ✅ 后，才进入 Phase 2。

---

### Phase 2: PRD 结构设计

根据深挖结果，确定 PRD 的章节结构。给用户看目录大纲，确认后再写正文。

**标准章节（通用）：**

| 章节 | 内容 | 必须 |
|------|------|------|
| 一、文档信息 | 版本号、作者、日期、审批人、变更记录 | ✅ |
| 二、产品概述 | 背景、目标（Goals）、**非目标（Non-Goals）**、定位、目标用户 | ✅ |
| 三、用户角色与权限 | 角色定义、权限矩阵 | ✅ |
| 四、功能需求 | 用户故事、需求优先级（P0/P1/P2）、**验收标准（Given/When/Then）**、业务规则 | ✅ |
| 五、业务流程 | 核心流程图（文字描述）、状态流转 | ✅ |
| 六、数据需求 | 核心数据对象、字段定义（业务含义）、数据来源 | ✅ |
| 七、接口需求 | 接口名称（业务含义）、调用方向、输入输出（业务字段）、调用场景 | 视情况 |
| 八、非功能需求 | 性能、安全、兼容性、可用性 | ✅ |
| 九、效果度量 | **领先指标**（上线后快速验证）+ **滞后指标**（长期观察）、具体目标值 | ✅ |
| 十、风险与约束 | 已知风险、技术约束、依赖项、**范围管理**（防止需求蔓延的规则） | ✅ |
| 十一、**待决事项** | 未解决的问题，标注**责任人**（产品/设计/开发/法务/数据） | ✅ |
| 附录 | 术语表、竞品参考、原型链接 | 建议 |

**新增章节说明：**
- **Non-Goals（非目标）** 和 Goals 同等重要——明确不做什么，防止做着做着范围膨胀。每个非目标要说明为什么不做。
- **验收标准用 Given/When/Then 格式**——比"预期结果"更精确，开发和测试直接可用。
- **效果度量分领先/滞后指标**——领先指标（采纳率、任务完成率）上线后几天就能看，滞后指标（留存、满意度）需要几周。两者都要设具体目标值。
- **待决事项带责任人**——不是笼统的"待确认"，而是"谁来确认、什么时候需要答案"。

**根据产品类型调整：**
- **AI/智能体产品**：增加"模型能力边界"、"效果评估指标"章节
- **To B 企业应用**：增加"审批流程"、"组织架构适配"章节
- **数据产品**：增加"数据源说明"、"指标定义"、"看板设计"章节
- **移动端产品**：增加"离线策略"、"推送策略"章节

**小需求简化规则：** 如果功能点 ≤3 个且不涉及多角色/多系统交互，以下章节可省略：
- 三、用户角色与权限（只有一种角色时）
- 六、数据需求（无新数据对象时）
- 七、接口需求（无外部接口时）
- 十一、待决事项（无遗留问题时）

省略前问用户确认："这个需求比较小，我建议省略 XX 章节，你觉得呢？"

**必须等用户确认目录结构后再写正文。**

---

### Phase 3: 撰写 PRD

按确认的目录结构逐章撰写。撰写时读取 `references/chapter-templates.md` 获取各章节的详细模板。

**撰写原则：**

1. **产品经理边界：** 定义"做什么"，不定义"怎么实现"
   - ✅ 写：接口名称（业务含义）、调用场景、输入输出（业务字段）、性能要求
   - ❌ 不写：URL 路径、HTTP 方法、数据库表名、字段类型、CSS 样式、代码实现

2. **判断原则：** 写 PRD 时问自己——"这个信息换一个开发团队来做，他们需要知道吗？"
   - 如果是"业务上必须这样" → 应该写
   - 如果是"技术上可以这样也可以那样" → 不该写

3. **不超出 Phase 1 收集范围：** Phase 1 没问到的需求，不在 Phase 3 自行补充。发现遗漏时回到 Phase 1 追问。

**撰写完成后执行自评审（见 Phase 4）。**

---

### Phase 4: 自评审

以资深产品经理角度评审初稿，输出评审报告：

| 维度 | 检查要点 |
|------|----------|
| **需求完整性** | 所有功能点是否都有用户故事？异常场景是否覆盖？ |
| **逻辑一致性** | 流程是否自洽？数据流转是否闭环？权限是否匹配？ |
| **可落地性** | 开发团队能否直接基于此文档排期？是否有歧义？ |
| **用户体验** | 操作流程是否顺畅？异常提示是否友好？ |
| **验收可测** | 每个功能是否有明确的验收标准？ |
| **边界清晰** | 功能范围是否明确？不做什么是否说清？ |

评审发现的问题分级：
- **P0 必须修复**：逻辑缺陷、需求遗漏
- **P1 建议补充**：体验优化、边界说明
- **P2 后续迭代**：锦上添花的内容

将 P0 问题修复后，将评审报告和问题清单呈现给用户确认。

---

### Phase 5: 输出 .docx

用户确认内容无误后，使用 docx-js（Node.js `docx` 库）生成 .docx 文件。

**生成前必须执行：**
1. 读取 `docx` skill 获取 docx-js 的完整 API 和排版规范
2. 读取 `docx-chinese-fix` skill 获取中文字符串处理规则（核心：所有中文字符串必须用反引号 `` ` `` 而非双引号 `"`）

**排版要求：**
- 封面页：标题居中，深蓝主色调，包含版本号和日期
- 目录：使用 `TableOfContents`，用户在 Word 中右键可更新
- 字体：正文 Arial/微软雅黑 12pt，标题层级用颜色区分（H1 深蓝 / H2 蓝 / H3 灰）
- 行距：1.5 倍（段后间距 120）
- 页边距：上下 2.54cm（1440 DXA），左右 3.17cm（1800 DXA）
- 表格：三线表风格（上下粗线 `size:6` + 表头下细线 `size:2`，无左右竖线，表头灰底 `D9D9D9`）
- 页眉：右对齐文档标题，底部细线分隔
- 页脚：居中页码

**交付物清单：**
- [ ] PRD 文档（.docx）
- [ ] 评审报告（在对话中呈现，不单独出文件）
- [ ] 需求追溯表（功能点 ↔ 用户故事 ↔ 验收标准，包含在 PRD 内）

---

## 补全模式

用户已有半成品文档时：

1. **导入文档**：读取用户提供的文件（.docx / .md / 粘贴的文本）
2. **差距分析**：对照标准章节结构，标注哪些章节已有、哪些缺失、哪些不够详细
3. **定向追问**：只针对缺失和不足的部分执行 Phase 1 的三维度追问
4. **补写内容**：补全后执行 Phase 4 自评审
5. **输出 .docx**：整合原有内容和新补充内容，统一格式输出

---

## 调研模式

只收集领域背景，不写 PRD。适用于产品规划早期。

1. 了解用户要调研的领域和方向
2. 收集资料（用户提供的文档 + MCP 搜索 + 对话中的信息）
3. 输出调研摘要：行业现状、竞品分析、用户痛点、机会点
4. 保存到 `<当前工作目录>/docs/prd-knowledge/<领域名>/<模块名>.md`，后续写 PRD 时直接复用