【Skill 创作】我做了一个能生成标准 PRD 文档的 Skill

yujia · 2026 年5 月 29 日 08:02

1、Skill 简介

这是一个纯产品向 PRD 自动生成助手，通过多轮深度访谈式沟通与用户达成对需求的完全共识，输出一份结构完整、逻辑清晰、符合国内互联网行业标准的产品需求文档。全程专注于产品本身的需求定义，不涉及任何技术架构、接口设计、代码实现相关内容。

核心功能：

支持全流程深度访谈式需求挖掘，覆盖产品从背景到验收的所有环节
内置 7 大产品设计范式，确保生成的 PRD 专业、完整、可落地
自动生成业务泳道图、异常处理流程、BDD 格式验收标准
配套标准化 PRD 模板，支持自定义适配企业内部规范
可选多智能体 PRD 评审，从产品、UX、测试三个维度自动优化
全程自动保存访谈记录，支持随时中断、继续和修改

2、使用场景

为什么想做它？

这个PRD生成skill只是我skill组中的一个，我想要通过对产品的叙述，让Agent从需求调研、PRD编写、技术调研、技术详细设计编写、代码开发、自动测试生成测试报告，发布上线形成一整套软件工程流程。这个生成PRD的skill只是其中的一个环节，但我认为这个环境至关重要，这个环节内容的质量和颗粒度直接影响着后面的所有环境。

并且我发现很多产品人（尤其是新人）在写 PRD 时都会遇到这些痛点：

不知道 PRD 的标准结构是什么，每次都要找不同的模板拼凑
容易遗漏异常场景，导致开发过程中不断补需求
错误提示写得不清楚，用户体验差且容易产生纠纷
验收标准不明确，测试和开发对需求理解不一致
PRD 评审效率极低，每次都要花大量时间修改格式和逻辑

而且网上的 PRD 模板往往只提供了空架子，没有告诉你每个部分应该怎么写、需要注意什么。这时候一个能引导你一步步完善需求，并自动生成标准化 PRD 的工具就显得尤为重要。

解决了什么麻烦？

不用再到处找 PRD 模板，内置符合行业标准的完整模板
不用再担心遗漏异常场景，按照全链路覆盖原则自动引导
不用再纠结错误提示怎么写，严格按照 3W 原则自动生成
不用再手动编写 BDD 格式的验收标准，自动生成可量化的验收规则
不用再组织低效的 PRD 评审，多智能体自动评审并给出修改建议

能省掉哪些动作？

以前写一份完整的 3-5 个功能点的 PRD 需要：

梳理需求（2 小时）+ 搭建 PRD 结构（1 小时）+ 撰写功能描述（3 小时）+ 梳理异常场景（2 小时）+ 编写验收标准（1 小时）+ 绘制流程图（1 小时）+ 评审修改（2 小时）= 12 小时

现在只需要：

回答 AI 的访谈问题（30 分钟）→ 等待 PRD 生成（5 分钟）→ 确认并微调（10 分钟）= 45 分钟

效率提升16 倍，让产品人能把更多时间花在真正的需求思考上，而不是重复的文档撰写工作。

3、创作过程

第一步：确定 Skill 结构

根据官方 Skill Creator 的指引，创建了标准结构：

.trae/skills/product-prd-generator/
└── SKILL.md

第二步：编写 SKILL.md 核心内容

Frontmatter 定义：

---
name: product-prd-generator
description: 纯产品向PRD生成技能，通过深度访谈式沟通挖掘需求，输出符合标准的完整产品需求文档，尽量不涉及技术实现细节
version: 1.0.0
author: yujia
license: MIT
allowed-tools:
  - FileSystem
---

核心工作流程设计：

## 工作流程

### 1. 访谈记录文件初始化
- 自动检查当前目录是否存在interview-record.md文件
- 若存在，询问用户是否继续上次的访谈
- 若不存在，自动创建新的访谈记录文件，初始化所有章节

### 2. 问题背景与目标挖掘
- 询问产品类型（ToC电商/ToB后台/ToG/小程序/APP/网页端等）
- 引导用户描述当前遇到的具体问题及业务影响
- 按照SMART原则引导用户明确产品目标
- 挖掘产品核心价值和目标用户
- 了解竞品和参考案例及其优缺点

### 3. 用户角色与场景分析
- 梳理所有会使用产品的用户角色
- 对每个角色，明确其核心诉求和使用频率
- 描述每个角色在真实场景下的完整使用流程
- 识别核心用户角色和核心使用场景

### 4. 核心功能与边界定义
- 基于用户角色和场景，生成三级功能点清单
- 采用RICE评分模型划分功能优先级（P0/P1/P2）
- 明确绝对不做的功能（Out of Scope）
- 梳理功能之间的依赖关系

### 5. 业务流程与异常处理
- 绘制每个核心功能的正常业务流程
- 按照「全链路覆盖原则」梳理所有可能的异常场景
- 按照「3W原则」为每个异常场景设计错误提示
- 按照「极限值原则」明确所有输入和操作的边界条件
- 按照「最小权限原则」明确每个流程的权限边界
- 按照「原子性原则」明确数据修改操作的回滚和补偿机制
- 按照「容错原则」明确不可逆操作的二次确认和撤销机制

### 6. 交互与视觉要求
- 描述每个页面的核心元素和布局要求
- 描述关键操作的交互反馈
- 描述页面之间的跳转逻辑和弹窗联动规则

### 7. 非功能需求与验收标准
- 覆盖性能、安全、兼容性、可维护性、可访问性、合规性等维度
- 自动填充行业基准值，支持用户自定义调整
- 为每个核心功能生成BDD格式的验收标准

### 8. 最终确认与PRD生成
- 向用户总结对需求的全部理解
- 展示需求完整性校验清单
- 确认无误后，读取PRD模板生成完整的PRD文档

### 9. 多智能体PRD评审（可选）
- 调用产品专家智能体评审需求价值和合理性
- 调用UX设计师智能体评审交互流程和用户体验
- 调用测试工程师智能体评审可测性和完整性
- 汇总所有评审意见，自动修改PRD并生成修订说明

第三步：设计 7 大产品设计范式

这是本 Skill 最核心的部分，也是区别于其他简单 PRD 生成工具的关键。我将产品设计中最核心的 7 个原则提炼出来，确保生成的每一份 PRD 都符合专业标准：

异常流程设计必须遵守「全链路覆盖原则」：覆盖前置条件、输入、网络、服务器、并发、权限、业务规则 7 大类异常
所有错误提示必须严格遵守「3W 原则」：What（发生了什么）+ Why（为什么发生）+ What to do（该怎么办）
所有输入和操作必须定义明确的极限值：输入长度、格式、操作频率、数据量限制等
权限设计必须遵守「最小权限原则」：每个角色只能拥有完成其工作所必需的最小权限
所有涉及数据修改的操作必须遵守「原子性原则」：要么全部成功，要么全部回滚，并有补偿机制
所有交互设计必须遵守「容错原则」：不可逆操作必须有二次确认，用户输入自动保存
可访问性设计必须遵守「WCAG 2.1 AA 级标准」：确保产品对所有用户都可访问

第四步：配套 PRD 模板设计

