70万订单！WMS从0到60模块，AI神话破灭！

有人曾不以为然地说：“不就是每天2000个订单嘛，能有多复杂？”

当听说我们的一个客户每天要处理约70万个订单时，对方随口一算，觉得2000个订单一天，似乎也没什么大不了。这种轻描淡写，往往源于对复杂系统缺乏直观认知。但实际上，供应链物流的每一个环节都充满了意想不到的挑战。

上面这张看似简单的图表，里面的每一个“盒子”——也就是每一个功能模块，都是在一次次“我们不需要这个”的断言之后，在某个凌晨两点、某个业务高峰期，大家才幡然醒悟并最终构建出来的。这其中蕴含着无数经验教训和成本。

随着当前“即兴编程”（vibe coding）的热潮兴起，我常听到一种论调：用AI随手一写就能搞定一个仓储管理系统（WMS）。对此，我想说，如果真的能用“即兴编程”解决问题，那当然是好事一桩。我们真心乐见其成。但当业务体量足够大，需求足够复杂时，专业的解决方案就显得不可或缺了。

所以，今天我们就从零开始，一起构建这张复杂的WMS图表。让我们从一个最简单的“订单”模块出发，看看最终是如何演变成多达数十个精细功能模块的。

一切都从“订单”开始。假设您拥有一座仓库，希望为商家提供订单履约服务，这是一个非常好的起点。于是，您着手开发一个系统，让商家能够添加订单。但究竟“订单”指的是什么呢？

从核心来看，订单是一系列“订单行项目”的集合：包括产品信息和对应的数量。先记住这一点。

目前系统已包含：

• 订单系统

既然是“现代化”仓库，您的客户自然希望系统能从他们现有的平台中拉取订单。这些订单来源可能多种多样，只要能获取订单数据的渠道都算。这些来源的集成难度从“简单”（在物流领域，从来就没有真正的“简单”，只有“痛苦”和“不那么痛苦”的区别）到极其复杂，甚至令人头疼。

目前系统已包含：

• 订单系统
• 外部集成模块

听起来不难，对吧？集成几个平台而已，应该不会太多。

集成地狱：复杂多变的生态系统

在实际操作中，外部集成远比想象中复杂。新媒网跨境获悉，跨境电商和全球供应链的飞速发展，使得企业不得不面对各种各样的平台和系统。

以亚马逊为例，您需要通过耗时且审批严格的应用流程，才能获取到自家数据进行履约。更别提亚马逊还有FBA（亚马逊物流）模式，这意味着您不是简单拉取“订单”，而是要将货物以“入库”形式发往亚马逊仓库，由其完成后续履约。这要求您的系统能区分并处理“入库单”。此外，亚马逊为其SP-API（销售伙伴API）收取数据访问费。为了节省成本，您可能需要使用其通知API，但这又要求您拥有AWS账户。如果您的客户在全球多国设有店铺，那可能需要管理跨区域的3个AWS账户。这些费用和审计要求，尤其是在处理FBM（卖家自配送）模式时，更是雪上加霜。

eBay的集成同样需要开发应用，但其API调用频率限制却讳莫如深，从不公开，给开发带来了不确定性。

Shopify则展现了技术迭代的活力。从最初偏爱RESTful API，到后来力推GraphQL，再到现在两者并存，都要求您的集成模块能够灵活适应。

Salesforce的Commerce Cloud集成也并非一劳永逸。您可能认为完成一个项目的集成就能触类旁通，但事实是，每个客户都会根据自身业务对系统进行高度定制，使其面貌各异。

NetSuite和Odoo等ERP系统同样如此。表面上看起来大同小异，但在实际部署中，每个客户都会进行大量个性化修改，将其“弯曲”到独特的、超出常规预期的状态。这意味着您的集成模块必须具备极强的适应性和定制能力。

目前的系统已包含：

• 订单系统
• 外部集成模块
• 亚马逊（FBM + FBA）
• eBay
• Shopify
• Salesforce
• NetSuite
• Odoo
• ……而且，随着新的电商平台和系统不断涌现，您将持续增加更多集成。

