企业官网建设流程全解析

给一台机器人增加语音控制，最简单的需求可能只有一句话：

用户说“停止”，机器人停止运行。

如果只看最终效果，这个功能似乎没有多少技术环节。但把整个过程拆开，会发现一句“停止”至少要经过声音采集、语音活动判断、识别、命令映射和设备控制几个步骤。

这也是为什么端侧语音OEM不能简单理解成“提供一个ASR模型”。

用户开口说话以后，设备首先拿到的不是文字，而是一段连续音频。

这段声音里可能既有人声，也有环境噪声、设备运行声以及房间反射。

麦克风负责把声音转换成后续系统能够处理的信号。实际产品中，还可能根据需求进行降噪、回声处理等音频前处理。

如果设备长期处于监听状态，还需要判断当前音频里什么时候真正出现了语音。

这里通常会涉及VAD，也就是Voice Activity Detection，语音活动检测。

它主要负责判断音频中的哪些区域存在有效语音，让后面的处理不需要把所有持续输入都当成人在讲话。

完成这些前端处理以后，才进入ASR。

ASR的任务相对明确：把用户说出的声音转换成文字或者可供后续程序处理的识别结果。

假设最终得到了：

停止

到这里，机器人其实还没有停止。

系统还需要把“停止”这个识别结果和设备已有的控制逻辑建立关系。

最简单的方式，可以理解成一组命令映射：

开始 → START 停止 → STOP 返回 → BACK 充电 → GO_CHARGE

如果产品只有少量固定控制命令，这种方案已经能够解决很多问题。

并不是所有语音交互都需要大型语言模型。

ASR负责识别说了什么。

如果后续任务范围明确，可以直接把识别结果映射到设备控制。

只有当用户开始使用更加自由的自然语言表达，系统才可能进一步需要意图识别、自然语言理解或者大模型参与后续处理。

这时，语音识别和语言理解就不能混为一谈。

接下来真正影响系统架构的是：ASR在哪里运行。

如果相应音频数据发送到远程服务器，由服务器完成识别，再把结果返回设备，这是比较典型的云端语音处理。

如果ASR模型直接部署在机器人自身的处理器、NPU或者语音模组上，则属于端侧处理的一种方式。

对于“停止”这样的基础指令，如果识别和控制逻辑都在设备本地完成，那么这项操作不需要为了完成相应推理访问公网。

整个链路可以缩短为：

用户说“停止” ↓ 麦克风采集 ↓ 本地语音处理 ↓ 本地识别“停止” ↓ 调用 STOP 控制逻辑 ↓ 设备执行

这种结构最直接的变化，是网络不再成为这项基础操作的必要环节。

但这不能继续推导成“使用端侧以后整个产品都不需要联网”。

设备完全可以同时保留云端能力。

例如：

┌─ 基础控制 → 本地处理 语音输入 → 端侧判断 └─ 复杂问答 → 云端处理

启动、停止、返回等指令留在本地。

需要在线知识、复杂问答或者更多计算资源的任务，根据产品设计交给云端。

这种端云协同在工程上并不冲突。

反而可以根据任务的重要程度、网络要求和计算量进行拆分。

端侧真正带来的挑战，是硬件资源。

云端服务器可以提供较充足的计算资源，终端却需要面对固定的CPU、NPU、内存、存储、功耗和散热条件。

所以一个模型在PC或者服务器上能跑，并不能直接说明它可以原样部署到机器人控制板或者IoT终端。

真正进入OEM阶段以后，通常需要围绕目标平台进行适配。

处理器架构是否支持，推理框架是否能够运行，有没有可利用的硬件加速单元，内存占用是否能够接受，这些都会影响最终部署。

如果项目继续增加语音能力，处理链路还会向后延伸。

设备需要主动回答，可以在后面增加TTS，把文字重新转换成语音。

需要区分多人发言时，可以使用说话人分离，把不同Speaker的语音片段尽量区分开。

如果还要把某段声音与已经登记的具体人员关联，则可能进一步结合声纹相关能力。

如果机器人需要知道讲话者位于哪个方向，则会涉及声源定位，以及与之相关的麦克风阵列设计。

这些模块虽然经常同时出现在语音方案中，但解决的问题不同。

真正做产品时，需要根据设备任务决定是否加入。

还有一个在算法Demo阶段不太容易体现的问题：真实设备本身也是声音环境的一部分。

机器人有电机声。

一些终端有风扇。

设备自己的扬声器也会播放声音。

再加上外壳结构、麦克风安装位置、房间混响和用户距离，最终进入算法的音频可能和开发阶段使用的标准录音差别很大。

因此，语音OEM项目最终还是要进入整机测试。

产品未来在两米距离使用，就按照接近两米的条件测试。

机器人正常工作时有电机声，就让电机工作。

设备如果面向四川地区用户，就直接测试真实四川话或者带四川口音的普通话。

“支持某种语言或方言”只能说明系统具备对应的处理能力，不能直接推导出不同用户和不同环境下都有相同表现。

现在一些国内语音厂商也在提供端侧OEM或模组方案。

熙瑾公开的信息中，包括端侧语音智能芯片模组，以及语音转文字、语音交互、声纹识别和声源定位等技术方向。

对于已经有整机产品的团队来说，这类方案可以作为一种集成路线了解。

但真正进入开发以后，需要验证的仍然是目标硬件。

模型运行在哪颗芯片上，需要多少资源，麦克风方案如何配合，没有公网时哪些功能可以继续使用，识别结果怎样进入设备原有控制系统，后续版本如何维护，这些才是OEM项目最终需要落地的问题。

所以，从一句简单的“停止”指令往下拆，会发现端侧语音并不是只有一个ASR模型。

它实际上连接了声音采集、前端音频处理、语音识别、任务判断和设备控制。

表面上只是增加一种交互方式，工程上却是在给硬件增加一条新的输入链路。

只有当这条链路能够在真实设备和真实声音环境中正常工作，语音能力才真正完成了产品化。