CN111369704B - 一种车辆处理方法以及系统 - Google Patents

Abstract

本发明公开了一种车辆处理方法及系统。所述方法包括：获取第一终端的用车请求；基于所述用车请求，确定第一终端对应选择的车辆；获取所述被选择的车辆的故障确认信息；响应于车辆即将开锁和/或完成关锁，至少一次将所述车辆的故障确认信息发送给所述第一终端；获取用户在第一终端上对于故障确认信息的反馈信息；以及至少基于所述反馈信息判断车辆的处理方式。本发明通过根据用户对报修车辆的反馈等数据对出现故障的车辆的检修进行优先级排序，让优先级别高的车辆进行优先处理，从而提高车辆检修效率。

Description

一种车辆处理方法以及系统

技术领域

本发明涉及共享单车领域，尤其涉及一种车辆处理方法以及系统。

背景技术

共享理念、低碳生活理念逐渐得到广大民众的认同，选择共享车辆出行已经成为一种趋势。在车辆使用过程中，当车辆出现问题需要维修时，用户可以通过用户终端对车辆进行保修，并将详细的报修信息上传给服务器进行后续处理。运维部门安排对车辆进行检查维修。但有时车辆的报修结果可能会因为用户的感受不同而出现不同，例如，可能存在报修的车辆中没有出现故障，或出现的故障很小不影响用户骑行等。例如，车座的调节出现故障，有时可能因为用户的力气大小不一样，使得车座的调节难易程度也不一样，实际并非存在故障，这样会造成运维部门的人力、财力、时间等的浪费。因此，需要一种车辆处理方法以及系统对用户的报修信息进行确认和评估，并对不同车辆作出相应的处理，从而提高车辆检修效率。

发明内容

本发明的实施例提供了一种车辆处理方法、系统、装置及计算机可读存储介质。具体包括以下几个方面：

第一方面，本发明披露了一种车辆处理方法。所述方法包括：获取第一终端的用车请求；基于所述用车请求，确定第一终端对应选择的车辆；获取所述被选择的车辆的故障确认信息；响应于车辆即将开锁和/或完成关锁，至少一次将所述车辆的故障确认信息发送给所述第一终端；获取用户在第一终端上对于故障确认信息的反馈信息；以及至少基于所述反馈信息判断车辆的处理方式。

在一些实施例中，获取所述被选择的车辆的故障确认信息还包括：获取所述被选择的车辆的历史报修数据；基于所述被选择的车辆的历史报修数据，确定所述被选择的车辆的故障确认信息。

在一些实施例中，基于所述车辆的历史报修数据，确定被选择的车辆的故障确认信息还包括：基于所述被选择的车辆的历史报修数据，筛选出上报次数最多的故障信息；将所述上报次数最多的故障信息确定为所述被选择的车辆的故障确认信息。

在一些实施例中，获取用户在第一终端上对于故障确认信息的反馈信息还包括：用户在第一终端上通过触屏交互方式反馈被选择的车辆是否存在故障后，获取所述反馈信息；所述反馈信息至少包括以下一种：车辆部位是否存在故障、车辆部位正常或损坏、和车辆部位的故障原因。

在一些实施例中，至少基于所述反馈信息判断车辆的处理方式还包括：基于所述反馈信息，确定用户反馈所述车辆存在故障的次数；当所述车辆被反馈存在故障的次数满足预设条件时，将所述车辆确定为待处理车辆。

在一些实施例中，所述方法还包括：将所述车辆的车辆信息发送给运维终端。

在一些实施例中，至少基于所述反馈信息判断车辆的处理方式还包括：基于所述反馈信息，确定用户反馈所述车辆存在故障的次数；基于不同车辆被反馈存在故障的次数，确定不同车辆待处理的优先级别；基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

在一些实施例中，至少基于所述反馈信息判断车辆的处理方式还包括：基于所述反馈信息、所述车辆的历史报修数据和/或所述车辆的历史订单数据，确定不同车辆待处理的优先级别；基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

在一些实施例中，所述方法还包括：将所述确定为待处理车辆的车辆信息和对应的优先级别发送给运维终端。

第二方面，本发明披露了一种车辆处理系统。所述系统包括：第一获取模块，用于获取第一终端的用车请求；确定模块，用于基于所述用车请求，确定第一终端对应选择的车辆；第二获取模块，用于获取所述被选择的车辆的故障确认信息；发送模块，用于响应于车辆即将开锁和/或完成关锁，至少一次将所述车辆的故障确认信息发送给所述第一终端；第三获取模块，用于获取用户在第一终端上对于故障确认信息的反馈信息；判断模块，用于至少基于所述反馈信息判断车辆的处理方式。