我创建了一份完整的、符合国内互联网行业标准的 PRD 模板（product-prd-template.md），包含以下核心模块：

文档信息（版本、编写日期、需求状态等）
产品概述（问题背景、产品目标、核心价值、全局通用规则、全局异常处理）
用户角色分析（角色列表、核心用户场景）
产品功能交付清单（一级模块→二级页面→三级功能点，含优先级）
产品界面功能详情（页面→区域→元素，每个元素包含功能描述、状态说明、边界条件、异常处理、处理流程（泳道图）、验收标准）
非功能需求（性能、安全、兼容性等）
不包含范围
其他说明

第五步：多智能体评审流程设计

为了进一步提升 PRD 质量，我设计了多智能体评审流程，模拟真实的 PRD 评审会议：

@ppg-pr（产品专家）：评审需求价值、合理性、完整性，是否解决了用户的核心痛点
@ppg-ur（UX 设计师）：评审交互流程是否流畅、用户体验是否良好、是否符合用户习惯
@ppg-tr（测试工程师）：评审可测性、验收标准是否明确可量化、异常场景是否覆盖全面

评审完成后，Skill 会自动汇总所有意见，并根据评审意见修改 PRD，生成详细的修订说明。

4、使用步骤

调用方式

在 SOLO 中直接描述你的 PRD 需求即可，例如：

基础版：

帮我写一份电商小程序购物车功能的PRD

详细版：

我需要一个ToB客户管理系统的PRD，核心功能是客户信息录入、跟进记录和销售漏斗分析，目标用户是销售团队

快速版：

生成一个登录注册功能的PRD，支持手机号和微信登录，忘记密码功能

Skill 会自动：

检查当前目录是否有已存在的访谈记录，询问你是否继续上次的访谈
按照 7 步访谈流程，一步步引导你完善需求，不会遗漏任何重要环节
自动将你的所有回答保存到 interview-record.md 文件，支持随时修改
访谈完成后，自动读取 PRD 模板，将访谈内容填充到对应章节
自动生成业务泳道图、异常处理流程和 BDD 格式的验收标准
询问你是否需要启动多智能体 PRD 评审
如果需要，依次调用三个专业智能体进行评审
汇总评审意见，自动修改 PRD 并生成修订说明
输出最终的 PRD 文档

5、效果展示

使用示例

用户输入：

Skill 访谈过程（节选）：

由于沟通内容较多，这里仅展示部分对话。

最终生成的PRD：

由于最终PRD内容较多，这里仅做部分内容的展示。

7、多智能体评审智能体设计

产品专家智能体：守住 “做正确的事” 的底线，确保需求解决真实问题、价值明确

UX 设计师智能体：守住 “正确地做事” 的底线，确保产品易用、符合用户习惯

测试工程师智能体：守住 “事能做成” 的底线，确保需求可验证、可落地、质量可控

产品专家智能体（@ppg-pr）设计

核心定位与作用

作为 PRD 评审的第一责任人和 “业务守门员”，从产品战略、业务逻辑和用户价值层面进行顶层把关。核心作用是判断 “这个需求该不该做” 以及 “需求的设计是否能达成业务目标”，是三个智能体中唯一有权否决 PRD 整体方向的角色。

必备专业技能

需求分析与价值判断能力：能够识别真实需求与伪需求，评估需求的用户价值和商业价值
业务逻辑梳理能力：能够快速理解复杂业务流程，发现逻辑矛盾和流程断点
SMART 目标拆解能力：能够判断产品目标是否具体、可衡量、可实现、相关、有时限
功能优先级评估能力：基于 RICE 模型（Reach 影响范围、Impact 影响程度、Confidence 置信度、Effort 投入成本）评估功能优先级合理性
边界定义能力：能够清晰区分 “必须做”、“应该做” 和 “绝对不做” 的功能，避免需求蔓延
竞品分析能力：能够结合行业最佳实践，判断需求设计的合理性和创新性
ROI 计算能力：能够评估需求的投入产出比，判断是否值得投入资源开发

核心评审维度（按 PRD 章节划分）

1. 文档信息模块

文档版本号是否规范，更新记录是否完整可追溯
需求状态是否明确（待评审 / 已评审 / 已驳回）
编写人、编写日期、上次更新日期是否准确

2. 产品概述模块（核心评审重点）

问题背景：
- 是否描述了具体、可量化的业务痛点或用户痛点？
- 是否说明了问题的影响范围和严重程度？
- 是否有数据支撑问题的真实性？（如 “日均 100 个客服咨询该问题”）
产品目标：
- 是否符合 SMART 原则？（具体、可衡量、可实现、相关、有时限）
- 是否区分了核心目标和次要目标？
- 目标是否与问题背景一一对应？
核心价值：
- 是否用一句话清晰提炼了产品的核心价值？
- 是否明确了核心价值的受益对象（用户 / 业务 / 公司）？
全局通用规则：
- 是否定义了系统通用的基础规则？（如按钮状态、弹窗逻辑、提示样式）
- 规则是否统一、无矛盾？
全局异常处理规则：
- 是否覆盖了网络中断、服务器错误、权限不足等通用异常？
- 异常处理逻辑是否合理？

3. 用户角色与场景模块

用户角色：
- 是否列出了所有会使用该产品的用户角色？
- 每个角色的描述是否清晰？（职责、使用频率、核心诉求）
- 是否明确了核心用户角色（占比最高、价值最大的角色）？
- 角色权限划分是否符合 “最小权限原则”？
核心用户场景：
- 是否覆盖了所有核心用户的主要使用场景？
- 场景描述是否真实、具体？（是否包含前置条件、操作步骤、预期结果）
- 是否区分了主场景和边缘场景？
- 场景是否与产品目标一致？

4. 产品功能交付清单模块

功能结构：
- 是否采用 “一级模块→二级页面→三级功能点” 的三级结构？
- 功能点是否颗粒度适中？（单个功能点可独立开发、测试）
- 是否有遗漏的功能点？
优先级划分：
- 是否采用 P0/P1/P2 的优先级划分标准？
- P0 功能是否为核心功能，阻断产品上线？
- P1 功能是否为重要功能，影响用户体验但不阻断上线？
- P2 功能是否为优化功能，可后续迭代实现？
- 优先级划分是否符合 RICE 模型？
边界定义：
- 是否明确列出了 “绝对不做的功能”（Out of Scope）？
- 功能边界是否清晰，无模糊地带？
- 是否避免了需求蔓延？

5. 产品界面功能详情模块

业务流程：
- 主流程是否闭环？（从开始到结束的完整路径）
- 分支流程是否完整？（是否覆盖了所有可能的操作路径）
- 流程是否符合业务逻辑和用户习惯？
- 是否有流程断点或逻辑矛盾？
功能描述：
- 每个功能点的描述是否清晰、无歧义？
- 是否明确了功能的触发条件、执行逻辑和预期结果？
- 是否符合 “原子性原则”？（涉及数据修改的操作要么全部成功，要么全部回滚）

6. 非功能需求模块

非功能需求是否覆盖了性能、安全、兼容性、可维护性等核心维度？
需求是否具体、可衡量？（如 “页面加载时间≤2 秒” 而非 “页面加载要快”）
需求是否合理，符合行业基准和技术可行性？

7. 不包含范围模块

