物流与运输：局部更快，整体更好吗

一张订单抵达系统，离货物送到门口还很远。

物流平台Nash在2025年6月发表的客户案例里，洛杉矶商家Pink Dot此前要把电商平台Shopify中的订单人工复制到另一个系统，再打电话分配司机。双方从当年2月开始合作，随后通过接入订单、自动派车来减少这段人工传递。¹ 这是一份供应商记录，不能单凭它确认整体经营效果；但订单怎样从销售入口走到司机手里，已经清楚可见。

这样的改动容易理解：去掉一次复制，省下一通电话，订单更快开始移动。然而，若车辆提前到了，货物还没备好，时间又会停在另一处。若更快派车把大量订单同时送进仓库的装货口，前端的进步也可能成为后端的拥堵。

物流里的“快”，总要接着问一句：哪一段更快，谁因此多等了，承诺最终有没有兑现？FDE进入这个行业，面对的不只是软件能否理解一条要求，还要让要求在货物、车辆、人员和时间之间成立。

订单首先是一组承诺

为了沿途看清问题，先建立一个教学情境。某配送中心接到一批订单，其中一单约定下午送达，收货点在一栋办公楼的后侧，只在特定时段接收；货物需要两人搬运。以下过程是本书构造的推演，不是对某个真实客户内部流程的复原。

如果系统只看到地址和距离，这一单可能很容易安排：找最近的车，连上附近几单，给司机一条路线。但它遗漏了决定能否送成的条件。那辆车上有没有两个人？货物是否已经完成备货？到楼前算抵达，还是到收货口才算？如果错过接收时间，车辆要等候、改送还是回仓？每一个答案都会改变所谓最佳路线。

这里可以把条件分成两种。硬条件不满足，方案就不可执行，例如车辆容量不足；偏好则可以在付出代价后改变，例如希望尽量少绕路。两者混在一起，会造成两种相反错误：把偏好写成绝对限制，系统失去可用选择；把必须满足的条件写成普通偏好，算法就可能用一笔便宜报价换来根本无法完成的运输。

谁来分清它们？业务负责人知道客户承诺，仓库知道备货和装卸，承运方知道车辆与人员，调度员知道临时例外。软件团队负责把这些条件变成可以检验的规则，但无权独自决定某项承诺是否可以牺牲。FDE贴近现场的意义，首先是在这些人之间把问题问完整。

Nash的CTO Aziz Alghunaim在2026年8月6日明确介绍其FDE实践：工程师需要理解客户的仓库系统、承运合同和真实约束；切换前让平台与既有方案处理同样的需求，比较单次配送成本、约束符合和人工介入，并准备回退方式。² 这是公司对交付方法的自述，并非独立的成效审计，却具体说明了工程师要把什么带进系统。

Pink Dot的较早案例没有写明FDE职衔，不能因为Nash后来公开采用这个组织名称，便把历史项目全部追认成FDE。已读材料能把工程接入与FDE方法并置，却尚不能还原一名具名FDE在该客户如何修改约束、由谁验收。因此本章用下面的合成调度题检查方法的含义，不把题目的结果补进真实项目史。

地址正确，目的地仍可能错误

物流有一个很容易被屏幕遮住的事实：地图上的点，并不等于完成任务的位置。

UPS在2018年公布UPSNav时，特别说明它把司机引向具体的装卸区和收货位置，而不只是建筑入口；司机和其他员工可以修正地图。公司明确把它描述为内部开发的导航技术。³ 这不是一个FDE项目，却是很有力的对照：将现场知识变成运行系统，早已是运输工程的重要工作，并不因为出现新的职位名称才开始。

回到教学中的办公楼订单。若导航把车带到正门，司机可能已经完成系统认定的“抵达”，实际卸货却尚未开始。调度看见绿色状态，客服告诉客户货物已到，仓库也不再关注；真正的问题被留给司机在现场找人解决。数据没有丢，错误出在它代表了一个过早的完成。

