别急，先搞清楚谁需要最短路径拣货算法
跑通最短路径拣货算法，在业内已经不是新鲜事。但我要先泼一盆冷水：如果你的仓库日订单行不足 3000 行，或者平均每单拣货行数不到 2，我建议你现在就关掉这篇文章，去优化你的存储策略、完善库位准确率，带来的收益绝对比跑算法来得大。我见过太多中小仓库盲目跟风上算法，结果系统算出的路径比老拣货员凭直觉走的还多绕了三成距离，最后系统被闲置，员工怨声载道。
但在真正需要它的场景里，比如日均万单以上的电商大仓、连锁零售的分拨中心、SKU 数上万的冷链仓库，把拣货员每天的步行距离从 18 公里降到 8 公里，不是纸上谈兵，这是实实在在在三个仓库里验证过的结果。
这篇文章不打算重复教科书上 A* 算法和 Dijkstra 算法的异同对比，也不打算贴 GitHub 上你瞬间能搜到的几千行代码。我想做的事，是把你拉回真正做决策的那一刻：当你决定在 WMS 里嵌入最短路径拣货算法的时候，你的技术选型、落地瓶颈、团队阻力、甚至算法本身该不该被“优化”，背后的真实取舍是什么。
核心结论很简单：最短路径拣货算法落地的成败，从来不在算法本身，而在于数据治理的成熟度、波次策略的耦合设计、以及系统与人的握手协议。这三个因素随便漏一个，算法最优解也是废纸一张。
所有最短路径算法的起点，都是一个可计算的图。在仓库里，这个图不是画在 CAD 图纸上的通道网格，而是一个包含了以下约束条件的加权有向图：
综合来看，一个可用的拣货地图节点数，至少应该是储位数的 1.7 到 2.3 倍（含通道节点、转弯节点和作业区边界节点）。我见过最糟糕的情况是某仓库直接用了 ERP 里的库位列表当节点，结果地图上仓库物理布局完全错位，从第 9 通道走到第 10 通道这条路，在真实环境里是一堵墙。那次项目的项目经理被老板拍了三回桌子。
算法落地失败的第二个常见原因，是业务方以为“最短路径”意味着“每一个波次都重新计算全局最优”。这是对实时计算压力的严重误判。
一个日均波次数 80 个、每波次 200 到 300 行的仓库，如果用实时在线计算（每个波次释放时都重新跑 Dijkstra），平均每次求解耗时约 1.2 到 1.8 秒。听起来还好，对吧？但别忘了，WMS 系统一般要等路径计算结束，才把第一批拣货指令推送到到 PDA。80 个波次的延时累积，就是两到三分钟的订单释放延迟。
更重要的是，实时计算的路径结果不一定比预计算方案更优。我之前把两个方案做过对比测试：
一个 8000 平方米、4300 个 SKU 的仓库，连续跟踪了 7 个工作日，在线实时方案比离线方案平均每个波次少走了 27 米（约 2.3%），但代价是 WMS 响应时间增加了 8.3 秒。这个性价比，在大多数仓库里不值得。除非你的仓库通道频繁变更、或者订单行分布极度不规律，否则离线预计算加微调，是更务实的做法。
有一个事实我必须在前面就说清楚：当你的系统认为 2 号通道第 5 排第 3 层储位有一个 SKU 存在，但拣货员到了现场发现是空位时，整个路径规划就报废了。算法不会考虑“库存可能不准确”这个概率事件。
我参加过某家快消品仓库的算法上线验收，他们当时的库存准确率是 93%。你猜怎么着？路径算法上线后，每 14 次拣货就会有一次到达储位后发现货物缺失，然后系统必须重新规划：要么从备用储位补货，要么跳过该行。平均每次异常会多花费 47 秒，并让后续路径的“最短”属性完全失效。
如果你的库存准确率低于 96%，我建议你先别部署最短路径拣货算法。这不是算法问题，是基础数据问题。
这是最大的认知陷阱。只要在仓库现场待过三天就知道：“最短”是距离属性，“最优”是综合指标。在一个 5000 平方米的仓库里，最短路径和实际最佳路径之间可能有 15% 到 20% 的偏差，因为系统没有考虑以下因素：
我接手优化的一个仓库，最短路径算法算出来的路线让拣货员在 3 号通道 5 层高货架取了某个零散件之后，紧接着走到 4 号通道的最底层取一个箱子。距离确实短，但拣货员必须在通道里弯腰、站起、再弯腰，体感效率实际上比走“S 型”差了一截。最后我们在路径评分里加入了一个“垂直动作惩罚系数”，每个层位变化计罚 4 米等效距离，路径效率才回归正常。
有人一听到“最短路径”，就觉得应该是 Dijkstra 或 A*，如果不用这些就不好意思叫“智能拣货”。但实际上，在很多仓库里，贪心算法 + 分区策略的组合，比 Dijkstra 更好用。
为什么？因为真实仓库的拣货场景不是一个静态图。Dijkstra 算出来的确实是理论最优路径，但这个最优路径前提是订单行固定、储位固定、通道畅通。一旦发生任何扰动（补货中途占用通道、系统延迟导致某些指令提前释放、用户取消订单），Dijkstra 就需要重新计算。而仓库跑 Dijkstra 的代价是多少？
我之前做过一个性能压测：在一个 3285 个节点的仓库图上，Dijkstra 单次求解平均耗时 612 毫秒（C# 实现·服务器单核 3.2GHz），而一个简单的贪心算法（最近邻搜索+历史路径复用）仅需 24 毫秒。两者的路径长度差异平均只有 6.7%。考虑到贪心算法的实现难度、运维成本、和抗干扰能力，这 6.7% 完全值得牺牲。
所以，不要迷信 Dijkstra。你做落地的目标，不是让算法竞赛评委给你打满分，而是让仓库里的拣货员在每天结束时少走 6 到 8 公里。
这是我见过最天真的想法。实际情况是：哪怕你跑通了一个完美的最优路径算法，你还是需要给拣货员至少留 15% 的自主路径选择权。
一线拣货员多年积累的经验里，包含了大量系统无法量化的信息：“2 号通道尽头前天放了整箱退货，系统没更新，实际根本走不过去”；“7 号储位那个人经常把条码面贴反，我得绕到对面看”；“3 楼的那个 SKU 最近经常破损，我去之前要先去岗位拿胶带。”
当系统给拣货员规划的路径被拒绝超过 12%（我们在三个仓库统计的数据），最终退化为“不用系统，我自己走”。所以我的建议是：在算法中增加一个“人工覆盖”通道，当拣货员选择不按系统规划路线走时，允许他自主行走，系统只做后续路径的重新计算，而不是强制锁定，这在很大程度上提高了系统的接受率。
来，我帮你搞一个简单粗暴的决策参考：
| 仓库画像 | 订单特征 | 推荐算法策略 | 不建议方案 |
|---|---|---|---|
| 单区小仓库，通道单一 | 行均 3-5 行，峰值 2000 行以下 | S 型走法 + 分区固定路线 | 任何最短路径算法（没必要） |
| 多区中型仓，通道直角矩形网 | 行均 2-4 行，日均 5000-10000 行 | 贪心最近邻 + 分通道预计算 | Dijkstra 实时计算（响应慢） |
| 大型平台仓，不规则或多楼层 | 行均 1-2 行，日均 15000 行以上 | A* 启发式预计算 + 在线微调 | 纯离线方案（灵活性不足） |
| 冷链、医药等特殊环境 | 温度分区异构，行均密集 | 时间窗约束 Dijkstra 变体 | 无时间约束的通用算法 |
注意，以上推荐基于我自己的实施经验，但每家仓库的货架排布、通道宽度、拣货工具（地牛、手推车 vs. 电动托盘车）都会影响最终选择。我去年在一个医药仓里花了一个月才意识到：由于他们的货架厚度不均，两条通道之间的实际穿行距离和理想距离差了 2.7 米，导致我写的 A* 启发函数完全失准。后来把“估距”改成“模拟漫步”后，误差才降到 1.2% 以下。
当你决定选一类算法后，还需要在以下三个指标间做权衡。这是我整理的一个决策阶梯：
第一优先级：求解时间。如果算法计算时间超过 WMS 的波次释放时间窗口，统统淘汰。以常见场景为例：ERP 要求波次释放后 5 秒内生成拣货单，你的算法最多占用 3 秒（留 2 秒给其他业务逻辑）。超过的直接不选。
第二优先级：路径综合效率。“纯距离”不是唯一指标，要考虑拥堵惩罚、垂直换层代价、以及波次间的进度均衡。我一般是把距离、拥堵概率（历史数据预测）、和换层次数加权算出一个复合评分。权重需要跑至少两个星期的跟踪数据来标定。
第三优先级：热更新能力。当货位变化、通道临时封闭或仓库进行波次切换时，算法多久能重新收敛。贪心算法几乎没有预热期，而 Dijkstra 变体在频繁变化场景下需要每秒重新建图，我在某仓库就看到过由于热更新太慢，导致 PDA 显示的地图和真实仓库相差了 6 分钟，这是无法容忍的。
如果在做技术选型时你自己也没谱，先回答下面四个问题：
只要有一条不清楚或存疑，就先别急着跑算法，先去补课。否则上线一个月后，你很可能需要对老板说：“算法是好的，但数据拖了后腿。” 这种话我已经从三个客户那里听到过了，说多了，连自己都觉得像借口。
经过三年时间、跨越十几个仓库的项目，我越来越清楚一个事实：最短路径拣货算法的落地，70% 是人的问题，20% 是数据问题，只有 10% 是算法本身的问题。那个 70% 比例不是随便说的。在我统计过的 14 个实施案例里，算法上线后的头两周，至少有一半的拣货员的路径拒绝率超过 35%。这期间如果不采取干预措施，后面几乎就没戏了。
但这不等于说我们就要“强行规定”。我特别推荐的策略是：建立人机协同的“握手协议”。
握手协议具体指什么？每台 PDA 上，在显示系统推荐路径的同时，增加一个“自主规划”按钮。拣货员可以选择是否采纳系统方案。当拣货员拒绝系统路径的次数超过 5 次后，系统会弹出一个极简的对话框：“您觉得刚刚哪里不好走？” 收集足够多的反馈（约 300-500 条）后，把这些拒绝点作为额外权重向量，反馈给算法优化。一个周期下来，路径接受率可以从 68% 提高到 88% 以上。
我们做过一个测试：在同一个仓库，同一个波次，前两个月不给任何互动按钮，路径接受率 62%；后两个月加上握手协议，接受率升到 87%，而且拣货员自己汇报的平均每日步数从 21,346 步降到了 16,873 步。
你有“最优路径”算出来了，但 PDA 上的箭头指令能不能跟得上拣货员步行的节奏？我遇到过一个案例：我们的路径算法计算时间不到 200ms，但 PDA 屏幕上的“下一个指令”更新延迟平均达到 1.8 秒。因为在仓库深处，Wi-Fi 信号衰减很严重。
这不只是一个“网络不好”的小问题，它真实地破坏拣货员的节奏：走到货位前，去看 PDA 时它还在转圈圈；好不容易显示了，又发现它告诉你这不是这个货位。最后拣货员的结论是“这系统不好用”。
解决方式其实很简单：采用离线缓存 + 同步模式。把整波次的路径数据预先缓存在 PDA 本地，而不是每次都去服务器请求“下一步走到哪”。本世纪初的 PDA 就支持这种缓存方式，但现在很多公司在开发时却忘了这茬。
在仓库现场，管理者往往希望算法是个黑盒：点一个按钮，输出正确结果，他们不需要知道内部逻辑。但这不是一线员工的想法。他们认为自己在仓库里走了十几年，不知道为什么一个后来者搞的“算法”能比我聪明。
所以我做了一件事：给每个波次的路径结果附上一句极简的“规划理由”，中文本地化那种，不是技术术语。“系统建议你先去 3 通道取 A 类 SKU，因为 B 类 SKU 在 5 通道靠里，两个在物理上更近。” 就是这么简单的解释，让拣货员的接受率在两周内提升了 21 个百分点。
这件事背后的心理学机制很直白：人天生对“未知决策来源”有排斥，一旦系统展示了它的逻辑（哪怕这个逻辑极其简单），信任度会自动升高。
如果你决定启动一个最短路径拣货算法的落地项目，我给出一份经过验证的 12 周行动路线图。这是我从过去五年里十几个执行得比较好的项目里提炼出来的，不是办公室的推演。
| 阶段 | 周数 | 核心任务 | 交付物 | 卡点检查 |
|---|---|---|---|---|
| 一、基础治理 | 第 1-2 周 | 数字化仓库拓扑地图；移动巡检所有储位，校准坐标，标记通道宽度 | 地图验收报告（误差 ≤ 0.5m） | 库存准确率是否达 96%？ |
| 二、算法研发 | 第 3-5 周 | 根据地图建立图结构；选型并实现算法（建议从贪心开始）；跑 A/B 测试对比 | 算法白盒演示 + 路径效率报告 | 求解时间是否控制在 3 秒内？ |
| 三、联调联试 | 第 6-7 周 | WMS 对接；PDA 显示变更开发；数据缓存模式上线 | 联调测试报告 | PDA 响应延迟是否 ≤ 200ms？ |
| 四、小范围试运行 | 第 8-9 周 | 选 4-6 名骨干拣货员试跑；收集反馈；优化握手协议 | 试运行分析报告 | 路径接受率是否 ≥ 75%？ |
| 五、全面推广 | 第 10-11 周 | 全员上线；安排简单的路演培训（讲清楚系统逻辑） | 全员培训记录 | 日均拒绝次数是否 ≤ 1.5 次？ |
| 六、复盘迭代 | 第 12 周 | 分析波次耗时、拣货员步数、路径拒绝分布；调整权重参数 | 效果评估会议 | 人均步数是否有 ≥ 20% 降幅？ |
这份路线图的关键不在于时间表的粗细，而在于每个阶段有没有“卡点检查”。用我上一家服务的客户的一句话来说，以前他们只是把算法部署完了就认为结束了，结果三个月后系统直接被骂成废物。后来他们在第 3 周就发现问题：库存准确率只有 92%，然后他们停下整个项目、花了两周大扫除库存，半年后算法真正跑起来，效果很好。该停就停，比硬着头皮上线强十倍。
假设你熬过了前 12 周的阵痛，系统已经在稳定运行，拣货员每天少走 6 公里，老板在季度会上表扬了信息部。现在做什么？
我给你的建议是：不要躺在算法上。因为通道部署半年后，你的仓库结构可能出现变化；员工的意见可能二次演化；甚至业务模式可能开始向“团购”或“ToB 大单”转型。如果你不建立一个持续优化的机制，6 个月后的算法最优解可能还不如一个人工经验的老员工。
具体来说，我建议你做三件事：
我自己手头正帮一个家装材料仓库设计“人机混场”的调度，他们手上有 6 台自动导引车和 15 名拣货员同时在仓库活动。算法要算的不仅仅是“哪条路更短”，还有“这个时间段让谁去更合适”。这是一个新课题，但工具和方法论都是从最短路径算法一步步长出来的。
这篇文章写完的时候，我又跑去读者中间问了一圈，收了大概 30 多条反馈。很多人问：“你讲这么多，有没有能直接复制粘贴的代码？”
我的回答是：代码不重要，决策框架才重要。如果你真的下决心去做，算法代码可以在几个小时内搞定，而搞清楚自己的仓库适不适用、该用什么策略、有没有基础数据去支撑，才决定了你的项目成功或失败。
我把自己过去一年不断迭代的决策模板打包成了一个 Word 文档，里面有我前面讲的内容、四道问题自检清单、以及 12 周路线图的检查表。你也可以直接在后台回复【路径算法】获取。当然这只是助力，不是最终方案，拿到后你还是要自己拆解自己的仓库。
下一步做什么？
先把你手边仓库的数据拉出来看看，看看库存准确率、波次延迟率、拣货员日均步数这几个数值。就这三个数字，大概就能让你知道你的仓库适不适合跑最短路径。
如果觉得现在不是时候，记得把这篇文章收藏，等你有朝一日被老板逼着问你“能不能用算法让效率翻倍”的时候，拿出来再看一遍。
读者评论
文章说得很实在，我们仓库日均订单行不到3000，之前跟风上了算法，结果路径比老员工凭直觉走还多绕了三成，系统被闲置。后来回归优化库位准确率和存储策略，效率反而提升了。中小仓库千万别盲目上算法，先打好基础。
作为一线拣货员，最怕系统规划的路径不考虑现场拥堵和货架变动。文中提到要给15%自主权，太对了。我们仓库强制走系统路线，结果经常在窄巷子撞车，最后大家都不用，还是凭经验走。算法得尊重实际操作才行。
数据很关键，库存准确率低于96%别上算法，这个判断值得参考。我们做冷链仓库，日均万单，文中提到的步行距离从18降到8公里很有吸引力，但会先评估数据治理成熟度。波次释放策略和离线预计算方案也是务实选择。
作者分享的贪心算法+分区策略对比Dijkstra的实测数据很有价值，6.7%的路径代价换来25倍响应速度，维护成本还低。实际落地中算法复杂度不是越优越好，A*启发函数失准的例子很典型，需要根据仓库布局调整惩罚系数。