需求文档里写「P99 < 200ms」还是写「用户点击后 1 秒内看到结果」——为什么工程师对这两种写法的反应完全不同？

【背景】

做了 10 年产品经理，带过 3 个不同规模的团队（12 人 / 40 人 / 120 人），我发现一个反复出现的怪现象：

同样一个"性能需求"，写成两种形式，工程师的执行力天差地别——

写法 A（技术指标）：「订单列表接口 P99 响应时间 ≤ 200ms，P50 ≤ 50ms，错误率 < 0.1%」 → 工程师反应：「嗯，收到。」然后……就没有然后了。上线后 P99 是 380ms，PM 问一句，答曰「下游数据库慢，不是我们的问题」。

写法 B（用户感知）：「用户点击"提交订单"后，1 秒内必须看到结果页或明确的进度反馈；超过 3 秒需要给出可感知的进度提示（不是转圈圈）。」 → 工程师反应：「等等，3 秒给进度提示？那前端得加骨架屏 + 超时兜底……」然后真的做了。

两种写法说的其实是同一件事，但 B 的落地率明显更高。我猜原因不是"工程师懒"，而是——

【常见分歧 / 几种做法】

1. 纯指标派：PM 只写 SLA 数字（P99、QPS、错误率），理由是"可量化、可验收、可写进 SLO"。代表论据：「你总不能验收时说'感觉够快就行'吧？」
2. 场景派：PM 写用户故事 + 可感知的阈值（"1 秒内看到结果"），理由是"工程师知道 why，才会真的去优化"。代表论据：「P99 是 198ms 但用户还是觉得卡——因为他在等动画播完。」
3. 混合派：正文写场景，附录写指标。"用户 1 秒内看到结果"是验收标准，"P99 ≤ 200ms"是工程实现约束。
4. 甩锅派（我见过最多的）：PRD 里完全不写性能要求，等联调时再说"太卡了"。然后变成扯皮。

【我的倾向与理由】

我倾向混合派，但主菜是场景、配菜是指标。理由有三：

• 指标是手段，不是目的。 工程师看到 "P99 ≤ 200ms" 会本能地去找"怎么让数字达标"（加缓存、砍字段、降精度），而不是"用户到底在等什么"。看到"1 秒内看到结果"，他会去想整个链路的用户旅程——前端渲染、动画、网络、后端，哪一段在拖后腿。
• 指标会"达标但体感差"。 我见过 P99 = 180ms 但用户投诉"卡"的案例：接口确实快，但前端在等一个 200KB 的头像加载完才渲染列表。指标绿了，体验红了。
• 指标写错了比没写更危险。 PM 拍脑袋写"P99 ≤ 100ms"，工程师为了满足这个数字去砍功能、降采样、关日志——省了 30ms，丢了排查能力。如果写的是"用户能感知到流畅"，工程师会自己判断哪些该砍、哪些不能动。

但我也承认指标的不可替代性：验收、SLO、跨团队对齐必须靠数字。"1 秒内看到结果"没法写进 Grafana 告警，也没法在 SLA 合同里签字。

所以我的实操模板是：

• 正文（给工程师看的）：用户场景 + 可感知阈值 + 异常时的降级行为
• 附录（给 SRE / 运维看的）：对应的 P50/P99/P999 目标值 + 监控指标名 + 告警阈值
• 验收标准（给 QA 看的）：在什么硬件、什么网络条件下，用户操作后 N 秒内必须看到什么

【想听大家聊的】

1. 你们团队 PRD 里的性能要求，是 PM 写的还是工程师自己补的？如果是 PM 写的，工程师是"照做"还是"打回重写"？
2. 有没有遇到过"指标全绿但用户投诉体验差"的案例？根因在哪一层？
3. 反过来：有没有"体验描述很模糊，最后靠指标兜底才没翻车"的案例？
4. 最核心的问题：PM 写性能需求时，到底该写到什么颗粒度？ 写到"1 秒内看到结果"够用，还是必须拆到"首屏渲染 ≤ 800ms + 交互响应 ≤ 200ms"？再细了是不是越权了？

抛出来就想听不同角色（PM / 前端 / 后端 / SRE）的视角，看看这个"翻译"到底卡在哪。