PRD Generator

Use when drafting, improving, reviewing, or explaining PRDs, product requirements, feature specs, user stories, acceptance criteria, scope boundaries, MVP de...

PRD 生成器

本技能帮助生成清晰、结构完整、逻辑严谨的产品需求文档（PRD），让业务相关方都能切实执行。

一份好的 PRD 需要回答三个问题：

1. 为什么 — 我们在为谁解决什么问题？
2. 做什么 — 产品/功能将实现什么？
3. 做多好 — 成功的标准是什么？

写 PRD 最难的地方不是知道模板——而是进行深入思考。你的职责是帮助用户完成这个思考过程，而不仅仅是填写模板。

---

可用资源

文件	路径	何时使用
PRD 标准模板	references/prd_template.md	起草 PRD 时，用作结构参考和示例内容
UX 交互设计规范	references/ux_guidelines.md	需要描述界面行为、状态反馈、错误处理时参考
用户旅程图指南	assets/user_journey_example.md	功能流程复杂（≥3 阶段）时，引导用户绘制旅程图

使用指引：在阶段二正式起草前，读取 references/prd_template.md 获取完整结构示例；当 PRD 涉及界面或交互描述时，读取 references/ux_guidelines.md；当用户场景复杂或跨多个角色时，参考 assets/user_journey_example.md 并建议用户配套绘制旅程图。

---

快速决策流程

先判断用户真正要的是哪一种产出，不要把所有场景都套成完整 PRD 导出。

用户意图	判断信号	默认动作	输出
引导起草	只有粗略想法，未要求直接出稿	进入阶段一，逐轮补齐关键缺口	3-7 个定向问题
直接出草稿	用户说“直接写一版”“先按你的理解写”或信息已足够	立即起草，缺口用 【推测】 和待确认项标注	Markdown 草稿，必要时导出文件
评审/完善	用户提供已有 PRD、需求片段或设计稿	按“PRD 评审模式”指出缺口和修改建议	评审结论 + 可执行修订建议
方法咨询	用户问怎么写、模板包含什么、如何评估完整性	只解释方法和清单，不生成文件	简明指南或检查表

执行顺序：

1. 提取用户已给出的业务目标、角色、范围、约束、成功标准。
2. 根据上表选择模式；如果模式不明确，优先问 1 个澄清问题。
3. 起草前读取 references/prd_template.md；涉及界面行为时再读取 references/ux_guidelines.md。
4. 输出前执行“质量门禁”，确保需求可测试、边界明确、假设可追踪。

---

阶段一：信息收集

在开始撰写之前，通过访谈了解以下内容：

• 问题：存在什么痛点？谁在经历这个问题？没有这个功能时，现状是什么？
• 用户：主要用户是谁？是否有次要利益相关方？
• 范围：这是新产品、现有产品中的新功能，还是对现有功能的改进？
• 约束：时间线？技术限制？平台（Web/移动端/API）？合规要求？
• 成功指标：如何判断这个功能成功了？是否有目标数据？

提问要有针对性——不要一次性抛出所有问题。如果用户提供了粗略想法，从中提取已有信息，只询问真正缺失的内容。

默认工作方式：先问答，后起草

除非用户明确要求“直接先出草稿”“不要先提问”“先按你的理解写一版”，否则第一轮响应必须先进行定向调研问答，不得直接输出完整 PRD。

默认调研过程最多进行 3 轮问答；一旦 5 类最小信息门槛足够支撑起草，就进入阶段二，不要为了凑轮次继续追问。这里的“3 轮”指：

• 第 1 轮：识别问题、用户、范围、约束、成功标准中的主要缺口
• 第 2 轮：基于用户回答继续追问关键边界、例外流程、角色分工、输入输出和依赖关系
• 第 3 轮：确认仍会显著影响 PRD 结构或优先级的未决项，并明确哪些内容将采用 【推测】、哪些进入“待确认事项清单”

每一轮都应以前一轮回答为基础缩小不确定性，不允许重复提问或提无关问题。若用户只想快速得到初稿，直接起草并把缺口集中放入“待确认事项”。

默认至少补齐以下 5 类最小信息门槛中的缺口：

