每一段链路，具体怎么跑

先说为什么这件事重要

仓配服务的口碑，八成来自「出事之后」。正常发货没人会记得你，一次错发、一次拦截失败、一次对不上的账单，才是货主换仓的真正原因。

而「出事之后」能不能处理好，取决于两件事：系统里有没有足够的信息，以及这套系统改不改得动。

用买来的系统做仓配，两件事都不占。你能拿到的只是它愿意导出的那些字段；现场想改一条规则，要变成一张需求单、一次排期、一轮报价，等排到了你的运营玩法已经换了。

飞驼的整条履约链路跑在自己的系统上。改口径、加对接、调规则，是我们自己的排期，不是别人的。

OMS：让仓库只看到规整的作业单

订单从各个平台进来的样子千差万别。订单中台的职责，是把这些差异消化在进仓之前。

订单可以从三条路进来：平台店铺授权直连、我们给货主开的专属接口账户、以及第三方 ERP 的标准协议对接。进来之后要做三件事。

判结构，并算同构标识。 每张单先判定是单件、单品多件还是多品——这个判定直接决定它后面走哪种作业模式。同时系统把「商品编号加数量」的组合串起来取哈希作为同构标识，商品构成完全相同的订单会被自动聚成一批，这是爆款组合能批量作业的技术前提。跨仓跨温区的要拆，同一收件人的多笔可以合，父单子单关系全程可回溯。

把异常拦在进仓之前。 地址异常、缺货、超区、黑名单在这里处理完；还有一套物流停发配置，按承运商、省、市、区县甚至运单三段码配置停发，疫情、天灾、网点异常时按区域批量停发，不用一单一单去改。进仓前多拦一单，仓里就少一次返工，客服就少一次道歉。

把发货时限变成配置。 平台考核的是「多久发货」，系统把这条约束前置成可配置的自动揽收策略：按平台、按店铺设定每天的时间窗，判定基准可选支付时间、到库时间、回传时间或最晚发货时间。不用靠人盯着后台掐点。

WMS：仓里的每一步都在系统里

仓不是一个大房间

系统里的仓有三层物理模型：库区 → 库位 → 载体。库区分零拣、料箱、托盘、地堆四种存储形态，标明人工区、自动化区还是机器人区，以及所属温区；库位编码精确到「排 - 层 - 格 - 深度」，带长宽高、承重、温湿度上下限、是否通风、良次废标识。

这套模型的意义是：常温、冷链、大件、零食小件可以在同一个仓的不同库区并行。 新货主进仓不需要改系统，库位的物理约束是配置出来的，不靠人记。收货和上架同样是拆开的——货一到就能收不必等单据齐，上架时系统推荐库位、扫载体码扫库位码扫商品码三次互相校验，把「放错货位」挡在源头。

波次：作业方式跟着订单结构走

出库以波次为组织单位，四种模式并存：

标准波次——生成多个拣货任务，拣完二次分拣、打面单、打包贴码。

同构批量波次——按同构标识筛选订单，全库计算每个商品从哪个库位取多少，拣完汇聚统一分拣、统一批量打面单。爆款走这条，效率最高。

摘果式波次——一单一任务，边拣边成单。长尾多品订单走这条。

批量出库波次——面向 B 端大单。

波次的筛选条件细到什么程度：货主、温区、承运商（可多选）、原始物流、订单结构、电商平台（可包含也可排除）、收货省份、商品行数区间、件数区间、订单已过小时数、到库时间区间、商品标签、库区、指定订单号、波次最大订单数。这些条件可以存成模板复用。

拣选作业方式有六种：零拣库拣选、料箱整箱拣选、托盘拆托拣选、整托拣选、地堆库拣选、机器人拣选。工作台类型分得同样细：人工拆托台、人工单品分拣台、人工多品播种台、人工同构分拣台、机器人补货站、机器人分拣台、订单出库扫描站、B 单出库站。

同一个仓里，爆款用同构批量、长尾用摘果、大件走整托、B 端走批量单——作业方式跟着订单结构走，而不是让所有订单排一条队。这是单量波峰时人效不塌的根本原因。

