2.8异常处理
如果系统没有听到或者没有理解用户说的话，要提示用户再说一次，这很重要。让用户知道自己的话是否被机器听见，以及是否被理解，有助于对话能够流畅的进行。当用户一直没有听见机器反应时，会本能地重复一遍，当用户的重复时间点过了机器设置的接收时间上限时，就被被机器打断，接着中断这轮对话，进而重新唤醒，会使用户有一种接连被冒犯的感觉，所以时间上线设置要合理（一般10S），最终没能识别或者没能理解，换一种表达方式让用户再说一次。对于一些流程下的问题等到回复，不一定要10S，具体问题具体设置
由于对方是机器，所以用户对他的容错度要相对高一些，无论是主动还是被动重复，在一定范围内可以被接受，一方面可以通过多种回复方式，缓解尴尬，另一方面换一种问法，让用户更容易表达，也让机器更容易掌控，在或者对一句话理解的程度，可以设定阈值，可确定在理解一部分内容后能推测用户的意图，可询问是否要进行相应操作，这样让用户知道自己的哪里表达机器没有明白，“放一首华晨宇的歌”“聪明的我竟然没能明白，您要听谁的歌？”
英特尔语音助手部经理：你偶尔因为犯错和不知道某些事情导致评分降低造成的影响，比你每次做对一件事情重要百倍。
未检测到语音时，有两种方式可处理，明确说出来“对不起，没有听清楚，您的账号是什么？”
或者什么也不做
对于第一种，一般应用在：系统只使用语音，因为用户只能通过语音知道自己的表达是否被机器识别，如果有界面（文字，虚拟人物）可以辅助表达；用户没有其他的回复方式，比如可以用键盘，图像帮助表达，所以语音识别与否被凸显得很重要；必须要用户回复后，系统才能继续任务/对话，比如购物的支付口令，如果用户不表达清楚，就不能完成购买流程
对于第二种，一般应用在：用户可以通过其他方式进行回复；就算什么也不做，也不会中断对话，比如正在播放音乐，我唤醒中断了他，即使用户说的机器没有识别，也可继续放歌；当有一个视觉提示告诉用户系统没有理解。
无论对于自然语言理解，交互设计还是语音合成，掌握人们日常对话习惯是这些技术研发的重要指引，在不同场景下机器该说什么，怎么说，甚至是不说，都需要对用户的表达习惯深入掌握
检测到语音但没有识别时，回答方式与为检测到语音相同，但是要让用户知道你已经听到他说话了，但是没听懂说的什么意思“对不起，我没明白我听到的问题”
语音被正确识别，但是系统无法处理，这种可能是一词多义，机器误解了用户要表达的意思“你这次干得漂亮”“我可是倾国倾城的呢”；还有是用户说话或者系统恢复设置不全面，这样系统找不到对应的答案“你感觉怎么样”“我手臂受伤了”“对不起，我没听到，你说你感觉怎么样？”这种就是用户的回复超出了系统的预设。对这种未知情况回复可能性比较大的对话，可对用户的语句进行正负面判断（好事，坏事，积极，消极，也可对程度判断），然后做相应的反馈，比如识别到了受伤，判定为坏事，应该是负面情绪“听起来有些难过”，也可针对句子中的动词进行进一步提问“是怎么受伤的呢”“我丢了钱包”“是怎么丢的呢”但是限于负面情绪，对于积极情绪，识别后表示祝贺就好“真替你感到开心”，如果用户有分享的欲望，要结合上下文，不要中途判断，因为高兴的事中可能夹杂负面经历，悲伤的事中也可能夹杂积极词语，对于中性情绪，可以询问“开心么”，“我今天搬家了”“你感觉开心么”“今天上午有一个女生和我表白了”“你感觉开心么”，不过为避免过于超出能解决的范畴，尽量给用户选项，或者在自己系统比较完善的领域靠
部分语音识别错误，导致要么机器不做任何事情，因为不是想要的结果，要么匹配上错误的行为。对于识别错误，我们在交互上做不了什么，只是要么尽量减少发生的可能性，比如结合上下文增加识别结果的准确率，要么用界面的方式帮助用户知道自己的表达识别错误，而且也可以通过使用N-BEST列表和真实用户响应的数据分析，构建解决办法
增加错误提示，意思是当存歧义，或者用户的回答系统没有对应准备时，可使用增强策略，“帮我查一下延大的历史”“请问是延边大学还是延安大学呢”，“帮我查一下快递”“255654254222”“快递单号应该是20位，请再检查一下”
可以为异常的次数设定一个阈值，当超过一定阈值时，转为人工处理
2.9不要责怪用户
用户在使用机器时就像一个孩子在课堂上接受知识，给予正面情绪的指引和鼓励，会让他们更乐意尝试，接受犯错，并在以后的操作中表现更好，如果对用户的操作错误进行职责，会对产品的评分大打折扣
2.10新手和专家用户
对于第一次，和多次使用的用户的解决问题的方式是不同的，通过长时间对用户兴趣点，关注点的学习以及使用频率的统计，会在后期的表达中只输出关键和必要信息“我想买一袋洗衣粉”“为您推荐XXX，销量XXX，价格XXX，要为您买一份么”“有XXX牌子的么”“为您推荐XXX... ...”，经过几次购买“买袋洗衣粉”“还是XXX牌子的么，销量XXX，价格XXX”“是”
或者“已下单成功，请跟着我说接下来的口令，我们会为您声纹识别，26423”“26423”，多次之后，“已下单成功，口令51326”“51326”
当然对于用户的使用频率要注意虽然次数较多，但是可能很久才用一次，容易将操作流程忘记，所以还是要将流程叙述一遍，所以综合考虑：次数少，频率多，也可用专家，次数多，频率少，也可用新手
在对话时，要记得使用对话式标识，让用户知道自己的话被机器接收到
谷歌的交互设计师说“你的目标不是简单的训练你的用户，应当适应用户的行为，而不是用已有的命令让用户感觉厌烦，要在不知不觉中，对用户的行为进行诱导，又不会感觉不舒服，“启动效应”就是一个很好的方式，它是指某人受到某种特定的刺激后，会影响他们后来在接受同样刺激的反应。比如“我想听华晨宇的微光”“播放华晨宇的微光”，在几次操作之后，用户自然就说“华晨宇的微光”，除此之外，也可以用来给用户一定程度的心理暗示，让他们对接下来的事有心理准备，且对结果更容易接受，比如“我有三个问题要问你，这对后来提供服务很重要”，用户就知道会有几个问题，而不是回答了两个之后就感觉厌烦，不知道还要问多少个
2.11 持续跟踪上下文
要知道两个词语指的是同一个东西，“最火的男明星是谁”“XXX”“他有什么作品”要知道他是指这个男明星，界面也是如此，在搜索一些结果后，对这些结果进行进一步搜索，要知道“哪些”“他们”都是指上一轮的结果。将用户询问的结果储存下来，以备后续询问，简单的方法是储存最近一次的结果，“很火的男明星都有谁”“XXX,XXX,XX”“他是单身么”，就不能选最近的结果，如果用界面的话，可以查到性别，更精确的表达“他”“她”，当然也可用“他们”
指代要正确，比如“哪个城市适合看花”“苏州的拙政园，杭州的西湖，武汉的武汉大学都是看花的好地方”用户说“哪个离我更近一些呢”“相比之下，哪个最好看呢”中的哪个指代是不同的
要避免回复内容中的非礼貌用语，确保你服务的用户群体都可以接受你的表达方式，起码不可以反感，加上意见反馈通道也是必要的
2.12帮助和其他通用部分
无论VUI的功能是做什么，载体是什么，都要有一组通用组件，以确保一些可能发生的超出功能之外的细节可以得到解决：重复，主菜单，帮助，操作，再见。
在一些各种规划好的场景中可能存在的使用问题，理解问题，技术问题，产品本身问题，会影响用户使用产品的流畅性，而这些也是容易在对话设计中容易被忽视的地方，过于专注自己要解决的问题，所以帮助功能的存在就很有必要，这需要对场景思考的更为全面，“帮我查一下航班信息”“请说一下您的航班号”可是用户不知道什么是航班号“帮助”“航班号在机票的XXX，XX打头的就是”帮助任务顺利完成，无论是帮助还是其他通用功能，都要将场景中可能发生需求，指令，异常情况考虑在内，设计好
而对于开放式场景下寻求帮助，一般为用户不知道可以用机器完成什么任务，所以对于纯语音就可以将功能归类，概要阐述，如果是界面，就可以讲这些功能显示出来，或者直接给用户一些操作的例子（但是语音不要说：你可以试着对我说... ...），这种类型的帮助也有助于用户减少迷茫感，一个恰当的帮助按钮，或者语音询问，可以让用户的体验在一瞬间提升。
虽然机器会说“我有什么可以帮你呢”但是能做的事情还是有限的，所以让用户知道机器能做什么事情很重要，如果一再的提出超出能力之外的请求，会降低体验效果，要让用户在没有准备的情况下有惊喜感，而不是在准备了很多尝试后的失望感。
退出机制不应该被忽视，就想人们在通过电话交流一样，你会突然挂断电话，那样会很不舒服，所以人们在使用IVR时依然习惯于说再见，如果不说，甚至会不舒服，还有就是在要退出时，确保用户是否真的要结束现在的对话，可以用三级置信度来确认，如果是中级“我想我听见您说了再见，要退出么”高级“Alexa，晚安”“晚安”，低级“我没能听清... ...”
不同的场景在使用同一语句时，表达的含义是不同的，所以要确认上面的表达是在做什么，情绪如何（分类）
2.13 延迟
延迟发生的可能原因：连接性能不好，系统处理慢，数据库访问速度慢
除了在技术上的提升外，加之适当的交互也可以解决这一问题，要先知道在处理这个问题需要多长时间的延迟，然后给予一些等待提示，时间较长，可用语言“请稍等，正在查找”，时间较短，可用提示音或者视觉效果，要注意的是，如果没有延迟时，也最好插入几秒，因为用户已经习惯于这种解决问题的进程，这种感觉，就不要破坏它（如果是开放式交流就尽量不用延迟，会影响流畅性，当开放式和封闭式的转换，要让用户知道处理方式上的差别）
2.14消除歧义
地点，人名，饭店，日期等等都有可能存在歧义，需要系统为用户提供最有可能是用户需要的结果，可以也用置信度来衡量，“今天天气怎么样”可以通过定位用户所在的城市，知道是在问该地的天气，也可通过上下文搜索的方式，知道用户的诉求的主语是什么，“北京现在热么”“有什么美食”，虽然没有指代，但是通过上下文也知道是在问北京的美食有什么。
可以看出置信度有消除歧义，退出，上下文指代，用户回复内容的关系几个方面的应用，总的来说就是确认策略。
说到确认策略，也可用隐性确认的方式消除歧义，“给XXX打电话”，“好的，为您拨通XXX的手机号”，用隐性确认的方式消除对人名的歧义（但是要确保XXX的置信度很高，或者只有一个XXX，要不然影响服务进度和质量，其他的也如此）
再有就是显性确认，直接询问用户要的是哪一个“我不舒服”“您怎么了”“我发烧了，感觉恶心”，“哪一个是您的主要症状呢”“是发烧吧”“好的，发烧... ...”
对于用户提出的两种答案，为避免对话的复杂，可以通过判断答案之间的关系，减少用户对话的次数，比如是否有因果关系，包含关系，并列关系等，就想发烧和恶心，他们是因果关系，所以解决“因”，“大范围的”“其中一个”就可以将问题解决，当然也要通过置信度，比如“我感觉头疼，恶心”，就要消除歧义（系统有局限），或者分开回答，或者由现象推断原因，进行询问“您是感冒了么”（要让答案可控，或者借助界面）
对用户各种可能的回答也要有良好的适应性，用户可能用不同的方式表达同一个主语，XXX的XXX，XXX,或者只是说了指代词，都要做好准备。
2.15 设计文档
提示列表指的是系统对用户说的话，预先写好提示列表有几个用途：
可以为配音演员提供需要录制的文案列表，可以从用户那里得到确认，可以为TTS引擎提供确认
由于一句话的表达方式很多，可能会加入“没错”“嗯啊”“是的”“对”还有语气词“嗯”“呃”还有寒暄“谢谢”“请”等等，很难考虑全面，不过现在许多系统都支持通过指定关键短语而不是确切的句子，或者使用机器学习来映射用户的意图
2.16 无障碍设计
交互应该是省时，高效的，对于任务型系统，对话的次数越少自然越好，在用户发出请求时，无论是用精准的意图分类器将用户的需求快速推断出来，还是用话术让人们一次性将该说的信息说全，或者将需要的商品或服务说全，都是为了用最少的对话轮数解决问题，现在的系统会将用户在展开对话后，定位到某一个领域，然后用填槽的模式达到能够为用户解决问题的程度，“请问你的送货地址是哪里”“朝阳区南湖公园”“哪个城市”“长春市”“具体位置”“吉林大学南湖校区”“邮编”“XXXXXX”，机器不断让用户去填槽，用户会感觉很麻烦，如果直接说“请说出您的详细送货地址，比如：北京市苏州街XXX号”，如果用户还能没能表达完整，也可自动匹配上相关信息，比如邮编，不用过于流程化的逐一询问
信息的输出一定是要简短的，这也是语音能否高效服务的关键，无论用户的诉求是什么，给出能满足需求的最关键信息，并准备好用户可能提问的相关信息，比如“我想买一件衣服”“为您推荐XXX，月销量XXX，价格XXX，是否需要购买”同时要准备好用户可能询问的衣服尺码，颜色选择，用户评论甚至发货城市等等
语速要快一些，这样对于输出长篇幅的信息来说（新闻，评书，小说，搜索），更高效的完成这件事，而且越来越多的用户正逐渐习惯比正常语速更快的速度。所以为用户提供控制语速的功能是有必要的
对于难免会输出或者场景本身就是长篇幅输出的，要允许用户随时打断，因为语音本身就是单通道接受和输出信息的过程，让用户在整个过程保持时刻的可控制性是在设计时一定要考虑在内的，当然尽量先输出最关键信息，再配备好相关信息是比较实用的
对于有界面来说，用户很容易知道对话进行到哪一步了，之前说了什么，还有什么要问的，如果搞不清楚了，系统也可以通过页面提示，但是对于纯语音来说，语音的短时性，很容易不知道该如何进行下去“我想买一件衣服”“为您推荐XXX，月销量XXX，价格XXX，是否需要购买”，用户如果不想买，但是又不知道如果一直这样盲目推荐要进行多少次才能说到自己想要买的，同时又不知道该如何表达自己想买的衣服究竟是什么样子的，就会陷入不知所措，所以要设计应对措施
对于上个情况，给与用户随时询问“我在我该说什么哪”的帮助是有必要的，帮助他们重新定位所处位置，在不知所措时，用户会说“帮助”“进行到哪一步了”“我很困惑”或者直接沉默，这就需要在判断出用户这次使用系统的意图后，通过对过去用户行为的数据分析，推断接下来他们的倾向对象会是什么，比如在了解或察觉到用户迷惑时，“您是要买什么衣服呢，长袖？裤子？还是外套？”“看看长袖吧”“为您推荐XXX，月销量XXX，价格XXX，是否需要购买”（其实对于外形和质量会影响选择结果的商品，是不太适合用纯语音的方式购买的，除非有一直在用的牌子，或者只要便宜，其他都无所谓），当然如果用户说“随便”，也不能继续推荐，让用户继续迷惑，可以通过商家活动，或商品的卖点给用户一个选择理由
在语音输出时，
网友评论