Menu
产品需求文档(PRD)撰写工具。引导用户从模糊想法到完整PRD，通过递归追问深挖需求细节，输出专业的.docx格式文档。当用户提到写PRD、需求文档、产品需求、功能设计、需求规格说明书、方案文档时使用。也适用于用户有半成品文档需要补全、或需要整理散乱需求时。即使用户只说'帮我整理一下这个需求'也应触发。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | prd-writer |
| description | 产品需求文档(PRD)撰写工具。引导用户从模糊想法到完整PRD，通过递归追问深挖需求细节，输出专业的.docx格式文档。当用户提到写PRD、需求文档、产品需求、功能设计、需求规格说明书、方案文档时使用。也适用于用户有半成品文档需要补全、或需要整理散乱需求时。即使用户只说'帮我整理一下这个需求'也应触发。 |
本 skill 需要配合以下 skill 使用：
如果这两个 skill 未安装，Phase 5 输出 .docx 时可能失败或出现编码问题。
PRD 的本质是把用户脑中的产品想法转化为开发团队可执行的需求文档。这意味着：
| 用户意图 | 模式 |
|---|---|
| "我要写一个新的 PRD" / 从零开始描述产品想法 | 新建模式 |
| "帮我补全/整理这个需求文档" / 已有半成品 | 补全模式 |
| "帮我收集一下这个领域的背景资料" / 先调研 | 调研模式 |
判断不了就问："你是要从零写 PRD、补全已有文档、还是先做领域调研？"
写 PRD 前先确保理解业务领域。纯工具类产品（计算器、文件转换）可跳过。
0.1 问用户一句话描述要做什么产品/功能，判断涉及哪个业务领域。
0.2 检查是否已有该领域的知识：
<当前工作目录>/docs/prd-knowledge/ 下是否有对应领域文件如果已有领域知识文件，读取后直接进入 Phase 1。
0.3 如果背景不足，向用户要：
从提供的资料中提取：业务对象和概念、专业术语、关联模块、用户角色。记录到当前项目的 docs/prd-knowledge/<领域名>/<模块名>.md，后续追问时参考。
知识存储结构：
docs/prd-knowledge/
├── 财务一体化/ # 领域目录
│ ├── _index.md # 领域总览（模块清单、通用术语、模块间关联）
│ ├── 财务报表.md # 模块知识
│ └── 总账管理.md
├── 供应链/
│ ├── _index.md
│ └── 采购管理.md
└── ...
_index.md 记录模块清单、通用术语和模块间关联不提取具体业务规则——规则在 Phase 1 中通过追问获取。
目标：把模糊的产品想法拆解到每个功能点都有明确的用户故事、数据来源和异常处理。
1.1 启动问题（必问）：
注意：不要一次性把所有问题倒给用户。先问最重要的 1-2 个，根据回答追问，像对话而不是填表。
1.2 递归追问 —— 三维度结构化：
对每个功能点/流程步骤，必须明确回答以下三个问题后才算完成：
| 维度 | 追问 | 完成标准 |
|---|---|---|
| 数据来源 | 这个信息从哪来？ | 已明确为：用户输入 / 系统查询 / 第三方接口 / 固定配置 |
| 业务规则 | 怎么判断/怎么计算/怎么流转？ | 已明确为：固定规则（列出规则）/ 用户选择 / 系统自动（说明依据） |
| 异常处理 | 数据缺失/冲突/超限怎么办？ | 已明确为：默认值 / 报错提示 / 降级方案 / 人工介入 |
追问方式：
1.3 识别子模块： 如果某个功能点足够独立且复杂（如审批流程、权限体系），标记为子模块，同样执行三维度追问。
1.4 终止检查： 结束 Phase 1 前输出完整的功能点检查表：
## 需求完整性检查
| # | 功能点 | 数据来源 | 业务规则 | 异常处理 |
|---|--------|---------|---------|---------|
| 1 | 用户注册 | ✅ | ✅ | ✅ |
| 2 | 订单创建 | ✅ | ❓待确认计价规则 | ✅ |
| 3 | 支付流程 | ✅ | ✅ | ❓待确认超时处理 |
所有功能点三个维度都 ✅ 后，才进入 Phase 2。
根据深挖结果，确定 PRD 的章节结构。给用户看目录大纲，确认后再写正文。
标准章节（通用）：
| 章节 | 内容 | 必须 |
|---|---|---|
| 一、文档信息 | 版本号、作者、日期、审批人、变更记录 | ✅ |
| 二、产品概述 | 背景、目标（Goals）、非目标（Non-Goals）、定位、目标用户 | ✅ |
| 三、用户角色与权限 | 角色定义、权限矩阵 | ✅ |
| 四、功能需求 | 用户故事、需求优先级（P0/P1/P2）、验收标准（Given/When/Then）、业务规则 | ✅ |
| 五、业务流程 | 核心流程图（文字描述）、状态流转 | ✅ |
| 六、数据需求 | 核心数据对象、字段定义（业务含义）、数据来源 | ✅ |
| 七、接口需求 | 接口名称（业务含义）、调用方向、输入输出（业务字段）、调用场景 | 视情况 |
| 八、非功能需求 | 性能、安全、兼容性、可用性 | ✅ |
| 九、效果度量 | 领先指标（上线后快速验证）+ 滞后指标（长期观察）、具体目标值 | ✅ |
| 十、风险与约束 | 已知风险、技术约束、依赖项、范围管理（防止需求蔓延的规则） | ✅ |
| 十一、待决事项 | 未解决的问题，标注责任人（产品/设计/开发/法务/数据） | ✅ |
| 附录 | 术语表、竞品参考、原型链接 | 建议 |
新增章节说明：
根据产品类型调整：
小需求简化规则： 如果功能点 ≤3 个且不涉及多角色/多系统交互，以下章节可省略：
省略前问用户确认："这个需求比较小，我建议省略 XX 章节，你觉得呢？"
必须等用户确认目录结构后再写正文。
按确认的目录结构逐章撰写。撰写时读取 references/chapter-templates.md 获取各章节的详细模板。
撰写原则：
产品经理边界： 定义"做什么"，不定义"怎么实现"
判断原则： 写 PRD 时问自己——"这个信息换一个开发团队来做，他们需要知道吗？"
不超出 Phase 1 收集范围： Phase 1 没问到的需求，不在 Phase 3 自行补充。发现遗漏时回到 Phase 1 追问。
撰写完成后执行自评审（见 Phase 4）。
以资深产品经理角度评审初稿，输出评审报告：
| 维度 | 检查要点 |
|---|---|
| 需求完整性 | 所有功能点是否都有用户故事？异常场景是否覆盖？ |
| 逻辑一致性 | 流程是否自洽？数据流转是否闭环？权限是否匹配？ |
| 可落地性 | 开发团队能否直接基于此文档排期？是否有歧义？ |
| 用户体验 | 操作流程是否顺畅？异常提示是否友好？ |
| 验收可测 | 每个功能是否有明确的验收标准？ |
| 边界清晰 | 功能范围是否明确？不做什么是否说清？ |
评审发现的问题分级：
将 P0 问题修复后，将评审报告和问题清单呈现给用户确认。
用户确认内容无误后，使用 docx-js（Node.js docx 库）生成 .docx 文件。
生成前必须执行：
docx skill 获取 docx-js 的完整 API 和排版规范docx-chinese-fix skill 获取中文字符串处理规则（核心：所有中文字符串必须用反引号 ` 而非双引号 "）排版要求：
TableOfContents，用户在 Word 中右键可更新size:6 + 表头下细线 size:2，无左右竖线，表头灰底 D9D9D9）交付物清单：
用户已有半成品文档时：
只收集领域背景，不写 PRD。适用于产品规划早期。
<当前工作目录>/docs/prd-knowledge/<领域名>/<模块名>.md，后续写 PRD 时直接复用