前阵子重构一个多场景路径优化项目，翻到第一个场景的代码骨架时，忍不住多盯了一会儿。最让我觉得有意思的不是搜索算子怎么写，反而是看起来最“平淡”的目标函数构建部分。很多朋友一听到“目标函数”四个字，下意识觉得就是把公式翻译成代码，没什么技术含量，但实际做下来会发现，目标函数才是整个求解器真正的灵魂所在——它定义了解的质量，决定了搜索方向，也直接影响最终方案的可用性。这篇就来聊聊第一个场景里代码骨架的设计思路，重点拆一下目标函数从业务定义到代码落地的完整过程。
这次的文章适合正在写优化类算法、准备搭元启发式代码框架、或者被“约束条件不知道怎么塞进目标函数”这类问题卡住的朋友。我会从代码骨架的整体结构讲起，再一步步拆解目标函数的各项构成、权重设计、Python实现和调试经验，全程用第一个场景作为例子，尽量让每个环节都能直接落到纸上。
1. 第一个场景的代码骨架到底长什么样
先交代一下背景。这个项目模拟的是一个城市配送场景下的车辆路径规划问题，整体分成了好几个场景，第一个场景是最基础的版本：单车场、单车型、无时间窗约束，车辆从同一个仓库出发，服务完所有客户点后返回仓库，目标是让总成本最小。这个场景可以看作整套代码的“最小可用版本”，后面所有复杂条件都是在这个骨架上叠加出来的。
所以第一个场景的代码骨架不能只满足于“能跑”，还要考虑后面场景怎么扩展。骨架要是搭得太死，第二个场景加时间窗、第三个场景加多车场的时候，改动量会大到你怀疑人生。我用的方式是按模块切分，每个模块只干一件事，模块之间通过输入输出解耦，具体可以看看下面这个结构：
| 模块 | 职责 | 关键输入 | 输出 |
|---|---|---|---|
| data_loader | 读取配送点坐标、需求量、车辆参数 | 原始数据文件 | 距离矩阵、需求数组、车辆容量 |
| solution_representation | 定义解的编码方式和可行性判断 | 客户序列 | Route对象或数组 |
| objective | 计算一条完整路线的总成本 | 路线、距离矩阵、权重参数 | 浮点数值 |
| operators | 定义邻域搜索动作（交换、插入、反转） | 当前解 | 新解 |
| search_framework | 搜索主循环，控制迭代和终止条件 | 初始解、算子集合 | 最优解 |
整个骨架的核心调用链很简单：读数据，生成初始解，进入搜索循环，不断用算子改造当前解，每次改造之后调用目标函数打分，然后根据分数决定是否接受新解。
# 第一个场景的代码骨架（精简版） class ScenarioSolver: def __init__(self, config): self.dist_mat = None self.demands = None self.capacity = None self.config = config def load_data(self, data_path): # 读取客户坐标和需求，预计算距离矩阵 pass def build_initial_solution(self): # 使用最近邻或最远插入生成一条合法路径 pass def objective(self, route): # 目标函数：计算总成本 pass def neighbor_operators(self, route): # 交换、2-opt、插入等算子 pass def search(self): # 模拟退火或禁忌搜索主循环 pass这套骨架我前后调整过三轮。第一版把目标函数和可行性判断混在一起，结果搜索阶段每次都要重复判断容量约束，性能很差。第二版把所有惩罚项都堆在一个大循环里，可读性又崩了。最后才收敛成现在这个结构：可行性判断由解表示层负责，目标函数只关心“给一条合法路径，算出成本”，惩罚项全部通过参数注入。这样做的好处是，后续要换目标函数版本时，只需要改objective模块内部逻辑，搜索框架完全不用动。
2. 目标函数构建：第一步不是写公式，而是把成本掰开揉碎
2.1 从业务成本到数学表达式的拆解过程
做目标函数最容易犯的错误就是一上来就翻优化论文找公式。第一个场景里，我先把实际业务中的成本列了个清单：车辆跑固定线路要花油费、司机要算工时、车从仓库开出去本身就产生折旧和出勤成本。落到这个最简单的配送场景里，总成本主要由两块组成——固定成本和变动成本。
固定成本就是每派出一辆车就要支付的费用，哪怕它只跑一个客户也得花这么多钱。变动成本则跟着行驶距离走，跑得越多花得越多。所以第一个版本的目标函数写出来就是：
总成本 = 固定成本 × 使用车辆数 + 单位距离成本 × 总行驶距离
这个公式看起来简单得过分，但实际做的时候有个关键细节：如何把“被使用的车辆数”用一个可计算的函数表达出来。在路径编码中，每个解的车辆数是确定的，由路线分割方案决定，所以这块其实不需要惩罚，直接统计路线条数就行。
不过要是只有这两项，算法很快就会走偏。因为完全没有约束信息的时候，模型倾向于把所有客户塞进一辆车里，这样固定成本只剩一份，虽然距离可能长一点，但总成本未必会吃亏。可是在真实场景里，一辆车是有容量上限的，不可能无限塞货。这就是为什么目标函数必须把容量、时间这类约束条件也“翻译”进去，不能只算成本和距离。
2.2 约束条件不是搭进去就完事，硬约束和软约束要分开处理
在车辆路径问题里，容量约束通常会被当成硬约束处理。什么叫硬约束？就是解必须满足，不满足直接判为非法。我一开始也是这么做的：目标函数计算之前先检查整条路线的总需求是否超过车辆容量，超了就返回一个很大的惩罚值，让搜索算法直接放弃这个解。
这样做本身没有错，但运行几轮之后问题就出来了：当问题规模稍微变大，初始解生成本来就不容易，再加上搜索过程中大量解因为容量限制被判为非法，算法的搜索空间被压缩得非常厉害，甚至出现搜了几万次迭代依然没有明显进展的情况。
后来我换了一种处理方式：容量约束不放到硬性合法性判断里，而是以一种“过载惩罚项”的形式写进目标函数。思路也很直白：如果路线总需求超过了容量，超出的部分乘以一个远大于正常成本的惩罚系数，加进总成本里。
对比一下这两种方式的效果差异：
| 处理方式 | 非法解的处理 | 搜索效率 | 最终方案质量 |
|---|---|---|---|
| 硬约束拦截 | 直接丢弃 | 搜索空间受限，迭代效率低 | 容易陷入局部最优 |
| 软惩罚纳入目标函数 | 允许保留但成本极高 | 搜索空间连续，平滑过渡 | 更容易探索出优质解 |
这个转变是我在实际跑实验时感触很深的一点。软惩罚方式有一个额外的好处：算法可以在迭代中期“借道”几个过载解，绕开某些难以穿越的搜索区域，到后期再被惩罚项拉回到合法区域。这在模拟退火这类带随机性的算法里尤其明显，比较顺畅地兼顾了探索和收敛。
2.3 时间成本怎么处理：没时间窗不代表不用等
第一个场景虽然不涉及硬时间窗，但客户点的服务时间其实没法忽略。每到一个客户点，卸货、交接、签字都要花时间，这些时间虽然不直接产生距离成本，却决定了司机一天能跑几个点。如果完全不计入目标函数，算法会觉得多绕路也无所谓，反正只看距离。
所以我在目标函数里增加了时间成本项。做法是给每个客户点预设一个服务时间，然后估算司机的小时工资成本，把服务时间和路上行驶时间都折算成钱。公式变成：
总成本 = 固定成本 × 车辆数 + 单位距离成本 × 总距离 + 单位时间成本 × 总耗时
这样一来，目标函数就从单一的“里程优先”变成了“里程+时间”的综合成本，更贴近真实调度场景。实际效果也很明显——同样的配送任务，最终方案的路程总长可能不是最短的，但综合成本更优，司机实际跑完全程所需的时间缩短了不少。
3. 权重标定与惩罚系数的确定：这一步特别容易被忽略
3.1 量纲统一，是目标函数能正确工作的前提
目标函数里有好几项成本，每项的量纲完全不同：距离是公里数，时间是分钟数，固定成本是元。它们绝对不能直接相加。比如一辆车的固定成本如果是200元，而某条线路的行驶距离成本只有30元，那固定成本会把距离成本完全淹没，算法只顾着少派车，完全不在乎距离有多离谱。
所以第一步就是做量纲统一。我按实际业务单价把所有项全部换算成“元”。假设单位距离成本0.8元/公里，司机工时成本0.5元/分钟，固定出车成本80元/车。那上面那个公式每一项都已经是“元”了，可以直接相加。
这里有一个非常实操的小细节：换算的时候要注意单位陷阱。比如“小时工资”和“分钟成本”之间差着60倍，如果代码里直接拿来用，目标函数的平衡性会被彻底破坏。我习惯在配置里统一用最小单位写清楚，变量名叫cost_per_minute而不是cost_per_hour，从命名上就避免这种坑。
3.2 惩罚系数到底设多大才合适：用“代价换算”代替“瞎猜”
容量过载惩罚系数怎么定，是最容易让人纠结的地方。我用了一个相对靠谱的方法：把“超载一单位的代价”和“绕行一公里的代价”做对比。
比如车辆容量是100箱，超载1箱可能带来的实际损失（比如需要二次配送、违规风险折算）估算为10元，那单位超载惩罚就是10元/箱。这个值要比单位距离成本大很多，但又不能大到完全排斥任何过载解，否则又回到硬约束的老路上去了。我在第一个场景里把超载惩罚系数设为距离成本的20倍左右，搜索过程和最终结果都比较平衡。
给一个实际配置参考：
| 参数 | 数值 | 说明 |
|---|---|---|
| 固定出车成本 | 80 元/车 | 只要派车就要付 |
| 单位距离成本 | 0.8 元/公里 | 油费、车辆损耗的折算 |
| 单位时间成本 | 0.5 元/分钟 | 司机工资折算 |
| 容量过载惩罚系数 | 16 元/箱 | 距离成本的20倍 |
| 提前到达等待惩罚 | 0.2 元/分钟 | 第一个场景暂未启用，只做预留 |
这里顺便多说一句，很多人调参是凭感觉，今天改成15，明天改成20，跑出来的结果根本没法对比。我后来养成的习惯是，每次调参都归档记录当时的测试场景和结果，哪怕只是改一个系数，也把前后两组实验的图上差异标注出来。时间久了，这些记录就是最有价值的经验库。
4. 实操：第一个场景目标函数的Python实现细节
4.1 输入数据结构与计算主逻辑
写目标函数之前我先把输入数据缓存好。距离矩阵是提前算好的二维数组，dist_mat[i][j]表示从点i到点j的行驶距离。每条路线用一个客户点编号列表表示，从仓库出发，按列表顺序访问每个客户点，最后回到仓库。
目标函数的主逻辑分成几步：先遍历路线上的相邻节点，把每一段的距离累加起来得到总行驶距离；再累加所有客户点的服务时间；然后统计当前路线使用的车辆数；最后把容量过载量算出来，乘以惩罚系数，加进总成本。
这一步的代码其实不难，难的是怎么把数组操作写得高效。一开始我用Python原生循环去算距离总和，客户一多、迭代次数一上来，光是目标函数这一层就占掉了大部分运行时间。后来全部改用NumPy的索引操作，性能明显提升。
4.2 目标函数核心代码实现
import numpy as np class DeliveryObjective: def __init__(self, dist_mat, demands, vehicle_capacity, weights): self.dist_mat = dist_mat # 二维数组，dist_mat[i][j]表示点i到点j的距离 self.demands = demands # 每个客户点的需求量 self.capacity = vehicle_capacity self.fixed_cost = weights["fixed_cost"] # 单辆车固定成本 self.cost_per_km = weights["cost_per_km"] # 单位距离成本 self.cost_per_min = weights["cost_per_min"] # 单位时间成本 self.penalty_per_unit = weights["penalty_per_unit"] # 容量超载惩罚系数 def compute_route_cost(self, route): # 计算单条路线的行驶距离 seq = np.array([0] + list(route) + [0], dtype=int) segment_dist = self.dist_mat[seq[:-1], seq[1:]] total_distance = float(segment_dist.sum()) # 计算总需求量 total_demand = int(self.demands[route].sum()) # 计算总服务时间（假设每个点服务10分钟，仓库和点之间行驶时间按距离估算） service_time = 10.0 * len(route) travel_time = total_distance / 30.0 * 60.0 # 假设平均车速30km/h total_time = service_time + travel_time # 计算各项成本 fixed_cost_part = self.fixed_cost distance_cost_part = self.cost_per_km * total_distance time_cost_part = self.cost_per_min * total_time # 容量过载惩罚 overload = max(0, total_demand - self.capacity) overload_penalty = self.penalty_per_unit * overload return fixed_cost_part + distance_cost_part + time_cost_part + overload_penalty def compute_total_cost(self, routes): total = 0.0 for route in routes: total += self.compute_route_cost(route) return total这段代码用了NumPy的花式索引来算距离。self.dist_mat[seq[:-1], seq[1:]]这一行，本质上就是一次性取出所有相邻节点对的距离，比写for循环快得多。实测在几百个客户点规模下，单次目标函数计算从毫秒级降到了几十微秒级。
关于时间成本这里有个值得思考的点：上面代码里时间成本已经把“行驶时间”折算进总耗时了。如果平均车速是30km/h，那每公里要跑2分钟，按0.5元/分钟折算的话，相当于每公里时间成本是1元，比距离成本0.8元还高。也就是说在这个参数设置下，算法会更偏向于缩短总时间，而不是单纯缩短里程。这种倾向是不是符合实际业务需要，完全取决于场景本身，所以我习惯把参数全部留在配置里，而不是写死在代码中。
4.3 为什么目标函数不能用“最小化距离”替代
可能有人会问，第一个场景又没时间窗，为什么不能直接把行驶距离作为目标函数，简单直接还省事？我在实际对比测试中专门验证过这个问题。
只优化距离的做法会让算法天然倾向把所有客户塞进尽量少的车次里。因为每多开一辆车，就产生一份从仓库到第一个客户点的“空驶距离”，这部分距离对只计算总里程的算法来说是很不划算的。结果就是算法会疯狂让一辆车跑尽可能多的客户，即便中间绕行再大也认了。但真实业务里面，车辆的装载容量、司机每天的最大工作时长都是有上限的，只优化距离等于把这些约束全丢掉了，出来的方案基本没法在实际中执行。
所以从这个角度看，目标函数构建的核心不是“我选哪个目标最好”，而是“哪个目标函数形式可以同时表达业务目标和业务约束”。为什么很多项目跑出来的算法方案总是被业务方吐槽“没法用”？绝大部分原因不是算法不收敛，而是目标函数根本没有完整地表达业务的真实诉求。
5. 调试实录：目标函数相关的典型问题与排查技巧
5.1 目标函数值异常偏大或偏小，先查量纲
有段时间我发现目标函数输出数值在小数点和几万之间反复横跳，后来定位到问题出在时间单位上。我把某个模块返回的耗时从“分钟”直接当成“小时”处理，单位换算差了60倍，导致时间成本项和其他项完全不在一个数量级上。
排查方法很简单：构造一个只有两个客户的极简场景，手工计算各项成本，和代码输出做对比。如果对不上，逐项打印距离成本、时间成本、固定成本、惩罚项，看哪一项的量级跟预期不符。我几乎每次排查最后都能在打印日志里一眼看出问题在哪，毕竟各项成本的正常量级是可以通过业务常识快速估算出来的。
5.2 惩罚项完全不起作用怎么办
出现过一种现象：路线严重超载，但目标函数数值和合法路线相差无几，导致算法一直输出超载方案。问题几乎都出在惩罚权重太小，超载惩罚在总成本里的占比很低，被其他成本项淹没掉了。
这种情况下可以做一个简单的灵敏度测试：把惩罚系数从1倍、5倍、10倍、20倍、50倍递增，看看最终解的超载水平会不会随之下降。如果惩罚系数调到很大了依然有超载，那基本可以确定不是权重问题，而是解的表示层根本没把超载信息传进来。
5.3 目标函数出现NaN，先排查距离矩阵和空路线
NaN的问题在算法中期突然冒出来时，最常见的原因有两个：一个是某个节点编号越界，导致距离矩阵访问时拿到非法值；另一个是搜索过程中生成了空路线，对空数组直接求和时返回了一个奇怪的值。
我的习惯是在目标函数入口加一层简单的防御性检查，如果route为空数组，直接返回一个极大值作为成本。这样既避免了程序崩溃，也相当于把非法解挡在搜索流程外面。这一类问题在调试日志里其实很容易认出来，关键是目标函数要有清晰的输入输出边界，不要试图在函数内部处理所有异常，应该让上层调用方来保证输入合法性。
5.4 常见问题速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 目标函数值数量级异常 | 时间/距离/金额单位混用 | 统一换算成同一量纲，用最小单位命名参数 |
| 最终方案总是超载 | 惩罚系数过小，被成本项淹没 | 做惩罚系数灵敏度测试，按实际成本测算系数 |
| 目标函数偶发NaN | 节点索引越界或空路线 | 入口防御性检查，空路线返回极大值 |
| 距离成本主导一切 | 固定成本或时间成本设置过低 | 调整权重，参考实际业务单价 |
| 目标函数计算太慢 | Python循环遍历距离矩阵 | 改成NumPy花式索引批量取值 |
6. 后续场景怎么扩展这套目标函数
第一个场景的目标函数稳定跑通后，第二个场景开始加入时间窗约束。这个扩展比想象中顺利，因为我前期把约束条件全部用惩罚项方式预留好了。加时间窗只需要在目标函数里额外增加一个“早到”“迟到”的成本函数：早到要等待，司机时间成本照付；迟到可能要有违约损失，单位惩罚设置得比等待成本更高。这两项加进去，目标函数就从“成本+容量惩罚”变成了“成本+容量惩罚+时间窗惩罚”，其他模块完全不用动。
第三个场景再加多车场时，目标函数会新增一项“车场开放成本”。不同车场的开放成本可能不一样，车辆的起始点和终止点也不再是同一个仓库。对这个场景，代码骨架只需要把fixed_cost从固定值改成按车场读取，然后把每条路线首尾对应的车场编号纳入计算，整体架构完全扛得住。
我自己在几个场景反复迭代之后最大的体会是：代码骨架的模块划分和参数化设计，决定了后续加需求时你是改十行代码还是改一百行。目标函数构建更是如此，刚做第一个场景的时候，多花一点时间把“成本项”和“约束惩罚项”的边界划清楚、把权重配置独立出来，后面所有场景的接入都会顺利很多。如果你也在写类似的优化项目，建议先别急着调搜索算法，静下心来把目标函数这层一次做扎实。
