容量限制与时间衰减是两种独立机制，缓解一种不能替代另一种

概念解释

"用户记不住"这个笼统的结果，背后至少来自两种彼此独立的原因：一种是同时要保持的项目数超出了容量上限，另一种是保持的时间太长导致内容自然流失。这两种原因经常同时出现在同一个失败场景里，但它们是两回事——减少同时呈现的项目数量，解决的是容量问题；缩短用户需要记住内容的时长，解决的是衰减问题；对症下药才有效，把其中一种当成另一种的替代方案通常不起作用。

机制

这两种机制可以被独立操纵而互不影响，这正是它们彼此独立的证据：只增加同时呈现的项目数、保持记忆间隔不变，回忆表现会因超出容量而下降；只延长记忆间隔、保持项目数不变，回忆表现会因衰减而下降；两者叠加时,失败率通常接近两种效应各自贡献的叠加，而不是其中一种效应吞并了另一种。这说明工作记忆的失败不是单一原因的产物,而是"同时能装多少"和"能撑多久"这两条互相独立的限制共同作用的结果，设计上想要真正解决记忆负担问题，必须先分清楚具体是哪一种在起作用。

怎么研究

区分两种机制的实验设计通常采用二因素操纵：一组条件固定记忆间隔、只改变同时呈现的项目数，观察表现如何随数量下降；另一组条件固定项目数、只改变记忆间隔的长短，观察表现如何随时间下降；再设一组同时改变两者的条件，检验两种效应是否可以近似相加。如果两种操纵各自都能独立造成表现下降，且不存在只有其中一种因素能解释另一种因素效应的情况，就可以确认二者是可分离的独立机制。

边界

这条区分在描述两种机制彼此独立时成立，但不代表实际使用场景里两者互不干扰——真实流程中，项目数量增加往往也会拖长处理这些项目所需的时间，二者可能同步恶化；这条结论提醒设计者去分别核算每一种因素造成的贡献，而不是说它们在具体场景里一定各自单独出现。

怎么落地

• 排查记忆相关的可用性问题时，先分开诊断两个维度：一是这一步骤要求用户同时保持的独立项目数有多少，二是从看到信息到需要用出来之间隔了多久，两者分别对照各自能承受的范围，不要只改动其中一项就认为问题已解决。
• 如果诊断结果是"同时项目数没超标，但间隔太长"，正确的对策是缩短流程、让信息展示与使用的时间点更接近，而不是进一步精简项目数量；反过来，如果诊断结果是"间隔很短，但同时要记的项目太多"，正确的对策是拆分或外部化部分项目，而不是指望用户加快操作节奏来抢在遗忘前用上信息。
• 验证办法：对同一个流程分别做两组改动测试——只减少项目数量的版本，和只缩短间隔时间的版本，比较两版各自对错误率的改善幅度，据此判断这个具体流程的瓶颈主要在容量还是在衰减，再决定优先修哪一个。

延伸

• 同组：A6.02.1 工作记忆同时保持的项目数有限 · A6.02.2 保持时间短且受干扰易失 · A6.02.3 跨页流程要求用户记住内容即是设计缺陷 · A6.02.4 工作记忆容量的经典估计约为四个组块，而非早期认为的七个 · A6.02.5 无复述条件下，工作记忆内容在约十几秒内自然衰退 · A6.02.6 复述可延长信息留存，但会占用同一有限的加工资源 · A6.02.7 容量随项目复杂度变化，简单项目与复杂项目不能用同一数字比较
• 相邻：A6.03 组块化 · A9.02 负荷的测量
• 站内检索：working memory load versus delay · capacity limit · time-based decay