设备与操作员信息散在表格里,登记不全、更新不及时
项目概览
客户是谁
某无人体系运营方向项目。交付的是一套身份管理平台,覆盖设备与操作员的登记、审核与状态台账;Java 微服务后端,Web 管理后台。
遇到什么问题
无人设备数量少的阶段,表格够用;数量一多,谁在飞、谁能飞、哪台设备还能用,全靠人记。
- 登记材料交上来有没有人审、审过没有,没有固定流程。
- 设备转让或停用之后,表格忘了改,底册就慢慢失真。
运营方缺的不是一张更大的表,而是一个流程化的底册。
我们做了什么
- 登记与审核分离。提交归提交、审核归审核,每个节点的处理人与时间留痕,避免「交了就算登了」。
- 状态变更走流程不走手工。停用、转让、报废都是台账事件,记录在案,底册的可信度靠流程维持,不靠自觉。
- 字段最小化起步。登记字段一多,填报质量立刻下降;先把关键字段跑通,再按运营需要扩展。
难点怎么解决的
- 底册随表格失真:登记与审核分节点留痕,状态变更走流程,可信度靠机制而不是靠人记。
- 填报质量上不去:字段最小化起步,先跑通关键字段。
- 后续要对接外部系统:接口层预留统一出口。
交付了什么
系统按服务端、业务层、接口层组织:Java 微服务承载流程;业务层覆盖登记、审核流转与状态台账;接口层提供查询导出,为后续与运营系统的对接预留了统一出口。
现在的状态
系统处于维护期。我们负责身份登记与审核业务层;与外部监管平台的对接另行立项,无人机硬件与飞控相关系统不在范围,作业审批类业务流程也不在其中。
项目信息
某无人体系运营方向项目
低空经济与无人系统
未披露
Java 微服务 / Vue / Web 管理后台
无人体系身份管理平台
CHALLENGES
客户当时面对的现实
审核流转没有固定流程,谁批的、什么时候批的查不到
设备状态变化(停用、转让、报废)没有台账,底册很快失真
CAPABILITIES
我们交付的能力
无人设备多起来之后,第一件缺的事是一本清清楚楚的身份底册
设备与操作员登记
设备信息与操作员资质分类登记,字段可按运营要求扩展。
审核流转
登记材料走审核流程,每个节点的处理人与时间留痕。
状态台账
在用、停用、转让、报废等状态变更全程记录,底册持续可信。
查询与导出
按类型、状态、时间段检索,支持按需导出对账。
SCOPE
交付范围
以下范围按本项目实际交付内容与边界整理,不属于这次范围的部分一并列出。
已交付
- 登记与审核模块
- 状态台账
- 查询导出
- 管理后台界面
不在本次范围
- 与监管平台的对接(另行立项)
- 无人机硬件与飞控相关系统
- 作业审批类业务流程
ARCHITECTURE
分层技术架构
公开口径归纳为三层:Java 微服务承载登记审核流程;业务层覆盖登记、审核流转与状态台账;接口层提供查询导出,为后续对接预留统一出口。
服务端
承载登记审核流程
业务层
身份底册主链路
接口层
对账与后续对接预留
DELIVERY
交付过程
分阶段推进,每个阶段都有可验收的产出,客户在早期就能看到实际效果。
字段与流程定义
确定登记字段最小集与审核层级。
登记与审核模块
实现登记提交、审核流转与节点留痕。
状态台账
落地停用、转让、报废等状态变更流程。
导入与上线
既有表格数据整理导入,作为底册初始数据。
FACTS
可核验的交付事实
以下内容来自本项目实际交付物;未经验证的指标不予展示。
设备 / 操作员
审核与状态变更可回溯
登记审核查询统一后台
TRANSFER
这套做法适不适合你
案例的用处不是证明"我们做过",而是让你判断"在我们这种条件下能不能做成"。下面三句是我们对这一单的判断,写下来供你对照自己的情况。
适合什么情况
适合无人设备规模上来后、需要一本可信底册的运营方。
什么情况下别照搬
外部平台对接、飞控与硬件相关系统不在本次范围。
如果要试,第一步做什么
确定登记字段与审核层级,先把最小底册跑起来。
FAQ
常见问题
以下是同类项目沟通中出现频率最高的问题,答案就是我们实际的做法。
这套系统和监管平台是一回事吗?
设备状态变化频繁,台账会不会很快过时?
这套系统是你们自己写的吗?
能对接我们现有的表格数据吗?
第一步做什么?
本页最后更新:2026年9月26日