如何把 PRD 转成可测试规格

PRD 解决“为什么做”,规格解决“怎样判断做对了”。

快速结论

先保留 PRD 的业务目标,再补上 Non-goals、Acceptance Criteria、Failure Paths、Dependencies 和 Rollout Notes。这样工程团队拿到的就不再只是意图,而是可交付的约束。

你应该先看什么

可直接复用的示例

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,正确的做法是将简短的结构化缺口列表发回给 PM,而不是在实现中填补这些缺口。

PRD 到规格交接中的角色职责

从 PRD 到规格的转换既不是 PM 的任务,也不是工程的任务——而是需要双方参与的交接任务。PM 负责意图:解决什么用户问题,成功是什么样子。工程负责约束:发布范围内技术上可行的是什么,边界情况是什么。QA 负责可测试性:验收标准是否可观测到足以验证。

规格在三个角色都审阅并签字后才可开始实现。如果跳过任何角色,他们本会发现的缺口将在实现、QA 或生产中被发现——代价逐级递增。

落地建议

拿一张当前的 PRD,只做一件事:把里面所有含"提升"、"优化"、"改善"的句子,改写成"具体的输入/条件 → 可观测的结果"。这一步完成后,你已经做了 PRD 转规格中最难的部分。

如果改写时发现成功指标、非目标或依赖条件无法确定,不要让工程团队自行猜测。把这些空白作为 PRD 反馈项退回,比在实现阶段补决定更便宜。

更新日期:2026-03-10

相关文章

转换完成后的评审方式

PRD 转成 Spec 后,不要立刻进入排期。先让产品确认目标和非目标是否准确,让研发确认接口、数据和状态变化是否完整,让 QA 确认验收标准是否能转成测试。任何角色无法确认的部分,都应该回到 Spec 中补充。

一个好的转换结果不只是“工程化表述更清楚”,而是能暴露 PRD 中尚未决策的内容:默认状态、异常路径、权限限制、发布顺序、回滚条件和成功指标。

转换后如何避免 Spec 漂移

PRD 转成规格后,最容易出现的问题是两份文档继续各自变化。建议在规格顶部记录来源 PRD、转换日期、规格负责人和仍未解决的问题。之后任何范围变化都应该更新规格,而不是只修改聊天记录或会议纪要。

如果 PRD 后续新增目标,也要判断它是否属于当前版本。属于当前版本,就补进验收标准和测试计划;不属于,就明确写进非目标或下一阶段。

编辑说明

本指南涵盖 如何把 PRD 转成可测试规格,面向 Spec-First 工程团队。示例为说明性场景,非生产代码。