除了这些主流平台，您还需要一套强大的机制，去拉取那些不支持Webhook的系统数据，并严格遵守第三方API的调用频率限制，尤其是在对方对这些限制语焉不详的情况下。同时，一套完善的Webhook系统，能够接收实时推送，能大大提高数据同步效率。当然，您自己的系统也需要做好速率限制，以防被外部请求压垮。

而您的商家客户，并非都使用高端的电商平台。有些可能仍然通过CSV文件批量上传订单、产品或入库单。这就要求您有一个强大的批量上传模块，不仅限于订单，还包括产品、库存调整等一切数据。这不仅仅是一个简单的文件解析器，它需要具备行级数据验证、错误报告、处理部分失败的能力，并且不能在处理5万行甚至更大文件时崩溃。此外，您还需要一个上传模板管理器，因为每个客户都有自己习惯的列布局，并且往往不愿更改。

产品：远不止一个名称那么简单

在这一阶段，您会意识到需要一套完善的商品管理方式，我们称之为“产品”。您的订单里包含了产品和数量，但这远不足以描述一个真实的商品。

一个产品，通常包含：

• 名称（如：可口可乐）
• 标识符（如：SKU）
• 数量（如：2）

但“数量2”到底是什么意思呢？是2瓶可口可乐，还是2箱？一箱又包含多少瓶？这就引出了计量单位（UoM）系统的必要性：

• 一瓶可口可乐 → 一个**“个”**
• 6瓶 → 一**“箱”**
• 48箱 → 一**“托盘”**

订单可能以任何单位下达，因此系统必须支持单位转换。更复杂的是，不同的“箱”可能代表不同的数量，例如一“箱”可口可乐和一“箱”苹果的内含数量就可能不同。所以，您需要一个UoM配置管理器和用于自定义UoM的主数据管理系统。

您以为产品仅仅是产品本身？一件红色的T恤和一件白色的T恤，它们是同款T恤吗？它们不是完全相同，而是变体。12盎司的可口可乐和2升装的可口可乐，它们都是可口可乐，但在您的系统中，它们需要不同的SKU、不同的条形码、不同的重量、不同的包装、不同的货位，但您的客户又希望在报告中将它们归类为“可口可乐”。同时，您的拣货员又需要将它们视为完全独立的商品，以免发错货。因此，一个产品变体模块至关重要：它能处理产品间的父子关系，在父级层面共享属性，在变体层面拥有独有属性，并支持在两级层面进行搜索、筛选和报告。而且，不同集成平台处理变体的方式也各不相同，Shopify内置变体，亚马逊有父子ASIN，而一些ERP系统甚至没有变体的概念，直接将所有商品扁平化为独立的SKU。所以，您的变体模块还需要将这些差异统一成仓库工人实际可操作的单一表示形式。

如果您的商家进行跨境运输（这几乎是必然的趋势），您的产品还需要HSN（协调制度命名）代码。这些是海关部门用于确定关税和税费的分类代码。每件产品都需要一个。它们具有层级结构，因国家而异，一旦出错，货物就可能被海关扣留。因此，您需要一个海关与合规模块：用于管理HSN代码、查询特定国家/地区的关税，并生成海关申报单。对于任何从事跨境业务的企业来说，这都是必不可少的。

国际贸易环境不断演变，各地关税政策的调整，也对商品分类和贸易合规提出了更高要求。一夜之间，过去顺利通关的商品可能需要新的编码或面临不同的税率。原产地，这个曾经不起眼的属性，如今却可能成为决定货物能否顺利流通的关键。这对企业的运营和供应链管理带来了巨大挑战。您的系统需要具备一次性更新成千上万个产品分类代码的能力，并保留完整的审计追踪。同时，原产地信息也需要精确到产品层面进行追踪。

目前系统已包含：

• 订单系统
• 外部集成模块（亚马逊、eBay、Shopify、Salesforce、NetSuite、Odoo等）
• 批量上传模块 + 上传模板管理器
• 产品管理模块
  • SKU / 标识符
  • 计量单位（UoM）系统 + UoM配置（例如1箱=6个） + UoM主数据管理
  • 海关与合规（HSN代码、关税查询、申报）