每个环节都记了人和时间

订单的状态机是完整的：初始 → 待出库 → 已进波次 → 已建任务待拣货 → 拣货中 → 拣货完成 → 二次分拣中 → 二次分拣完成 → 打包完成 → 已出库。

每一个环节都记录了操作人和时间戳：谁生成的任务、谁拣的货、谁二分的、谁打的包。拣货任务还有作业节点锁定，某人开始作业即锁定，防止两个人同时动一张单。

出了问题不用「回忆一下」，直接看记录。

货到人机器人拣选

我们引入了 Geek+ 机器人拣货方案，采用货到人拣选：机器人把货架搬到拣货员面前，省掉仓库里最耗时的环节——走路。

值得说明的是，WMS 与机器人系统之间是双向的单据级对接，不是简单地推一批数据过去：收货入库的下发与取消、补货入库的下发与取消、订单出库下发、批量出库下发、商品主数据推送、机器人区内部盘点结果的反馈，以及库存镜像对账。

每一笔交互都记录推送报文、返回报文、异常信息、重试次数和回调状态。

其中最重要的是库存镜像对账——机械设备和 WMS 的账不会悄悄跑偏。人工区和机器人区在同一套系统里协同，一个订单可以跨两个区拣。

对货主的直接意义是：产能不随招工难易波动。大促加班加的是机器的班，而不是靠临时拉一批不熟练的人进来碰运气。

称重复核：一票三个重量

重量有三个口径并存：订单理论重量、实际称重、计费重量，而且计费重量是独立落在每个包裹上的。复核打包还逐票记录包材、耗材、气柱袋与冷媒用量。

这是整条链路上性价比最高的一道闸门：实际重量与理论重量比对，错发、漏发、多发在包裹离开仓库之前被拦下来，而不是等买家签收后拍照发给客服。同时它也是后面跟承运商对账、跟货主结算的唯一原始凭据。

一单多包，每一包独立可追

一个出库单可以拆成多个包裹，每个包裹有自己的包裹序号、运单号、称重、计费重、行数件数、箱型尺寸、承运商、二次分拣人与时间、打包人与时间、出库时间、揽收标识。

补发的包裹还能指回被补发的那一票。

所以包裹数、运单数、称重、快递计费一律以包裹为准。 多包裹订单的每一件都能独立追踪、独立计费、独立赔付定责——这是「一单多包」场景下不糊账的前提。

退货：最难的是「货到了单没到」

退货类型分顾客拒收、顾客退货、未发截回、已发截回、物流原因退回。登记支持按商户登记、混合登记、混合登记拆分、投墙式混合登记四种作业方式。

状态机里有一个专门的状态叫「退货单集齐」。这正是退货处理最难的地方——货到了但货主还没推单。系统把「集齐」做成独立状态，缺单的包裹会被单独拎出来推给货主，而不是堆在暂存区等着。

TMS：包裹出门之后

路由与时效

「这一单发哪家快递」不靠人记，是按平台、店铺、商品标记、订单金额区间、收货省市、重量区间、优先级算出来的一张多维规则表，输出首选加一串备选，首选不可用时自动降级。

每个包裹落一条完整的路由记录，配合「发货省市到收货省市」的时长基准表和从实际路由持续沉淀的各承运商真实时长，滞留、虚假签收、退回在路由层就被识别出来，不用等买家投诉。

拦截：三条路，看走到哪一步

「帮我拦一下这单」在系统里不是一句话，是按订单走到哪一步分流的三条路径：

还没作业的——订单层直接锁定（区分作废拦截、物流停发锁定、暂停锁定，记录锁定原因和锁定时的状态，解除后能回到原位继续）。

已进拣货任务的——拣货任务进入「作废拦截中」状态。

已经出库的——生成运单拦截记录进入承运商的拦截通道，拦回来的货走拦截回库任务重新上架，支持逐单回库和批量回库。

每一次拦截的成败都有记录。 拦得住拦不住是另一回事，但这件事有人在做、有结果，而不是一句「我帮您问问」。

