用户搜的是症状，你写的是服务，而在日语里这两句话连动词都不是同一个

摘要：日语把东西自己出了状况和人对它做了什么分成两个不同的动词，成体系有几百对。用户在故障、售后、配件这些场景里打进搜索框的全是前一种，而你的页面从标题到正文全是后一种，两组字符串一个字都不重叠，母语审校也挑不出任何毛病。英语里这两件事共用一个词，所以整套关键词方法论从来没有为这一维准备过位置。本文讲清这两类词怎么分、用户在哪个环节会切换、你的内容为什么天生偏向其中一边、词干还原为什么反而帮倒忙、页面哪几个位置该放哪一类，以及这批查询的商业价值该怎么估。

为什么日本用户搜出来的故障词，在你的页面上一次都不出现？

一次厨房小家电站的日志比对

有个客户做日本市场的厨房小家电，主力是咖啡机、电饭煲和料理机这几条线。

页面是找母语写手做的，术语规范，语气得体，商品页和使用指南都写得很扎实。

上线一年多，品牌词和品类词的表现都不错，可有一整块流量始终没有起来：跟使用问题相关的那一块。

保哥让他们把搜索词报告和站内搜索日志放在一起看，发现一个很整齐的现象。

用户打进来的查询里有相当大一批是描述状况的短句，比如电源进不去、盖子打不开、机器不转了。而站上所有的页面标题写的都是另一套说法：怎么开机、怎么开盖、怎么保养。两边说的是同一件事，可字面上没有一个字重合。

更关键的是，这批查询不是零星的长尾。把它们按词干归并之后，总量能占到使用类查询的一半以上，而这一半在词表里一条都找不到。词表六百多条，母语写手过了三遍，没有任何一个环节报错，因为从语言的角度看这份词表挑不出毛病。

还有一个细节后来被反复引用：这批查询的设备分布明显偏向手机，而且集中在傍晚到深夜。这跟人在厨房里手忙脚乱那一刻的场景完全吻合，也解释了为什么承接这批词的页面必须在第一屏就给出答案，用户没有耐心往下翻。

两组说法在字符串上没有交集

把两组查询并排放着看，差别不是词尾，是整个词。

用户那一侧的动词描述的是机器自己的状态：不动了、进不去、打不开。

页面那一侧的动词描述的是人的动作：启动它、装进去、把它打开。

在日语里这是两个不同的词，读音不同、写法不同，只有汉字那一部分是共享的。

于是精确匹配拿不到，短语匹配拿不到，连人眼扫一遍词表都不容易发现，因为两组词看上去确实很像，只是像在汉字上，不像在实际字符串上。

这里可以顺手记一条排查经验：凡是两组查询在语义上明显同源、字符串上却几乎不重合的，先别怀疑是拼写或者写法变体，先看它们的语法角度是不是不同。写法变体那一类差异通常只落在词的表层，而视角差异会把整个词换掉。

这不是正式度的问题也不是翻译质量的问题

第一反应通常是把它归到已知的某一类问题里去。

是不是用户用了口语，页面用了书面语。不是，两组词的正式度完全一样，都可以出现在说明书里。

是不是翻译不够地道。也不是，页面上那批词本来就是日本人写的。

是不是敬语用得太重。这一层在日语敬语那一篇里单独讲过，跟本文说的是两件事，而且那件事改了以后这件事一点都不会好转。

真正的差别在语法视角上：同一件事，可以从事情本身的角度说，也可以从做事的人的角度说，而日语为这两个角度准备了两个不同的词。你的页面全站站在后一个角度，用户在遇到问题的那一刻站在前一个角度。

把这几种可能一个个排除掉这件事本身很有价值。团队里对语言问题的第一反应往往集中在那几类熟悉的原因上，而只要这几类都排除了，剩下的解释就只能从语法结构里找，讨论也就从各说各话变成了查资料。

判据是看这句话的主语是谁

要判断一个动词属于哪一类，有个很简单的办法。

看这句话里发生变化的那个东西站在什么位置：它是主语，那就是第一类；它是宾语而另有一个人在做这件事，那就是第二类。

机器不转了，主语是机器，属于第一类。

我把机器关了，主语是人，机器是宾语，属于第二类。

这个判据的好处是它完全不需要日语能力。你把中文说法摆出来，问一句这句话里是谁在做这件事，答案是没有人在做，那对应的日语词就是第一类。这一步可以交给任何一个不懂日语的人做，而且做得比半懂不懂的人更准。

这条判据还有一个用法是反过来查自己的页面。挑十个标题，逐句问一遍谁在做这件事，如果十个答案全是用户，那你的整站就只覆盖了一半的视角，这个自查两分钟就能做完。

