最近有一个讨论值得展开美团外卖、同城快递、网约车本地生活服务三大行业会不会“去其一”。这个判断在交易、资本、政策层面可以争论很久但从技术视角看结论会更清晰真正的“去其一”大概率不是某个行业被直接砍掉而是三套分立的履约系统最后收敛成同一套基础设施。外卖和同城快递之间本来只差一个“是否包含餐品”的标签网约车本质上是“把人当作货物的同城配送”。当无人配送车、无人机、自动驾驶开始规模落地时三大行业的技术边界会越来越模糊。本文不讲股价不讲商业模式故事只从调度算法、LBS 地图、时空数据、AI 工程化四个维度拆解帮技术读者建立一个判断框架这三套系统到底哪里相同、哪里不同谁最容易被吃掉。1. 三大行业核心能力速览先给一张横向对比表。这里的“美团”可以理解为本地生活服务平台的代表三大行业的对比立足点是技术底座和履约链路。维度外卖同城快递 / 跑腿网约车核心问题短时履约 订单密度多品多址 时效承诺时空匹配 安全合规典型计算任务订单分配、骑手路径、ETA 预测包裹拼单、路径优化、末端分配派单、动态定价、上车点推荐终端形态骑手电动车 App电动车、无人机、无人车汽车 司乘两端 App地图依赖中依赖路况和商户 POI中依赖楼宇和自提柜位置高依赖实时路网和导航调度实时性秒级到分钟级分钟级到小时级秒级AI 落地重点多模态识别、预测性调度无人配送决策、CV 识别包裹自动驾驶、安全风控数据资产交易、轨迹、商户画像包裹、轨迹、IoT 设备状态轨迹、路况、司机行为从这张表能看出一个关键现象三者的底层技术栈高度重叠——都是“位置数据 调度算法 移动端”的组合。区别主要在实时性要求、终端形态和合规约束而不在算法本质。2. 三套系统的技术全貌2.1 外卖分钟级履约的调度机器外卖是三大行业里订单密度最高、时效要求最严的场景。它的技术难点不是单一算法而是整个调度链路要处理几类实时问题新订单进来分配给谁。骑手手上已有订单是否能顺路加单。商户出餐时间波动ETA 要不要调整。恶劣天气、突发爆单运力怎么重新平衡。这些问题的共同点是不确定性极高。出餐慢、等电梯、交通拥堵都会让静态规划失效所以外卖系统必须做到“边执行边重算”。常见做法是把问题建模成多目标优化用户等待时间要短骑手空驶率要低平台成本要可控商户出餐时间要被模型中。多个目标之间相互制约系统每隔几十秒就要做一次局部重分配。2.2 同城快递多品多址的运力网络同城快递或跑腿业务表面上和外卖很像但有一个重要区别履约对象不限于“餐品”可能是一份文件、一束花、一台手机也可能是需要在多个地点取送的批量包裹。因此它在调度上要额外考虑重量、体积、取件点和送件点分离、自提柜容量等因素。从技术实现看同城快递非常适合被抽象成“线上路演问题”Online Routing Problem。骑手或无人车在接到新任务时系统需要判断是否插入当前路径、是否会影响已有任务时效。插入操作要满足时间窗约束同时评估成本增量。这一套逻辑和外卖调度没有本质区别只是约束条件更多。2.3 网约车载人的时空匹配问题网约车和外卖在“找人送货”的框架上很像但它的独特之处在于“人”即“货物”所以体验和安全的权重完全不同。技术上的核心问题是下单点与实际上车点不一致需要匹配和推荐。司机位置是连续运动的派单要预测未来几分钟的空车位置。一单结束后的下一单是否顺路关系到司机收入。动态定价要结合供需比和天气、区域活动等外部事件。另外网约车的合规要求比外卖高得多。车辆资质、司机身份、行程录音、行车安全实时监测都会变成系统的技术模块。它是最容易走向自动驾驶终局的场景因为“载人配送”一旦标准化体验差异会被自动驾驶抹平。3. 调度系统三大行业共享的内核3.1 订单分配的本质三大行业的调度问题都可以抽象为在某一时刻有若干订单和若干可用运力系统要给出一个匹配方案让某个全局目标最优。这个目标的典型形式是“订单总延迟最小化 运力空闲率最小化 成本最小化”。由于实时性要求工业级系统极少做全局穷举而是采用“贪心 局部搜索 规则约束”的混合策略。先把订单按紧急程度排序再为每个订单找代价最小的骑手或司机最后做一轮冲突消解。离线阶段可以用强化学习或运筹优化求解器生成策略在线阶段把策略蒸馏成近似规则保证延迟可控。3.2 一个简化的调度决策示例下面用一个极简 Python 示例演示“订单分配给谁”的基本逻辑。实际生产系统会包含路网距离、商家出餐时间、骑手负载、实时路况等大量特征这里只展示骨架。# 简化的订单分配决策示例真实系统需要替换为实际服务 from dataclasses import dataclass from typing import List dataclass class Order: order_id: str pickup_lat: float pickup_lng: float dropoff_lat: float dropoff_lng: float created_at: int dataclass class Rider: rider_id: str lat: float lng: float current_load: int # 当前已接订单数 def estimate_distance(a_lat, a_lng, b_lat, b_lng) - float: # 这里应该调用真实路网距离服务保留一个估算占位 # 直接用欧式距离只用于示例 return ((a_lat - b_lat) ** 2 (a_lng - b_lng) ** 2) ** 0.5 def assign_order(order: Order, riders: List[Rider]) - str: best_rider None best_score float(inf) for rider in riders: if rider.current_load 5: continue # 超载保护 d estimate_distance( rider.lat, rider.lng, order.pickup_lat, order.pickup_lng ) # 评分越低越优真实系统还要加商家出餐时间和路况特征 score d rider.current_load * 0.5 if score best_score: best_score score best_rider rider.rider_id return best_rider if __name__ __main__: order Order(o001, 31.2304, 121.4737, 31.2400, 121.4900, 1700000000) riders [ Rider(r001, 31.2320, 121.4750, 2), Rider(r002, 31.2450, 121.4800, 1), ] print(assign_order(order, riders))这个例子说明调度系统核心不是“谁能更快跑过去”而是“在约束条件下谁的综合代价最低”。负载均衡、顺路可能性、未来订单预测都是评分函数里的可配置项。3.3 强化学习在调度中的价值规则和贪心方案在简单场景下足够用但一旦出现“爆单”“天气恶劣”“大型活动散场”等异常状态规则库会指数级膨胀。强化学习在这里的优势是从历史调度数据中学习策略让系统在复杂场景下做出比人工规则更好的决策。实际落地时要解决的问题有三个模拟器必须足够接近真实环境否则策略会产生偏移。线上行为要加保护策略避免探索动作影响真实体验。评估指标要分层不能只看单一指标。不过强化学习不是万能的。冷启动阶段数据不足、业务指标频繁变动时强化学习项目的维护成本会很高。更稳的路线是先用规则和优化算法跑通再在局部场景用强化学习替代。4. LBS 与地图三大行业的地基4.1 位置数据是履约系统的“内存”外卖、同城快递、网约车都依赖一套完整的位置数据体系。粗略来说包括POI 数据商户、小区、办公楼、自提柜的位置和属性。路网数据道路等级、通行方向、实时拥堵。轨迹数据骑手、司机、无人车的历史轨迹。地理围栏机场、学校、景区等特殊区域的电子边界。这三套系统的地图策略有差异。外卖对楼宇内部结构敏感骑手最关心“商户在几楼、哪个门进”网约车对路网和上下车点敏感需要精确到车道级导航和停车点推荐同城快递则介于两者之间既要关注楼宇也要关注自提柜和驿站。4.2 地理围栏判定示例下面是判断一个坐标点是否落入某个圆形围栏的简化实现。真实场景中围栏通常是多边形并需要接入地理服务。import math def haversine(lat1, lng1, lat2, lng2) - float: # 计算两个经纬度点之间的球面距离单位米 radius 6371000.0 phi1 math.radians(lat1) phi2 math.radians(lat2) delta_phi math.radians(lat2 - lat1) delta_lambda math.radians(lng2 - lng1) a math.sin(delta_phi / 2) ** 2 math.cos(phi1) * math.cos(phi2) * math.sin(delta_lambda / 2) ** 2 c 2 * math.atan2(math.sqrt(a), math.sqrt(1 - a)) return radius * c def is_in_circle(target_lat, target_lng, center_lat, center_lng, radius_meter) - bool: distance haversine(target_lat, target_lng, center_lat, center_lng) return distance radius_meter # 示例判断骑手是否进入商圈配送围栏 print(is_in_circle(31.2304, 121.4737, 31.2340, 121.4700, 800))这类能力不仅用来做“是否在配送范围”的判断还会被用于运力投放、广告投放、骑行安全提示等业务。可以说LBS 能力的水位决定了三大行业交付质量的底层水平。4.3 地图数据的工程挑战地图服务不是“查个坐标”那么简单工程量集中在实时性和一致性上。地图数据要随时间更新新路、封路、商户搬走都会影响调度结果。很多平台的做法是主路网用第三方地图数据楼宇和 POI 自建再叠加自采的骑手轨迹来修正。这里有一个关键技术点路径规划不能只算距离最短要按“预计耗时”来算。耗时预测要结合一天内的时间段、天气、具体路段的红绿灯时长、骑手熟悉的区域等因素。一个通用的做法是用历史轨迹数据训练一个 ETA 模型而不是依赖路网距离直接除以平均速度。5. 数据资产决定行业壁垒5.1 三大行业各自沉淀了什么数据技术系统最终会沉淀成数据资产。横向对比外卖海量商户 POI、出餐时长分布、骑手轨迹、用户偏好。同城快递包裹体积重量、取送地址结构化、自提柜状态、无人车运行日志。网约车完整路况时间序列、司机行为、行程录音、上下车点热点。这些数据最有价值的用法不是给人看报表而是进入模型训练闭环。例如出餐时长预测模型可以直接影响外卖调度的成功率下车点推荐模型可以减少网约车司乘沟通成本无人车运行日志则是迭代自动驾驶策略的基础。5.2 ETA 模型调用示例假设团队已经训练好一个 ETA 预测服务内部调用通常会像下面这样。具体接口路径和字段需要按实际项目调整。curl -X POST http://your-server/api/v1/eta/predict \ -H Content-Type: application/json \ -d { start_lat: 31.2304, start_lng: 121.4737, end_lat: 31.2400, end_lng: 121.4900, biz_type: takeout, time: 1700000000 }import requests url http://your-server/api/v1/eta/predict payload { start_lat: 31.2304, start_lng: 121.4737, end_lat: 31.2400, end_lng: 121.4900, biz_type: takeout, time: 1700000000, } response requests.post(url, jsonpayload, timeout5) if response.status_code 200: data response.json() print(预测耗时, data.get(eta_seconds)) else: print(调用失败状态码, response.status_code)5.3 特征工程是共性难点三大行业做预测模型时特征工程会占掉大部分工作量。常见特征包括时间特征时段、星期几、是否节假日。空间特征起点终点区域、距离、是否跨江跨河。运力特征附近可用骑手或司机数量、忙碌程度。天气特征雨量、温度、风力。事件特征演唱会、赛事、临时管控。这些特征在三大行业里几乎通用区别只在业务映射方式。这也解释了为什么一个团队做过外卖调度后再做同城快递或网约车调度技术迁移成本并不高。6. “去其一”真正的技术含义回到标题的疑问。从技术架构演进来看“去其一”大概率不是砍业务而是“三套系统统一成一套”。6.1 外卖与同城快递本来就该是一套履约网络外卖和同城快递的终端场景高度相似。同一个骑手电动车可以送餐也可以送文件、送药品、送超市商品。从系统设计角度看二者完全可以共用一套调度中台差异只体现在约束配置上。现实中很多平台已经这么做了。用户看到的是“外卖”和“跑腿”两个入口但后台的骑手池、路径规划能力、ETA 服务是同一个。业务差异被抽象成订单类型而不是重新建一套技术系统。所以“去其一”在这里的体现是外卖和同城快递的履约层会越来越融合独立建一套系统的价值会持续下降。6.2 网约车载人配送的终局是自动驾驶网约车和外卖、快递之间最大的区别是终端和合规而不是算法。如果把“人”看作需要准时、安全送达的“特殊包裹”网约车就只是一个约束更严格的配送问题。自动驾驶技术成熟后这种区别会被进一步抹平。车和电动车都可以变成无人化运力调度系统只需要维护“载人”和“载货”两种模式。司机成本消失后网约车与同城快递的技术差异会被压缩到只剩安全等级、乘坐体验和法律责任。届时真正留下来的不是三个行业而是一个“同城移动网络”。6.3 无人配送的时间线要现实看待无人配送车和无人机已经在特定区域、特定时段投入使用但目前还无法大规模替代骑手和司机。主要瓶颈很明确成本无人车和无人机早期造价高回本周期长。政策路权、空域、事故责任划分仍在完善。技术末端复杂的上下楼、面对面交付无人设备很难处理。体验用户对“无人化”接受度还需要验证。所以更稳的判断是三大行业会先完成后台技术融合再逐步推进最后一公里的无人化。对技术从业者来说这种演进反而提供了足够长的窗口期。7. 工程师视角入局需要什么能力如果选择进入外卖、同城快递、网约车这类时空履约领域下面五类能力最值得投入。7.1 调度与运筹优化核心能力是数学建模、混合整数规划、约束求解、局部搜索。实际业务里不要求工程师手推公式但要能判断“这个问题能否建模成指派问题”“能否用启发式解法求解”。7.2 时空数据工程要能处理海量 GPS 轨迹、POI 数据、路网数据。常见工具包括 ClickHouse、Doris、Flink、Spark 等。关键是建立“空间索引”和“时间分区”思维避免用传统关系型数据库硬扛高并发轨迹写入。7.3 机器学习与模型部署ETA 预测、供需预测、价格预测、骑手行为预测都是监督学习任务。需要熟悉特征工程、XGBoost/LightGBM、时序模型以及模型上线后的监控和回滚机制。模型离线 AUC 高不代表线上效果好必须持续关注推理延迟和数据分布漂移。7.4 仿真系统建设调度算法迭代必须依赖仿真环境。要用历史数据回放模拟骑手/司机移动、订单生成、异常事件才能在不上线的条件下评估策略收益。仿真越接近真实策略迭代速度越快。这是很多团队容易低估的工程门槛。7.5 嵌入式与 AIoT 基础无人机、无人车、智能自提柜、车载设备都会产生大量命令和控制需求。即使不做底层开发也要了解端云通信协议、设备状态上报、OTA 升级机制否则难以设计完整业务闭环。建议学习路径先跑通一个含 GPS 轨迹的 Kaggle 数据集做一次完整特征工程再尝试用开源调度求解器解决一个配送实例最后搭建一个简单仿真回放系统。8. 数据合规与安全边界三大行业都涉及大规模轨迹、人脸、声音、交易数据合规是不可绕开的技术约束。位置数据用户授权要明确采集频率要克制轨迹数据要脱敏存储。用户隐私订单记录、家庭住址、通话录音都属于敏感数据访问权限要按角色严格控制。无人设备无人配送车和无人机的测试要符合地方试点政策不能在未授权区域运行。AI 决策安全调度算法对骑手或司机的劳动强度影响很大模型上线前要做公平性评估避免连续派单造成过劳风险。技术人员在开发过程中要把“数据最小化”当作默认原则能采集订单号就不采集手机号能聚合统计就不留存明细。权限审计日志不能省接口访问要有鉴权和限流。9. 常见问题与分析角度问题现象可能的分析角度建议处理方式“哪个行业先被去掉”行业是否具备独立技术壁垒对比该行业与相邻行业在调度、地图、终端上的复用度“无人配送什么时候规模落地”成本、政策、技术三方约束跟踪试点城市政策、整车成本曲线、异常处置能力测试“三大行业到底在争什么”本质是争夺同城运力和用户时长从运力调度效率和技术系统复用度观察“算法工程师去哪个行业更稳”算法迁移成本优先选择数据资产丰富、调度复杂度高的平台“数据中台是否值得独立建设”看业务归一化程度如果订单类型差异大建议先做领域抽象再做中台“网约车会不会被自动驾驶公司取代”技术决定下限合规和运营决定上限同时观察 L4 路测数据和平台运营能力10. 总结与下一步三大行业的关键变量不是“谁会被淘汰”而是“调度中台能否做到一套系统承载多种履约模式”。外卖和同城快递的融合已经是最确定的趋势网约车与物流无人化只是时间问题。建议技术读者下一步做三件事找一个本地外卖配送的数据集手动实现一次订单分配和路径插入逻辑感受约束条件带来的复杂度。学习一个通用的运筹优化求解器把“最小化配送成本”的问题完整跑通理解工业级调度系统的难点不在于公式而在于数据质量和工程落地。关注低速无人车、无人机配送的试点项目对比它们和人力配送在实际场景中的效率差异。这个话题不需要等到“某一天某个行业突然消失”再关注。技术演进的路径已经足够清晰先融合再无人化最后统一成一张同城移动网络。对工程师来说这是一个值得长期投入方向的一线战场。