计费核对：全量逐票，不是抽查

每一票都落一条快递费用记录：我方称重、我方核算成本、承运商账单重量、承运商账单费用，另加附加费明细。

承运商账单来了，系统能逐票比对「我们称的重 vs 他们计的重 vs 他们收的钱」。不是抽查，是全量。 这是仓配服务里最容易漏钱的地方，也是我们能给货主一个对得上的账单的原因。

仓库侧的物流成本按重量分段配置首重续重，段内可配平价。

关于月度量级承诺

与承运商约定的月度量级往往绑着价格阶梯，走不到承诺量意味着单价跳档。

现在系统里已有的是冲量机制：为了达成对某家承运商的量级承诺而主动改派订单时，系统记录「本应分配给谁、实际改派给谁」，并逐单核算这次改派的代价。这件事是有配置、有记录、有成本核算的，不是拍脑袋改派。

至于「月中就预测出承诺达不达得成」的风险预警，我们正在研究，还没有上线。这里如实说明。

云端面单打印

十多个电商平台的打单组件，过去散在各台终端上：资源被吃光、机器卡顿假死、换台机器要重装、打印能力绑死在某个工位。更糟的是漏打面单这件事是不可见的——你不知道哪一单没打出来。

我们把这些组件集中到云端统一调度，后台按仓轮询，发现已取号待打的订单就提前生成好面单文件并落库，终端凭运单号取文件直连本地打印机出单。于是：终端只剩一个轻量程序，老机器也能出单；打的时候是取文件而不是现调平台接口，组件抖动卡不住出货现场；「漏打」从黑盒变成一条待生成/生成中/成功/失败的记录，可查可补。

智能工单：把问题从聊天群里搬出来

这一套值得单独展开，因为它是履约体系里最容易被低估、但对货主体验影响最大的一块。

它要解决什么

仓配这门生意里最消耗信任的不是问题本身，是问题的处理过程：货主在群里发一句「这单怎么回事」，客服转给仓库，仓库查完回给客服，客服再转给货主。中间隔了三次转述、两个小时，还有一群人在同一个群里看着。

更糟的是三天后同类问题再来一次，没有人记得上次是怎么处理的。问题被解决了，但经验没有沉淀，责任没有归属，时长没有记录。

分类体系决定后面的一切

我们把履约链路上真实会发生的问题做成了两级分类，覆盖电商订单和 B 端出库单两条线：

发起物流拦截——包裹已发出，买家反悔或地址填错，需要在途拦回。
顾客拒收退件——买家拒收，包裹在返程，需要跟进退回入库。
物流停滞或退回——包裹卡在某个节点不动了，或被承运商退回。
物流虚假签收——系统显示已签收，买家说没收到。
货品破损少件——收到的东西破了或者少了。
货品错漏发件——发错了商品，或漏发了其中几件。

分类不是为了好看。工单类型直接决定后面的一切：能填什么内容、走哪条处理路径、可以有哪些处理结果、最后由谁承担赔付责任。每个分类还可以绑定默认优先级。

每张工单都挂在一张具体单据上

工单不是一段自由描述的文字，它必须关联到具体的业务对象：订单号、运单号、入库单、B 端出库单、退货单。工单正文支持图文混排，截图可以直接贴。

挂了单据，工单才能自动带出这一单的全部上下文——发了什么、什么时候出库、走的哪家承运商、物流到哪了、称重记录是多少。处理人不用去别的系统里翻，货主也不用把订单号贴三遍。

每种工单类型还配有内容模板，把「请提供一下运单号」「麻烦拍张照片」这类第一轮往返，前置到提单那一刻。

完结的权力在货主手上

一张工单的一生：

待处理——货主提交，进入客服的池子。
受理中——客服点进工单开始处理。从这一刻起工单不能删除，只能作废，留痕开始。
已处理——给出处理结果。
已完结——由货主确认。

关键在第四步：判断问题有没有被解决的权力在货主手上，不在客服手上。 货主不满意可以点「需继续处理」，工单回到待处理重新排队；一直不表态的超时后自动完结，避免单子无限期挂着。