库存与库位：精细化管理的基石

有了订单和产品，接下来自然是管理库存。在仓库里，库存总是存放在特定的库位。

库存管理不能仅仅是某一时刻的点状快照，因为您需要进行审计和回溯。因此，您需要构建一个基于账本的不可变库存系统。但实际操作中，库存差异在所难免，这就需要盘点与校正机制。

盘点并非一年一次的活动。您不可能每年停工，清点所有物品，然后就万事大吉。那是一种耗资巨大的“全面实物盘点”，您是在为员工停止履行订单的时间买单。因此，您需要循环盘点，即按计划定期对小部分库存进行盘点，最终在不中断运营的情况下覆盖所有库存。但循环盘点本身也是一项复杂的任务：今天应该盘点哪些库位？是优先盘点高价值商品？高周转商品？还是最近出现差异的商品？是按区域盘点、按SKU盘点，还是随机抽样盘点？当盘点结果不符时，是立即调整还是触发复盘？谁有权限批准调整？您需要一个循环盘点调度器、移动应用上的盘点执行流程、差异解决流程以及调整审计追踪，因为您的客户一定会想知道为什么他们的库存数据在某个周二下午3点发生了变化。

您可能还认为库存数量总是整数，比如有7瓶可乐，而不是7.3瓶。直到有一天，一位客户告诉您他们销售液体商品。他们以加仑为单位销售油漆，但以55加仑的桶装接收，并以小数分配。他们需要为这个订单分配2.75加仑。他们不会为了您的系统保持整数而将其转换为液盎司，他们用带小数的加仑已经20年了，并且不会改变。所以，现在您的整个库存系统——您的账本、分配引擎、盘点、循环盘点、UoM转换——都需要支持小数数量。这不仅仅是“增加一个小数列”那么简单。您需要确定精度，处理分配中的四舍五入，确保不会因为舍入而丢失或凭空产生库存。您需要确保10个订单每个消耗0.33加仑，从一个3.30加仑的容器中扣除后，不会留下系统认为真实存在的0.00000001加仑。

您还需要跟踪序列化库存，即拥有唯一序列号的商品，如电子产品或药品。同时，托盘（LPN）追踪也必不可少，它能将一系列物品作为单个可扫描单元（如托盘、料箱、纸箱）进行追踪，这样员工就不必扫描200个独立物品，只需扫描一个标签即可。您还需要具备库位预留功能，因为当一个上架任务正在进行时，您不希望另一个任务瞄准同一个货位。

仓库里的库位并非扁平的。它们存在层级结构，甚至同一仓库内可能存在不同的层级体系。一个货道有货架，每个货架有立面、层级和内部位置。有些库位在地面，有些在托盘上，有些在高处，这就需要系统知道是否需要叉车才能触及。有些库位可能已满，您也需要知道，这样就不会派人将物品放入已满的货位。

一个规范的仓库通常会划分为主要拣货区和补货区。您需要在系统中表示这些区域，需要存储层级、库容管理和库位控制平面。

由于这是物理空间，您还需要在系统中对仓库布局进行编码。不仅是逻辑层级，还有实际的空间排列：哪个货道连接哪个区域，库位之间的距离，通过某个区域的最佳路径。这直接影响到路径规划，而每个仓库的布局都是独一无二的，这意味着您需要为每个仓库定制一套路径优化算法。

目前系统已包含：

• 订单系统
• 外部集成模块
• 批量上传模块 + 上传模板管理器
• 产品管理（SKU、UoM、单位转换、海关/HSN）
• 库存（基于账本的不可变系统）
• 盘点与校正
• 序列化库存追踪
• 托盘（LPN）追踪
• 库位预留
• 库位管理
• 库位层级
• 存储分区
• 库位控制平面
• 库容管理
• 仓库布局编码
• 每个仓库的路径优化
  

订单处理：比想象中更复杂

我们前面提到订单就是产品和数量的集合。但在实际运营中，订单的含义远不止如此。

