G3.04.3approximate query offer设计研究
无结果时应主动提供近似查询
别名: 近似查询建议 · zero-result did you mean · 无结果纠错
概念解释
查询已经跑完、结果是空的，这时不要只留下「0 条」。若空很可能来自拼写或用词差一点，界面应主动提供近似查询：一两句点了就能重搜的、系统认为更可能命中的说法。它出现在自动纠正没有改写原文、或用户刚还原回原文之后——原文被尊重了，空集却还在，补救是给出下一枪，而不是坚持空页。
近似查询是一条新的查询建议，不是在同一查询下暗中塞进模糊命中。用户点了，才换成那一句；没点，当前仍是零。它也不负责解释「为什么是零」或拆掉筛选，那是零结果处理的其他动作。
机制
空集中断了查询构造的反馈环：人不知道下一枪该改哪个字符、该换哪个词。拼写纠错在这里的价值不是改写已经提交的那次，而是把「可能是这个」变成可见选项，让工作记忆不必从空白重新生成。空页上的近似查询比有结果时的自动纠正更安全——没有一份正在被观看的列表会被偷偷换掉，选择被推迟到用户看过「0」之后。
主动，是因为空页上人的默认动作是离开或随机改一个字。把候选藏在高级语法或「请检查拼写」的忠告里，等于把生成成本还回去。候选必须是可提交的查询，而不是「你可能拼错了」这种诊断：诊断不构成下一动作。若近似说法其实也是空的，给出它会制造第二次零，信任下降，所以候选要先探活再展示。
怎么研究
在真实会空的拼写变异上测「给出可点的下一查询」是否缩短恢复。
- 范式：已知项的错误拼写导致零结果，一组只显示 0，一组提供探活过的近似查询；拼写纠错 UX 研究里把「无结果后的建议」与「有结果时的自动改写」分成两套界面。查询日志看零结果之后下一次查询是否等于系统给出的那句。
- 自变量：是否展示近似查询、展示几条、是否保证候选自身非空。
- 因变量：从零恢复到命中目标的时间、采纳建议的比例、第二次仍为零的比例。
- 方法论注意点：不要用有结果的查询来测这条，否则近似查询没有出场机会。候选若未探活，失败要算在建议头上，不能算用户又拼错了。专名被当成近似目标时，要单独标记实体是否被换，以免「恢复成功」其实是找错了人。
边界
零是因为筛选过窄、范围选错、权限不足，近似查询帮不上忙，乱给拼写候选会误导归因。集合里确实没有该对象时，给出一个相关但不同的对象，是在用近邻冒充命中。语音识别错误造成的空，近似查询可能该针对同音而不是形近，来源不同，候选策略不能混用一套。用户已经看到自动纠正横幅并选择坚持原文时，再塞同一纠正当近似查询，等于无视刚才的还原。
怎么落地
- 零结果且查询像拼写或用词偏差时，在空状态里放 1–2 条已探活的可点查询，文案是那句查询本身，不是「请检查拼写」。
- 探活失败的候选不要展示；宁可少一条，不要连环空。
- 点近似查询之后走普通结果页，并允许回到原文的零结果，避免「帮忙」变成不可逆改写。
- 验证：用目标存在、仅差一两个字符的查询制造零结果。空页上若没有任何可点的下一句，主动提供没有发生；有下一句但点进去仍是零，或点进去变成另一个实体，候选不合格。