今天老土想要說說智能音箱相關的生態建設。智能音箱這種入口型的產品注定不可能單單某個廠商的支撐搞起來，即使是亞馬遜、Google、微軟和蘋果也不行，當然BAT（百度、阿里、騰訊）也不行。因此所有入行智能音箱的大廠紛紛祭出“生態建設”的大旗。
關于智能音箱的生態建設，可以先從Amazon講起。畢竟目前在智能音箱及其相關的生態建設中，Amazon是遙遙領先與其他廠商的。目前Amazon Alexa上發布的技能已經超過了15000個。
關于Amazon智能音箱的生態環境結構，老土覺得下圖說的簡單而清晰。
在上圖中，Amazon就是專注做好位于中間的Alexa服務（https://avs-alexa-na.amazon.com），其中所有的“周邊”統統開發給第三方實現。如此開放的心態，讓開發者非常容易接入Alexa。
如果開發者想開發一款基于Alexa的智能音箱，簡單！Amazon提供了官方的智能音箱端的示例代碼（https://github.com/alexa/alexa-avs-sample-app）。在此?示例代碼中，音箱喚醒用了 Sensory 和 KITT.AI，麥克風陣列用了科聲訊的兩麥方案。因為Alexa不綁定任何硬件方案，喚醒和錄音的技術方案完全掌握由開發者自己決定，Alexa只是對錄音的質量提出要求。
如果開發者想基于Alexa提供某種技能。這個就更加簡單了！開發者可以選擇為Alexa開發插件（Alexa Skills Kit），或是接入語音服務（Alexa Voice Service）。
如果選擇為Alexa開發插件。Alexa支持三種類型的插件：自定義（custom）、智能家居（smart home）、快報（flash briefing） 。Alexa 并不要求開發者將自己的內容資源（如音視頻、問答對等）上傳到亞馬遜， 而只要在Alexa 中定義「意圖」，當用戶觸發「意圖」時調用開發者定義的接口，開發者自己在接口中返回 Alexa 要回答用戶的答案。這種調用方式與微信公眾號非常類似。 Alexa 做到了「意圖」和「回答」的分離，開發者在 Alexa 平臺定義「意圖」，在自己的服務器上實現「回答」。
如果選擇接入Alexa的語音服務。開發者需要先在開發者中心創建一個語音服務的應用，從而獲得兩個 KEY： Client ID 和 Client Secret（這兩個 KEY 值是調用接口時需要用到的）。接口地址為：https://avs-alexa-na.amazon.com，請求接口時傳遞錄音文件，Alexa 的云端同時進行了語音識別和語義理解，將音頻文件轉換為文字，然后對文字進行理解，如果觸發了某個技能插件的「意圖」，則調用開發者的定義第三方服務器的接口；如果是聽歌或聽書等「意圖」，則調用亞馬遜自家的資源。語義理解后 Alexa 將需要返回的文字內容合成為音頻文件，所以接口的返回內容也是音頻文件。
上述關于Alexa接入的相關內容改編自“一文看懂Echo和Alexa，亞馬遜如何用蘋果的玩法在玩語音？”
通過上述分析可以看出，Amazon在面對智能音箱的產業時心態非常開放，只是專注于解決語音識別和“意圖判定”這兩個核心功能。其他的部分都不做強制要求，但貼心的提供了“參考實現”，從而不但減少了對開發者的限制，而且增加了對開發者的支持。
老土不得不給Amazon點個“贊”！目前Amazon在智能音箱領域已經算是漸入佳境，而Google、微軟和Apple則在積極跟進，但目前還看不清這幾家的思路。不過如果按照企業的調性分析，Google很有可能走Amazon類似的路線。而微軟和Apple則很可能對音箱側（硬件）抓的更緊，主要是在服務（業務）端向開發者開放。
[未完待續]
