需求评审与验收标准写作模板包（5 份文档 + 3 个改写示范）

一句话导读：这套模板适合 5–50 人规模的产品团队——不需要大厂级别的需求管理平台，但需要比"口头对齐"更结构化的协作方式。2 人全栈小队用文档 1+3 即可；50 人+ 多团队协作建议把文档 2 嵌入评审会流程，文档 4 给项目经理用。

文档 1：PRD 模板（含 AC 章节）

何时用：每次启动新功能/新需求前，产品经理用本模板起草 PRD。 怎么用：按 7 个章节依次填写，每节先读"填写说明"再动笔，写完对照"反例"自查。 不适用：纯 bugfix、紧急 hotfix、内部工具。

一、背景

填写说明：用 2–3 句话讲清"为什么要做"。必须包含：① 当前痛点（最好有数据）；② 不做的代价。 反例：❌ "为了提升用户体验"——没有数据、没有代价、没有因果。 正例：✅ "过去 30 天购物车→支付页跳出率 23%（日均流失 1400 单），主因是支付页加载 >4s。不做此优化，Q4 GMV 预计少 200 万。"

二、目标

填写说明：写 1–3 个可量化目标（North Star Metric）。每个目标必须有数字 + 时间窗口 + 测量方式。 反例：❌ "提升转化率"——提升多少？多久？怎么量？ 正例：✅ "支付页 P95 加载时间从 4.2s 降至 1.5s（2026-12-31 前），通过 Sentry RUM 埋点衡量。"

三、用户故事

填写说明：用"作为[角色]，我希望[功能]，以便[价值]"格式。每个故事对应一个功能点。 反例：❌ "作为用户，我希望整个购物流程都很顺畅"——太抽象，无法拆解。 正例：✅ "作为正在支付的买家，我希望看到实时的优惠券抵扣金额，以便确认最终支付价格。"

四、功能清单

填写说明：表格列出每个功能点，含：编号 / 功能描述 / 优先级（P0/P1/P2）/ 依赖项 / 预估工时。P0 不超过 5 个。 反例：❌ 20 个功能全标 P0——等于没有优先级。 正例：✅ P0：支付页骨架屏、优惠券实时计算、错误提示优化；P1：支付方式排序、历史地址快捷选择。

五、验收标准（AC）

填写说明：每个 P0/P1 功能必须有 ≥2 条 Given-When-Then 格式 AC。必须覆盖 5 类边界：空、满、并发、异常、权限。详见文档 3。 反例：❌ "功能正常即可" / "性能要好"。 正例：✅ Given 用户已登录且购物车有 3 件商品；When 点击"去支付"；Then 支付页 2s 内展示商品列表、优惠金额、实付金额，且金额与购物车页一致（误差 ≤0.01 元）。

六、数据埋点

填写说明：列出需新增/修改的埋点事件，含：事件名 / 触发时机 / 参数列表 / 上报方式（实时/批量）。 反例：❌ "加一些埋点"——哪些？什么参数？ 正例：✅ 事件名 payment_page_load_complete，触发：支付页 DOM 就绪 + 首屏渲染完成，参数：load_time_ms、coupon_applied(bool)、payment_method，上报：实时。

七、上线与回滚方案

填写说明：包含 ① 灰度策略（比例/人群/地域）② 回滚触发条件 ③ 回滚操作步骤（谁执行、多久完成）④ 数据兼容性说明。 反例：❌ "上线后观察"——观察什么？谁观察？多长？ 正例：✅ 灰度：5% 内部→20% 低活→全量，每阶段观察 24h；回滚条件：支付成功率下降 >2% 或 P95 延迟 >3s 持续 5min；回滚操作：SRE 执行 kubectl rollout undo，<5min 完成。

文档 2：需求评审 Checklist（11 项）

何时用：PRD 评审会前 30 分钟自查 + 会上逐项过。 怎么用：逐项打勾，任何"不通过"必须当场给出修复方案或明确 deadline。 不适用：纯技术内部方案评审。