在一些实施例中，第二获取模块还用于：获取所述被选择的车辆的历史报修数据；基于所述被选择的车辆的历史报修数据，确定所述被选择的车辆的故障确认信息。

在一些实施例中，第二获取模块还用于：基于所述被选择的车辆的历史报修数据，筛选出上报次数最多的故障信息；将所述上报次数最多的故障信息确定为所述被选择的车辆的故障确认信息。

在一些实施例中，第三获取模块还用于：用户在第一终端上通过触屏交互方式反馈被选择的车辆是否存在故障后，获取所述反馈信息；所述反馈信息至少包括以下一种：车辆部位是否存在故障、车辆部位正常或损坏、和车辆部位的故障原因。

在一些实施例中，判断模块还用于：基于所述反馈信息，确定用户反馈所述车辆存在故障的次数；基于所述车辆被反馈存在故障的次数，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

在一些实施例中，所述系统还包括：发送模块，用于将所述确定为待处理车辆的车辆信息发送给运维终端。

在一些实施例中，判断模块还用于：基于所述反馈信息，确定用户反馈所述车辆存在故障的次数；基于不同车辆被反馈存在故障的次数，确定不同车辆待处理的优先级别；基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

在一些实施例中，判断模块还用于：基于所述反馈信息、所述车辆的历史报修数据和/或所述车辆的历史订单数据，确定不同车辆待处理的优先级别；基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

在一些实施例中，所述系统还包括：发送模块，用于将所述确定为待处理车辆的车辆信息和对应的优先级别发送给运维终端。

第三方面，本发明披露了一种车辆处理装置。所述装置包括至少一个处理器以及至少一个存储器；所述至少一个存储器用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现所述车辆处理方法。

第四方面，本发明披露了一种计算机可读存储介质。所述存储介质存储计算机指令，当所述计算机指令被处理器执行时实现所述车辆处理方法。

本发明的一部分附加特性可以在下面的描述中进行说明。通过对以下描述和相应附图的检查或者对实施例的生产或操作的了解，本发明的一部分附加特性对于本领域技术人员是显而易见的。本发明的特性可以通过对以下描述的具体实施例的各种方面的方法、手段和组合的实践或使用得以实现和达到。

附图说明

图1为根据本发明的一些实施例所示的一种按需服务系统100的示意图。

图2为根据本发明的实施例所示的一种车辆处理方法200的流程图。

图3为根据本发明的实施例所示的一种示例性的至少基于反馈信息判断车辆的处理方式300的方法流程图。

图4为根据本发明的实施例所示的另一种示例性的至少基于反馈信息判断车辆的处理方式400的方法流程图

图5为根据本发明的实施例所示的另一种示例性的至少基于反馈信息判断车辆的处理方式500的方法流程图。

图6为根据本发明的实施例所示的一种示例性的车辆处理装置600的模块图。

具体实施方式

为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

虽然本申请对根据本申请的实施例的系统中的某些模块或单元做出了各种引用，然而，任何数量的不同模块或单元可以被使用并运行在客户端和/或服务器上。所述模块仅是说明性的，并且所述系统和方法的不同方面可以使用不同模块。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

本申请的实施例可以应用于不同的运输系统，不同的运输系统包括但不限于陆地、海洋、航空、航天等中的一种或几种的组合。例如，出租车、专车、顺风车、巴士、代驾、火车、动车、高铁、无人驾驶的交通工具、收/送快递等应用了管理和/或分配的运输系统。本申请的不同实施例应用场景包括但不限于网页、浏览器插件、客户端、定制系统、企业内部分析系统、人工智能机器人等中的一种或几种的组合。应当理解的是，本申请的系统及方法的应用场景仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其它类似情景。

本申请描述的“乘客端”、“乘客端用户”、“乘客端设备”、“客户端”、“客户端设备”、“客户端用户”、“用户”、“使用者”、“用户端”、“移动终端”、“移动设备”、“第一终端”等是可以互换的，是指需要或者订购服务的一方，可以是个人，也可以是工具。另外，本申请描述的“用户”可以是需要或者订购服务的一方，也可以是提供服务或者协助提供服务的一方。

图1为根据本发明的一些实施例所示的一种按需服务系统100的示意图。

