建议不应替代用户已输入的意图
别名: 建议覆盖意图 · typed query preserved · 输入优先
概念解释
框里已经写下的字符串是用户此刻承认的意图。建议可以补全、可以示范，但不能在用户没有明确选中时，把那串字符换成更热门、更「正确」的另一句。建议不应替代已输入的意图：回车、点击搜索按钮、或失焦提交，都应按框内原文去搜；建议若被采用，必须是一次可感知的选择（点了那一行、或用键盘把高亮移到那一行再确认）。
「您是不是要搜…」放在结果页上作为可点的另一条路径，与提交前偷偷改写查询，不是同一件事。前者保留原意图并提供分支；后者让用户无法核实自己到底搜了什么。
机制
自动补全常把第一条建议当成默认。回车被实现成「接受高亮建议」，而高亮又默认落在第一条热门词上。于是「发票作废」被热门的「发票报销」顶掉——两个词共享前缀，热度却差一个数量级。用户看见框里还是自己的字（有的实现连框都改了），结果页却按另一句排，归因会落在「没有作废」而不是「查询被换了」。
替换还发生在「最佳猜测」改写：系统认为原文拼错或不够流行，未征求就把查询换成规范说法。这与拼写纠错的可见改写不同——纠错至少还承认发生了一次替换。这里谈的是建议模块越权：用列表里的一条去覆盖尚未被选中的输入。意图一旦被换，后续的筛选、排序、零结果处理都在错误的查询上工作，错误被放大而不是被纠正。
怎么研究
把「提交的查询」和「框里最后看见的字符串」做成必须核对的一对，而不是只看建议点击率。
- 范式：前缀同时匹配冷门原词与热门建议时，测量回车提交的是哪一句；眼动或回放看提交前是否扫过建议；日志中「框内文本 ≠ 实际查询参数」的比例。
- 自变量：回车是提交原文还是接受高亮、高亮是否默认落在第一条、结果页是否展示实际执行的查询。
- 因变量：意图被替换的次数、替换后用户是否发现、发现后还原原文的成功率。
- 方法论注意点：实验室若强调「请使用建议」，会把替换合法化。要设「建议可见但任务是提交你写的那句」。热门建议与原词字面相近时，用户更难看出来被换了，材料要包含近前缀、远意义的对抗对。
边界
输入法选词会改框内文本，那是用户在确认候选，不属于建议越权。命令面板里「第一条即执行」是明示的快捷约定，前提是高亮可见且与输入强相关。无障碍场景下，若焦点在建议列表里，回车接受建议是正确的——关键是焦点到底在输入框还是在列表，两处的回车语义必须分开。用户明确把一条建议点进框内之后，那条就成为新的已输入意图，此后再提交不再算替换。
怎么落地
- 输入框有焦点且建议未被显式选中时，回车和搜索按钮提交原文；不要把第一条建议设成隐式默认。
- 只有点选或键盘把高亮移到某条后，才用该条替换框内文本，并且替换要发生在框里，让用户看见新字符串。
- 结果页标题或检索条件复述实际执行的查询；若因建议而与键入不同，提供「改回搜 [原文]」。
- 验证：键入一条与第一条建议不同的完整查询，不碰列表，直接回车。结果若按建议走，意图被替代了。再看框内和结果页是否仍显示原文；两处都改成建议却无还原入口，替换是静默的。