外卖骑手的路线比你写的代码更智能

你打开外卖App，点了一份黄焖鸡米饭。页面弹出一行字：”预计30分钟送达”。

你没多想，继续刷手机。

但你可能没意识到，从你点下”确认下单”的那一刻起，一套比大多数程序员写的代码都要复杂的AI系统已经开始运转了——它在0.1秒内扫描了你附近20个骑手的实时位置、手里各有几单、每单还要多久送完、从餐厅到你家走哪条路能避开三个红灯、甚至预测了那家黄焖鸡的出餐时间（精确到秒级）。

然后，它选了一个”最优”骑手。

这一切发生在你把手机往桌上一放的瞬间。

缩短12分钟的不是骑手的腿

五年前，外卖平均配送时间大概是40分钟。现在，美团的平均时长压到了28分钟左右。

差了12分钟。

这12分钟不是因为骑手骑得更快了——电瓶车的速度限制没变，路上的红灯没减少，楼下的门禁依然要等人开门。缩短这12分钟的，是背后的AI调度系统。

这套系统每天要处理大约1亿次订单分配。每一次分配，本质上都是一个多约束、多目标、高度不确定的优化问题。

翻译成人话就是：同时要考虑几十个互相矛盾的条件，在极短时间内做出一个”还不错”的决定。

一道让数学家也头疼的题

给你出道题：3个骑手，5个订单，每个订单有取餐地点和送餐地点，每个骑手有不同的位置和已有订单量。请给出最优分配方案。

这还只是最简化的版本。加上实时路况、天气、商家出餐速度、骑手电瓶车电量、小区门禁等待时间……变量直接爆炸。

计算机科学里有个概念叫NP-hard——通俗点说，就是”没有已知方法能在合理时间内算出最优解”。如果你尝试穷举所有可能的分配方案来找最优，等你算完，黄焖鸡早凉了，骑手也下班了。

10个骑手配20个订单，排列组合的数量比宇宙中的原子还多。

那怎么办？

美团的工程师们用了一个务实的策略：不求最优，只求”足够好”。

打个比方：你到一个陌生城市找吃的，不可能走遍所有餐厅再选最好那家——你会先看看附近评分高的，挑一家还不错的进去。吃不吃得到”最佳”不确定，但你一定能在饿死之前吃上一顿像样的饭。

美团调度系统用的就是这个思路的数学版本：先快速锁定一个”还行”的方案，然后在剩余时间里不断微调——每调一次好一点，直到0.1秒用完，输出当前最好的那个解。

工程师管这叫近似算法。翻译成大白话：放弃找到最好的，专注找到够好的，然后快。

不只是”谁去取餐”这么简单

你可能觉得外卖调度就是”把订单分给最近的骑手”。

远不止。

想象一个场景：骑手小王手里有3单，正骑车去第一家餐厅。这时候系统发现——那家店出餐比预期慢了4分钟。于是0.3秒内，系统重新算了一遍：让小王先去隔壁200米的另一家取已经做好的单，等他取完回来，第一家正好出锅。同时，另一个骑手小李刚送完一单，距离小王的第三单取餐点只有300米——系统把那单从小王身上卸下来，转给了小李。

这一系列决策全程没有人参与。

这套系统做的事情，更像是自动驾驶——只不过它”驾驶”的不是一辆车，而是同时指挥300万辆车。谁去哪取什么、走什么路、中途顺路接哪一单、出餐慢了怎么调、骑手没电了订单转给谁——所有决定，每隔几秒重新计算一次。

每一秒都有上万个”意外”在发生：堵车、爆单、商家关火重做、骑手手机没信号。系统不能暂停，不能报错重试，只能在混乱中实时给出下一个”还不错”的解。

系统最优，骑手最苦

技术上确实漂亮。但这里有一个让人不舒服的问题。

算法追求的是系统最优——整体配送时间最短、整体效率最高、整体用户满意度最好。

但”系统最优”不等于”每个骑手都好过”。

为了让你的黄焖鸡早到3分钟，算法可能会给骑手规划一条穿越步行街的路线（更短但更难骑）。为了全局效率，算法可能会把5单同时塞给一个骑手（系统看来是”充分利用运力”，骑手看来是”要命了”）。

2020年那篇《外卖骑手，困在系统里》刷屏朋友圈的时候，很多人才第一次意识到：那个让你觉得”外卖好快啊”的效率提升，是骑手在红灯面前犹豫”要不要闯”的几秒钟里挤出来的。

算法不会闯红灯。但算法给出的时间约束，会逼着骑手做这个选择。

这是一个工程上的”多目标优化”概念在现实中最残酷的投影——当你优化一个目标（配送时间）的时候，另一个目标（骑手安全和体验）可能在悄悄恶化。而算法的损失函数里，后者的权重往往不够大。

所以这跟我有什么关系？

如果你也写代码——

你大概在技术选型的时候纠结过”这个方案是不是最优的”。美团调度系统给出的答案很直接：别纠结了。NP-hard问题连数学家都解不出完美解，但0.1秒内的”够好”方案每天稳定跑着1亿单。工程的核心从来不是追求完美，是在约束条件下快速给出可用解。

如果你做算法或者产品——

每一个”优化目标”的背后，都站着一个承受优化代价的真人。你的”点击率最大化”对应的可能是用户凌晨三点还在刷手机；你的”配送效率最大化”对应的可能是骑手在黄灯前两秒的犹豫。把”被优化的那个人”也写进损失函数，不是情怀，是让系统能跑十年而不是跑两年就崩的工程决策。

如果你只是一个点外卖的普通人——

下次骑手迟到5分钟，在点差评之前可以多想一秒：这5分钟里，可能是算法同时塞了3单给他，可能是商家出餐慢了8分钟，可能是他在你楼下等门禁等了3分钟。那个迟到里，有太多他根本控制不了的变量。

装在同一个外卖箱里的

回到开头那份黄焖鸡。

它能在30分钟内送到你手上，靠的是一套每秒重算数千次的调度系统——工程上确实是奇迹。

但这个奇迹的燃料，是一个骑手在第47单和第48单之间看了一眼导航，然后选择闯过那个还剩2秒的黄灯。

技术之美和技术之残酷，装在同一个外卖箱里送到了你面前。你吃到的每一口热饭，都同时是算法的杰作和某个人的代价。