按需服务系统100可以包括服务器110、网络120、用户端130、车辆140和存储器150。

服务器110可以是本地的，也可以是远程的。服务器110可以处理信息和/或数据。在一些实施例中，服务器110可以用于对收集的信息进行分析加工以生成分析结果的系统。服务器110可以是一个终端设备，也可以是一个服务器，还可以是服务器群组。所述服务器群组可以是集中式的，例如数据中心。所述服务器群组也可以是分布式的，例如分布式系统。

网络120可以提供信息交换的渠道。网络120可以是单一网络，也可以是多种网络组合的。在一些实施例中，网络120可以包括一个或多个网络接入点。例如，网络120可以包括有线或无线网络接入点，如基站和/或互联网交换点120-1、120-2、……，系统100的一个或多个部件可以通过接入点连接到网络120以交换数据和/或信息。

用户端130可以也指发布服务订单的个人、工具或者其他实体。在一些实施例中，用户端130包括但不限于移动设备130-1(例如，手机)、车辆的内置设备130-2、笔记本电脑130-3、台式电脑130-4等中的一种或几种的组合。用户端130可以处理信息和/或数据。用户端可以用于对收集的信息进行分析加工以生成分析结果的系统。

车辆140可以包括但不限于单车、自行车、电动车、电动摩托、电动自行车等。车辆140可以包括内置装置，该内置装置可以与服务器110实现网络通信。该内置装置可以包括GPS系统、蓝牙通信模块、近场通讯模块、移动通信模块等。

服务器110可以直接访问存取储存在存储器150的数据信息，也可以直接通过网络120访问存取用户端130的信息。存储器150可以泛指具有存储功能的设备。存储器150主要用于存储从用户端130收集的数据和按需服务系统100工作中产生的各种数据。存储器150可以是本地的，也可以是远程的。系统数据库与系统其他模块间的连接或通信可以是有线的，也可以是无线的。

图2为根据本发明的实施例所示的一种示例性的车辆处理方法200的流程图。

在一些实施例中，该车辆处理方法200可以由服务器110等具有处理、运算能力的设备执行。

步骤201，获取第一终端的用车请求。

用户可以通过第一终端(或用户端130)发送用车请求。进一步地，服务器110通过网络120获取第一终端发送的用车请求。在一些实施例中，用户可以通过安装在第一终端的应用程序发送用车请求。例如，用户可以通过第一终端选择扫描用车扫描车辆上的图像识别信息(例如，二维码、条形码等)发送用车请求。又例如，用户可以通过第一终端手动输入选择的车辆上的编码信息并发送用车请求。

步骤202，基于所述用车请求，确定第一终端对应选择的车辆。

用车请求可以包括车辆的识别信息，服务器110可以根据车辆的识别信息确定第一终端对应选择的车辆。每个车辆具有唯一对应的识别信息。用户在进行用车请求操作时，第一终端会根据车辆上的图像信息解析得到车辆的识别信息。例如，用户通过第一终端扫描车辆上的二维码时，第一终端可以解析得到包含在二维码中的车辆识别信息，并将该识别信息包含在用车请求中发送至服务器110。

步骤203，获取所述被选择的车辆的故障确认信息。

在一些实施例中，服务器110可以获取所述被选择的车辆的历史报修数据，并基于所述被选择的车辆的历史报修数据，确定被所述选择的车辆的故障确认信息。示例性的，获取所述被选择的车辆的故障确认信息可以包括以下步骤：

步骤A1，获取所述被选择的车辆的历史报修数据。

服务器110可以获取所述被选择的车辆的历史报修数据，并将该被选择的车辆的历史报修数据存储在存储器150中。历史用户可以通过用户端130上报该车辆的报修信息给服务器110。例如，历史用户可以通过用户端130的报修界面选择该车辆存在故障。例如，历史用户可以通过用户端130的报修界面上报车座存在故障、刹车存在故障、脚踏存在故障、车把存在故障、车锁存在故障等。进一步地，历史用户也可以选择车辆的部位的具体的故障原因，例如，把手断裂、左刹车失灵、车锁无法锁车等。服务器110可以通过网络120获取历史用户上报的车辆的故障信息，并将不同车辆对应的故障信息一一对应存在存储器150中。

步骤A2，基于所述被选择的车辆的历史报修数据，筛选出上报次数最多的故障信息。

