最近有一个讨论值得展开：美团外卖、同城快递、网约车，本地生活服务三大行业，会不会“去其一”。这个判断在交易、资本、政策层面可以争论很久，但从技术视角看，结论会更清晰：真正的“去其一”，大概率不是某个行业被直接砍掉，而是三套分立的履约系统最后收敛成同一套基础设施。
外卖和同城快递之间，本来只差一个“是否包含餐品”的标签；网约车本质上是“把人当作货物的同城配送”。当无人配送车、无人机、自动驾驶开始规模落地时，三大行业的技术边界会越来越模糊。本文不讲股价，不讲商业模式故事，只从调度算法、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, json=payload, timeout=5) 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. 总结与下一步
三大行业的关键变量不是“谁会被淘汰”，而是“调度中台能否做到一套系统承载多种履约模式”。外卖和同城快递的融合已经是最确定的趋势，网约车与物流无人化只是时间问题。
建议技术读者下一步做三件事：
- 找一个本地外卖配送的数据集，手动实现一次订单分配和路径插入逻辑，感受约束条件带来的复杂度。
- 学习一个通用的运筹优化求解器，把“最小化配送成本”的问题完整跑通，理解工业级调度系统的难点不在于公式，而在于数据质量和工程落地。
- 关注低速无人车、无人机配送的试点项目，对比它们和人力配送在实际场景中的效率差异。
这个话题不需要等到“某一天某个行业突然消失”再关注。技术演进的路径已经足够清晰：先融合，再无人化，最后统一成一张同城移动网络。对工程师来说，这是一个值得长期投入方向的一线战场。
