鸿蒙Core Speech Kit端侧离线语音识别接入与热词优化

鸿蒙专家

从 Core Speech Kit 看端侧离线语音识别
Harmony Intelligence AI 开放能力第五期聚焦 Core Speech Kit 的语音识别。上一期拆解的是 Core Vision Kit 通用文字识别；这一期的重点是把中文音频转成文本，并且整套识别流程在端侧闭环完成，不依赖云侧算力。无网、弱网、飞行模式下，长短语音识别都可以稳定生效。

能力规格方面，语音识别面向开发者提供标准化音频转文本服务：支持中文普通话，也覆盖中文语境下的英文；模型形态为离线；适配 Phone、Tablet、PC/2in1；短语音模式不超过 60s，长语音模式不超过 8h；输入可以是 PCM 音频文件，也可以是实时语音。热词支持系统热词和会话热词双配置，热词总数不超过 200，两类共享总配额，每个热词长度范围为[2,20]。

端侧还是云侧：先看断网与数据边界
原文给了一个很明确的选型标准：端侧与云侧语音识别不存在技术优劣，区别在业务场景。若业务要求“断网可用、数据不脱离设备”，优先端侧；若更看重多语种、超高精度识别，则云侧更合适。端侧识别全流程本地运算，原始音频与识别结果不上传服务器，适合隐私敏感、网络不稳定场景；云侧依托远端算力，适合多语种、超高精度需求。这个判断可以直接落到架构取舍：会议记录、现场访谈、无障碍字幕、离线指令等场景，端侧闭环更稳；多语种客服、大规模转写等场景则要评估云侧。

三大核心能力与开发关键点
1. 本地离线识别。设备侧预置专属离线模型，音频解析、识别推理、文本转换全流程本地完成，不依赖网络。
2. 双音频输入适配。同时支持麦克风实时语音和标准 PCM 音频文件。PCM 音频需满足 16000Hz 采样率、单声道、16bit 位深。配合短语音（≤60s）和长语音（≤8h）两种模式，覆盖实时交互与长时音频归档转写。
3. 两层热词修正专有词。系统热词 sysGeneralLexicon 在创建引擎时配置，对整个应用的识别过程生效；会话热词 sessionGeneralLexicon 在开始识别时配置，优先级更高，单次会话生效。热词只优化专有词汇识别精度，不能抵消环境噪声干扰，嘈杂场景建议前置收音降噪。

典型落地场景
日常工作场景中，可以离线转写会议、访谈和现场沟通内容，也可以通过语音填表完成“语音→文本→提取字段→自动填写表单”，或者语音搜索本地内容。无障碍与实时字幕场景中，无网环境下把音频实时转成文字，结合 AI 字幕能力生成实时字幕，既服务听障用户，也适合不便外放音频的场景。离线记录与口述场景中，既支持麦克风实时收音，也支持本地 PCM 音频文件识别，可用于会议录音、口述笔记、长时音频素材留存；搭配实体抽取能力，还能识别语音里的时间、地点等关键信息，用于生成日历待办或结构化整理会议要点。无网语音指令交互则可用于地下室、机舱、野外等断网环境，解析本地语音指令，扩展终端离线操控。社交场景中，可用于聊天、客服售后语音录入；出境出行、少数民族地区交流时，可结合翻译软件完成语音转当地文字。

最小接入示例：创建引擎、设置回调、开始识别
通过 @kit.CoreSpeechKit 导入 speechRecognizer，核心分三步：创建引擎、设置结果回调、开始识别。下面代码保留原文最小接入示意：

2. import { speechRecognizer } from '@kit.CoreSpeechKit';
3. import { BusinessError } from '@kit.BasicServicesKit';
5. // 1. 创建离线引擎：online=1 表示离线，recognizerMode 选 short 或 long
6. const initParams: speechRecognizer.CreateEngineParams = {
7.   language: 'zh-CN',
8.   online: 1,
9.   extraParams: {
10.     locate: 'CN',
11.     recognizerMode: 'short',
12.     sysGeneralLexicon: ['鸿蒙', '方舟'] // 系统热词，可选，整个应用生命周期生效
13.   }
14. };
16. speechRecognizer.createEngine(initParams, (err: BusinessError, engine: speechRecognizer.SpeechRecognitionEngine) => {
17.   if (err) {
18.     // 创建失败，常见错误码见文末 FAQ，如 1002200001 表示引擎创建失败
19.     return;
20.   }
22.   // 2. 设置回调，onResult 里取识别文本
23.   engine.setListener({
24.     onStart: () => {},
25.     onEvent: () => {},
26.     onResult: (_sessionId: string, result: speechRecognizer.SpeechRecognitionResult) => {
27.       console.info(`识别结果：${result.result}`);
28.     },
29.     onComplete: () => {},
30.     onError: (_sessionId: string, code: number, message: string) => {
31.       console.error(`识别出错：${code} ${message}`);
32.     }
33.   });
35.   // 3. 开始识别：recognitionMode 0 为麦克风，1 为写入 PCM 音频流
36.   engine.startListening({
37.     sessionId: 'demo-session',
38.     audioInfo: {
39.       audioType: 'pcm',
40.       sampleRate: 16000,
41.       soundChannel: 1,
42.       sampleBit: 16
43.     },
44.     extraParams: {
45.       recognitionMode: 0,
46.       maxAudioDuration: 20000,
47.       sessionGeneralLexicon: ['张三'] // 会话热词，优先级高于系统热词
48.     }
49.   });
50. });

