进入了智能语音时代，我们都已经熟悉了如何在DuerOS 上开发一个智能语音技能应用，典型的流程如下：
在完成代码之后，在上线商用之前，就是我们的日常——技能的调试。对于SaaS或者类AI中台之类的服务，联合调试并不是一件轻而易举的事。
在DBP平台上，提供了多种调试的方式，这里简要介绍意图调试，模拟器调试，真机调试，团队调试，还有不可或缺的日志调试。
意图调试
意图调试是对交互模型的部分调试。意图代表用户想要达到的目的，常用表达是一系列与意图相对应的常用口语化表达，常用表达可以包含槽位的信息。
在我们创建交互模型之后，可以对所创建的意图进行调试，以判断语音的交互是否可以被DuerOS系统识别为我们定义的意图。
意图测试的局限是没有携带任何设备端的上下文信息，对于媒体播放以及多轮对话等存在着较多的局限，比较适合于相对独立的话术意图测试。
模拟器调试
模拟器调试是对业务逻辑的模拟测试，是基于DBP 控制台的simulator 进行的调试。
鉴于概念的区分，有必要比较一下仿真器（Emulator ）和模拟器（Simulator）的区别。
模拟器（Simulator），又称模拟程序，是指完全基于主机程序并模拟了目标处理器的功能和指令系统的程序。模拟器是用于分析研究目标系统本身，模拟器系统本身跟目标系统保持一致。好的模拟器本身也可以仿真其目标系统，但不是所有模拟器都有这个特性。
仿真器（Emulator），又称仿真程序，在软件工程中指可以使计算机或者其他多媒体平台（掌上电脑，手机）能够运行其他平台上的程序，目的是作为目标系统的替代品，可以完全替代目标系统，完成其对外的功能，即仿真器系统只需要保证呈现给外部的行为跟目标系统一致（不需要保证内部运行原理一致）。
显然，DBP 提供的是模拟器，通过控制台模拟器，开发者输入用户的语音query，途径DuerOS 操作系统，转换成意图等信息送达技能服务的Bot，并将从Bot返回的结果呈现在控制台和模拟器上。
模拟器调试有着自身的局限，当前的限制包括：
1.渲染的图形、布局与真机有差异，比如元素在模拟器上占据的区域、宽高、间隔和真机上相比有细微差异。这种差异在某种具体的组件下可能会很大，但是大部分都能较好模拟。
2.模拟器上报的端状态没有真机那么全。但是上报的端状态包含了基本的必须的端状态，比如tts播报开始/结束，当前渲染的是哪一屏数据。
3.模拟器不支持动画，不支持异步指令，比如在DPL页面渲染之后，在不刷新页面的前提下操作页面内的元素，这在模拟器上是不支持的。
4.模拟器还不支持点击事件，在模拟器上点击时不会上报事件到云端。
5.模拟器现在还不能返回homecard等等。
真机调试
在真实设备上的调试才是确保智能语音技能正常工作的前提。无论是有屏设备，还是无屏设备，都要在控制台勾选“技能调试模式”才能进行真机调试。
需要注意的是，在真机调试的时候，要保证技能的开发者账号要与设备的登陆账号一致。
对设备说，“小度小度，打开技能调试模式”即可启用真机调试，在真实设备上来调试/测试我们开发的技能了。对个人开发者而言，同一时间仅支持一个技能的调试。
团队调试
对于企业开发者而言， 往往需要在多个设备上由多个开发者同时调试技能，这就需要用到Team Debug 的功能。
企业开发者可创建团队，邀请其他开发者加入团队，团队创建者审核确认后成为团队成员。团队创建者可以将自己的技能授权给团队进行技能调试，团队成员可在【团队技能】中打开相应的技能调试开关，然后在使用绑定了自己账号的设备上进行技能的调试。
首先，开发者点击【创建团队】，跳转到团队信息页面。
然后，填写团队名称和简介，点击【保存】。
在团队信息页面点击【邀请加入】，或者在【控制台】页面将光标移动到团队名称上方，点击【邀请】。
在弹出的对话框里点击【复制】将邀请链接复制下来，发送给其他要加入团队的开发者，其他开发者点击后即可申请加入。
对于成员的审核，在【控制台】我的团队列表中，将光标移动到团队名称上方，点击【管理】，进入团队信息页面。
点击左侧【成员审核】，进入审核页面，点击【同意】即可审核通过，被邀请的开发者成为团队正式成员。
团队创建人进入【团队技能】页面，在【我的技能】列表中选择要授权给团队的技能，开启开关即可将该技能的调试权限授权给团队。
普通团队成员进入【团队技能】页面，选择要调试的技能，开启右侧【技能调试】开关，然后可以在绑定自己账号的设备上调试该技能。
团队调试的方式与iOS的企业开发者类似， 为大型团队或大型技能应用的开发调试提供了便利。
日志调试
以上的诸多调试方式，都是通过交互测试的手段来对智能语音技能的输入输出进行验证，并进行进一步的调试。
对于技能的业务逻辑而言， 尽管可以通过ngrok建立内网穿透的方式实现单步调试，但是由于各种网络超时的限制，导致效果不佳。
日志调试是大多数基于云服务应用调试的不二法门，关于日志的用途可以参见《全栈必备 Log日志》。
技能Bot的日志记录要尽量完整，最好保存完整的request 和response信息。对DBP 协议的深入理解，可以在很大程度上帮助开发者发现技能Bot 中的问题，模拟器调试中的Request/Response信息为日志的记录提高了可参考的模式。其中，RequestID，DialogRequestID，设备ID，用户ID 以及时间戳是每一条日志的重要标识，也是DuerOS 与开发者之间沟通排查的主要依据。
对于基于Web Service 部署的技能服务，日志的记录以及基于日志的调试取决于具体的技能实现编程语言，日志的记录方式与一般的Web服务日志没有太多的差异。对于基于CFC开发的应用，可以将日志存储在指定的BOS上，并注意一下定期清理。对于基于在线编辑器实现的技能，面向在线编辑器的日志记录还在DBP 平台的开发规划中，很快就可以上线应用了。
小结
调试对于创作出深受用户喜爱的语音技能意义重大，目前，DuerOS Bot Platform （DBP）提供了意图调试、模拟器调试、真机调试、团队真机调试以及日志追踪调试等多种方式，但距离DBP 平台高效开发与高效调试的目标还有较大差距，DBP正在积极地进行平台演进，会陆续为开发者提供更多稳定易用且功能强大的平台工具。