这一类问题需要工程师和业务一起定义事件。车辆进入附近区域，可以表示“接近”；在指定点停车，表示“到达收货点”；货物交给合适的接收人并留下证据，才能表示“交付”。不一定要为所有小包裹引入复杂流程，但对昂贵、笨重或有特殊要求的货物，这些区别决定后续责任能否接得住。

关键不在于把状态名称越分越细，而在于哪一个状态会触发哪一个动作。谁一收到“抵达”就开始计费，谁会停止催办，谁会向客户发消息？只要下游因此作决定，这个词就有实际后果。FDE在这里处理的，是业务含义穿过软件接口之后还能不能保持一致。

现场更正也需要回到长期资料中。司机今天发现入口变了，下一位司机明天能否得到同样的信息？可以把更正先标为待核，保留来源和时间，再由合适人员确认。不能把一次临时绕行永久设成所有车辆的默认路线，也不能因为担心错误，就让可靠的新信息永远只留在个人手机里。

这类反馈机制有成本：需要有人判断更正范围、处理冲突、淘汰过期资料。它不像一个新模型名字那样显眼，却决定系统是否会随着现实改善，还是把旧经验自动化得越来越熟练。

一辆车省了时间，其他订单呢

继续追踪这张教学订单。车辆快装满时，又来了一单顺路货。如果只看这一趟的装载率，把它加进去似乎是好事；但备齐它还要等待，原来已经装好的订单就可能错过约定时段。装得更满和送得更准，并不是同一个目标。

简单规则往往各有合理来历。“尽量满车”可以降低空驶，“先到先处理”方便解释，“自有车辆优先”可能符合已有成本安排。问题出在它们同时出现时，究竟哪条优先。系统不可能靠更有说服力的语言消除冲突；要么有人设定取舍，要么冲突会在运行中以延误或人工救场的形式显现。

把教学订单缩成两单、两辆车，就能实际算一次。O1是那件需要两人搬运的办公楼货物，重120公斤；O2重80公斤，只需一人。V1容量200公斤、两名作业人员，出车成本80个教学费用单位；V2容量100公斤、一名作业人员，出车成本50。两车起初都在仓库，费用只用于此题，不是运输报价。接收窗口指开始卸货时刻。

先记住两个硬条件：这两辆车里，O1只能由V1承运；O2最迟要在14:05开始卸货。

两处收货点之间行车25分钟。把O1交给最近可出发的V2不可行：容量和人数都不足。让V1先送O1再送O2也不可行：等O2在13:30备好后一起出发，14:10开始卸O1，14:30结束，再开25分钟到O2时已是14:55。多叫一个“优化模型”不会使这两个方案可执行。

原定的合单计划尚未执行。到了13:35，仓库确认V1最早13:50才能离仓，两单都未装车；若仍合单，O2要14:10才到，超过14:05的窗口。仓库先确认O2从V1清单解除，再将它改派给V2。把原计划与改派并排看，时间和代价就清楚了：

原计划满足两项窗口；相比分别派两车的130费用，合单节约50，却压缩了余量。调度负责人应看见这项代价，而不只收到“最低成本”标签。改派后两项承诺仍可履行，但O1已无余量，需要继续监控。若O2已经装车，不能照抄这次改派，须先确认货物转移。

两单两车的约束与改派记录提供订单、车辆、候选方案和一页决定。读者可以改一个备好时间，重新判断哪些方案消失。另一种合理选择是与客户重约窗口，但必须先获得同意，不能在报表里把窗口悄悄放宽，再宣布准时率提高。

怎样开始，才不会把项目拖进无边无际的全公司改造？可以选择一段有明确起点和终点的工作，例如从订单确认到完成交接。记录这段内谁提供什么、何时能拒绝、异常由谁接手，再把与范围外相连的条件列清。先管住一段真实承诺，通常比宣称优化整张供应链更容易检验。

