仓储项目最难的部分，往往不在于把一个库存数字展示在页面上，而在于让采购到货、库存变化、库内作业、订单履约、供应商交付与在途运输这些原本分散的动作，能够在同一条业务链里被追踪和协同。
这次整理的项目是 链途智慧仓储供应链协同平台。它面向多仓运营场景，覆盖库存、入库、出库、作业任务、供应商协同和运输跟踪等环节。开发过程中，我把飞算JavaAI当作 Java 工程起步阶段的协作工具：先把业务边界和技术约束描述清楚，再根据智能引导逐步整理模块、依赖与基础代码结构，让注意力更多回到真正需要判断的业务规则上。
图 1：将链途的平台定位、技术栈和业务模块作为上下文输入。
一、仓库并不是一张库存表，而是一条跨角色的链
链途的目标不是单独做一个 WMS 页面集合，而是把仓库内部动作和供应链外部协同连接起来。以一笔采购入库为例，它会经过供应商交付、到货预约、收货、上架、库存占用与后续出库等状态；其中任一环节的数据滞后，都可能让计划、仓内作业和客户承诺出现偏差。
因此，平台按业务领域划分为仓库、商品、库存、订单、入库、出库、调度、运输、供应商、预警和数据分析等模块。前台不追求把所有指标堆在一个页面，而是让运营人员先看到今天该处理的异常、关键任务与跨仓状态，再进入对应环节完成操作。
图 2：登录页以“多仓协同、库存可视化、波次拣选、运输跟踪”概括平台的业务入口。截图中的账号为原型演示信息，生产环境应使用独立账号、强密码与权限控制。
二、先把需求说清楚，再让工程有可落地的边界
项目的技术组合包含 Vue 3、Spring Boot、Spring Cloud Alibaba、MySQL、Redis、RocketMQ、Elasticsearch、ShardingSphere、ClickHouse、Docker 与 Kubernetes。这样的组合并不等于把组件全部接入；真正重要的是先明确每一类能力解决什么问题：
- Spring Cloud Alibaba 负责服务发现、配置与服务间治理，让领域模块能独立演进；
- MySQL + ShardingSphere 承接订单、库存和作业等核心交易数据，并为后续数据扩展预留分片能力；
- Redis 用于热点查询、短期状态与必要的并发控制；
- RocketMQ 传递库存变化、任务推进、预警触发等异步事件，避免一次操作把所有下游都绑在同步链路上；
- Elasticsearch 与 ClickHouse 分别服务检索和运营分析，让实时交易与查询分析各自保持合适的节奏；
- Docker 与 Kubernetes 为服务部署、扩缩容和环境一致性提供基础支撑。
飞算JavaAI在这一阶段提供的是 Java 专属的工程协作入口。根据 Brief 中的产品信息，智能引导会通过 5 步梳理需求并生成完整 Java 工程，而不是只给出零散代码片段；内置的 10 个垂直领域专家 Agent 也适合在文档、工程结构、编译排错等任务之间切换。对这个项目而言，最有价值的不是“自动替人做决定”，而是更快把已明确的领域边界转成可继续补充的工程骨架。
图 3：根据需求创建 Maven 配置、统一返回对象和异常处理等基础文件，作为多模块工程的起点。
三、拆成多个服务之后，协同不能靠“各自成功”
供应链系统的典型风险，是每个服务各自执行成功，但整条业务链却停在了半路。链途把“状态变化可追踪、失败可补偿、关键动作可幂等”作为服务间协作的基本原则。
例如，入库确认后，库存中心需要更新可用库存，作业中心需要推进上架任务，预警中心可能要重新评估安全库存；这些动作适合由事件驱动进行传播。消费端以业务单号或事件标识去重，保证消息重投时不会重复扣减或重复生成任务。对必须严格串行的库存操作，则通过分布式锁、版本控制或状态机约束并发入口。
这里刻意把“业务状态”和“页面状态”分开：页面显示收货中、待处理、已发运等状态，是为了帮助运营人员判断下一步；后端则保留订单、库存、作业和运输各自的状态流转与事件记录。这样即使某个下游服务暂时不可用，也能通过重试、补偿和告警恢复，而不是把不一致隐藏在一次接口调用里。
四、入库、出库与库存：把最容易出错的三段链路放在一起看
库存中心需要同时展示可用库存、锁定库存与在途库存。这个拆分看似简单，却直接影响采购调拨、波次拣选和承诺库存的计算：可用库存用于判断是否可以继续分配；锁定库存代表已被订单或任务占用；在途库存则帮助运营人员预判未来补货。
图 4：库存中心按 SKU、仓库和库位查看三类库存，并标识库存偏低项。
入库管理把采购入库、调拨入库和到货预约放在同一入口。实际处理时，收货不等于最终上架：货物完成收货后仍需要根据质检、库位与作业任务推进，库存状态也应随过程逐步切换。
图 5：入库管理聚合采购入库、调拨入库和预约到货状态。
出库侧则围绕销售出库、波次拣选、复核和发运组织。订单数、商品数量和波次号被保留在一张可追踪的任务记录里，便于在拣选中、复核中或已发运等节点定位问题。
图 6：出库管理按发货仓、订单数、商品数量和波次号组织待办。
五、看得见的运营现场，才谈得上协同
平台工作台不是一张“漂亮的大屏”，而是运营动作的汇总入口。当天入库量、出库量、库存准确率、订单履约率和异常预警被放在同一视图中；趋势图与各仓库容量利用率用于辅助判断资源是否需要调配，关键作业任务则保留给一线人员继续推进。
图 7：工作台汇总多仓入出库、履约、预警、趋势与库容信息。
作业任务页面将上架、波次拣选、动态盘点和异常复核按进度排列。相比只显示“任务已创建”，进度、负责人和仓库信息更能让管理人员判断任务是等待资源、正在处理，还是需要升级处置。
图 8：作业任务页面展示任务类型、仓库、负责人和推进进度。
供应商协同页则将准时交付率、质量合格率和在途订单纳入同一维度。它不负责替代供应商管理流程，但能把影响仓内计划的交付信息前置，减少“货没到、计划却已经排好”的被动情况。
图 9：运输跟踪按运单展示路线、承运信息、运输进度和签收状态。
六、这次开发留下的，不只是一个展示页
回看链途的实现过程，最值得保留的经验有三点：
- 先建立领域语言。 “库存”“锁定”“在途”“波次”“收货”这些词必须在产品、前端和服务端之间保持同一种含义，后续接口和数据模型才不容易漂移。
- 让状态变化可回放。 库存、任务、订单和运输都不是孤立数据，围绕业务单据记录状态与事件，才能在异常发生时知道从哪里补偿。
- 把 AI 放在合适的位置。 飞算JavaAI更适合协助完成需求澄清、工程初始化、基础代码与排错等高频环节；涉及库存口径、履约规则和并发边界的决策，仍需要开发者结合业务场景作最终判断。
本次作品也借着飞算JavaAI炫技赛的契机，记录了从业务描述、工程起步到可运行界面的过程。根据活动资料，本期活动时间为 2026 年 7 月 10 日至 7 月 27 日，设置了“晒一晒”和“讲一讲”两个内容方向；前者适合展示阶段性成果，后者更适合完整复盘项目设计。产品资费与活动奖励会随页面信息更新，当前可通过官方页面查看；Brief 中列出的版本信息为 9.9 元/月。对于想尝试 Java AI 协作开发的同学，可以先从一个边界清晰、能观察到完整链路的项目开始：先让工程跑起来，再用真实业务问题不断校正它。
#飞算JavaAI炫技赛 #AI编程 #Java开发 #程序员日常 #技术分享 #开发者工具
