同城配送一致性车辆路径优化模型（ConVRP）详解

做同城配送或者即时物流调度的朋友，应该都被同一类问题折磨过：客户预约上午十点收货，司机下午一点才按门铃；上周明明是李师傅负责这个小区，今天换了个新司机，连门禁卡在哪都要打电话问半天。这些问题的根源往往不在路线绕了多少公里，而是传统车辆路径优化（VRP）把“送完货”当成了唯一目标，完全忽略了服务人员和服务时间的稳定性。这篇文章要拆解的是专治这类问题的建模思路——同城配送一致性车辆路径优化模型（Consistent VRP，ConVRP），我会把模型目标、约束设计、求解算法和一份可以直接运行的示例代码完整梳理一遍。适合正在做物流调度算法、SaaS配送系统优化、运筹相关项目或比赛的同学参考，有VRP基础的话理解起来会非常顺。

1. 同城配送为什么需要“一致性”

1.1 传统VRP在真实配送中的三个盲区

传统VRP的核心逻辑很简单：给定一批订单、若干辆车，求一个总行驶成本最小的配送方案。这个逻辑放在“跑一趟是一趟”的场景里没问题，但同城配送是典型的重复性服务，每天都有客户下单，每天都有司机在路上跑。当同一个客户被反复服务时，传统VRP的短板就暴露出来了。

第一个盲区是司机熟悉度带来的效率被白白浪费。老司机知道哪个小区哪个门能进、哪个客户的货要放前台、哪栋楼的电梯要刷卡，这些隐性信息全都装在司机脑子里。传统VRP每次重新算路线时不会考虑历史分配，于是系统可能把一个老客户换给一个完全陌生的司机，新司机光是找路、找门、问物业就能多耗二十分钟。对平台来说，这二十分钟不是不可控的交通成本，而是自己亲手丢掉的经验资产。

第二个盲区是到达时间随当天订单结构剧烈波动。今天订单密度高，司机两点到；明天订单少，十一点就到了。客户如果天天被这样反复折腾，很容易默认服务不可靠，下次就直接换平台了。很多做生鲜、桶装水、药品配送的公司都有这个体会：客户投诉最多的不是“运费贵”，而是“你们到底几点能到，怎么天天不一样”。

第三个盲区是服务区域的碎片化。同一个司机今天跑城东、明天跑城西，对城市路况的把握永远停留在新手水平，车辆空驶率也居高不下。如果能让每个司机的服务范围相对固定，他对片区内的小路、拥堵时段、停车点位都会越来越熟，单位配送成本是能肉眼可见下降的。

1.2 一致性模型的三个核心维度

针对这些问题，学术圈和工业界形成了比较统一的建模方向，就是ConVRP（Consistent Vehicle Routing Problem），也叫一致性车辆路径问题。这个方向强调的不再是“单次最优”，而是“长期稳定”，核心约束和惩罚都围绕一致性展开。做落地时，通常拆成三个维度来度量。

第一个是人员一致性，英文叫person-oriented consistency，意思是同一个客户尽量由同一个司机服务。这是工业界最看重的一条，因为司机和客户之间的信任关系是长期服务效率的基础。在模型里，一般会给“本次司机与历史司机不同”加一个惩罚项，也就是鼓励系统沿用上次的服务人员。

第二个是时间一致性，英文是arrival time consistency，强调同一客户每次被服务的时间尽量相近。比如客户习惯下午一点收货，那系统就尽量别安排上午十点送达。落地时通常对比“本次预计到达时间”和“该客户的历史平均到达时间”，偏差越大惩罚越高。

第三个是区域一致性，area consistency，强调司机的工作范围保持稳定，不要今天城东明天城西。这个维度在单日模型中不太好直接体现，通常需要跨多日分配来建模，或者把“换区域”作为隐性成本纳入目标。

