红灯停表之后，外卖平台还要从哪里抢时间？

本文来自微信公众号： 防冷涂的腊 ，作者：防冷涂的腊

8月7日上午，北京国贸商圈。59岁的外卖骑手刘德平取到两单咖啡，目的地在2.7公里外。途中3个路口，他连续遇到3次红灯。过去，为了不让配送倒计时继续消耗，他会拐进侧路绕行，或者瞄着车流抢过去。这一次，手机开始记录等灯时长。两单送完，累计4分多钟的红灯等待被从考核时长中剔除。

按直觉，这4分钟总要以另一种方式补回来：用户多等一点，骑手少送一点，或者平台承担更高的履约成本。但苏州试点上线两周后，美团披露，订单平均补时约2分钟，骑手闯红灯率持续改善，多数消费者体验没有明显变化，部分骑手接单量反而提高。这些数据还不足以证明整体效率提升，却至少说明一个重要事实：给骑手更多安全时间，并不必然等于平台降低效率。

8月17日，无锡将“红灯停表”扩展到全市4253个信号灯路口；北京也将在9月于朝阳、通州、经开区部分区域组织三家平台试运行。一个原本只涉及几十秒等待的产品功能，正在变成外卖行业共同调整的计时规则。

问题随之变成：这两分钟最后去了哪里？它可能成为骑手的安全余量，也可能通过合单、路径和调度重新变成系统效率；消费者端的等待时间，也未必同步增加。

红灯早就在算法里，为什么还要“停表”？

外卖配送时间早已不是“距离除以统一骑行速度”这么简单。美团技术团队2018年披露，系统需要预测骑手接单、到店、取餐、送达，商家出餐和用户交付等多个环节；平面骑行、上下楼、出餐还会分别建模。饿了么公开的模型也把天气、交通、路线、商家备餐、供需状态和骑手负载纳入特征。

历史订单本身就经历红灯、拥堵和正常骑行，这些时间会进入模型训练。美团2025年公开的规则还显示，系统会在模型时间之外叠加多层保护，并对红绿灯、恶劣天气、商家卡餐和难配送小区补时。美团在今年8月的骑手恳谈会上表示，从2022年开始，预估配送时间已经加入红灯和复杂路况的时间估算。

过去的平台并非不知道路上有红灯。它解决的是一条路、一个区域、一类订单在通常情况下需要多久，红灯主要通过历史数据、模型特征和规则补时进入ETA。

实时“红灯停表”增加的是另一层能力。平台接入交管部门的灯态数据，再结合骑手位置、轨迹和订单状态，识别骑手是不是正在这一盏红灯前等待。无锡公开的信息显示，信号数据时延稳定在1秒以内；骑手停车后计时暂停，绿灯恢复后继续。

假设模型给一个路口预留40秒，某位骑手当天实际等了100秒。平均值足以支撑大规模调度，但多出来的60秒仍然会落到这一单上。实时识别把这段误差从骑手身上拆出来。

红灯停表重新分配的并不是红灯时间本身，而是预测误差：这部分误差还要不要继续由骑手自己消化。

图1：红灯停表前后的时间处理方式。资料来源：美团算法公开、苏州及无锡试点公开资料。

两分钟还给骑手，平台未必少两分钟效率

补时一上线，骑手很快有新的顾虑。一位接受媒体采访的众包骑手说，现在一趟挂4单，时间宽裕后会不会加到6单、7单；如果任务密度同步提高，遇到出餐慢、拥堵，时间仍然不够。这是个体担忧，却点中了试点之后最值得观察的变化：平台会怎么使用骑手拿回来的时间。

外卖平台算的并不只是骑手时速，而是整套履约效率。同样骑5公里，只送1单和顺路送3单，骑手速度一样，平台的单均效率却完全不同。调度系统会把新订单插入骑手已有任务，计算新增时间和超时风险，再决定由谁配送、按什么顺序取送。饿了么2017年公开的资料已经描述过这套逻辑。

可配送时间变长，会给调度系统留下更多订单组合空间。原本因为时间太紧无法合并的两笔顺路订单，可能变得可以一起配送；同一条路上的重复骑行也会减少。如果合单合理，可能同时出现三种结果：骑手不必提高车速、重复骑行减少、平台单均履约成本下降。

苏州试点里“部分骑手接单量提高”至少说明，补时和订单量增加可以同时发生。但平台尚未披露合单率、平均背单量、骑手单位小时完成订单量（TPH）和单均成本，现有数据还无法判断效率究竟从哪里产生。

真正需要防止的是另一种结果：系统把新增的安全余量重新填满。红灯补回2分钟，调度再把任务密度推高到刚好消耗这2分钟，骑手面对突发情况时依然没有余量。多送一笔真正顺路的订单没有问题，判断标准应该落到结果上：骑手是否又开始加速，时间压力和收入怎么变化，消费者是否准时，平台有没有通过更好的组合降低成本。

试点下一阶段值得公开的，不只是补时时长和闯灯率，还包括平均携带订单量、合单率、TPH、骑手收入、准时率、投诉率和单均履约成本。真正需要观察的是两件事：安全余量有没有保留下来，新增效率究竟来自更好的系统调度，还是来自更高的任务密度。