| # | 维度 | 检查项 | 通过标准 | |---|------|--------|----------| | 1 | 完整性 | 背景是否包含痛点数据 + 不做的代价 | 有具体数字 | | 2 | 完整性 | 每个 P0 功能是否有对应 AC | 1:1 对应 | | 3 | 完整性 | 上线/回滚方案是否含 4 要素（灰度/触发/操作/兼容） | 4 项齐全 | | 4 | 一致性 | 目标指标与 AC 指标是否一致 | 无矛盾 | | 5 | 一致性 | 用户故事与功能清单是否一一对应 | 无遗漏/多余 | | 6 | 可测性 | 每条 AC 是否可被 QA 独立判定通过/不通过 | 无"大概""基本"等模糊词 | | 7 | 可测性 | 性能类 AC 是否含 P95/P99 + 阈值 + 测量方式 | 有数字+工具 | | 8 | 依赖风险 | 是否列出外部依赖 + 影响评估 | 有依赖表 | | 9 | 依赖风险 | 数据迁移/兼容性风险是否有应对方案 | 有 fallback | | 10 | 数据合规 | 是否涉及用户隐私数据 + 标注脱敏/加密要求 | 有合规检查 | | 11 | 数据合规 | 埋点参数是否含用户 ID 等敏感字段 + 标注用途 | 最小化原则 |

文档 3：验收标准（AC）写作指南

何时用：写 PRD 的 AC 章节时 + 评审时逐条检查。 怎么用：先写 Given-When-Then 骨架，再补 5 类边界条件，最后对照"好/坏 AC 表"自查。 不适用：探索性需求（还在调研阶段）。

3.1 Given-When-Then 写法

Given  [前置状态：用户是谁、系统处于什么状态]
When   [触发动作：用户做了什么 / 系统发生了什么]
Then   [预期结果：可观测的、可判定的输出]

关键原则：

• Given 要具体到数据状态（"购物车有 3 件商品"而非"用户有商品"）
• When 只写一个动作（不要"When 用户浏览并点击并输入"）
• Then 必须可判定（"展示金额 199.00 元"而非"展示正确金额"）

3.2 五类边界条件（每条 AC 必须覆盖）

| 边界 | 含义 | 示例（支付功能） | |------|------|-----------------| | 空 | 数据为空/不存在 | 购物车为空时点"去支付"→ 提示"购物车为空" | | 满 | 达到上限 | 优惠券叠加上限 3 张，第 4 张 → 提示"已达上限" | | 并发 | 多用户/多端同时操作 | 同账号 2 台设备同时下单 → 只成功 1 笔 | | 异常 | 网络断开/服务降级 | 支付接口超时 5s → 展示"支付处理中，请 30s 后刷新" | | 权限 | 无权限/角色不匹配 | 未登录用户点"去支付"→ 跳转登录页 |

3.3 好 AC vs 坏 AC 对照表（12 组）