是否明确列出了本次迭代不做的功能？
不包含范围是否合理，是否会影响核心功能的使用？

标准化评审流程

整体通读：快速通读整个 PRD，了解需求的整体背景、目标和范围，形成初步印象
分模块评审：按照上述 7 个核心评审维度，逐章逐节进行详细评审，标记所有发现的问题
问题分级：根据问题的严重程度和影响范围，将问题划分为 P0、P1、P2 三个级别
影响分析：对每个问题进行影响分析，说明如果不修改该问题会带来什么后果
优化建议：针对每个问题，给出具体、可操作的优化建议，而非笼统的批评
整体结论：给出 PRD 的整体评审结论（通过 / 修改后通过 / 驳回），并说明理由
生成报告：按照统一格式生成产品专家评审报告

问题级别定义

P0（阻断性问题）：严重影响 PRD 的合理性和可行性，必须修改，否则 PRD 不能通过评审
- 示例：问题背景不真实、产品目标不可衡量、核心功能缺失、业务流程存在致命逻辑漏洞
P1（重要问题）：影响 PRD 的质量和可落地性，建议修改，否则会导致后续开发和测试出现问题
- 示例：功能优先级划分不合理、核心场景遗漏、边界定义不清晰、非功能需求不明确
P2（优化建议）：不影响 PRD 的核心逻辑和可落地性，属于锦上添花的优化，可根据实际情况选择是否修改
- 示例：文档格式不规范、功能描述可以更简洁、部分边缘场景可以补充

优化指导逻辑

P0 问题：必须强制修改，智能体将在评审报告中明确指出修改的必要性和具体方向
- 示例：“原问题：产品目标为 ’ 提升用户体验 ‘，不符合 SMART 原则。优化建议：将目标修改为 ’ 上线 3 个月内，用户人均使用时长提升 20%，用户留存率提升 15%’”
P1 问题：强烈建议修改，智能体将给出详细的优化方案和参考示例
- 示例：“原问题：核心用户场景遗漏了 ’ 用户忘记密码 ’ 的场景。优化建议：补充该场景，包含前置条件（用户已注册但忘记密码）、操作步骤（点击忘记密码→输入手机号→获取验证码→设置新密码→登录成功）、预期结果（用户成功重置密码并登录）”
P2 问题：作为可选优化建议，智能体将标注为 “建议修改”，由产品经理自行决定是否采纳
整体优化指导：在评审报告的末尾，给出 PRD 的整体优化方向和重点注意事项

产品专家智能体（@ppg-pr）系统提示词

一、角色与定位

你是一位拥有 10 年互联网产品经验的资深产品专家，精通 ToC/ToB 产品设计、需求分析、价值评估、优先级排序和产品规划。你的核心使命是从产品战略、业务价值和用户价值角度对 PRD 进行顶层把关，判断 “这个需求该不该做” 以及 “需求设计是否能达成业务目标”，确保产品解决真实问题、创造实际价值、边界清晰可控，提前发现并规避产品方向和逻辑风险。

你必须严格遵守分阶段增量输出到文档的工作模式，绝不一次性生成完整评审报告。每次只处理一个评审阶段，将结果追加到指定的.md 文档中，不修改、不删除文档中已有的任何内容。

二、核心工作原则

1、价值优先原则：所有需求必须有明确的用户价值或商业价值，无价值的需求坚决否决

2、SMART 原则：所有产品目标必须具体、可衡量、可实现、相关、有时限

3、边界清晰原则：必须明确 “做什么” 和 “不做什么”，坚决避免需求蔓延和范围镀金

4、用户中心原则：所有设计必须基于真实用户的真实需求，而非产品经理的主观臆想

5、数据驱动原则：所有判断必须有数据支撑，禁止凭感觉做决策

6、一致性原则：产品整体逻辑、功能设计、交互方式必须保持统一

7、ROI 导向原则：优先投入高价值、低成本的需求，合理评估投入产出比

8、增量输出原则：每次只输出当前阶段的评审结果，追加到文档对应位置，绝不重写已有内容

三、分阶段评审流程（必须严格按顺序执行）

你需要按照以下 7 个阶段依次进行评审，完成一个阶段后等待指令再进入下一个阶段。每个阶段开始时，你将收到：

当前需要评审的 PRD 章节内容
已生成的部分评审报告文档内容

阶段 1：文档信息与产品概述评审

评审内容：PRD 文档基本信息、问题背景、产品目标、核心价值、全局通用规则

检查点：

1、文档版本号规范，更新记录完整可追溯

2、需求状态明确，编写人、编写日期、更新日期清晰

3、问题背景描述了具体、可量化的业务痛点或用户痛点

4、说明了问题的影响范围和严重程度

5、有数据支撑问题的真实性（如用户反馈量、客服咨询量、业务损失等）

6、产品目标符合 SMART 原则，区分了核心目标和次要目标

7、目标与问题背景一一对应，能够解决提出的问题

8、核心价值清晰明确，一句话说明产品为谁解决了什么问题

9、定义了统一的全局通用规则（按钮、弹窗、提示等）

10、全局规则无矛盾，符合产品整体定位

输出位置：评审报告的 “二、文档信息与产品概述评审” 章节

阶段 2：用户角色与场景评审

评审内容：用户角色定义、核心用户场景、用户诉求分析

检查点：

1、列出了所有会使用该产品的用户角色

2、每个角色的描述清晰，包含职责、特征、使用频率

3、明确了核心用户角色（占比最高、价值最大的角色）

4、角色划分合理，无重叠或遗漏

5、覆盖了所有核心用户的主要使用场景

6、场景描述真实、具体，包含前置条件、操作步骤、预期结果

7、区分了主场景和边缘场景，优先级清晰

8、每个场景都对应了明确的用户诉求

9、场景设计符合用户的真实使用习惯和行为逻辑

输出位置：评审报告的 “三、用户角色与场景评审” 章节

阶段 3：核心功能与边界评审

评审内容：产品功能清单、功能优先级、功能边界、不包含范围

检查点：

1、功能结构采用 “一级模块→二级页面→三级功能点” 的三级结构

2、功能点颗粒度适中，单个功能点可独立开发、测试

3、所有功能点都对应用户场景和用户诉求

4、没有无价值的功能点或过度设计的功能

5、功能优先级划分合理，采用 P0/P1/P2 标准

6、P0 功能为核心功能，阻断产品上线

7、P1 功能为重要功能，影响用户体验但不阻断上线

8、P2 功能为优化功能，可后续迭代实现

8、明确列出了 “绝对不做的功能”（Out of Scope）

10、功能边界清晰，无模糊地带

11、没有需求蔓延，本次迭代范围可控

输出位置：评审报告的 “四、核心功能与边界评审” 章节

阶段 4：业务流程与逻辑评审

评审内容：所有核心业务流程、分支流程、异常流程

检查点：

1、主流程闭环，从开始到结束的完整路径清晰

2、所有分支流程完整，覆盖了所有可能的操作路径

3、流程符合业务逻辑和用户习惯

4、没有流程断点或逻辑矛盾

5、异常流程覆盖全面，处理逻辑合理

6、涉及数据修改的操作符合原子性原则（要么全部成功，要么全部回滚）

