PRD 与技术规格文档：有什么区别？

把 PRD 和技术规格混为一谈的团队，最后写出来的文档两头不讨好。PRD 是一份给人看的产品文档，用来判断一件事值不值得做。技术规格是一份给人看的工程文档，用来决定怎么做以及到底做成什么样。受众不同、要回答的问题不同、保质期也不同。

发布于 2025-12-02 · ✓ 已更新 2026-05-06 · 阅读约 7 分钟 · 作者：Daniel Marsh · 审校：编辑政策

PRD 到底是做什么用的

PRD，也就是产品需求文档（Product Requirements Document），存在的意义只有一个：回答"这玩意儿该不该做"。它的读者通常不写代码，他们要判断的是：这个功能值不值投入几个 team-week、是否和战略对齐、客户的问题是不是真问题。PRD 的任务就是把这件事论证清楚。

一份合格的 PRD 包含：客户问题、问题真实存在的证据、概念层面的解决方案、预期的影响、大致的范围、粗略的时间线。它可以提一下技术上的约束，但不规定架构怎么搭。

PRD 通常由产品经理写。受众是其他 PM、工程负责人、设计，有时候是高管。要做的决策是：上还是不上，排在什么优先级。

技术规格到底是做什么用的

技术规格要回答的是另一个问题：既然决定做了，它到底要做成什么样？读者是在写代码、写测试、写上线计划的人。规格的任务是把行为说到没有歧义。

一份合格的技术规格包含：具体的验收标准、边界情况和失败模式、数据模型变更、API 契约、带数字的非功能需求、上线计划、回滚方案。它引用 PRD 来说明动机，但不会把 PRD 的内容再抄一遍。

技术规格通常由技术负责人或团队里的资深工程师来写。受众是工程、QA 和运维。要做的决策是：我们能不能把这件事做对，以及怎么知道自己做对了。

交接过程画出来是这样的

PRD                          Technical Spec
────────────────────         ──────────────────────
问题：用户在付款环节           目标：让付款环节的结账
  放弃结账                      放弃率降低 20%

方案：加"已保存的                验收标准：
 支付方式"                     - 已保存的支付方式在多个
                                 会话间持久存在（通过带
                                 user_id 和 tokenized
                                 method_id 的 DB 记录
                                 验证）
                               - 令牌化使用服务商 X
                                 （PCI DSS 要求）
                               - UI 中默认方式通过单选
                                 高亮
                               - 边界：结账打开时方式被
                                 删除 → 刷新并内联提示

影响：结账完成率                 非功能：
 提升 5%-8%                     - 结账 API p95 < 400ms
                               - 令牌保存成功率 99.9%
                               - 上线：按用户百分比灰度
                                 的 feature flag
                               - 回滚：翻转 flag，令牌
                                 留在 DB 里但不再使用

注意两者是怎么咬合的。PRD 定方向，规格把它落到具体。PRD 里的"降低结账放弃率"变成可度量的 AC；PRD 里的"已保存的支付方式"变成具体的数据模型和令牌策略。

两份文档合二为一会出什么问题

我见得最多的失败模式是：一份文档既想当 PRD，又想当规格。里头既有问题描述又有数据模型，既有客户影响又有 API 路由。四十页长，委员会合写，没人愿意读。

这种混合文档有几个具体问题：

• 对两边的受众都不合适。高管不想看 API 契约；工程师也不想为了找 AC 先翻过一堆业务论证。
• 评审被卡住。PM 读得慢，因为技术章节需要背景；工程师也读得慢，因为产品章节对他们没什么用。结果就是没人批。
• 两部分以不同速度变旧。产品层面的定调可能一个季度都还准确；技术细节却会随着实现决策不断变动。把它们混在一起，整份文档就都不可信了。

真正跑得通的顺序

先 PRD，再技术规格，不要并行。技术规格应该把"为什么"交给 PRD，而不是重新说一遍；PRD 也不该去猜实现怎么做。

• PRD 先由产品 leadership 批方向。
• 工程基于 PRD 来写规格。
• 规格评审的参与者是工程、QA、运维，而不是 PRD 的全体受众。
• 如果规格评审暴露出某件事会改变 PRD 的范围估计，就去更新 PRD，让产品再批一次。只要 PRD 当初对未知坦诚过，这种情况很少见。

谁写哪份

PM 写 PRD，工程师写规格。PM 再从用户意图的角度审一遍规格，工程师则从可实现性的角度审一遍 PRD。各自对自己那份文档有否决权，但对方给意见是默认流程的一部分。

这个分工一旦崩了，通常是两种情况。一种是 PM 替工程写规格来省时间（工程没精力、ddl 又很紧）。结果是规格没有验收标准，通篇都是散文，行为靠工程师在实现时临时编。另一种是工程师替 PM 写 PRD，理由是"PM 太忙"。结果是 PRD 变成一份没有用户问题的功能描述，功能上线后解决的是一个根本不存在的问题。