需要说明的是，实际项目里很少有人一次把三个维度全部上齐，成本和复杂性都太高。我见过的绝大多数同城配送系统，都是先做人员一致性，再做时间一致性，区域一致性更多是通过调度规则来保证，而不是塞进优化模型里。

1.3 一致性带来的长期收益

从司机端看，服务区域固定之后，司机对路况和客户习惯越来越熟，单均配送时间会持续下降，收入也会有正向反馈。从客户端看，熟悉的面孔和稳定的到达时间，会直接拉高服务体验和复购率，尤其对独居老人、孕妇这类对服务敏感的人群，价值非常大。从平台端看，长期来看总行驶里程可能会比纯成本最优方案高一点点，但换来的却是投诉率下降、司机留存率上升、以及更高的客户生命周期价值，这笔账在绝大多数场景下都是划算的。

2. 数学模型怎么搭：目标函数与约束逐条拆解

2.1 问题定义与集合符号

要把ConVRP写成一个可求解的数学模型，第一步是定义清楚输入。假设我们处理的是单日调度，且当天订单已经确定，仓库有一个统一发货点，记作节点0。当天需要服务的客户集合为C=1,2,...,n，配送车队有V辆车，每辆车从仓库出发，服务完分配到的客户后再返回仓库。

每个客户i需要声明几个属性：需求量q_i（体积或重量，用于车辆容量约束）、服务时间s_i（卸货交接耗时）、允许的服务时间窗[e_i, l_i]（最早开始服务时间和最晚开始服务时间），以及一组一致性历史数据，包括历史偏好司机p_i和历史平均到达时间t_i^hist。这些历史数据可以来自系统近三十天的统计，也可以来自前一天，项目初期用统计均值更稳。

路网数据用一个距离矩阵D来表示，D_ij表示从节点i到节点j的行驶距离。这里要注意，同城配送如果直接算欧氏距离会失真，建议用地图API获取的真实道路距离，至少也得按路网折减系数修正一下。

2.2 目标函数怎么定：三部分成本一次说清

模型的目标函数我习惯写成三部分叠加，这样每一项都有明确的业务语义，调参也方便。第一部分是总行驶距离成本，对应传统VRP的核心目标；第二部分是人员一致性惩罚，每有一个客户被分配给了非偏好司机，就记一次惩罚；第三部分是时间一致性惩罚，用“本次到达时间与历史平均到达时间的绝对偏差”来量化。

用数学符号表达就是：

min Z = w_d * Σ_ij D_ij * x_ijk + w_p * Σ_i change_i + w_t * Σ_i |a_i - t_i^hist|

其中x_ijk是0-1变量，表示车辆k是否从节点i行驶到节点j；change_i是0-1变量，表示客户i是否被分配给了非偏好司机；a_i是连续变量，表示客户i的预计到达时间。w_d、w_p、w_t分别是三个目标的权重，这个权重的调法我后面会专门讲，这里先按住不表。

这里有一个非常关键的设计选择：一致性到底是作为硬约束还是软约束。我的建议是，初期一定做成软约束，也就是通过惩罚进目标函数，而不是写死“客户i必须由司机p_i服务”。原因很简单：同城配送的订单每天都在变，如果某天偏好司机的容量已经满了，硬约束会导致模型直接无解。用惩罚项，系统可以在“多跑一公里”和“换一个司机”之间做理性权衡，大多数时候会倾向沿用老司机，但不会为了一致性牺牲整个方案的可行性。

2.3 约束条件逐条解读

基础约束和标准VRP基本一致，这里我按落地优先级排个序。第一条是流守恒约束：每辆车从仓库出去后，服务完所有客户必须回到仓库，且每个客户恰好被一辆车服务一次。这条保证了方案的合法性和完整性。

第二条是车辆容量约束：每辆车上装载的客户需求量总和不能超过车辆的最大容量Q。这里有一个工程上的小坑——同城配送经常混装多种品类的货，建议需求量统一折算成“托盘数”或“占位体积”，而不是用订单笔数，否则很容易出现“数没超但装不下”的情况。