自动词和他动词到底差在哪，为什么英语里没有这个问题？

英语用一个词兼了两个职

这件事在英语里之所以不存在，是因为英语让同一个动词同时干两份活。

花瓶碎了和我把花瓶打碎了，英语里的那个动词是同一个词，一个字母都不用改。

句子的意思靠语序和有没有宾语来区分，词本身不动。

于是英语世界的关键词表里，这两种查询天然落在同一行上，你不做任何处理它们也是合并的。

这条差异值得单独记一笔：所有基于英语总结出来的关键词方法论，都默认同一件事只有一个动词。这条默认假设在英语上成立得太彻底，彻底到没有人想过它是一条假设，更不会有人在做日语站的时候想起来去检查它。

顺着这条线还能推一步：正因为英语没有这个区分，所有从英语出发的关键词工具在建议相关词的时候，也不会把另一个视角的说法推给你。工具不是漏掉了它，是它的模型里根本没有这一维。

日语把它们做成了成对的词

日语走的是另一条路，它把这两个角度固化成了两个词。

而且这不是零星几个词的例外，它是一个成体系的现象，配成对的动词有几百组。

更要紧的是这些对子集中在最日常的动作上：开关、进出、装卸、停动、坏修。

而最日常的动作恰好就是家电类目里出现频率最高的那些动作。

所以这件事对不同品类的杀伤力完全不同。卖服装的几乎碰不到它，卖家电、卖工具、卖任何带机械结构商品的站，会在整个售后和使用板块上一路踩到底。

这套对子还有一个方便的地方：它是可枚举的。日语教学材料里早就把常用的动词对整理成了表，你不需要从零采集，拿现成的表跟自己的品类词一交叉，第一批候选就出来了。

汉字相同容易让人误判成同一个词

有个陷阱专门坑懂一点日语的人。

成对的两个动词通常共享同一个汉字，只有后面跟着的假名不同。

于是一眼扫过去很容易觉得这就是同一个词的两种写法，顺手就并成一条了。

但它们在搜索里是彻底的两个字符串，共享的那个汉字救不了任何东西。

这一层跟日语三套文字的写法那一篇要分开看：那一篇处理的是同一个词的多种写法，属于归一问题；这一篇处理的是两个不同的词，属于覆盖问题。归一做得再好也补不上一个从没写过的词。

这个陷阱有个很典型的表现：会一点日语的同事看完词表说没问题，完全不会日语的同事反而会问一句这两个是不是不一样。半懂不懂在这里比不懂更危险，因为汉字给了他一种已经看懂了的错觉。

动词的选择顺带暴露了用户在哪一步

这套区分还有一个副产品，而且是个很值钱的副产品。

用第一类词的人，东西已经在他手里，而且出了状况。

用第二类词的人，多半还在了解这东西该怎么操作，可能还没买。

也就是说，动词本身就是一个漏斗位置的信号，不需要任何模型去猜。

英语把这个信号合并掉了，所以英语世界的意图分类框架里根本没有这一维。而在日语站上，这一维是白送的：你只要看用户用了哪一类动词，就知道该给他一个购买入口还是一个解决办法。

这个信号还能用来做页面分流。同一批流量进来之后，用第一类词的引导到支持和配件，用第二类词的引导到商品和教程，分流规则就是一张动词表，不需要任何行为数据积累。

用户在什么场景下会用自动词，什么场景下用他动词？

故障和异常场景几乎全是第一类

最集中的一块是故障描述。

东西不工作了、灯不亮了、盖子卡住了，用户描述这些的时候不会说自己做了什么。

因为在他的认知里这件事就是机器自己发生的，他没做任何事。

这批查询的转化路径通常很短：找到原因、找到配件、或者找到售后入口。

值得注意的是这类查询往往带着焦虑，用户希望立刻拿到答案而不是先看一段品牌故事。所以承接这批词的页面结构应该跟商品页完全不同，第一屏就该给判断和动作。

这批查询还有个特点是几乎不带品牌名。用户描述的是现象，他心里的问题是这东西怎么了，而不是这个牌子怎么了。所以指望靠品牌词把这批流量接住是接不住的，它们从一开始就没打算提到你。

操作和保养场景偏向第二类

另一头是操作类内容。

怎么装滤网、怎么拆刀头、怎么清洗内胆，这些都是人主动做的事。

用户搜这一类的时候，东西是好的，他只是不知道该怎么弄。

这批词跟商品页和使用指南的匹配度天然就高，通常也是站上已经覆盖得最好的一块。

