打断，是用户默认免费而工程上最贵的那个功能
让用户在设备说话的中途，靠开口就打断它，在消费级硬件的成本约束下是个系统性难题，没有又便宜又可靠的解法。我们为这件事专门上了一颗降噪 IC 加一套算法，调了几周，这仍然是老实的结论。
本来想做成什么样
打断看起来很简单。你一开口，设备就停下来听你说。这是对话最基本的礼貌，每个用户都默认语音 AI 应该这样。我们把它当成一个细节，为它单独留了硬件预算，然后发现是个坑。
真正卡在哪里
在自己办公室测试的时候，旁边同事在打电话。设备把他的声音当成了打断指令，把跟我这边的上下文整个丢掉了。不是很远的声音，也不算响，就是几米外另一个成年人在正常音量说话。
根子在于，打断不是一个「够不够响」的问题。要判断对，设备得同时知道三件事，谁在说话、在什么位置说、说的内容是不是给这台设备的。单拿一件出来都难，三件叠在一起放到一块控成本的消费级板子上，基本无解。
四条路，各自怎么失效
靠距离
孩子抱着玩具跑、放桌上、拿手里，嘴和麦克风的距离从来不稳定，任何建立在距离上的阈值都会一直漂。这条路在开始之前就堵死了。
靠音量阈值
环境声和用户自己说话的音量高度重叠。电视、旁边的谈话、窗外的街声，都落在你关心的那个人所在的区间里。同一个测出来的音量，可能是主人在说话，也可能是电视，光靠幅度分不开。
靠声纹
技术上是最好的答案，锁定注册用户，别人一概不理。但它需要的算力和授权成本，消费级玩具的 BOM 扛不住，所以它是被价格排掉的，不是被技术排掉的。
靠本地降噪 IC
这是我们实际发货的方案。有效果，在相对安静的室内表现可以接受。在嘈杂的开放环境里，误触发仍然会发生。我们没有解决这个问题，只是把失败率挪了个位置。
手机助手为什么能做到
手机上的助手打断做得好，是因为背后有麦克风阵列、高性能应用处理器和云端算力。把这三样搬进一台控成本的玩具，每一样都会撞坏点什么。阵列增加体积和成本，处理器把 BOM 打穿，云端往返带来延迟和网络依赖，而这个产品恰恰要在网不好的时候也能用。
差别在约束条件，跟谁的算法更聪明没关系。
最后发出去的是什么
我们把触发边界卡紧，接受设备偶尔漏掉一次真正的打断，也不要它一直对整个房间做出反应。用户喊它名字或者清楚地朝它说话时，响应是可靠的。在开放的嘈杂环境里做到零误触发，以今天这个成本做不到，我们宁可说清楚，也不想让渠道在上市之后自己发现。
可以推广的那部分
做 AI 硬件，用户觉得理所应当的那些交互，往往是工程上最贵的。打断是其中一个。如果你在给一个语音产品定规格，把这个功能单独算钱，别默认它跟着语音链路一起来，并且尽早决定你希望错误往哪个方向偏。