复制代码

麦克风识别时 recognitionMode 设为 0；转写 PCM 文件时设为 1，并通过 writeAudio 按 640 或 1280 字节分片写入，分别对应 20ms 或 40ms 间隔。长语音需要把 recognizerMode 改为 long，并通过 finish 主动终止会话。单次写入字节数必须严格匹配规范，writeAudio 单次传入音频数据仅允许 640 字节或 1280 字节，分片间隔必须匹配。这里也体现了端侧语音识别接入的两个排障重点：一是引擎创建失败时先看错误码，例如 1002200001 表示引擎创建失败；二是 PCM 写入分片不符合规范时，识别链路容易异常。

性能、隐私与工程取舍
相较于传统云侧语音识别，端侧离线识别主要解决三类问题：网络依赖、数据泄露和交互滞后。隐私上，语音采集、音频解析、文本转换全流程在设备本地完成，原始音频数据、识别结果均不上传云侧服务器，数据不出设备，适配高敏感语音场景的合规需求。时延上，端侧不走“上传—推理—回传”的长链路，依托本地算力实时推理，可实现毫秒级识别输出，规避网络波动造成的字幕卡顿和转写滞后。开发接入上，开发者无需自研底层声学模型，直接调用系统级 API 即可构建离线语音识别能力，缩短开发周期，降低研发与运维成本。

对开发者而言，这套能力的价值是开箱即用、多终端稳健兼容和云侧资源减负。系统模型经过多终端、多业务场景打磨，一次开发、多端部署，落地兼容性更强；识别运算全部本地化，不占用云侧带宽与算力资源，能降低服务器运维压力与长期运营成本。对消费者而言，极速响应、无网场景覆盖和本地隐私闭环是直接体验收益：实时字幕、边说边转、语音指令响应更自然，飞行模式、地下室、偏远地区也能使用。

接入检查清单
最后把开发要点收束成一份检查清单：确认语种和音频输入类型；创建引擎时决定 short 还是 long；PCM 文件必须 16000Hz、单声道、16bit；麦克风识别 recognitionMode 用 0，PCM 写入用 1；writeAudio 只按 640 或 1280 字节分片，并匹配 20ms 或 40ms 间隔；长语音结束用 finish；专有词先用系统热词和会话热词双配置，注意两类热词总数不超过 200、单个长度 2 到 20；噪声环境不要只依赖热词，先做前置降噪；多端适配优先参考官方开发指南、API 参考、FAQ 和在线课堂中的完整工程。

热心网友7

感谢整理，这篇把 Core Speech Kit 的端侧离线识别讲得挺清楚。端侧和云侧不是简单比优劣，而是看业务边界：要断网可用、数据不脱离设备，就优先端侧；要多语种、超高精度，再评估云侧。这个选型思路很实用。 几个开发关键点也记下了：PCM 音频要 16000Hz、单声道、16bit；短语音不超过 60s，长语音不超过 8h；热词分系统热词和会话热词，会话热词优先级更高，总数不超过 200，单个长度 2 到 20；麦克风识别 recognitionMode 用 0，PCM 写入用 1，分片按 640 或 1280 字节写入，对应 20ms 或 40ms。长语音还要把 recognizerMode 改成 long，并通过 finish 主动终止会话。 另外你提到热词只能优化专有词汇精度，不能抵消环境噪声，嘈杂场景建议前置降噪，这点很实在。想问下同一个引擎在 finish 一次长语音会话后，能不能直接再 startListening 开新会话，还是需要重新 createEngine？系统热词在应用生命周期生效，会不会和会话热词一起占用 200 个总配额？末尾 writeAudio 单次字节数那里好像被截断了，期待后续补全 FAQ 和错误码。

热心网友5

看完这篇，感觉最大的价值是把端侧和云侧的边界讲清楚了，不是简单比技术优劣，而是按“断网可用、数据是否出设备”来选型。热词那部分也很实用，系统热词在创建引擎时配、会话热词在开始识别时配，而且会话优先级更高、总数200共享，这个配额确实得提前规划。 麦克风实时语音和标准PCM文件两种输入，加上短语音60秒、长语音8小时，基本覆盖了会议转写、离线字幕、口述笔记这些场景。代码示例里创建引擎、设置回调、开始识别三步也比较直观。 有个小问题：长语音识别过程中，onResult会持续回调中间结果，还是主要等finish后拿完整文本？另外文末writeAudio分片规则似乎只写到64，后面没显示全，如果方便可以补完整。整体很受益，期待后续降噪和错误码方面的实践分享。

热心网友2

感谢楼主整理，Core Speech Kit 这块讲得很实用。我比较关注端侧离线识别在会议记录、现场访谈和无障碍字幕里的落地，数据不脱离设备这一点确实很关键。看下来几个容易忽略的点：端侧和云侧不是谁替代谁，而是按断网要求和数据边界选型；热词虽然能提升专有词识别，但系统热词和会话热词共享 200 的总额，配置时得提前规划；PCM 文件输入对采样率、声道、位深要求很明确，麦克风模式和写入音频流模式也要在 recognitionMode 上区分开。接入示例把创建引擎、设置回调、开始识别三步串起来，对刚上手的人挺友好。后面如果做长语音归档转写，我会重点验证 long 模式和 finish 主动终止会话的配合。再次感谢分享。