部分履约：客户订购了10件商品，您只有7件库存。是立即发货7件，剩余的稍后发出？还是等待所有商品到齐再发？商家需要根据情况决定，您的系统必须支持这两种模式。这意味着您需要一个部分履约模块，能够将一个订单拆分为多个发货批次，追踪已发送和未发送的部分，并最终协调所有这些复杂情况。

缺货订单管理：剩下那3件商品？它们现在是缺货订单。您需要一个缺货订单管理系统，能够监控新入库的商品，并根据优先级、订单创建时间、服务水平协议（SLA）或商家配置的任何规则，自动将库存分配给待处理的缺货订单。

订单拆分：一个订单中的商品可能分散在不同的仓库，或者部分商品需要冷链运输，而另一部分不需要。这时，您需要订单拆分功能——能够将一个订单拆分为多个履约任务，这些任务可能在不同地点执行，由不同承运商承运，但最终仍能以一个订单、一个包裹追踪体验呈现给最终客户。

订单路由：当您拥有多个仓库时，您需要决定从哪里发货。是离客户最近的仓库？运费最低的仓库？还是库存最充足的仓库？您需要一个订单路由引擎，它必须考虑库存水平、运输成本、承运商可用性以及SLA。而且，它需要在处理数千个订单时，在毫秒级时间内做出决策。

产品替代：客户订购了A品牌电池，但库存已空。商家已配置B品牌作为可接受的替代品。您需要一个产品替代模块，能够识别哪些产品可以在什么条件下替代哪些产品，以及需要怎样的审批流程。这种情况在杂货和消费品行业中比您想象的要普遍得多。

新增到系统：

• 部分履约
• 缺货订单管理
• 订单拆分
• 订单路由引擎
• 产品替代
  

入库与出库：物流核心流程

物品入库：收货与上架

总会有人将物品发送到您的仓库。这个过程如何管理呢？您需要一个入库管理系统。用户可以通过哪些方式创建入库单？

• 纯粹的入库
• 关联采购订单的入库
• 退货订单
• 仓库间库存调拨

当商家的入库货物运抵仓库时，比如一辆卡车到达，接下来该怎么办？有人必须进行收货。如果未能及时处理，卡车要么离开，要么停靠在货运码头，产生费用，消耗燃油，等待入库空间。但您并非总有足够的库位来存放所有货物，因此需要一套收货流程。您需要生成提货单（BOL）用于卡车提货，并且需要支持零担（LTL）运输，即处理那些未满一整卡车的货物。这意味着您需要与LTL承运商合作，管理货运等级，并安排码头调度。

收货完成后，您需要决定这些货物应该放置在哪里。这被称为上架。您不能随意放置，否则库存会散落在整个仓库。因此，您需要一个智能上架推荐系统，它会综合考虑商品周转率、可用库容、距离拣货区的远近以及同SKU现有库存等因素。

但有时您需要进行越库操作，即直接将入库商品从收货区运到发货区，直接装上出库卡车。这就需要一个越库模块。还有一些入库的货物可能直接对应待发订单，无需开箱、上架、再重新打包。这是一种**直运（Drop Shipping）**形式，您的系统也需要支持。

物品出库：批次、拣选、包装、发货

现在，您的商品已上架，订单系统显示今天有1000个订单待履约。您该如何决定先履约哪些订单，以及如何进行？

批次管理

您需要一个批次管理系统来决定哪些订单需要出库。不同的订单有不同的SLA（服务水平协议）。您的工人需要在互不干扰的情况下完成所有这些操作。批次策略并非一成不变，您需要支持多种策略：

• 按订单批次：一个拣货员一次处理一个订单。
• 按SKU批次：将包含相同产品的订单分组，拣货员一次性拣取某SKU的所有单位。
• 波次拣选：在设定好的时间点发布一批订单，以平衡仓库内部的工作量。
• 自定义策略：因为每个仓库操作都有自己认为最有效的方式。

批次管理模块负责检查库存可用性、进行拣货分配，并将任务派发给拣货员。

工作站管理与设备支持