服务器110可以统计所述被选择的车辆的历史报修数据，确定出不同故障信息上报次数。进一步地，基于不同故障信息上报次数，筛选出上报次数最多的故障信息。例如，历史用户上报该车辆的车座存在故障5次、车辆的刹车存在故障4次、车辆的车座存在故障3次。服务器110可以筛选出上报次最多的故障信息为车座存在问题。又例如，当历史用户上报车辆的车座存在故障5次、车辆的刹车存在故障5次、车辆的车座存在故障3次时，服务器110可以确定出上报次数最多的故障信息为车辆的车座存在故障和车辆的刹车存在故障。此时，存在两个上报次数最多的故障信息，服务器110可以将最近一次上报的故障信息确定为上报次数最多的故障信息。例如，最近一次上报的故障信息为车辆的刹车存在故障，服务器110则将车辆的刹车存在故障确定为上报次数最多的故障信息。或者，服务器110可以随机选择其中一种故障信息作为上报次数最多的故障信息。

步骤A3，将所述上报次数最多的故障信息确定为所述被选择的车辆的故障确认信息。

基于步骤A2筛选出的上报次数最多的故障信息，服务器110将该故障信息确定为所述被选择的车辆的故障确认信息。

步骤204，响应于车辆即将开锁和/或完成关锁，至少一次将所述车辆的故障确认信息发送给所述第一终端。

在一些实施例中，响应于车辆即将开锁，服务器110可以将所述车辆的故障确认信息发送给所述第一终端。例如，当用户通过第一终端扫描所述被选择的车辆的二维码成功后，在服务器110通过网络120向车辆发送开锁指令前，服务器110可以向第一终端发送所述车辆的故障确认信息。例如，第一终端的显示界面可以弹出提示界面“系统监测到脚踏板可能出现故障，请帮忙判断”，并提示用户反馈“正常或损坏”。

在一些实施例中，响应于车辆完成关锁，服务器110可以将所述车辆的故障确认信息发送给所述第一终端。例如，当用户通过第一终端向服务器110发送关锁指令，且服务器110向所述车辆发送关锁指令且车辆成功关锁后，服务器110可以向第一终端发送所述车辆的故障确认信息。例如，第一终端的显示界面可以弹出提示界面“您骑行的车辆刹车有问题吗”，并提示用户反馈“没有或有”。

在一些实施例中，在用户使用车辆过程中，服务器110可以向第一终端发送所述车辆的故障确认信息。用户在停车后可以通过第一终端反馈故障确认信息。

步骤205，获取用户在第一终端上对于故障确认信息的反馈信息。

用户可以在第一终端的显示界面上对故障确认信息进行反馈。用户在对故障确认信息进行反馈后，服务器110可以通过网络120获取相应的反馈信息。反馈信息可以包括车辆部位是否存在故障、车辆部位正常或损坏、车辆部位的故障原因等。

在一些实施例中，用户可以通过触屏交互方式反馈被选择的车辆是否存在故障。例如，在第一终端的显示界面弹出提示界面“系统监测到脚踏板可能出现故障，请帮忙判断”，并提示用户选择“正常或损坏”后，用户可以在第一终端的显示界面点击第一终端的显示屏幕选择“正常”或“损坏”。用户可以选择“正常”或“损坏”对故障确认信息进行反馈。进一步地，服务器110可以获取相应的反馈信息。又例如，在第一终端的显示界面弹出提示界面“您骑行的车辆刹车有问题吗”，并提示用户选择“没有或有”后，用户可以在第一终端的显示界面点击第一终端的显示屏幕选择“没有”或“有”。用户可以选择“没有”或“有”对故障确认信息进行反馈。进一步地，服务器110可以获取相应的反馈信息。

在一些实施例中，用户可以通过触屏交互方式进一步反馈车辆部位的具体损坏原因。提示界面可以包括针对车辆部位的具体损坏原因的多个选项。例如，提示界面可以为“系统监测到车刹可能出现故障，请帮忙判断”，请选择“正常或损坏”。当用户选择“损坏”后，第一终端可以弹出新的提示界面，该提示界面可以为“请反馈车刹损坏的具体原因”，并提示用户选择“左车刹失灵”、“右车刹失灵”、“车刹太紧”等。用户可以选择车辆部位具体的损坏原因对故障确认信息进行反馈。进一步地，服务器110可以获取相应的反馈信息。

步骤206，至少基于所述反馈信息判断车辆的处理方式。

基于所述反馈信息，服务器110可以判断出不同的车辆的处理方式。