把两块摊开对比会看到一个很典型的分布：站上的内容密度和用户的查询密度正好错位，覆盖最好的那一块竞争最激烈，而竞争稀薄的那一块你一个页面都没有。

操作类内容还有一个容易被忽略的价值：它是购前用户在评估易用性时会看的东西。所以这一块即便竞争激烈也不能放弃，只是不该指望它顺带把故障类查询也接了，两者对页面结构的要求是相反的。

购前顾虑句里两类会同时出现

还有一类查询比较特别，两类词会一起出现。

用户在买之前会问这东西容不容易坏、会不会卡住、好不好拆洗。

容易坏用的是第一类，好不好拆洗用的是第二类，一句话里两边都有。

这类查询的商业价值很高，因为提问的人正处在下单前的最后一步。

处理办法是把这类问题原样收进商品页的问答区，别改写成书面表达。改写的动作看着是在提升文案质量，实际是在把用户的原话换成你自己的话，而用户的原话才是查询。问答长尾那一篇讲的正是这类内容为什么在小语种市场特别值钱。

这类混合句还有一个好用的地方：它是最容易验证选词对不对的样本。把这句话原样丢进搜索框，看看返回的前几条是不是同行的问答页，如果是，说明这个说法确实有人在用，而且你还没参与竞争。

怎么把这两类查询从日志里分出来

分类这件事听着难，实际有个很省事的做法。

不用给每条查询做语法分析，只需要准备一份词尾特征清单。

第一类动词的常见结尾形式数量有限，把它们做成一个匹配规则跑一遍日志就能分出大半。

剩下分不清的丢给本地同事，通常不会超过一成。

这个做法的价值不只在省时间，还在于结果可复现。任何人拿同一份规则跑同一份日志会得到同一个分组，而交给人凭感觉分类的话，换个人做出来的口径就变了，两个季度之间根本没法比。

规则跑完之后建议保留一份未分类的样本，别急着丢。那一成分不清的查询里往往藏着这门语言里最口语的说法，而口语说法正是口语短词那一篇说的那类工具看不到的词。

你的内容为什么天然全是他动词？

产品资料本来就是从操作视角写的

这件事的根源不在写手身上，在资料来源上。

说明书、安装指引、客服话术这三份东西，全部是站在教用户做事的立场上写的。

而站在这个立场上，动词只能是第二类，因为句子的主语必须是用户。

写手拿到的第一手资料就是这样，他写出来的第一稿自然也是这样。

所以这不是某个人的疏忽，是整条内容供应链的默认输出方向。厂商视角天生是操作视角，用户遇到问题时的视角天生是状态视角，两者错开是结构决定的，不是态度决定的。

顺着这条线还能推出一个预测：凡是内容生产高度依赖厂商资料的品类，这个错位就越严重。反过来，内容主要来自用户社区的品类，两个视角天然就都在，因为社区里说话的人本来就是遇到问题的那一方。

母语审校为什么一次都不会提

更麻烦的是这个错位过不了任何一道质检。

页面上的每个句子语法正确、用词得体、读起来自然。

母语审校的职责是判断这句话写得对不对，而它确实对。

审校不会问的问题是：用户会不会用另一个词来描述同一件事。

这跟母语审校验收清单那一篇的结论一致：一句读着自然不能当成验收通过的判据，因为可读性和可检索性是两把不同的尺子，而审校手里只有前一把。

这里还有一个组织上的原因：审校拿到的是一份已经写好的稿子，他的工作范围是这份稿子内部。没有人给他一份用户查询清单，也没有人要求他对照着看，所以这件事在流程上根本没有出口。

跟被动语态那件事的区别在哪

有人会把这件事跟语态混为一谈，值得分清楚。

被动语态与施事者丢失那一篇讲的是一个动词的两种形态，改了之后句子里少了一个名词。

本文讲的是两个不同的词，改不改都不缺任何成分，缺的是另一个词从来没在页面上出现过。

一个是信息被删掉了，一个是词根本没写过，排查方式完全不同：前者要数名词，后者要数动词。

还有一个更实际的差别：被动语态那件事你可以要求译者别那么写，而这件事没法靠约束写法解决，因为两类词都是对的，你要做的是补内容而不是改内容。

两件事还有一个差别体现在改动成本上。语态那件事可以在译审环节靠一条规范约束住，几乎不增加工作量；这件事必须新增内容，要走选题、写作、发布的完整流程，排期上要按内容项目来算，不是一条规范能解决的。

跟否定构词那件事正好是镜像

另一篇值得对照的是否定构词那一篇。

那件事的特征是字符串极像而语义相反，无糖和含糖只差几个字母。

本文这件事的特征正好倒过来：字符串完全不同而说的是同一件事。

