M3.03.3filter instead of reading long lists设计研究
超过少量条目应改为筛选
别名: 改筛选勿通读 · spoken list to filter · 列表改约束
概念解释
条目一超过少量，对话应从朗读改成筛选。手腕上的设备积了十二条通知，不要从头念到尾，问「工作、消息，还是运动？」电影院售票柱上的排片同样：先收约束，再决定还值不值得读。筛选是把集合变成一个可答的问题，用用户已经有的潜伏条件（时间、类型、发件人）换掉十二段耳朵时间。这不是因为工作记忆装不下那么多口头选项才改口——装得下，通读也仍然贵。改的是呈现策略。
机制
串行朗读的成本随 N 涨；筛选的成本随用户叫得出的维度涨。消费类集合（航班、餐厅、通知、场次）里，人通常已经带着一条约束。问出那条约束是一轮；把十二项读完是十二轮听。对话从「我来念清单」转成「你来收窄查询」。即便听者能记住十二个标签，时间账仍不划算。筛选不是把 N 削到某个记忆上限再继续念，而是尽早离开逐条呈现。没有叫得出的维度（十二条同等资格的验证码），筛选问不出东西，这条才不适用。
怎么研究
同一批十到十五个真实候选项：条件甲通读；条件乙先问一个筛选问题，再读剩下的。因变量是选中时间、选择质量、放弃。自变量是 N，以及数据里是否真有用户会说的那个维度。
若乙条件问的维度在数据里不存在，测到的是空转，不是筛选失败。不要用「读完为止的满意度」代替时间——通读可以听着完整，同时把人留在磁带上直到放弃。
边界
用户明说「都念一遍 / 菜单上有什么」。法定必须线性披露的清单（全部副作用）不能伪装成筛选。N 只有两三个，先问约束是多余的一轮。维度不在数据里还要问，是演戏。把筛选做成又一个口头大菜单（「请选择按时间、影厅、语言、字幕……」），只是换了一份长列表。
怎么落地
- 超过大约三到五项，第一动作是一条筛选问句，不是开始读。
- 筛选维度从用户真正会说的话里挑（几点、谁发的、哪类），不要从内部字段枚举。
- 筛完仍超过少量，再问下一刀，而不是改回通读。
- 验证：N 大于五的技能里，有多少会话走进通读、有多少走进约束轮。通读占主导，就是筛选根本没被提供。