篇幅和保质期

PRD 通常 2-4 页就够一个功能用，大型专项 5-10 页。它活在功能这一层，更大的背景交给其他战略文档。功能在造的时候 PRD 都算活着的，上线之后就进入归档状态。

技术规格单个功能通常 2-5 页。它活在实现这一层。上线之后，规格变成文档——既是这个功能日常运维的参考，也是未来工程师想搞清楚"当初到底想做成什么样"的依据。

一句话自检法

对任何一份文档都可以问自己：谁会根据这份文档做决策，做的是什么决策？

• 如果答案是"产品 leadership 决定要不要排这个优先级"，那就是 PRD。
• 如果答案是"工程决定要写什么代码、QA 决定要跑什么测试"，那就是技术规格。
• 如果答案是"没人，只是随手记了一下"，那两种文档都没在干自己的活。

只需要一份文档的时候

小功能不需要两份。一句话的 PM 需求，如果"为什么"显而易见，可以直接走规格。原型或 spike 甚至可以两份都不写，把产出物当作一份 PRD-加-规格的合集，再回头喂给正式的 ticket。

规则是：如果"为什么"还有争议，就写 PRD；如果"到底做什么"还有争议，就写规格；如果两个都清楚，也许两份都不用写。

评审时看什么

这篇文章适合用在把 PRD 转成技术规格时。别从“原则”聊起，直接拿一条真实改动来对照，看看规格里还缺什么。

• PRD 保留用户价值和业务背景。
• 技术规格补行为、状态、字段、错误和发布规则。
• 把 PRD 暗示但没决定的地方列成问题。
• 最终规格要能追溯回 PRD 的原始意图。

转换后的规格应该减少会议。如果工程仍需要作者口头解释基本行为，转换还没完成。

例子：PRD 可以写“降低老用户结账失败率”；技术规格要写清保存卡是否重新 token 化、3DS 失败如何展示、哪些事件证明用户恢复成功。一个解释目标，一个锁定行为。

落地例子

结账恢复项目里，PRD 负责说明客户问题：老用户在卡失败后放弃结账。技术规格负责说明行为：token 重试规则、3DS 失败状态、幂等键处理、receipt 事件，以及新支付路径出错时如何回退。两个文档混在一起，目标和行为都会变糊。

评审时可以沿着一条用户路径检查：PRD 是否说明为什么做，技术规格是否说明每一步失败时系统怎么表现。

交接时别只传 PRD，要传决策包

PRD 解释为什么做，技术 spec 解释系统如何表现。两者之间最好有一份很短的交接包，把还没决定的事单独列出来。否则工程会把 PRD 里的愿望句当成实现规则。

PRD -> spec handoff:
- user problem: merchants need partial refunds
- product decision: support item-level refund reason
- unresolved: whether refund reason is customer-visible
- engineering decision needed: idempotency and provider timeout behavior
- QA concern: duplicate submission and role permissions
- non-goal: no refund analytics dashboard in this release

边界：PRD 不该写数据库索引，技术 spec 也不该重新定义商业目标。边界清楚，评审才不会跑偏。

两份文档要共享同一个词表

PRD 里的“退款中”、技术 spec 里的 pending_refund、API 里的 pending_provider_confirmation 如果指的是同一状态，就要在词表里对齐。命名不一致会直接传导到 UI、客服话术和测试用例。

交接包里还要列出状态词表：draft、pending、failed、refunded、cancelled 这些词在 PRD、API、数据库和 UI 中是否同义。词表对齐之后，测试和客服话术也会少很多歧义。

如果 PRD 使用用户语言，技术 spec 使用系统语言，中间最好有 mapping：用户看到“退款处理中”，API status 是 pending_provider_confirmation，数据库字段是 refund.status，客服后台状态是 Waiting for provider。mapping 一写，测试和文案都更稳。

可复制产物：交付评审包

当文章要进入计划、设计评审或发布准备时使用。它让责任人、证据和停止条件保持可见。

交付评审包：PRD 与技术规格文档：有什么区别？

本次要做的决策：
- 把责任人、门禁、证据和止损条件写到交付流程里。

责任人检查：
- 产品责任人：
- 工程责任人：
- QA 或运维评审：

范围边界：
- 本次包含：
- 本次不包含：
- 仍需确认的假设：

验收证据：
- 测试或 fixture：
- 日志、指标或截图：
- 人工复核步骤：

流程边界：实现前必须写明责任人、决策记录、证据和止损阈值。

评审追问：
- 没参加需求会的人还会误解哪里？
- 哪个证据能证明这次改动足够安全，可以发布？

编辑复核记录

复核日期：2026-04-28。本次补充了可复用产物，按相关主题 Hub 检查了文章定位，并收紧下一步链接，让页面更像可操作参考，而不是孤立长文。