PRD 里最容易漏的三件事：枚举、上限、默认值——联调返工 70% 都栽在这

现象与背景：返工不是出在功能，而是出在"没写全"

我做过 3 年技术 PM，复盘过 14 个迭代的联调返工单，一个反直觉的结论：导致前后端联调返工的工单里，约 70%（9/14）根因不是"功能做错"，而是"PRD 没写全"。具体三类高频缺失：

• 枚举没列全：状态机只写了"待支付/已支付"，漏了"已取消/已退款/退款中"，前端写死两个分支，后端实际吐 5 个，上线当天客服工单直接爆掉。
• 上限没写：备注字段"随便输"，用户输了 2000 字，前端没截断、后端 VARCHAR(512) 直接 500。
• 默认值没定：分页 size 不写，前端传 0、后端当 10、第三方当 100，三个系统各算各的。

影响规模：这 3 类问题平均每个吃掉 1.5 人日的联调返工，一个季度下来约 10 人日，而且越是需求越简单，越容易漏——因为"看起来都懂了"。

原理或根因：为什么"大家都懂了"反而最危险

根因是口头共识 ≠ 可执行契约。PRD 里写"状态有几种""备注随便输"，听起来清楚，但它依赖每个读者脑内补全那部分。而"脑内补全"这件事，PM、前端、后端、测试四个人补出来的是四份不同的东西。

机制上有一个放大器：信息在"默认不写"的字段上，传递路径越长，失真越多。一个字段从 PRD → 后端接口设计 → 前端渲染 → 测试用例，每经过一个没写清的"空白"，就被填一次默认值。四个环节 × 三种缺失类型，就是 12 个潜在失真点。枚举尤其危险，因为它是离散集合——漏一个值，前端 if-else 就是死分支，后端 switch 就是 default 兜底，两边都不报错，直到生产才炸，这是最阴的一类。

对比一下：写清楚的字段，四个环节读到的是同一份事实；没写清楚的字段，四个环节读到的是四份想象。返工率就是这么来的。

具体做法：把"三件套"固化进 PRD 模板

我在 PRD 模板里强制加了一个"字段契约表"，每个涉及数据的字段必须填全这三列。以"订单状态"为例：

字段: orderStatus
类型: enum
枚举值: PENDING_PAY / PAID / SHIPPED / CANCELLED / REFUNDING / REFUNDED
默认值: PENDING_PAY
非法值处理: 返回 400 + code=INVALID_STATUS，前端展示"状态异常"

再给一个可直接抄的 checklist，写 PRD 时逐条勾：

[ ] 每个 enum 字段：枚举值列全了吗？非法值怎么处理？
[ ] 每个可输入字段：最大长度？最大条数？上限是多少？
[ ] 每个可空字段：默认值是什么？null 还是空串还是 0？
[ ] 每个列表接口：分页 size 上限？排序字段？默认排序？
[ ] 每个时间字段：时区？时间戳还是字符串？格式？
[ ] 每个金额字段：单位（元/分）？精度几位？

一个真实数字：加了这张表之后，我负责的两个迭代，联调返工单从 3 个/迭代降到 1 个/迭代，返工人日从 4.5 降到 1.5。

踩过的坑与反直觉之处

1. 枚举"留一个 OTHER 兜底"是偷懒不是方案。我见过后端加 UNKNOWN 兜底、前端加 default 分支，两边都"不报错"，结果一个脏数据状态在系统里流转了三周没人发现。兜底分支应当打告警日志，而不是静默通过。
2. 默认值写"由后端决定"等于没写。这句话听起来把决定权交出去了，实际是把返工埋进了联调期。PM 必须给出业务默认值，技术实现细节可以另议，但业务默认值不能空。
3. 上限写"较大"是无效信息。"最多几百条""长度稍长"这类描述，四个读者补出四个数。必须是具体数字，哪怕先拍一个 200，也比"稍长"强 100 倍。
4. 反直觉的是：字段越简单越要写全。"备注"两个字看起来最不需要设计，恰恰是最容易翻车的——因为它太简单，PM 会跳过契约表。

结论与可复用清单

一句话：PRD 的质量不在功能多完整，而在"空白字段"有多少。空白字段就是未来联调期的返工单。

可复用清单（建议贴进你的 PRD 模板）：

1. 每个 enum 字段 = 枚举值列全 + 默认值 + 非法值处理，三样缺一不可。
2. 每个可输入字段必须有具体数字上限，拒绝"较大/稍长"。
3. 业务默认值由 PM 拍板，不许写"由后端决定"。
4. 列表接口写全：size 上限、排序字段、默认排序、时区。
5. 金额写清单位与精度；时间写清时区与格式。
6. 兜底分支必须告警，不允许静默 default。
7. 评审时专门问一句："这个字段没写的部分，你脑内补的是多少？"——问出来就是漏了。

把"三件套"从自觉变成模板强制，返工率会肉眼可见地降下来。