G3.03.2suggestion order jump设计研究
建议顺序跳变会造成误选
别名: 建议跳变 · moving autocomplete · 误触建议
概念解释
下拉列表还在根据最新前缀重排时，用户已经按旧顺序把指针或手指伸向某一行。行还在那个坐标上，内容却换成了另一条建议。这种顺序跳变造成的误选，不是用户点错了含义，是运动已经发出、目标在到达前被替换。自动补全越「聪明」、刷新越勤，列表作为运动目标就越不稳定。
误选的后果是提交了一条用户从未读完的查询。日志会把它记成「用户选了建议」，于是错误被训练进下一轮排序。
机制
指向一行建议是一次瞄准：视觉选定第 N 行，运动系统按那个坐标发出点击或敲下箭头+回车。网络延迟和逐字重排会在运动飞行过程中改写第 N 行。桌面上这是指针落点与内容错位；触屏上是手指遮住列表的同时行在跳动，更难中途纠正。键盘选中态若绑的是「第 3 行」而不是「这一条文本」，刷新后高亮还在第 3 行，回车就提交了新来的那条。
跳变还有一种更阴险的形态：列表高度忽变，下面的行被挤出，指针下突然变成空白或另一组。人按「还是刚才那一块」去点，点到的是新布局。稳定性比新鲜度更决定这项交互能不能被用来瞄准。
怎么研究
把建议列表当成会移动的靶，而不是静态菜单。
- 范式：在固定延迟下逐字刷新列表，记录指向某行过程中内容被替换的次数与误提交率；触屏与鼠标分开；查询日志中「建议点击后立即返回重搜」可作为误选的弱信号。
- 自变量：刷新是否保持行身份（同一文本留在原位）、刷新最小间隔、选中态绑行号还是绑文本、是否在指针悬停或手指按下期间冻结。
- 因变量：误选率、误选后的撤销或立即重查、主观上「列表在抢」。
- 方法论注意点：实验室网络若瞬间返回，跳变被低估。要用真实延迟或人为插入 100–300 ms。任务若要求「必须用建议」，会放大瞄准，不等于日常扫视。把误选和「建议质量差所以改主意」分开：前者发生在点击当下内容已换，后者发生在结果页上看见再改。
边界
建议只有一两条且几乎不换序时，跳变不是主问题。完全由本地词表、无网络往返的补全，刷新可以跟击键对齐，跳变窗口很短。屏幕阅读器按「当前条目文本」朗读，绑行号的实现会读出跳变后的新词，危害比误点更大，冻结策略要优先服务辅助技术。用户明确用键盘逐步把高亮移到某一条并停住时，那条应被钉住，即使新建议到来。
怎么落地
- 已渲染的建议尽量不换行号：新结果插入或追加，不要让第 2 行的文本在用户瞄准时变成另一句。
- 指针悬停、手指按下、键盘高亮停在某条时，冻结该条与其坐标，直到这次选择结束或前缀被删改。
- 选中态绑定建议文本，不绑定「从上数第几行」；回车提交的必须是高亮那句，而不是刷新后占据该槽位的新句。
- 验证：在节流网络下连续输入，看瞄准第 2 行的过程中该行文本是否被换掉。能换掉并被点走，跳变未被处理；悬停期间列表仍剧烈重排，瞄准没有被保护。