拣货员在工作站工作，您需要工作站管理：包括工作站的位置、处理的工作类型以及分配给谁。您还需要管理料箱、推车和其他移动设备，追踪哪些正在使用，哪些可用，哪些已损坏。

您还需要支持硬件集成，例如播种式拣货（Pick-to-Light）系统，货架上的指示灯会引导工人找到正确的库位和数量。不同的仓库使用不同的硬件、不同的工作流程。这就引出了插件架构的需求，因为没有两个仓库的操作是完全相同的，您不可能为每个仓库硬编码工作流程。您需要一种方式，能够为每个客户、每个仓库、每个区域灵活地插入不同的策略、不同的硬件集成和不同的规则。

移动作业

拣货员不可能仅凭记忆穿梭于仓库。您需要一个移动应用，它需要适配从智能手机到平板电脑的各种屏幕尺寸，能在旧设备上流畅运行，同时为不同背景的仓库工人提供友好的用户体验。

在仓库里，几乎没有人会长时间阅读文本。高效的运营依赖于条形码、二维码、RFID或其他追踪系统。因此，您需要一个快速扫描模块。但扫描结果会查找什么呢？您的客户无法控制入库货物的标签，这些标签来自其供应商的工厂。所以，您需要一个扫描搜索模块，能在数十万个标识符中实现近乎即时的搜索。有时，您可能会遇到一个来自入库单或订单的商品，其条形码无法识别。这完全可能发生，因为产品数据可能还在上传，而货物却已到货。因此，您需要一个强大的异常管理模块。

包装流程

订单最终需要包装。如何包装？需要使用哪些箱子？谁来告诉用户某个SKU应该使用何种包装材料？您需要一个包装模块来追踪使用的包装耗材类型。由于这些是可计费的，所以您还需要计费模块来追踪人工和材料成本。

客户会以各种形式发送入库货物。如果他们发送一个包含200瓶可口可乐的托盘，而您收到一个只包含2瓶的订单，您需要一种方式来追踪已开封或部分开封的托盘，以便高效地清空它们。所以，您需要一个托盘化/反托盘化模块。

您还需要为捆绑/组套模块做好准备，因为商家会销售大量捆绑商品——例如，一个礼品套装可能包含3个不同的SKU，但作为一个整体销售，您需要能够动态地进行组装。

发货管理

包装完成后，您需要将货物发出。您需要生成运输标签，但承运商选择众多。您需要集成联邦快递（FedEx）、UPS、DHL等运输系统。您还需要集成承运商聚合平台，如EasyPost、ShipStation、Shippo——这些服务整合了多个承运商，提供统一的API。听起来简化了问题，对吧？但现在您必须同时支持直接承运商集成和聚合平台集成，因为有些客户需要前者，有些需要后者，有些甚至对不同产品线需要两者兼顾。

您还需要允许客户接入他们自己的承运商集成，他们不会为了您的系统而中断已有的承运商合作关系。因此，您需要BYOI（自带集成）支持的集成管理模块。现在，客户的凭证将存储在您的系统中，这些凭证绝对不能以明文形式存储。因此，您需要一个密钥管理模块，用于即时加密/解密并支持密钥轮换。

您还需要一个运费比价模块，用于比较不同承运商和聚合平台的费率和SLA。选择费率后，您会收到标签。但标签的格式多种多样，如PNG、PDF、ZPL文件，您需要以非常特定的尺寸进行打印。为什么？因为订单来源（电商平台或ERP）会有规范。客户还可能要求在装箱单上定制品牌信息或强制性措辞。因此，您需要一个标签管理模块和标签设计模块，这样用户就不必麻烦您的工程团队去构建新的格式。标签还有不同的形状——常规A4、撕拉式标签——这些都需要精确校准。

由于桌面和移动设备会打印大量标签，您需要一种方式绕过打印权限对话框，让用户快速打印。您还需要解决如何从移动应用触发打印到仓库内的打印机的问题。您需要一个打印/设备管理模块，因为并非所有打印机都相同，有些操作强制要求热敏打印机，而其他具有不同要求的则不强制。

