Google 搜索为什么先替你补半句话？它把「想不起怎么搜」变成了「认得出哪一条」
从 Google 搜索自动补全拆解识别与回忆的认知差异，并把「候选是否真的帮用户表达」转成可直接用于设计评审的五个问题。
你在搜索框里打下几个词，下面立刻出现一串还没说完的句子。你不必先想好完整的关键词，只要在候选里认出自己要找的那一条，按一下回车就行。
Google 把这个功能叫作 Autocomplete。它处理的不是答案，而是「我大概想搜什么，却一时想不起该怎么说」这一步。这个小动作背后，藏着一个很具体的认知设计：把一部分需要从记忆里提取的查询，改成眼前可以辨认的选项。
先看 Google 到底替你做了什么
Google 官方把 Autocomplete 描述为：用户开始输入后，系统生成预测，帮助用户更快完成已经开始输入的查询。预测主要来自 Google 上已经出现过的搜索，系统会寻找与当前输入相匹配的常见或正在升温的查询。1
这里有三个容易被混在一起的动作。
| 界面动作 | 它实际提供的东西 | 用户仍然要做的事 |
|---|---|---|
| 输入前几个词 | 给当前输入接上可能的词语或短语 | 判断哪一条符合自己的意图 |
| 显示多条预测 | 把不同的查询路径同时摆出来 | 选择、修改，或继续自己输入 |
| 依据语言、地区、趋势和历史调整预测 | 给候选加上当前情境 | 检查候选是否真的适合这次任务 |
Google 的预测并不是把一个主题下最常见的查询机械地排在前面。官方示例里，同样输入
driving test，美国加利福尼亚州与加拿大安大略省会出现不同的地点词和拼写；系统还会考虑输入语言、搜索地点、趋势热度，以及登录用户的过往搜索记录。12
best star trek 后，Google 官方示例用 series、episodes、movies 等不同后缀，把一个还不完整的主题展开成几条可直接搜索的路径。1这也解释了一个重要边界：预测不是搜索结果。Google 的官方说明明确区分了两者。预测只帮助用户完成输入；用户仍然可以完整输入任何查询，预测的过滤规则不会阻止搜索结果出现。1
所以，Autocomplete 的产品承诺很窄：缩短从半句话到完整查询的路。 它没有替用户判断哪个答案可靠，也没有替用户决定真正的问题是什么。
它把回忆改成了识别
认知科学里，
recall 指从记忆中提取相关信息，recognition 指在眼前出现选项时，认出某个信息是否熟悉。Nielsen Norman Group 用一个日常例子说明两者的差别：你可能认出一个见过的人，却一时叫不出他的名字；前者是识别，后者更接近回忆。3两种任务的难度，关键不只是记忆里有没有答案，还在于当前有多少线索可以帮助提取。一个 2017 年 NeurIPS 论文提出的模型，把识别和回忆看成针对同一份记忆提出的两种不同问题：识别是在给出一个项目后寻找相关线索，回忆则是在给出较少线索后找回项目。论文的实验操纵了项目数量与线索数量，发现两种任务的相对表现会随线索和项目的比例改变。4
把这个区别放回搜索框，过程就清楚了：
- 用户先提供一个不完整的线索，例如
best star trek。 - 系统把大量可能的后续词压缩成几条可见候选。
- 用户不必从零回忆完整句子，而是在候选之间辨认「我想找的是哪一种」。
- 用户仍然可以改写候选，或忽略候选继续输入。
这不是说人类一看到候选就一定更快，也不是说候选越多越好。研究结论告诉我们，识别与回忆的相对难度会受线索数量、项目数量和任务形式影响。4 Google 的设计推断则更具体：当用户已经有一个方向，却缺少准确的词语、地点或查询结构时，候选列表能把「想不起怎么表达」变成「看见后能判断」。
为什么候选词必须带着情境出现
Autocomplete 真正有价值的地方，不是把一句话补长，而是让候选和当前情境对得上。
1. 它给模糊主题补上可选择的维度
best star trek 只说明用户想比较某个主题，却没有说明要比较剧集、单集、电影还是游戏。官方示例展示的多个后缀，实际上把「我在找什么」拆成了几种不同的查询对象。1这一步的认知作用，不是替用户添加答案，而是把原本藏在脑中的分类问题摆到眼前。用户看见
series 和 episodes 后，才有机会发现自己需要先做选择。设计师可以把它理解成一份候选维度清单：产品先猜测用户可能需要区分哪些方向，再让用户认出其中一个。候选如果只是同一句话的同义改写，用户得到的线索很少；候选之间若对应不同对象、地点、时间或任务目的，列表才真的帮用户缩短了回忆。
2. 它用地区和语言缩小检索空间
如果产品只按全体用户的热门程度排序，用户还得自己从一堆脱离情境的词里筛选。地区、语言和时间把候选空间先缩小了一步，用户才更容易在列表里认出适合当前任务的选项。Google 也提醒，Autocomplete 与 Google Trends 的用途不同；预测并不是一个单纯按搜索总量排列的热度榜。1
3. 它把「可能有用」和「一定正确」分开
候选词看起来像产品给出的答案，用户很容易把它误读成事实或推荐。Google 的官方说明专门强调，Autocomplete 预测可能令人意外，也不一定会导向可靠内容；系统会过滤一部分有害、违反政策或不太可能指向可靠内容的预测。12
这是一条产品边界，而不是一句免责声明。搜索框下的候选承担的是「帮我完成输入」的职责，搜索结果页才承担「让我继续查找和判断」的职责。设计如果把候选做成过于确定的答案样式，用户就会跳过后续判断；设计如果明确它只是可选路径，用户仍然保留修改和核验的空间。
把这个机制带回设计评审
Autocomplete 适合解决一种特定的任务：用户大致知道自己想找的东西，但很难一次想出准确的词、地点、对象或查询结构。它不适合替代意图澄清，也不适合在高风险场景里把模型猜测伪装成结论。
评审一个搜索建议、表单联想或命令提示时，可以按下面五个问题检查：
| 评审问题 | 需要观察的证据 | 常见失败方式 |
|---|---|---|
| 用户已经提供了什么线索？ | 输入里是否有足以缩小候选范围的对象、动作或情境 | 用户只输入一个过于宽泛的词，列表只能展示热门噪声 |
| 每条候选之间究竟差在哪里？ | 候选是否对应不同的对象、地点、时间或任务目的 | 多条候选只是同义改写，用户仍要自己回忆真正的分类 |
| 候选是在帮用户表达，还是替用户做决定？ | 用户能否继续修改、忽略或清空候选 | 候选被做成唯一正确答案，用户被产品的猜测带着走 |
| 情境信号是否真的参与排序？ | 地区、语言、历史或当前任务是否能改变候选，并且改变有可解释的结果 | 所有人看到同一份热门列表，地方性任务仍要人工筛选 |
| 用户选中后还需要核验什么？ | 结果页、状态提示或后续步骤是否保留验证路径 | 用户把预测当成事实，直接接受错误或不可靠的方向 |
这五个问题也给出了一个取舍顺序：先确认用户是否有明确方向，再决定要不要展示候选；先让候选之间有真正差异，再考虑排序；最后才讨论点击率或输入速度。
设计团队还可以把失败看得更具体一些。候选太少，用户得不到足够线索；候选太多，识别任务又变成新的筛选任务。热门查询很容易被排在前面，但热门只说明别人经常这样搜，不说明它适合眼前这个人。个性化历史能提供熟悉感，却也可能把过去的偏好带进当前任务。Google 的官方材料把语言、地区、趋势和过往搜索都列为影响因素，设计师就应该分别验证这些信号什么时候有帮助，什么时候会把用户带偏。12
结尾：先帮用户说出来，再把判断还给用户
Google Autocomplete 值得借鉴的地方，不是「预测」这两个字，而是它把一个复杂任务拆成了两段：产品先根据当前线索提出几条可辨认的表达，用户再决定哪一条接近自己的意图。
这个机制在用户知道方向、但缺少准确表达时最有价值。它能减少从零组织查询的负担，却不能替用户定义问题、判断信息可靠性，或承担选择后果。
设计评审时，真正值得问的不是「我们能不能给用户更多建议」，而是：用户已经知道什么？他缺的究竟是答案，还是把想法说出来的线索？ 如果缺的是线索，候选可以帮他认出来；如果缺的是判断，界面就应该把核验和比较留在下一步。
References
- 1
- 2How Google autocomplete predictions worksupport.google.com
- 3
- 4A simple model of recognition and recall memorypapers.nips.cc
认知设计日课
每天从带图的真实产品案例出发，拆解背后的认知科学原理，并把它落到设计决策上。
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.
Related content
- Sign in to comment.