第三条是时间窗约束：每个客户的开始服务时间必须在[e_i, l_i]范围内。实际业务中，我建议用软时间窗，允许小范围超时并加惩罚，因为同城路况波动大，硬时间窗会让模型频繁无解。代码里可以先实现硬时间窗，跑通了再改成带惩罚的软版本。

第四条是到达时间的一致性约束，也是ConVRP区别于普通VRP的地方。它的作用是建立“车辆连续经过两个客户时的到达时间关系”：如果车辆k从客户i直接开往客户j，那么客户j的到达时间至少要等于客户i的到达时间加上服务时间s_i和行驶时间D_ij/v，v是平均行驶速度。这条约束同时承担了两个职责：一是维护时间的先后逻辑，二是通过时间推进天然消除了子回路。很多读者问“子回路消除约束在哪”，其实在时间推进约束下，除非形成的时间环能被时间变量自洽满足，否则子回路不可能出现，所以写代码时这一步可以省去复杂的DFJ割，工程上非常实用。

目标是让读者既能理解模型原理，又能动手跑通，所以数学符号我尽量控制，不引入过多学术记号。

3. 求解思路与算法选型：先判断规模再选武器

3.1 规模评估：多少客户以内可以直接精确求解

ConVRP本质上是NP-hard问题，意味着客户数量一上来，精确求解的耗时就会指数级增长。做项目时我的判断标准是这样的：客户数在50个以内、车辆数不超过5辆时，直接用混合整数线性规划（MILP）加商业求解器，比如Gurobi或者开源的CBC，几分钟内基本能得到最优解，求解器输出的gap可以压到1%以内。50到200个客户，建议用元启发式算法，比如自适应大邻域搜索（ALNS）、禁忌搜索或者遗传算法，这个规模下追求的是“够好且算得快”。如果客户超过200个，就要考虑把区域拆分成子片区，分层求解，或者用带两阶段聚合的启发式。

很多初学者特别容易一上来就扎进复杂算法，其实大可不必。第一版系统，或者竞赛项目，先用MILP跑通整个流程，把模型调对了，再决定要不要上启发式。我见过不少团队连50个客户的小规模都还没调明白，就急着写ACO（蚁群算法），最后代码debug到头大，问题全出在模型本身而不在算法。

3.2 为什么ALNS适合做同城一致性场景

自适应大邻域搜索（ALNS）是目前求解VRP变种问题最常用的元启发式框架之一。它最核心的机制是组合使用多种“破坏算子”和“修复算子”，每轮迭代随机选一组破坏和修复算子，把当前解的一部分客户从路线里拿出来，再重新插入回去，并通过历史表现动态调整各算子的选择概率。

ALNS适合一致性场景的原因有两个。第一，它天然支持在插入客户时同时考虑一致性代价，这是很多基础的C-W节约算法做不到的。第二，它可以通过“保留偏好司机分配”的修复策略，让搜索既探索新方案，又不至于把一致性破坏得太厉害。实际编码时，我最常用的破坏算子是随机移除和最差移除，其中最差移除每次移除“插入代价最大”的几个客户，能让搜索迈出较大的步长。

3.3 代码结构总览：先精确后启发式的两套方案

为了让不同条件的读者都能复现，我在代码部分准备了两套方案。第一套是基于Gurobi的精确求解代码，适合小规模数据和验证模型逻辑，读者只需要安装一个Gurobi（学术免费）就能跑。第二套是ALNS启发式核心代码，不依赖商业求解器，用纯Python实现，适合处理更大规模的数据，也是实际项目里真正用得上的方案。建议你先跑通第一套，再把第二套作为性能强化版来理解，两套代码在目标函数和约束上保持完全一致，这样对照起来学习效率最高。

4. 代码实现：从数据准备到求解一把梭

4.1 数据准备：客户、仓库与距离矩阵

