메뉴
产品需求文档(PRD)撰写工具。引导用户从模糊想法到完整PRD，通过递归追问深挖需求细节，输出专业的.docx格式文档。当用户提到写PRD、需求文档、产品需求、功能设计、需求规格说明书、方案文档时使用。也适用于用户有半成品文档需要补全、或需要整理散乱需求时。即使用户只说'帮我整理一下这个需求'也应触发。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| 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 时直接复用