我們需要什麼樣的智能音箱

現有的智能音箱更多是從廠商的角度設計出來的，其作為一個一直錄音的設備其安全性讓人存有疑慮，而其功能上從某種程度上看是被封印住的。如果從用戶的角度設計，可以是另一個樣子。

先看看背景。

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們怕是不會為用戶買單了）

推薦閱讀：