• 业务目标：为什么要做，想解决什么问题
• 目标用户/角色：谁使用，谁审批，谁受影响
• 范围边界：这次做什么，不做什么
• 约束条件：国家/地区、平台、时间、合规、依赖系统
• 成功标准：上线后看什么指标判定成功

何时可以跳过问答直接起草

仅在以下两种情况下允许直接进入起草阶段：

1. 用户明确要求先出草稿；
2. 用户已明确提供了上述 5 类最小信息，且不存在会显著影响 PRD 结构的关键缺口，并且这些信息已经足以替代默认的 3 轮调研。

如果信息明显不足但用户没有明确要求跳过问答，必须先进入多轮调研；单轮一次性问完不是默认方案。每轮建议追问 3-7 个最关键问题，再根据回答进入下一轮。

信息不足时的处理原则：合理推测并标注"【推测】"，在文档末尾列出"待确认事项清单"，而不是让流程卡住。

---

阶段二：撰写 PRD

💡 在此阶段开始前，读取 references/prd_template.md 获取带有示例内容的完整结构参考。

使用以下结构。根据功能范围灵活调整各部分深度——一个小型内部工具不需要与旗舰产品功能同等深度。始终使用清晰、无歧义的语言。

标准 PRD 结构

# [功能/模块名称] — PRD

**最后更新**：[YYYY-MM-DD]
**版本**：v1.0

---

## 1. 业务目标

- [目标 1：例如提升合规率 / 提升处理效率 / 降低错误率]
- [目标 2：例如降低人工处理成本]
- [目标 3：例如支撑多国家/多租户/多业务场景接入]

### 1.1 背景与问题
[说明业务背景、当前问题、为什么现在需要建设该功能。]

### 1.2 验收标准
- [核心页面/流程] 能支撑基础业务流程可用
- 保存前能阻断必填缺失和格式错误
- 保存后能处理异步校验、状态回写或任务流转
- 批量处理场景能输出失败原因，支持修正后重试

---

## 2. 功能定位

[用 1-2 句话说明该功能在产品中的定位，以及它对上下游流程的职责边界。]

### 2.1 目标用户与角色

| 角色 | 职责边界 | 典型操作 |
|---|---|---|
| [角色 A] | [职责边界] | [查看、新增、编辑、处理异常等] |
| [角色 B] | [职责边界] | [导入、删除、配置、授权等] |
| [API/系统集成方] | [系统对接职责] | [调用查询、创建、更新、导入接口] |

### 2.2 MVP 范围边界

| 能力 | MVP 是否覆盖 | 说明 |
|---|---|---|
| [核心列表] | 是 | 支持查询、筛选、基础操作 |
| [新增/编辑] | 是 | 支持核心字段维护 |
| [详情/查看] | 是 | 支持完整信息与状态查看 |
| [批量导入] | 是/否 | 说明同步/异步、失败文件等能力 |
| [手动触发异步校验] | 否 | MVP 可通过保存后异步触发 |

---

## 3. 功能与其他模块的联系

- **[上游模块]**：[说明如何提供数据或触发本功能]
- **[下游模块]**：[说明如何消费本功能数据]
- **[规则/合规模块]**：[说明校验、状态判断、配置来源]
- **[任务中心]**：[说明异步任务、导入任务、结果回写]
- **[系统设置]**：[说明字段配置、权限配置、国家/租户配置]

---

## 4. 功能的业务使用场景

1. **[场景 1：日常维护]**
   [用户角色] 新增/编辑 [业务对象]，确保后续业务流程可用。
2. **[场景 2：批量导入]**
   [用户角色] 通过模板批量导入，快速上线存量数据。
3. **[场景 3：异常/待确认处理]**
   用户集中处理校验失败、真实性未确认或数据存疑的记录。
4. **[场景 4：业务流程快速选择]**
   在 [业务页面] 快速搜索并选择该主数据对象。
5. **[场景 5：API 自动补全]**
   通过唯一标识在 API 调用时自动补全主数据。
6. **[场景 6：规则配置]**
   按国家/租户/企业维度维护字段、校验、默认值或业务规则。

---

## 5. 功能描述

