我想要什么样子的智能音箱？（4）

今天老土想要说说智能音箱相关的生态建设。智能音箱这种入口型的产品注定不可能单单某个厂商的支撑搞起来，即使是亚马逊、Google、微软和苹果也不行，当然BAT（百度、阿里、腾讯）也不行。因此所有入行智能音箱的大厂纷纷祭出“生态建设”的大旗。

关于智能音箱的生态建设，可以先从Amazon讲起。毕竟目前在智能音箱及其相关的生态建设中，Amazon是遥遥领先与其他厂商的。目前Amazon Alexa上发布的技能已经超过了15000个。

Amazon Alexa上发布的技能

关于Amazon智能音箱的生态环境结构，老土觉得下图说的简单而清晰。

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开发插件（Alexa Skills Kit），或是接入语音服务（Alexa Voice Service）。

Alexa的“技能”类型

如果选择为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则很可能对音箱侧（硬件）抓的更紧，主要是在服务（业务）端向开发者开放。

[未完待续]