| # | 坏 AC | 好 AC | 改了什么 | |---|-------|-------|----------| | 1 | 性能要好 | P95 响应时间 ≤ 200ms（k6 压测，100 并发） | 加了数字+工具+并发数 | | 2 | 兼容主流浏览器 | Chrome 120+ / Safari 17+ / Firefox 121+ 首页渲染无 JS 报错（Lighthouse ≥ 90） | 指定版本+判定标准 | | 3 | 支持多端 | iOS 16+ / Android 13+ / Web（Chrome 120+），三端功能对齐率 100%（对照功能清单逐项检查） | 指定系统版本+对齐标准 | | 4 | 数据不能丢 | 写入后 3s 内可读到，故障时最多丢 1s 数据（RPO ≤ 1s） | 加了 RPO 指标 | | 5 | 接口要稳定 | 可用性 ≥ 99.95%（月度），错误率 < 0.05%（Prometheus 告警阈值） | 加了百分比+监控方式 | | 6 | 支持批量导入 | 单次最多 10000 行 CSV，≤ 30s 完成，失败行生成错误报告（含行号+原因） | 加了上限+时间+失败处理 | | 7 | 权限要安全 | 非 Owner 角色访问 → 403 + 审计日志（含 IP/时间/操作），日志保留 180 天 | 加了状态码+日志要求 | | 8 | 要能搜索 | 10 万条数据内搜索 ≤ 500ms（P95），支持模糊匹配（≥2 字符前缀） | 加了数据量+延迟+匹配规则 | | 9 | 要能回滚 | 回滚后 5min 内恢复到上一版本，数据不丢失（版本号 + 快照机制） | 加了时间+数据保障 | | 10 | 移动端体验好 | 首屏可交互 ≤ 3s（4G 网络，中端机），操作反馈 ≤ 100ms | 加了网络条件+设备+延迟 | | 11 | 文件上传要快 | ≤ 10MB 文件上传成功率 ≥ 99.9%，> 10MB 自动分片（2MB/片），断点续传 | 加了大小阈值+分片策略 | | 12 | 要支持国际化 | 首版覆盖中/英/日/韩 4 语言，文案 key 覆盖率 100%（无硬编码中文） | 指定语言+覆盖率标准 |

文档 4：技术评审"翻译"清单（12 条）

何时用：技术方案评审会上，把技术决策翻译成业务方/客户能听懂的话。 怎么用：左边是工程师会说的话，右边是业务方能理解的话，中间是适用场景。 不适用：纯技术团队内部讨论。

| # | 技术说法 | 业务说法 | 适用场景 | |---|---------|---------|---------| | 1 | 用 K8s 做容器编排 | 给每个服务配了一个"自动管家"，挂了自动重启，流量大了自动扩容 | 向客户解释架构 | | 2 | P99 延迟 200ms | 100 个请求里最慢的那个也要 200ms 内完成，用户感知不到等待 | 向业务方汇报性能 | | 3 | RPO ≤ 1s | 最坏情况丢 1 秒数据，换算到订单系统约 3 笔 | 向业务方解释容灾 | | 4 | 用 Redis 做缓存 | 把高频查询结果"抄一份"放内存里，响应快 10 倍，但重启会丢 | 解释缓存取舍 | | 5 | 微服务拆分 | 把大系统拆成 8 个小组独立开发，改一个不影响其他，但需要"组间协议" | 解释架构演进 | | 6 | 用 Kafka 做消息队列 | 相当于"快递中转站"，下单和发货不用同时完成，解耦了 | 解释异步架构 | | 7 | CI/CD 流水线 | 代码提交后 10 分钟内自动跑完测试并部署到预发，不用人工操作 | 解释交付效率 | | 8 | 用 ArgoCD 做 GitOps | 所有变更都走 Git 提交，可追溯、可回滚，不会出现"谁手动改的" | 解释变更管理 | | 9 | Service Mesh 做 mTLS | 服务间通信全部加密，即使内网被攻破也读不到数据 | 向安全/合规汇报 | | 10 | Prometheus + Grafana 做监控 | 7×24 小时盯着所有关键指标，异常 30 秒内告警，不用人盯屏幕 | 解释可观测性 | | 11 | 用 eBPF 做可观测性 | 不用改代码就能看清每个请求走了哪条路、卡在哪一步 | 解释零侵入监控 | | 12 | 用 Terraform 做 IaC | 所有环境配置都写成代码，新环境 10 分钟搭好，不会出现"这台机器我改过" | 解释环境管理 |

文档 5：需求复盘模板（上线后 30 天）

何时用：功能上线满 30 天时，产品经理组织 30 分钟复盘会。 怎么用：会前填"目标达成度"表格，会上讨论"偏差原因"，会后 48h 内输出"下期改进"。 不适用：紧急 hotfix / 纯 bugfix。

5.1 目标达成度