在一些实施例中，对于单个车辆而言，服务器110可以基于所述反馈信息，确定用户反馈所述车辆存在故障的次数。进一步地，服务器110可以基于所述用户反馈所述车辆存在故障的次数，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。具体内容可以进一步参见后面的详细描述(例如，图2)。进一步地，服务器110可以将将所述确定为待处理车辆的车辆信息发送给运维终端。

在一些实施例中，对于多个车辆而言，服务器110可以基于所述反馈信息，确定用户反馈车辆存在故障的次数。进一步地，服务器110可以基于不同车辆存在故障的次数，确定不同车辆待处理的优先级别。进一步地，服务器110可以基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆；并将满足预设条件的车辆确定为待处理车辆。具体内容可以进一步参见后面的详细描述(例如，图3)。进一步地，服务器110可以将将所述确定为待处理车辆的车辆信息发送给运维终端。

在一些实施例中，对于多个车辆而言，服务器110可以基于所述反馈信息、所述车辆的历史报修数据、所述车辆的历史订单数据等因素，确定不同车辆待处理的优先级别。进一步地，服务器110可以基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。具体内容可以进一步参见后面的详细描述(例如，图4)。进一步地，服务器110可以将将所述确定为待处理车辆的车辆信息发送给运维终端。

图3为根据本发明的实施例所示的一种示例性的至少基于反馈信息判断车辆的处理方式300的方法流程图。

步骤301，基于所述反馈信息，确定用户反馈所述车辆存在故障的次数。

服务器110可以基于所述反馈信息，确定用户反馈所述车辆存在故障的次数。例如，服务器可以统计用户的反馈结果为“有”或“损坏”的次数。例如，存在6个用户对“系统监测到脚踏板可能出现故障，请帮忙判断”的确认信息选择了“损坏”；存在5个用户对“您骑行的车辆刹车有问题吗”的确认信息选择了“有”，则用户反馈该车辆存在故障的次数为11次。在一些实施例中，服务器110也可以统计对车辆的同一部位存在故障的次数。例如，4个用户反馈车辆的车座存在故障；5个用户反馈车辆的链条存在故障。

步骤302，当所述车辆被反馈存在故障的次数满足预设条件时，将所述车辆确定为待处理车辆。

当所述车辆存在故障的次数满足预设条件时，服务器110可以将所述车辆确定为待处理车辆。在一些实施例中，预设条件可以为车辆存在故障的次数大于某一阈值(例如，0次、5次、10次、20次等)。例如，当所述车辆存在故障的次数大于10次时，则服务器110可以将所述车辆确定为待处理车辆。当所述车辆存在故障的次数不大于10次时，则服务器110可以将所述车辆确定为非待处理车辆。通过车辆被反馈存在的故障次数的筛选，使得被反馈存在故障次数多的车辆得到优先处理，可以提高运维部门的工作效率。

步骤303，将所述确定为待处理车辆的车辆信息发送给运维终端。

服务器110可以将所述车辆的车辆信息发送给运维终端。运维终端获取所述车辆的车辆信息后，运维工人可以及时对所述车辆进行维修。

图4为根据本发明的实施例所示的另一种示例性的至少基于反馈信息判断车辆的处理方式400的方法流程图。

步骤401，基于所述反馈信息，确定用户反馈所述车辆存在故障的次数。

服务器110可以基于所述反馈信息，确定用户反馈所述车辆存在故障的次数。步骤401与步骤301类似，具体内容可以参见图3。

步骤402，基于不同车辆被反馈存在故障的次数，确定不同车辆待处理的优先级别。

基于大数据统计，服务器110可以获取不同车辆被反馈存在故障的次数。例如，车辆1存在故障10次、车辆2存在故障8次、车辆3存在故障9次，…，车辆n存在故障5次。进一步地，服务器110可以基于不同车辆被反馈存在故障的次数，确定不同车辆待处理的优先级别。

在一些实施例中，不同车辆待处理的优先级别可以按照车辆被反馈存在故障的次数进行排序，即被反馈存在故障的次数越多，则待处理的优先级别越高。在一些实施例中，服务器110可以按照车辆存在故障次数的范围对不同车辆待处理的优先级别进行划分。例如，将故障次数大于第一阈值(例如，15次)的车辆划分为第一优先级别、将故障次数大于第二阈值(例如，10次)且不大于第一阈值的车辆划分为第二优先级别、将故障次数不大于第二阈值的车辆划分为第三优先级别等。

步骤403，基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

