摘要

随着智能设备和物联网场景的不断普及，语音控制已经从“锦上添花”的功能，逐渐变成很多应用的基础交互方式。
在鸿蒙系统中，官方已经提供了较为完整的语音识别能力，但在实际项目中，很多开发者会卡在几个地方，比如不知道完整流程怎么走、语音识别结果怎么和业务结合、或者代码能跑但不好扩展。

本文从真实工程角度出发，结合鸿蒙语音识别能力，完整梳理在鸿蒙中实现一个“真正能用”的语音控制功能需要经历哪些步骤，并通过可运行的 Demo 模块代码，讲清楚语音控制在实际项目中的落地方式。

引言

在手机、平板、智慧屏、IoT 设备等场景中，传统的点击式交互并不总是最优选择。
比如在智能家居中，用户并不一定每次都方便拿起设备操作界面，这时语音控制就显得非常自然。

鸿蒙在设计之初就强调多设备协同和分布式能力，因此语音控制在鸿蒙体系中不仅仅是“控制一个按钮”，更可能是：

• 控制页面状态
• 控制本地硬件
• 控制远端 IoT 设备
• 触发分布式设备协同

理解这一点，对后面的架构设计非常重要。

鸿蒙语音控制的整体实现流程

在鸿蒙中实现语音控制，整体流程可以总结为一句话：

语音输入转成文本，再由文本驱动业务逻辑。

拆开来看，实际工程中一般分为四步：

1. 语音采集与权限配置
2. 调用鸿蒙语音识别能力
3. 对识别结果进行指令解析
4. 执行对应的业务逻辑

这四步如果顺序没想清楚，很容易写成一团逻辑混在一起，后期维护会非常痛苦。

权限与基础配置

麦克风权限声明

语音控制的第一步不是写代码，而是配置权限。
如果没有麦克风权限，后面所有逻辑都会直接失败。

在 module.json5 中声明麦克风权限：

{
  "module": {
    "requestPermissions": [
      {
        "name": "ohos.permission.MICROPHONE"
      }
    ]
  }
}

这个步骤看起来简单，但在实际项目中是最容易被忽略的点之一。

语音识别能力的调用

引入语音识别模块

鸿蒙提供了现成的语音识别能力，可以直接使用，不需要自己处理音频流。

import speechRecognizer from '@ohos.ai.speechRecognizer';

创建语音识别对象

创建识别器时，一般需要关心两个参数：语言和识别模式。

let recognizer = speechRecognizer.createRecognizer({
  language: 'zh-CN',
  online: true
});

在线识别的好处是准确率高，缺点是依赖网络。
在大多数应用场景下，这是一个可以接受的取舍。

监听识别结果

语音识别的核心输出是文本结果，后续所有控制逻辑都围绕它展开。

recognizer.on('result', (result) => {
  let text: string = result.result;
  console.log('识别到的内容:', text);

  handleVoiceCommand(text);
});

这里要注意一点：
语音识别模块只负责“听”和“识别”，不要在这里写复杂业务逻辑。

启动与停止识别

recognizer.start();
recognizer.stop();

在真实项目中，一般是通过按钮、触摸事件或者唤醒条件来控制识别的开启和关闭，而不是一直开着。

语音指令解析设计

为什么不能直接字符串全等匹配

很多新手一开始会这样写：

if (text === '打开灯') {
  // 执行逻辑
}

但真实用户的说话方式是不固定的，比如：

• 打开灯
• 把灯打开
• 帮我开一下灯

如果只做全等匹配，语音控制几乎不可用。

实用的关键词匹配方案

一个更实用、也更容易维护的方式是关键词匹配。

function handleVoiceCommand(text: string) {
  if (text.includes('打开') && text.includes('灯')) {
    turnOnLight();
  } else if (text.includes('关闭') && text.includes('灯')) {
    turnOffLight();
  }
}

这种方式虽然简单，但在大多数项目中已经足够用，而且可读性和扩展性都不错。

最小可运行 Demo 模块

下面是一个最小可用的语音控制 Demo，可以直接作为学习或验证用。

import speechRecognizer from '@ohos.ai.speechRecognizer';

let recognizer = speechRecognizer.createRecognizer({
  language: 'zh-CN',
  online: true
});

let lightOn: boolean = false;

recognizer.on('result', (result) => {
  let text = result.result;
  console.log('识别内容:', text);

  if (text.includes('打开') && text.includes('灯')) {
    lightOn = true;
    console.log('灯已打开');
  } else if (text.includes('关闭') && text.includes('灯')) {
    lightOn = false;
    console.log('灯已关闭');
  }
});

// 启动识别
recognizer.start();

这个 Demo 虽然简单，但已经完整覆盖了语音控制的核心流程。

实际应用场景分析

场景一：页面状态控制

在普通应用中，语音控制经常用来替代按钮操作。

function turnOnLight() {
  lightOn = true;
}

function turnOffLight() {
  lightOn = false;
}

这种场景下，语音只是另一种输入方式，业务逻辑本身不需要修改。

场景二：智能家居或 IoT 设备控制

在 IoT 项目中，语音指令通常需要转成网络请求。

function sendDeviceCommand(command: string) {
  console.log('发送设备指令:', command);
  // 实际项目中可替换为 HTTP 或 MQTT
}

if (text.includes('打开') && text.includes('空调')) {
  sendDeviceCommand('AC_ON');
}

这里的关键点是：
语音模块不关心设备细节，只负责把“人说的话”转成“系统能理解的指令”。

场景三：结合鸿蒙分布式能力

在多设备协同场景中，语音指令可以触发跨设备操作。

function startRemoteAction() {
  console.log('触发远端设备执行任务');
}

这种模式在智慧屏、车机、可穿戴设备中非常常见。

QA 常见问题

Q1：语音识别要不要一直开着？

不建议。
持续监听会明显增加功耗，实际项目中通常是事件触发式开启。

Q2：关键词匹配会不会不够智能？

在大多数工程项目中已经够用。
等功能稳定后，再考虑引入更复杂的语义理解。

Q3：语音控制模块应该放在哪一层？

推荐独立成模块，只输出“解析后的指令”，不要直接操作业务。

总结

在鸿蒙中实现语音控制，本质上并不复杂，关键在于把流程拆清楚、职责分离好。
语音识别负责把声音变成文本，指令解析负责理解文本，业务模块负责执行动作。

只要结构设计合理，语音控制既可以用于简单页面操作，也可以扩展到 IoT、分布式设备等复杂场景中。