两者带来的错误方向也相反，一个是把不该并的并了，一个是把该覆盖的漏了。

把这两条放在一起可以推出一个更一般的检查项：判断两个词该不该合并，永远不能只看字符串距离。字符串距离在这两件事上都会给出完全错误的答案，而且两次错的方向还不一样。

这两篇放在一起还能得出一条给工具选型的建议：任何号称能自动扩展关键词的工具，先拿这两类词各测三条。一类看它会不会误并，一类看它会不会漏推，两轮测下来这个工具在屈折语和黏着语上的成色就清楚了。

词干还原和同义词能不能把两组词并起来？

词干还原会给你一个虚假的安全感

技术上的第一反应还是让工具摆平。

成对的两个动词共享词干，粗粒度的处理确实能把它们削到同一个形式。

削完之后统计口径上看起来覆盖率很好，两组查询都能对上同一个词条。

问题是这只解决了统计，没解决页面。

并回同一个词干不等于页面上出现过那个词。你的报表会显示这批查询已被覆盖，而实际情况是站上一个第一类动词都没写过，用户搜进来看到的仍然是一堆讲操作步骤的标题。

这种虚假的安全感有个更隐蔽的版本：报表上的覆盖率数字甚至会因为合并而变好看，因为分母里的查询被并到了已有词条上。指标改善和问题解决在这里是反向的，这大概是所有代理指标里最容易骗人的一种情形。

站内搜索可以靠同义词表接住

站内搜索那一侧倒是可以靠配置解决。

把常用的动词对显式写进同义词表，几十行就能覆盖主要品类。

这一步成本极低，而且见效非常快，通常一个发布周期内就能看到零结果比例下降。

建议按品类分组维护，因为不同品类高频的动词对并不一样。

需要留意的是不要把配对做成双向无条件等价。有些对子在特定语境下语义差别不小，全部双向打通会把不相干的结果也召回来，稳妥的做法是先单向打通，从第一类指向第二类。

同义词表这一步还有个附带收益：它会把你之前从来没统计过的一批查询暴露出来。配上之后再看站内搜索报告，你会第一次看到这批词的真实量级，而这个数字通常就是立项材料里最有说服力的那一个。

外部搜索那一侧只能靠补内容

站外就没有配置这条路可走了。

搜索引擎自己会不会把两个词关联起来，你既控制不了也观测不到。

唯一可靠的动作是让这批词真的出现在页面上。

出现的位置不需要很多，标题、首段和问答区各一次通常就够。

这一点跟绝大多数关键词工作是一样的：能配置的层可以配置，展示层只能靠写。区别只在于这一次要写的不是同义词，是同一件事的另一个视角。

补内容这件事有个最低限度的版本：不必为每个词对单独建页面，先在已有的支持页里补一段用用户说法写的开头就行。一段话的成本很低，而它已经足够让这个页面跟那批查询建立起字面上的联系。

结构化数据里该填哪一类

还有一个容易漏的位置是结构化数据。

问答类型的结构化数据里，问题那一栏应该原样保留用户的说法。

也就是说问题里出现第一类动词，答案里出现第二类动词，这个搭配是最自然的。

很多团队会把问题也改写成规范表达，改完两栏都是第二类，等于白做。

这条跟结构化数据本地化那一篇的原则并不冲突：那一篇说的是格式字段要写回国际口径，而问题文本属于内容字段，内容字段永远跟着用户走。

问答区这个位置还有一个特别之处：它是全站唯一一个可以理直气壮地使用不规范说法的地方，因为那本来就是在引用用户的提问。别的位置要顾观感，这个位置顾的是真实感，两者的取向正好相反。

这批查询的商业价值该怎么估？

不能按购买意图那套模型估

这批词在常见的意图分类里通常会被划进信息类，然后被排到后面去。

这个划分本身没错，但它算漏了一件事：提这些问题的人已经买过了。

他不是潜在客户，他是现有客户，而且正处在一个可能流失也可能复购的节点上。

接住他的收益不体现在这次转化上，体现在配件、耗材和下一次购买上。

所以这批词的正确估值方式不是看它的直接转化率，而是看它挡住了多少次差评和退货。这个数字不好归因，但只要看一眼客服工单里同类问题的占比，量级就出来了。

把现有客户和潜在客户分开算这件事，在小语种市场尤其要紧。这类市场的用户基数小，复购和口碑占的比重比大市场高得多，一次没接住的售后问题造成的损失，往往比一次没成的转化大好几倍。

三个可以直接拿去汇报的数字

要立项就得有数，这里有三个最容易拿到的。

第一个是站内搜索里这类查询的次数和零结果比例。