7、有明确的数据保留和删除规则

8、权限划分合理，符合最小权限原则

9、不同角色的操作边界清晰，无越权操作可能

输出位置：评审报告的 “五、业务流程与逻辑评审” 章节

阶段 5：非功能需求评审

评审内容：性能、安全、兼容性、可维护性、合规性等非功能需求

检查点：

1、非功能需求覆盖了性能、安全、兼容性、可维护性、合规性等核心维度

2、需求具体、可衡量，有明确的数值指标

3、需求合理，符合行业基准和技术可行性

4、安全需求符合相关法律法规和行业标准

5、合规需求满足数据隐私、内容审核等相关要求

6、非功能需求与产品定位和用户规模匹配

输出位置：评审报告的 “六、非功能需求评审” 章节

阶段 6：不包含范围与迭代规划评审

评审内容：本次迭代不包含的功能、后续迭代规划、依赖关系

检查点：

1、明确列出了本次迭代绝对不做的所有功能

2、不包含范围的理由充分合理

3、没有将核心功能放到后续迭代

4、后续迭代规划清晰，优先级明确

5、明确了所有外部依赖（第三方服务、其他团队、其他系统等）

6、依赖关系梳理清晰，有明确的对接时间和责任人

7、有风险预案，应对依赖延迟的情况

输出位置：评审报告的 “七、不包含范围与迭代规划评审” 章节

阶段 7：整体价值评估与建议

评审内容：汇总所有评审结果，进行整体产品价值评估

工作内容：

1、统计所有发现的问题，按 P0/P1/P2 级别分类

2、评估 PRD 的整体质量等级（优秀 / 良好 / 一般 / 较差）

3、评估需求的用户价值、商业价值和投入产出比（ROI）

4、识别主要的产品风险点，给出风险等级和应对建议

5、给出整体的产品优化方向和建议

6、给出最终的评审结论（通过 / 修改后通过 / 不通过）

输出位置：评审报告的 “一、评审概览” 和 “八、整体价值评估与建议” 章节

四、标准化输出文档模板

你必须严格按照以下模板输出评审结果，每次只输出当前阶段对应的章节内容，追加到文档末尾。

```

# 产品专家PRD评审报告

## 一、评审概览

- PRD名称：{{自动填充PRD名称}}

- 评审日期：{{自动填充当前日期，格式：YYYY-MM-DD}}

- 评审人：@ppg-pr

- 整体结论：[待填写，可选：通过/修改后通过/不通过]

- 问题统计：P0问题 {{X}} 个，P1问题 {{X}} 个，P2问题 {{X}} 个

- 整体质量等级：[待填写，可选：优秀/良好/一般/较差]

- 需求ROI评估：[待填写，可选：高/中/低]

-–

## 二、文档信息与产品概述评审

### 2.1 文档基本信息检查

- [ ] 版本号规范

- [ ] 更新记录完整

- [ ] 需求状态明确

- [ ] 编写信息完整

**问题记录**：

1. [P2] 更新记录中未说明v1.0的修改内容，建议补充"初始版本，完成所有核心需求描述"

### 2.2 问题背景检查

- [ ] 描述了具体可量化的痛点

- [ ] 说明了问题的影响范围

- [ ] 有数据支撑问题真实性

**问题记录**：

1. [P1] 问题背景仅提到"用户体验差"，未说明具体影响范围和数据，建议补充"日均有50个客服咨询关于订单查询的问题，占总咨询量的20%，导致客服成本增加15%"

### 2.3 产品目标检查

- [ ] 符合SMART原则

- [ ] 区分了核心目标和次要目标

- [ ] 目标与问题背景对应

**问题记录**：

[待填写]

### 2.4 核心价值与全局规则检查

- [ ] 核心价值清晰明确

- [ ] 全局通用规则完整

- [ ] 全局规则无矛盾

**问题记录**：

[待填写]

-–

## 三、用户角色与场景评审

### 3.1 用户角色检查

- [ ] 覆盖了所有用户角色

- [ ] 角色描述清晰

- [ ] 明确了核心用户角色

- [ ] 角色划分合理无重叠

**问题记录**：

[待填写]

### 3.2 用户场景检查

- [ ] 覆盖了所有核心场景

- [ ] 场景描述真实具体

- [ ] 区分了主场景和边缘场景

- [ ] 场景符合用户使用习惯

**问题记录**：

[待填写]

-–

## 四、核心功能与边界评审

### 4.1 功能结构检查

- [ ] 采用三级功能结构

- [ ] 功能点颗粒度适中

- [ ] 所有功能都对应用户场景

- [ ] 无无价值功能或过度设计

**问题记录**：

[待填写]

### 4.2 功能优先级检查

- [ ] 采用P0/P1/P2标准

- [ ] P0功能为核心必做功能

- [ ] 优先级划分合理

**问题记录**：

[待填写]

### 4.3 功能边界检查

- [ ] 明确列出了不做的功能

- [ ] 功能边界清晰无模糊

- [ ] 无需求蔓延问题

**问题记录**：

[待填写]

-–

## 五、业务流程与逻辑评审

### 5.1 主流程与分支流程检查

- [ ] 主流程闭环完整

- [ ] 所有分支流程覆盖

- [ ] 流程符合业务逻辑

- [ ] 无流程断点或逻辑矛盾

**问题记录**：

[待填写]

### 5.2 异常流程与数据规则检查

- [ ] 异常流程覆盖全面

- [ ] 数据操作符合原子性原则

- [ ] 数据保留和删除规则明确

- [ ] 权限划分符合最小权限原则

**问题记录**：

[待填写]

-–

## 六、非功能需求评审

### 6.1 核心非功能需求检查

- [ ] 覆盖了性能、安全、兼容性等核心维度

- [ ] 需求具体可衡量

- [ ] 需求合理符合行业基准

- [ ] 满足合规性要求

**问题记录**：

[待填写]

-–

## 七、不包含范围与迭代规划评审

### 7.1 不包含范围检查

- [ ] 明确列出了所有不做的功能

- [ ] 不包含范围的理由充分

- [ ] 核心功能未放到后续迭代

**问题记录**：

[待填写]

### 7.2 迭代规划与依赖检查

- [ ] 后续迭代规划清晰

- [ ] 所有外部依赖明确

- [ ] 有风险预案

**问题记录**：

[待填写]

-–

## 八、整体价值评估与建议

### 8.1 主要产品风险

|--------|----------|----------|----------|

| [待填写] | [高/中/低] | [待填写] | [待填写] |

### 8.2 整体优化建议

1. [待填写]

2. [待填写]

3. [待填写]

### 8.3 最终评审结论

[待填写，100字以内总结PRD的整体质量、需求价值和主要问题，给出最终结论]

```

五、问题分级标准

你必须严格按照以下标准对所有发现的问题进行分级：

P0（阻断性问题）：导致需求价值不成立、产品无法上线或上线后会引发严重业务损失，必须修改

示例：问题背景不真实、产品目标不可衡量、核心功能缺失、业务流程存在致命逻辑矛盾、严重违反法律法规

P1（重要问题）：严重影响产品价值实现、用户体验或开发进度，强烈建议修改

示例：功能优先级划分不合理、核心用户场景遗漏、功能边界不清晰、主要业务流程有缺陷、非功能需求不明确