要求：
- 编号、无歧义、可测试的系统行为说明
- 数据模型需列出字段名、类型、是否必填、描述
- 业务规则需明确边界条件
- 页面说明需明确只读/可编辑、默认值、动态字段、原型图、操作按钮
- 异步任务、导入、校验、删除、状态流转必须写清触发条件和结果状态

### 5.2.1 [功能一：列表页]

对每个功能点，按以下子结构展开：
  5.2.x.1 功能描述
  5.2.x.2 页面说明
  5.2.x.3 状态流转逻辑
  5.2.x.4 权限控制
  5.2.x.5 异常处理规则  ← 参见 ux_guidelines.md 第 6 节
  5.2.x.6 数据模型结构（字段级说明）
  5.2.x.7 业务规则（可测试，格式：FR-XXX）

建议功能点：
- 5.2.1 列表页：查询、筛选、摘要列、状态、分页、操作
- 5.2.2 新增/编辑：基础信息、动态字段、明细、保存策略
- 5.2.3 详情/查看：只读信息、校验状态、审计信息
- 5.2.4 批量导入：模板、上传、同步/异步、更多配置、失败文件

---

### 5.3 跨页面规则

#### 5.3.1 配置驱动动态展示
- 字段集合、必填条件、默认值、校验策略
- 明细字段集合、顺序与必填性
- 名称/编码规则
- 国家/租户/企业级业务规则

#### 5.3.2 校验策略 / 保存策略
- 保存时同步阻断：必填缺失、格式/长度失败、配置一致性不满足
- 保存时不阻断：真实性校验、第三方校验超时、异步校验失败

#### 5.3.3 删除与审计策略
- 删除采用软删除，保留关键标识、操作人、操作时间与删除原因
- 已被下游业务引用的数据不允许物理删除
- 删除后的数据不出现在默认列表、查询结果和业务选择结果中

#### 5.3.4 非功能约束
- 列表查询 P95 响应时间目标 ≤ [阈值]
- 同步导入目标处理时间 ≤ [阈值]，超时需提示转异步
- 异步任务需可在任务中心追踪，任务结果至少保留 [天数]
- 敏感数据传输必须使用 HTTPS，导出/下载文件需按租户权限隔离
- 删除、导入、覆盖更新、校验结果变更必须记录审计日志

---

## 待确认事项

1. [待确认问题] — 负责人：[姓名] — 截止：[日期]

---

写作原则

具体，而非空泛。 "用户能导出数据"太弱。"用户可将筛选后的数据导出为最多 10 万行的 CSV 文件"才是可测试的。

为读者而写。 工程师需要足够的细节来构建。设计师需要背景来做好决策。高管需要快速理解"为什么"。相应调整内容深度。

区分做什么与怎么做。 PRD 定义需求，而非实现方案。"系统应在 5 秒内完成上传处理"——可以。"系统应使用 Redis 进行任务队列"——不可以（除非有充分理由）。

明确非目标。 未言明的假设会导致范围蔓延。明确说明你不做什么。

用证据支撑观点。 "用户对 X 感到沮丧"如果有数据支撑则更有力："在 Q2 调研中，68% 的受访者将 X 列为最主要的痛点。"

引导而非填充。 当用户信息不足时，标注"【待补充】"并列出待确认事项，帮助用户意识到遗漏，而非自行填造内容。

---

PRD 评审模式

当用户要求“需求评审”“帮我看看完整吗”“完善这份 PRD”或提供已有文档时，不要默认重写全文。先评审，再按用户需要局部改写。

评审维度：

维度	检查重点
问题与目标	是否说明为什么现在要做、为谁解决什么问题、目标是否可衡量
角色与场景	是否覆盖主要用户、审批者、运营/管理员、系统集成方
范围边界	MVP 做什么、不做什么、后续迭代与非目标是否明确
功能可测试性	FR 是否编号、条件/触发/结果是否清楚、是否能写成测试用例
数据与状态	字段、枚举、状态流转、唯一性、审计、删除策略是否完整
异常与权限	空状态、失败重试、权限、导入失败、外部依赖超时是否覆盖
非功能要求	性能、安全、合规、可用性、数据隔离、日志保留是否有指标
待确认事项	未决问题是否有负责人、影响范围和截止时间

评审输出格式：

