基于事件的前瞻记忆依赖外部线索触发，基于时间的依赖内部监控
别名: 事件型前瞻记忆 · 时间型前瞻记忆 · cue-based reminder
概念解释
前瞻记忆按"什么触发了想起来去做"分成两类。基于事件的前瞻记忆（event-based prospective memory）靠环境里出现某个约定好的线索来触发——看到某个人就想起要转告TA一件事，走进厨房看到某样东西就想起要做的事；基于时间的前瞻记忆（time-based prospective memory）没有外部线索，只能靠自己持续留意时间的流逝或对照当前状态，判断"是不是到点了"，比如记得三点整要打一个电话。
机制
两者依赖的加工方式不同。基于事件的前瞻记忆可以借助一个足够清晰、独特的外部线索，在线索出现时相对自动地把储存的意图激活出来，用户不需要一直有意识地惦记着这件事，线索本身承担了大部分"提醒"的工作。基于时间的前瞻记忆没有这样的外部触发点，用户必须靠自己内部的监控过程周期性地检查"现在几点了、是不是该做了"，这个检查过程本身要占用注意资源，而且完全依赖使用者主动发起——没有人替TA按下这个检查动作，监控频率一旦被别的事情挤占就会漏检。
怎么研究
区分两类前瞻记忆的经典做法是操纵线索的性质：一组任务里植入与主线任务直接相关、显著的事件线索，另一组只给出一个时间点要求；比较两组在相同延迟下的完成率与反应延迟，基于时间的一组通常表现更差、个体差异也更大。研究者还会记录被试在等待期间主动查看时间的频率，用来验证监控行为本身消耗资源这一假设——查看频率与主任务表现之间通常存在此消彼长的权衡关系。
边界
事件线索本身的性质决定它是否真的能带来这种相对自动的优势——如果这个线索和用户当下正专注的主任务毫不相关，激活效果会大打折扣，接近甚至差于基于时间的表现，这条结论只在线索足够突出、并且落在用户当下注意力覆盖的范围内时成立。另外多数真实待办其实是两者的混合体，比如"到家以后但要等六点以后"，纯粹的事件型或时间型只是两端，大部分场景介于中间。
怎么落地
- 能设计成事件触发的提醒，优先设计成事件触发：把提醒绑定到用户必然会经过的一个具体动作或场景（打开某个应用、进入某个地点、完成某个前置步骤），而不是让用户凭空记住一个抽象时间点。
- 如果任务本身只能用时间定义（几点开会、几分钟后到期），不要假设用户会自己盯着时间监控，必须由系统主动在时间点附近发出提示，替用户完成本该由TA自己承担的监控工作。
- 验证办法：统计同一批用户在事件触发型提醒和纯时间型提醒下的按时完成率，如果时间型明显更低，说明该场景确实需要系统主动补上监控这一步，而不能留给用户自我提醒。