openWakeWord本地唤醒词方案：原理、部署与自定义训练实战

1. 为什么要折腾一个本地跑得动的唤醒词方案前两天给手头一个小型语音交互设备换固件的时候我发现自己又一次卡在同一个问题上唤醒词。设备本身有麦克风、有扬声器能跑Linux但想要一句干净的“你好小X”就得接云端要么就是烧钱买商业离线唤醒方案。说实话我对商业方案本身没什么偏见像很多智能音箱用的唤醒技术确实成熟识别率也漂亮。但我自己的需求往往比较尴尬——可能只是一个放在工位上的DIY中控可能是一个只有一块小小树莓派Zero驱动的终端盒子。这类项目要的是离线可跑、模型轻量、授权不折腾最好还能自定义几个词。于是我开始认真看openWakeWord这个项目。它的定位简单直接一个基于机器学习的本地唤醒词检测组件允许你直接用预训练模型识别“Hey Jarvis”“Hey Computer”这类词也可以自己录几段声音训练一个全新的唤醒词。它用ONNX Runtime做推理不需要GPUCPU就能跑在树莓派这类迷你设备上也能达到实时的检测速度。换句话说它试图在开发者社区提供一个所谓的“Hey Siri级别”的本地唤醒能力——不是苹果那种软硬一体的极致优化但对普通嵌入式设备和桌面项目来说已经是非常能打的一套方案了。这篇文章我就围绕openWakeWord把整套东西从原理、部署、自定义训练到实战避坑讲透。如果你正好在做智能家居网关、离线语音助手盒子、个人语音控制台或者单纯想在某个小设备上拥有一句自己的专属口令这篇内容可以直接当操作手册用。我会把环境配置、代码流程、模型训练逻辑以及我实际跑下来遇到的各种幺蛾子都放进来。2. openWakeWord的运行机制它凭什么敢说本地运行很多第一次接触openWakeWord的人会有一个误解觉得它和那些商业离线唤醒方案一样内部可能用了某种巨型模型。其实它走的是完全不同的路子整个推理链路设计得非常克制。2.1 从“小而专的音频模型”说起openWakeWord的核心是一个音频事件检测模型它针对的并不是“理解一整句话”而是“判断最近这一小段音频里有没有出现目标词”。这个定位非常关键因为唤醒词识别本质上是一个二分类任务——不是目标词就是非目标词。它不需要庞大的语言模型不需要上下文理解只要能把目标词和普通说话声、环境噪声区分开就行。模型层面openWakeWord使用的是一种相对轻量的卷积循环结构输入是音频的特征图输出是每个时间片上的“目标词概率”。最重要的是它推理走的是ONNX Runtime。ONNX Runtime的跨平台能力很强Windows、Linux、macOS都能跑还能在CPU上做各种算子优化。这意味着不需要安装PyTorch或者TensorFlow一整套重型依赖只需一个几十MB的ONNX Runtime库就能完成推理。我自己在实际部署的时候为了验证它到底有多轻量特意在一台树莓派Zero 2W上跑了性能测试。加载一个大约一百万级参数的自定义模型单次推理耗时大概在40毫秒到80毫秒之间浮动取决于系统的负载。考虑到唤醒词检测本身是一个持续运行的流式任务这种推理速度完全能满足“边录音边判断”的需求。2.2 音频特征处理让模型看到的不是波形而是“语谱图”直接喂给神经网络的不是原始音频波形而是经过预处理的声学特征。这也是很多做语音项目的开发者第一次碰openWakeWord时容易搞混的地方。openWakeWord内部用librosa做了特征提取把每25毫秒左右的音频帧转换成一串Mel频谱特征参数相当于把一段波形压缩成“随时间变化的频谱能量分布”。这样做有两个好处一是大幅减少数据量避免模型处理冗余的波形细节二是让模型对不同音色、不同音量更加鲁棒。同样是说“Hey Computer”男生女生说出来、离麦克风近一点远一点波形差异非常大但在Mel频谱空间里它们的共性会比波形明显得多。具体参数上openWakeWord默认使用16kHz单声道的音频输入每帧长度和滑窗步长在代码里写得很清楚。如果你直接在桌面上用麦克风采集需要确保音频格式是16bit PCM、采样率16kHz。很多人在部署时遇到“检测不到唤醒词”的问题往往就是麦克风采样的采样率不匹配模型拿到的是48kHz或者44.1kHz的音频流预处理出来的特征已经乱了模型自然怎么都触发不了。2.3 滑窗推理与“触发冷却期”的决策逻辑模型不是一秒钟判断一次整段录音而是采用滑窗的方式持续推理。简单说系统维护着一个固定长度的音频缓冲新音频进来时把最老的部分挤出去然后用这个滑动窗口内的音频做一次推理。这里有一个很多人不理解的设计模型输出的是“目标词在窗口内出现的概率”而不是“这句话就是唤醒词”的硬判断。openWakeWord的做法是设置一个触发阈值默认在0.5左右当概率超过这个阈值时判定唤醒。但这个概率曲线在实际运行中会连续飘动只靠单一帧的过阈值判断容易造成重复触发。openWakeWord提供了触发状态位triggered属性和重置机制。当一次唤醒被触发后系统会进入冷却状态即使后续几帧概率依然走高也不会立刻再次触发。只有当你调用相应方法重置状态或者冷却时间结束后才会响应下一次唤醒。我在实际项目里通常会用这个机制做“唤醒后置位”的操作——比如触发后打开录音上传直到用户说完一句话才复位。2.4 多模型并行可以同时监听多个唤醒词openWakeWord另外一个我很喜欢的设计是它可以同时加载多个模型。目录下的models文件夹放多少个ONNX模型运行时就都会加载进来然后一次性输出所有模型的预测结果。这意味着你可以同时监听“Hey Computer”和“Hey Jarvis”甚至自己训练一个专属词和官方预训练模型并行运行。在多模型的情况下系统会返回一个字典键是模型名值是概率分数。你可以在代码里分别为不同唤醒词绑定不同的回调动作比如“Hey Jarvis”启动音乐播放“Hey Computer”打开灯控界面。多模型并行推理的开销是线性增加的但官方模型都很小跑两三个模型对主流设备没什么压力。3. 把openWakeWord跑起来从安装到实现第一句唤醒理论说完了接下来就是实操环节。这部分我尽量把流程写得像傻瓜教程但每一步都会解释为什么要这么做方便你后续排查问题。3.1 环境准备别在依赖上翻车openWakeWord对Python版本要求不算苛刻我在3.9到3.11上都跑过都没什么大问题。安装主库用pip就能搞定pip install openwakeword但这里有一个容易绕弯的点单装openwakeword并不包含它内部运行时需要的所有音频处理依赖尤其在实际调用麦克风时还需要安装音频输入库。openwakeword本身侧重在有音频数据送入时的检测逻辑而不是直接帮你从声卡采样的全套流程。所以通常还需要pip install pyaudio sounddevicepyaudio负责从麦克风采集音频sounddevice在部分环境中比pyaudio更省心。我自己在Windows上遇到过pyaudio安装报错的情况尤其是在Python 3.11以上版本如果没有预编译的wheel就得先安装对应版本的PortAudio或者干脆换用sounddevice这个库在大多数平台都能一行装好。此外还需要librosa来处理音频特征。注意librosa的安装版本可能和numpy存在依赖冲突如果你原本的项目里有定死的numpy版本建议用虚拟环境隔离一下避免装完openwakeword之后其他代码跑不了。我个人的惯例是给这类语音项目单独建一个venv不跟主环境混。3.2 预训练模型与“首次使用即自动下载”机制如果你直接读文档通常会看到说“安装后运行时会自动下载预训练模型”。这个机制确实很方便但首次运行时往往让人一头雾水因为下载过程可能卡住或者下载不完整导致运行时静默跳过。我个人更推荐手动把官方模型仓克隆到本地然后把models目录放到项目里git clone https://github.com/dscripka/openWakeWord.git克隆下来的仓库里已经有现成的models目录包括“hey_jarvis.onnx”“hey_computer.onnx”等。使用方式也很直观from openwakeword import Model # 初始化模型指定本地模型路径 oww Model(wakeword_model_paths[./models/hey_jarvis.onnx])直接把ONNX模型文件路径传进去可以绕开自动下载带来的不确定性。这样还有一个好处后续你自己训练好的自定义模型也可以用同样的方式加载逻辑非常统一。这里必须提醒一句openwakeword在运行时会创建一个缓存目录存放下载的模型如果你是在无外网环境部署自动下载那条路基本会失败提前手动放置模型文件几乎算是必经之路。3.3 最小可运行代码让“Hey Jarvis”真正触发事件下面这段代码是我在桌面端跑通的最简版本不依赖任何复杂框架核心逻辑就是“读麦克风音频 - 交给openwakeword预测 - 检测到触发 - 执行回调函数”。import pyaudio import numpy as np from openwakeword import Model # 加载模型 oww Model(wakeword_model_paths[./models/hey_jarvis.onnx]) # 音频参数16kHz单声道16bit FORMAT pyaudio.paInt16 CHANNELS 1 RATE 16000 CHUNK 1280 # 每次读取的音频帧数约80ms audio pyaudio.PyAudio() stream audio.open( formatFORMAT, channelsCHANNELS, rateRATE, inputTrue, frames_per_bufferCHUNK ) print(监听中... 说 Hey Jarvis 试试) try: while True: # 读取一帧音频 data stream.read(CHUNK, exception_on_overflowFalse) # 转成float32数组范围[-1, 1] audio_array np.frombuffer(data, dtypenp.int16).astype(np.float32) / 32768.0 # 喂给模型预测 prediction oww.predict(audio_array) # 检查是否触发 if oww.triggered: print(唤醒成功) # 这里可以接你自己的业务逻辑 # 注意复位状态避免连续触发 oww.reset() except KeyboardInterrupt: print(停止监听) stream.close() audio.terminate()这里有几个细节需要展开说说它们决定这段代码能不能真正稳定运行。CHUNK大小的选择我用的1280约等于80毫秒的音频数据。openwakeword建议的音频块不要太小否则单次推理的信息量不够也不用太大否则触发延迟会偏高。实测中1280或1600都是合理区间。float32的归一化pyaudio读出来的是16bit整数范围在-32768到32767之间必须归一化到-1.0到1.0的浮点数模型才能正确处理。oww.triggered状态这是一个属性表示在当前预测帧里模型是否已经判定唤醒。但要注意它不一定要求每一帧都超阈值而是结合了滑窗和延迟逻辑。我在实际调试时发现有时你明明说了唤醒词但它并没能立即触发而是隔了一帧才触发。这是正常的因为模型是在看到完整的音频模式后才给出高置信度通常会有100到200毫秒的感知延迟。3.4 如何验证你的安装没问题写完代码直接运行如果说了“Hey Jarvis”毫无反应先别怀疑代码逻辑按这个顺序自查第一麦克风是否真的在采集先打印几秒钟的音频数据最大值确认音频数值不是全零或者异常小。第二采样率是否匹配如果你在系统设置里改了麦克风默认采样率pyaudio读取时按RATE16000去读但实际设备输出的是44.1kHz数据就会错位。第三模型文件是否损坏如果手动下载的模型不完整Model初始化时会直接报错不会有静默失败。第四阈值是不是太高尝试在代码中打印oww.prediction看看在说话时概率值大概是多少。如果概率值最高也只有0.2基本就是音频预处理不对劲或者环境噪声干扰太大如果概率能达到0.7以上却就是不触发那大概率是触发状态管理逻辑写得不对比如上一轮触发的冷却状态还没复位。4. 让唤醒词变成你自己的话训练一个专属词汇官方预训练模型只能识别固定的几组词你要真想在自己项目里用“你好小盒”“芝麻开门”这种个性化口令就必须走自定义训练这条路。openWakeWord这套训练流程挺有门槛的因为它不是一个纯GUI工具得稍微动点命令行和Python代码但整体思路非常清晰完全可以照着做。4.1 自定义训练的整体思路正样本、负样本与聚类嵌入传统语音识别训练可能需要几百小时标注语料自定义唤醒词训练卷不了那么重。openWakeWord走的是一条更轻巧的路线它不训练一个全新的端到端音频模型而是借用一个预训练好的音频编码模型把每一段音频提取成一个“嵌入向量”然后在这个向量空间里做分类。形象点说预训练模型相当于一杆秤已经把音频特征量化成一组维度坐标了你要做的只是在坐标空间里圈出“目标词”和“其他”两类区域。正样本就是你反复录制的目标词音频。负样本则包括任何人说话非目标词、环境噪声、音乐、电视声等。系统训练的目标是让目标词在嵌入空间中聚成一簇同时尽量远离负样本簇。训练完成后导出的模型就是一个小型分类器不再包含庞大的音频编码器运行时配合openwakeword的推理框架使用。这种迁移学习的思路让自定义词的数据需求量大大降低。官方示例给出的参考是每个词收集100到200条正样本时长大约0.5到1秒负样本几百条即可。相比动辄需要几百小时的语音识别项目这个采集量已经是相当友好了。4.2 录音数据准备怎么快速收集一批质量过关的样本数据采集是整个流程里最耗时也最影响最终识别率的一环。我的经验是千万不要一口气坐在电脑前连录几百遍同一个词那样出来的样本韵律单调、音量一致训练出来的模型换个人说就很可能认不出来。更好的做法是打散采集环境。同一个词分别在不同房间、不同距离、不同音量下录。正样本的每条录音控制在0.8秒到1.5秒之间前后留一点静音段没关系但目标词必须完整落在中间。另外不要只录你自己的声音尽量找三到五个不同的人分别录哪怕每人只录二三十条多音色的覆盖效果都会远超一个人录几百条。负样本采集相对轻松可以录电视声、键盘声、脚步声也可以直接把一两个小时的播客音频切成几秒一段。负样本的目标是覆盖日常环境中可能出现的干扰声。如果项目是放在厨房里的那就尤其要录一些倒水声、厨具碰撞声如果是放在工位上键盘声和同事说话声就特别重要。openWakeWord官方仓库里有一个数据整理的脚本结构主要是按目录存放。我在本地建立了这样的目录布局custom_wake_word_data/ ├── positive/ │ ├── 001.wav │ ├── 002.wav │ └── ... ├── negative/ │ ├── 001.wav │ ├── 002.wav │ └── ... └── test/ ├── positive/ │ ├── 001.wav │ └── ... └── negative/ └── 001.wav正负样本分目录放好之后训练脚本会按目录遍历所有wav文件。文件名格式建议统一用数字编号避免脚本在处理中文文件名时出问题。4.3 用官方Colab或本地脚本完成训练导出ONNX模型openWakeWord作者提供了一个基于Colab的训练流程对于没有GPU的人来说特别友好。因为自定义训练阶段实际只是训练一个分类层计算量不算大CPU也能完成但Colab上跑起来快很多。整个训练流程大致是读取正负样本 - 提取嵌入向量 - 训练分类器 - 导出ONNX模型。分类器的结构通常是一个简单的神经网络或逻辑回归层输入是嵌入向量维度输出是目标词和非目标词的概率。训练脚本导出的模型文件名后缀是.onnx本质上是一个封装好的推理模型。openwakeword自定义模型在内部结构上比预训练模型小很多因为分类器参数极少。我导出过的一个“你好小盒”模型文件只有几百KB推理时间比官方模型还短。这里必须注意一个版本细节不同版本的openwakeword使用的嵌入模型可能不同所以训练环境和运行环境需要保持同一套预训练特征提取代码。我一开始就吃过这个亏——用最新版Colab代码训练的模型拿回旧版openwakeword运行时预测结果完全乱套。解决办法就是定期更新本地的openwakeword到训练时对应的版本。4.4 模型导出后如何加载与联调训练完的模型放回项目的models目录然后用前面提到的Model加载方式指定路径即可。自定义模型通常需要比官方模型调低触发阈值因为我实测过小样本训练出来的分类器置信度分布会比大规模训练的更保守同一个词说出强度稍微弱一点概率就会掉到0.4以下。我的做法是在初始化后用一段真实录音做验证打印预测概率观察目标词出现时概率最高能到多少其他语音最高能到多少然后取两者之间的中间值作为阈值。比如目标词最高0.86非目标词最高0.31那么阈值设在0.5左右就相对合理。千万别直接沿用默认的0.5尤其是自定义模型不然大概率会出现“说话没反应”或者“噪音狂触发”两个极端。另外模型对接的时候建议做一次“盲测”——让一个没有参与录音的人说这个唤醒词看能不能触发。这能筛掉很多过拟合问题。如果只有录音者自己发音稳定能触发换个人就失灵说明正样本的音色多样性不够需要补充不同人的声音再去训练而不是一味调低阈值。5. 部署到实际设备上的调优与那些文档里没写的坑跑通demo容易真的要放到嵌入式设备或者七乘二十四小时的环境里稳定运行坑就多了。我在两种典型设备上做过实测一台树莓派4B一台树莓派Zero 2W还有一台普通的Windows办公电脑。三台设备的处理能力和音频环境完全不同踩过的坑也不太一样。5.1 树莓派部署性能、功耗与音频接口的取舍树莓派上跑openwakeWord最大的问题不是CPU扛不住推理而是默认音频接口的质量和延迟问题。树莓派的3.5mm音频接口和板载麦克风属于典型的低成本模拟方案底噪大、采样率不稳定。如果只是做DEMO勉强能用要做长期运行的项目我强烈建议接一个USB声卡或者USB麦克风尤其是那种支持16kHz/48kHz采样率的免驱设备。USB声卡的稳定性和底噪控制通常比板载好很多特别是用树莓派做语音控制时拾音质量直接决定唤醒率。我做过一次对比板载麦克风在距离半米处说唤醒词识别率大约只有六成换成几十块钱的USB麦克风后同样的测试条件识别率能提到九成以上。性能方面树莓派4B跑一个官方模型单次推理大约30到60毫秒CPU占用单核的一半左右。树莓派Zero 2W会吃力一些推理时间约80到120毫秒但仍然在可接受范围。如果要在Zero上跑多模型并行CPU占用会接近满载建议只保留一个最重要的唤醒词模型。5.2 误唤醒怎么调阈值、VAD前置与场景化数据实际用下来误唤醒是比漏唤醒更让人头疼的问题。因为设备在运行时全程监听难免碰到电视播报里出现类似“Hey Jarvis”的声音或者自己家里人的闲聊里恰好带出了相似的音节组合。openwakeWord本身提供的调节手段就是阈值但阈值调高之后必然牺牲灵敏度。我实践下来更好用的办法是在openwakeWord之前加一个简单的语音活动检测也就是VAD前置。只有先检测到有人声能量出现才把音频交给openwakeWord做进一步判断没人说话的时候根本不做唤醒词推理。这样做的收益是双重的一是明显降低误唤醒率二是CPU占用大幅下降。我用的VAD是webrtcvad这个库极轻量在树莓派上跑也没压力。检测到有人声的帧才将音频推进openwakeWord的预测队列静音帧直接跳过。另外一个很有效的方法就是场景化收集负样本。如果误唤醒频繁发生在特定场景比如家里电视开着那就专门录一段电视节目的声音做负样本重新训练自定义模型。我用这个方法把一个自定义词在电视节目场景下的误唤醒率从每小时七八次降到了两三天一次。5.3 常用参数参考一个可以抄作业的起点参数值并不是越高越好一切都是以你的实际场景为基准。我整理了一张表是我在不同设备上验证过的相对稳妥的起点你可以在此基础上微调。触发阈值官方模型0.5自定义模型0.4到0.6之间需要实测校准采样率固定16000 Hz不可随意更改单次音频块大小1280或1600对应80毫秒或100毫秒判断冷却时间/复位逻辑触发后至少500毫秒内不响应新的触发用oww.reset()配合定时器实现CPU占用目标树莓派4B上官方模型约10%到20%VAD前置后有明显下降麦克风推荐USB免驱麦克风距离半米内效果最佳这些参数不是硬性规范但它们决定了你在调优时的基准线。参数调整时一次只改一个变量不然真出了问题根本不知道是哪个改坏的。5.4 持续监听下的内存与日志管理细节长期运行的项目还会遇到两个“隐藏坑”内存增长和日志刷屏。openwakeWord的模型在初始化时加载到内存之后一般是稳定的。但如果你在循环里频繁创建新的audio数组而没有正确释放Python的内存还是会悄悄涨。我的习惯是在主循环里复用同一个数组对象而不是每帧都新建。对于音频流当心记录数据叠加必要时定期清空。日志方面如果你把文本日志直接打印到标准输出在无人值守的树莓派环境里很容易把存储塞满。建议使用logging模块控制日志级别把非关键信息关掉只保留唤醒事件和异常日志。还有一个容易忽略的问题电源稳定性。树莓派在监听唤醒词时CPU负载会有小幅波动如果用劣质电源瞬间电流不足可能会导致系统降频进而影响推理时间。我在Zero 2W上遇到过类似情况换一个功率足够的电源后推理延迟立刻稳定下来。6. 把它接进完整的语音链路不只是触发一个回调openwakeWord只是整个语音助手的“耳朵开关”真正让它有用的是唤醒之后接下去的动作。我在项目里通常会把整个链路拆成三个部分唤醒词检测、语音识别ASR、指令执行与回复TTS。6.1 关键设计唤醒后录音的交接策略一个经典失误是这样的检测到唤醒词后立即开启录音结果把唤醒词最后一个音节的尾音也录进去了ASR识别出来的文本经常以残缺音节开头。解决办法是在触发唤醒后延迟300至500毫秒再开始录音让尾音过去同时给用户一个明确的“已唤醒”提示音。这样用户听到提示后会自然停顿一下再说话录音质量会好很多。另外唤醒后的这段时间openwakeWord还在持续推理极有可能因为后续说的话太像唤醒词而二次触发。代码里必须有状态标志在“唤醒后待识别”这个阶段禁用唤醒词检测直到本次对话结束。6.2 离线还是云端根据场景选择ASR引擎唤醒词那句口令本地搞定之后后面的完整语音识别可以选择离线或云端。如果设备能联网云端ASR的识别率通常更高如果追求隐私和完全离线运行可以用Whisper的tiny/base模型或者Vosk这类轻量语音识别。我自己的做法是做了两层抽象在唤醒词触发后先尝试本地ASR如果置信度不够高再请求云端识别。这样既兼顾了响应速度又保证了识别率下限。但要注意这种双轨方案需要处理好网络超时和错误重试否则用户等待时间会变得不可接受。6.3 TTS反馈与交互节奏语音助手的体验不只在“听懂”还在“回应”。唤醒成功后的反馈音或者一句简短的“在的”能让整个交互节奏自然很多。TTS方案我试过espeak、edge-tts以及一些本地TTS模型各有利弊。嵌入式设备上espeak最轻量但音色机械edge-tts音色自然但需要联网。如果你的项目允许联网用edge-tts这类云端方案体验会好一个档次如果彻底离线piper这类针对嵌入式设计的TTS也是个不错的选择。交互节奏上有一个小技巧唤醒反馈不要太快也不要太慢。太快了用户还没来得及说完话反馈音就盖住了后面的语音太慢了用户会以为没有唤醒成功。我实测大约300到500毫秒的反馈延迟比较合适也就是在触发唤醒后先停顿一下再播放在的。6.4 一台设备多用户场景怎么处理兜底如果你做的是家庭共用的设备多用户场景有几个需要注意的点。openwakeWord本身对音色并不敏感但唤醒词训练时的数据如果只覆盖单一声色其他人说起来识别率会明显下降。解决办法要么在训练时尽量覆盖不同说话人要么接受“默认唤醒词对所有人通用、自定义词只对特定人高灵敏”这种差异。更实际的问题是设备唤醒之后怎么判断这个声音是谁说的这已经超出openwakeWord的范畴属于声纹识别。如果项目需要多用户区分建议在唤醒后接一个轻量说话人识别模块而不是试图在唤醒词模型里强行加入说话人维度。openwakeWord在唤醒词层面只负责“听到没听到”不负责“谁在说”把期待值放对位置后续设计才不会乱。7. 一点个人实操体会如果只看文档你可能会觉得openwakeWord就是一个平平无奇的Python库但真正把它放到真实项目里打磨一轮之后我最大的感受是它的设计思路非常“嵌入式友好”。它不在功能上贪多专注把唤醒词这一件事做好计算开销、模型体积、自定义能力都留出了足够的腾挪空间。尤其让我觉得值回票价的是自定义训练。以前我想给项目加一个独一无二的唤醒词基本只能看商业方案的脸色要么付费要么被封闭在别人的生态里。有了openwakeWord这样的开源组件我自己录几十分钟音频、跑一次训练就能得到一个属于自己项目的专属口令而且完全离线、不依赖云、不产生任何使用限制。这种掌控感是拿预算买商业SDK很难替代的。最后再分享一个我反复用到的小技巧定制唤醒词的时候词本身尽量选择三个音节以上、发音开口度大、和其他常用词区别明显的组合。比如“你好小盒”就比“启动”好用得多“小盒”这种带有平仄对比的词在Mel频谱空间里辨识度天然更高。选词选得好后面所有训练和调参的工作量都能小一半。