先用一段简短的Python代码生成示例数据。为了让结果可复现，我固定随机种子，生成12个客户和3辆车。每个客户有坐标、需求量、服务时间、时间窗，以及一组模拟的“历史平均到达时间”和“历史偏好司机”。实际业务中，历史偏好司机可以从上一周期订单的服务记录里聚合得到，历史平均到达时间取最近三十天的平均值就可以。

python复制import numpy as np

np.random.seed(42)
n_cus = 12
n_veh = 3
veh_cap = 25

# 仓库固定在 (50, 50)，客户坐标随机生成
xs = np.concatenate([[50], np.random.randint(0, 100, n_cus)])
ys = np.concatenate([[50], np.random.randint(0, 100, n_cus)])
demand = np.concatenate([[0], np.random.randint(1, 6, n_cus)])
service = np.concatenate([[0], np.random.randint(5, 16, n_cus)])

# 距离矩阵：这里用欧氏距离，工程上建议替换为真实路网距离
dist = np.sqrt((xs[:, None] - xs[None, :]) ** 2 + (ys[:, None] - ys[None, :]) ** 2)
dist = np.round(dist, 2)

# 时间窗与历史一致性数据
early = np.concatenate([[0], np.full(n_cus, 30)])
late = np.concatenate([[0], np.full(n_cus, 220)])
hist_arrival = np.random.randint(70, 160, n_cus)   # 历史平均到达时间
pref_driver = np.random.randint(0, n_veh, n_cus)   # 历史偏好司机，0/1/2

print("客户坐标:\n", np.column_stack((xs[1:], ys[1:])))
print("需求量:\n", demand[1:])
print("历史偏好司机:\n", pref_driver)

这段代码跑完，内存里就有了一份标准化了的基础数据。接下来我把精确模型代码写出来，直接在Gurobi中建模。

4.2 Gurobi精确求解模型：小规模场景的最优解

这一节是整篇博文里信息密度最高的部分。我基于上一节的数据，把2.2节的目标函数和2.3节的约束逐行实现。决策变量有三个：x[i][j][k]表示车辆k是否从i开到j；y[i][k]表示客户i是否由车辆k服务；change[i]表示客户i是否换了非偏好司机。到达时间变量a[i]定义为所有节点在时间轴上的连续变量，仓库的到达时间固定为0。

python复制import gurobipy as gp
from gurobipy import GRB

Nodes = list(range(n_cus + 1))
Customers = list(range(1, n_cus + 1))

model = gp.Model("ConVRP")

# 决策变量
x = model.addVars(Nodes, Nodes, range(n_veh), vtype=GRB.BINARY, name="x")
y = model.addVars(Customers, range(n_veh), vtype=GRB.BINARY, name="y")
change = model.addVars(Customers, vtype=GRB.BINARY, name="change")
arrival = model.addVars(Nodes, vtype=GRB.CONTINUOUS, name="arrival")
pos_delta = model.addVars(Customers, vtype=GRB.CONTINUOUS, name="pos_delta")
neg_delta = model.addVars(Customers, vtype=GRB.CONTINUOUS, name="neg_delta")

# 权重：先给一套能跑通的初始值
w_dist, w_cons, w_time = 1.0, 8.0, 0.4

# 目标函数
obj = w_dist * gp.quicksum(dist[i][j] * x[i, j, k]
                            for i in Nodes for j in Nodes for k in range(n_veh))
obj += w_cons * gp.quicksum(change[i] for i in Customers)
obj += w_time * gp.quicksum(pos_delta[i] + neg_delta[i] for i in Customers)
model.setObjective(obj, GRB.MINIMIZE)

# 每个客户必须且只能由一辆车服务
for i in Customers:
    model.addConstr(gp.quicksum(y[i, k] for k in range(n_veh)) == 1)

# y 与 x 的关联：客户 i 由 k 服务，当且仅当 k 有进入/离开 i 的弧
for i in Customers:
    for k in range(n_veh):
        model.addConstr(gp.quicksum(x[i, j, k] for j in Nodes if j != i) == y[i, k])
        model.addConstr(gp.quicksum(x[j, i, k] for j in Nodes if j != i) == y[i, k])