扩大范围也不一定每次都划算。新增一个仓库、承运方或国家，会带来新的限制和新的可选资源。FDE需要判断其中哪些是共同机制，哪些是本地特例。若为了统一，抹掉本来必须存在的差异，规模扩张就会把一次小误解复制到更多订单上。

仓库和车队，究竟谁在等谁

同一教学情境还藏着一个时间问题。销售系统接受订单，并不意味着仓库已经备齐；仓库完成拣货，也不一定完成包装、复核与装车准备。若把最早的状态直接发给承运方，车可能来早了。若等到全部完成才开始找车，货物又可能在门口等很久。

协调这两边，需要的不是一个永远准确的预测，而是一份会更新、能影响动作的准备时间。仓库发现缺货，应当改变预计可取货时间；调度发现车辆晚到，也应让仓库知道哪些任务可以调整顺序。双方都掌握局部最新信息，如果更新只留在自己的系统里，另一边就会按已经过时的计划继续行动。

工程师可以先跟踪少量订单，把“预计备好”“实际备好”“车辆到达”“开始装货”“完成离场”分别留下来。这样可以看清等待主要产生在哪里：是车到了而货没齐，货齐了却没有车，还是两者都到了但装货口正在处理别的车辆。三种等待需要三种干预，单看平均出库时间很难区分。

这也解释了为何越频繁地重新计算，有时越让人忙乱。仓库刚按一个顺序集中货物，调度立刻更换车辆和装载组合，人员便要反复搬动。计划当然需要响应变化，但可以为已经开始执行的动作保留稳定区间，只调整尚未锁定的部分。何时锁定、允许什么原因打破锁定，应由现场可承受的返工代价决定。

规则落地之后，还要为不同岗位保留有用的解释。司机不必看整个优化过程，但应知道这一站为何调整、当前任务能否执行、出现冲突向谁反馈。仓库不必了解每一辆车的全部成本，却需要知道哪个到达时间已经确认、哪个仍是预测。给所有人同一张庞大的总控图，并不等于大家获得了完成自己工作所需的信息。

人工改动在这里尤其值得认真记录。一次调整可能是经验丰富的调度员发现了遗漏条件，也可能只是沿用旧习惯。若系统只把它算成“不遵从建议”，就无法学习；若每次都无条件接受，又可能失去统一安排的收益。记录修改理由和后续结果，可以让工程团队分辨该修规则、补数据，还是重新解释已有约束。

这种协作不能只围绕总部容易看到的指标。临时搬运、等待和解释工作常由一线承担，外部团队若只访谈最初提出项目的人，可能连新增劳动在哪里发生都不知道。让执行者参与检查候选流程，既能补充现场知识，也让他们有机会指出哪些计划在屏幕上合理、实际做不到。

计划更快，也要问现场改变了什么

物流和供应链还有一段发生在货物移动之前的工作：预测、订购、补货与调整计划。微软2026年9月17日的回顾称，其云供应链先梳理和简化端到端流程，再建设共同数据基础及Agent。文末把一项周期改善限定在2026年4至8月的五个月度规划周期：平均约10个工作日变为少于2.5个工作日。⁴

这个限定值得保留。测到的是选定规划工作的时间，不是运输时间下降了四分之三，也不是所有供应链成本同步下降。材料属于企业内部前后对照，没有拆分流程简化、数据整理与Agent各自的贡献；它也没有把这项内部实践明确称作FDE。

对交付团队更有帮助的，是顺着计划去找下一项动作。新的计划提前形成后，采购员是否能够更早处理一个缺口？仓库会不会得到更多反复变动的安排？如果只是把做表压缩了，后面仍要等同一个批准，整个流程的等待可能没有同比缩短。本书据此建议同时保留计划形成、业务批准和实际执行三个时间点，让管理者知道节省的时间在哪里兑现。