第二个是客服工单里同一批问题的条数，这个数通常大得让人意外。

第三个是这批查询对应品类的退货率，因为很多退货的起点就是一个没找到答案的疑问。

三个数里第二个最有说服力，因为它是用户在完全没有提示的情况下说出来的原话，而且它已经在工单系统里躺了好几年，从来没人从这个角度看过它。

这三个数还有一个共同的好处：它们全部来自你自己的系统，不依赖任何第三方工具，也不需要解释统计口径。汇报时最怕的就是对方质疑数据来源，而工单条数这种数字没人会质疑。

竞争密度通常比商品词低一个量级

还有一个值得看的角度是竞争。

本土大站的资源基本都压在商品词和品类词上。

故障和使用问题这一块，愿意认真写完整回答的站要少得多。

而这类问题的答案又高度具体，很难靠模板批量生产。

结果是这一片的内容供给天然稀薄，你只要写得比说明书更像人话就已经有优势了。这个结构在小语种市场比在英语市场明显得多，因为整个语种的内容总量本来就小。

竞争稀薄这一点在小语种市场还有一层放大效应：整个语种的内容总量本来就小，愿意为一个具体故障写完整答案的站更少。这跟问答长尾那一篇观察到的供给结构是同一件事，只是这里的需求侧更明确。

先做哪几个词

不必一上来铺全量，按两个维度排序就行。

第一个维度是这台机器最常出的那几个问题，客服最清楚。

第二个维度是这个问题有没有可售的解决方案，比如一个配件或者一次上门服务。

两个维度都占的词排最前面，只占第一个的排第二梯队。

照这个顺序做，第一批通常十来个词就能覆盖掉大半的量，因为故障类查询的分布比商品类查询集中得多，头部几个问题就能占掉一半以上。

排序时还有一个隐藏维度值得考虑：这个问题解决之后用户会不会顺手再买点什么。滤芯、密封圈、刀头这类耗材的复购天然挂在故障和保养场景上，把它们列进来之后，这批词的账会好看很多。

页面上哪些位置该放自动词，哪些位置不能放？

标题要用用户那一侧的说法

承接这批查询的页面，标题应该直接写用户的说法。

不是怎么开机，而是开不了机的时候先看哪里。

这样写在搜索结果页上的辨识度也更高，因为它跟用户刚打完的那句话长得一样。

担心观感的话可以在后半句补上解决动作，两类词一句话里都放下。

这一条是本文里唯一一个需要动标题的地方，也是收益最集中的地方。别的位置都可以慢慢补，标题这一处不改，其它改动的效果会打很大折扣。

改标题的时候有个分寸要拿捏：别把整句故障描述原样搬上去，那样标题会很长而且读起来像在抱怨。取那个关键动词加上品类词就够了，后半句留给解决动作，这样既接住了查询又保住了专业感。

商品页正文只放一两处就够

商品页的处境不一样，它的主职是卖东西。

在商品页上大写特写故障场景会伤害转化，这个顾虑是合理的。

合理的做法是在规格区或者常见问题区放一两处，点到为止。

把详细内容放到独立的支持页上，用内链接过去。

这样分工的好处是两类页面各自的意图很干净：商品页承接购买，支持页承接问题，而支持页的内链又能把已经买过的用户带回配件和耗材页面。

商品页这一处还有个折中办法：把常见问题区的问题文本用用户的说法写，答案用规范说法写。问题那一行本来就短，出现一次口语视角的动词不会有任何观感成本，而它已经足够让这个页面沾上那批查询。

支持页和使用指南要分成两套

很多站把这两件事写在同一个页面里。

使用指南讲的是正常流程，支持页讲的是不正常的情况。

合在一起的结果是两批查询互相稀释，哪一批都排不上。

拆开之后各自的标题和首段都能对准一类词，效果立竿见影。

拆的时候有个简单的界线：句子的主语是用户的，归使用指南；主语是机器的，归支持页。这条界线正好就是本文那条语法判据，用起来不需要任何额外的判断。

拆页面这件事在排期上比想象中轻。支持页的内容大部分已经存在，只是散落在使用指南的各个小节里，把它们抽出来重组比从零写省一大半工时，真正新增的往往只有开头那一段判断路径。

面包屑和筛选器不要碰

最后要说清楚哪里不该动。

面包屑、分类名、筛选器取值这些位置是站点结构的一部分，要保持稳定和整齐。

把故障说法塞进分类名会让整个导航读起来很奇怪。

这些位置继续用规范的操作视角说法就好。

按位置分工这条原则在本站好几篇里都出现过，这里只是又一个实例：匹配层可以宽，展示层要窄，而导航属于展示层里最窄的那一档。