那些容易被忽视的关键环节

除了上述核心功能，还有很多“幕后”模块，它们虽不显眼，却是支撑整个WMS高效运行不可或缺的部分。

工作流编排：
有人希望拣货后立即包装，有人希望独立的运输步骤，还有些客户则要求在拣货和包装之间进行质量检查。您需要一个工作流编排器，能够根据不同的客户、不同的仓库、不同的产品类型，灵活地组合这些步骤。

库位调整：
在仓库里，物品最终可能会被低效地放置。因此，需要一种方式进行库位调整，这些调整与任何入库单或出库订单无关，仅仅是为了优化空间布局。

规则引擎：
您会遇到各种业务规则：这个订单使用这个承运商，这个SKU使用这种包装，这个客户总是进行质量检查，这个产品缺货时可以用那个产品替代。您需要一个规则引擎，能够在不修改代码的情况下表达和评估这些规则。

通知管理：
人们需要知道事情何时发生：入库单到达、订单已包装、出现异常、缺货订单已履约。您需要一个通知管理系统——通过电子邮件、短信、应用内消息、推送通知等方式，并能够配置谁在何时收到什么通知。

数据库操作：
在大规模运营中，您需要结构化的方式进行数据库编辑，而不是某个工程师在凌晨2点直接在生产环境中运行原始SQL。您需要数据库迁移工具、审计追踪、变更跟踪。每一次手动数据修复都必须可追溯，因为当问题发生时（这几乎是必然的），您需要知道什么变了、何时变了、谁变的。

用户管理、权限及其他：
您还需要用户管理、客户管理、权限管理。您需要一个仪表盘系统，一个在运营负荷下不会崩溃的报告系统。

安全：永无止境的堡垒

在构建了所有这些功能之后，您必须确保系统不会被攻破。这不仅关乎企业自身的生存发展，也符合社会主义核心价值观中对安全和诚信的追求，保障了企业资产和用户数据安全。

身份认证（Authentication）：您的仓库工人、商家、管理员都需要登录。您需要身份认证系统，且不仅仅是用户名/密码。对于企业客户，您可能需要单点登录（SSO）；对于管理员账户，需要多因素认证（MFA）；对于集成，需要API密钥管理；对于移动应用，则需要基于令牌的认证。不同的客户还可能需要不同的身份提供商。

授权（Authorization）：拣货员不应能查看财务数据。商家不应能查看其他商家的库存。A仓库的管理员不应能修改B仓库的配置。您需要一个精细的授权系统，最低限度是基于角色的访问控制（RBAC），如果要求更高，则需要基于属性的访问控制（ABAC）。权限模型会迅速变得复杂，因为您正在处理多租户数据，单个仓库可能为50个不同的商家提供服务。

供应链安全：这是真正让您夜不能寐的问题。您的系统依赖于数百个第三方软件包。就在不久前，一个名为litellm的开源库，被成千上万的AI应用所使用，就遭受了供应链攻击。攻击者侵入了维护者的账户，上传了恶意版本到PyPI，窃取了凭证、SSH密钥、云令牌和Kubernetes密钥，并试图在集群中的每个节点上部署持久后门。这些受损版本在被发现之前，已经在线运行了数小时。这不是假设，而是您的WMS系统在拥有部署流水线、第三方依赖和云基础设施时所面临的真实世界。

因此，您需要依赖项扫描、软件物料清单（SBOM）管理、漏洞监控、容器镜像扫描，以及一套真正有效的密钥轮换策略。您需要锁定依赖项并验证校验和。您必须假设从互联网上获取的任何软件包都可能随时被攻破。

除此之外，还有日常的繁琐工作：SSL证书管理、安全补丁、渗透测试、SOC 2合规（因为您的企业客户会要求）、静态和动态数据加密、对每个敏感操作的审计日志记录，以及当（而不是如果）问题发生时的事件响应程序。

新增到系统：

• 身份认证（SSO、MFA、API密钥、令牌管理）
• 授权（RBAC/ABAC，多租户权限）
• 供应链安全（依赖项扫描、SBOM、漏洞监控）
• 安全运营（补丁、渗透测试、合规、加密、审计日志、事件响应）
  