这也提醒团队，现场发现的不一定都要变成新的模型功能。删掉一次没有决策价值的重复确认、明确由谁维护一份共同数据，可能先于Agent带来改善。把这些改动写进交付记录，才能知道下一家客户需要复制的是软件，还是一项组织安排。

等几分钟，有时才是更好的运输

航空转机把局部和整体的差别表现得更鲜明。2019年6月10日，United公布ConnectionSaver时称，系统会考虑转机旅客在登机口之间的步行时间，以及等待对其他航班和旅客的影响，再判断某个航班能否等候；向选择接收通知的旅客提供登机口与步行信息，也是该方案的一部分。⁵

这份航空公司原始公告没有把该工具归于FDE，也不能据此归于某一家外部技术供应商。它在本章承担的是交通运行的对照：单班航班尽快关门，与整段旅程顺利完成，可能导向不同的动作。

把这个问题用于一般运输分析，能够看见为什么单一“准点出发率”不足以概括质量。晚一点出发，有时可以让更多人赶上行程；等待也可能让已在机上的人错过下一程。两边都是真实需求，不能只数被帮助的一边。更完善的决策，必须把受影响的后续任务也纳入，而不是给等待本身贴上好或坏的标签。

同时，正确的内部决定需要与外部通知一致。如果调度决定等待，旅客却仍以为赶不上而改变行动，系统计算出的收益可能无法实现。在货运里也是一样：重新安排了一辆车，但仓库没有收到新的装货时间，重新调度只存在于后台。

因此，信息传递也是运输的一部分。这里的通知不是为页面增加友好感，而是让人按照更新后的安排采取行动。何时通知、是否已被接收、计划再次变化后怎样避免旧消息继续误导，都需要与运行过程一起设计。

当然，并非每一种延迟都需要全网络重新计算。变化范围小、后果低时，简单规则和有经验的调度员可能更便宜、更快。全局信息越多，获取、更新和判断的成本也越高。工程目标是覆盖会改变决定的关键影响，而不是为了“全局智能”收集所有能够收集的数据。

异常需要下一位接手者

理想路线只描述顺利发生时的过程。司机取消、车辆未到、收货点拒收之后，由谁把任务重新接起来，决定了现实中的服务。

Nash于2023年发表的Roti餐饮配送案例，记录了自动接收订单、统一支持，以及承运方取消或接近取件时限时重新分配的做法。⁶ 这份材料含客户负责人的引述，但没有明确FDE角色；本章也不采用其中不同口径的效果数字。对我们更有价值的是，原先依赖人追着订单寻找解决办法的一段工作，被纳入了可接续的流程。

重新分配并不只是再点一次“派车”。在教学订单里，如果第一位司机已经在路上，系统又派了第二位，谁确认第一位不再执行？如果货物已装车，订单状态却还停在仓库，重新分配可能制造重复运输。异常处理需要知道此前动作到了哪一步，并把撤销和新安排关联起来。

这也是为何“自动恢复”必须有范围。信息足够、动作可撤回时，可以按预设条件重新分配；若货物位置不清、交接证据冲突或损失可能扩大，就需要停在清楚的位置等待人处理。暂停并不等于把订单从看板上移除，仍须有接手对象、最后已知状态和下一次检查时间。

客户和承运方对“已解决”的理解也可能不同。客服完成一次答复，司机成功联系收货人，平台把故障工单关闭，都不必然等于货物已交付。为了避免各方都完成自己的步骤而无人完成运输，最终责任应追到这次服务承诺的终点。

FDE可以帮助把这些接续关系做进软件，但有些决定必须由运营负责人明确。谁有权改变承诺时间，谁承担额外费用，哪类异常可以直接取消？若这些问题尚未谈妥，模型生成再流畅的解释也只是把未决问题说得更像决定。

状态消息也能挡住货物

