メニュー
从业务上下文（产品概念文档/MRD/口头描述/已有PRD）出发，动态推导 PRD 结构，逐节生成细节完备的产品需求文档。不依赖固定模版——AI 理解背景后自行规划大纲。当用户说「写PRD」「写需求文档」「把概念文档展开成PRD」「帮我出落地文档」「展开成可执行的需求」「帮我写功能需求」时触发。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/chituai/pm-prdwriting --skill pm-prdwritingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
SOC 職業分類に基づく
| 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。
[待补充] > 编造——信息不足时明确标出，不用模糊语言带过。[推测] 标注无事实依据的内容——涉及具体数据/规模/场景的描述必须追溯到事实清单。【本次更新】 标注改动。