多厂商机器人统一管理平台：用 AI 完成 AetherLink 的设计与交付
摘要：客户已经采购多家厂商的机器人，但设备状态、任务、位置和异常信息分散在不同入口。为解决这一问题，我参与设计并实现了前端工程 AetherLink，将设备、任务、地图、视频、告警和 IoT 接入纳入统一的园区机器人管理框架。本文主要记录业务闭环梳理、AI 协作开发、Mock 验证以及内网部署交付过程。
1. 项目背景：多厂商机器人需要统一管理入口
随着园区内机器人类型和数量增加，一个现实问题逐渐暴露出来：不同品牌有各自的管理方式，设备状态、执行任务、运行位置和异常信息分散在多个入口。管理者很难从园区整体视角判断机器人正在做什么，也缺少一个能够继续接入新设备的统一平台。
这就是“机器人平台”出现的原因。它的前端工程名为 AetherLink，最终形成了一套可以运行、演示并部署到内网的园区机器人管理产品。平台围绕设备、任务、地图、视频、告警和 IoT 接入组织业务，并以指挥大屏作为全局入口。
我在项目中的工作覆盖业务理解、需求澄清、系统拆分、方案选择、AI 协作实现和交付验证。整个过程中，最重要的工作是持续为 AI 提供清晰边界，并判断生成内容能否组成一个可长期迭代的产品。
2. 将“统一管理”转化为业务闭环
“做一个统一平台”听起来目标明确，但进入实现阶段后，很容易变成页面堆叠。我先从客户已经采购多家机器人这一事实出发，梳理平台需要解决的共同问题。
不同机器人虽然用途各异，但管理过程存在相似结构：设备需要注册和分组；运行时会产生状态与位置；工作由任务驱动；执行过程可能触发异常；管理者还需要回看相关记录。基于这些共性，平台的业务主线被收敛为：
设备接入—任务执行—过程监控—异常处理—结果追踪
这一抽象直接决定了后续模块之间的关系：
- 设备管理提供统一的管理对象；
- 任务调度负责组织工作；
- 地图和视频用于观察执行过程；
- 告警中心承接异常信息；
- 数据与日志用于结果回溯。
清洁、巡检、配送和 AGV 等机器人可以保留各自特征，同时进入同一套管理视图。
我也主动区分了当前交付范围和未来能力。数字孪生、远程控制、视频智能分析等方向可以保留入口，但不能让预留功能干扰核心业务闭环。先让主要业务路径完整可见，再根据真实设备协议逐步接入，更符合多厂商机器人场景的演进节奏。
3. 用模块边界组织 AI，而不是一次生成整个系统
确定业务主线后，我将工作拆成几层约束交给 AI：
- 建立全局导航和页面骨架；
- 统一设备、任务、告警等核心状态；
- 完成各业务模块；
- 补充演示数据、配置开关和部署方式。
这种拆分可以降低 AI 在大型项目中出现上下文漂移的风险。设备状态需要同时出现在列表、地图和指挥大屏中；任务状态会影响设备当前工作、执行历史和统计视图；告警级别也需要在不同页面保持一致的语义。如果每个页面独立生成，名称、颜色、状态流转和交互口径很容易互相冲突。
因此，我要求将公共状态沉淀为常量，将通用展示抽取为组件，按照业务域组织接口，并让页面只消费统一的数据结构。仓库中可以看到设备、任务和告警的常量划分，也包含状态徽标、电池指示、统计卡片和通用面板等公共组件。这些内容表明，系统已经开始形成可复用的产品结构，而不是若干互不相关的效果页。
我的主要投入集中在提供业务约束、检查模块之间的关系，以及决定哪些内容应该共享、哪些内容应当隔离。AI 用于加速页面和工程代码生成，而我负责让这些产物始终向同一个系统目标收敛。
4. 通过 Mock 模式提前验证平台
多厂商机器人项目通常会受到设备协议、后端进度和现场环境的影响。如果所有前端工作都等待真实接口，需求讨论可能长期停留在文档和口头描述上。
为此，我为平台保留了 Mock 演示模式，并让接口调用统一经过请求层和数据适配边界。设备、任务、告警、地图和巡检等模块都有对应的模拟数据，开发模式与演示模式也拥有独立的启动和构建入口。即使暂时没有完整后端，平台的导航结构、状态表达和关键操作路径仍然可以被直接体验。
Mock 在这里不仅用于填充页面，也承担业务验证工具的作用。客户可以看到：
- 多类机器人如何进入同一设备视图；
- 任务从创建到执行结果如何表达；
- 地图如何关联设备位置；
- 告警如何进入处理流程。
当真实厂商接口接入时，变化主要集中在数据来源和适配层，页面结构与业务语言可以继续复用。
这也是我在 AI 辅助开发过程中坚持的一条原则：每个阶段都要产生可观察的结果。与大量尚未验证的描述相比，可运行界面更容易暴露问题，也能更早发现业务对象之间缺失的关系。
5. 从“页面能打开”走向可交付
功能覆盖完成后，我将验证重点放在完整业务路径和部署边界上。路由中包含登录、指挥大屏、设备、任务、地图、视频、告警、巡检、IoT 和系统管理等入口，并通过统一布局和状态管理连接起来。大型页面采用按路由加载，生产构建能够输出静态资源，以便部署到 Nginx。
5.1 检查跨平台路径问题
交付检查还需要覆盖一些容易被 AI 忽略的工程细节。例如，Windows 环境通常对路径大小写较宽松，而 Linux 部署环境会严格区分路径大小写。因此，我将导入路径与实际文件名的一致性列入构建检查。
5.2 配置单页应用路由回退
单页应用部署到 Nginx 时，需要配置路由回退，避免用户刷新业务页面后得到 404。API 地址、功能模块和主题配置也被集中管理，为后续切换环境、关闭未启用模块和品牌定制保留边界。
这些工作没有指挥大屏的视觉效果醒目，却会直接影响产品能否从开发环境进入客户内网。稳定落地通常由一系列具体判断组成：
- 演示数据与真实接口可以切换；
- 模块能够按需启用；
- 构建产物可以独立部署；
- 预留能力具有明确边界。
6. 项目沉淀：AI 辅助开发仍依赖持续判断
机器人平台目前已经形成可运行、可演示、可构建部署的前端产品，能够将分散的园区机器人管理需求纳入同一套业务框架。项目没有提供公开访问地址，现阶段更适合作为内网交付和后续设备接入的基础。
这次实践让我更加确定，AI 时代的工程价值仍然体现在持续做出正确判断：先识别客户真正缺少的管理闭环，再将复杂系统拆分为稳定边界；让 AI 在边界内快速实现，同时通过统一状态、数据适配、演示模式和部署检查控制质量。
只有当这些工作能够连贯完成，来自客户现场的模糊想法，才会逐渐转化为可体验、可交付并能够继续迭代的产品。