这条边界还有一个理由：导航文案会被大量页面复用，改一处影响全站。而故障说法天生是具体的、场景化的，把它放进一个要在几千个页面上出现的位置，无论从观感还是从维护角度都不划算。

德语、俄语、西班牙语有没有同样的分岔？

德语靠不同的词或者反身形式

德语的处理方式介于英语和日语之间。

有些概念它用两个不同的词，有些概念它靠给动词加一个反身成分来表达。

反身形式那一类在字符串上更容易识别，因为多出来的那个成分是固定的。

做德语站时可以先从反身形式入手，规则明确，跑一遍就能列出候选。

不过德语这里有个额外的复杂度：反身成分在句子里的位置不固定，可能离动词很远。这一点跟并列与列举那一篇说的距离问题是同一类麻烦，短语匹配一样会失手。

德语这边还要提醒一句：反身形式在关键词工具里经常被当成两个词处理，导出的搜索量会被切开。看到某个词的量小得不合常理时，先确认工具有没有把那个成分单独算了一次。

俄语靠一个后缀切开两边

俄语走的是后缀路线。

同一个动词加上一个特定后缀，意思就从人做的事变成了自己发生的事。

这对识别是好消息，因为后缀是固定的，写条规则就能把两边分开。

但对词干还原是坏消息，因为还原器很可能直接把这个后缀削掉。

削掉之后两类词合成一个，症状跟日语那边一模一样：统计上覆盖了，页面上没有。这也说明本文的核心问题跟具体是哪门语言无关，只跟这门语言有没有把两个视角做成两个字符串有关。

俄语这条线还能跟生命度那一篇连起来看：两件事都发生在词尾，都会被词干还原动到，而且都是英语里不存在的维度。做斯拉夫语市场时这两项可以合并成一次排查，省一半沟通成本。

西班牙语和意大利语用代词标记

罗曼语族这边靠一个小词来标记。

那个小词有时黏在动词后面，有时单独站在前面，形态会随人称变化。

形态多这一点让候选列表比德语和俄语都长。

好在电商场景里用到的人称非常有限，实际要覆盖的形态没那么多。

这几门语言还有一个共性值得记住：越是靠附加成分来区分两个视角的语言，越容易被词干还原抹平；越是用两个完全不同的词的语言，越容易被人眼漏掉。两条路各有各的翻车方式。

罗曼语族这边还有一个实操建议：先从最高频的第三人称形态入手。商品文案和用户描述里绝大多数句子都是第三人称的，覆盖了这一种形态，实际能接住的查询已经接近八成。

怎么快速判断一门新语言要不要做这件事

开一个新市场时，这件事值不值得投入有个十分钟的判断法。

挑三个最常见的动作，让本地同事各写两句话：一句是东西自己出了状况，一句是人对它做了这件事。

看两句话里的动词是不是同一个字符串。

三组里有两组不同，那这门语言就要按本文的流程走一遍。

这个判断法不需要语法知识，也不需要查任何资料，问的是母语者的直觉输出。而且它顺带能拿到第一批词对，等于把调研和采集合并成了同一个动作。

这个十分钟判断法还有一个变体：直接问本地同事，用户抱怨机器出问题的时候一般怎么说。他脱口而出的那句话就是你要的第一类说法，而且比任何词典释义都更接近搜索框里的真实输入。

一套三天能跑完的自他动词补齐流程

第一天，从工单和日志里捞原话

第一步是采集，来源只有两个但足够了。

客服工单里的用户描述，站内搜索里的原始查询串。

两份数据合起来去重，通常能得到几百条候选。

这一步不要做任何改写，原话就是要保留的东西。

如果工单系统不支持导出，退一步可以听十通电话录音的开头。用户说明来意的那半句里几乎一定带着状态描述，而且是最自然的那一种说法。

采集这一步最容易被跳过的是去重之前先看一遍原始数据。同一个故障的不同说法之间的差别本身就是信息，去重规则定得太狠会把这批变体压成一条，而变体的数量恰恰说明了这个问题有多普遍。

第二天，配对并挑出高频的那十几组

第二步是把候选整理成动词对。

每一组两列，一列是用户的说法，一列是页面现在用的说法。

按出现次数排序，取前面十几组作为第一批。

剩下的长尾先放进匹配层，不必为每一条都写内容。

配对的时候可以顺手标一列有没有可售的解决方案，这一列在后面排优先级时直接决定顺序，而且它是市场和产品部门唯一关心的那一列。

配对表还有个用法是拿去跟商品页做交叉核对。把左列的说法逐条在自己站上搜一遍，看有没有页面能接住，接不住的那几行就是这一轮要补的内容清单，这份清单可以直接交给写手。

