为什么需要离线语音

智能音箱靠云端语音助手听懂人话，但家里一断网，音箱就变成了"哑巴"。离线语音把识别模型直接跑在设备本地：没有网络也能唤醒、识别、执行，而且语音数据不出家门，天然规避隐私顾虑。

对智能家居来说，离线语音的典型场景是高频基础指令：开关灯、调亮度、开窗帘、设空调温度。这些指令词表固定、句式简单，用轻量模型就能达到很高的准确率，完全没必要依赖云端。

本文核心知识点
  • 本地识别模型跑在设备，数据不出门。
  • 唤醒词低功耗常驻监听。
  • 命令词表按场景裁剪，准确率高。
  • 隐私优先本地存储与删除机制。

离线语音不是云端的替代品，而是互补：本地处理基础指令保底线，云端处理开放问答和复杂技能。设计产品时把两类能力分开，用户感知反而更稳定。

智能家居离线语音配图：深蓝渐变背景上发光的方形智能音箱主体，顶部扩散出多层声波弧线，左侧麦克风图标右侧芯片图标的扁平科技插画
听懂你的话，不再依赖那根网线。

离线语音方案与硬件

离线语音方案分芯片级和模组级两类。芯片级方案把语音识别算法固化在专用芯片里（比如离线语音识别 ASIC），功耗低、响应快，适合面板、开关这类小设备；模组级方案在通用 MCU 或 SoC 上跑语音 SDK，灵活性高，适合网关和音箱。

  • 麦克风：单麦够用，双麦支持简单降噪，远场场景建议四麦阵列。
  • 算力：唤醒 + 命令词识别，几十 TOPS 以下的轻量算力即可，关键看内存。
  • 功耗：常驻监听的设备要关注待机电流，唤醒电路做低功耗门控。
  • 离线能力：确认 SDK 支持全离线运行，不依赖任何云端鉴权。

选型先定场景：面板开关用芯片级方案，几块钱成本就能加语音；网关音箱用模组级方案，可以承载更丰富的命令词和本地技能。

唤醒词与命令词训练

离线语音的核心是两段式识别：先唤醒，再听命令。唤醒词长期驻留监听，越短越好记，但太短容易误唤醒；命令词按设备场景裁剪，数量不用多，几十条就能覆盖日常操作。

// 命令词表示例：空调面板离线语音
const cmd_t cmds[] = {
  {"打开空调", ACT_POWER_ON},
  {"关闭空调", ACT_POWER_OFF},
  {"温度调高", ACT_TEMP_UP},
  {"温度调低", ACT_TEMP_DOWN},
  {"风速大一点", ACT_FAN_HIGH},
  {"风速小一点", ACT_FAN_LOW},
};
// 识别结果直接映射到设备动作
int act = match_command(cmds, text, sizeof(cmds) / sizeof(cmds[0]));
if (act >= 0) { device_exec(act); }

训练时要注意口音覆盖：同样的指令，普通话、方言口音、儿童声音都要采集样本来训练。发布后通过用户反馈持续收集误识别样本，周期性重新训练命令词模型，准确率会越用越高。

本地意图解析与控制

识别出文字只是第一步，真正要做的意图解析是：把"把客厅灯调亮一点"拆成对象（客厅灯）、动作（调亮）、程度（一点），然后映射到具体设备指令。离线场景词表有限，用规则加轻量槽位填充就能做好。

// 槽位填充示例：从识别文本提取对象与动作
int parse_intent(const char *text, intent_t *out) {
  if (strstr(text, "客厅")) out->room = ROOM_LIVING;
  else if (strstr(text, "卧室")) out->room = ROOM_BEDROOM;
  if (strstr(text, "灯")) out->dev = DEV_LIGHT;
  if (strstr(text, "亮")) out->op = OP_BRIGHTEN;
  if (strstr(text, "暗")) out->op = OP_DIM;
  return (out->dev != DEV_NONE) ? 0 : -1;
}

解析成功后，控制层通过本地协议（比如 Matter 或厂商局域网协议）把指令下发到目标设备。解析失败要给出友好反馈，而不是让用户对着哑巴设备反复重说。