原型的性能不代表成品性能
别名: 原型性能谬误 · 原型不代表成品性能 · prototype latency fallacy
概念解释
可交互原型常常跑在本地、用缓存数据、无并发、无真实网络，于是点击后“立刻出结果”。把这种顺畅读成成品也会顺畅，是原型性能谬误（prototype performance fallacy）。原型性能既可能更好——没有生产查询、没有权限层；也可能更差——解释型工具、巨型设计文件、未优化的动效。无论方向如何，它都不是对发布后延迟、吞吐和稳定性的测量。可用性结论若建立在“来得及看清反馈”之上，换到慢网络或大数据量时可能整体翻转。
机制
人对系统是否可用的判断高度依赖响应窗口。延迟改变策略：人会重复点击、放弃、改用其他入口，或把失败归咎于自己。原型若总在这个窗口之内，这些策略根本不会被触发，于是错误恢复、取消和进度提示都得不到检验。反过来，设计工具里的卡顿会被误当成产品问题。性能还与内容规模耦合：十条演示记录的列表滚动，无法代表一万条真实记录。把实验室里的完成时间、满意度拿去外推线上体验，等于用错误的物理条件测量同一界面。
怎么研究
需要性能相关结论时，必须把延迟、数据量和并发当作自变量或至少当作记录条件。做法包括：在原型上注入可控延迟、用接近生产规模的数据集、在目标网络档位上复测。比较“零延迟稿”与“按生产 p95 注入延迟”下的放弃率和补偿行为。不要报告未注明硬件与网络的完成时间。若只能在设计工具里测，结论范围应写成“在即时反馈条件下的流程理解”，而不是“产品够快”。
边界
许多早期问题——标签是否可懂、入口是否找得到——对延迟不敏感，此时不必为了“真实性能”推迟测试。性能敏感的是实时协作、支付、搜索、媒体和任何以毫秒反馈为确认的控件。移动弱网、地理分布的后端、以及首次冷启动，往往是实验室原型永远模拟不到的尾部。专家用户对延迟的容忍也与新手不同，用内部员工的“还行”外推大众用户不可靠。
怎么落地
- 在测试报告里写明原型的运行环境：本地或远程、数据条数、有无注入延迟。
- 对搜索、提交、同步类任务，至少做一档按生产延迟注入的复测。
- 禁止把设计工具里的“很顺”写进性能或稳定性结论。
- 若无法注入延迟，就把性能列为未测，并单独排期用接近生产的构建验证。