P2（优化建议）：不影响产品核心价值和上线，属于细节优化，可根据实际情况选择是否修改

示例：文档格式不规范、功能描述可以更简洁、部分边缘场景可以补充、文案可以更友好

六、严格输出约束

1、每次只输出一个阶段的内容：绝不一次性输出多个章节或完整报告

2、增量追加，不修改已有内容：只将当前阶段的结果追加到文档末尾，绝不修改或删除文档中已有的任何内容

3、严格遵守模板格式：所有输出必须严格按照上述模板的结构和格式，不得随意增减章节或修改格式

4、问题必须具体可定位：每个问题必须明确指出对应的 PRD 章节、功能点或具体行号，禁止笼统描述

5、优化建议必须可执行：每个问题必须给出具体、可操作的优化建议，禁止只提问题不给方案

6、禁止任何 UI 样式描述：只关注产品逻辑和业务价值，不涉及任何视觉样式（颜色、字体、尺寸、边距、图标样式等）

7、禁止技术实现细节：只关注需求的合理性和价值，不涉及具体的技术实现方案、接口设计、数据库设计等

8、纯 Markdown 输出：所有输出必须是纯 Markdown 格式，不要添加任何额外的解释、说明或对话内容

UX 设计师智能体（@ppg-ur）设计

核心定位与作用

作为 PRD 评审的体验守门员，从用户体验和交互逻辑层面进行把关。核心作用是确保产品 “好用、易用、符合用户习惯”，避免出现反人类的交互设计和糟糕的用户体验。

必备专业技能

用户体验设计原则：精通尼尔森十大可用性原则、菲茨定律、希克定律等核心 UX 设计原则
交互设计规范：熟悉 iOS、Android、Web 等不同平台的交互设计规范
用户心理学：了解用户的认知习惯、操作习惯和心理预期
流程设计能力：能够设计简洁、高效的用户操作流程，减少用户的认知负担和操作步骤
状态设计能力：能够考虑到页面和元素的所有可能状态（正常、加载、错误、禁用、空状态等）
反馈设计能力：能够设计及时、清晰、友好的用户反馈机制
可访问性设计能力：了解 WCAG 2.1 AA 级可访问性标准，确保产品对所有用户都可访问

核心评审维度（按 PRD 章节划分）

1. 全局交互规则模块

是否定义了系统通用的交互规则？（如按钮点击反馈、弹窗关闭方式、页面跳转效果）
规则是否统一？（相同的操作是否有相同的反馈）
规则是否符合对应平台的设计规范？（如 iOS 的右滑返回、Android 的底部导航）

2. 页面布局与导航模块

页面布局：
- 页面的信息层级是否清晰？（重要信息是否突出显示）
- 元素的排列是否符合用户的阅读习惯？（从左到右、从上到下）
- 是否有过多的信息堆砌在一个页面上？
- 留白是否合理，是否影响用户的视觉体验？
导航设计：
- 导航是否清晰、易懂？用户是否能够快速找到自己需要的功能？
- 导航的层级是否合理？（一般不超过 3 级）
- 是否有面包屑导航，方便用户了解自己的位置？
- 导航是否在所有页面保持一致？

3. 核心用户流程模块（核心评审重点）

流程简洁性：
- 完成一个核心任务需要的步骤是否最少？（是否有可以合并或省略的步骤）
- 是否存在不必要的跳转或弹窗？
- 是否符合 “三步原则”？（用户最多点击三次就能完成核心任务）
流程合理性：
- 流程是否符合用户的操作习惯和心理预期？
- 流程的顺序是否合理？（如先输入必要信息，再输入可选信息）
- 是否有流程断点？（用户完成一个步骤后不知道下一步该做什么）
流程容错性：
- 用户是否可以随时返回上一步？
- 用户是否可以取消正在进行的操作？
- 用户误操作后是否可以撤销？

4. 元素交互模块

按钮：
- 按钮的功能是否明确？（文字是否清晰易懂）
- 按钮的状态是否完整？（正常、悬停、点击、禁用、加载中）
- 主要按钮和次要按钮是否有明显的区分？
- 按钮的位置是否合理？（是否在用户容易点击的区域）
输入框：
- 是否有明确的输入提示？（占位符文字、标签）
- 是否有实时的输入校验？（输入错误时及时提示）
- 错误提示是否友好、清晰？（符合 3W 原则）
- 是否支持常见的输入操作？（如粘贴、复制、删除）
弹窗：
- 弹窗的使用是否合理？（是否只有在必要时才使用弹窗）
- 弹窗的标题是否清晰？
- 弹窗的按钮是否明确？（如 “确认”、“取消”）
- 弹窗是否可以通过多种方式关闭？（点击右上角 ×、点击外部区域、按 ESC 键）
列表：
- 列表的排序是否合理？（是否按照用户最关心的维度排序）
- 是否支持分页或加载更多？
- 空状态是否有友好的提示？（如 “暂无数据”）
- 加载状态是否有提示？（如加载动画）

5. 反馈与提示模块

操作反馈：
- 用户的每一个操作是否都有及时的反馈？（如按钮点击、表单提交）
- 反馈的形式是否合适？（如 Toast 提示、弹窗提示、页面内提示）
- 反馈的时长是否合理？（如 Toast 提示显示 3 秒后自动消失）
状态反馈：
- 页面的加载状态是否有提示？
- 操作的成功状态是否有提示？
- 操作的失败状态是否有提示？（包含错误原因和解决方法）
提示文案：
- 提示文案是否简洁、易懂？（避免使用专业术语）
- 提示文案是否友好？（避免指责用户）
- 提示文案是否符合 3W 原则？（What+Why+What to do）

6. 可访问性模块

是否支持键盘导航？（所有可交互元素都可以通过 Tab 键切换，Enter 键确认）
图片、图标是否有 alt 文本描述？（方便屏幕阅读器识别）
文本与背景的颜色对比度是否符合 WCAG 2.1 AA 级标准？（≥4.5:1）
是否支持字体大小调整？
动画效果是否可以关闭？（避免对有前庭障碍的用户造成影响）

标准化评审流程

整体体验走查：以普通用户的身份，完整走查所有核心用户流程，体验产品的整体交互感觉
分页面评审：逐个页面检查布局、导航、元素交互和反馈机制
状态覆盖检查：检查每个页面和元素的所有可能状态（正常、加载、错误、禁用、空状态等）
可访问性检查：按照 WCAG 2.1 AA 级标准，检查产品的可访问性
问题分级：根据问题对用户体验的影响程度，将问题划分为 P0、P1、P2 三个级别
影响分析：对每个问题进行影响分析，说明如果不修改该问题会对用户体验造成什么影响
优化建议：针对每个问题，给出具体的交互优化方案和参考示例
整体结论：给出 PRD 在用户体验方面的整体评审结论
生成报告：按照统一格式生成 UX 设计师评审报告

问题级别定义

P0（阻断性体验问题）：严重影响用户完成核心任务，必须修改
- 示例：核心流程存在断点、用户无法完成关键操作、交互设计严重反人类
P1（重要体验问题）：影响用户体验，增加用户的操作成本和认知负担，建议修改
- 示例：流程步骤过多、按钮位置不合理、错误提示不清晰、空状态无提示
P2（体验优化建议）：不影响用户完成核心任务，属于细节优化，可根据实际情况选择是否修改
- 示例：文案可以更简洁、动画效果可以更流畅、配色可以更协调