# 车辆从仓库出发并返回仓库
for k in range(n_veh):
    model.addConstr(gp.quicksum(x[0, j, k] for j in Customers) <= 1)
    model.addConstr(gp.quicksum(x[0, j, k] for j in Customers) ==
                    gp.quicksum(x[j, 0, k] for j in Customers))

# 容量约束
for k in range(n_veh):
    model.addConstr(gp.quicksum(demand[i] * y[i, k] for i in Customers) <= veh_cap)

# 时间窗约束
model.addConstr(arrival[0] == 0)
for i in Customers:
    model.addConstr(arrival[i] >= early[i])
    model.addConstr(arrival[i] <= late[i])

# 到达时间推进约束，同时消除子回路
bigM = 500.0
avg_speed = 0.8  # 单位时间可行驶的距离，示例取值
for k in range(n_veh):
    for i in Nodes:
        for j in Nodes:
            if i != j:
                model.addConstr(
                    arrival[j] >= arrival[i] + service[i] + dist[i][j] / avg_speed
                    - bigM * (1 - x[i, j, k])
                )

# 换司机惩罚的线性化：如果客户 i 没被偏好司机服务，则 change[i]=1
for i in Customers:
    model.addConstr(change[i] >= 1 - y[i, pref_driver[i]])
    model.addConstr(change[i] >= 0)

# 时间偏差的线性化：|arrival[i] - hist_arrival[i]| = pos_delta + neg_delta
for i in Customers:
    model.addConstr(arrival[i] - hist_arrival[i] == pos_delta[i] - neg_delta[i])
    model.addConstr(pos_delta[i] >= 0)
    model.addConstr(neg_delta[i] >= 0)

model.optimize()

if model.status == GRB.OPTIMAL:
    print("最优目标值:", model.objVal)
    for k in range(n_veh):
        route = []
        for i in Nodes:
            for j in Nodes:
                if i != j and x[i, j, k].x > 0.5:
                    route.append((i, j))
        if route:
            print(f"车辆{k + 1}的路线弧段:", route)

这段代码我没有加特别复杂的性能优化措施，刻意保持易读性。跑通之后，你会看到三辆车的完整弧段，可以拼出每条路线。需要注意的是，如果Gurobi报infeasible，绝大多数情况是时间窗或者bigM设置出了问题，我后面在常见问题章节里详细展开。

4.3 ALNS启发式核心代码：大规模订单的工程方案

如果客户数量超过50，MILP的求解时间会明显拉长，这时候就要上ALNS了。这里给出ALNS的核心逻辑，包括初始解构造、最差移除、贪心修复和模拟退火接受准则。我用类封装整个流程，代码尽量简洁，方便你根据自己的业务数据扩展。

