PRD 质量审查 — 产品文档的 AI 审稿人#

#场景概述

一份 15 页的 PRD 写完了，PM 自己 review 了两遍，觉得没啥问题，发给了开发团队。三天后开发 Lead 来找你："这个用户故事没有验收标准，我们不知道做到什么程度算完。"设计师也来找你："这 3 个功能描述互相矛盾——第一页说'保留用户已填内容'，第五页又说'切换步骤时清空表单'。"

PRD 中的问题大致分三种：缺失（该写的没写）、矛盾（两处说的不一致）、模糊（写了但不可执行）。人工审查 PRD 的主要困难在于——写的人审查自己写的东西，大脑会自动补全缺失的信息。Agent 没有"脑补"能力，它只会对照你给它审查标准逐项检查——而这恰好是审稿最需要的品质。

#为什么用 Agent 审查 PRD

Agent 不是替代开发 Lead 和设计师的审查——而是在 PRD 发给他们之前先过一次完整性和一致性检查，让人类审查者把精力放在"这个设计好吗"而不是"这里是不是漏了什么"。

#前置准备

• PRD 文档：Markdown 或纯文本格式，包含用户故事、功能描述、验收标准等
• 审查标准：你的团队对 PRD 的质量要求（如"每个用户故事必须有 Given/When/Then""所有成功指标必须可量化"）
• 不做清单模板：如果有现有的 scope 约束文档，一并提供

#完整交互过程

#Step 1：把 PRD 和审查标准一起给 Agent

你是一位产品总监。请审查以下 PRD 文档，对照下列标准逐项检查。

**PRD 文档**
---
[粘贴完整的 PRD 内容]
---

**审查标准**
1. 完整性 — 每个用户故事是否包含清晰的 Given/When/Then 验收标准？
2. 一致性 — 是否有前后矛盾的功能描述或状态定义？
3. 可量化 — 所有成功指标是否可以量化？（"提升体验""改善效率"不通过）
4. 不做清单 — 是否明确了本次迭代不做的功能？
5. 边界条件 — 是否覆盖了空状态、错误状态、极端数据量？
6. 技术可行性 — 是否有明显超出当前技术栈边界的需求？
7. 依赖关系 — 是否有"依赖第三方上线但我们没法控制"的部分？

**输出要求**
- 每条问题标注严重度：Critical（阻断）/ High（重要）/ Suggestion（建议）
- 附原文摘录 + 修改建议 + 修改后示例
- 不要直接修改原文，只输出审查报告
- 最后给出总体评价：Ready / Needs Minor Fix / Needs Major Rework

#Step 2：Agent 输出审查报告

Agent 输出示例：

## PRD 审查报告
文档：团队协作看板功能 PRD v1.2 | 审查日期：2026-07-06

---

### Critical（阻断——必须修）

**C1. 用户故事缺少验收标准**
位置：第 3 节"用户故事"

原文：
> "As a 项目经理, I want 拖拽卡片到不同列, So that 状态更新更方便"

问题：只给了用户故事描述，没有 Given/When/Then 验收标准。
开发无法判断"做到什么程度算完成"。

修改后示例：

Scenario: 拖拽任务卡改变状态 Given 看板已加载，有待处理列的"登录优化"卡片 When 用户拖拽"登录优化"卡片到"进行中"列 Then 卡片移动到"进行中"列 And 后端 PATCH /api/tasks/:id/status 被调用 And 如果 API 调用失败，卡片弹回原位置 And 显示 toast 错误提示

**C2. 状态流转规则自相矛盾**
位置：第 2 节"状态定义" vs 第 5 节"交互细节"

原文（第 2 节）：
> "任务可以从 pending 直接拖拽到 done"

原文（第 5 节）：
> "done 列只接受来自 review 列的卡片，其他列拖入时显示禁止图标"

这两处描述矛盾。第 2 节说可以直接到 done，第 5 节说不可以。
需要在产品层面确认：到底允不允许跳过中间的 review 状态？

**C3. 缺失不做清单**
位置：全文搜索"不做"关键词，无匹配

建议补充不做清单。根据文档上下文，推测以下功能属于 scope 边界：
- 不做甘特图视图（PRD 提到"后续迭代"但未明确排除）
- 不做多人在线实时协作编辑单张卡片
- 不做卡片评论功能

---

### High（重要——建议修）

