发布应用生成Agent以来，蓝卓一直在做一件事：不断用真实工业场景，验证它的能力边界。因为相比「Agent能生成工业APP」这样的概念，更值得关注的是：Agent到底能生成什么样的工业APP。

最近，我们给应用生成Agent出了一个新的题目，这个题目并不简单👇

实战演练：生成设备健康管理APP，包含设备建档、设备分类、设备分组、实时监测、预警管理等基础功能，并涉及故障知识库、维护工单、备件管理、报表分析等完整业务体系。

更重要的是，这些模块之间并不是孤立存在，而是需要建立真实的数据关系和业务流转逻辑。最终生成出来的，不是一组页面，而是一套能够部署运行的设备健康管理应用。

这一次，我们想展示的不是Agent能不能生成APP，而是它已经能够做到什么程度。

从真实业务开始

而不是从页面开始

在很多人的印象里，AI 生成应用，往往意味着输入一句话，然后得到几个页面。但工业应用真正复杂的部分，从来不是页面，而是业务。

在这次案例中，应用生成Agent接收到的并不是「帮我做一个设备管理系统」这样简单的需求，而是一整套真实业务要求。

真实业务需求：

• 设备需要支持建档、分类和分组管理；
• 采集参数需要绑定具体设备；
• 设备分类需要被预警阈值模板引用；
• 设备ID和模板ID需要通过弹窗选择并自动回填；
• 新增预警记录后，需要根据通知配置调用supOS站内信；
• 设备分组中需要实时显示关联设备数量，并支持查看具体设备列表；
• 所有关键操作都需要进入系统日志，并记录IP地址。

这些都不是页面需求，而是真实工业场景中的业务需求。

应用生成Agent所完成的，也不仅仅是生成页面，而是把这些自然语言需求逐步转化为业务对象、数据模型、交互逻辑和应用结构。

不仅生成页面

更构建业务数据关系

工业现场最怕的一种系统，是功能很多，但数据彼此孤立。看起来什么都有，但彼此之间没有关系。

而这次生成的设备健康管理APP，从一开始就在构建完整的数据关系：

完整数据关系：

• 设备信息关联设备分类和设备分组；
• 采集参数绑定具体设备；
• 预警阈值模板关联设备分类；
• 预警配置绑定设备与模板；
• 预警记录关联通知配置、故障记录和维护工单；
• 备件入库、出库、调拨和盘点共同影响库存数量；
• 报表统计汇总设备、预警、维护和备件数据；
• 系统操作日志记录关键操作，支撑后续追溯。

这意味着应用中的每一次操作，都会影响后续业务流程。

• 新增设备后，设备总数自动变化；
• 设备加入分组后，分组统计实时更新；
• 选择预警模板后，相关配置自动关联；
• 产生预警记录后，系统自动找到对应通知配置；
• 维护过程中消耗备件后，库存同步变化。

对于工业应用而言，这些数据关系远比页面本身更重要。因为真正有价值的从来不是“有多少功能”，而是这些功能能否协同工作。

不仅能生成

还能基于上下文精准修改

应用生成只是第一步。工业现场真正的挑战，往往来自后续不断出现的新需求。

在这次案例过程中，现场团队持续提出优化意见。

菜单层级不合理，直接提出：

“请帮我优化菜单层级结构。”

系统根据已有功能模块重新整理菜单，而不是让用户去找代码文件。

设备字段越来越多，直接提出：

“新增和编辑页面统一改成右侧抽屉。”

系统把相关页面的新增、编辑交互统一调整。

设备分组统计结果异常，直接提出：

“先检查原因，再做最小范围修复。”

这些需求背后涉及页面、接口、数据模型和统计逻辑的调整。而应用生成Agent并不是推倒重来，而是在已有应用基础上持续完成修改。

这说明对话式生成不是无边界地乱改，而是可以围绕已有数据模型、页面结构和业务逻辑进行定向修改。

这也是本次案例中特别值得关注的一点。它完成的已经不仅是从0到1生成应用，而是在已有上下文基础上持续理解需求、调整应用并保持整体一致性。

真正的考验

是业务流程能否跑通

评价一个工业APP，不能只看首页，更要看业务流程能否真正跑起来。这次设备健康管理APP中，一条完整业务链路被构建出来：

设备建档 → 参数配置 → 数据监测 → 阈值判断 → 生成预警 → 消息通知 → 故障分析 → 维护工单 → 备件使用 → 报表统计。

环节	作用
设备建档	提供基础数据
采集参数	决定监测哪些点位
阈值配置	决定什么情况算异常
预警记录	沉淀异常事件
通知配置	决定消息发给谁
故障知识库	帮助判断原因
维护工单	推动现场处理
备件管理	支撑维修消耗
报表记录	用于后续分析

其中有一个典型需求非常具有代表性：

客户要求：

当新增一条预警记录时，需要绑定对应预警通知配置，并调用supOS站内信接口，把消息发送给指定责任人。

这看似只是一个通知动作，实际上涉及预警记录、通知配置、责任人信息和平台接口之间的协同。

当这条链路真正跑通时，说明生成的已经不是一个demo演示系统，而是一套能够驱动现场业务运行的工业应用。

复用平台能力，从生成到部署

完成最后一公里验证

工业现场并不需要更多孤立系统。

如果每开发一个APP，都要重新建设一套用户、角色、权限、菜单以及运行环境，不仅会增加开发工作量，也会带来更高的运维和管理成本。

因此，这次设备健康管理APP从生成之初就明确运行在supOS X平台之上。用户、角色、权限、菜单等基础能力全部复用平台体系，不在应用内部重复建设，应用则聚焦于业务场景本身。

这也是应用生成 Agent在工业场景中的关键能力之一。它不仅需要理解「我要实现什么功能」，还需要理解「这个功能应该放在什么平台架构中实现」。

• 平台负责统一用户、权限、菜单、接口和运行环境
• APP 负责具体业务场景
• 数据通过平台能力接入、治理和调用
• 业务流程在 APP 中组织和交互

只有建立在统一平台之上的应用，才能真正融入企业现有数字化体系，而不是成为新的信息孤岛。

工业软件还有最后一道门槛：部署。很多系统能够生成，但距离真正交付还有很长距离。

最终，生成完成的设备健康管理APP 被导出为 Linux 安装包，并成功部署到本地 supOS X 环境运行。

从需求表达，到应用生成；从数据关系构建，到业务流程打通；从持续修改，到最终部署，整条链路完成验证。

这次验证的价值

不在于生成了一个APP

设备健康管理APP并不是一个孤立案例，它更是应用生成Agent能力边界的一次新验证。

这次验证中，我们看到的不只是页面生成能力，而是业务理解能力、数据建模能力、流程组织能力、持续迭代能力以及平台集成能力的协同发挥。

对于工业软件而言，这些能力比生成页面更重要，因为现场真正关心的，从来不是AI会不会写代码，而是能不能把需求变成系统，把数据变成流程，把反馈变成持续迭代。

而这一次，应用生成Agent给出的答案，比上一次又向前走了一步。