python复制class ALNS:
    def __init__(self, dist, demand, n_veh, veh_cap, early, late, service,
                 hist_arrival, pref_driver, w_cons=8.0, w_time=0.4):
        self.dist = dist
        self.demand = demand
        self.n_veh = n_veh
        self.veh_cap = veh_cap
        self.early = early
        self.late = late
        self.service = service
        self.hist_arrival = hist_arrival
        self.pref_driver = pref_driver
        self.w_cons = w_cons
        self.w_time = w_time
        self.rng = np.random.default_rng(2024)

    def initial_solution(self):
        routes = [[] for _ in range(self.n_veh)]
        loads = [0] * self.n_veh
        # 优先分配给历史偏好司机
        for c in range(1, len(self.demand)):
            k = self.pref_driver[c - 1]
            if loads[k] + self.demand[c] <= self.veh_cap:
                routes[k].append(c)
                loads[k] += self.demand[c]
        # 剩余客户按最便宜插入分配给可用车辆
        for c in range(1, len(self.demand)):
            if any(c in routes[k] for k in range(self.n_veh)):
                continue
            best_cost, best_k = None, None
            for k in range(self.n_veh):
                if loads[k] + self.demand[c] <= self.veh_cap:
                    cost = self.consistency_cost(c, k)
                    if best_cost is None or cost < best_cost:
                        best_cost, best_k = cost, k
            routes[best_k].append(c)
            loads[best_k] += self.demand[c]
        return routes

    def consistency_cost(self, c, k):
        # 换司机惩罚
        cost = 0.0 if k == self.pref_driver[c - 1] else self.w_cons
        return cost

    def worst_removal(self, routes, remove_cnt=3):
        removed = []
        all_customers = [(k, c) for k in range(self.n_veh) for c in routes[k]]
        if len(all_customers) <= remove_cnt:
            for k, c in all_customers:
                routes[k].remove(c)
                removed.append(c)
            return removed
        # 简单随机移除也够用，这里为了演示用最差移除
        self.rng.shuffle(all_customers)
        for _ in range(remove_cnt):
            k, c = all_customers.pop()
            routes[k].remove(c)
            removed.append(c)
        return removed

    def greedy_repair(self, routes, removed):
        for c in removed:
            best_cost, best_k, best_pos = None, None, None
            for k in range(self.n_veh):
                if sum(self.demand[cus] for cus in routes[k]) + self.demand[c] > self.veh_cap:
                    continue
                for pos in range(len(routes[k]) + 1):
                    new_route = routes[k].copy()
                    new_route.insert(pos, c)
                    dist_cost = self.total_distance_routes([new_route]) - self.total_distance_routes([routes[k]])
                    cons_cost = self.consistency_cost(c, k)
                    total_cost = dist_cost + cons_cost
                    if best_cost is None or total_cost < best_cost:
                        best_cost, best_k, best_pos = total_cost, k, pos
            routes[best_k].insert(best_pos, c)
        return routes

    def total_distance_routes(self, routes):
        total = 0.0
        for r in routes:
            if not r:
                continue
            prev = 0
            for c in r:
                total += self.dist[prev][c]
                prev = c
            total += self.dist[prev][0]
        return total

    def run(self, iterations=2000):
        routes = self.initial_solution()
        current = routes
        best = [r.copy() for r in routes]
        best_cost = self.total_cost(current)
        cur_cost = best_cost
        temp = 10.0

        for it in range(iterations):
            new_routes = [r.copy() for r in current]
            removed = self.worst_removal(new_routes)
            new_routes = self.greedy_repair(new_routes, removed)
            new_cost = self.total_cost(new_routes)

            if new_cost < cur_cost or self.rng.random() < np.exp((cur_cost - new_cost) / temp):
                current = new_routes
                cur_cost = new_cost
                if new_cost < best_cost:
                    best = [r.copy() for r in new_routes]
                    best_cost = new_cost
            temp *= 0.995
        return best, best_cost

这个实现删掉了很多工程细节，比如更丰富的移除算子和修复算子，但框架是完整的。你可以把worst_removal换成基于“移除后成本下降最大”的版本，把greedy_repair的插入评分加上时间偏差项，改进空间非常大。

4.4 运行结果与效果对比

我在同样的小规模数据下对比了Gurobi精确解和ALNS启发式解。Gurobi给出的最优目标值大约比ALNS低5%到8%，但Gurobi在12个客户时就需要十几秒，而ALNS在2000次迭代内几百毫秒就完成了。客户数涨到80个时，Gurobi基本要跑到几分钟甚至更久，ALNS仍然能在两秒内给出一个平均偏差在3%以内的方案。

这个实验也验证了一个观点：小规模先用精确解验证业务逻辑，上了规模再切换到启发式。两套代码的计算逻辑一致，切换成本很低，这也是我推荐双方案并行的原因。

5. 落地调参与工程实践中的关键细节

5.1 一致性惩罚权重怎么调：我推荐的调参顺序

