需要同义词与模糊匹配支撑
别名: 命令同义词 · fuzzy command search · 词汇问题
概念解释
即使用户知道要找的那一类动作，他们用的词也往往不是产品写在菜单上的那个词。同义词与模糊匹配（command synonym matching）让「删除 / 去掉 / 回收站 / del」落到同一条命令。面板以名称为索引，名称一窄，回忆通道就会在「词没对上」处断开——人不是不知道要找什么，是不知道你们管它叫什么。
机制
这是经典的词汇问题：设计者选一个标签，用户带着另一个标签来搜。精确子串匹配只覆盖碰巧共用词根的情况。「Find」搜不到「Search」，「Archive」搜不到「Hide from inbox」，拼写差一个字母就零结果。人会改写一两次，然后判定功能不存在。同义词表、常见缩写、反向操作的名称（「取消固定」也要能被「unpin」找到）把多条口语映射到同一记录。模糊匹配（编辑距离、分词、拼音）覆盖拼写和语序，但不能代替同义词：两个毫无公共字母的词，模糊也帮不上。
排序同样关键。模糊一旦放得太松，结果里会出现一堆勉强相似的项，真正目标被挤出第一屏，匹配在数学上成功了，在选择上仍失败。上下文加权（当前编辑器里的命令优先）能把对的那条托上去。
怎么研究
收集真实查询（日志里的零结果和改写链），做成一组「用户说法 → 目标命令」的测试集。自变量是精确匹配、加同义词、再加模糊。因变量是第一屏命中率、改写次数、零结果率。
不要用设计者自己会搜的名称当测试集，那会系统性低估词汇问题。跨语言用户应用他们的语言查询测一遍。
边界
同义词过多会把无关命令拉进来（「open」匹配过多）。法律或破坏性命令需要更紧的匹配，避免「del」误中「部署」。内部代号不应作为主匹配，除非那是用户社区已经在用的叫法。没有语料时先做小规模开放式命名：给动作看演示，问他们会搜什么，再把高频说法写进同义词，而不是闭门造词。
怎么落地
- 为每条命令维护一份可搜名称：官方标签、口语同义词、反向操作名、常见缩写。
- 零结果时提供「没有匹配」和可能的拼写建议，不要 silently 给出毫不相关的一长串。
- 用真实零结果日志每月补词；第一屏经常被错的命令挤占时收紧模糊、加强上下文加权。
- 验证：拿用户说法而不是官方标签跑一遍查询，目标应出现在第一屏。零结果里凡是事后被证明「功能存在」的查询，都是缺词。再故意拼错一两个字母，仍应能认出，但不能把完全不同的破坏性命令拉到前面。