action定义流程

输入：s-a（原测试数据中的内容）

确认支付

记录失败原因

叫车界面

action

在打车intent完成后，符号系统会给用户一个event2u的可见事件，此时的event必须是一个成功的事件，输出对应的message_type和message_body。

step1：确定参数

成功

说明

确认打车信息

打车支付请求

支付请求

打车

  message_type再整理

失败

小爱音箱

示例

打车后

输出：a-s

taxi_order_status

等待接驾

在打车品类中，1、用户说，“我在青山湖，打个去梦想小镇的车”，在用户的表述中同时有出发地和目的地的信息；2、对应的action：打车；3、此时助理向符号系统请求的输入参数为和

打车中

打车支付成功

在打车品类中，状态结果的返回有三种：成功/缺失参数/无效参数1、成功：实现打车的intent，用户输入的参数完整并且有效，或者符号系统成功的推断出用户的intent所缺失的相关参数（如：出发地），可以成功完成用户打车的意图；2、缺失参数：完成用户意图时缺失必要的参数，符号系统也不能成功推断该缺失的参数值，此时需要输出用户再次询问，补齐打车intent的必要参数；3、无效参数：用户输入信息在格式上正确，但通过符号系统判断没有实际操作意义，此时需要输出给用户说明当前状态，告诉用户输入正确的出发地或目的地。

符号系统会根据输入的请求slot，做出相应的返回，共包括两部分：1、状态结果的反馈；2、符号系统返回给用户可见的成功的事件（event2u）

在打车品类中，1、必要参数有：出发地、目的地；2、非必要参数有：帮助对象、时间点、时间段、打车类型、订单类型及预估价格；3、根据用户的使用场景以及action的定义，将不同的参数类型进行组合，可以得到打车品类下不同的action，形成一个打车action的簇；4、关于参数的组合顺序，先对必要参数进行组合，输出该品类action的模板，然后再扩展到其他涉及到非必需参数的action，根据用户使用场景的细分不断地扩充action的数量。

taxi_information_confirm

action定义： action = intent……

step2：输入

noti

根据用户的使用场景，对应转化为定义的action，输入不同的请求slot

taxi_order_detailis

as

输入：a-s（原测试数据中的输入内容）

打车前

发布行程

taxi_pay_request

订单详情

支付模块统一

订单状态

模型与技能联调测试流程示意图

dm

输出：a-u

根据用户的使用场景，配置必要参数及非必要参数，然后再定义不同场景下对应的action

输出：s-a

适配器

输入：u-a

step3：输出

taxi_pay_success