基于所述不同车辆待处理的优先级别，服务器110确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。例如，服务器110可以将所有被报修过的车辆确定为待处理车辆，只是按照优先级别的高低，处理的顺序存在先后。又例如，当不同车辆待处理的优先级别按照车辆存在故障的次数进行排序(例如，按降序排序)时，满足预设条件的车辆可以为前100的车辆，服务器110可以将前100的车辆确定为待处理车辆。又例如，当按照车辆存在故障次数的范围对不同车辆待处理的优先级别进行划分时，满足预设条件的车辆可以为属于第一优先级别(例如，故障次数大于15次)的车辆和属于第二优先级别(例如，故障次数大于10次小于等于15次)的车辆。服务器110可以将属于第一优先级别和第二优先级别的车辆确定为待处理车辆。

步骤404，将所述确定为待处理车辆的车辆信息和对应的优先级别发送给运维终端。

服务器110可以将所述确定为待处理车辆的车辆信息和对应的优先级别发送给运维终端。例如，运维终端获取所述车辆的车辆信息以及对应的优先级别后，运维工人可以按照优先级别的顺序对所有被报修过的车辆进行维修。又例如，运维工人可以按照优先级顺序依次维修排在前100的车辆。又例如，运维工人将优先处理第一优先级别的车辆，当维修完第一优先级别的车辆后再选择维修第二优先级别的车辆。

图5为根据本发明的实施例所示的另一种示例性的至少基于反馈信息判断车辆的处理方式500的方法流程图。

步骤501，基于所述反馈信息、所述车辆的历史报修数据和/或所述车辆的历史订单数据，确定不同车辆待处理的优先级别。

在一些实施中，服务器110可以基于反馈信息、车辆的历史报修数据，确定不同车辆待处理的优先级别。例如，服务器110可以将历史报修次数大于某一阈值(例如，5次)且被反馈存在故障的次数大于某一阈值(例如，10次)的车辆确定为第一优先级别的车辆。又例如，服务器110可以分别设置历史报修次数和被反馈存在故障的次数对应的权重值，例如，历史报修次数的权重为30％、被反馈存在故障次数的权重为70％。例如，服务器110可以将历史报修次数乘以对应的权重值和被反馈存在故障的次数乘以相应的权重值相加计算出的加权值大于8(或其他数值)的车辆确定为第一优先级别的车辆、将加权值大于4不大于8的车辆确定为第二优先级别的车辆等。又例如，服务器110可以按不同车辆对应的加权值大小确定不同车辆待处理的优先级别，即加权值越大表明待处理的优先级别越高。

在一些实施中，服务器110可以基于所述反馈信息、所述车辆的历史报修数据和所述车辆的历史订单数据，确定不同车辆待处理的优先级别。例如，通过设置历史报修次数、报修时对应的骑行时长、被反馈存在故障的次数对应的阈值，判断报修车辆的故障情况。在一些实施例中，报修时对应的骑行时长可以为不同用户报修时骑行的平均时长。例如，设置骑行时长阈值为10(或其他数值)分钟，若车辆骑行时长在10分钟以内进行车辆报修，且历史报修次数和被反馈存在故障的次数满足阈值条件时，则判定车辆为第一优先级别的车辆。又例如，若车辆骑行时长在10至30分钟内才报修，且历史报修次数和被反馈存在故障的次数满足阈值条件时，则可以认为该车辆的故障可能影响骑行的程度相对较小，则服务器110可以判定车辆为第二优先级别的车辆。又例如，若车辆骑行时长超过30分钟才报修，且历史报修次数和被反馈存在故障的次数满足阈值条件时，则可以认为该车辆的故障可能影响骑行的程度很小，则服务器110可以判定车辆为第三优先级别的车辆。

在一些实施中，服务器110可以分别设置被反馈存在故障的次数对应的权重值、历史报修次数对应的权重、报修时车辆骑行时长对应的权重值。例如，被反馈存在故障次数的权重为60％、历史报修次数的权重为30％、车辆骑行时长对应的权重值为10％。进一步地，服务器110可以将历史报修次数乘以对应的权重值、被反馈存在故障的次数乘以相应的权重值以及报修时车辆骑行时长的倒数乘以相应的权重值相加计算出的加权值作为评价车辆待处理优先级别的标准。例如，服务器110可以按加权值的大小来确定不同车辆待处理的优先级别，即加权值越大表明待处理的优先级别越高。又例如，服务器110可以按加权值排序，将加权值排在前100的车辆确定为第一优先级别的车辆、将加权值排在100至200的车辆确定为第二优先级别的车辆、将加权值排在200以后的车辆确定为第三优先级别的车辆等。