| 目标 | 预设值 | 实际值 | 达成率 | 备注 | |------|--------|--------|--------|------| | （例）支付页 P95 加载 | ≤ 1.5s | 1.8s | 83% | 低端机拖后腿 | | （例）支付转化率 | ≥ 95% | 93.2% | 98% | 接近目标 | | （例）用户投诉量 | ≤ 5 条/周 | 2 条/周 | 200% | 超额完成 |

5.2 偏差原因分析（5 Why 法）

偏差描述：____ Why 1：____ Why 2：____ Why 3：____ 根因：____ 改进动作：____（负责人 + deadline）

5.3 下期改进

| # | 改进项 | 优先级 | 负责人 | deadline | |---|--------|--------|--------|----------| | 1 | | P0/P1/P2 | | | | 2 | | P0/P1/P2 | | | | 3 | | P0/P1/P2 | | |

5.4 经验沉淀

• 这次做对了什么（继续保持）：____
• 这次做错了什么（避免再犯）：____
• 学到了什么新东西（分享给团队）：____

改写示范 1：「性能要好」

改写前：性能要好，用户体验要流畅。

改写后：支付页首屏可交互时间 ≤ 3s（4G 网络、骁龙 855 中端机、Chrome 120），操作反馈延迟 ≤ 100ms（按钮点击到视觉反馈），列表滚动帧率 ≥ 55fps（60Hz 屏幕）。测量方式：Lighthouse Mobile 模式 + 自研 RUM 埋点 page_interactive_ms。

为什么这样改：原句"性能好"是主观形容词，开发可以理解为"能跑就行"，测试无法判定通过/不通过。改写后：① 指定了具体指标（时间/延迟/帧率）；② 指定了测量条件（网络/设备/浏览器），排除了"在我电脑上很快"的争议；③ 指定了测量工具（Lighthouse + RUM），QA 可以独立复现。

改写示范 2：「兼容主流浏览器」

改写前：系统需兼容主流浏览器，确保用户正常使用。

改写后：最低支持：Chrome 120 / Safari 17 / Firefox 121 / Edge 120（对应 2025-09 版本）。功能验收范围：核心交易流程（浏览→加购→支付→订单详情）在上述 4 浏览器 × 2 分辨率（1920×1080 / 1366×768）共 8 种组合下，无 JS 报错（Console error = 0）、无布局错乱（元素溢出视口 = 0）。不支持 IE / 不支持 Safari 16 及以下。

为什么这样改："主流浏览器"是移动靶——2020 年的"主流"和 2026 年不同，不同团队定义也不同。改写后：① 锁定了具体版本号（有明确边界）；② 定义了"兼容"的判定标准（无 JS 报错 + 无布局错乱），不是"能打开就行"；③ 明确了不支持的范围（IE / Safari 16-），避免用户报"我在 IE 上打不开"的工单。

改写示范 3：「支持多端」

改写前：该功能需要支持多端，包括 PC、H5、App。

改写后：三端功能对齐清单（100% 覆盖）：

• Web（PC）：Chrome 120+ / Edge 120+，分辨率 ≥ 1366×768，支持键盘快捷键
• H5（移动浏览器）：iOS Safari 17+ / Android Chrome 120+，屏幕 ≥ 375×667px，支持手势操作
• App：iOS 16+ / Android 13+，包体积增量 ≤ 5MB，离线可用（核心流程）

验收方式：三端功能对照表（见附件），QA 逐条打勾，任何一端缺失即不通过。差异说明：App 独有"推送通知"功能，Web/H5 无此能力（标注为 N/A，不算缺失）。

为什么这样改："多端"没有定义"哪几端""什么版本""功能是否对齐"。开发可能只做 Web，测试可能只测 App，业务方可能期望三端完全一致。改写后：① 列出了具体端 + 系统版本 + 最低硬件；② 明确了"100% 功能对齐"的验收标准；③ 提前标注了合理差异（App 独有推送），避免验收时扯皮；④ 给了 QA 明确的验收工具（对照表逐条打勾）。