半年多一直在做机器人语音方向的应用，现在产品基本上稳定下来了，在语音交互的路上踩过不少坑，在这里记录分享一下。假设看到这篇文章的人对AIUI的基本概念包括实体、技能、语料、意图都已了解。
最开始的语音处理方案
讯飞MSC录音+本地NLP处理。
当时还不知道有AIUI这个东西，本地做了一个简陋的NLP处理的程序。大概思路和AIUI的技能处理一样，先把不同的问题分类并定好优先级，然后从返回的语音文本中提取出关键字，分析意图。再对相应的意图做处理。
这种方案满足了最初的演示需求，但是机器人的语音交互体验不好，必须使用固定的句式、只能回答固定的问题。演示圆满完成之后，公司要求着力做好这个项目。本来说有个demo就行的任务，变成了产品级的项目。于是就有了下面的方案。
真正可行的语音处理方案
MSC录音 + AIUI语义解析 +本地技能处理
既然是产品级的项目，开始研究要怎么做。在AIUI的官网中看到了有关AIUI的介绍，发现其处理思路和我之前做的几乎一样，但其丰富的问题库，优秀的语义解析设计比我的好多了。也就是说，我可以用AIUI这套处理实现之前所有的功能，还能做的更好。
AIUI的接入有一定的学习成本， 经过几个月的实践，总结一下AIUI的技能语料设计的内容。
AIUI的语料是全匹配的，比如你设计的语料是“你叫什么名字”，问法也必须是“你叫什么名字”才能识别出来。由于录音中可能会存在各种各样的杂音，要想识别“你叫什么名字××××××”（×表示任意字符）这种问题，需要使用AIUI的通配实体。
如果终端的实体需要差异化配置，可以使用动态实体。动态实体分为应用级、用户级和自定义级。应用级可以在实体名相同的情况下，为每个 appid 设置不同的实体副本；用户级对每个用户维护一个实体副本；自定义可以自定义的维度，为自定义的维度设置不同的实体副本。我的应用在不同的城市，实体的数据是不一样的，相同城市，实体数据一样。所以选择了自定义维度，维度就是城市(city)。
动态实体在应用每次启动必须重新上传，否则不会生效。每次上传都会覆盖之前的动态实体。
语料设计时尽量不要出现文字，全部用实体来表示。
例如：我的某一条语料就是{common}{station}{common}{go}{common}{station}{common}
其中common是通配实体，可以匹配任意1-21个字符，go是一个静态实体，语料可以是“去，到，前往”等，station是一个动态实体，表示每个城市的站点。
这样设计的好处在于，如果发现某个词语有很多近义词，可以直接修改其静态实体就行，而不必修改语料的句式。技能在初期设计时，就应该做好区分，保持单一原则，即一个技能只处理一类问题。千万不要把不同类型的问题放在同一技能里面，当你后续需要对不同技能分类处理的时候，你就会感谢当初选择了单一原则。
当技能多了，避免不了会出现一个语料，一种问法，可能对应了多个技能里的意图。这个时候要怎么处理？我的策略是：技能分级，按优先级处理。为每一种技能设定一个优先级，只处理最高优先级的技能。
如何处理商店的技能：商店的技能其实很好处理，因为商店的技能基本上都是有直接答案的。我们可以统一处理。在answer这个字段里能解析到商店技能返回的语义结果的回答，我们只要处理这个信息就可以。
思考
1.AIUI的这套语音语义处理方案解决了录音、识别、语义解析功能，但是实际使用过程中，用户的问法不可能按照我们设计的来，如何才能最大限度地匹配出用户的意图？最好还需要自己做一些NLP的处理，比如可以计算用户的问法和语料库的相似度，选择一个相似度最大的意图返回给用户，或者引导用户做出正确的问法。