全貌展现：WMS的“螃蟹演化”

在生物学中，有一种现象叫做“螃蟹演化”（Carcinization），即进化在不同谱系中独立地反复演化出螃蟹的形态。在过去的2.5亿年里，至少有五个独立的甲壳纲动物谱系趋同演化出了螃蟹的身体结构。螃蟹的形态对于其生存环境来说是如此有效，以至于大自然总是从完全不同的起点达到相同的演化结果。正如动物学家L.A. Borradaile在1916年所说，这是“大自然多次尝试演化出螃蟹之一”。

WMS系统就像企业软件中的“螃蟹”。无论您从何开始——无论是从订单管理工具、简单的库存追踪器，还是从运输标签生成器起步，如果您要运营一个真正的仓库，最终都将趋同于相同的“身体结构”。您最终会拥有所有这些功能。下面列出的模块并非可有可无的“愿望清单”，而是业务环境的必然要求。

• 订单系统：部分履约、缺货订单管理、订单拆分、订单路由引擎、产品替代
• 外部集成：亚马逊（FBM + FBA）、eBay、Shopify、Salesforce、NetSuite、Odoo，以及每个季度都会出现的新集成
• 批量上传模块 + 上传模板管理器
• 产品管理：SKU、标识符、计量单位（UoM）系统、UoM配置、UoM主数据管理、海关与合规（HSN代码、关税、申报）
• 库存管理：基于账本的不可变系统、盘点校正、序列化库存追踪、托盘（LPN）追踪、库位预留
• 库位管理：库位层级、存储分区、库位控制平面、库容管理、仓库布局编码、每个仓库的路径优化
• 入库系统：采购订单、退货、库存调拨、提货单（BOL）生成、零担（LTL）运输支持
• 收货系统：缓冲区、工作流、任务分配
• 上架：推荐引擎、越库模块、直运支持
• 批次管理：按订单、按SKU、波次拣选、自定义策略、拣货分配
• 工作站管理：工作站追踪、料箱、推车、设备
• 移动应用：多设备支持、条形码/二维码/RFID扫描模块、异常管理、快速搜索模块
• 包装：包装模块、耗材追踪、托盘化/反托盘化、捆绑/组套
• 发货：直接承运商集成（联邦快递、UPS、DHL）、承运商聚合平台（EasyPost、ShipStation、Shippo）、自带集成管理、密钥管理、运费比价、标签管理、标签设计、打印/设备管理
• 工作流编排器
• 规则引擎
• 库位调整
• 通知管理：电子邮件、短信、应用内、推送通知，可配置
• Webhook系统：接收和发送
• 限流系统：针对自身API和遵守第三方限流
• 插件架构：每个仓库的定制、硬件集成（播种式拣货等）
• 身份认证：SSO、MFA、API密钥、令牌管理
• 授权：RBAC/ABAC，多租户权限
• 供应链安全：依赖项扫描、SBOM、漏洞监控
• 安全运营：补丁、渗透测试、SOC 2合规、加密、审计日志、事件响应
• 用户管理、权限管理、客户管理
• 仪表盘和报告系统
• 数据库变更管理：结构化编辑、审计追踪
• 计费系统：人工、耗材、仓储费

数一数上面加粗的模块，已经近60个了。

我们终于达到了！

然而，这份清单甚至还不够详尽。我们还没有深入探讨个人身份信息（PII）管理，因为您的系统可能存储着跨司法管辖区（涉及不同数据保护法规）的姓名、地址、电话号码，您的客户可能会向您询问GDPR合规性问题。我们也没有讨论如何调试生产问题，例如俄亥俄州仓库的拣货员报告扫描不匹配，您需要弄清楚是条形码、产品数据、搜索索引、移动应用缓存，还是标签打印机固件出了问题。我们还没有谈到遥测技术，即您需要在每个服务中部署的仪器，以便当系统缓慢或出现故障时，能够真正找到问题所在，而不是盲目猜测。我们也没有讨论当您在同一平台上运行多个仓库时出现的分布式系统问题——时钟偏差、最终一致性、库存数据分裂、需要就库位是否被预留达成一致的服务间网络分区。我们还没有讨论Webhook接收的弹性。当Shopify向您发送Webhook而您的系统停机11秒时会发生什么？那个Webhook就丢失了。订单是否已经通过？库存更新是否已经完成？您需要重试处理、幂等性、死信队列和和解任务来捕获Webhook遗漏的信息——因为它们一定会遗漏。

