Menu
从业务上下文（产品概念文档/MRD/口头描述/已有PRD）出发，动态推导 PRD 结构，逐节生成细节完备的产品需求文档。不依赖固定模版——AI 理解背景后自行规划大纲。当用户说「写PRD」「写需求文档」「把概念文档展开成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 | pm-prdwriting |
| description | 从业务上下文（产品概念文档/MRD/口头描述/已有PRD）出发，动态推导 PRD 结构，逐节生成细节完备的产品需求文档。不依赖固定模版——AI 理解背景后自行规划大纲。当用户说「写PRD」「写需求文档」「把概念文档展开成PRD」「帮我出落地文档」「展开成可执行的需求」「帮我写功能需求」时触发。 |
从业务上下文推导结构，不套模版。维度驱动大纲，大纲即合同，逐节生成，逐节自检。
如果用户没有任何业务上下文（没有概念文档、没有 MRD、连口头描述都说不出来），引导去 pm-brainstorming 先想清楚方向。
「直接套个 PRD 模版就行了」 不行。Web 工具、Mobile App、to-B 后台、to-C 社区的 PRD 结构差异很大。模版是偷懒，维度推导才是正路。
「概念文档里说了就不用再问了」 概念文档给方向，但 PRD 需要大量概念文档没覆盖的细节。Phase 0 提取信号时会识别出哪些信息还缺。
「先把功能都列完再补交互细节」 每个功能模块写完就要自检细节。推迟 = 遗忘。
「用户量应该不小吧 / 技术栈大概是 React 吧」
零默认假设。用户没说的就是不知道，标 [待补充] 或追问。不默认填充任何信息。
| 用户情况 | 进入模式 |
|---|---|
| 有概念文档/MRD/口头描述，要写完整 PRD | → 模式 A：完整生成 |
| 有已有 PRD，想评估/改进 | → 模式 B：评估 + 改进 |
| 有已有 PRD，要追加功能/迭代 | → 模式 C：增量融合 |
digraph pm_prdwriting {
rankdir=TB;
node [shape=box];
"接收业务上下文\n提取信号+事实清单" [shape=box];
"信号确认？" [shape=diamond];
"分类\n识别关注维度" [shape=box];
"维度确认？" [shape=diamond];
"推导PRD大纲\n（含验收标准）" [shape=box];
"按需搜索" [shape=box, style=dashed];
"大纲确认？" [shape=diamond];
"逐节生成+自检" [shape=box];
"三项自检\n（结构/一致性/幻觉）" [shape=box];
"输出PRD文件" [shape=doublecircle];
"接收业务上下文\n提取信号+事实清单" -> "信号确认？";
"信号确认？" -> "接收业务上下文\n提取信号+事实清单" [label="补充"];
"信号确认？" -> "分类\n识别关注维度" [label="确认"];
"分类\n识别关注维度" -> "维度确认？";
"维度确认？" -> "分类\n识别关注维度" [label="调整"];
"维度确认？" -> "按需搜索" [label="确认"];
"按需搜索" -> "推导PRD大纲\n（含验收标准）";
"推导PRD大纲\n（含验收标准）" -> "大纲确认？";
"大纲确认？" -> "推导PRD大纲\n（含验收标准）" [label="修改"];
"大纲确认？" -> "逐节生成+自检" [label="确认"];
"逐节生成+自检" -> "三项自检\n（结构/一致性/幻觉）";
"三项自检\n（结构/一致性/幻觉）" -> "输出PRD文件";
}
接受的输入类型（至少一种）：
提取信号：
从输入中提取以下信号。已有的直接提取，缺失的必须追问——不猜测、不假设。
| 信号 | 提取内容 | 缺失处理 |
|---|---|---|
| 产品类型 | 全新产品 / 功能迭代 / 改版重构 / 技术迁移 | 必问 |
| 平台 | Web / Mobile / 小程序 / 桌面 / 插件 / 多平台 | 必问 |
| 受众 | to-C / to-B / 内部工具 / 开发者工具 | 必问 |
| 项目阶段 | MVP / V2+迭代 / Redesign | 必问 |
| 核心用户旅程 | 用户的主要任务路径 | 从概念文档提取或追问 |
| 范围边界 | 做什么/不做什么 | 从概念文档提取或追问 |
| 技术约束 | 已有技术栈、依赖、平台限制 | 如有则记录 |
| 时间/资源约束 | 截止日期、团队规模 | 如有则记录 |
关键行为：如果输入是 pm-brainstorming 的概念文档，继承所有已有信息（产品定位、用户画像、功能方向、边界等），不重复追问。只补充概念文档没覆盖的 PRD 特有信息。
事实清单（防幻觉核心机制）
Phase 0 的最终输出除了信号汇总表，还包含一份事实清单——把用户明确提供的所有具体信息逐条列出，每条标注来源。
后续所有 Phase 生成的内容，如果涉及具体数据/规模/场景/技术选型，必须能追溯到事实清单中的某一条。无法追溯的内容标 [推测]。
## 事实清单
| # | 事实 | 来源 |
|---|------|------|
| F1 | 目标用户是25-35岁职场人 | 概念文档「目标用户」章节 |
| F2 | MVP阶段，预计3个月内上线 | 用户口头描述 |
| F3 | 核心功能是AI辅助写作 | MRD 第3节 |
| F4 | 技术栈为 React + Node.js | 用户口头描述 |
| ... | ... | ... |
⚠️ Gate：信号汇总表 + 事实清单展示给用户，获得明确确认后才进入 Phase 1。
参考 references/concern-dimensions.md，根据 Phase 0 确认的信号，激活对应的维度集合。
维度体系（详见 reference 文件）：
输出方式：
把激活的维度列表展示给用户：
基于你的产品特征（Mobile + to-C + MVP），
我识别出以下关注维度需要在 PRD 中覆盖：
通用维度（必选）：
- ✅ 用户与场景
- ✅ 功能定义（含验收标准）
- ✅ 交互完整性
- ✅ 状态覆盖
- ✅ 边界条件
- ✅ 数据规范
- ✅ 文案规范
- ✅ 非功能性需求
- ✅ 通知策略
- ⏭️ 搜索/筛选/排序（产品暂无列表场景，跳过）
- ✅ 数据埋点
平台维度（Mobile）：
- ✅ 触控与手势
- ✅ 离线处理
- ✅ 推送通知
- ✅ 设备权限
- ✅ 异形屏适配
- ✅ 审核约束
...
有没有需要增减的维度？
用户可以增加维度（如"这个产品有支付功能"→ 激活支付/交易维度），也可以去掉不适用的维度。
⚠️ Gate：维度列表获得用户确认后才进入 Phase 2。这个列表就是后续大纲的"完备性基线"。
核心逻辑：从维度推导章节
维度→章节的映射规则：
不是每个维度都独立成章。维度分为三类：
| 维度类型 | 处理方式 | 举例 |
|---|---|---|
| 全局维度 | 独立成章，放在 PRD 前部或后部 | 用户与场景、非功能性需求、数据埋点 |
| 功能内嵌维度 | 嵌入每个功能模块内部，不单独成章 | 交互完整性、状态覆盖、边界条件、数据规范、验收标准 |
| 专题维度 | 如果涉及多个功能则独立成章，只涉及单个功能则嵌入该功能 | 通知策略、搜索/筛选/排序、支付/交易 |
章节排列的一般顺序（AI 根据具体产品调整，不死板照搬）：
1. 产品概述与背景（继承概念文档）
2. 目标用户与使用场景（全局维度）
3. 核心用户动线（全局维度，Mermaid 流程图）
4. 功能清单与优先级（全局维度，树状结构）
5. 关键页面布局（全局维度，ASCII 线框图）
6-N. 各功能模块详细描述（每个模块内含：功能逻辑、交互细节、状态机、边界条件、数据规范、验收标准）
N+1. 文案规范（全局维度）
N+2. 非功能性需求（全局维度）
N+3. 数据埋点（全局维度）
N+4. [平台/受众/阶段专题章节]（按需，如"App Store 审核相关"、"RBAC 权限模型"）
N+5. 待确认问题
这个顺序是参考，不是模板。AI 应该根据产品的复杂度和重点自行调整。
按需搜索：
推导大纲前，评估是否需要搜索外部信息。以下场景需要搜索：
需要搜索时，先向用户展示搜索方向和目的，确认后执行：
我准备搜索以下方向：
1. Apple Human Interface Guidelines 中关于底部 Tab 导航的最新规范 — 确保导航设计符合审核要求
2. [竞品名] 的购物车交互模式 — 参考行业标准做法
用户说不搜或用户已提供足够信息 → 跳过搜索。
大纲格式：
# [产品名] — 产品需求文档 v1.0
> 一句话：[产品定位]，本次 PRD 范围：[范围描述]，核心目标：[目标]
## 变更记录
| 版本 | 日期 | 变更范围 | 变更原因 | 操作人 |
|------|------|---------|---------|-------|
| v1.0 | [日期] | 初始版本 | — | [AI/用户] |
## 第1节：[节标题] — [这节解决什么问题]
- [ ] 具体bullet（精确到可验证："登录支持手机号+验证码和微信OAuth两种方式"）
- [ ] 具体bullet（带数据依据："商品列表每页20条 [F12]，支持按价格/销量/时间排序"）
## 第X节：[核心功能模块标题]
- [ ] 功能A
- 验收：前提：[具体前提] / 操作：[单一动作] / 预期：[可观察结果]
- 验收：前提：[异常前提] / 操作：[同一动作] / 预期：[异常处理结果]
- [ ] 功能B
- 验收：...
---
## 维度覆盖检查
✅ 用户与场景 — 第1节
✅ 交互完整性 — 第3-5节（每个功能模块内）
✅ 触控与手势（Mobile） — 第3-5节
⚠️ 数据埋点 — 第8节（信息不足，标注 [待补充]）
Bullet 质量标准：
[FN] 标注事实清单来源⚠️ Gate：展示大纲，等待用户明确确认或提出修改。没有确认不开始生成。
生成规则：
[ ] bullet 都必须被覆盖，缺失的立即补写references/detail-reference-examples.md 的自检清单逐项检查：
[待补充]，不编造[推测]验收标准展开：
大纲阶段写的是简要验收条件（一行），Phase 3 生成时必须展开为完整的验收用例表，覆盖正常流程 + 主要异常/边界场景。格式参考 references/detail-reference-examples.md 第 9 节。
格式要求：
全部章节生成完毕后，必须执行以下三项自检：
自检 1：结构自检
用模式 B 的评估逻辑，按三层 checklist 给这份 PRD 打分：
方向层：
结构层：
细节层：
发现 ❌ 或 ⚠️ 的问题，直接修复后再输出。
自检 2：一致性自检
拿 Phase 0 的事实清单逐条对照全文：
自检 3：幻觉清除
把全文所有 [推测] 和 [待补充] 捋一遍，逐个给出处理：
[待补充] 并汇总到"待确认问题"章节三项自检通过后，输出最终文件。
文件命名：[ProductName]-PRD-[YYYYMMDD].md
保存路径：用户当前工作目录（路径不明确时询问）
输出后提示：
/anthropic-skills:docx 转为 Word 格式prd([ProductName]): v1.0 初始版本收到用户提供的已有 PRD 后：
对已有 PRD 执行 Phase 0 的信号提取（产品类型/平台/受众/阶段），确认缺失的信号。
执行 Phase 1 的维度识别——根据这个产品的信号，它的 PRD 应该覆盖哪些维度？
方向层：
结构层：
细节层：
对照 references/detail-reference-examples.md 的自检清单逐项检查——
维度覆盖检查： 对照步骤 2 识别的维度清单，哪些维度在已有 PRD 中缺失？
## 评估结果
**总体评分**：X / 10 — [一句话评价]
### 方向层（X/Y 项通过）
✅ ...
❌ ...
### 结构层（X/Y 项通过）
✅ ...
⚠️ ...
### 细节层（X/Y 项通过）
❌ ...
### 缺失维度
- [维度1]：当前 PRD 未覆盖，建议新增「XX」章节
- [维度2]：...
---
我可以直接帮你补全缺失的部分，或者你想先自己修改再来检查——你更倾向哪种？
核心原则：融合而不是覆盖，更新而不是重写。
让用户提供：
对新需求单独跑 Phase 1 的维度识别——新功能涉及哪些维度？确保新增内容不遗漏该覆盖的细节。
新内容会影响哪些章节？通常需要同步更新：
【本次更新】 标注，方便用户核对| v1.1 | [日期] | 新增「[功能名]」模块，更新用户动线 | [变更原因] | [操作人] |
输出融合后的完整 PRD 文件，建议 commit message：prd([ProductName]): v1.1 [变更摘要]
【本次更新】标记在下一个版本更新时自动清除——标记只服务于本次 review。
[待补充] > 编造——信息不足时明确标出，不用模糊语言带过。[推测] 标注无事实依据的内容——涉及具体数据/规模/场景的描述必须追溯到事实清单。【本次更新】 标注改动。