配送调度系统的报价从八万到八十万不等，跨度接近十倍。有意思的是，这个差额里真正被反复提及的分水岭，是“智能路径规划”这四个字。基础派单版本不含它，区域调度版本通常也不含它，只有四十万起步的平台级方案才把它列为标配。于是甲方最常问的一个问题是：路径规划到底算算法开发，还是接一个地图接口就完事？
这个问题的答案，直接决定预算量级，也决定项目风险落在谁头上。
从工程实质看，路径规划分两个层次。第一个层次是单点算路：给定起点和终点，返回一条路线。这部分确实接近接口调用，地图厂商已经把它封装成标准服务，按调用次数计费，接入方做的主要是参数拼装和结果解析。如果需求只是“骑手点开导航能到客户那”，接口调用就够了。
第二个层次是多点排序：骑手手上同时挂着若干订单，系统要在满足取送先后约束的前提下，算出整体最省时的配送顺序。这不是地图接口能直接回答的问题，因为地图厂商不知道骑手手上还有哪些单、每单的取送关系是什么、哪些单已经超时风险很高。它需要业务侧自己建模，把订单、骑手、时间窗、路网代价组织成一个可求解的问题，再决定用精确求解还是启发式搜索。这一步是算法开发，接口只是其中一个数据来源。
所以更准确的说法是：路径规划是一个复合体，接口调用负责提供路网和距离这类基础能力，算法开发负责在此之上做业务决策。把两者混为一谈，往往导致两种误判。
一种是低估。甲方以为路径规划就是接个地图接口，报价时按接口联调的工作量估，结果开发方发现要做多目标优化、要处理实时订单插入、要应对骑手改派，工作量远超预期，最终要么加钱要么砍功能。
另一种是高估。开发方把“智能路径规划”当成卖点写进方案，实际交付的却只是按距离远近排个序，遇到取送交叉、超时约束就退化。上线后调度员发现系统给出的顺序还不如自己凭经验排，功能形同虚设。
判断一个方案里的路径规划到底属于哪一类，有个相对可靠的问法：当骑手手上已有订单、新订单进来时，系统是重新计算整条配送链的顺序，还是只把新订单插到队尾。前者需要算法，后者大概率只是接口加排序。再问一句：如果地图服务商换了，业务代码要不要重写。如果路径逻辑和地图接口耦合在一起，换供应商就得大改，这本身就说明算法层没有被独立出来。
对预算有限的团队，比较务实的路径是分两期。一期先把订单分配、骑手定位、状态流转做扎实，路径规划用地图接口的单点算路顶着，调度顺序由人工微调。等单量上来、人工排单明显成为瓶颈时，再上二期做多点排序算法。这样既不会在需求还不清晰时为一个可能用不上的能力付费，也不会因为一开始省掉算法而把系统锁死在低效状态。
归根结底，路径规划算不算算法开发，取决于业务要它解决的是“怎么走”，还是“按什么顺序走”。前者是接口，后者是算法，两者的成本结构和交付风险完全不在一个量级。
