A9.08.1Reserve capacity and performance insensitivity to load研究设计
主任务绩效不下降不代表负荷未增加，可能只是资源仍有富余
别名: 储备容量 · 绩效对负荷不敏感 · 主任务绩效指标
概念解释
用主任务绩效（primary task performance）本身作为认知负荷的指标时，一个常见的误判是把"绩效没有变差"直接等同于"负荷没有增加"。实际上绩效指标只有在占用的资源逼近或超过可用总量时才会开始下降，在这条边界被触及之前，负荷可以持续上升而绩效保持不变。
机制
人在完成任务时通常拥有超过刚好够用的加工资源，这部分冗余称为储备容量（reserve capacity）。只要任务需求还落在储备容量之内，新增的负荷会被这部分冗余吸收，绩效曲线在这一段几乎是平的；只有当需求超出了包括冗余在内的总容量，绩效才会明显下滑。绩效与负荷之间因此不是线性对应关系，而更像一条前段平坦、后段陡降的曲线，单看绩效在平坦段完全无法分辨负荷是刚起步还是已经逼近临界点。
怎么研究
要发现这条曲线的转折点，通常需要系统操纵任务难度做梯度设计，记录绩效指标随难度变化的完整轨迹，而不是只比较两三个条件。一个常见的方法学陷阱是仅设置一个"低负荷"和一个"高负荷"条件，发现两者绩效无差异就断言"负荷差异对操作没有影响"——如果这两个条件恰好都落在储备容量能吸收的范围内，这个结论并不成立，应当把难度梯度扩大到确实观察到绩效开始下滑，才能确认已经越过了资源边界。
边界
这个问题在储备容量较大的熟练用户或简单任务上尤其突出，绩效对负荷变化不敏感的区间会更宽；在储备容量本来就小的场景（新手用户，或者已经叠加了其他并行任务的情形）下，这段绩效指标失灵的安全区间会缩短，绩效变化能更早地反映负荷上升。
怎么落地
- 不要仅凭"用户操作速度和正确率没有变化"就判定新增的功能或信息没有增加负荷，尤其是在为熟练用户设计的高频操作场景中，绩效对负荷的滞后尤其明显。
- 应补充其他证据（主观报告或次任务表现）交叉验证，而不是只依赖绩效指标下结论。
- 验证办法：如果条件允许，把任务难度继续往上推一档做测试，观察绩效是否开始出现下滑拐点，以判断当前设计到实际储备容量边界还有多少余量。