如何把 PRD 转成可测试规格
PRD 解决“为什么做”,规格解决“怎样判断做对了”。
快速结论
先保留 PRD 的业务目标,再补上 Non-goals、Acceptance Criteria、Failure Paths、Dependencies 和 Rollout Notes。这样工程团队拿到的就不再只是意图,而是可交付的约束。
你应该先看什么
- 把用户故事改写成 Given/When/Then。
- 把“提升体验”这类描述拆成可量化结果。
- 把风险最大的依赖和异常路径单独列出来。
可直接复用的示例
PRD: 支持联系人批量导入 Spec: - Goal: 1000 条以内 CSV 导入成功率 > 99% - Acceptance: 非法行要返回行号和原因 - Edge Cases: 空列、重复 email、权限不足
常见 PRD 句式与规格转写对照
PRD 使用方向性语言是因为它写给对齐用,而非实现用。一旦识别了模式,转换步骤就变得机械:用可观测结果替换方向性语言,将隐含的范围边界转为明确的非目标。
PRD 句式:"支持用户管理通知偏好"
规格转写:
目标:允许用户独立开关各类通知,不影响其他账户设置。
非目标:本次不做批量重置通知;移动端推送通知推迟到 v2。
验收标准:Given 已登录用户,When 将 email_marketing 切换为关闭,
Then preferences.email_marketing = false 持久化
And 下次营销活动不发送该用户邮件。
PRD 句式:"提升搜索相关性"
规格转写:
目标:在现有 Elasticsearch 索引内,包含全部查询词的结果优先于部分匹配。
非目标:本次不引入 ML 排序模型;不支持同义词扩展。
验收标准:Given 查询"年度报告 2024",When 返回结果,
Then 包含全部三词的文档排名高于仅包含一两词的文档。
成功信号:A/B 测试中 p90 点击位置从 4.1 降至 2.5 以下。
PRD 句式:"支持基于团队的访问控制"
规格转写:
目标:允许工作区管理员将用户分配到命名团队,并按团队成员资格限制资源可见性。
非目标:本次不做跨团队共享;不支持团队层级或子团队。
验收标准:Given 分配到 A 团队的访客用户,When 请求 B 团队拥有的资源,
Then 响应返回 403,不包含任何资源数据。
PRD 还未准备好转换的信号
并非每份 PRD 都可以直接转换。强行将不完整的 PRD 转为规格,会产生结构正确但内容错误的规格——验收标准在形式上可测试,但在实质上不对,因为底层意图从未被明确。
- 成功指标缺失。如果 PRD 没有定义对用户或业务的成功标准,规格就无法定义满足它的验收标准。先回头定义成功,再写验收标准。
- 范围内有已知的待定决策。如果 PRD 包含"待定"、"待确认"或"依赖设计"等措辞,这些决策将由写规格的人悄悄作出——未经评审。在待定决策关闭前阻止转换。
- 依赖项已命名但未确认。提到"依赖新认证服务"但未确认可用性或 API 结构的 PRD 还未就绪。规格将基于一个可能不存在或行为不同于假设的依赖项来编写。
- 灰度和回滚未被考虑。如果没有人考虑过分阶段发布或回滚,该功能的设计就是不完整的——只是部分设计。实现将单方面作出这些决策,没有监督。
对于无法转换的 PRD,正确的做法是将简短的结构化缺口列表发回给 PM,而不是在实现中填补这些缺口。
PRD 到规格交接中的角色职责
从 PRD 到规格的转换既不是 PM 的任务,也不是工程的任务——而是需要双方参与的交接任务。PM 负责意图:解决什么用户问题,成功是什么样子。工程负责约束:发布范围内技术上可行的是什么,边界情况是什么。QA 负责可测试性:验收标准是否可观测到足以验证。
- PM:撰写 PRD,确认非目标,批准规格中的目标陈述,负责成功指标定义。
- 技术负责人/工程师:将验收语言转为 Given/When/Then,识别 PRD 中不可见的技术边界情况,文档化依赖和契约影响。
- QA:审查验收标准的可测试性,标记在当前测试环境中无法验证的标准,确认错误路径和权限路径已覆盖。
规格在三个角色都审阅并签字后才可开始实现。如果跳过任何角色,他们本会发现的缺口将在实现、QA 或生产中被发现——代价逐级递增。
落地建议
拿一张当前的 PRD,只做一件事:把里面所有含"提升"、"优化"、"改善"的句子,改写成"具体的输入/条件 → 可观测的结果"。这一步完成后,你已经做了 PRD 转规格中最难的部分。
如果改写时发现成功指标、非目标或依赖条件无法确定,不要让工程团队自行猜测。把这些空白作为 PRD 反馈项退回,比在实现阶段补决定更便宜。
相关文章
转换完成后的评审方式
PRD 转成 Spec 后,不要立刻进入排期。先让产品确认目标和非目标是否准确,让研发确认接口、数据和状态变化是否完整,让 QA 确认验收标准是否能转成测试。任何角色无法确认的部分,都应该回到 Spec 中补充。
一个好的转换结果不只是“工程化表述更清楚”,而是能暴露 PRD 中尚未决策的内容:默认状态、异常路径、权限限制、发布顺序、回滚条件和成功指标。
转换后如何避免 Spec 漂移
PRD 转成规格后,最容易出现的问题是两份文档继续各自变化。建议在规格顶部记录来源 PRD、转换日期、规格负责人和仍未解决的问题。之后任何范围变化都应该更新规格,而不是只修改聊天记录或会议纪要。
如果 PRD 后续新增目标,也要判断它是否属于当前版本。属于当前版本,就补进验收标准和测试计划;不属于,就明确写进非目标或下一阶段。
编辑说明
本指南涵盖 如何把 PRD 转成可测试规格,面向 Spec-First 工程团队。示例为说明性场景,非生产代码。
- 作者详情: Daniel Marsh
- 编辑政策: 我们如何审核和更新文章
- 纠正: 联系编辑