prd-generator-cc

by unknown

Install this Skill

curl -fsSL -o prd-generator-cc.zip https://skill.seembox.com/api/v1/skills/prd-generator-cc/download && unzip prd-generator-cc.zip

Download prd-generator-cc.zip

SKILL.md About

---
name: prd-generator
description: Use when drafting, improving, reviewing, or explaining PRDs, product requirements, feature specs, user stories, acceptance criteria, scope boundaries, MVP definitions, or stakeholder-ready product documents; trigger on PRD, 需求文档, 功能规格, feature spec, 产品文档, 需求评审, 写用户故事.
allowed-tools:
  - bash
  - create_file
  - str_replace
  - view
  - present_files
---

# 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 版本

### 默认导出命令

```bash
tools/generate_prd.sh input.md output.docx
```

### 次级回退命令

```bash
tools/export_prd_docx.sh input.md output.docx
```

### 手工回退命令

```bash
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
```

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

```bash
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 等）
- 段落简短；避免大段文字
- 描述用户流程时，编号步骤优于叙述性文字
- 比较、指标、风险使用表格展示

_meta.json Metadata

{
  "ownerId": "kn7c9kejv5vab87np7npqe2pyd84cxcy",
  "publishedAt": 1776255200266,
  "slug": "prd-generator-cc",
  "version": "1.0.3"
}