骑手多两分钟，消费者真的会多等两分钟吗？

外卖页面上看起来只有一个倒计时，履约系统里却不止一只时钟。系统先估算基础时长，再分别形成消费者看到的预计送达时间和骑手最晚送达时限，最后还有实际完成时间，三者不会完全重合。

在实际履约体系中，用户端预计时间与实际送达之间通常会留出一定余量；据公开信息显示，典型差值约为6—8分钟：这个数字能说明一个基本机制：骑手拿回2分钟，不代表让消费者晚2分钟拿到外卖。

平台公开的算法也能印证这种结构。美团在模型预测之外叠加特殊场景补时和三层保护，并从多个候选时间中取最长值；饿了么2025年公开算法时也区分平台期望送达时间与更宽裕的骑手要求送达时间。因此，骑手增加的2分钟并不只有一个去向：保护余量、时间展示、实时调度、出餐协同和路径优化，都可以吸收这部分变化。

“快”依然有价值，尤其在早餐、工作午餐、赶车等场景，几分钟足以影响体验。但速度也有边际。配送从60分钟缩短到40分钟，体验变化很明显；已经进入半小时区间后，再把31分钟压到29分钟，对用户的价值很难继续保持同样的幅度。

这里出现的是用户体验的第二笔账：消费者需要的究竟是再快一两分钟，还是更稳定的送达预期？有人愿意为更快配送付费，有人可以接受晚三五分钟，还有人更在意平台显示30分钟，就尽量在30分钟左右送到。外卖体验不只剩下一个越来越小的分钟数，速度、准时率和可预期性同样重要。

目前公开信息明确了骑手端最晚送达时间会顺延，但没有完整披露消费者端预计时间是否会随每次红灯实时更新。参与试点讨论的专家提出，消费者端预计时间和说明也应同步调整，避免催单和差评把压力重新传回骑手。这决定了“红灯停表”能不能从骑手端规则，真正变成一套完整的用户产品。

算法越懂真实世界，平台越难把超时都算给骑手

北京这次调整的范围远超红灯。三家平台承诺，电动自行车配送按平均时速不超过15公里计算；转单场景适度增加时长；恶劣天气和复杂路况加大补时；商家出餐慢造成的超时不影响骑手服务分；商家列表页避免“分钟级竞速”。

红灯、出餐、天气、路况、转单，看起来是几套不同的规则，背后其实都在回答同一个问题：一笔订单为什么会变慢。

过去，平台最容易管理的是结果——订单有没有超时。现在，系统越来越能还原过程：红灯、出餐、临时管制、小区门禁、电梯和转单分别消耗了多少时间。2025年，美团称已在考核中陆续剔除无电梯小区步行、商家出餐延误、高层电梯等待和偏远小区等耗时；饿了么公开算法也覆盖接单、出餐、取餐和送餐各阶段，并设置异常报备和豁免。

识别能力越细，平台就越难继续用一个“超时”结果把所有责任压给骑手。能控制的效率，可以继续考核骑手；无法控制的时间，应该由系统承担。信号灯、商家、天气、道路、门禁、电梯以及系统自身的预测偏差超出骑手控制范围，就应该由平台在时限、调度和用户承诺中吸收。

这种责任识别本身也能带来效率。知道商家经常晚出餐，可以推迟骑手到店；知道某栋楼电梯等待时间长，可以给后续订单留出空间；知道临时封路，可以提前改道。平台识别得越准确，越能把冗余放到真正需要的订单上，而不是给所有订单统一增加安全垫。

算法能力越强，平台得到的不该只是更精确的管理工具，也应该承担更精确的时间成本和履约责任。

骑手不能再快，效率就要从别处找

过去十多年，外卖平台依靠地图、订单密度、路径规划和智能调度，把配送时间压缩到半小时左右。但骑手速度终究有物理和安全上限，继续从车速里挤时间，能换来的效率越来越少，付出的代价却越来越高。

餐厅、楼宇和订单组合仍然有更大的空间。饿了么与阿里云2017年的公开资料曾称，当时餐厅出餐等待约占送餐时间的三分之一；美团后续技术资料也把出餐、平面骑行和楼内交付列为独立预估对象。从履约链条看，出餐和取送至今仍是占时较高、波动也较大的环节。

下一轮效率可以拆成四个方向：出餐更准、取送更顺、路径更真实、合单更合理。让骑手到店和商家出餐更匹配，把小区门禁、电梯和真实入口做得更准确，减少无效绕路，再通过合理合单和供需调度减少重复骑行。这里每省下一分钟，依靠的是系统对真实世界理解得更深，而不是要求骑手再快一点。

红灯停表拿回的只是几分钟，却把外卖平台推到一条新的分界线上：当骑手不能继续无限加速，平台还能不能靠调度、协同和产品设计继续提高效率？

下一轮外卖真正值得抢的时间，应该从餐厅、路线、楼宇和订单组合里找，而不是继续从骑手的车速里找。