步骤502，基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

基于所述不同车辆待处理的优先级别，服务器110确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。例如，服务器110可以将所有被报修过的车辆确定为待处理车辆，只是按照优先级别的高低，处理的顺序存在先后。又例如，服务器110可以按优先级别排序，将排在前100的车辆确定为待处理车辆。又例如，服务器110可以将第一优先级别的车辆和第二优先级别的车辆确定为待处理车辆。

步骤503，将所述确定为待处理车辆的车辆信息和对应的优先级别发送给运维终端。

服务器110可以将所述确定为待处理车辆的车辆信息和对应的优先级别发送给运维终端。例如，运维终端获取所述车辆的车辆信息以及对应的优先级别后，运维工人可以按照优先级别的顺序对所有被报修过的车辆进行维修。例如，运维工人可以按照优先级别顺序依次维修排在前100的车辆。又例如，运维工人可以优先处理属于第一优先级别的车辆，当维修完属于第一优先级别的车辆后再选择维修第二优先级别的车辆。

图6为根据本发明的实施例所示的一种示例性的车辆处理装置600的模块图。

车辆处理装置600可以包括第一获取模块610、确定模块620、第二获取模块630、发送模块640、第三获取模块650和判断模块660。

第一获取模块610可以用于获取第一终端的用车请求。

确定模块620可以用于基于所述用车请求，确定第一终端对应选择的车辆。

第二获取模块630可以用于获取所述被选择的车辆的故障确认信息。

发送模块640可以用于响应于车辆即将开锁和/或完成关锁，至少一次将所述车辆的故障确认信息发送给所述第一终端。

第三获取模块650可以用于获取用户在第一终端上对于故障确认信息的反馈信息。

判断模块660可以用于至少基于所述反馈信息判断车辆的处理方式。

在一些实施例中，第二获取模块630还可以用于获取所述被选择的车辆的历史报修数据；基于所述被选择的车辆的历史报修数据，确定所述被选择的车辆的故障确认信息。

在一些实施例中，第二获取模块630还可以用于基于所述被选择的车辆的历史报修数据，筛选出上报次数最多的故障信息；将所述上报次数最多的故障信息确定为所述被选择的车辆的故障确认信息。

在一些实施例中，第三获取模块650还可以用于用户在第一终端上通过触屏交互方式反馈被选择的车辆是否存在故障后，获取所述反馈信息；所述反馈信息至少包括以下一种：车辆部位是否存在故障、车辆部位正常或损坏、和车辆部位的故障原因。

在一些实施例中，判断模块660还可以用于基于所述反馈信息，确定用户反馈所述车辆存在故障的次数；基于所述用户反馈所述车辆存在故障的次数，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

在一些实施例中，车辆处理装置600还可以包括发送模块。发送模块可以用于将所述确定为待处理车辆的车辆信息发送给运维终端。

在一些实施例中，判断模块660还可以用于基于所述反馈信息，确定用户反馈所述车辆存在故障的次数；基于不同车辆存在故障的次数，确定不同车辆待处理的优先级别；基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

在一些实施例中，车辆处理装置600还可以包括发送模块。发送模块可以用于将所述确定为待处理车辆的车辆信息发送给运维终端。

在一些实施例中，判断模块660还可以用于至少基于所述反馈信息、所述车辆的历史报修数据、所述车辆的历史订单数据，确定不同车辆待处理的优先级别；基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

在一些实施例中，车辆处理装置600还可以包括发送模块。发送模块可以用于将所述确定为待处理车辆的车辆信息发送给运维终端。

本发明还涉及一种车辆处理装置。所述装置包括至少一个处理器以及至少一个存储器；所述至少一个存储器用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现所述车辆处理方法。

本发明还涉及一种计算机可读存储介质。所述存储介质存储计算机指令，当所述计算机指令被处理器执行时实现所述车辆处理方法。

本申请实施例可能带来的有益效果包括但不限于：本发明通过根据用户对报修车辆的反馈、车辆的历史报修数据、车辆的历史订单数据等数据进行综合判断报修的车辆是否真的出现故障，以及根据报修车辆的反馈、车辆的历史报修数据、车辆的历史订单数据等数据对出现故障的车辆的检修进行优先级排序，让优先级别高的车辆进行优先处理，从而提高车辆检修效率。

需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或类似介质，或任何上述介质的组合。

