业务员清晨打开 APP，拜访列表按距离由近到远排列，看起来合情合理。真正跑一天却常常变成折返：上午在城东，下午被一条跨区门店拽回城西，晚上再补一家近的。单点导航解决的是“怎么去下一家”，而巡店路线要解决的是“这一天该按什么顺序去哪几家”，两者不是同一个问题。TSP（旅行商问题）路径优化算法进入巡店系统的价值，正在这条分界线上。
从排序到排程
TSP 的经典定义很简洁：给定一组网点和两两之间的通行成本，找一条遍历全部网点、总成本最低的闭环。网点数量增长时，可能的排列组合呈阶乘级膨胀，精确求解很快就不现实，工程上通常采用启发式方法求近似最优解。这也解释了为什么巡店系统里“按距离静态排序”只是入门形态——它把多点决策降级成了单点排序，省下的开发工作量，最终会以业务员多跑的里程体现出来。
但巡店的路线优化并不是教科书问题。门店有营业时间，有的商场要到固定时段才允许入场；不同等级的门店执行堆头、货架检查的耗时不同；拜访频次本身是一套规则，周访、双周访、重点门店加密，路线必须与频次日历一起编排。约束叠加之后，问题从纯几何路径变成带时间窗、带优先级的多网点排程，输出也不该是一张路线图，而是一份可以直接执行的当日拜访计划。
落地时的三个现实约束
算法再漂亮，也要落到真实数据和真实网络上。网点之间的通行成本依赖地图服务商提供的路径规整与里程计算能力，这类商用接口有授权和调用成本，属于开发预算之外的持续开销，方案初期就该算进去。外勤场景常出现在地下商超、偏远乡镇，弱网下连距离矩阵都拉不全，系统需要有本地兜底策略，而不是把页面卡在加载状态。
更关键的是，计划排出来只是开始。业务员的实际轨迹与计划路线一旦偏离，系统要能识别异常偏航和漏访，把偏差回流成下一轮编排的依据。只有闭环存在，算法才不是一次性输出的黑盒；否则调度人员无法解释为什么今天被派到这条线，最终仍会退回手动调整。
判断是否值得投入，不必看算法名词，先看三件事：网点规模是否已经大到人工排线难以兼顾、拜访频次规则是否足够复杂、以及是否积累过真实的历史里程与到店时长数据。通常建议先把一线督导和区域主管的拜访动线规则整理清楚，再谈模型选型——数据与规则的质量，比求解方法更早决定这套系统能不能用。
