最近做的企微二开，客户经常发语音消息问问题，机器人之前只会处理文本，语音直接忽略，客户体验差。业务方要求机器人能"听懂"语音——把语音转成文字，走正常的意图识别和回复流程，必要时还用语音回复。把这套怎么接记下来。

底层用的是 Eyun 平台开放的企微 API，承接消息收发和文件下载，本文重点不在调接口，在"语音消息怎么识别和处理"。

语音消息接收：先下载

客户发语音，机器人收到的是语音消息回调，带一个 fileId。第一步是下载语音文件到本地或对象存储：

def handle_voice_message(msg):
    audio_path = cdn_api.download(msg.file_id, save_to="oss")
    return {"file_path": audio_path, "format": msg.format, "duration": msg.duration}

下载要异步，不能阻塞回调——语音文件可能几秒到几十秒，下载慢了回调就超时。下载完存 OSS，本地不留文件。关于语音文件下载接口，可以看开发文档。

ASR 转写：语音转文字

下载的语音文件要做 ASR（自动语音识别）转成文字。企微的语音格式通常是 amr，主流 ASR 服务支持 amr，但有些要先转 wav。转写流程：

• 格式转换：amr 转 wav（如果 ASR 不支持 amr）

• 调用 ASR 服务：把音频传给 ASR 接口

• 拿到转写文本：识别结果可能带标点和时间戳

转写的坑是准确率。客户方言、噪音、说话快，ASR 会出错。几个优化：

• 上传前降噪：用音频处理库做简单降噪

• 分段转写：长语音（>60 秒）分段转写再拼接

• 领域词表：把公司产品名、行业术语加进 ASR 自定义词表，提高识别率

领域词表效果明显——不加的话"企微"经常被识别成"气味"，加了就对了。

文本后处理：ASR 结果不能直接用

ASR 转写出来的文本要后处理，不能直接丢给意图识别：

• 标点修复：ASR 可能漏标点或标错，用模型补标点

• 纠错：领域术语纠错，"气味"→"企微"

• 语气词过滤：去掉"嗯""啊""那个"等无意义词

• 口语转书面：把"那个啥来着"归一化成通顺表达

后处理的目的是让文本接近书面语，意图识别才准。不做后处理，ASR 出来的"那个我想问下你们那个企微怎么搞"直接给意图识别，识别率低。

意图路由：语音文本走正常流程

后处理完的文本，和普通文本消息走同一套意图识别和回复流程。不需要为语音单独做一套——语音只是输入形式不同，语义处理是一样的：

语音 → ASR → 后处理 → 意图识别 → 业务处理 → 回复

这样维护成本低，文本消息优化的所有能力语音都能用。不共用流程，语音一套文本一套，改一次要改两遍。

TTS 语音回复：有些场景适合语音回

不是所有场景都要语音回复，但有些场景语音比文字好：

• 客户发语音问，机器人语音回，体验更自然

• 驾驶场景，客户没法看文字，语音回更安全

• 老人客户，语音比文字友好

TTS（文字转语音）回复要做：

• 把回复文本传给 TTS 服务生成音频

• 调企微语音消息接口发出去

• 语音时长控制在 30 秒内，太长客户不爱听

TTS 的坑是音色——默认音色机械感强，客户听着别扭。用定制化音色（公司员工录制）效果好很多，但成本高。折中是用主流 TTS 的自然音色，不用机械默认音。

多语言和方言

企业客户可能有方言和外语需求：

• 方言：粤、客、闽等方言，ASR 要选支持对应方言的服务

• 外语：英语、日语等，ASR 和 TTS 都要支持多语言

• 混合：客户中英混说，ASR 要支持代码切换

多语言支持靠选对 ASR 服务——有些支持几百种语言，有些只支持普通话。选型时要按业务实际需求选，不要为了"全"选贵的。

容错和降级

语音处理环节多（下载、转写、后处理、TTS），每个环节都可能失败。容错策略：

• 下载失败：回"语音消息接收失败，请重发"

• ASR 失败：回"语音识别暂不可用，请改用文字"

• 后处理失败：用原始 ASR 文本继续，不阻塞

• TTS 失败：降级成文字回复

每个环节失败都要有降级，不能一个环节挂了整条语音消息处理链崩。我们最早 ASR 服务挂了，所有语音消息直接 500，客户投诉一次就记住了。

写在最后

语音识别接入这套东西，难点不在调 ASR 接口，在语音下载、ASR 转写优化、文本后处理、意图复用、TTS 回复、多语言、容错降级这些工程细节。每一项都不深奥，但少做一项语音处理就卡或者错。这套搭扎实，机器人真正能听懂客户说话、用语音回复——而不是只会处理文字的半成品。