我们目前列举了大约60个模块。而实际数量远不止这些——它总是比想象中更多。

陷阱：从“建”到“维”的挑战

这里有一个很少有人提及的真相：构建系统只是其中相对容易的部分。

快速搭建一个1.0版本可能容易获得成就感。但维护它，则是完全不同的游戏。当亚马逊在不事先通知的情况下改变其API时，如何确保您的集成保持正常运行？如何在凌晨3点、业务高峰期的周六处理那些只有在此时才会浮出水面的边缘情况？如何在如此庞大的系统上进行数据库迁移而又不造成停机？如何确保移动应用在购买时就已经老旧的硬件上依然保持高性能？如何确保您的工作流编排器不会在客户提出您未曾预料的需求时让您陷入僵局？如何在密钥被利用之前进行轮换？如何在下一个类似litellm的供应链攻击袭击您的技术栈中的某个软件包之前进行修补？这些都是长期且艰巨的挑战。

那些拥有庞大、难以维护系统的公司常常陷入一个循环往复的陷阱：他们最终只能构建其系统容易实现的功能。架构反而限制了业务发展，而不是赋能业务。WMS成为了瓶颈，运营团队开始“绕着软件走”，而不是通过软件来高效工作。需要部分履约，但您的系统不支持？那就只能扣下整个订单。需要在多个仓库之间路由订单，但您的架构不支持？那就只能手动分配。软件开始僵化，业务为了适应软件的局限而扭曲。最终，您就陷入了困境。

更深层次的一点是：您或许在第一天不需要所有这些功能。但要运行一个严肃的业务，您最终会需要其中的大部分。问题不在于“我是否需要这个功能？”，而在于“我何时需要这个功能，以及我的现有架构能否支持它的添加而不会崩溃？”

所以，我们应该“即兴编程”一个WMS吗？

坦率地说，我们认为“即兴编程”很棒。说真的，如果您能用一个周末的小程序解决问题，那就应该去做。新媒网跨境认为，当前AI辅助开发的浪潮是积极的，它实际上有助于那些深耕垂直领域的SaaS公司。原因在于：它筛选掉了“非理想客户”。那些真正能通过一个AI原型或简单的电子表格解决问题的用户，原本就不会为一套复杂的专业系统付费，如果他们能以更低的成本解决问题，又何必呢？

最终留下的，是那些真正需要深度、可靠性、可维护性的客户，这些特质源于多年积累并融入软件的运营经验。

我们是各自领域的专家，我们构建、设计并领导开发了能够处理这种复杂程度的系统。当您可以“即兴编程”解决问题时，您当然应该这样做。但当业务规模足够大——当您需要在管理三个AWS区域的亚马逊FBA入库，同时您的订单路由引擎正在将部分履约的订单拆分到两个仓库，而您的越库工作流因为一个序列化商品出现异常，需要通过不同的聚合平台路由到另一个承运商，因为原承运商周日不服务该邮编地区，而且更糟糕的是，您的部署流水线中的一个依赖项刚刚被攻破，您需要轮换Kubernetes集群中的所有密钥时——新媒网跨境预测，那时，您会渴望拥有一个从设计之初就为应对这一切而生的系统。

那时，您会需要那些在构建过程中留下“疤痕”（积累了宝贵经验）的专业团队。

新媒网（公号: 新媒网跨境发布），是一个专业的跨境电商、游戏、支付、贸易和广告社区平台，为百万跨境人传递最新的海外淘金精准资讯情报。

本文来源：新媒网 https://nmedialink.com/posts/700k-orders-wms-60-modules-ai-myth.html