业务流程 / 知识与设计

无人机物流 | 把一次配送做到最后一步

包裹、机体、起降场地、交接、异常。把一条飞得通的航线,连接成一项真正送得到的服务。

按顺序阅读本页
01

最小的工作单位是一次配送任务

为每一个配送请求明确包装、重量、交接方式、时间窗,以及起点与终点的条件。MLIT(日本国土交通省)的物流资料汇集了入门指南等资源。基本前提是,您需要针对自己的具体机体、地区和运行方式,确认相应的规则与安全组织体系。

来源:MLIT | 物流领域的无人机应用
层面设计问题
需求谁的什么东西,要在什么时候之前送到?
场地包裹能否在那里安全交接?
运行机体、航线、天气和通信条件是否匹配?
签收凭什么确认送达,又凭什么确认签收?
异常取消、收件人不在、取回和地面配送由谁处理?
02

把配送状态与飞行状态分开

配送被受理,不代表飞行已经开始。飞机已经降落,不代表包裹已经交接。不要把这两者合并成一个状态。

配送:requested → accepted → in_transit → received
                                         ↘ delivery_exception
任务:draft → approved_for_operation → airborne → landed
                     ↘ delayed / cancelled

received 的凭证:收件人确认、快递柜确认,或其他约定的方式
绝不能仅凭 landed 就改为 received
03

把异常情况也算进盈利性

一次成功飞行的成本,说明不了这项业务是否可持续。待命时间、取消、取回、设施和地面交接也要记录下来。下面的公式是一份用于收集您自己运营数据的设计提案。

单位周期配送成本
  = 机组人工 + 机体与场地成本 + 维护与通信
  + 地面处理 + 异常处理

单次配送成本 = 周期成本 / 已确认签收的配送件数
同时跟踪:取消率 / 取回次数 / 签收用时

分母是飞行架次还是包裹件数,数字会完全不同。把单位和范围写进指标名称里,不要把不同地区或不同试验条件下的结果混在一起。

04

把第一次试点收得小一点

先限定航线、包裹、运行时段和交接方式,并分别为飞行和配送定义成功标准。取得实际运行所需的许可和组织体系,从桌面研究和仿真开始逐步升级。对公众的承诺,只能到您已经验证过的程度为止。

完成的定义

构建时,请检查以下要点。

  • landed 与 received 分别以各自的凭证记录。
  • 取消时通知谁、备用方案由谁负责,均已明确。
  • 成本可以按整个周期汇总,而不只是成功的飞行。

用于规格评审与功能测试的设计检查清单。

查看资料来源

有关规则与定义的解说参考了以下资料。界面、数据与完成的定义均为我们自己的设计提案。

资料核对日期:2026 年 9 月 30 日。针对您的具体情况,请以最新的官方信息为准。