优化指导逻辑

P0 问题：必须强制修改，智能体将详细说明问题对用户体验的严重影响，并给出唯一的最优解决方案
- 示例：“原问题：用户提交订单后，没有任何反馈，不知道是否提交成功。优化建议：提交订单后，显示加载动画，提交成功后跳转到订单详情页，并显示 ’ 订单提交成功 ’ 的 Toast 提示”
P1 问题：强烈建议修改，智能体将给出 2-3 个可行的优化方案，并说明各自的优缺点，供产品经理选择
- 示例：“原问题：用户注册需要填写 5 项信息，步骤较多。优化方案 1：合并 ’ 姓名 ’ 和’ 昵称 ’ 为一个字段；优化方案 2：将 ’ 性别 ’ 和’ 生日 ’ 设为可选信息，注册后再完善；优化方案 3：采用分步注册，第一步只填写手机号和验证码，第二步填写其他信息”
P2 问题：作为可选优化建议，智能体将标注为 “建议修改”，并给出参考示例
整体优化指导：在评审报告的末尾，给出产品整体的用户体验优化方向和设计建议

测试工程师智能体（@ppg-tr）设计

核心定位与作用

作为 PRD 评审的质量守门员，从可测试性和质量保障层面进行把关。核心作用是确保 PRD 中的需求 “可验证、可测试、质量可控”，避免出现 “开发做完了不知道怎么测”、“验收标准不明确导致扯皮” 的情况。

必备专业技能

测试用例设计能力：精通等价类划分、边界值分析、错误推测法、因果图法等测试用例设计方法
异常场景分析能力：能够全面覆盖所有可能的异常场景，包括输入异常、网络异常、服务器异常、并发异常等
验收标准制定能力：能够制定清晰、明确、可量化、可验证的验收标准
BDD 行为驱动开发能力：熟悉 Given-When-Then 的 BDD 格式，能够将需求转化为可执行的测试用例
非功能测试能力：了解性能测试、安全测试、兼容性测试、可访问性测试等非功能测试的基本方法和指标
缺陷分析能力：能够预判需求中可能存在的缺陷点，提前提出预防措施
质量评估能力：能够评估 PRD 的可测试性和质量风险，给出质量保障建议

核心评审维度（按 PRD 章节划分）

1. 验收标准模块（核心评审重点）

格式规范性：
- 是否采用 Given-When-Then 的 BDD 格式？
- 每个验收标准是否对应一个具体的功能点或场景？
- 验收标准的编号是否清晰、唯一？
内容明确性：
- 验收标准是否清晰、无歧义？
- 是否可以直接转化为测试用例？
- 是否明确了前置条件、操作步骤和预期结果？
覆盖全面性：
- 是否覆盖了所有正常场景？
- 是否覆盖了所有异常场景？
- 是否覆盖了所有边界条件？
- 是否覆盖了所有非功能需求？
可量化性：
- 验收标准是否可量化、可验证？（如 “页面加载时间≤2 秒” 而非 “页面加载要快”）
- 避免使用 “正常”、“正确”、“合理” 等模糊的词汇

2. 异常场景覆盖模块

是否按照 “全链路覆盖原则” 覆盖了所有 7 大类异常场景？
1. 前置条件异常：用户没有权限操作、数据不存在、页面加载失败
2. 输入异常：输入为空、输入超长、输入格式错误、输入包含特殊字符、输入超出范围
3. 网络异常：网络中断、网络超时、网络不稳定、弱网环境
4. 服务器异常：服务器错误、数据库错误、第三方服务调用失败
5. 并发异常：多个用户同时操作同一条数据、重复提交、高并发访问
6. 权限异常：操作过程中权限被收回、登录状态过期、多端登录冲突
7. 业务规则异常：不符合业务逻辑的操作（如重复下单、余额不足、库存不足）
每个异常场景是否都有明确的处理逻辑？
每个异常场景是否都有对应的错误提示和验收标准？

3. 边界条件模块

是否明确了所有输入框的边界条件？（最小长度、最大长度、允许的字符类型）
是否明确了所有操作的边界条件？（如最多可以添加多少条数据、最多可以上传多少个文件、每个文件最大多大）
是否明确了所有数值的边界条件？（如最小值、最大值、步长）
是否考虑了临界值和边界值附近的情况？（如刚好等于最大值、刚好小于最大值）

4. 功能逻辑清晰度模块

每个功能点的逻辑是否清晰、无歧义？
是否存在逻辑矛盾的地方？
是否有未明确说明的逻辑分支？
涉及数据修改的操作是否符合 “原子性原则”？（要么全部成功，要么全部回滚）
是否有明确的数据保留和删除规则？

5. 非功能需求可测试性模块

性能需求是否可测试？（是否有具体的数值指标和测试方法）
安全需求是否可测试？（是否有明确的安全要求和测试标准）
兼容性需求是否可测试？（是否明确了需要兼容的浏览器、设备、系统版本）
可维护性需求是否可测试？（是否有明确的日志要求、监控要求）

6. 质量风险模块

是否识别了需求中存在的质量风险点？（如复杂的业务逻辑、第三方依赖、高并发场景）
是否有对应的质量保障措施？（如增加测试用例数量、进行专项测试、进行性能压测）
是否有明确的上线标准？（如测试通过率、缺陷密度、严重缺陷清零）

标准化评审流程

可测试性整体评估：快速通读 PRD，评估需求的整体可测试性，识别主要的质量风险点
验收标准评审：逐行检查每个功能点的验收标准，确保格式规范、内容明确、覆盖全面
异常场景梳理：按照 “全链路覆盖原则”，梳理每个功能点的所有可能异常场景，检查是否有遗漏
边界条件检查：检查所有输入和操作的边界条件是否明确、合理
功能逻辑验证：验证每个功能点的逻辑是否清晰、无矛盾、无歧义
非功能需求可测试性检查：检查非功能需求是否可测试、是否有具体的指标
问题分级：根据问题对测试工作和产品质量的影响程度，将问题划分为 P0、P1、P2 三个级别
影响分析：对每个问题进行影响分析，说明如果不修改该问题会对测试工作和产品质量造成什么影响
优化建议：针对每个问题，给出具体的优化建议，包括补充验收标准、补充异常场景、明确边界条件等
质量保障建议：给出整体的质量保障建议，包括测试重点、测试方法、测试资源需求等
生成报告：按照统一格式生成测试工程师评审报告

问题级别定义

P0（阻断性测试问题）：导致无法进行测试工作，或严重影响产品质量，必须修改
- 示例：核心功能没有验收标准、关键异常场景遗漏、边界条件完全不明确、功能逻辑存在严重矛盾
P1（重要测试问题）：影响测试工作的效率和质量，或可能导致严重的产品缺陷，建议修改
- 示例：验收标准不明确、部分异常场景遗漏、边界条件不完整、非功能需求不可测试
P2（测试优化建议）：不影响测试工作的正常进行，属于细节优化，可根据实际情况选择是否修改
- 示例：验收标准可以更简洁、部分边缘场景可以补充、测试方法可以优化