第三天，改标题并补支持页

第三步是落地，动作只有三个。

把第一批词对应的支持页标题改成用户的说法。

没有支持页的补一个，结构简单，第一屏给判断和动作。

同义词表把这十几组配上，站内搜索当天就能生效。

三个动作里前两个要走内容发布流程，第三个是配置改动，可以先上。建议先上配置那一个，它能在内容还没写完的时候就把站内搜索的零结果比例压下来，也能给后面的内容排期提供更准的数据。

落地时建议把这三个动作分给不同的人并行做，因为它们互相之间没有依赖。配置改动交给技术，标题改动交给运营，新页面交给内容，三条线各自跑各自的，一周之内就能全部上线。

验收看什么

上线之后盯三个信号。

站内搜索里这批查询的零结果比例，应该在一周内明显下降。

支持页的展现量，它会比点击更早出现变化。

客服工单里同类问题的条数，这个指标滞后但最能说明问题真的被接住了。

三个信号里第一个用来确认改动生效，第二个用来确认搜索侧开始认这批内容，第三个用来说服业务方继续投入。分工不同，别混在同一张报表里看。

另外建议给这三个信号各定一个观察窗口，别每天盯。零结果比例看一周，展现量看三周，工单条数看一个季度。窗口定错会让人在数据还没稳定的时候就下结论，进而砍掉一件其实做对了的事。

哪些事不归这一层管

写法归一是另一件事

同一个词在日语里可能有汉字、假名几种写法，这属于归一问题。

它的处理方式是把变体收进同一条词目，跟本文的覆盖问题不是一回事。

两件事的顺序建议是先覆盖后归一，因为一个从没写过的词，归一得再好也没有用。

反过来如果先做归一，你会看到一份很整齐的词表，整齐到看不出里面缺了一半的视角。

这也是这类问题难被发现的原因之一：所有的整理工作都会让表格看起来更好，而缺失的东西不会因为整理而浮出来。

这两件事的关系还可以再说明白一点：归一是把已有的东西整理好，覆盖是把没有的东西加进来。前者让报表变干净，后者让流量变多，而团队天然更愿意做前者，因为它的产出立刻可见。

内容质量那一半有独立的判据

本文只解决用哪个词的问题，不解决内容写得好不好。

支持页的答案是否真的解决了问题，属于内容质量的范畴。

那一层有自己的验收方式，跟关键词覆盖率没有关系。

两件事都要做，但要分开验，混在一起就会出现词覆盖了流量也来了而用户仍然不满意的情况。

顺带说一句，这两件事在排期上可以并行，因为它们改的不是同一批文件，也不需要同一批人。

分开验还有一个好处是责任清晰。词覆盖没做到是关键词那一侧的事，答案没写好是内容那一侧的事，两个问题混在一起的时候，最常见的结局是谁都觉得是对方没做好。

引擎那一半交给平台层

最后仍然有一半功课不在语言这一层。

搜索引擎自己会不会把两类动词关联起来、日本市场的主流引擎在这一点上有没有差异，这些属于引擎的行为。

本站把引擎那一半放在平台与多引擎那个方向里单独讲，这篇不展开。

分清楚的好处是排查顺序不会乱：先确认页面上有没有这个词，有了还不出现才轮到去研究引擎。

顺序反过来的团队通常会先花两周研究引擎的语义理解能力，然后发现自己站上根本没写过那个词。这个顺序值得写进排查手册的第一行。

另外提醒一句，日本市场还有一层平台因素值得单独看，但那属于引擎和渠道的选择，跟本文这一层的动作没有先后依赖，可以完全并行推进。

常见问题解答

不懂日语，怎么自己判断两个词是不是一对？

有个不需要日语能力的办法。把你要处理的那个动作用中文写成两句话，一句是东西自己发生了变化，比如盖子打不开了；另一句是人做了这件事，比如把盖子打开。然后把这两句中文分别丢进任意一个在线日语词典或者例句库，看返回的动词是不是同一个字符串。不是同一个，那就是一对。整个过程你需要的只是复制粘贴和字符串比对的能力。要提醒的是别只看汉字部分，成对的两个词汉字通常是一样的，差别全在后面的假名上，只对比汉字会得出所有词都一样的错误结论。

做完之后可以把配好的对子发给本地同事确认一遍，但问题要问得具体，问他机器出这个状况时用户一般怎么说。另外提醒一点，例句库返回的结果要挑生活场景的那几条看，技术文档里的用法往往偏书面，跟搜索框里的输入不是一回事。

把两类词都堆进同一个页面，是不是最省事？

