既然要做本地化，我就连夜给原型接入了成都方言识别。这玩意儿根本不是技术问题，是产品经理的尊严问题。客户在会议室里用川普说“打开那个文件”，我的原型像傻子一样沉默了三秒，然后弹出一句“请问您是要打开‘辣个废品’吗？”全场憋笑，我恨不得钻到桌子底下。回酒店路上我就决定了，今晚不睡也得把这口音给治了。
拆开看，问题出在语音识别引擎的声学模型和语言模型都没针对四川话训练。通用模型对“那个”的声学特征捕捉是基于普通话的“nà ge”，但成都话的“辣个”是降调加喉塞音，元音开口度也小。更麻烦的是连续语音中的变调，比如“你要爪子嘛”里的“爪子”，在句末的轻声处理上，现有模型直接当成了“爪子（zhuǎ zi）”。我第一反应是调百度语音的方言识别接口，结果发现他们只支持粤语和四川话的“基础版”，识别率文档里写着“约70%”——这数字在互联网行业跟“基本不能用”是同义词。
只能自己动手做适配层。思路是在通用识别结果后加一个本地化纠错模块。我翻出之前爬虫存的成都本地论坛语料，大概20万条帖子，用jieba做了基础分词，然后手动标注了500组高频词对照表（普通话-成都话）。比如“做啥子”对应“干什么”，“巴适”对应“舒服”，“瓜娃子”对应“傻子”。但光有词不够，还得处理句法。成都话里“得”字常用作补语标记，比如“吃得太辣了”，普通话模型容易把“得太”识别成一个无意义词块。我写了个规则引擎，用正则匹配常见句式，再调用百度接口的“后处理”参数做替换。
真正头疼的是实时性。原型跑在Electron里，录音采样率16kHz，每200ms发送一个音频片段到云端。成都客户说话快，吞音严重，比如“你不晓得”经常说成“你晓不得”，云端返回的中间结果（is_final=false）经常是“你小不得”，等到整句结束（is_final=true）才修正成“你不晓得”。这中间0.8秒的延迟会让用户觉得机器卡顿了。我开了本地缓存，把常见误识别模式（比如“小不得”→“晓不得”）做成一个优先替换表，在最终结果返回前先给前端一个“预判文本”显示，等云端最终结果到了再无缝替换。这个骚操作把感知延迟压到了300毫秒以内。
凌晨四点测试的时候，我对着麦克风反复说“帮我把这个文件拖到那边文件夹头”。前几次它还是识别成“拖到那边家头”，我意识到是“文件夹”三个字连读时，“夹”的声母j在成都话里弱化成类似y的音，和“家”混了。我临时在纠错规则里加了一条：当识别结果出现“家头”且上下文有“文件”“打开”等关键词时，强制替换为“文件夹里头”。这种规则会降低泛化能力，但针对特定场景的演示足够了——产品经理的智慧，就是在有限时间里用最脏但最有效的办法解决问题。
窗外的天开始泛灰，我灌下第三罐红牛。最后一步是把唤醒词从标准的“你好小智”改成“喂，小智嘛”。测试时发现，带语气词“嘛”的唤醒，在嘈杂环境下误触发率会升高，因为“嘛”的频谱和某些环境噪音有重叠。我调高了唤醒的置信度阈值，从0.7调到0.82，代价是用户需要更清晰、更靠近麦克风地说出唤醒词。这其实符合线下演示的场景——客户会刻意对着设备说话。如果是消费级产品，这么干就是自杀，但做B端原型，先解决“有”再解决“好”。
早上八点，我把新包发给了客户的技术对接人。附言里写：“昨晚针对成都话做了深度优化，欢迎测试‘巴适得板’的语音交互。”两小时后他回了一句语音，点开是带着笑意的川普：“这回对了嘛，你个瓜娃子还有点凶诶。”我瘫在椅子上，知道今晚的夜没白熬。但下一秒就焦虑起来——下周要去广州，粤语的九声六调，怕是得掉更多头发。