**H1. 移动端交互未定义**
原文全篇未提及移动端的看板行为。

建议：至少定义移动端的关键行为——
- 拖拽在移动端不适用：改为点击卡片 → 选择"移动到 X 状态"的下拉菜单？
- 卡片在窄屏上如何展示？只显示标题还是支持展开？

**H2. 成功指标不可量化**
原文：
> "核心指标：提升团队任务管理效率"

问题："提升效率"不可量化。

修改后示例：

核心指标（量化）：

1. 看板上线后 4 周，任务状态更新频率 vs 上线前 4 周， 预期提升 ≥ 20%
2. 看板页面加载时间 p95 ≤ 2s（含 100 张卡）
3. 拖拽成功率 ≥ 99%（失败 = 卡片弹回 + toast 显示）
4. 用户首次使用看板的"首次价值实现时间" ≤ 3 分钟

**H3. 不存在"加载失败"的设计**
原文覆盖了空状态和正常状态，但没有任何"API 加载失败时页面该长什么样"的描述。

建议：补充每个页面的错误状态设计——看板加载失败、拖拽 API 失败后的回滚、搜索无结果的空状态 vs 搜索出错的错误状态。

---

### Suggestion（锦上添花）

**S1. 缺少术语表**
文档中"card""ticket""task"三个词混用，可能需要统一。

建议：在文档开头确定一个术语并全文统一。推荐"card"（和看板的隐喻一致）。

**S2. 没有"风险与假设"章节**
文档直接跳到解决方案，缺少"我们假设"部分的声明。例如：
- 假设用户已有 PC 端使用习惯（拖拽不适用移动端）
- 假设团队的任务量在 50-200 之间（超过 500 的性能未验证）

---

### 总体评价：Needs Minor Fix

Critical 3 项必须修（C1+C2+C3），High 3 项强烈建议修，Suggestion 2 项可迭代。
预计修改工作量：30-45 分钟。

#Step 3：PM 修改后，Agent 增量再审

PM 根据审查报告修改 PRD 后，让 Agent 只审查变更部分：

我已根据上一轮审查修改了 PRD，新增的内容是：
- 每个用户故事的 Given/When/Then 验收标准
- 状态流转规则纠正
- 不做清单
- 量化成功指标
- 移动端行为定义

请只审查新增/修改的内容，确认修复质量。

Agent 输出：

## 增量审查报告
修复验证：5/5 通过 ✓

C1 ✓ 每个用户故事已补 Given/When/Then，验收标准完整
C2 ✓ 状态流转已统一为 pending → in_progress → review → done（done 不可直接拖入）
C3 ✓ 不做清单已补充，scope 边界明确
H2 ✓ 成功指标已量化为 4 个可测量指标
H1 ✓ 移动端定义了点击式状态切换和卡片折叠展示

本轮无新增问题。状态：Ready ✓

#要点总结

1. 审查标准必须在启动 Agent 前明确。你给什么标准它就查什么——标准越具体，输出越有价值。模糊的标准（"看看有没有问题"）产出的就是模糊的审查。
2. 原文摘录是审查报告的锚点。不要只写"第 3 节有问题"——必须引用原文具体段落。修改者不需要在全文中搜索"到底是哪句话"。
3. 修改后示例比修改建议更有用。Agent 给出的"修改后示例"让你可以直接复制粘贴到 PRD 中，比"建议补充验收标准"这种抽象的修改建议快得多。
4. 增量审查省时。PRD 修改后只需审查变更部分而非全文，大幅降低重复审查成本。
5. Agent 审查不是替代人工审查。它是开发 Lead 和设计师审查之前的"第一道筛子"——拦掉低级问题和一致性错误，让人类审查者聚焦设计质量。

#变体与延伸

• 技术方案审查：把技术方案文档给 Agent，检查是否有架构图、性能目标、回滚方案、监控指标
• 会议纪要质量检查：审查会议纪要是是否符合"结论、责任人、截止日期"的格式要求
• 周报质量检查：审查团队周报是否每个 key result 有数据支撑（而非"本周推进了 XX"这种纯叙事）
• 合同/SOW 一致性检查：检查合同中的交付范围和 SOW（工作说明书）是否一致，是否有模糊条款

#相关场景

• 用户访谈 → 需求提炼 — 文本分析 + 需求聚类
• OKR 拆解与对齐 — 目标拆解 + 一致性检查