1. 结论：可进入设计/开发、需补充后进入、或不建议进入。
2. 阻塞问题：按严重度列出会影响范围、实现或验收的问题。
3. 改进建议：给出可直接粘贴进 PRD 的补充条目。
4. 待确认事项：列出需要业务、设计、工程或法务确认的问题。

---

输出格式

当用户需要可交付 PRD 时，优先输出 .docx 文件；当用户只是咨询方法、做轻量评审或还处在问答阶段，不要强行导出文件。推荐工作流如下：

1. 先生成结构完整的 Markdown 版本，作为 Word 导出的源文件；
2. 如项目中存在 tools/generate_prd.sh，默认调用该脚本完成 .docx 导出；
3. 仅当高层导出脚本不存在时，才回退到 tools/export_prd_docx.sh；
4. 仅当 .docx 导出工具不可用或用户明确不要文件时，才回退为纯 Markdown 输出。

Word 导出规则

• 默认文件名使用 [产品或需求名称]-PRD.docx
• 如用户未指定输出目录，优先写入当前工作目录
• Word 文件内容必须与 Markdown 源稿保持一致，不允许导出时删减章节
• 如项目中存在 docs/templates/prd-reference.docx，应先生成 docs/templates/prd-cn-reference.docx 作为中文友好的参考模板
• 默认使用高层导出脚本；高层脚本内部再串联模板生成、pandoc 导出、表格修复和段落修复
• 若导出失败，必须明确说明失败原因，并同时提供完整 Markdown 版本

默认导出命令

tools/generate_prd.sh input.md output.docx

次级回退命令

tools/export_prd_docx.sh input.md output.docx

手工回退命令

python3 tools/make_cn_prd_template.py docs/templates/prd-reference.docx docs/templates/prd-cn-reference.docx
pandoc input.md -o output.docx --reference-doc=docs/templates/prd-cn-reference.docx
python3 tools/fix_docx_table_layout.py output.docx
python3 tools/fix_docx_paragraph_layout.py output.docx

如项目中不存在参考模板，可回退为：

pandoc input.md -o output.docx

如需更稳定地保留标题层级、表格和段落结构，可先生成规范 Markdown，再执行导出，不要直接拼接不规范文本后导出。 另外，子项标题如 5.2.5.1 功能描述 应使用真实标题层级（如 #####），不要用加粗文本加手动换行伪装标题。

导出前先检查脚本和依赖是否存在：

• 若 tools/generate_prd.sh 存在且可执行，优先使用；
• 若脚本不存在但 pandoc 可用，使用手工回退命令；
• 若脚本、模板或 pandoc 不可用，明确说明无法导出 .docx 的原因，并提供完整 Markdown。

样式要求

• 正文：字体为宋体（SimSun），字号为小四（12pt）
• 段落行间距：1.5 倍（line-height: 1.5）
• 段落首行缩进：每个段落首行缩进 4 个字符（text-indent: 4em）
• 表格文字：字体为宋体（SimSun），字号为五号（10.5pt）
• 表格对齐：所有表格居中显示

当用户对某些细节不确定时，提供合理的默认值，或将该部分标注为"待定——[需解决的问题]"，而不是凭空填写内容。

---

质量门禁

输出完整 PRD 或评审结论前，快速自检：

• 是否明确业务目标、目标用户、范围边界、约束条件和成功标准？
• 是否有“非目标/暂不做”，避免范围蔓延？
• 每条核心需求是否包含触发条件、系统行为、结果状态或验收标准？
• 数据模型、状态流转、权限、异常处理、导入导出、审计日志是否按场景覆盖？
• 涉及税务、法务、合规、支付、隐私等高风险内容时，是否标注“需专业确认”，避免把推测写成事实？
• 所有 【推测】、【待补充】、待定 是否进入“待确认事项”？
• 如果生成 .docx，Markdown 源稿与导出文件是否内容一致？

---

语气与风格

• 主动语态，需求使用现在时（"系统允许..."而非"系统将允许..."）
• 需求编号便于追溯（FR-001、FR-002 等）
• 段落简短；避免大段文字
• 描述用户流程时，编号步骤优于叙述性文字
• 比较、指标、风险使用表格展示