PRD 对抗性场景：需求阶段就该想到的那些「坏事」

产品经理写 PRD 时，最容易陷入一种叫做「正常流程偏执」的状态——把所有精力放在 happy path 上，把状态机画得清清楚楚，却从不想「如果两个人同时点这个按钮会怎样」。

这不是产品的失职，而是认知盲区。我们天然倾向于设计顺序、单线程的世界，而真实系统是并发的、多用户的、充满外部干扰的。

为什么逃逸成本这么高

对抗性场景的问题，如果在 PRD 阶段发现，修改成本接近零：改一段文字，加一个状态，多画一条分支流。

但如果它在开发完成后才暴露，代价是截然不同的：数据模型可能要加字段，API 合约要改签名，前端状态管理要重写，已有数据要做迁移。一个「并发写入冲突」的缺漏，可能带来三天的返工。

更糟糕的是，这类问题很难被常规测试发现。功能测试走正常流程，QA 手动点击时不会刻意两个窗口同时操作。它们往往要等到线上真实用户触发才现形。

七个必检场景

下面是我沉淀出的清单，每次 PRD 涉及多用户协作、外部分享或持续增长的数据时，逐条过一遍：

1. 并发写入：两个用户同时编辑同一条记录，后保存者是否会无感覆盖前者的修改？需不需要乐观锁（基于 version 字段或 update_time 比对）？冲突时用户看到什么提示？

2. 操作中删除：A 正在编辑时，B 删掉了这条记录。A 点保存会发生什么？内容会丢吗？系统有没有兜底提示？

3. 操作中状态变化：多步骤流程（如审批）中，前序数据被修改了怎么办？审批人看到的是提交时的快照，还是实时最新值？

4. 数据膨胀：版本历史、操作日志、评论这类关联数据，会随时间无限增长。列表弹窗有没有分页？单条记录关联几千条子记录时页面还能正常打开吗？

5. 外部链接稳定性：对外分享的 URL 是否美观、稳定、不泄露内部 ID？路径参数设计是否经过思考，还是直接暴露数据库主键？

6. 权限边界：资源创建者账号被禁用或删除后，资源的可见性和操作权限如何处理？有没有所有权转移机制或管理员兜底？

7. 密码/Token 生命周期：用户修改密码后，旧 session 或 token 是否应该立即失效？有没有暴力破解防护？

怎么落地

我的做法是把这张清单做成 PRD 模板的一个必填章节，叫做「异常场景分析」。

不是要求产品写所有七条——而是要求产品逐条判断「是否适用」。如果某条不适用，写明理由。如果适用，写处理方案。这个动作本身就会逼着产品在需求阶段完成一次头脑风暴。

技术侧 Review PRD 时，只需要扫这一章节，确认产品的方案是否可行、是否有遗漏。比在代码 Review 时猜「这里有没有并发问题」要高效得多。

对于 AI 辅助写 PRD 的场景，直接在 prompt 里要求输出「异常场景分析」模块，效果很好——大模型对这类穷举式检查列表反而比人更稳定，不容易漏项。

一句话心法

正常流程证明系统能工作，对抗性场景证明系统值得信任。

需求阶段的一小时对抗性思考，能换来开发阶段的三天返工免疫。