上文提到，语音助手可以触达每个产品的常用甚至所有功能有助于提高用户的使用效率;全局性的人工智能助手有助于整合信息自我学习提供更多帮助，所以未来我们后续的产品需要在人工智能助手的基础上进行设计。人工智能助手包括了可以被随时唤醒的语音助手，例如Siri，它可以语音对话和提供信息的展示;以及包括了操作系统层面的FEED，例如MIUI9的信息助手，它可以主动展示相关内容和入口。

　　在设计产品请关注以下几点：

　　1.为了方便用户使用语音唤醒功能，产品功能应该是可以瞬间被理解的，以及唤醒词是方便记忆和开口的，例如可以映射到常用或者真实生活中的词语;切勿使用使用户难以开口的唤醒词;同时考虑唤醒词的兼容性问题，例如不同方言有着不同叫法。

　　举例：「打开微信朋友圈」完全没有问题，但「打开微信我」就非常有问题，首先意思完全看不懂，其次用户不会第一时间想到。钱包在粤语里叫做「银包」，意思相同的词语应该可以相互映射。

　　2.聚合不同功能的页面设计是为了方便管理和发现入口，但本身对用户来说没有太大意义。后续请减少让用户费神思考和记忆的聚合页面，这样可以避免被语音助手或系统FEED唤醒时，展示的全是功能入口。(除非这页面便于用户理解以及里面的功能非常重要)

　　举例：微信第三个Tab承载着不同功能，用户可能知道「朋友圈」，「摇一摇」，但可能想不到这个聚合页面叫「发现」，因为「发现」这动词太抽象，用户难以第一时间想到。用户想到「钱包」这词更多联想到的是真实世界里装钱的那个钱包，但微信的钱包功能包括了各种服务金融功能，不符合用户第一时间下的心理预期。

　　3.不同设计对象请考虑模块化设计，尽可能采用不同入口和页面管理设计对象，方便用户唤醒设计对象。

　　例子：设计对象有可能是一个功能;也有可能是通讯录中的一个名字，他们属性和功能相同，但用户的记忆对象不同。

　　4.常用功能允许被系统FEED集成，方便用户第一时间使用。系统FEED也会相应提供入口打开相关产品。

　　5.考虑避免常用功能与其他功能的耦合，降低系统FEED的结构复杂性和操作成本。

　　例子：在微信朋友圈可以进入朋友的详细资料并进行聊天，朋友圈和聊天两个常用功能可以不断循环，耦合紧密会导致信息架构的复杂。从产品和用户角度设计完全没有问题，但不符合FEED的轻量结构。第四点在FEED内提供产品入口是为了在完全分隔功能的情况下做的体验补偿。

　　6.具有操作性的功能例如设置闹钟、查看天气、购买机票等需要考虑页面的信息展示和操作流程，也需要考虑语音输入的操作流程，两者的操作步骤在用户认知上需要统一。若做不到，请提供相应场景下的合理流程。

　　解释：眼睛接收信息时可以随处浏览，它具有xyz和时间四个维度;耳朵接收信息时只有时间这个维度，这会导致同时接收或者筛选的信息量具有很大差异。同理，这也是为什么语音识别发生错误时，用语音修正的成本远比用键盘修正文字错误大。

　　1、2、4和6这四点更多考虑的是用户在使用语音或打开APP操作APP时可能会产生不同的心理预期，所以需要保证设计对象在这两种操作上的一致性。2、3和5这三点是从模块化的角度来考虑，有助于减少功能的耦合，降低信息架构的复杂程度。

　　新型API和组件

　　为了保证人工智能底层数据的一致性和完整性，数据仓库需要为第三方应用提供身份信息、健康数据、兴趣爱好、工作信息、财产数据、信用度、消费信息、社交圈子、活动范围9项API服务。获得用户授权后，第三方应用可以得到用户特征并向数据仓库保存用户数据。人工智能也会提供更多功能给第三方应用，例如摄像模块、语音模块、身份验证模块、支付模块等组件，提高用户体验的同时也降低了产品的开发成本。

　　API

　　数据仓库和用户特征如下：

　　身份信息：名字、性别、年龄、家乡、身份证(身份证包含前4项)、账号、现居住地址和家庭信息

　　健康数据：基础身体情况、医疗记录和运动数据

　　兴趣爱好：饮食、娱乐、运动等方面

　　工作信息：公司、职位、薪酬和同事通讯录

　　财产数据：薪酬、存款、股票、汽车、不动产和贵重物品

　　信用度：由信用机构提供的征信记录

　　消费信息：消费记录(含商品类型、购买时间、购买价格和收货地址)、消费水平和浏览记录

　　社交圈子：通讯录(含好友、同事、同学和亲戚)和社交动态(含线下和线上)

　　活动范围：出行记录、主要活动范围和旅游

　　以上用户特征以API形式接入，第三方应用获得用户授权后才可访问和存储相关数据，相关细节请看第二篇文章。

　　组件