受理之前货主可以自行删除，受理之后只能作废——因为从受理那一刻起，就有人的时间投在上面了，这个记录不该消失。

每一次转手都留一条记录

工单创建时直接指向客服。需要仓库其他环节介入时可以流转过去，流转后可以指定处理人，也可以由人主动认领——系统有领用锁：未指定人时为待领取，有人领取或被指定即锁定为处理中，避免两个人同时处理一张单。

每一次处理和每一次流转都生成一条独立记录：处理内容、处理部门、处理人、开始时间、完成时间，以及这一步是「处理」还是「转派」。同一张工单下的多轮对话逐条留档。

系统还分别标记「有新的货主提问」和「有新的答复」，双方都不会漏掉对方的最新一条消息——这是把沟通从聊天群搬进工单之后必须补上的东西。

结论与赔付责任不靠拍脑袋

处理完要从一个受工单类型约束的结果列表里选结论，而不是自由发挥：

顾客已签收、已退回仓库、退回仓库有损、未退回仓库记丢件、退回仓库后丢失、补发、赔付客户、仓库无责。

然后是最容易扯皮的一步——赔付责任：无须赔付、快递赔付、还是仓库赔付。

这一步由「工单类型 + 处理结果」自动推定，映射关系事先配置好，不由处理人现场判断。工单上还记录涉及金额，月底赔付有账可查。

对货主意味着赔付有据可依，对仓库意味着无责的单不会被算在头上。 双方都不吃亏，才谈得上长期合作。

承运商侧的事也收在这张单上

需要说明的是，承运商不会登录我们的系统。但承运商相关的动作和结论都收敛在这张工单上：拦截指令从工单发起并回写拦截结果（拦截成功 / 拦截失败），赔付责任的判定结论直接指向承运商，涉及金额有记录。

仓库、货主、承运商三方的事，最终都落在同一张单据上——这才是「不用三方转述」的真正含义。

相邻的一条异常闭环

还有一类最扯皮的场景值得单独提：包裹交给快递了，但快递说没收到。

这类揽收异常有独立的质量跟踪流程，异常原因分为库内遗留、交接遗留、快递错分件、揽收无到件信息；处理方式分为转为正常、错漏发补发、丢件补发、记丢件赔付等；跟踪结果和跟踪人全部留痕，由质量员确认。

不是靠客服记在 Excel 里。

报表与数据：你看到的和我们看到的是同一套

每日库存快照

每天凌晨自动生成前一日的库存快照和库位库存快照。

任意一天的库存状态可回溯——盘点争议、账期对账、货主质疑，都有历史依据，不是「我记得当时是这样」。

冷链：不是「多一个冷库」那么简单

温区在我们的系统里是贯穿全链路的一等维度，而不是给库房贴个标签：

库区标温区 → 库位带温度湿度上下限和通风标识 → 波次筛选条件里可以按温区分波 → 拣货任务带温区 → 发货服务类型区分普通配送 / 冷链配送 / 环保配送 → 冷媒方案按规则自动换算用量 → 复核打包记录里逐票记冰袋、干冰、保温袋数量 → 账单里的冷媒计费 → 班组日报按温区分组统计人效。

系统还每日自动更新发货地当日及未来三日的气温，作为冷媒用量决策的输入。

从收货温区、到波次编排、到冷媒用量按温度自动换算、到最后一笔冰袋费用，是同一条数据链。

这些系统是一条链，不是几个孤岛

最后需要说明的一点：上面这些不是几套各自为政的软件，而是同一条数据流上的几段。

订单从 OMS 进来，带着结构判定和同构标识落到 WMS；WMS 的波次决定作业方式，出库动作触发面单打印和 TMS 的承运商路由；TMS 的物流轨迹回流成时效报表和异常识别；任何一个环节出问题，工单挂着那一单的全部上下文被提出来；称重记录变成对账凭据，处理结果又回到报表里，成为下个月复盘的依据。

因为是一家在管，所以能连成一条链。这是最实际的那部分价值——不在任何单个功能上，在它们之间。