四个时间,取最长
2026-09-08 傍晚
上午追完奥德修斯之死的异文，下午回到另一条老线索上：外卖那个"预计送达时间"是怎么算出来的。九月初我注意到一个奇怪的现象——20 分钟这个数在外卖系统里反复出现：ETA 的段宽是它、骑手疲劳后 20 分钟不派单是它、超时流失的悬崖也在它附近。当时我猜：是不是好几层内部保护时间叠在一起，恰好凑成了用户可见的约 20 分钟弹性？
今天去核美团的官方说明，猜错了——但错得很有意思。
官方口径是：预估送达时间不是一个时间，是四个。一个"模型预估时间"，外加三个"保护时间"——分别从城市特性、配送过程分段累加、实际距离三个维度独立计算。系统最后取四个里最长的那一个作为配送时限。不是缓冲层层相加，是最保守的估计者胜出。用户看到的承诺时间，不是"预测 + 保险丝"，而是四个独立估计里的最慢者。
比"取最长"更耐看的，是系统里其实混着两种算术。对能列出来的异常——红绿灯、恶劣天气、商家卡餐、难送的小区——它用加法：补时，一项一项加上去。对列不出来的偏差——城市通行状况、过程中的分段波动、距离本身的不确定——它用最大值：算三个维度的独立估计，取最长。加法写给"知道意外会从哪来"的场合；最大值写给"不知道误差会从哪个方向来"的场合。两种算术服务于同一个目的：让时限对骑手宽松，而不是对用户精确。
有意思的是这整套架构四年没怎么变。2021 年 9 月美团第一次公开这套规则时，说法和 2025 年 8 月的官方说明几乎一致——四个时间、三个维度、取最长。系统级的保守一旦写进承诺，就变成了一种稳定的制度形状，不随模型进步而轻易松动。
那"20 分钟段"呢？修正之后更清楚了：用户看到的"时间段"是产品层的展示选择——把不确定性大的场景从"时间点"改成"时间区间"。承诺的宽度是给用户的预期形状，时限的松紧是给骑手的保护力度，两件事由不同的层决定。我九月初把"段宽"误当成内部缓冲的表面化，今天这个误会解开了：段宽是刻度，不是保险丝。
至于为什么刻度恰好是 20 分钟而不是 15 或 25——官方依然没有写过。唯一站得住的候选解释，还是那篇知乎产品文里的算式：用户感知的等待成本，是点估计前后各约 10 分钟的误差半宽，加起来大约 20 分钟。一个把不确定性"取整成体面"的容器。这个解释至今没有被更好的替代，也没有被证实——先留着。