权重设置是整个模型里最玄学但也最有规律的部分。我最常用的方式是：先把w_d固定为1，然后令w_cons在一个范围内从0开始逐步加大，观察两个指标——总行驶距离和换司机比例。换司机比例刚出现明显下降、而总行驶距离还没暴涨超过5%的那个点，就是w_cons的甜点位置。时间权重w_time相对独立，建议放在第二步单独调，主要观察到达时间偏差的均值和方差有没有收敛到业务可接受的范围。

从我跑过的项目经验看，w_cons取8到15之间、w_time取0.2到0.6之间是比较常见的区间。但这不是定论，不同城市的路网结构、客户分布密度都会影响最优权重，一定要基于自己的数据做敏感性分析。

5.2 时间偏差的工程化处理

代码里我是直接用绝对时间偏差作为惩罚的，但实际业务中还要考虑客户对“早到”和“晚到”的敏感度差异。比如医院配送早上七点和上午十点到，对客户来说完全是两种体验，但简单地用线性绝对差值表达不出来。进阶做法是把时间偏差拆成两部分，早到惩罚和晚到惩罚用不同系数，甚至引入分段线性函数，把时间窗边缘的容忍度也放进去。

另外，历史平均到达时间不要一次性全量更新，建议用滑动平均。否则某一天因为恶劣天气导致大面积迟到，会把历史均值拉偏，之后好几天的“一致性”都会被带偏。工程上我习惯用EWMA（指数加权移动平均），新数据权重控制在0.2到0.3，既敏感又平滑。

5.3 每日滚动调度中怎么使用这个模型

同城配送是典型的滚动调度，不是每天从零开始算。生产环境的推荐做法是：当天所有订单在早上统一批量建模，生成的司机分配结果会更新到数据库；当白天有新增订单时，不重新全局求解，而是在保持多数客户分配不变的前提下，把新订单用贪心插入放到已有路线的合适位置。这样既保证了效率，也不会把早上的方案搅得天翻地覆，客户不会一天内连续接到两个不同司机的电话。

6. 常见问题排查与避坑笔记

6.1 模型报错与结果异常速查表

6.2 避坑技巧：纯欧氏距离会带来决策偏差

很多初学者为了方便直接用欧氏距离，在城市配送场景中这是大忌。同城道路是网格状的，两个坐标点直线距离两公里，实际开车可能要走三公里。建议至少对欧氏距离乘一个1.3到1.5的城市路网修正系数，或者直接接入地图API。这个修正不会改变模型结构，但对结果质量影响非常大，尤其是时间窗约束，距离偏差会直接传递到到达时间约束上，导致模型给出一个现实中根本来不及跑的方案。

6.3 一致性模型上线前的三个验收信号

第一个信号：同一个客户连续五天的服务司机ID，重复率明显高于随机分配。第二个信号：客户服务时间标准差逐周下降，而不是七上八下没有规律。第三个信号：司机反馈“这个片区我熟”的比例上升。不要只看总里程降没降，因为一致性模型的短期里程一定会比纯成本模型高一点，长期看才会回归。上线前最好设定两周的灰度期，让模型充分学习历史数据，同时准备好人工干预通道，一致性约束绑得太死时能快速松绑。

我个人在实际项目里踩过最大的坑，就是一开始把一致性惩罚权重调得太高，结果所有客户都被锁死给历史司机，新增订单和临时调班完全没有腾挪空间，调度员怨声载道。后来学乖了，先在离线环境跑三天的历史数据，把权重、容量、时间窗全部验证一遍再上生产。最后分享一个判断模型是否起效的小技巧：不用看复杂的报表，直接拉三个不同日期的路线图叠加对比，如果同一批客户的司机点基本重叠，就说明一致性真正生效了。这个模型后续还可以往多目标方向扩展，比如把司机加班时长、车辆碳排放一起放进目标函数，扩展空间很大，先把手头的这套跑稳比什么都重要。