并非所有运输瓶颈都发生在路上。Nash工程师John Zenk记录了2026年初两次消息流量突增：状态更新和创建配送共享处理资源，更新请求等待、失败后重试，连新配送请求也受到拖累。团队随后将相关端点拆成独立服务。作者强调，隔离共享资源比更换编程语言本身更关键。⁷

“端点”在这里可以理解为接收一类消息的入口。一边不断询问或传送运输状态，另一边要创建新的配送；如果大家挤在同一组处理人员面前，旧消息的拥堵就会挡住新任务。这个比喻只用于理解资源争用，不代表系统真的按人工作。

同一记录没有停在成功迁移：新服务后来仍发生过停止转发更新的问题，而且是通过支持反馈才发现。⁷ 一个曾经扩散到其他入口的故障被隔离，并不代表新入口从此不会坏。这一段反证尤其有用，因为它把“改善了一个失败方式”和“系统整体可靠”分开了。

对本章而言，结论不是物流企业应该统一采用某种语言或架构。要学会追踪的是：一条对客户看起来次要的信息链，是否占用了完成核心动作的资源？状态通知晚一点，与新订单根本无法进入，后果并不相同。系统应怎样保留基本服务，要结合这两个后果来决定。

拆开资源也有代价。更多独立部件需要分别维护、监控和明确负责人；彼此隔离有助于限制影响，却会增加排障时需要理解的连接。不能因为一次拆分有效，就把每个功能都拆成独立系统。现场要求应推动产品选择，而不是成为无限定制的理由。

这份工程师记录没有证明他当时担任FDE。它展示的是平台内部必须接住的工作：客户提出“配送请求超时”，真正要改的可能是共享架构。前线能够把具体受损的工作传给平台，平台又能把修正带回各客户，前线部署与产品工程才形成有用的分工。

把局部成绩放回同一张订单上

到了这里，订单经过了输入、备货、派车、导航、交接和异常接手。不同团队都可以找到自己的改善：少一次复制、更短路线、更快响应、更少人工干预。评价整段工作，需要确认这些改善是否发生在可比较的订单和条件里。

首先保留承诺本身。若系统通过延长允许送达时间获得更高的准点率，这可能是一种合理经营调整，却不是在原有承诺下提高了能力。若把难送区域排除，平均成本也可能变好。比较前后时，订单范围、服务承诺和被排除的异常，应当一起出现。

其次避免重复计入收益。同一个迟到被避免，可能同时减少退款、催单和人工追查；这些收益可以分别记录，但某些内部报表已经把它们打包成一个总成本，再相加就会计算两次。与其收集越来越多的“提升百分比”，不如选取一批能沿途追踪的订单，看它最终经历了什么。

仍需小心影子运行的边界。新方案在后台给同一批订单排出更好的计划，不等于司机实际走过这条路线，更不证明所有现场约束已经收全。它适合发现明显冲突和比较候选；进入实际使用后，还要观察装卸等待、临时变更和人工接手是否暴露了遗漏。仿真优势与履约结果之间，有一次现实检验。

最后，比较必须允许一种并不耀眼的结论：某项简单改动已经足够。对Pink Dot式的手工传递问题，标准接入可能比长期派驻复杂团队更合适；对于深嵌多个仓库和承运合同的流程，具备工程能力的现场协作则可能更有价值。UPS的内部开发记录也提醒我们，理解现场与构建系统的结合，可以由不同组织方式完成。

物流FDE因此不是一个替代所有调度员和运筹团队的角色。它更适合出现在现有平台能力与特定运行条件难以接合的地方，把隐藏的承诺变成可执行条件，把异常变成有人接手的工作，再让多处局部改进接受同一个终点的检验。

一张订单不关心用了几种模型、接口响应缩短了多少，也不会因为某个部门达标就自行抵达。它最终需要以约定的方式交到合适的人手里。所有局部的“更快”，都要走到那里，才算完成了本章的问题。