我们需要什么样的智能音箱？

现有的智能音箱更多是从厂商的角度设计出来的，其作为一个一直录音的设备其安全性让人存有疑虑，而其功能上从某种程度上看是被封印住的。如果从用户的角度设计，可以是另一个样子。

先看看背景。

2014年Amazon发布了Echo，智能音箱新物种诞生。到2017上半年，顺着AI的风，智能音箱在国内呈燎原之势，据说在深圳南山区就有100多家厂商做智能音箱。而2017下半年，BAT都入了场，小米携￥299的小爱同学肆虐友商，众多友商怕是把自己的BOM表掏出来看了又看，而后阿里在双11以￥99的价格促销天猫精灵，近乎买一年VIP音乐会员白送天猫精灵，似乎这个舞台对于大多数小厂商来说还未来得及登场就要谢幕了。

然后对于用户而言，智能音箱才刚刚崭露头角。虽然有数十家厂商推出数十种智能音箱，但没有一个跳出Amazon对Echo的设定。用关键词唤醒，在云端扩展Skills，本质上这些智能音箱是一个样。并不是说Amazon对Echo的设定不合理，Amazon在设计Echo时必定经过深思熟虑，Echo团队就有千人之众。实际上，从厂商的角度看，Echo的设定非常合理，这种设定能形成足够深的护城河，能带来足够大的商业价值；只是，从用户的角度，这不够好。

现有的智能音箱在哪里不够好？开头也说了，一是安全存疑，另一是功能受限。

智能音箱安全存疑

身旁有一个一直录音的设备很容易让用户有一种被监听的感觉，从交互逻辑上看，智能音箱在被关键词唤醒之后才发送当前语音数据到云端，但那是一个黑盒子，用户不知道里面真的在做什么，谁知道ta会不会悄悄地录音，偷偷地上传。用户会因为那是大公司的产品而放心吗？有的人会，但不是所有人都会。

解决安全的疑虑，这里两个思路。一是设计上的，保证语音被上传时有明显的提示（通常是灯光提示），可以把智能音箱分成A、B两个模块，模块A负责录音、控制灯光并检测关键词，模块B负责其它逻辑，A检测到关键词时触发事件给B，B请求向A请求语音数据，A向B发送数据时用灯光提示，其中将A的逻辑固化，则可保证B从A获取语音上传数据时，A一直有提示。另一个是流程上引入代码审查和测试，让智能音箱不再是黑盒子，当然开放源码是最直接的。

智能音箱功能受限

智能音箱大多用的CPU并不弱，拥有类似低端智能手机的算力，有的甚至跑的也是Android，同一个手机上可以跑Siri、Google Assistant、Alexa、Cortana，但智能音箱只跑了一个应用，Google Home只跑Google Assistant、Echo上只养了Alexa、小米AI音箱只囚禁了小爱同学，其实每个设备都可以把ta们都圈养了，叫到谁，谁出来秀秀。

相比手机的人机接口是触摸屏，智能音箱的人机接口是语音，智能音箱其实也是一个语音交互的通用计算平台，上面的应用当然不止局限于跑个语音助手，像手机一样开个应用商店也是可以的。

再想想让现在的智能音箱控制旁边距离5厘米的灯，控制指令大多数要半个地球转一圈回来。小米音箱控制小米台灯都是一家人还如此。天猫精灵要控制小米台灯要费死劲了（把小米台灯的局域控制打开，Home Assistant在Pi运行并添加小米台灯，外网架个支持https的服务器，然后开发一个天猫精灵skill，大致如此）。

这大概都是源于Amazon的Echo只开放了云端的skills，跟随者还自忙于借鉴呢。本地如此强大的计算能力完全废了。

所以呢，如果从用户的角度设计智能音箱，把ta设计成一个语音交互的通用计算平台吧，打造一个语音交互应用的应用商店，可以把天猫精灵、小爱同学、Alexa等都入住到设备中，当然也不忘了代码审查，能开源当然最好了，不要是一个黑盒子，要让用户用的放心。

这样的智能音箱肯定会好用多了，当然也会贵啦-_-（阿里baba们怕是不会为用户买单了）

作者：Yihui

谢谢阅读，欢迎分享给您的朋友：『优雅派』 » 我们需要什么样的智能音箱？