飞算JavaAI协作开发实录：让链途智慧仓储供应链协同平台跑起来

仓储项目最让人头疼的，往往不是把库存数字画在页面上，而是让采购到货、库存变化、库内作业、订单履约、供应商交付和在途运输这些原本散落各处的环节，能在同一条业务链里被追踪、被协同。这背后的逻辑，远比一个漂亮的界面复杂得多。

这次要聊的项目是“链途智慧仓储供应链协同平台”。它瞄准的是多仓运营场景，覆盖了库存、入库、出库、作业任务、供应商协同和运输跟踪等环节。在开发过程中，我尝试把飞算Ja vaAI当作Ja va工程起步阶段的协作伙伴——先把业务边界和技术约束描述清楚，再根据智能引导逐步整理模块、依赖和基础代码结构，这样就能把有限精力放回那些真正需要判断的业务规则上。

图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为服务部署、扩缩容和环境一致性提供基础支撑。
飞算Ja vaAI在这个阶段提供了一个Ja va专属的工程协作入口。根据Brief中的产品信息，智能引导会通过5步梳理需求并生成完整Ja va工程，而不是只给零散代码片段；内置的10个垂直领域专家Agent也适合在文档、工程结构、编译排错等任务之间切换。对这个项目而言，最有价值的不是“自动替人做决定”，而是更快把已明确的领域边界转成可继续补充的工程骨架。

图3：根据需求创建Ma ven配置、统一返回对象和异常处理等基础文件，作为多模块工程的起点。

三、拆成多个服务之后，协同不能靠“各自成功”

供应链系统的一个典型风险，是每个服务各自执行成功，但整条业务链却停在了半路。链途把“状态变化可追踪、失败可补偿、关键动作可幂等”作为服务间协作的基本原则。

举个例子，入库确认后，库存中心需要更新可用库存，作业中心需要推进上架任务，预警中心可能要重新评估安全库存。这些动作天然适合由事件驱动进行传播。消费端以业务单号或事件标识去重，保证消息重投时不会重复扣减或重复生成任务。对于必须严格串行的库存操作，则通过分布式锁、版本控制或状态机约束并发入口。

这里刻意把“业务状态”和“页面状态”分开：页面显示收货中、待处理、已发运等状态，是为了帮助运营人员判断下一步；后端则保留订单、库存、作业和运输各自的状态流转与事件记录。这样，即使某个下游服务暂时不可用，也能通过重试、补偿和告警恢复，而不是把不一致隐藏在一次接口调用里。

四、入库、出库与库存：把最容易出错的三段链路放在一起看

库存中心需要同时展示可用库存、锁定库存与在途库存。这个拆分看似简单，却直接影响采购调拨、波次拣选和承诺库存的计算：可用库存用于判断是否可以继续分配；锁定库存代表已被订单或任务占用；在途库存则帮助运营人员预判未来补货。

图4：库存中心按SKU、仓库和库位查看三类库存，并标识库存偏低项。

入库管理把采购入库、调拨入库和到货预约放在同一入口。实际处理时，收货不等于最终上架：货物完成收货后仍需根据质检、库位与作业任务推进，库存状态也应随过程逐步切换。

图5：入库管理聚合采购入库、调拨入库和预约到货状态。

出库侧则围绕销售出库、波次拣选、复核和发运组织。订单数、商品数量和波次号被保留在一张可追踪的任务记录里，便于在拣选中、复核中或已发运等节点定位问题。

图6：出库管理按发货仓、订单数、商品数量和波次号组织待办。

五、看得见的运营现场，才谈得上协同

平台工作台不是一张“漂亮的大屏”，而是运营动作的汇总入口。当天入库量、出库量、库存准确率、订单履约率和异常预警被放在同一视图里；趋势图与各仓库容量利用率用于辅助判断资源是否需要调配，关键作业任务则保留给一线人员继续推进。

图7：工作台汇总多仓入出库、履约、预警、趋势与库容信息。

作业任务页面将上架、波次拣选、动态盘点和异常复核按进度排列。相比只显示“任务已创建”，进度、负责人和仓库信息更能让管理人员判断任务是等待资源、正在处理、还是需要升级处置。

图8：作业任务页面展示任务类型、仓库、负责人和推进进度。

供应商协同页则将准时交付率、质量合格率和在途订单纳入同一维度。它不负责替代供应商管理流程，但能把影响仓内计划的交付信息前置，减少“货没到、计划却已经排好”的被动情况。

图9：供应商协同页面汇总交付、质量与在途订单情况。

最后一段是运输跟踪。出库完成并不代表供应链任务结束，车辆、路线、司机与签收状态仍然是履约闭环的一部分。将这些信息与出库任务关联，客服、调度和仓库才能围绕同一个订单上下文沟通。

图10：运输跟踪按运单展示路线、承运信息、运输进度和签收状态。

六、这次开发留下的，不只是一个展示页

回看链途的实现过程，最值得保留的经验有三点：

先建立领域语言。“库存”“锁定”“在途”“波次”“收货”这些词必须在产品、前端和服务端之间保持同一种含义，后续接口和数据模型才不容易漂移。让状态变化可回放。库存、任务、订单和运输都不是孤立数据，围绕业务单据记录状态与事件，才能在异常发生时知道从哪里补偿。把AI放在合适的位置。飞算Ja vaAI更适合协助完成需求澄清、工程初始化、基础代码与排错等高频环节；涉及库存口径、履约规则和并发边界的决策，仍需要开发者结合业务场景作最终判断。
这次作品也记录了一个从业务描述、工程起步到可运行界面的完整过程。对于想尝试Ja va AI协作开发的同学，可以从一个边界清晰、能观察到完整链路的项目开始：先让工程跑起来，再用真实业务问题不断校正它。