本申请涉及服务领域，具体而言，涉及信息提示方法、装置、电子设备和存储介质。
背景技术：
：近些年，随着互联网技术的兴盛，出现了一些基于互联网技术的新兴服务业，比如网约车服务、外卖服务等。这些新兴服务业给服务请求方和服务提供方都带来了极大的便利。以网约车为例，服务请求方可以在自己出行前就下达订单，来提前预约出行时间和出行地点，以免在出行时需要花费大量时间在路边等待出租车；出租车服务提供方可以根据服务请求方所期望到达的目的地来选择运送的服务请求方，进而，服务请求方和服务提供方双方都可以更好的安排自己的出行。技术实现要素：本申请的目的在于提供信息提示方法、装置、电子设备和存储介质。本申请所提供的一种信息提示方法，该方法包括：获取服务请求方发送的服务请求信息；基于服务请求信息，确定订单服务信息；若订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息，提示信息用于提示服务请求方确认是否需要对服务请求信息进行修改。在一些实施例中，在基于服务请求信息，确定订单服务信息之后，还包括：若订单服务信息不符合预设服务信息范围，则向服务请求方发送订单服务信息。在一些实施例中，向服务请求方发送订单服务信息，包括：向服务请求方发送携带有订单服务信息的发单页面信息；向服务请求方发送提示信息，包括：向服务请求方发送携带有提示信息的弹窗信息，以便在服务请求方的发单页面上通过弹窗方式展示提示信息。在一些实施例中，订单服务信息包括以下信息中的至少一种：订单价格、出行距离、出行时间和服务等待时长。在一些实施例中，订单服务信息不符合预设服务信息范围包括以下情况中的一种或多种：订单价格超过设定价格阈值；出行距离超过设定距离阈值；出行时间超过设定时长；服务等待时长超过设定时长。在一些实施例中，提示信息中包括以下信息中的至少一种：提示服务请求方确认出行起点和出行终点的信息；存在异常的订单服务信息；选择继续发单的按钮；选择返回修改服务请求信息的按钮。在一些实施例中，基于服务请求信息，确定订单服务信息，包括：基于服务请求信息，确定多种服务方式中每种服务方式对应的订单服务信息。在一些实施例中，若订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息，包括：获取服务请求方从多种服务方式中选择的一种服务方式；若在服务请求方选择的一种服务方式下的订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息。在一些实施例中，若订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息，包括：若至少一种服务方式所对应的订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息；提示信息中携带有不符合预设服务信息范围的订单服务信息的所对应的提示方式，以使服务请求方按照提示方式展示不符合预设服务信息范围的订单服务信息。在一些实施例中，预设服务信息范围是通过如下步骤确定的：获取服务请求方的历史服务信息；根据服务请求方的历史服务信息，确定预设服务信息范围。在一些实施例中，服务方式包括：出租车服务、代驾服务服务、快车服务、拼车服务、公共汽车服务服务、驾驶员租赁服务和班车服务。本申请所提供的一种信息提示装置，该装置包括：第一获取模块，用于获取服务请求方发送的服务请求信息；第一确定模块，用于基于服务请求信息，确定订单服务信息；第一发送模块，若订单服务信息不符合预设服务信息范围，则用于向服务请求方发送提示信息，提示信息用于提示服务请求方确认是否需要对服务请求信息进行修改。在一些实施例中，还包括：第二发送模块，若订单服务信息不符合预设服务信息范围，则用于向服务请求方发送订单服务信息。在一些实施例中，第二发送模块，包括：第一发送单元，用于向服务请求方发送携带有订单服务信息的发单页面信息；第一发送模块，包括：第二发送单元，用于向服务请求方发送携带有提示信息的弹窗信息，以便在服务请求方的发单页面上通过弹窗方式展示提示信息。在一些实施例中，订单服务信息包括以下信息中的至少一种：订单价格、出行距离、出行时间和服务等待时长。在一些实施例中，订单服务信息不符合预设服务信息范围包括以下情况中的一种或多种：订单价格超过设定价格阈值；出行距离超过设定距离阈值；出行时间超过设定时长；服务等待时长超过设定时长。在一些实施例中，提示信息中包括以下信息中的至少一种：提示服务请求方确认出行起点和出行终点的信息；存在异常的订单服务信息；选择继续发单的按钮；选择返回修改服务请求信息的按钮。在一些实施例中，第一确定模块，包括：第一确定单元，用于基于服务请求信息，确定多种服务方式中每种服务方式对应的订单服务信息。在一些实施例中，第一发送模块，包括：第一获取单元，用于获取服务请求方从多种服务方式中选择的一种服务方式；第三发送单元，若在服务请求方选择的一种服务方式下的订单服务信息不符合预设服务信息范围，则用于向服务请求方发送提示信息。在一些实施例中，第一发送模块，包括：第四发送单元，若至少一种服务方式所对应的订单服务信息不符合预设服务信息范围，则用于向服务请求方发送提示信息；提示信息中携带有不符合预设服务信息范围的订单服务信息的所对应的提示方式，以使服务请求方按照提示方式展示不符合预设服务信息范围的订单服务信息。在一些实施例中，预设服务信息范围是通过如下模块确定的：第二获取模块，用于获取服务请求方的历史服务信息；第二确定模块，用于根据服务请求方的历史服务信息，确定预设服务信息范围。在一些实施例中，服务方式包括：出租车服务、代驾服务服务、快车服务、拼车服务、公共汽车服务服务、驾驶员租赁服务和班车服务。本申请所提供的一种电子设备，包括：处理器、存储介质和总线，存储介质存储有处理器可执行的机器可读指令，当电子设备运行时，处理器与存储介质之间通过总线通信，处理器执行机器可读指令，以执行时执行如信息提示方法的步骤。本申请所提供的一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如信息提示方法的步骤。本申请实施例提供的信息提示方法，首先获取了服务请求方发送的服务请求信息；而后，基于服务请求信息，确定了具体的订单服务信息；最后，如果订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息，提示信息用于提示服务请求方确认是否需要对服务请求信息进行修改。这种处理方式，使得服务请求方能够及时的对自己所发出的服务请求信息进行修改，以提高服务请求方操作的准确度。在某种实施方式下，本申请所提供的方法中，可以将提示信息在发单页面上进行展示，以使服务请求方在下达服务订单之前就完成对服务请求信息的修改，避免了服务请求方在下达服务订单后再取消服务订单而造成违约的情况。在某种实施方式下，本申请所提供的方法中，订单服务信息包括以下信息中的至少一种：订单价格、出行距离、出行时间和服务等待时长。进而在对服务请求方进行提示的时候，可以从多个不同的角度同时进行提示，提高了服务请求方的感受度。在某种实施方式下，本申请所提供的方法中，在确定订单服务信息时，可以基于服务请求信息，确定多种服务方式中每种服务方式对应的订单服务信息。在该种实施方式下，订单服务信息是根据服务方式的特性而确定出来的，提高了订单服务信息的计算的针对性和准确度。为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。附图说明为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。图1示出了本申请实施例所提供的信息提示方法的基本流程图；图2示出了本申请实施例所提供的信息提示方法中，在订单价格过高后，输出提示信息的一种具体形式；图3示出了本申请实施例所提供的信息提示方法中，服务等待时间的具体展现形式；图4示出了本申请实施例所提供的电子设备的示意图；图5示出了是本申请一些实施例的信息提示方法所在的服务系统的框图。具体实施方式下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。相关技术中，随着互联网技术的兴起，出现了一些基于互联网技术的新兴服务业，比如网约车服务、外卖服务等。以网约车服务为例，在服务请求方享受网约车服务时，首先要由服务请求方(如乘客)向服务器下达服务订单，而后，服务器会将服务订单向某些服务提供方(如司机)广播，服务提供方在收到广播后，可以选择回复该广播或者是忽略该广播，进而服务器可以根据服务提供方的回复该广播的情况来确定将该服务订单分配给哪个服务提供方。进而，在服务器将服务订单分配给指定的服务提供方后，被分配服务订单的服务提供方就可以按照服务订单中的要求来运送服务请求方，进而完成网约车服务了。在服务请求方向服务器下达服务订单时，需要在服务订单中携带和服务相关的信息，比如服务地点、服务类型、服务时间等，服务平台在将服务订单转发给服务提供方的时候，也会将这些信息一并进行转发，服务提供方也正是凭借这些信息确定自己是否要承接服务订单。但实际操作的时候，由于种种原因，服务请求方可能由于手误而导致输入错误，致使输入的服务地点、服务类型、服务时间等信息发生错误，如果服务平台直接将携带有错误信息的服务订单转发给司机的话，则会造成后续的服务出现问题，比如后续流程中，服务请求方可能会撤销服务订单等。因此，本申请发明人认为，可以在将服务订单发送给司机之前先对服务订单中的信息进行核验，以确定服务请求方所提供的信息是否有误，如果有误的话，则对服务请求方进行提示，以使服务请求方对这些信息进行修改。进而，本申请提供了一种信息提示方法，该方法包括：s101，获取服务请求方发送的服务请求信息；s102，基于服务请求信息，确定订单服务信息；s103，若订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息，提示信息用于提示服务请求方确认是否需要对服务请求信息进行修改。其中，服务请求信息是由服务请求方通过操作服务请求方所生成的，或者是服务请求方自动生成，服务请求信息中所携带的信息的种类比较多，比如，可以有服务请求方的定位位置(如通过定位系统获取的服务请求方的当前位置)、服务请求方所选择的服务位置(如网约车的出行起点、出行终点)、服务时间(如上车时间)等。s101中，服务请求方发出服务请求信息的行为可以是自动发出的，也可以是服务请求方在受到服务请求方触发后发出的。具体的，服务请求信息通常有两种形式，第一种形式是服务请求信息是在服务请求方在发出服务订单前发出的用于进行验证的信息(只有服务请求方发出服务订单后，服务器才会将认为服务请求方期望下单，如果服务请求方只是发出了服务请求信息，则服务器只是会执行s102和103动作，而不会直接将服务请求信息作为服务订单发送给服务提供方)；实际上，这些用于验证的信息的内容和服务订单中的内容可以是一样的，服务请求方发出服务请求信息的目的也是在下达服务订单之前先进行一次验证，避免在下达服务订单之后，再取消服务订单而造成违约的情况。对应的，第二种形式是服务请求信息是携带在服务订单中一起下达的，或者是说服务请求信息就是服务订单。不论服务请求信息的形式如何，s102中都需要确定出对应的订单服务信息，订单服务信息是根据服务请求信息确定出的和服务订单有关的信息(就是根据服务请求信息模拟出服务请求方按照服务请求信息下达服务订单的话，对应的服务订单中所包含的信息的内容)，比如，订单服务信息可以有以下信息中的任意一种或多种：订单价格、出行距离、出行时间和服务等待时长等。其中，订单价格指的是在服务提供方在完成服务订单之后，服务请求方需要向服务提供方所支付的价格。该订单价格的计算和多个方面的信息是有关系的，比如该价格可以是通过以下多个信息计算得到的：服务类型信息、服务请求方所对应的优惠信息、资源消耗量等。其中，服务类型指的是服务请求方所选择的类型(如在服务请求信息中所携带的类型)，如果是网约车业务的话，服务类型可以有拼车车辆、专车、快车、出租车、顺风车等。优惠信息指的是如优惠券、折扣卷等能够将订单价格进行调整的信息。优惠券、折扣卷可以是服务请求方所对应的电子钱包中预存的。优惠券、折扣卷可以是服务器或者其他服务请求方发送给该服务请求方的，也可以是根据服务请求方的身份信息临时确定的。比如，年龄超过65岁的老年人乘坐网约车都是95折，这种确认折扣的方式就是根据服务请求方的身份信息(如年龄信息)确定的。资源消耗量主要是指服务提供方完成本次服务所需要消耗掉的成本。以网约车为例，消耗掉的有汽油(提供服务的车辆为汽油车)、电能(提供服务的车辆为电动车)、车损(提供服务的车辆可能发生的部件磨损老化)等。具体的，由于汽油和电能的消耗量无法准确的测算出来，因此，一般技术中都是根据车辆行驶距离、拥堵时长等信息折算出的耗油量或耗电量，或者是说根据车辆行驶距离、拥堵时长等信息可以直接折算出订单价格出行距离有两种具体的情况，分别是从出行起点到达出行终点的距离和服务请求方从当前位置移动到出行起点的距离。其中，出行起点指的是服务提供方接服务请求方的地点，或者是服务请求方上车的地点。出行终点是服务请求方预定的目的地(服务请求方期望到达的地点)。服务请求方的当前位置指的是服务请求方当前所在的位置，该位置可以通过定位系统(gps或北斗定位系统)获取到的。这两个距离的差别在于，从出行起点到达出行终点的距离是服务提供方驾驶车辆运载服务请求方的距离；服务请求方从当前位置移动到出行起点的距离指的是服务请求方采用自选的出行方式，移动到出行起点的距离。出行方式有步行、自行车出行、电动车出行、机动车出行。不管是上述哪种距离，都要先确定出行的导航路线，再将导航路线的距离作为从出行起点到达出行终点的距离，或服务请求方从当前位置移动到出行起点的距离。出行时间和出行距离是相关的，都是反映了和导航路线相关的信息。在确定了导航路线之后，结合道路的拥堵情况就可以确定出出行时间了。与出行距离相类似的，出行时间也有两种具体的情况，分别是服务请求方从当前位置移动到出行起点的时间和从出行起点到达出行终点的时间。需要说明的是，从出行起点到达出行终点的时间可以有多种表达方式，下面仅列举两种：第一种表达从出行起点到达出行终点的时间的表达方式：将从出行起点移动到出行终点所消耗的时间作为从出行起点到达出行终点的时间。第二种表达从出行起点到达出行终点的时间的表达方式：将服务请求方到达出行终点的时间作为从出行起点到达出行终点的时间。这两种表达方式的差别在于，第二种表达方式是在第一种表达方式的基础上计算得到的(通常，需要结合从出行起点移动到出行终点所消耗的时间、服务请求方从当前位置移动到出行起点的时间和服务等待时间来确定)。如图3所示，预计10:47到达就是从出行起点到达出行终点的时间的一种表达形式。服务等待时长指的是服务提供方从出行起点接到服务请求方的时间(具体可以是某一个时刻的时刻值，如12:57分)，或者说，是从当前时间到服务提供方移动到出行起点的时间(具体可以是剩余的时间，如3分钟后服务提供方到达出行起点)。如图3所示，示出了服务等待时间的具体展现形式，图3中，2分钟后上车表示了服务等待时间。由于订单服务信息可以包含有上述多种信息中的任意一种或多种，进而，订单服务信息不符合预设服务信息范围包括以下情况中的一种或多种：订单价格超过设定价格阈值；出行距离超过设定距离阈值；出行时间超过设定时长；服务等待时长超过设定时长。具体实现时，上述四种情况出现任意一种就可以认为订单服务信息不符合预设服务信息范围。当然，根据预先设定的要求，可以是上述四种情况出现任意至少两种就可以认为订单服务信息不符合预设服务信息范围。在确定了订单服务信息后，就可以在步骤s103中确定是否向服务请求方发送提示信息了。如前文中所说的内容，订单服务信息中所包含的信息比较多，具体实现的时候，可以有两种判断订单服务信息是否符合预设服务信息范围的方式：第一种判断订单服务信息是否符合预设服务信息范围的方式：是分别对每个信息(如预计的订单价格、服务请求方服务请求方从当前位置移动到出行起点的距离、服务请求方服务请求方从当前位置移动到出行起点的时间、从出行起点到达出行终点的距离、从出行起点到达出行终点的时间)进行判断，以确定这些信息是否符合对应的阈值范围。如果有一个订单服务信息不符合对应的阈值范围，则确定向服务请求方发送提示信息。第二种判断订单服务信息是否符合预设服务信息范围的方式：是分别对每个信息(预计的订单价格、服务请求方从当前位置移动到出行起点的距离、服务请求方从当前位置移动到出行起点的时间、从出行起点到达出行终点的距离、从出行起点到达出行终点的时间、服务等待时长)进行判断，以确定这些信息是否符合对应的阈值范围。而后，根据预设的要求，查看相关联的多个订单服务信息中是否至少一个订单服务信息符合对应的阈值范围，如果相关联的多个订单服务信息中至少一个订单服务信息符合对应的阈值范围，则不向服务请求方发送提示信息；如果相关联的多个订单服务信息均不符合对应的阈值范围，则向服务请求方发送提示信息；此处，多个订单服务信息之间是否相关联可以是服务请求方预先设置的，比如服务请求方服务请求方从当前位置移动到出行起点的距离和服务请求方服务请求方从当前位置移动到出行起点的时间就可以是关联的，因为这两个信息都能够反映服务请求方服务请求方从当前位置移动到出行起点的情况，对应的，服务请求方服务请求方从当前位置移动到出行起点的距离、从出行起点到达出行终点的距离、预计的订单价格就可以是不相关联的，因为这三个信息从不同的角度反映了服务订单。在向服务请求方发送提示信息后，服务请求方可以依据提示信息选择对服务请求信息是否进行修改，如果服务请求方认为自己所发出的服务请求信息有误，则应当重新提交服务请求信息，服务器在接收到重新提交的服务请求信息后，应当依据重新提交服务请求信息重新执行步骤s101。如果服务请求方认为自己所发出的服务请求信息无误，则可以向服务器发送确认指令，以使服务器根据服务请求信息生成出行订单，而后，服务器就可以将服务订单向服务提供方发送，并进一步确定由哪个服务提供方承接该服务订单了。通常情况下，步骤s103中，提示信息只包含有用于进行提示的文字，没有具体的订单服务信息的内容。此处，订单服务信息如“订单价格为100元”、“服务请求方服务请求方从当前位置移动到出行起点的距离为5km”、“服务请求方服务请求方从当前位置移动到出行起点的时间为10分钟”、“从出行起点到达出行终点的距离为15km”、“从出行起点到达出行终点的时间为25分钟”等。用于进行提示的文字如“订单价格过高”、“服务请求方从当前位置移动到出行起点的距离过长”等。也就是提示信息中没有具体的某种订单服务信息的内容(数值)，只有提示性的文字(说明某种订单服务信息的不符合要求的文字)。如图2中所示，示出了订单价格过高后，输出提示信息的一种具体形式，图2中，示出了“当前订单金额可能较高，为保证形成顺利，请确认起终点是否准确”的文字。图2中的文字就是通过弹窗的形式显示在服务请求方的显示屏上的。也就是步骤s103中，在向服务请求方发送提示信息之后，服务请求方只能知道订单服务信息不太合理，但并不清楚具体的数值。进而，为了能够让服务请求方更加清楚订单服务信息的情况，可以是在向服务请求方发送了提示信息的基础上，进一步向服务请求方发送订单服务信息，以使服务请求方更加清楚具体的内容。也就是，本申请所提供的方法中，在s102之后，还包括：若订单服务信息不符合预设服务信息范围，则向服务请求方发送订单服务信息。具体的，发送订单服务信息的步骤可以是和发送提示信息的步骤同时执行，也可以是这两个步骤中某一个步骤先执行，另一个步骤后执行。如前文中的说明，服务请求信息有两种具体的形式，分别是：第一种形式是服务请求信息是在服务请求方在发出服务订单前发出的用于进行验证的信息；第二种形式是服务请求信息是携带在服务订单中一起下达的，或者是说服务请求信息就是服务订单。进而，当服务请求信息是上述第一种形式时，就可以根据直接通过在发单页面上携带提示信息发送给服务请求方了，如果服务请求方认为信息无误的话，可以直接通过操作发单页面，以下达服务订单。也就是，本申请所提供的方法中，向服务请求方发送提示信息，包括：向服务请求方发送携带有提示信息的弹窗信息，以便在服务请求方的发单页面上通过弹窗方式展示提示信息。也就是，在发送提示信息的时候，是通过弹窗信息的形式发送提示信息，以便于增强客户的提示效果。并且，该弹窗信息是携带在服务请求方的发单页面上展示出来，这样服务请求方可以直接在发单页面上进行操作，以完成生成/下达服务订单的操作。类似的，发送订单服务信息的方式也可以是通过在发单页面上携带订单服务信息来对服务请求方进行提示。也就是，向服务请求方发送订单服务信息，包括：向服务请求方发送携带有订单服务信息的发单页面信息，以便于服务请求方在发端页面上直接显示订单服务信息，或者是在发单页面上通过弹窗方式展示订单服务信息。具体而言，在发单页面上展示提示信息或者是展示订单服务信息的方式有多种，除了采用弹窗方式来展示提示信息和订单服务信息以外，还可以采用其他的方式同时输出提示信息和订单服务信息，以便于服务请求方能够更加清晰的了解到展示提示信息和订单服务信息。具体的，比如服务请求方可以采用以下提示方式中的至少一种来输出提示信息：震动形式、语音形式。服务请求方可以采用以下提示方式中的至少一种来输出订单服务信息：震动形式、语音形式。其中，语音形式的提示信息如：服务请求方自动播放“订单价格过高”、“出行距离过远”、“服务等待时长过长”的语音，以对服务请求方进行提示。震动形式的提示信息如：服务请求方可以在接收到携带有提示信息的弹窗信息，或接收到携带有订单服务信息的发单页面信息后，持续的进行振动，直至服务请求方通过操作发单页面完成生成/下达服务订单的操作才停止振动，或者是在服务请求方更改了服务请求信息后，停止振动。此处，更改服务请求信息的行为可以是服务请求方通过操作服务请求方重新输入了服务请求信息，也可以是服务请求方通过操作服务请求方重新向服务器发起了服务请求信息。除了增加震动形式、语音形式的输出方式以外，还可以通过在提示信息中携带上更多便于服务请求方进行操作的信息。具体的，提示信息中包括以下信息中的至少一种：提示服务请求方确认出行起点和出行终点的信息；存在异常的订单服务信息；选择继续发单的按钮；选择返回修改服务请求信息的按钮。其中，提示服务请求方确认出行起点和出行终点的信息可以是以指定的方式输出出行起点和出行终点，并显示确认按钮，如果服务请求方按下了确认按钮，则停止输出出行起点和出行终点。此处，指定的输出方式有以下提示方式中的至少一种：文字形式、震动形式、语音形式、浮动窗口形式。具体的，文字形式的提示信息如：服务请求方在的当前显示界面(如可以是发单页面)上显示“出行起点为服务请求方服务请求方服务请求方；出行终点为bbb”的文字内容，以对服务请求方进行提示。震动形式的提示信息如：服务请求方可以持续的进行振动，直至服务请求方按下了确认按钮。语音形式的提示信息如：服务请求方自动播放类似“出行起点为服务请求方服务请求方服务请求方；出行终点为bbb，请确认地点”的语音，以对服务请求方进行提示。浮动窗口形式的提示信息如：服务请求方在当前界面上，显示浮动窗口，并在浮动窗口中以文字或图片、动画的形式展示出行起点和出行终点的具体内容。此处的确认按钮有多种形式，具体可以分为两种形式，第一种形式是，确认按钮是用来让服务请求方停止输出出行起点和出行终点的；第二种形式是确认按钮是用来驱动服务请求方生成/下达服务订单的。其中，存在异常的订单服务信息可以是不输入具体的出行起点和出行终点，而只是由服务请求方输出了“当前可能存在异常行为”(存在异常的订单服务信息的一种具体表达形式)的信息，这种在提示信息中携带存在异常的订单服务信息的方式，一定程度上能够保护服务请求方的隐私。具体的输出存在异常的订单服务信息的方式可以是以下提示方式中的至少一种：文字形式、震动形式、语音形式、浮动窗口形式。其中，选择继续发单的按钮可以是一种具体的按钮，如前文中介绍提示服务请求方确认出行起点和出行终点的信息中，所提到的确认按钮就是可以是选择继续发单的按钮。如果只在提示信息中携带选择继续发单的按钮，则服务请求方可以不输出出行起点和出行终点的具体信息，而只是显示一个按钮，如果服务请求方按下了该按钮，则服务请求方可以直接依据服务请求信息生成/下达服务订单。与选择继续发单的按钮相对应的，选择返回修改服务请求信息的按钮的作用是，在服务请求方按下了选择返回修改服务请求信息的按钮后，就表示服务请求方期望对s101中的服务请求信息进行修改，此时，应当重新显示让服务请求方输入服务请求信息的界面，以便于服务请求方进行输入。具体实现时，除了出行起点和出行终点可以影响出订单服务信息，服务方式也会影响订单服务信息。进而，s102可以按照如下方式实现：基于服务请求信息，确定多种服务方式中每种服务方式对应的订单服务信息。其中，服务方式有多种，比如拼车车辆服务、专车服务、快车服务、出租车服务、顺风车服务等。最直接的，不同服务方式所对应的服务订单信息是有差别的。比如，每种服务类型所对应环境条件均相同的情况下，拼车车辆的上车等待时间相对于专车的上车等待时间而言，是较慢的，主要是拼车车辆通常需要先接到一定数量的其他服务请求方之后，才会来接服务请求方的使用者；而专车则是直接来接服务请求方的使用者。又比如，出租车的上车等待时间相对于快车的上车等待时间而言，是较慢的，主要是出租车可能会运载路边招手的服务请求方，出租车服务提供方很可能在没有运送完路边招手的服务请求方后，就承接了出行订单，此时，出租车服务提供方只能先将路边招手的服务请求方运送到目的地后，才能来接下达出行订单的服务请求方，而快车则通常不会发生此类问题。当每种服务类型所对应环境条件均不相同的情况下(大多数情况下，每种服务类型所对应环境条件均不相同的，比如在服务请求方区域内，快车的数量远大于专车的数量，则在服务请求方区域内呼叫快车的上车等待时间要比呼叫专车的上车等待时间更短)，则每种服务类型所对应的上车等待时间通常是不相同的。又比如，每种服务类型所对应环境条件均相同的情况下，拼车车辆的订单价格相对于专车的订单价格而言，是较低的，主要是拼车车辆是由拼车的多个服务请求方共同承担车费；而专车则是由唯一的一个服务请求方承担车费。又比如，出租车的订单价格相对于专车的订单价格而言，是较低的，主要是出租车的购车价格比专车的购车价格更低，购车价格在折算到订单价格中之后，专车的订单价格就要高于出租车的订单价格了。又比如，每种服务类型所对应环境条件均相同的情况下，拼车车辆的出行距离(从出行起点到达出行终点的距离)是较长的，主要是拼车车辆在运行的时候，需要分别在不同的地点接到不同的乘客，之后才能前往目的地；而专车车辆在运行的时候，只需要在一个地点接到乘客，之后，就可以直接向目的地进发。又比如，每种服务类型所对应环境条件均相同的情况下，拼车车辆的服务等待时间是较长的，主要是拼车车辆在运行的时候，可能需要先在其他地点接到乘客后，才能接自己；而专车车辆在运行的时候，只需要接到自己后，就可以直接向目的地进发。在此基础上，服务方式可以是由服务请求方主动选择的，进而向服务请求方发送提示信息的时候，就可以根据服务请求方的选择情况，将服务请求方所选择的服务方式所对应的提示信息，以提高提示的准确程度。也就是，本申请所提供的方法中，若订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息，包括：获取服务请求方从多种服务方式中选择的一种服务方式；若在服务请求方选择的一种服务方式下的订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息。其中，服务请求方选择的服务方式有两种来源，下面分别进行说明：第一种服务请求方选择的服务方式的来源：服务请求方选择的服务方式是服务请求方自行上传的。比如服务请求方可以通过操作服务请求方向服务器发送过服务方式，并说明该服务方式是自己的常用服务方式，进而服务器可以将服务请求方所发送的服务方式作为服务请求方选择的服务方式。此处，服务请求方自行上传的时机有两个，一个是服务请求方在本申请所提供的方法执行前，就预先将自己的常用服务方式上传到服务器中了。另一个是服务请求方在本申请所提供的方法执行时临时上传的，比如可以是服务请求方在发送服务请求信息的同时上传服务方式的，又或者是在其他步骤执行时上传的。第二种服务请求方选择的服务方式的来源：服务器根据服务请求方的服务习惯确定的(比如，服务请求方使用服务请求方来下达服务订单的时候，经常选择某种/某些种服务类型，则这个/些经常选择的服务类型就可以作为服务请求方选择的服务方式)。如下表1所示，示出了在服务器中预存服务请求方和服务类型对应关系的一种形式：表1通过表1中可以看出，每个服务请求方都对应了一个服务类型，进而，在向服务请求方发送提示信息的时候，就可以先判断服务请求方所对应(选择)的服务方式是否符合预设服务信息范围，如果不符合，就向服务请求方发送提示信息。具体而言，每种服务方式所对应的预设服务信息范围也可以是有一定差别的。比如拼车的服务等待时间范围(预设服务信息范围的一种)就应当比专车的服务等待时间范围(预设服务信息范围的一种)更大一些。具体实现时，还可以是更有针对性的进行提示，也就是，每种服务订单信息所对应的提示方式不同，在提示的时候，可以是按照对应的提示方式，只将不符合预设服务信息范围的订单服务信息进行展示。也就是，本申请所提供的方法中，步骤s103还可以按照如下方式实现：若至少一种服务方式所对应的订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息；提示信息中携带有不符合预设服务信息范围的订单服务信息的所对应的提示方式，以使服务请求方按照提示方式展示不符合预设服务信息范围的订单服务信息。其中，提示方式有弹窗形式、震动形式和语音形式这几种形式在前文中均已经具体说明过，此处不再重复说明。在实现时，服务中可以预存有每种订单服务信息所对应的提示方式，而后，在执行该步骤的时候，就可以直接调用提示方式了。此处预设服务信息范围可以是系统预定的，也就是，预设服务信息范围针对不同的服务请求方而言，均是相同的，还可以是，预设服务信息范围是根据服务请求方的历史服务信息进行调整，比如，可以是根据服务请求方的历史服务信息来确定预设服务信息范围。具体而言，如服务请求方在经常下达的服务订单的订单价格为100元，则可以确认预设服务信息范围为90-110元；如服务请求方在经常下达的服务订单的出行距离为15-17公里，则可以确认预设服务信息范围为14-18公里。类似的，还可以根据服务请求方的身份信息来确定预设服务信息范围。这主要是考虑到不同身份的服务请求方的出行习惯不同，比如，经常出差去机场的服务请求方，其出行距离和订单价格必然都很高，如果是一般的上班族，则出行距离和订单价格通常相对较低。因此，在实现时，可以是先调取服务请求方的身份信息，而后，根据服务请求方的身份信息，确定预设服务信息范围。在上述两种方式的基础上，还可以是将服务请求方的历史服务信息和身份信息进行结合来更加精准的确定预设服务信息范围。具体实现时可以是分别根据服务请求方的历史服务信息和身份信息分别确定第一服务信息范围，而后，采用加权计算的方式根据两个第一服务信息范围计算预设服务信息范围。也可以是将历史服务信息认为是一个比例系数，以及将身份信息也认为是一个比例系数，而后，将统一的第二服务信息范围(每个服务请求方的第二服务信息范围都是相同的)同时与这两个比例系数进行计算，以求得预设服务信息范围。前文中已经介绍了在服务请求方发送服务请求信息后，如何对对服务请求方进行提示，以辅助服务请求方对服务请求信息进行确认或修改的方案。也说明了订单服务信息包括以下信息中的至少一种：订单价格、出行距离、出行时间和服务等待时长。下面，分别对这几种订单服务信息的获得过程进行说明：首先对服务等待时长的计算过程进行说明：计算(预估)服务等待时间的方式有很多种，下面仅列举三种：第一种，先预估出如果服务请求方以当前的上车起点(服务请求信息中携带的出行起点)作为服务订单中的出行起点的话，哪个服务提供方接受该服务订单的概率最高，而后，再根据接受该服务订单的概率最高的服务提供方(目标服务提供方)的当前位置和出行起点的位置，计算目标服务提供方从其当前位置达到出行起点所需要的时间，并将该时间作为服务等待时间；第二种，分别预估出距离出行起点距离较近的服务提供方中，每个服务提供方从其当前位置到达出行起点的时间(目标时间)，并将这多个目标时间采用加权求平均的方式计算出服务等待时间。上述这两种预估服务等待时间的方式仅仅是示例性质的，并不代表本申请所提供的方案所期望保护的范围只有这两种。第三种，根据当前服务能力信息以及预先训练的服务等待时间预测模型，得到服务等待时间。与第一种、第二种计算服务等待时间的方式不同的是，第三种计算服务等待时间的方式使用了已经训练好的服务等待时间预测模型进行预测，这主要是考虑到影响服务等待时间的要素比较多，如果单纯的通过人为分析会比较困难，因此，本申请所提供的方法中引入了使用模型进行预测的方式。此处，本申请所提供的方法中，优选按照如下方式计算服务等待时间：根据当前服务能力，确定上车等待时间。此处，首先介绍一下当前服务能力，当前服务能力可以由以下几种要素中的任意一种或多种要素构成：第一种构成当前服务能力的要素：当前竞争排队的服务请求方数量；第二种构成当前服务能力的要素：预定时间内在与出行起点的距离在设定距离范围内的地点完成服务订单的服务提供方数量；第三种构成当前服务能力的要素：当前在与出行起点的距离在设定距离范围内的地点处于空闲状态的服务提供方数量。其中，当前竞争排队的服务请求方，是指已经下达服务订单，并且下达的服务订单中的出行起点与步骤s101中服务请求信息中所携带的出行起点足够近的服务请求方所使用的服务请求方。进而，竞争排队的服务请求方具体指的是正处在呼叫网约车过程(已经向服务器下达服务订单，但该服务订单还未被分配给某个服务提供方的过程中)的服务请求方中，距离服务请求信息中的出行起点符合预设要求(如距离足够近)的地点作为出行起点(下达的服务订单中的出行起点)的服务请求方。预定时间内在与出行起点的距离在设定距离范围内的地点完成服务订单的服务提供方数量中，服务提供方指的是由服务提供方做使用的终端，该服务提供方与服务请求方是相对应的，服务请求方是期望由接受网约车服务的服务请求方所使用的终端，服务提供方是由期望提供网约车服务的服务请求方所使用的终端。完成服务订单的服务提供方数量指的是将服务请求方运载到目的地的服务提供方的数量。换句话说，该数量就是：即将在距离服务请求信息中的出行起点较近的位置完成服务订单的服务提供方的数量。当前在与出行起点的距离在设定距离范围内的地点处于空闲状态的服务提供方数量，指的是当前处于空驶状态，或者是未处于正在完成服务订单状态的服务提供方的数量。更准确来说，该当前在与出行起点的距离在设定距离范围内的地点处于空闲状态的服务提供方数量，应当是指既处于空驶状态(服务提供方可以通过向服务器上报自己是否在运送服务请求方来说明自己是否处于空驶状态)，也未处于正在完成服务订单状态的服务提供方的数量。由于服务订单是由服务器向服务提供方分配的，因此服务器必然知晓服务提供方是否被分配了服务订单，在服务订单被完成之后，服务提供方或服务请求方会向服务器发送反馈消息，以说明已分配的服务订单是否被完成。其次，再对出行时间的计算过程进行说明：如前文中的说明，出行时间分为两种情况，分别是服务请求方从当前位置移动到出行起点的时间和从出行起点到达出行终点的时间。服务请求方从当前位置移动到出行起点的时间在计算时，首先要生成从服务请求方的当前位置移动到出行起点的第一导航路线，之后，再根据该第一导航路线计算第一出行距离，而后，再根据第一出行距离计算第一出行时间(服务请求方从当前位置移动到出行起点的时间)。类似的，服务请求方从出行起点到达出行终点的时间在计算时，首先要生成从服务请求方的出行起点移动到出行终点的第二导航路线，之后，再根据该第二导航路线计算第二出行距离，而后，再根据第二出行距离计算第二出行时间(服务请求方从从出行起点到达出行终点的时间)。再次，再对出行距离的计算过程进行说明：如前文中的说明，出行距离分为两种情况，分别是服务请求方从当前位置移动到出行起点的出行距离和从出行起点到达出行终点的出行距离。服务请求方从当前位置移动到出行起点的时间在计算时，首先要生成从服务请求方的当前位置移动到出行起点的第一导航路线，之后，再计算该第一导航路线的第一出行距离(服务请求方从当前位置移动到出行起点的出行距离)。类似的，服务请求方从从出行起点到达出行终点的时间在计算时，首先要生成从服务请求方的出行起点移动到出行终点的第二导航路线，之后，再计算该第二导航路线的第二出行距离(从出行起点到达出行终点的出行距离)。最后，再对订单价格的计算过程进行说明：首先要生成从服务请求方的出行起点移动到出行终点的第二导航路线，之后，再计算该第二导航路线的第二出行距离，之后，再根据第二出行距离和预定的价格计算方式，计算订单价格。此处，预定的价格计算方式可以是每公里xxx元，进而，根据第二出行距离和预定的价格计算方式就能计算出订单价格。进一步，在计算订单服务信息的时候，可以根据服务方式所对应的计算方式，计算订单服务信息。比如，在计算出行距离的时候，可以根据服务方式所对应的计算方式来计算出行距离。具体的，比如拼车服务，在知晓出行起点和出行终点之后，由于服务提供方还需要运载其他乘客，因此，在出行起点和出行终点完全相同的情况下，拼车服务所对应的出行距离通常是远于专车服务所对应的出行距离。进而，在计算某种服务方式所对应的出行距离的时候，首先要确定服务方式所对应的距离计算方式，而后，在计算出行距离的时候，就可以按照如下方式计算：根据服务请求方选择的一种服务方式所对应的计算方式，计算出行距离(订单服务信息中的一种)。具体的，服务请求方选择的一种服务方式的含义在前文中已经进行了解释，此处不在重复说明。具体的，根据第二出行距离和预定的价格计算方式，计算订单价格的过程，可以按照如下方式执行：根据第二出行距离，以及指定的服务方式和价格计算方式的对应关系，计算订单价格。如下表2所示，示出了指定的服务方式和价格计算方式的对应关系：表2编号服务方式价格计算方式1拼车3元/公里2出租车4元/公里3快车5元/公里4专车6元/公里可看出每种服务方式所对应的价格是有差别的，进而，在确定了第二出行距离和服务方式和价格的对应关系之后，就能够计算出第二出行距离所对应的订单价格。在计算服务请求方从当前位置移动到出行起点的出行距离的时候，可以根据服务请求方的出行方式所对应的计算方式来计算出行距离。比如，可以按照如下方式计算服务请求方从当前位置移动到出行起点的出行距离：根据服务请求方的定位位置、服务起点位置和指定的至少一种出行方式，确定与每种出行方式对应的导航路线；根据确定的与指定的出行方式对应的导航路线，确定在指定的出行方式下服务请求方从当前位置移动到出行起点的出行距离。此处，出行方式包括：步行、自行车出行、电动车出行、机动车出行。可以预想到的是，不同的出行方式所对应的计算导航路线的策略是不同的，比如，步行可以走小路，但机动车出行则只能走大路，也就是，不同的出行方式所对应的导航路线可能是有差别的。此处，指定的出行方式可以是服务请求方选择的，也可以是服务器根据服务请求方经常采用的出行方式来确定的。类似的，在计算服务请求方从当前位置移动到出行起点的时间时，也可以按照上述方式进行计算。也就是，服务请求方从当前位置移动到出行起点的时间的具体过程可以如下：可以按照如下方式计算服务请求方从当前位置移动到出行起点的出行距离：根据服务请求方的定位位置、服务起点位置和指定的至少一种出行方式，确定与每种出行方式对应的导航路线；根据确定的与指定的出行方式对应的导航路线，确定在指定的出行方式下服务请求方从当前位置移动到出行起点的时间。也就是，每种出行方式所对应的运动速度也是不相同的，比如，上述几种出行方式中，步行最慢、自行车少块，电动车更快，机动车最快。进而，在计算时间时，除了距离的远近，还需要考虑运动速度，以达到更加精准的计算。如图5所示，示出了是本申请一些实施例的信息提示方法所在的服务系统100的框图。例如，服务系统100可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。服务系统100可以包括服务器110(本申请所提供方法的执行主体的一种)、网络120、服务请求方终端130(服务请求方)、服务提供方终端140(服务提供方)和数据库150中的一种或多种，服务器110中可以包括执行指令操作的处理器。在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式系统)。在一些实施例中，服务器110相对于终端，可以是本地的、也可以是远程的。例如，服务器110可以经由网络120访问存储在服务请求方终端130、服务提供方终端140、或数据库150、或其任意组合中的信息和/或数据。作为另一示例，服务器110可以直接连接到服务请求方终端130、服务提供方终端140和数据库150中至少一个，以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实现；仅作为示例，云平台可以包括私有云、公有云、混合云、社区云(communitycloud)、分布式云、跨云(inter-cloud)、多云(multi-cloud)等，或者它们的任意组合。在一些实施例中，服务器110可以在具有本申请中图4所示的一个或多个组件的电子设备1000上实现。网络120可以用于信息和/或数据的交换。在一些实施例中，服务系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140和数据库150)可以向其他组件发送信息和/或数据。例如，服务器110可以经由网络120从服务请求方终端130获取服务请求。在一些实施例中，网络120可以是任何类型的有线或者无线网络，或者是他们的结合。仅作为示例，网络130可以包括有线网络、无线网络、光纤网络、远程通信网络、内联网、因特网、局域网(localareanetwork，lan)、广域网(wideareanetwork，wan)、无线局域网(wirelesslocalareanetworks，wlan)、城域网(metropolitanareanetwork，man)、广域网(wideareanetwork，wan)、公共电话交换网(publicswitchedtelephonenetwork，pstn)、蓝牙网络、zigbee网络、或近场通信(nearfieldcommunication,nfc)网络等，或其任意组合。在一些实施例中，网络120可以包括一个或多个网络接入点。例如，网络120可以包括有线或无线网络接入点，例如基站和/或网络交换节点，服务系统100的一个或多个组件可以通过该接入点连接到网络120以交换数据和/或信息。在一些实施例中，服务请求方终端130的服务请求方可以是除服务实际需求者之外的其他人。例如，服务请求方终端130的服务请求方a可以使用服务请求方终端130来为服务实际需求者b发起服务请求(比如，服务请求方a可以为自己的朋友b叫车)，或者从服务器110接收服务信息或指令等。在一些实施例中，服务提供方终端140的服务请求方可以是服务实际提供者，也可以是除服务实际提供者之外的其他人。例如，服务提供方终端140的服务请求方c可以使用服务提供方终端140接收由服务实际提供者d提供服务的服务请求(比如服务请求方c可以为自己雇用的服务提供方d接单)，和/或来自服务器110的信息或指令。在一些实施例中，“服务请求方”和“服务请求方终端”可以互换使用，“服务提供方”和“服务提供方终端”可以互换使用。在一些实施例中，服务请求方终端130可以包括移动设备、平板计算机、膝上型计算机、或机动车辆中的内置设备等，或其任意组合。在一些实施例中，移动设备可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器设备的控制设备、智能监控设备、智能电视、智能摄像机、或对讲机等，或其任意组合。在一些实施例中，可穿戴设备可包括智能手环、智能鞋带、智能玻璃、智能头盔、智能手表、智能服装、智能背包、智能配件等、或其任何组合。在一些实施例中，智能移动设备可以包括智能手机、个人数字助理(personaldigitalassistant，pda)、游戏设备、导航设备、或销售点(pointofsale，pos)设备等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实玻璃、虚拟现实贴片、增强现实头盔、增强现实玻璃、或增强现实贴片等，或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括各种虚拟现实产品等。在一些实施例中，机动车辆中的内置设备可以包括车载计算机、车载电视等。在一些实施例中，服务请求方终端130可以是具有用于定位服务请求方和/或服务请求方终端的位置的定位技术的设备。在一些实施例中，服务提供方终端140可以是与服务请求方终端130类似或相同的设备。在一些实施例中，服务提供方终端140可以是具有定位技术的设备，用于定位服务提供方和/或服务提供方终端的位置。在一些实施例中，服务请求方终端130和/或服务提供方终端140可以与其他定位设备通信以确定服务请求方、服务请求方终端130、服务提供方、或服务提供方终端140、或其任意组合的位置。在一些实施例中，服务请求方终端130和/或服务提供方终端140可以将定位信息发送给服务器110。数据库150可以存储数据和/或指令。在一些实施例中，数据库150可以存储从服务请求方终端130和/或服务提供方终端140获得的数据。在一些实施例中，数据库150可以存储在本申请中描述的示例性方法的数据和/或指令。在一些实施例中，数据库150可以包括大容量存储器、可移动存储器、易失性读写存储器、或只读存储器(read-onlymemory,rom)等，或其任意组合。作为举例，大容量存储器可以包括磁盘、光盘、固态驱动器等；可移动存储器可包括闪存驱动器、软盘、光盘、存储卡、zip磁盘、磁带等；易失性读写存储器可以包括随机存取存储器(randomaccessmemory,ram)；ram可以包括动态ram(dynamicrandomaccessmemory,dram)，双倍数据速率同步动态ram(doubledate-ratesynchronousram,ddrsdram)；静态ram(staticrandom-accessmemory,sram)，晶闸管ram(thyristor-basedrandomaccessmemory,t-ram)和零电容器ram(zero-ram)等。作为举例，rom可以包括掩模rom(maskread-onlymemory,mrom)、可编程rom(programmableread-onlymemory,prom)、可擦除可编程rom(programmableerasableread-onlymemory,perom)、电可擦除可编程rom(electricallyerasableprogrammablereadonlymemory,eeprom)、光盘rom(cd-rom)、以及数字通用磁盘rom等。在一些实施例中，数据库150可以在云平台上实现。仅作为示例，云平台可以包括私有云、公有云、混合云、社区云、分布式云、跨云、多云或者其它类似的等，或其任意组合。与上述方法相对应的，本申请还提供了一种信息提示装置，该装置包括：第一获取模块，用于获取服务请求方发送的服务请求信息；第一确定模块，用于基于服务请求信息，确定订单服务信息；第一发送模块，若订单服务信息不符合预设服务信息范围，则用于向服务请求方发送提示信息，提示信息用于提示服务请求方确认是否需要对服务请求信息进行修改。在某种实施方式中，还包括：第二发送模块，若订单服务信息不符合预设服务信息范围，则用于向服务请求方发送订单服务信息。在某种实施方式中，第二发送模块，包括：第一发送单元，用于向服务请求方发送携带有订单服务信息的发单页面信息；第一发送模块，包括：第二发送单元，用于向服务请求方发送携带有提示信息的弹窗信息，以便在服务请求方的发单页面上通过弹窗方式展示提示信息。在某种实施方式中，订单服务信息包括以下信息中的至少一种：订单价格、出行距离、出行时间和服务等待时长。在某种实施方式中，订单服务信息不符合预设服务信息范围包括以下情况中的一种或多种：订单价格超过设定价格阈值；出行距离超过设定距离阈值；出行时间超过设定时长；服务等待时长超过设定时长。在某种实施方式中，提示信息中包括以下信息中的至少一种：提示服务请求方确认出行起点和出行终点的信息；存在异常的订单服务信息；选择继续发单的按钮；选择返回修改服务请求信息的按钮。在某种实施方式中，第一确定模块，包括：第一确定单元，用于基于服务请求信息，确定多种服务方式中每种服务方式对应的订单服务信息。在某种实施方式中，第一发送模块，包括：第一获取单元，用于获取服务请求方从多种服务方式中选择的一种服务方式；第三发送单元，若在服务请求方选择的一种服务方式下的订单服务信息不符合预设服务信息范围，则用于向服务请求方发送提示信息。在某种实施方式中，第一发送模块，包括：第四发送单元，若至少一种服务方式所对应的订单服务信息不符合预设服务信息范围，则用于向服务请求方发送提示信息；提示信息中携带有不符合预设服务信息范围的订单服务信息的所对应的提示方式，以使服务请求方按照提示方式展示不符合预设服务信息范围的订单服务信息。在某种实施方式中，预设服务信息范围是通过如下模块确定的：第二获取模块，用于获取服务请求方的历史服务信息；第二确定模块，用于根据服务请求方的历史服务信息，确定预设服务信息范围。在某种实施方式中，服务方式包括：出租车服务、代驾服务服务、快车服务、拼车服务、公共汽车服务服务、驾驶员租赁服务和班车服务。与上述方法相对应的，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如信息提示方法的步骤。如图4所示，为本申请实施例所提供的电子设备示意图，该电子设备1000包括：处理器1001、存储器1002和总线1003，存储器1002存储有执行指令，当电子设备运行时，处理器1001与存储器1002之间通过总线1003通信，处理器1001执行存储器1002中存储的信息提示方法的步骤。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本
技术领域：
的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。当前第1页1 2 3
技术特征：1.一种信息提示方法，其特征在于，该方法包括：
获取服务请求方发送的服务请求信息；
基于所述服务请求信息，确定订单服务信息；
若所述订单服务信息不符合预设服务信息范围，则向所述服务请求方发送提示信息，所述提示信息用于提示所述服务请求方确认是否需要对所述服务请求信息进行修改。
2.如权利要求1所述的方法，其特征在于，在基于所述服务请求信息，确定订单服务信息之后，还包括：
若所述订单服务信息不符合预设服务信息范围，则向所述服务请求方发送所述订单服务信息。
3.如权利要求2所述的方法，其特征在于，向所述服务请求方发送所述订单服务信息，包括：
向所述服务请求方发送携带有所述订单服务信息的发单页面信息；
所述向所述服务请求方发送提示信息，包括：
向所述服务请求方发送携带有所述提示信息的弹窗信息，以便在所述服务请求方的发单页面上通过弹窗方式展示所述提示信息。
4.如权利要求1所述的方法，其特征在于，所述订单服务信息包括以下信息中的至少一种：
订单价格、出行距离、出行时间和服务等待时长。
5.如权利要求4所述的方法，其特征在于，所述订单服务信息不符合预设服务信息范围包括以下情况中的一种或多种：
订单价格超过设定价格阈值；出行距离超过设定距离阈值；出行时间超过设定时长；服务等待时长超过设定时长。
6.如权利要求1所述的方法，其特征在于，所述提示信息中包括以下信息中的至少一种：
提示服务请求方确认出行起点和出行终点的信息；存在异常的订单服务信息；选择继续发单的按钮；选择返回修改服务请求信息的按钮。
7.如权利要求1所述的方法，其特征在于，基于所述服务请求信息，确定订单服务信息，包括：
基于所述服务请求信息，确定多种服务方式中每种服务方式对应的订单服务信息。
8.如权利要求7所述的方法，其特征在于，若所述订单服务信息不符合预设服务信息范围，则向所述服务请求方发送提示信息，包括：
获取服务请求方从所述多种服务方式中选择的一种服务方式；
若在服务请求方选择的一种服务方式下的所述订单服务信息不符合预设服务信息范围，则向所述服务请求方发送提示信息。
9.如权利要求7所述的方法，其特征在于，若所述订单服务信息不符合预设服务信息范围，则向所述服务请求方发送提示信息，包括：
若至少一种服务方式所对应的订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息；所述提示信息中携带有不符合预设服务信息范围的订单服务信息的所对应的提示方式，以使服务请求方按照所述提示方式展示不符合预设服务信息范围的订单服务信息。
10.根据权利要求7-9任一项所述的方法，其特征在于，预设服务信息范围是通过如下步骤确定的：
获取服务请求方的历史服务信息和服务请求方的身份信息；
根据服务请求方的历史服务信息和身份信息，确定预设服务信息范围。
11.根据权利要求7-9任一项所述的方法，其特征在于，
所述服务方式包括：
出租车服务、代驾服务服务、快车服务、拼车服务、公共汽车服务服务、驾驶员租赁服务和班车服务。
12.一种信息提示装置，其特征在于，该装置包括：
第一获取模块，用于获取服务请求方发送的服务请求信息；
第一确定模块，用于基于所述服务请求信息，确定订单服务信息；
第一发送模块，若所述订单服务信息不符合预设服务信息范围，则用于向所述服务请求方发送提示信息，所述提示信息用于提示所述服务请求方确认是否需要对所述服务请求信息进行修改。
13.如权利要求12所述的装置，其特征在于，还包括：
第二发送模块，若所述订单服务信息不符合预设服务信息范围，则用于向所述服务请求方发送所述订单服务信息。
14.如权利要求13所述的装置，其特征在于，第二发送模块，包括：
第一发送单元，用于向所述服务请求方发送携带有所述订单服务信息的发单页面信息；
第一发送模块，包括：
第二发送单元，用于向所述服务请求方发送携带有所述提示信息的弹窗信息，以便在所述服务请求方的发单页面上通过弹窗方式展示所述提示信息。
15.如权利要求12所述的装置，其特征在于，所述订单服务信息包括以下信息中的至少一种：
订单价格、出行距离、出行时间和服务等待时长。
16.如权利要求15所述的装置，其特征在于，所述订单服务信息不符合预设服务信息范围包括以下情况中的一种或多种：
订单价格超过设定价格阈值；出行距离超过设定距离阈值；出行时间超过设定时长；服务等待时长超过设定时长。
17.如权利要求12所述的装置，其特征在于，所述提示信息中包括以下信息中的至少一种：
提示服务请求方确认出行起点和出行终点的信息；存在异常的订单服务信息；选择继续发单的按钮；选择返回修改服务请求信息的按钮。
18.如权利要求12所述的装置，其特征在于，第一确定模块，包括：
第一确定单元，用于基于所述服务请求信息，确定多种服务方式中每种服务方式对应的订单服务信息。
19.如权利要求18所述的装置，其特征在于，第一发送模块，包括：
第一获取单元，用于获取服务请求方从所述多种服务方式中选择的一种服务方式；
第三发送单元，若在服务请求方选择的一种服务方式下的所述订单服务信息不符合预设服务信息范围，则用于向所述服务请求方发送提示信息。
20.如权利要求18所述的装置，其特征在于，第一发送模块，包括：
第四发送单元，若至少一种服务方式所对应的订单服务信息不符合预设服务信息范围，则用于向服务请求方发送提示信息；所述提示信息中携带有不符合预设服务信息范围的订单服务信息的所对应的提示方式，以使服务请求方按照所述提示方式展示不符合预设服务信息范围的订单服务信息。
21.根据权利要求18-20任一项所述的装置，其特征在于，预设服务信息范围是通过如下模块确定的：
第二获取模块，用于获取服务请求方的历史服务信息；
第二确定模块，用于根据服务请求方的历史服务信息，确定预设服务信息范围。
22.根据权利要求18-20任一项所述的装置，其特征在于，
所述服务方式包括：
出租车服务、代驾服务服务、快车服务、拼车服务、公共汽车服务服务、驾驶员租赁服务和班车服务。
23.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行时执行如权利要求1至11任一所述的信息提示方法的步骤。
24.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至11任一所述的信息提示方法的步骤。
技术总结本申请提供了信息提示方法、装置、电子设备和存储介质，涉及服务领域。本申请提供的信息提示方法，首先获取了服务请求方发送的服务请求信息；而后，基于服务请求信息，确定了具体的订单服务信息；最后，如果订单服务信息不符合预设服务信息范围，则向服务请求方发送提示信息，提示信息用于提示服务请求方确认是否需要对服务请求信息进行修改。这种处理方式，使得服务请求方能够及时的对自己所发出的服务请求信息进行修改，以提高服务请求方操作的准确度。
技术研发人员：王翔;陈子腾;罗鸿苍
受保护的技术使用者：北京嘀嘀无限科技发展有限公司
技术研发日：2018.11.29
技术公布日：2020.06.05