本申请各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、Visual Basic、Fortran 2003、Perl、COBOL 2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。

此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

针对本申请引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本申请作为参考。与本申请内容不一致或产生冲突的申请历史文件除外，对本申请权利要求最广范围有限制的文件(当前或之后附加于本申请中的)也除外。需要说明的是，如果本申请附属材料中的描述、定义、和/或术语的使用与本申请所述内容有不一致或冲突的地方，以本申请的描述、定义和/或术语的使用为准。

最后，应当理解的是，本申请中所述实施例仅用以说明本申请实施例的原则。其他的变形也可能属于本申请的范围。因此，作为示例而非限制，本申请实施例的替代配置可视为与本申请的教导一致。相应地，本申请的实施例不仅限于本申请明确介绍和描述的实施例。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述为本申请的基本构思，仅以实施例形式呈现，显而易见地，本领域的技术人员依据本申请作出相应变化、改进或修正。这些变化、改进和修正已被本申请所暗示或间接提出，均包含在本申请实施例的精神或范围之内。

Claims (10)

1.一种车辆处理方法，其特征在于，包括：

获取第一终端的用车请求；

基于所述用车请求，确定第一终端对应选择的车辆；

获取所述被选择的车辆的历史报修数据；

基于所述被选择的车辆的历史报修数据，确定所述被选择的车辆的故障确认信息；

响应于车辆即将开锁和/或完成关锁，至少一次将所述车辆的故障确认信息发送给所述第一终端；

获取用户在第一终端上对于故障确认信息的反馈信息；

基于所述反馈信息、所述车辆的历史报修数据和所述车辆的历史订单数据的加权值，确定不同车辆待处理的优先级别；以及

基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

2.如权利要求1所述的方法，其特征在于，基于所述车辆的历史报修数据，确定被选择的车辆的故障确认信息还包括：

基于所述被选择的车辆的历史报修数据，筛选出上报次数最多的故障信息；将所述上报次数最多的故障信息确定为所述被选择的车辆的故障确认信息。

3.如权利要求1所述的方法，其特征在于，获取用户在第一终端上对于故障确认信息的反馈信息还包括：

用户在第一终端上通过触屏交互方式反馈被选择的车辆是否存在故障后，获取所述反馈信息；

所述反馈信息至少包括以下一种：车辆部位是否存在故障、车辆部位正常或损坏、和车辆部位的故障原因。

4.如权利要求1所述的方法，其特征在于，还包括：

将所述确定为待处理车辆的车辆信息和对应的优先级别发送给运维终端。

5.一种车辆处理系统，其特征在于，包括：

第一获取模块，用于获取第一终端的用车请求；

确定模块，用于基于所述用车请求，确定第一终端对应选择的车辆；

第二获取模块，用于获取所述被选择的车辆的历史报修数据；基于所述被选择的车辆的历史报修数据，确定所述被选择的车辆的故障确认信息；

发送模块，用于响应于车辆即将开锁和/或完成关锁，至少一次将所述车辆的故障确认信息发送给所述第一终端；

第三获取模块，用于获取用户在第一终端上对于故障确认信息的反馈信息；

判断模块，用于基于所述反馈信息、所述车辆的历史报修数据和所述车辆的历史订单数据的加权值，确定不同车辆待处理的优先级别；以及基于所述不同车辆待处理的优先级别，确定出满足预设条件的车辆，并将满足预设条件的车辆确定为待处理车辆。

6.如权利要求5所述的系统，其特征在于，第二获取模块还用于：

基于所述被选择的车辆的历史报修数据，筛选出上报次数最多的故障信息；将所述上报次数最多的故障信息确定为所述被选择的车辆的故障确认信息。

7.如权利要求5所述的系统，其特征在于，第三获取模块还用于：

用户在第一终端上通过触屏交互方式反馈被选择的车辆是否存在故障后，获取所述反馈信息；

所述反馈信息至少包括以下一种：车辆部位是否存在故障、车辆部位正常或损坏、和车辆部位的故障原因。

8.如权利要求5所述的系统，其特征在于，还包括：

发送模块，用于将所述确定为待处理车辆的车辆信息和对应的优先级别发送给运维终端。

9.一种车辆处理装置，其特征在于，所述装置包括至少一个处理器以及至少一个存储器；

所述至少一个存储器用于存储计算机指令；

所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现如权利要求1～4中任意一项所述的操作。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储计算机指令，当所述计算机指令被处理器执行时实现如权利要求1～4中任意一项所述的操作。

Images