PRD 生成
根据功能创意生成结构化的产品需求文档。
技能作用
将非正式的功能需求转化为完整的 PRD，包含用户故事、验收标准、功能需求、成功指标和合规建议。输出结果可直接用于工程团队实施和利益相关者评审。
何时使用
在以下情况下激活此技能：
- 用户想要记录新功能或产品创意
- 出现类似“写 PRD”、“创建需求”、“记录此功能”的表述
- 准备产品评审、利益相关者对齐或工程交接
- 用户提及用户故事、验收标准或成功指标
- 需要将粗略的想法整理成结构化文档
场景检测（关键 - 第一步）
在生成任何 PRD 内容之前，你必须先确定场景。
使用 AskUserQuestion 确定适用场景：
Q：请选择 PRD 生成场景
| 选项 | 描述 |
|---|---|
| 迭代更新 | 基于现有功能进行迭代优化 |
| 新功能 | 在现有产品上添加新模块 |
| 0-1 新产品 | 从零开始规划全新产品 |
按场景收集上下文
一旦确定场景，收集所需上下文：
| 场景 | 所需信息 | 收集方法 |
|---|---|---|
| 迭代更新 | 1. 当前功能描述2. UI 状态（截图/HTML/链接）3. 迭代目标 | 用户输入 + 使用 AskUserQuestion 询问 UI 状态选项 |
| 新功能 | 1. 产品整体架构2. 设计规范（组件库/交互模式）3. 入口位置 | 从 docs/product/ 读取或用户输入 |
| 0-1 新产品 | 1. 产品背景与目标用户2. 资源约束3. 参考产品 | 用户输入 + 竞品分析 |
迭代更新的 UI 状态收集： 当用户选择“迭代更新”时，询问他们如何提供当前 UI 状态：
- 截图 - 用户提供截图，使用
mcp__zai-mcp-server__ui_to_artifact或mcp__4_5v_mcp__analyze_image - HTML 文件 - 用户提供本地 HTML 路径，使用
Read工具解析 DOM 结构 - 在线链接 - 用户提供 URL，使用
mcp__web_reader__webReader（无需登录）
步骤 0.5：信息缺口分析与 PRD 计划（关键 — 硬门控）
硬门控：在完成此步骤并获得用户批准计划之前，不得进入行业基准检查或 PRD 生成阶段。
显式跳过协议（用户显式拒绝交互时）：如果用户明确禁止提问（例如“别问了，直接写”），你可以跳过交互式门控——但随后你必须在输出开头包含一个假设声明块，列出所做的每一项假设（场景、选中/排除的章节、目标产品、关键默认值），以便用户更正。假设声明同时充当证据纪律的完整度清单：未确认信息标【待确认】、无证据断言标【未验证】（见下文证据纪律），不得脑补填默认值。切勿默默跳过。
场景检测和上下文收集之后：
-
差距分析：将用户提供的信息与此场景的
context-requirements进行比较。列出每一项缺失的必填字段。同时检查docs/product/中现有的感知数据（market-analysis.json、competitive-analysis、user-research.json、positioning.md）。 -
一次一个问题：对于每个缺失项，使用
AskUserQuestion并提供多选选项来询问用户。请勿在一条消息中捆绑多个问题。缺失项 示例问题 UI 截图 “当前功能的界面状态，你如何提供？” → A. 已有截图 B. 有 HTML 文件 C. 有在线链接 D. 暂无，先跳过 竞品列表 “需要分析哪些竞品？” → 多选 + “其他” 目标用户 “目标用户是？” → A. 已定义画像 B. 我口述你来整理 C. 需要先做用户研究 参考产品 “有参考产品吗？” → A. 有，我来说 B. 你帮我搜索行业标杆 C. 不需要参考 -
处理缺失资源：如果用户说“我稍后提供截图”或“先跳过”，记录哪些项目待定，并在 PRD 计划中将其标注为
[待补充]。 -
生成 PRD 计划：准备（但尚未显示）PRD 计划结构。下表显示了默认选项的模板：
### 预计生成的 PRD 章节 | 章节 | 内容概要 | 选中 | 依赖状态 | |:-----|:---------|:-----|:---------| | 第0章 行业对标分析 | 将研究 X 个标杆产品 | ✅ | 已完成 / [待补充] | | 第1章 项目概述 | 基于用户描述展开 | ✅ | 已完成 | | 第2章 业务分析 | 目标用户 X，痛点 Y | ✅ | 已完成 / [待补充] | | 第3章 功能需求 | [关键功能列表] | ✅ | 已完成 | | 第4章 非功能性需求 | 行业标准要求 | ✅ | 自动生成 | | 第5章 用户体验流程 | 基于功能推导 | ✅ | 需 UI 补充 | | 第6章 项目风险 | 基于功能复杂度 | ✅ | 自动生成 | | 第7章 合规建议 | 基于数据类型 | ❌ | 自动生成 | | 第8章 原型设计 | [原型链接] | ❌ | - | | 第9章 成功指标 | 基于目标推导 | ❌ | 自动生成 | ### 排除清单（不生成以下内容） - 技术方案 / 架构设计 — PRD 为产品需求文档，不包含技术实现细节 - API 接口定义 / 端点规格 — 由开发团队在技术方案中另写 - 数据库表结构设计 — 不在产品需求范围内注意： 上表使用默认选项。实际的「选中」值将在步骤 4.5 中根据用户对章节选择的回答填写。暂时不要向用户呈现此表。
4.5. 章节选择（硬门控 — 在呈现 PRD 计划之前）：
通过 AskUserQuestion 向用户呈现章节选择（多选）。由于 4 个选项的限制，分为 3 个顺序问题。根据回答构建 selected_chapters 和 excluded_chapters 列表，并相应更新 PRD 计划表的「选中」列。
问题 1 — 核心章节（第 0-3 章）：
| 选项 | 默认 | 描述 |
|---|---|---|
| 第0章 行业对标分析 | ✅ 已选 | 研究基准产品和最佳实践 |
| 第1章 项目概述 | ✅ 已选 | 项目背景、目标、范围 |
| 第2章 业务分析 | ✅ 已选 | 目标用户、痛点、市场分析 |
| 第3章 功能需求 | ✅ 已选 | 功能列表、用户故事、详细需求 |
问题 2 — 扩展章节（第 4-7 章）：
| 选项 | 默认 | 描述 |
|---|---|---|
| 第4章 非功能性需求 | ✅ 已选 | 性能、安全、可用性、兼容性 |
| 第5章 用户体验流程 | ✅ 已选 | 用户旅程、页面流程图 |
| 第6章 项目风险 | ✅ 已选 | 项目风险和缓解策略 |
| 第7章 合规建议 | ⬜ 未选 | 合规指南和风险类别 |
问题 3 — 可选章节（第 8-9 章）：
| 选项 | 默认 | 描述 |
|---|---|---|
| 第8章 原型设计 | ⬜ 未选 | 原型链接和设计说明 |
| 第9章 成功指标 | ⬜ 未选 | 北极星指标、过程指标和结果指标 |
永久排除项（不在选择列表中，绝不生成）：
- 技术方案 / 架构设计 — PRD 不包含技术实现细节
- API 接口定义 — 接口文档由开发团队另写
- 数据库表结构设计 — 不在产品需求范围内
收集选择后： 更新 PRD 计划表的「选中」列以反映用户的选择（✅ 为选中，❌ 为排除）。
-
用户批准：使用
AskUserQuestion呈现 PRD 计划（包含章节选择）并获得明确批准：选项 描述 确认，按此章节方案生成 PRD 进入步骤 1 行业基准和步骤 2 PRD 生成 调整章节选择 重新勾选要生成的章节 需要调整方案 修改 PRD 计划后重新确认 我有更多信息要补充 回到步骤 0.5 补充信息，重新生成方案 先补充感知数据 调用 market-research / competitive-analysis
反模式：“信息足够了，直接生成吧” — 禁止。即使信息缺口很少，也要呈现计划并获得批准。
TUI 环境下的图片处理指南
在终端 (TUI) 环境下，用户可以通过以下方式提供图片：
方式一：本地文件路径（最简单）
直接提供图片的本地路径，使用 Read 工具读取：
# 用户对话示例
"分析这个 UI 截图: /Users/fh/Desktop/screenshot.png"
"当前界面: ~/Screenshots/ui-2025-03-12.png"
"参考图片: ./docs/product/images/reference.png"
支持的路径格式：
- 绝对路径:
/Users/fh/Desktop/screenshot.png - 家目录缩写:
~/Screenshots/ui.png - 相对路径:
./images/ui.png
支持的图片格式： PNG, JPG, JPEG, WebP, GIF
方式二：在线图片 URL
用户将图片上传到图床/云存储后提供 URL：
# 用户对话示例
"UI 截图: https://i.imgur.com/xyz.png"
"参考图: https://s3.aws.com/bucket/screenshot.png"
使用 mcp__4_5v_mcp__analyze_image 或 mcp__zai-mcp-server__ui_to_artifact 工具读取远程图片。
推荐图床：
- imgur.com (免费，无需注册)
- GitHub (作为 issue 附件)
- 云存储 (AWS S3, 阿里云 OSS)
方式三：终端截图命令
引导用户使用终端截图工具快速生成截图：
macOS:
# 截取选定区域（交互式）
screencapture -i ~/screenshot.png
# 截取整个窗口
screencapture -w ~/screenshot.png
# 截取整个屏幕
screencapture ~/screenshot.png
Linux:
# ImageMagick (需先安装: sudo apt install imagemagick)
import ~/screenshot.png
# gnome-screenshot (Ubuntu/GNOME)
gnome-screenshot -a -f ~/screenshot.png
#spectacle (KDE)
spectacle -r -o ~/screenshot.png
方式四：粘贴板直接获取（macOS）
# 安装 pngpaste 工具
brew install pngpaste
# 将粘贴板的图片保存为文件
pngpaste ~/screenshot.png
处理流程
当用户提供图片后：
- 本地路径 → 使用
Read工具直接读取 - 远程 URL → 使用
mcp__4_5v_mcp__analyze_image或mcp__zai-mcp-server__ui_to_artifact - 分析图片内容 → 提取 UI 结构、布局、交互元素
- 生成 PRD → 基于图片分析结果生成需求文档
行业基准检查
场景检测、上下文收集和信息澄清之后：
- 用户提供的基准（优先）：用户指定的参考产品
- Agent 补充搜索：根据场景关键词自动搜索行业最佳实践
- 提取最佳实践：3-5 个基准交互模式/功能设计
- 在 PRD 中引用：引用基准解决方案，并说明采纳/差异化的理由
搜索关键词映射：
| 场景 | 搜索关键词 |
|---|---|
| 迭代更新 | "{功能名} 最佳实践", "行业 {功能名} 设计" |
| 新功能 | "{产品类型} {模块名} 方案", "同类产品 {功能}" |
| 0-1 新产品 | "{行业} 产品框架", "{领域} 产品地图" |
工作原理
生成过程确保完整、可操作的 PRD：
- 场景检测 - 使用 AskUserQuestion 识别迭代/新功能/新产品
- 上下文收集 - 根据场景类型收集所需信息
- 信息缺口分析 - 识别缺失信息，一次问一个问题
- 章节选择 - 用户选择要生成的 PRD 章节（多选）
- PRD 计划呈现 - 呈现包含章节选择的计划供用户批准（硬门控）
- 行业基准研究 - 搜索并提取最佳实践（用户指定 + Agent 搜索）
- 解析需求 - 将用户的功能请求结构化分解为关键组件
- 收集上下文 - 读取市场分析、竞争洞察、用户研究
- 组装章节 - 仅构建用户选择的 PRD 章节，并包含适当的细节
- 验证完整性 - 对照质量标准检查（仅针对所选章节）
- 交付前自查 - 执行 PRD 预审尾门（章节自查 + 利益相关者视角挑战）；修复阻塞项或标记为【待确认】
- 生成输出 - 写入
docs/product/prd/{feature-name}-{date}-v{version}.md（含尾部「预审记录」一节）
内容约束（硬规则）：
在生成 PRD 内容之前，请注意：
- 仅生成用户选择的章节。完全跳过未选择的章节。
- 无论用户输入如何，绝不生成以下内容类型：
- 技术架构 / 实现细节
- API 端点定义或规格
- 数据库模式或表设计
- 如果用户的功能描述提及技术细节，将其总结为功能需求，而不暴露实现细节。
输入参数
| 参数 | 类型 | 必填 | 描述 |
|---|---|---|---|
requirements | string | 是 | 要记录的功能描述或用户故事 |
target_audience | string | 否 | 目标用户细分或角色画像 |
context_refs | list | 否 | 要引用的相关上下文文件 |
证据纪律（证据纪律）
- 缺失信息标记【待确认】：任何无法从输入或上下文获得的信息，标记为【待确认】，不得脑补填默认值。
- 证据追溯【未验证】：用户需求/市场断言必须追问证据来源；无证据的标记为【未验证】并注明所需验证方式。
- 完整度检查门：正式输出交付物前，先输出信息完整度清单（已确认 ✅ / 待确认 ⚠️ / 未验证 ❓），经用户确认后才生成正文。
与显式跳过协议（步骤 0.5）的关系：证据纪律是输出纪律（信息标注与交付前自查），显式跳过是交互纪律（用户显式拒绝交互时的降级处理），两者互补不冲突。显式跳过场景下完整度清单不免除 — 与「假设声明」合并输出，但不再等待用户确认；假设声明中的未确认信息同样按本节规则标注【待确认】/【未验证】。
输出结构
PRD 遵循以下结构（与标准 PRD 模板一致）。重要：此模板显示所有可能的章节。仅生成用户选择的章节。完全跳过未选择的章节。在任何情况下都不要生成技术架构、API 规格或数据库设计。
# [功能名称] PRD
## 文档基本信息
- **文档版本**: v1.0
- **创建日期**: YYYY-MM-DD
- **最后更新**: YYYY-MM-DD
- **文档状态**: Draft/Review/Approved
- **创建人**: [用户名]
- **审阅人**: [待定]
## 修订记录
| 版本 | 日期 | 修订内容 | 修订人 |
|:-----|:-----|:---------|:-------|
| v1.0 | YYYY-MM-DD | 初始版本 | [创建人] |
## 0. 行业对标分析
### 0.1 参考产品
| 产品 | 关键功能 | 采纳/差异化 |
|:-----|:---------|:-----------|
| [竞品A] | XXX | 采纳其 XXX 模式，因为... |
| [竞品B] | XXX | 差异化点在于... |
### 0.2 最佳实践总结
- **交互模式**: [采用的行业标准交互模式]
- **核心差异化**: [本方案的独特之处]
## 1. 项目概述
### 1.1 项目背景
[市场背景、竞争背景、用户需求背景]
### 1.2 项目目标
#### 1.2.1 核心目标
- [可量化的核心目标]
#### 1.2.2 次要目标
- [支撑性目标]
### 1.3 项目范围
#### 1.3.1 包含范围
- [本次迭代/功能包含的内容]
#### 1.3.2 不包含范围
- [明确不在本次范围内的事项]
## 2. 业务分析
### 2.1 目标用户
| 用户角色 | 描述 | 核心需求 |
|:---------|:-----|:---------|
| 用户A | [来自用户研究] | XXX |
| 用户B | [来自用户研究] | XXX |
### 2.2 用户痛点
| 痛点ID | 痛点描述 | 影响程度 |
|:-------|:---------|:---------|
| P-001 | XXX | 高/中/低 |
| P-002 | XXX | 高/中/低 |
### 2.3 市场分析
[行业趋势、竞争格局、市场机会点]
## 3. 功能需求
### 3.1 核心功能列表
| 功能ID | 功能名称 | 优先级 | 描述 |
|:-------|:---------|:-------|:-----|
| F-001 | XXX | P0/P1/P2 | XXX |
| F-002 | XXX | P0/P1/P2 | XXX |
### 3.2 用户故事
#### US-1: [功能名称]
**作为** [用户角色]
**我希望** [功能描述]
**以便** [业务价值]
**验收标准**:
- Given [前置条件]
- When [执行操作]
- Then [预期结果]
**优先级**: P0/P1/P2
**估算**: X Story Points
#### US-2: [功能名称]
...
### 3.3 功能详情
#### F-001: [功能名称]
**描述**: [详细功能描述]
**交互流程**:
1. 步骤一
2. 步骤二
3. 步骤三
**边界情况**:
- 正常流程: ...
- 异常情况: ...
## 4. 非功能性需求
### 4.1 性能需求
- 页面响应时间 < XXXms
- 支持 XXX 并发用户
### 4.2 安全需求
- 数据加密存储
- 用户权限控制
### 4.3 可用性需求
- 系统可用性 > 99.9%
### 4.4 兼容性需求
- iOS 14+, Android 10+
- 主流浏览器兼容
## 5. 用户体验流程
### 5.1 用户旅程
[关键用户路径描述]
1. 用户进入 → 2. 执行操作 → 3. 达成目标
### 5.2 页面流程图
[页面跳转关系说明]
- 页面A → 页面B → 页面C
## 6. 项目风险与应对
> 注：本节仅包含产品/业务风险，不包含技术实现风险（技术风险由开发团队在技术方案中评估）
| 风险ID | 风险描述 | 概率 | 影响 | 应对措施 |
|:-------|:---------|:-----|:-----|:---------|
| R-001 | XXX | 高/中/低 | 高/中/低 | XXX |
| R-002 | XXX | 高/中/低 | 高/中/低 | XXX |
## 7. 合规建议
### 7.1 合规要点概述
[合规专家审查的关键要点摘要]
### 7.2 风险提示
| 风险类别 | 说明 | 建议 |
|:---------|:-----|:-----|
| 隐私合规 | [涉及用户数据的处理方式] | [合规建议] |
| 内容合规 | [涉及的内容审核要点] | [合规建议] |
| 数据安全 | [数据存储和传输要求] | [合规建议] |
| 第三方合规 | [依赖的第三方服务合规性] | [合规建议] |
### 7.3 合规报告附件
- [ ] 合规分析报告已附 (如果有，提供路径)
- [ ] 等待合规审查 (如需要，安排合规专家评审)
## 8. 原型设计（可选）
### 8.1 设计预览
| 页面 | 原型链接 | 设计说明 |
|:-----|:---------|:---------|
| 页面A | [Figma/其他工具链接] | XXX |
| 页面B | [Figma/其他工具链接] | XXX |
## 9. 成功指标（可选）
### 9.1 北极星指标
[核心北极星指标描述]
### 9.2 过程指标
| 指标名称 | 描述 | 目标值 |
|:---------|:-----|:-------|
| XXX | XXX | XXX |
### 9.3 结果指标
| 指标名称 | 描述 | 目标值 |
|:---------|:-----|:-------|
| XXX | XXX | XXX |
## 附录
### 附录 A：术语表
| 术语 | 定义 |
|:-----|:-----|
| XXX | XXX |
### 附录 B：引用文档
- [文档路径/标题]
- [文档路径/标题]
---
### 预审记录
**章节自查**
| 检查项 | 状态 | 备注 |
|:-------|:-----|:-----|
| 第0章：行业对标 | ✅ / ❌ | 无基准产品则标记【待补充】 |
| 第1章：目标清晰可衡量 | ✅ / ❌ | 需要量化指标 |
| 第2章：用户痛点可溯源 | ✅ / ❌ | 需标注用户研究来源 |
| 第3章：功能需求完整 | ✅ / ❌ | 验收标准覆盖边界场景 |
| ... | ✅ / ❌ | （根据所选章节列） |
**利益相关者视角挑战**
**Challenge from Developer**: [开发者视角的潜在问题]
**Response**: [回应/修改记录]
**Challenge from QA**: [QA 视角的潜在问题]
**Response**: [回应/修改记录]
**Challenge from Design**: [设计视角的潜在问题]
**Response**: [回应/修改记录]
**Challenge from Ops**: [运维视角的潜在问题]
**Response**: [回应/修改记录]
**Challenge from Legal/Compliance**: [法务/合规视角的潜在问题]
**Response**: [回应/修改记录]
**仍然未解决的问题**：
1. 【待确认】[无法从输入获取的信息]
2. 【未验证】[无证据支持的市场断言]
示例使用场景
输入：
用户："为我博客网站添加评论功能"
输出：
生成 PRD 将包含：
- 第0章：分析主流博客（Disqus、WordPress）的评论系统
- 第1章：项目描述 - 在现有博客中添加评论功能
- 第2章：目标用户 - 博客作者和读者
- 第3章：功能需求 - 评论撰写、回复、审核、身份验证
注意：不包括后端架构或数据库规范，这些属于 PRD 范围之外。