短期看确实省事，长期看不建议。同一个页面同时承接购前操作问题和售后故障问题，会让页面的意图变得模糊，两类查询互相稀释，最后哪一类都排不到前面。更现实的问题是这两类用户需要的页面结构完全不同：操作类用户愿意从头看到尾，故障类用户希望第一屏就给判断路径。硬塞在一起，后者会在前三秒离开。合理的做法是商品页和使用指南保持现在的写法，另开一组支持页专门承接故障类查询，两边用内链连起来。

拆开之后每个页面的标题和首段都能对准一类词，这比在一个页面里塞两套说法有效得多，改动量其实也没大多少。还有一个附带好处是拆开之后两类页面的效果可以分别衡量，混在一起的时候你根本判断不出改动到底帮了哪一边。

这批词的搜索量在工具里看着很小，值得做吗？

工具给的数字在这一类词上系统性偏低，原因有两个。一是这批查询的说法非常分散，同一个故障用户能打出十几种不同的句子，工具按字符串统计就把量切碎了。二是很多这类查询本来就发生在站内搜索框里而不是搜索引擎里，工具根本看不到。所以判断它值不值得做，不要看工具的数字，要看你自己的第一方数据：站内搜索次数、客服工单条数、退货原因分布。

这三个数通常比工具数字大一到两个量级。汇报的时候也用第一方数据，因为它不需要解释统计口径，而且业务方对工单和退货这两个词天然敏感。另外建议把三个第一方数字按品类拆开看，通常会发现问题高度集中在一两条产品线上，先做那一两条的投入产出比最好。

词干还原已经把两类词合并了，为什么还要单独写？

因为合并解决的是统计口径，不是页面内容。词干还原让你的报表显示这批查询已经有对应词条了，但页面上一个字都没变，用户搜进来看到的还是那批讲操作步骤的标题。判断有没有真的解决，有个很直接的办法：拿一条实际查询在自己站上搜一遍，看返回的页面标题跟这条查询长不长得像。不像，那就是没解决。

另外还要注意还原器的行为跟版本有关，换一次搜索引擎版本，合并规则可能就变了，而显式写进同义词表的配对不受版本影响。稳妥的做法是两条腿走路，还原器兜底，核心词对显式写死。还有一个简单的验证动作是看页面源码里有没有那个字符串，搜不到就说明无论工具怎么报，这个词在你站上确实不存在。

改标题会不会影响已有页面的排名？

要看改的是哪一类页面。承接故障类查询的支持页，本来就没有排上什么名，改标题几乎没有下行风险，属于净收益。商品页和使用指南这类已经有排名的页面不建议动标题，它们现在的表现说明标题跟当前的查询是匹配的，动了反而可能掉。所以正确的做法是新开或者改写支持页，不碰已经跑得好的页面。如果一定要在已有页面上加，可以先加在首段和问答区，观察两三周没有负面影响再考虑动标题。

这个顺序也符合一般的改动原则：先在低风险的位置试，确认方向对了再往高风险的位置推。另外一个稳妥的做法是先在少数几个页面上试，观察两三周确认没有负面影响之后再批量推，改动范围小的时候回滚也容易。

其它品类需要做同样的排查吗？

要不要做取决于你的商品会不会自己出状况。带机械结构、带电、带耗材的品类必须做，家电、工具、户外装备、汽车配件都在这一档。纯软性商品比如服装、床品、饰品，这类查询的量非常小，做一次筛查确认就可以放过。判断办法很简单：翻一遍客服工单，看有多少条是在描述商品的状态而不是在问怎么用。

比例超过两成就值得按本文的流程走一遍。顺带说一句，即便是软性品类，退换货流程相关的查询里也可能出现这类词，那一块可以单独看一眼，成本很低。顺带一提，配件和耗材页面也值得单独看一眼，因为用户找配件的起点往往就是一句描述状态的话，而不是配件本身的名字。

这套办法在AI搜索那一侧还成立吗？

成立，而且理由更充分一点。生成式的回答需要从某个来源里抽取内容，而抽取的前提是这段文字在语义上跟问题对得上。如果全站没有任何一段文字是从用户那个视角描述这件事的，模型能拿到的最接近的材料就是操作步骤，回答出来自然也是操作步骤，跟用户想问的对不上。反过来，只要站上有一段用用户的说法写的判断路径，被引用的概率会明显提高，因为它跟提问的措辞更接近。

所以这件事在AI搜索那一侧的落点跟传统搜索是一致的：页面上得真的有那段文字，配置层的同义词在那边完全不起作用。还有一点值得留意，模型引用时倾向于挑那种结构清晰、判断路径明确的段落，所以这批内容的排版比一般文章更值得下功夫。