G3.11.3history–suggestion source confusion设计研究
历史与建议混排会造成来源混淆
别名: 来源混淆 · mixed autocomplete · 历史混入建议
概念解释
下拉框里一行是自己上周键入的，下一行是全站热门或算法补全，两者若共用同一种样式，人就分不清「这是我的记录」还是「这是系统在推销的查询」。来源混淆（source confusion）发生在历史与建议混排、且没有可学的标记时。点错的代价不对称：把热门当历史，会发出从未想过的查询；把历史当建议，会以为那是「大家也这样搜」，敏感串被当成了公共示范。
建议降低的是构造新查询的成本；历史降低的是重复旧查询的成本。混在同一条视觉列表里，两种机制互相冒充。
机制
自动补全是再认任务：眼睛在候选上扫，工作记忆只保留「哪一行像我要的」。来源是二阶信息，需要额外的标签、分组或图标才能进工作记忆；默认不被编码。于是选择被表面相似度驱动——更短、更粗、更像当前前缀的那一行赢，不管它来自个人日志还是全局语言模型。
混淆还有归因后果。用户把发出去的查询当作自己的意图记录；若实际点的是热搜，事后的「我搜过什么」档案被污染，再找到会失败，隐私列表里也会多出不是自己写的句子。反向同样成立：个人病史查询若看起来像建议，旁观者会以为那是站点在推荐，当事人会以为系统已经把它当成了公共词。
怎么研究
测的是来源判断，不是补全是否加快输入。
- 范式：同一前缀下同时提供历史项与建议项，操纵是否分组、是否用「最近搜索 / 热门」标签；问每一次点选前「这是你写过的还是系统给的」，或在双任务下看来源判断是否崩溃。查询自动补全的日志分析可以看混排后个人项与公共项的点击比，但点本身不能区分是否知情。
- 自变量：视觉分离（分组 / 混排）、来源标签有无、历史项与建议项的文本相似度。
- 因变量：来源判断正确率、把热门误当历史发出的次数、事后能否从「我的历史」里认出自己没写过的串。
- 方法论注意点：若历史项和建议项措辞差很远，混排也不容易点错，伤害被低估。要用前缀匹配后两者都说得通的刺激。旁观条件要单独测，那是尴尬而不是效率。
边界
只有历史、没有建议的产品不存在混排问题。只有建议、不存历史的产品也没有。一人一机、历史极短时，用户可能靠内容认出自己的句子，标签的边际变小。企业受控词表下拉（从白名单里选字段值）不是建议也不是历史，混用这套来源逻辑会标错。屏幕阅读器用户听的是线性名单，分组标题比颜色和图标更关键。
怎么落地
- 历史与建议分成两个区块，各有标题（「最近搜索」「建议」），不要做成无标记的单一列表。
- 历史项用时钟或「你搜过」一类标记，建议项用另一套；颜色不能当唯一区别。
- 敏感历史默认不要出现在可能被旁观的建议位置；至少让来源一眼可判。
- 验证：把一条用户自己的查询和一条措辞相近的热门建议放在同一前缀下，问未说明规则的人「哪一行是你写的」。分不清，或点了热门却说「这是我上次搜的」，混排已经造成来源混淆。