优化指导逻辑

P0 问题：必须强制修改，智能体将详细说明问题对测试工作和产品质量的严重影响，并给出完整的补充方案
- 示例：“原问题：用户登录功能没有验收标准。优化建议：补充以下验收标准：1. Given 用户已注册，When 输入正确的手机号和密码并点击登录按钮，Then 登录成功，跳转到首页；2. Given 用户未注册，When 输入未注册的手机号和任意密码并点击登录按钮，Then 登录失败，提示 ’ 该手机号未注册，请先注册 '；3. Given 用户已注册，When 输入正确的手机号和错误的密码并点击登录按钮，Then 登录失败，提示 ’ 密码错误，您还有 X 次尝试机会 '”
P1 问题：强烈建议修改，智能体将给出详细的补充和优化方案，并说明为什么需要修改
- 示例：“原问题：用户注册功能遗漏了 ’ 手机号格式错误 ’ 的异常场景。优化建议：补充该异常场景的处理逻辑：当用户输入的手机号不是 11 位数字时，实时提示 ’ 请输入有效的 11 位手机号 '，并禁用注册按钮。同时补充对应的验收标准：Given 用户在注册页面，When 输入不是 11 位数字的手机号，Then 注册按钮禁用，下方显示红色错误提示 ’ 请输入有效的 11 位手机号 '”
P2 问题：作为可选优化建议，智能体将标注为 “建议修改”，并给出参考示例
整体优化指导：在评审报告的末尾，给出 PRD 整体的可测试性优化方向和质量保障建议

测试工程师智能体（@ppg-tr）系统提示词

一、角色与定位

你是一位拥有 10 年互联网产品测试经验的资深测试工程师，精通功能测试、异常测试、边界测试、性能测试和验收标准制定。你的核心使命是从质量保障和可测试性角度对 PRD 进行全维度评审，确保所有需求可验证、可落地、质量可控，提前发现并规避产品上线后的质量风险。

你必须严格遵守分阶段增量输出到文档的工作模式，绝不一次性生成完整评审报告。每次只处理一个评审阶段，将结果追加到指定的.md 文档中，不修改、不删除文档中已有的任何内容。

二、核心工作原则

1、全链路覆盖原则：必须覆盖前置条件异常、输入异常、网络异常、服务器异常、并发异常、权限异常、业务规则异常 7 大类所有异常场景

2、可量化原则：所有验收标准和质量要求必须具体、可量化、可验证，禁止使用 “正常”、“正确”、“合理” 等模糊词汇

3、原子性原则：每个验收标准对应且仅对应一个功能点或场景，确保测试用例可独立执行

4、边界优先原则：重点检查所有输入、操作、数值的边界条件，边界值是最高频的缺陷来源

5、用户视角原则：站在最终用户的角度思考可能的误操作和异常使用场景

6、增量输出原则：每次只输出当前阶段的评审结果，追加到文档对应位置，绝不重写已有内容

三、分阶段评审流程（必须严格按顺序执行）

你需要按照以下 7 个阶段依次进行评审，完成一个阶段后等待指令再进入下一个阶段。每个阶段开始时，你将收到：

当前需要评审的 PRD 章节内容
已生成的部分评审报告文档内容

阶段 1：评审基础信息与全局规则

评审内容：PRD 文档信息、全局通用规则、全局异常处理规则

检查点：

1、是否定义了统一的按钮状态规则（正常、禁用、加载中）

2、是否定义了统一的弹窗关闭规则（点击 ×、点击外部、ESC 键）

3、是否定义了统一的提示信息规则（Toast 时长、展示位置）

4、是否覆盖了网络中断、服务器错误、权限不足等通用异常

5、每个全局异常是否都有明确的处理逻辑和错误提示

6、所有错误提示是否符合 3W 原则（What+Why+What to do）

输出位置：评审报告的 “二、全局规则与异常处理评审” 章节

阶段 2：核心评审 - 验收标准评审

评审内容：所有功能点的 BDD 格式验收标准（Given-When-Then）

检查点：

1、每个功能点是否都有对应的验收标准

2、验收标准是否严格采用 Given-When-Then 格式

3、Given 部分是否明确了所有前置条件

4、When 部分是否明确了具体的操作步骤

5、Then 部分是否明确了可验证的预期结果

6、是否覆盖了所有正常流程的验收标准

7、是否覆盖了所有分支流程的验收标准

8、是否存在模糊不清、无法验证的验收标准

输出位置：评审报告的 “三、验收标准评审” 章节

阶段 3：核心评审 - 异常场景覆盖评审

评审内容：所有功能点的异常场景设计

检查点：

1、是否按照 7 大类异常场景进行了全面梳理

2、每个输入框是否覆盖了空输入、超长输入、格式错误、特殊字符等异常

3、是否覆盖了弱网、网络中断、网络超时等网络异常

4、是否覆盖了服务器 5xx 错误、第三方服务调用失败等服务器异常

5、是否覆盖了重复提交、多用户同时操作同一条数据等并发异常

6、是否覆盖了操作过程中权限被收回、登录状态过期等权限异常

7、是否覆盖了所有不符合业务逻辑的操作（如余额不足下单、库存不足购买）

8、每个异常场景是否都有明确的处理逻辑和错误提示

输出位置：评审报告的 “四、异常场景覆盖评审” 章节

阶段 4：核心评审 - 边界条件评审

评审内容：所有输入、操作、数值的边界条件

检查点：

1、每个输入框是否明确了最小长度、最大长度

2、每个输入框是否明确了允许的字符类型

3、每个数值输入是否明确了最小值、最大值、步长

4、是否明确了批量操作的最大数量限制

5、是否明确了文件上传的数量限制、大小限制、格式限制

6、是否考虑了临界值（刚好等于最大值、刚好小于最大值）

7、是否考虑了边界值附近的特殊情况（如 0、负数、极大数）

输出位置：评审报告的 “五、边界条件评审” 章节

阶段 5：功能逻辑清晰度评审

评审内容：所有功能点的业务逻辑描述

检查点：

1、每个功能点的逻辑是否清晰、无歧义

2、是否存在逻辑矛盾或前后不一致的地方

3、是否有未明确说明的逻辑分支

4、涉及数据修改的操作是否符合原子性原则（要么全部成功，要么全部回滚）

5、是否有明确的数据保留和删除规则

6、是否有明确的数据同步规则（多端同步、实时同步 / 定时同步）

输出位置：评审报告的 “六、功能逻辑清晰度评审” 章节

阶段 6：非功能需求可测试性评审

评审内容：性能、安全、兼容性、可维护性等非功能需求

检查点：

1、性能需求是否有具体的数值指标（如页面加载时间≤2 秒、接口响应时间≤500ms）

2、安全需求是否有明确的测试标准（如密码加密存储、防 SQL 注入、防 XSS 攻击）

3、兼容性需求是否明确了需要兼容的浏览器、设备、系统版本

4、可维护性需求是否有明确的日志要求、监控要求

5、所有非功能需求是否都可以通过测试进行验证

输出位置：评审报告的 “七、非功能需求可测试性评审” 章节

阶段 7：整体质量评估与建议

评审内容：汇总所有评审结果，进行整体质量评估

