A6.19.5Context-triggered reminders设计
系统提醒应绑定到触发情境，而非仅记录待办文本
别名: 情境绑定提醒 · 触发式待办 · contextual cueing for to-dos
概念解释
一份待办清单只保存一段文字（"给王经理回电话"），并不等于给用户提供了完成这件事所需要的支持——文本记住的是意图的内容，但前瞻记忆真正的瓶颈在于"什么时候该想起来查这份清单"。系统提醒要真正起作用，需要绑定到一个具体的触发情境：一个地点、一个应用状态、一个前置动作完成的时刻，让提醒在用户真正需要它的那一刻主动出现，而不是被动等待用户自己想起来去打开清单查看。
机制
单纯记录文本的清单把整个前瞻成分——在恰当时机重新激活意图——完全留给了用户自己的内部监控去完成，等于没有提供任何外部支持，用户仍然要靠自己判断"现在是不是该看一眼清单了"。而把提醒绑定到情境，本质上是人为地为一件事先前没有天然线索的意图，制造出一个可以被感知的触发条件：系统在检测到用户进入某个地点、打开某个应用、或完成某个前置步骤时主动推送提醒，这相当于把一个原本只能依赖内部监控完成的意图，转换成了可以被外部线索直接激活的意图，绕开了自我监控这个最容易失效的环节。
边界
情境绑定要求系统能准确判断出与该意图真正相关的触发时机——如果绑定的情境判断错误或过于宽泛（比如把"出门前记得带伞"绑定成"每次打开手机"而不是"检测到即将离开住址"），提醒会在错误的时刻反复出现，变成用户会主动忽略甚至关闭的噪声，长期下来对该提醒和同类提醒的反应都会打折。另外，并非所有意图都存在一个可被系统感知的稳定触发情境（比如纯粹主观的"想起来就联系一下老朋友"），这类意图缺少可绑定的技术线索，情境绑定这条路径本身不适用。
怎么落地
- 设计提醒功能时，先为每一类待办明确定义它对应的触发情境是地点、应用内状态还是某个前置操作，再决定用什么信号去检测这个情境，不要默认所有待办都适合用同一种时间到点提醒来处理。
- 情境的判定颗粒度要与意图的实际相关性匹配，情境定义过宽会制造大量误触发，过窄则会漏掉真正该提醒的时刻，两者都会侵蚀用户对提醒功能的信任。
- 验证办法：对比同一批待办分别采用"仅文本清单"与"情境绑定提醒"两种呈现方式后的实际完成率，并统计情境绑定提醒中误触发（情境出现但用户当时并不需要处理该事项）的比例，用两组数据共同判断绑定的情境是否选对了。