I Turned a Product Name into an Offline Wake Word — What I Had to Test

Most smart products already have a name. The hard part is making the device hear that name reliably without sending every conversation to the cloud. This is the product question behind a custom wake word: can a device recognize one short phrase locally, then start the next interaction?

大多数智能产品都已经有了名字。难点在于如何让设备可靠地识别该名称，而无需将所有对话发送到云端。这就是自定义唤醒词背后的产品问题：设备能否在本地识别一个短语，然后开启下一次交互？

The product name and the wake word are different things. A brand name is designed for people. A wake word is designed for a detector. The same phrase can be a good brand name and a poor wake word if it is too short, too common, or easily confused with normal conversation. For an example product, imagine a small robot called “Taro”. The desired flow is: “Hey Taro” → wake the robot; “Move forward” → start a fixed action; “Stop” → stop the motor. The wake phrase and the fixed commands are not the same product requirement.

产品名称和唤醒词是两码事。品牌名称是为人类设计的，而唤醒词是为检测器设计的。同一个短语如果太短、太常见或容易与日常对话混淆，它可能是一个好的品牌名称，却是一个糟糕的唤醒词。以一个产品为例，想象一个叫“Taro”的小机器人。理想的流程是：“Hey Taro”→唤醒机器人；“Move forward”→启动固定动作；“Stop”→停止电机。唤醒短语和固定指令并非同一项产品需求。

KWS or ASR? If the product needs to understand arbitrary sentences, names, numbers, or parameters, it needs speech recognition and intent handling. But if it only needs one wake phrase or a small list of commands, keyword spotting is a more focused option.

KWS（关键词检测）还是 ASR（自动语音识别）？如果产品需要理解任意句子、名称、数字或参数，它就需要语音识别和意图处理。但如果它只需要一个唤醒短语或少量指令列表，关键词检测是一个更具针对性的选择。

KWS does not try to transcribe everything. It asks a narrower question: “did one of the target phrases occur?” That makes a small, local model possible.

KWS 不会尝试转录所有内容。它提出的问题范围更窄：“目标短语是否出现过？”这使得构建小型本地模型成为可能。

What I would test before choosing the name: I would not approve a wake word from the spelling alone. I would test: Several speakers saying the phrase naturally; different speaking speeds and distances; the target microphone and enclosure; background conversation, music, fans, and household noise; similar-sounding phrases that should not trigger the product.

在选择名称之前我会测试什么：我不会仅凭拼写就批准一个唤醒词。我会测试：几位说话者自然地说出该短语；不同的语速和距离；目标麦克风和外壳；背景对话、音乐、风扇和家庭噪音；以及不应触发产品的相似发音短语。

The browser is a useful first filter. It can tell us whether a phrase is worth taking to a device. It cannot prove that the same result will hold after the microphone, enclosure, distance, and noise environment change.

浏览器是一个有用的初步筛选工具。它可以告诉我们一个短语是否值得应用到设备上。但它无法证明在麦克风、外壳、距离和噪音环境改变后，结果依然保持不变。

The delivery path: The practical flow is: Product name → Train a custom keyword model → Test with real voices → Export ONNX or TFLite → Run locally on the target product. For a product team, the useful deliverable is not only a model file. The team also needs the audio input assumptions, feature extraction path, threshold behavior, cooldown logic, and a way to connect a detection callback to a safe product action.

交付路径：实际流程为：产品名称→训练自定义关键词模型→用真实语音测试→导出 ONNX 或 TFLite→在目标产品上本地运行。对于产品团队来说，有用的交付物不仅仅是一个模型文件。团队还需要音频输入假设、特征提取路径、阈值行为、冷却逻辑，以及将检测回调连接到安全产品操作的方法。

Where a small custom model fits: For my experiments, I wanted a model that could run offline and fit several possible targets: Python, Web, Android, and embedded hardware. A standard ONNX or TFLite artifact makes that transition easier than a platform-locked runtime. Voicute is one way to start this process without building the training pipeline first: enter the product name, train a Basic model, test it with real voices, and decide whether the result is good enough to download.

小型自定义模型的适用场景：在我的实验中，我需要一个可以在离线状态下运行并适配多种目标平台的模型：Python、Web、Android 和嵌入式硬件。标准的 ONNX 或 TFLite 工件比平台锁定的运行时更容易实现这种转换。Voicute 是一种无需先构建训练流水线即可开始此过程的方法：输入产品名称，训练一个基础模型，用真实语音进行测试，然后决定结果是否足够好以供下载。

Real-voice enhancement can help when the target users have a specific accent or speaking style. The honest boundary is important: online testing is a screening step, not a production guarantee. The final product still needs measurements for recall, false triggers per hour, latency, memory and power.

当目标用户有特定的口音或说话风格时，真实语音增强会有所帮助。诚实的界限很重要：在线测试是一个筛选步骤，而不是生产保证。最终产品仍然需要对召回率、每小时误触发次数、延迟、内存和功耗进行测量。

A minimal local integration example: The runtime should expose a simple event to the application layer. The application should also implement cooldowns and safe failure behavior. A detector should not repeatedly start an action because the same phrase remains in the audio buffer.

最小化的本地集成示例：运行时应向应用层公开一个简单的事件。应用程序还应实现冷却时间和安全故障行为。检测器不应因为音频缓冲区中残留相同的短语而重复启动操作。

What I would ship with the project: The ONNX or TFLite model; a reproducible inference example; the supported sample rate and audio format; threshold and cooldown defaults; a test checklist for the final microphone and enclosure; clear limitations instead of a universal accuracy claim.

我会随项目交付的内容：ONNX 或 TFLite 模型；可复现的推理示例；支持的采样率和音频格式；阈值和冷却默认值；最终麦克风和外壳的测试清单；明确的局限性说明，而非通用的准确性声明。

The open-source runtime and examples are available in onnx-wakeword. If you want to test your own product name, use the Voicute online training page. Disclosure: Voicute is my project. I am sharing the engineering process and its limitations, not claiming that one wake-word model is best for every language or device.

开源运行时和示例可在 onnx-wakeword 中找到。如果您想测试自己的产品名称，请使用 Voicute 在线训练页面。披露：Voicute 是我的项目。我分享的是工程流程及其局限性，并非声称某一个唤醒词模型适用于所有语言或设备。