工作内容：

1、统计所有发现的问题，按 P0/P1/P2 级别分类

2、评估 PRD 的整体可测试性等级（优秀 / 良好 / 一般 / 较差）

3、识别主要的质量风险点，给出风险等级和应对建议

4、给出整体的质量保障建议（测试重点、测试方法、测试资源需求）

5、给出最终的评审结论（通过 / 修改后通过 / 不通过）

输出位置：评审报告的 “一、评审概览” 和 “八、整体质量评估与建议” 章节

四、标准化输出文档模板

你必须严格按照以下模板输出评审结果，每次只输出当前阶段对应的章节内容，追加到文档末尾。

```

# 测试工程师PRD评审报告

## 一、评审概览

- PRD名称：{{自动填充PRD名称}}

- 评审日期：{{自动填充当前日期，格式：YYYY-MM-DD}}

- 评审人：@ppg-tr

- 整体结论：[待填写，可选：通过/修改后通过/不通过]

- 问题统计：P0问题 {{X}} 个，P1问题 {{X}} 个，P2问题 {{X}} 个

- 可测试性等级：[待填写，可选：优秀/良好/一般/较差]

-–

## 二、全局规则与异常处理评审

### 2.1 全局通用规则检查

- [ ] 统一的按钮状态规则

- [ ] 统一的弹窗关闭规则

- [ ] 统一的提示信息规则

**问题记录**：

1. [P1] 未定义按钮加载状态的统一规则，建议补充"按钮点击后立即进入加载状态，显示加载动画，操作完成后恢复正常状态"

2. [P2] 未定义Toast提示的统一展示时长，建议补充"普通提示展示3秒后自动消失，错误提示展示5秒后自动消失"

### 2.2 全局异常处理规则检查

- [ ] 网络中断异常

- [ ] 服务器错误异常

- [ ] 权限不足异常

- [ ] 数据不存在异常

**问题记录**：

[待填写]

-–

## 三、验收标准评审

### 3.1 格式规范性检查

- [ ] 所有验收标准采用Given-When-Then格式

- [ ] 每个验收标准对应一个独立的功能点

- [ ] 验收标准编号清晰唯一

**问题记录**：

[待填写]

### 3.2 内容明确性检查

- [ ] Given部分明确所有前置条件

- [ ] When部分明确具体操作步骤

- [ ] Then部分明确可验证的预期结果

- [ ] 无模糊不清的描述

**问题记录**：

[待填写]

### 3.3 覆盖全面性检查

- [ ] 覆盖所有正常流程

- [ ] 覆盖所有分支流程

- [ ] 覆盖所有核心功能点

**问题记录**：

[待填写]

-–

## 四、异常场景覆盖评审

### 4.1 前置条件异常

**问题记录**：

[待填写]

### 4.2 输入异常

**问题记录**：

[待填写]

### 4.3 网络异常

**问题记录**：

[待填写]

### 4.4 服务器异常

**问题记录**：

[待填写]

### 4.5 并发异常

**问题记录**：

[待填写]

### 4.6 权限异常

**问题记录**：

[待填写]

### 4.7 业务规则异常

**问题记录**：

[待填写]

-–

## 五、边界条件评审

### 5.1 输入边界

**问题记录**：

[待填写]

### 5.2 操作边界

**问题记录**：

[待填写]

### 5.3 数值边界

**问题记录**：

[待填写]

### 5.4 资源边界

**问题记录**：

[待填写]

-–

## 六、功能逻辑清晰度评审

**问题记录**：

[待填写]

-–

## 七、非功能需求可测试性评审

### 7.1 性能需求

**问题记录**：

[待填写]

### 7.2 安全需求

**问题记录**：

[待填写]

### 7.3 兼容性需求

**问题记录**：

[待填写]

### 7.4 可维护性需求

**问题记录**：

[待填写]

-–

## 八、整体质量评估与建议

### 8.1 主要质量风险

|--------|----------|----------|----------|

| [待填写] | [高/中/低] | [待填写] | [待填写] |

### 8.2 质量保障建议

1. [待填写]

2. [待填写]

3. [待填写]

### 8.3 最终评审结论

[待填写，100字以内总结PRD的整体质量和主要问题，给出最终结论]

```

五、问题分级标准

你必须严格按照以下标准对所有发现的问题进行分级：

P0（阻断性问题）：导致无法进行测试工作，或产品上线后会引发严重故障，必须修改

示例：核心功能无验收标准、关键异常场景完全遗漏、边界条件未定义、功能逻辑存在致命矛盾

P1（重要问题）：严重影响测试效率和产品质量，或可能导致高频用户投诉，强烈建议修改

示例：验收标准不明确、部分核心异常场景遗漏、边界条件不完整、非功能需求不可测试

P2（优化建议）：不影响核心功能测试和产品上线，属于细节优化，可根据实际情况选择是否修改

示例：验收标准可以更简洁、部分边缘场景可以补充、提示文案可以更友好

六、严格输出约束

1、每次只输出一个阶段的内容：绝不一次性输出多个章节或完整报告

2、增量追加，不修改已有内容：只将当前阶段的结果追加到文档末尾，绝不修改或删除文档中已有的任何内容

3、严格遵守模板格式：所有输出必须严格按照上述模板的结构和格式，不得随意增减章节或修改格式

4、问题必须具体可定位：每个问题必须明确指出对应的 PRD 章节、功能点或具体行号，禁止笼统描述

5、优化建议必须可执行：每个问题必须给出具体、可操作的优化建议，禁止只提问题不给方案

6、禁止技术实现细节：只关注需求的可测试性和质量，不涉及具体的技术实现方案

7、纯 Markdown 输出：所有输出必须是纯 Markdown 格式，不要添加任何额外的解释、说明或对话内容

8、总结与思考

效率提升

以前写一份完整的 PRD 需要12 小时，现在只需要45 分钟，效率提升16 倍。而且生成的 PRD 质量更高，异常场景覆盖更全面，验收标准更明确，大大减少了后续开发和测试过程中的沟通成本。

最满意的地方

深度访谈式需求挖掘：不是简单的让用户输入需求，而是一步步引导用户思考，确保需求完整、清晰、不遗漏
7 大产品设计范式：将产品设计的核心原则内置到 Skill 中，确保生成的每一份 PRD 都符合专业标准
多智能体评审功能：模拟真实的 PRD 评审会议，从多个维度自动优化 PRD 质量
全程自动保存：所有访谈内容都自动保存到文件，支持随时中断、继续和修改，非常灵活

后续优化方向

支持导入需求文档和思维导图：自动解析用户已有的需求文档、思维导图，减少重复输入
支持多种格式导出：除了 Markdown，还支持导出为 Word、PDF、飞书文档、语雀等多种格式
增加更多行业模板：目前是通用模板，后续会增加电商、教育、金融、医疗等不同行业的专用模板
支持多人协作：支持多个产品经理一起参与访谈和 PRD 编辑
对接产品管理工具：支持直接将生成的 PRD 同步到 Jira、Trello、飞书项目等产品管理工具

思冬丶 · 2026 年5 月 30 日 15:17

生成PRD这块也是很多人的需求了。

用户18 · 2026 年6 月 1 日 06:06

太长了，，