消息
1.开放平台概述
基于开放平台，您可以给DingDong音箱接入第三方应用。
DingDong开放平台，基于HTTPS协议，通过云端交互，与开发者的应用服务进行通信，从而赋予音箱新的能力。本文详细介绍开发者如何基于DingDong音箱，设计和实现第三方应用，从而让用户可以体验和使用到这个新功能。
2.成为开发者
DingDong音箱开放平台的开发者在提供应用之前需要在平台完成开发者身份的注册及审核。开发者类型分为两种：个人开发者、企业开发者。
2.1个人开发者
个人开发者需要对用户的身份信息进行验证，验证的信息主要为用户个人的身份证或护照信息等。
2.2企业开发
企业开发者需要对企业的营业执照进行验证，验证的主要信息为营业执照编号。
3.开发应用
在开放平台完成对开发者身份审核通过后，开发者就可以设计与实现自已的应用了。
3.1语音交互流程简介
DingDong音箱开放平台由用户、DingDong音箱、DingDong音箱APP、开放平台、应用五大部分组成，解决方案的概要视图如下。
从上图中可以看到，用户与应用之间的交互，主要是采用语音方式来完成的。
一次完整的交互流程，示例如下：
用户：“叮咚叮咚，让滴滴帮我叫一辆从朝林广场到北京南站的出租车”
当用户对启用了“滴滴出行”应用的音箱说出该话后，音箱被唤醒，后续动作如下：
1.用户的语音，通过音箱传输到云中的DingDong开放平台。
2.DingDong开放平台，识别出这个请求为“滴滴出行”应用中的“叫车”意图。
3.DingDong开放平台，将这个请求，形成结构化的信息，提交到 “滴滴出行”应用的云端服务上。
4.“滴滴出行”应用的云端服务获取到该请求后，采取适当的行动（从滴滴业务系统中找出合适的司机、预计到达乘客位置的时间、提交出行订单等）。
5.“滴滴出行”应用的云端服务，将业务处理结果的文字信息，包装成结构化的回复，提交给DingDong开放平台，DingDong开放平台将回复转发给音箱。
6.音箱将收到的文字内容，通过TTS播报的方式，向用户播放：
“好的，已帮您叫到王师傅的车，预计在3分钟后抵达朝林广场，请您做好上车的准备......”
应用的反馈，除了可以通过音箱自身的播放简洁明了的语音外，还可以向用户手机上的音箱app推送 “信息卡片”作为补充。“信息卡片”将使用文字、图片等方式，对应用的反馈进行更加全面的描述，这对用户交互体验的提升，作用明显。比如：
① 简单文本：链接内显示纯文本，应用需要指定标题和内容。
② 标准文本：链接内显示纯文本和图像，应用需要指定标题和内容。
信息卡片的相关内容，具体可参见通信协议中Card段。
3.2语音交互流程设计
3.2.1交互流程的核心——意图
所谓意图，表示用户在使用应用时所做的动作(譬如：问一个问题或发送一条指令)，这些意图代表了应用的核心功能。
如果应用成功地识别了用户意图，则需要在完成业务动作后，将结果反馈给用户；如果应用无法识别用户意图，则需要给用户友好的提示，指导用户使用。
3.2.2应用如何识别意图——语义文法
开发者通过在DingDong开放平台网站中，设置针对于这个应用的“语义文法”，当用户的语音提交到DingDong开放平台，DingDong开放平台首先进行文字转写，随后在基于这个应用的“语义文法”，实现对用户意图的识别。
“语义文法”类似于正则表达式，它定义了一组包含指定的单词或短语的语法结构，用户通过说出满足这种结构的语句，来调用意图。所以，应用开发者需要将这些语法结构，映射到不同的意图上。这个映射构成了应用与用户之间的互动模式。
3.2.3应用如何处理意图——云端交互
应用云服务：调用意图的结构化请求，会提交到该服务，该服务进行相应的应用逻辑处理后做出响应。 此服务必须通过Internet访问。开发者在DingDong开放平台配置应用的时候，需要提供服务的调用地址,保证音箱可以将用户的应用请求，通过DingDong开放平台路由到应用云服务。开发者在DingDong开放平台网站中，进行配置。
3.2.4平台原生支持的意图识别
DingDong开放平台内原生支持了一些意图，对于这些意图的识别，开发者可以不用为其编写文法。平台内置意图列表如下：
| Cancel | 取消、不想要了 |
| Help | 帮助 |
| Yes | 确认 |
| End | 结束、退出 |
比如，如果某应用的开发者选择了使用内置的“帮助”意图，当用户使用音箱，进入到该应用的交互流程中时，可以对音箱说“帮助”，“怎么用啊”等语句，平台会将其自动识别成“帮助”的语义，提交给应用的云端服务。应用的云端服务可以根据应用的实际情况，给出合适的答复。
为了用户使用体验一致，符合用户对帮助的期待，强烈建议开发者不要给出不符合帮助语义的答复。
开发者也可以不选择这些内置的意图识别包，而由自己来写这些意图的识别文法。我们不推荐这种做法，因为通常情况下，系统内置的意图识别包，会比开发者自己编写的意图文法，语义覆盖度更好。
3.2.5用户如何进入到第三方应用
用户在使用音箱的过程中，如果想开始使用某第三方应用，则需要在对音箱说的语句中，包含“应用调用名称 ”，如上文示例中的“滴滴”。
语音标准示例如图所示：
用户可以通过以下三种方式来进入到某个第三方应用：完整意图、部分意向、没有意图。
1.完整的意图
用户在一句话内，描述完整自己的意图。比如：
叮咚叮咚，让滴滴帮我叫一辆从朝林广场到北京南站的出租车
这种类型的语音交互是最常见的一种，因为用户通常希望他们的需求以尽可能少的步骤被满足，他们将很快学会通过这样的方式来表达“意图”。当用户在第一次交互中就给出了他的完整意图时，第三方应用应该给出简洁完备的答复。比如：
好的，已帮您叫到王师傅的车，预计在3分钟后抵达朝林广场，请您做好上车的准备。
应用的开发者，在配置该应用的对话示例时（该示例会显示在叮咚app界面上，用户在启用该应用时将会看到），应该尽量只列出这些包含完整意图的示例说法。这样，当用户启用这个应用时，将看到最有效的交互方式。我们建议提供的示例中，能够覆盖到该应用提供的所有功能。
2.部分意图
用户所说的内容是不可预测的，所以，开发者也需要考虑用户只表达出他们意图的一部分的情况，比如：
叮咚叮咚，让滴滴帮我叫一辆车。
如果发生这种情况，应用应该确定，用户所说的内容中，遗失了什么关键的信息点，并提示用户补全它，比如：
您好，您想从哪个地方去哪个地方？
3.没有意图
当用户使用应用的时候，他们也许对应用了解很少，可能只是通过简单的询问或者不知道如何进一步的使用它。这时，应用需要告诉用户该应用的使用指南。比如：
叮咚叮咚，能滴滴打车吗？
此时，就需要指导新手用户，与用户进行互动是关键。我们建议提供一个菜单式的待选列表，帮助用户开始。这些菜单建议不超过三个选项。因为当超过三个选项时，用户将显得无所适从，甚至停止使用该应用。
3.3 语义文法的编写
3.3.1 Abnf语法
Abnf语法请参考《ABNF文法规范_open1.0》
3.3.2文法词典
文法词典是指DingDong开放平台为开发者预置的一部分数据(在文法编辑界面可以查看到)，如：省市区、前缀词等，开发者可以在需要使用的时候直接引入平台预置的词典。如：
1.省市区词典展示
| 调用名 | 描述 | 词条数 | 词条示例 |
| province.lst | 中国全部省级及直辖市 | 34 | 北京、上海、天津、重庆、黑龙江、吉林… |
| city.lst | 中国全部市级 | 387 | 北京、上海、天津、重庆、哈尔滨、齐齐哈尔… |
| county.lst | 中国全部市区 | 3210 | 北京、海淀、朝阳、顺义、怀柔、通州、昌平… |
2.前缀词词典展示
| 调用名 | 描述 | 词条数 |
| pre_word.lst | 调起应用前的动作指令词 | 20 |
| 要求 | 使用 | 打开 | 开始 | 运行 |
| 调用 | 启动 | 告诉 | 让 | 命令 |
| 跟 | 用 | 查查 | 问一下 | 问下 |
| 看看 | 预约 | 开通 | 开启 | 请 |
3.3.3文法示例
#ABNF 1.0 UTF-8;
business didi;
//引入词典
#include " pre_word.lst";
#include "city.lst";
#include "province.lst";
root main;
#ABNF HEAD-END;
//词典引用
$pre_word = ($u_LST_pre_word);
$city{city} = ($u_LST_city);
$province{province} = ($u_LST_province);
//用户常用词汇的变量定义
$find = 找|搜|查|查找|查查|查询|叫|看|让;
$yixia = 一下|下|辆|一辆;
$car = 车|出租车|快车|专车;
$to = 到|去|向|往;
$from = 从;
$call_name_must = 嘀嘀|滴滴|弟弟|迪迪|底底|jj;
$call_name_choice = 打车|出行;
//叫车：
$I_want_find = [[$I] $want | $help [$I]] $find [$yixia];
//地点名称通配
$placeName = $_ti_ch_<2-10>;
$nearby = (附近|周围|周边)[的];
//$didiTaxi_1：叫车到某地：让“(嘀嘀|滴滴)打车|出行”帮我叫一辆到北京南站的出租车
$didiTaxi_1_0 = ($call_name_must)[$call_name_choice] [$help] [$I] $find [$yixia] $to $placeName{to} [的] $car;
$didiTaxi_1_1 = ($call_name_must)[$call_name_choice] [$help] [$I] $find [$yixia] $car $to $placeName{to} [的];
$didiTaxi_1{type%taxi_to_a} = $didiTaxi_1_0 | $didiTaxi_1_1;
//$didiTaxi_2：叫车，从A地到B地：让“(嘀嘀|滴滴)打车|出行”帮我叫一辆从朝林广场到北京南站的出租车
$didiTaxi_2_0 = ($call_name_must)[$call_name_choice] [$help] [$I] $find [$yixia] [$from] $placeName{from} $to $placeName{to} [的] $car;
$didiTaxi_2_1 = ($call_name_must)[$call_name_choice] [$help] [$I] $find [$yixia] $car [$from] $placeName{param} $to $placeName{to} [的];
$didiTaxi_2{type%taxi_a_to_b} = $didiTaxi_2_0 | $didiTaxi_2_1;
//$didiTaxi_3：叫车，让“(嘀嘀|滴滴)打车|出行”帮我叫一辆出租车
$didiTaxi_3{type%taxi} = ($call_name_must)[$call_name_choice] [$help] [$I] $find [$yixia] $car;
//定义叫车意图的说法，已经定义的有三种，分别为：$didiTaxi_1、|$didiTaxi_2、$didiTaxi_3
$main{biz:didi}=$_ti_ch_<3->[$I_want_find]($didiTaxi_1|$didiTaxi_2|$didiTaxi_3)$_ti_ch_<3->;
3.3.4 文法编译
开发者在文法编辑完成后，需要对编写的文法进行编译，来判断文法的编写有没有错误。
1.点击编译按钮：
2.编译进行时会提示：
等待编译完成。
3.编译成功的的同时表示该文法已发布上线，可在手机端开启应用，用音箱进行联机调试。
3.3.5 意图测试（文法验证）
1.点击页面上的测试按钮，弹出测试窗口：
2.输入要验证的内容：
3.点击测试按钮：
4.如果说法不支持，会提示如下信息，开发者可以依据需求进行文法的优化：
3.3.6 提交语音调试
开发者在文法编辑、编译、测试完成后，需要加入开发者群，找到技术支持人员申请开通语音调试。开发者群请查看6.5联系我们。
3.4云端交互的实现
3.4.1通信协议
1.DingDong音箱开放平台基于HTTPS协议与开发者服务进行通信。
2.DingDong音箱开放平台通过POST方式发送JSON格式数据包到开发者服务，开发者服务应答包也同样返回为JSON格式。
3.DingDong音箱开放平台与开发者服务间的调用超时或异常的重试次数由开发者在创建应用时指定，如未指定则平台将不会进行重试。
3.4.2 消息包头
HTTP消息头除定义以下字段的取值，其他字段使用标准协议。
| 参数名 | 参数值 |
| Content-Type | application/json;charset=UTF-8 |
| Accept | application/json |
| Accept-Charset | UTF-8 |
| timestamp | 接口请求的时间戳（单位：毫秒） |
| sign | 签名信息，用于提供方进行重放验证（如技能方不需要验证，可忽略），计算方式： sign=MD5(applicationid+body+timestamp)其中： 1、 applicationid：技能ID 2、 body：请求包体 3、 timestamp：接口请求的时间戳 注：以上三个字符串拼接后的MD5小写值 |
3.4.3 消息包体
3.4.3.1 请求包体
| 参数名 | 字段类型 | 说明 | 必填 |
| versionid | String | 版本号，格式:X.X, 目前默认为：1.0 | 是 |
| status | String | 状态，LAUNCH、INTENT、END、NOTICE,详细描述见6.2 | 是 |
| sequence | String | 交互流水号，唯一标识一次平台对开发者服务的调用 | 是 |
| timestamp | Long | 平台发送请求到开发者服务的的时间，格式为：当前时间的毫秒值 | 是 |
| application _info | Application Info | 本次用户输入的内容被理解为某个应用时的应用信息，用于一个开发者多个应用服务地址只有一个的时候的应用区分 | 是 |
| session | Session | 会话相关的数据，包含：本次会话的ID、用户历史输入内容、会话中保持的槽值等 | 是 |
| user | User | 用户相关的数据，包含：用户的ID、用户正对当前应用的一个基础设置 | 否 |
| input_text | String | 用户本次内容 | 否 |
| slots | Map<String,String> | 个性化语义识别出来的用户当前输入对应的语义结果（槽值），当status为INTENT时不为空 注：槽值的key以及取值，与开发者当前的应用文法是一一对应的 |
是 |
| ended_reason | String | 会话结束原因，详见附录6.1，当status为END时不为空，其它情况为空。 | 是 |
| notice_type | String | 通知类型，用于开发者详见附录6.3，当status为NOTICE时不为空，其它情况为空。 | 是 |
示例报文如下：
{
"versionid": "1.0",
"status": "INTENT",
"sequence": "f10ee90bcff644cdab1ed2a18c4ddd63",
"timestamp": 1873609207048,
"application_info": {
"application_id": "ia3a449b",
"application_name": "小智"
},
"session": {
"is_new": true,
"session_id": "be44d9f4f13a4e789c2d1b5f3d897e84",
"attributes": {
"focus":"open_xiaozhi",
"bizname": "小智",
"type": "order"
}
},
"user": {
"user_id": "9181c619bbe34e9e935248a70a199e37",
"attributes": {}
},
"input_text": "让小智关闭客厅灯。",
"slots": {
"focus":"open_xiaozhi",
"bizname": "小智",
"type": "order"
},
"extend": {}
}
3.4.3.2 应答包体
| 参数名 | 字段类型 | 说明 | 必填 |
| versionid | String | 版本号，回传平台端调用时传递的版本号, 目前默认为：1.0 | 是 |
| is_end | Boolean | 由开发者服务决定本次会话是否结束，如果标识为结束(true)平台会清除本次会话在平台保持的会话数据，如果标识为不结束（false）平台继续为用户保持当前会话数据。 | 是 |
| sequence | String | 交互流水号，回传平台调用时传递的值 | 是 |
| timestamp | Long | 开发者服务应答平台的请求的时间，格式为：当前时间的毫秒值 | 是 |
| need_slot | String | 需要的槽值：如不为空，开放平台会主动为开发者收集此槽值服务，如用户输入的说法不符合槽值提取规则，则视为未识别重复收集。如为空则表明不需要平台关注槽值的识别，全部透传到第三方应用进行判断 | 否 |
| directive | Directive | 开发者需要音箱设备播报的内容，其中可以包含文本播报和流媒体播报。 | 是 |
| push_to_app | Card | 开发者需要平台推送到音箱设备关联的手机APP展现的内容，其中连接内可包含文本图片 | 否 |
| repeat_directive | Directive | 当音箱未能识别用户说话时，给用户的重新提示语，以引导用户进行后继的对话，其中可以包含文本播报和流媒体播报。如果该字段为空，且音箱发生未识别用户说话时，则音箱会重复播放directive字段的内容 | 否 |
| extend | Map<String,String> | 扩展字段，目前支持的扩展内容是，上一次会话拒识时，要不要让音箱响应用户的下一次拒识的输入， 如果NO_REC（需大写）取值0时，播报响应。取值1时，不播报。默认是0 | 否 |
示例报文如下：
{
"directive": {
"directive_items": [
{"content": "好的，已帮您关闭了客厅灯",
"type": "1"
}
]
},
"extend":{"NO_REC":"0"},
"is_end":true,
"sequence":"f10ee90bcff644cdab1ed2a18c4ddd63",
"timestamp":1483609208020,
"versionid": "1.0"
}
3.4.4 对象定义
3.4.4.1 ApplicationInfo
| 参数名 | 字段类型 | 说明 |
| application _name | string | 开发者在平台创建应用时，填写的应用名称 |
| application _id | string | 开发者在平台创建应用时，平台分配的ID |
| application_version | string | 应用的版本号，保留字段，默认为：“10000” |
3.4.4.2 Session
| 参数名 | 字段类型 | 说明 |
| is_new | Boolean | 是否为新会话：true 是 false 否 |
| session_id | String | 本次交互会话中的会话ID，由平台方负责保持，在一次会话结束前，此ID不会变化 |
| attributes | Map<String,String> | 会话具体参数，依据每个应用的不同，参数也不相同，此字段中主要以之前的槽值为主。 |
3.4.4.3 User
| 参数名 | 字段类型 | 说明 |
| user_id | String | 用户在平台相对于开发者某个应用的ID，注：应用不同，用户的ID也会不同 |
| attributes | Map<String,String> | 用户具体参数，依据每个应用的不同，参数也不相同，此字段中主要以用户针对当前应用的基础配置，如：默认手机号、默认地址等。 |
3.4.4.4 Directive
| 参数名 | 字段类型 | 说明 |
| directive_items | DirectiveItem[] | 开发者需要音箱设备播报的内容 注：音箱会依据开发者给出的顺序播报 |
3.4.4.5 DirectiveItem
| 参数名 | 字段类型 | 说明 |
| type | string | 类型：1.TTS 2.AUDIO |
| content | string | TTS播报内容 AUDIO 的url连接,请使用http的播放地址，音频格式为mp3、ma4 |
3.4.4.6 Card
| 参数名 | 字段类型 | 说明 |
| title | string | 开发者需要平台推送到用户音箱关联的手机APP上展现的标题内容。 注：不能超过20个字 |
| type | string | APP展现内容类型： 1.纯文字 2.图片(暂未开放) 3.外部连接 |
| text | string | type为1时使用 |
| url | string | type为3时使用 |
3.4.4.7 RichContent
| 参数名 | 字段类型 | 说明 |
| type | string | 类型： 1.文字 2.图片 |
| content | string | 类型为1时：文字内容 类型为2时：图片连接，连接长度不可超过512个字符 |
3.5 提交应用信息
在应用开发完成之后，就需要在开放平台网站中提交DingDong音箱的应用配置信息，配置的流程如下：
1.开发者用注册的账号登录开发者页面，点击创建应用。
2.开发者填写应用的基础信息，如：应用名称、应用调用名称、应用介绍、应用图标。
图标规范如下所示：
3.开发者填写应用调用信息，如：应用服务地址，账号的授权方式、SSL证书。
4.开发者填写应用调用需要的用户基础配置信息，如：手机号码、默认地址等。
注：应用调用名称就是用户进入该应用的语音唤醒词，用户可以说“叮咚叮咚+打开（应用调用名）”的方式进入应用，调用名前可加入“打开，让，启动”等前缀词，后面可以加上目的意图，如果应用调用名为“今日头条”，标准的语音指令为“叮咚叮咚，让今日头条播放最近的新闻”，在设计应用调用名称时应注意以下几点：
① 禁止侵犯单位或个人的知识产权，涉黄涉暴。
② 应用调用名称不能是单字，建议在3-6字为宜。
③ 应用调用名称不能与叮咚音箱内置的唤醒词相同，比如，“叮咚”，“百灵”，“小薇”等。
④ 应用调用名称不能与现有的叮咚音箱内置的应用名冲突，比如，“天气”，“笑话”，“相声”，“闹钟”等。
⑤ 应用调用名称不建议为地名或者人名，或者知名的歌手、歌曲、有声资源的名称。
⑥ 应用调用名称必须容易发音，语音区隔度大，避免多音字词等因素的干扰。
4. 测试应用
4.1 文法测试
请参见：3.5文法验证。
4.2 设备调测
完成了应用的语义文法编写、测试、云端交互逻辑开发、部署后，您就可以使用音箱设备来对应用进行语音交互测试了。
测试前的准备工作有：
1、为应用绑定测试音箱。在我的应用->设备调测里，输入需要调测的音箱SN号，同一个应用最多可以绑定5台测试音箱
2、在音箱手机APP中开启应用。在音箱手机APP首页->应用平台->“我的”里，开通需要测试的应用
测试过程中重点测试的内容有：
1、针对已经编写的文法，也就是应用能够处理的用户意图，要全部覆盖到。
2、应用没有处理的用户意图，要有错误或异常处理。
3、应用的回复语如果采用音箱TTS合成播报的，尽量采用平铺直叙的文字，每句都要在音箱上试听下合成的效果（重点关注字、句是否读的准确，合成的语气和重音是否合理）。
5. 发布应用
5.1 提交审核
开发者在完成以上步骤后，就可以把应用提交DingDong开放平台审核了。
5.2 审核处理
审核结果会采用邮件的方式通知给开发者。如审核不通过，开发者根据不通过原因作出调整或提出异议后，可以再次提交审核。
5.3 应用上线
在应用完成审核通过后，开发者可以选择将应用提交上线，上线后，如用户选择了此服务，则用户可以通过平台使用到开发者开发的服务内容。
5.4 应用编辑
在应用上线后，开发者可以根据应用的使用情况对应用作出调整，对应用的编辑可分为两类，一类为文法意图的优化，开发者可自行对文法进行编辑和修改。另一类为应用创建信息的编辑，如：示例语句的修改，图标的替换等，此类信息的修改需要重新提交审核，审核通过后方可修改成功。
5.5 应用下线
应用上线后，开发者可以选择不再提供自己的应用给用户使用，此时开发者可以提出申请下线，下线审核通过后，应用将停止为用户进行服务，同一个应用允许进行3次下线操作，超过后不再提供上线服务。
6. 附录
6.1 会话结束原因
| 编号 | 说明 |
| USER_END | 用户主动结束 |
| SESSION_TIMEOUT | 会话超时平台结束 |
| SESSION_ALLTIMES_OUT | 会话总次数超出平台结束 |
| SESSION_CURTIMES_OUT | 会话当前次数超出平台结束 |
| OPEN_PLATFORM_ERROR | 开放平台处理异常 |
| SERVICE_INVOKER_TIMEOUT | 服务调用超时 |
| SERVICE_INVOKER_ERROR | 服务应答结果异常 |
6.2 交互状态
| 状态 | 说明 |
| LAUNCH | 用户只输入了应用名称无具体意图时的状态,可以理解为当前应用的会话启动 |
| INTENT | 用户输入的内容具有某个应用的具体意图时的状态，会话开始时可以理解为带有意图的启动，在会话中是可以理解为正在交互的内容。 |
| NOTICE | 在与用户交互的过程中，用户的输入不能识别出具体的意图时，音箱会开启重复询问，在询问的过程中也会异步地将用户的输入发送给开发者应用。注：这种状态下的报文，不是用来交互的，而且是异步延迟发送的，目的只是把数据日志给到应用，供应用端进行用户话术的分析，改进VUI的交互设计。 |
| END | 用户退出应用，或会话总次数超出平台次数限制。 |
6.3 通知类型
| 状态 | 说明 |
| USER_INTPUT_NOREC | 用户输入的内容语义结果为拒识情况 |
| USER_NOREC_TIMES_OUT | 用户拒识次数超出最大值，默认最大值为2次 |
| DEV_RESP_PACK_TOO_LONG | 开发者服务回包数据过长，长度最大为2Kb |
| DEV_SERVICE_VISIT_TIME_OUT | 开发者服务访问超时，默认超时时间为5秒 |
| DEV_SERVICE_RESP_PACK_ERROR | 开发者服务回包数据错误 |
| OPEN_PLATFORM_ERROR | 开放平台系统异常 |
6.4 语音用户界面设计最佳实践
设计一个有效的语音交互流程会给用户带来很好的用户体验。开放平台已经内置了一些基础应用，譬如：搜索歌曲、查询天气、设置闹钟、翻译、计算、新闻、星座、百科、PM值、假期、电影等。我们通过对语音上每天近亿次的用户使用习惯的数据分析，总结并提炼出，在语音交互设计过程中，一些设计原则和常见的最佳实践。当开发者应用还未上线，还没有收集到用户使用习惯的数据之前，这些设计原则和最佳实践可供开发者设计应用时参考。
6.4.1 语音交互设计的原则
设计的核心原则就是要始终以用户为中心的角度去考虑，把用户与音箱的每一次对话状态设计的简单、明了。需要遵循以下四个方面的原则。
6.4.2 让用户在会话中保持低认知负载
VUI不同于GUI，声音对于用户来说是短暂记忆的，在同一时刻，用户很难记住太多的新信息，应用需要尽量减少提示语长度及新知识，建议每次给用户的新知识不要多，并且要在上下文相关的语境中进行。
6.4.2.1 一次只获取一个关键信息
如果应用完成一个用户意图需要收集用户的多个信息时，尽量采用一步步的多次交互来完成，这样不仅能降低用户的认知负载，也能够提高语义文法的精准度。譬如：
用户：“叮咚叮咚，让中通快递帮忙发个包裹”
较好的回答：“欢迎您使用中通快递，请您说出发件人的电话”
不好的回答：“您好，请您说出发件人的姓名、联系电话、地址”
6.4.2.2 让用户知道他所在流程的哪个位置
在只有语音的交互过程中，用户没有像视觉那样容易定位自己。所以需要告诉用户他所在流程的哪个位置，让用户知道自已在哪里，从而减低用户认知负载，提升系统易用性。譬如：
用户：“叮咚叮咚，请星座大师告诉我处女座今天的运势”
较好的回答：“处女座今天的运势是：今天易出行，易交朋友......”
不好的回答：“今天易出行，易交朋友......”
6.4.2.3 对用户的说法要尽可能地广泛支持
需要考虑中文里的多音字、近义字词，以及各个地市的说法习惯，并通过后台的用户数据，持续进行迭代优化。譬如：
用户：“叮咚叮咚，让小智帮我把客厅灯关闭”
在“帮”这个语义上，就需要支持“帮我|绑我|给我|尽快”等说法。
在 “关闭”这个语义上，就需要支持“关闭|关掉|关了|拉上|闭合|退出”等说法。
6.4.2.4 保持全局性和一致性
全局性主要指，所有状态的主提示语、所有状态的错误恢复提示音、所有状态的帮助提示音、所有状态的指南和适时的提示音、所有的警告提示音等。
一致性主要指，在设计对话时，关注于用户以类似的方式做类似的事情，使用统一的策略，如拒绝、超时、无意图等情况下的处理。
6.4.2.5 给对话设计一个形象
大多数时，软件糟糕的体验都源于人类将机器看作机器，试图让人去理解机器，这种方式对于专家也许行的通，而在人工智能时代，人与机器的对话发展趋势越来越接近人与人之间的对话方式，所以在对话的最开始，就要瞄准创造最理想的形象来代表应用的品牌。譬如：
用户：“叮咚叮咚，让滴滴帮我叫一辆车？”
应用：“没问题，预计什么时间出发？”
用户：“现在”
应用：“谢谢，请问从哪里出发？”
用户：“朝林广场”
应用：“好的，需要到哪里去？”
用户：“北京站”
应用：“搞定，已帮您叫到王师傅的车，预计在3分钟后抵达朝林广场，请您做好上车的准备。”
6.4.3 让用户更高效地实现自已的意图
大多数用户需要速度和效率，应该使用户能够通过最少的步骤达到目标，并缩短用户必须要听的提示语的长度。而高的效率往往会以牺牲清晰度为代价，需要确保用户和系统的交流在任何时候都要清晰，必要时可以采取较长的提示语或者额外的步骤去避免可能产生的曲解和不清晰。
6.4.3.1 不要假设用户知道该怎么做
当用户第一次使用应用时，用户很可能不知道自已该怎么说，或者不清楚应用能提供哪些能力和服务，所以用户只能泛泛地问问。当发生这种情况时，应用需要根据自身提供的服务能力及用户的行为习惯，给用户一些交互的问题。譬如：
用户：“叮咚叮咚，能用中通快递吗？”
较好的回答：“您好，您说出寄件人的姓名”
不好的回答：“您好，可以的”
6.4.3.2 给出适用于“听”的信息，而不是适用于“看”的
在只有语音的交互过程中，用户没有像视觉那样快速丰富的去获取到信息。所以给用户口语对话是较好的，尽可能地不使用行业术语或行话。此外，还有一些专业性的符号，也要尽量避免。同时，设计好回复语后，一定要用音箱实际测试下，确保TTS合成正确，用户听起来效果不错。譬如：
用户：“叮咚叮咚，请世界杯应用告诉我最近的比赛结果”
较好的回答：“最近的比赛是巴西对德国，3比2，巴西胜出”
错误的回答：“巴西VS德国, 3:2”
6.4.3.3 基于用户分类的个性化引导
随着用户使用应用次数的增多，用户对应用的交互流程也越来越熟悉，为进一步促进用户体验的提高，可以按照用户对应用的认知程度和使用习惯，将用户分成多种类型，采取差异化的交互引导。譬如，按使用频率，可以将用户分为：“新用户”、“次新用户（使用过3到5次的）”、“活跃用户”等。
1、对于“新用户”，要鼓励他们勇敢地说出来，更多地是要举例子，让用户勇于尝试，不能在一次提示语中就给他提供很多的新知识，否则就会大大加重其认知负担，使其不知所措；需要在提示语中着重引导他们如何进行一步一步的操作。
2、当其中有些用户熟悉了如何通过说话找到自己想要的问题答案后，应用就可以再为他提供新知识，在提示语中提供更多的功能和选择，这样，这些用户就逐步熟悉了整个的应用的完整流程和使用方法，从而成为“活跃用户。
6.4.3.4 采用AIUI多轮对话，避免片段语句引起的会话中断
AIUI多轮对话是叮咚开放平台的一个重要特性，应用在设计时可以采用这个特性来高效地完成用户的意图，同时也可以避免片段语句引起的会话中断，给用户造成不好的体验。譬如：
用户：“叮咚叮咚，让天气通查一下今天天气怎么样？”
天气通：“今天北京天气，晴天，微风，最低温10度，最高22摄氏度。
用户：“对了，合肥呢？”
天气通：“合肥今天多云，微风，有少量雾霾......
用户：“那PM2.5有多少？”
天气通：PM2.5是160
......
6.4.4 应用需要准确地将信息展现给用户
每一个错误都会降低系统的可用性，并使用户产生拒绝使用的意识，需要通过调整提示语和语义文法，使识别的错误率达到最小。
6.4.4.1 明确的告诉用户需要如何回答
给用户一些选项去选择，这些选项的本身并不能充分地告知用户需要如何回答， 所以可以改成询问用户一个问题，让用户知道，他们预计将要说些什么。譬如：
用户：“叮咚叮咚，我想玩一下音乐游戏厅”
较好的回答：“您好，欢迎来到音乐游戏厅，我们现在有：我爱记歌词、猜猜大明星，趣味哼唱，您想玩哪一个？”
不好的回答：“您好，欢迎来到音乐游戏厅，我们现在有：我爱记歌词、猜猜大明星，趣味哼唱，请您在以上三个选项中选择？”
6.4.4.2 回答用户时要尽可能的简洁、明晰
语音播报是线性的，是基于时间顺序的。用户无法像阅读那样可以跳跃性地看，如果语音播报的时间过长，同时也很难让用户在短时间内迅速地做出回答。因此，回答用户的提示语要尽可能的简洁、明晰。譬如：
用户：“叮咚叮咚，查询一下天气”
较好的回答：“你想查哪个城市的？” 或者“请说出城市的名称”
不好的回答：“我们现在已经覆盖了661个城市的天气预报，同时还能查询一些主要国家的首都及大城市的天气”
6.4.4.3 对于复杂交互要给予帮助功能
当应用提供的服务能力较多时（三个以上），在任何一次与用户交互中，都不应该尝试把所有的服务能力在一次交互中都告诉用户。较好的做法是,把用户最需要的能力放在最前面，最后才引导用户说帮助。如果用户说出了帮助，这时才列出应用能提供的所有服务能力。譬如：
用户：“叮咚叮咚，能用嘀嘀打车吗”
较好的回答：“您好，您是想叫一辆车出行，还是想查询嘀嘀的车费，如果都不是，请说帮助”
不好的回答：“您好，你是想查询嘀嘀的车费？还是查询当前的车型？还是预估车程价格，还是想叫一辆车出行？”
6.4.4.4 慎重使用确认
如果让用户过多地使用确认对话，会让用户使用信心受到伤害，熟练的用户也会嫌麻烦。所以要尽量避免使用确认，但出现以下的高风险的行为，需要加上确认。
1、 用户的意图将要公开可见的（譬如：分享到朋友圈）
2、 涉及到扣费、付款的（譬如：用户在购买电影票）
3、 影响到其他的人（譬如：发送一条通知短信）
6.4.5 柔和地处理对话中的错误来保持对话的推进
当错误发生的时候，用户往往会觉得困惑，并有挫败的感觉，如果没有好的错误回复，用户很可能就会结束会话，所以我们需要采用“重复提示”、“重新提示”、“约束用户的说话范围”、“鼓励用户”等措施来保持对话的推进，从而推动交流。
6.4.5.1 使用重新提示来指导用户
如果用户说的话是DingDong音箱或者应用不能理解的意图，DingDong开放平台目前支持使用两种重新提示的方式来指导用户。
1、在用户与应用会话过程中，如果应用通过云端协议向DingDong开放平台指定了需要收集的用户意图时，此时，DingDong开放平台发现用户说的不是需要收集的意图，会重复播报上次的提示来指导用户重新说一次。
2、 用户与应用会话过程中，如果应用没有指定需要收集的用户意图时，DingDong开放平台会把每次的用户输入都会透传到应用，由应用来判断用户的意图，此时，应用发现用户说的意图无法理解或者不需要时，需要使用引导用户该如何说的提示语来指导用户后面的操作。
譬如：
用户：“叮咚叮咚，请次日达应用帮我发一个紧急包裹”
次日达应用：“请说出需要送达的城市名称”
用户：“安庆”
较好的回答：“目前我们只开通了直辖市和省会城市的次日达服务，譬如：北京、合肥，请说出需要送达的城市名称”
不好的回答：“请说出其它的城市名称”
6.4.5.2 不要责备用户
在语音交互过程中，用户的语音与周边环境的噪音很容易混杂在一起，这样的错误会容易发生。当错误发生时，不要将责任归咎于用户，但应用也无需太抱歉（这样做会使你的体验看起来只是暂时的，以避免用户对应用的服务能力失去信心）。譬如：
用户：“叮咚叮咚，请次日达应用帮我发一个紧急包裹”
次日达应用：“请说出需要送达的城市名称”
用户：“[背景噪音很大，掩盖了用户声音]”
较好的回答：“麻烦您再说一次需要送达的城市名称”
不好的回答：“你给的城市是无效的。很抱歉”
6.4.5.3 尽量约束用户的说话范围，防止用户随意说
在视觉界面上，用户可以按照屏幕上呈现的提示与系统进行交互，但在语音交互过程中，没有办法限制用户在语音交互中能够说些什么。因此，在语音交互界面设计中重点要考虑到用户可能说不支持的但却合理的事情，需要智能地去处理它们。譬如：
用户：“叮咚叮咚，预约次日达应用上门来取件”
次日达应用：“好的，你想几点钟过来？”
用户：“晚上10点”
次日达应用：“预约取件时间只能是早上8点到晚上8点钟之间，您想预约在几点？”
用户：“晚上8点”
6.5 联系我们
应用开发者交流QQ1群：698365788，QQ2群：518888507
应用开发者交流社区：http://bbs.dingdong.ai
