1. 项目起因领导要一块“能看全厂”的屏幕而不是又一张数据报表去年底我接手了一个制造企业的数字化转型项目。项目本身不新ERP、MES、SCADA 这些系统早就部署了厂里的自动化程度也不算低几十台数控设备加三条装配线数据采集网关也都跑了好几年。但问题在于这些东西全都分散在不同的系统里。车间主任要看设备状态得打开 MES 客户端能源管理员要查电表得单独登一个平台安全员每天靠对讲机问现场情况。信息在系统里但人拿不到或者说拿到的时候已经晚了。领导当时的需求很直接做一块大屏把厂房给我“搬”上去谁来看都能一眼知道现在厂里什么情况。最开始他内心想的其实是一张极尽炫酷的驾驶舱页面各种动态图表、灯光特效、科技感拉满。但我在项目调研阶段就意识到如果只做一个视觉包装过的 Web 报表那本质上还是在做图表只是把三步操作变成了一步。真正值得做的是用 3D 大屏去解决“空间认知”的问题——哪个设备在哪、现在什么状态、报警了周围有哪些关联设备、这半条产线为什么停下来这些信息只有落到空间位置里才有意义。也正是这个判断让我决定把整条链路走得重一点不仅是搭一个可视化页面而是从需求调研、指标梳理、场景建模、前端开发到数据回流全部自己过一遍。过程中我把 GPT-Image-2.5 和 GPT-6 Astra 两个 AI 工具分别塞进了生产流程里前者负责 3D 场景资产、材质贴图和视觉设计稿后者负责前端代码、接口适配和调试兜底。整个项目做完我发现 AI 工具链的引入不是帮我把某一步提速了而是在改变整个项目的组织方式。1.1 3D大屏的核心价值并不在于“好看”做可视化项目的人容易陷入一个误区以为 3D 大屏的价值在于视觉效果。确实甲方验收的时候第一眼看到的就是画面炫不炫但炫完之后真正决定这个项目能不能被日常用起来是信息是否可读、可查、可处置。我在这类项目里最常举的一个例子是“设备报警”传统二维看板可以做到在表格里列出一行红字“CNC-07 主轴温度过高”但操作员看到这行字之后还要去回忆 CNC-07 在哪、旁边有没有装卸工、周围的 AGV 会不会受影响。3D 大屏解决的是这之后的两秒钟——场景一拉近设备高亮闪烁周边的工位、物料、人员轨迹一览无余。这种“空间语境”是二维图表给不了的。所以在项目的第一次需求沟通会上我的 PPT 里没有放任何好看的效果图只放了三句话第一用空间定位替代表格搜索第二用态势感知替代文本报警第三用处置闭环替代只报不管。这三句话后来成了整个项目的验收标准比任何花哨的 UI 设计都管用。1.2 我给自己定的目标边界一个大屏项目里最容易失控的是需求范围。今天想看设备综合效率明天想看能耗分析后天又想把摄像头视频流接进来最后页面承载不了性能也崩了。我在动手之前给自己划了三条边界只做“管理层视角”的内容不做车间实时操作层的内容。设备参数微调、程序启停这些必须在原系统里完成大屏只负责呈现和跳转。数据只做“读”不做“写”所有派单、确认、参数修改都通过接口回调给原系统大屏本身不存业务数据。3D 场景只做到“定位级精度”不做毫米级仿真。设备的减速机转了几圈、皮带怎么在动这些细节不做因为对管理决策没有价值只会把成本和性能拖垮。这三条边界在整个开发过程中帮我挡掉了无数次需求变更。每次业务方提新想法我先问一句这属于管理决策需要的信息吗不属于就拒绝属于再评估数据能不能拿到。拿着这个标准去沟通项目推进要顺利得多。2. 调研阶段花了两周在厂房里走了一遍数据流标题里我写了“从调研到闭环”这个调研不是走过场。我花了整整两周时间泡在厂房里做了一件事把厂里几乎每个工位、每台设备、每条网络链路都走了一遍。这一步很枯燥但价值极大——后续所有开发工作、所有 AI 提示词的设计都基于这两周的认知积累。2.1 盘点清楚设备、点位和通信协议我盘点的第一步是拉设备清单。这家厂不算特别大但设备类型很杂两个加工车间里共有 38 台数控机床品牌有新有旧装配车间的三条产线上有 21 台工位终端和 4 台六轴机器人另外还有 6 台 AGV、3 套空压机组、1 个中央供料系统。设备总共 70 多台如果算上传感器点位真正需要上屏的接入点超过 600 个。盘点完设备第二步是梳理通信协议。这一步最耗时间因为老设备和新设备完全是两套思路设备类型通信方式数据内容采集频率新数控机床OPC-UA主轴转速、进给倍率、报警代码、程序号秒级老数控机床Modbus TCP运行状态、主轴负载、故障码秒级六轴机器人厂商私有 SDK关节坐标、程序步、报警毫秒级AGVMQTT当前位置、电量、任务状态秒级空压机组电表PLC 采集模块功率、排气压力、温度分钟级工位终端HTTP API工单号、计划数量、完成数量分钟级这个表格我后来直接拿给了 GPT-6 Astra 用。AI 对协议的理解能力很强比如我告诉它“数据入口是 OPC-UA字段语义是主轴负载单位是百分比”它生成的读代码基本不需要改。2.2 真正的麻烦数据不在同一个地方设备盘点完数据的获取方式基本清楚了。但这时候冒出来一个比通信协议更头疼的问题这 600 多个点位的实时数据分散在三套系统里。MES 只管工单和产量SCADA 只管设备状态能源管理平台只管电量。也就是说同一个设备的“运行状态”和“当前工单”在数据库里根本不在一起。我在调研笔记里画了一版数据流向图大概是这样设备 PLC 和传感器 → 边缘网关 → SCADA/OPC-UA 服务 → 时序数据库MES 数据库 → 工单表、产量表、报工表电表 → 能源管理平台 → 关系库AGV 调度系统 → MQTT Broker → 消息队列。传统做法的确可以写一堆 ETL 任务把这几个库同步到一个数据中台。但那个周期太长了而且会牵扯到好几个厂商的配合。我当时的思路是先不做统一数据中台而是让前端直接订阅多个数据源在展示层做融合。这个决定能让我用两周时间上联调而不是等三个月。2.3 哪些指标值得上大屏哪些别上调研过程中我每见一个业务负责人都会问同一个问题你每天最想在一屏之内看到什么问了一圈之后发现答案高度集中在几类信息设备实时状态哪台在运行、哪台故障、哪台空闲超过 30 分钟当班产量和计划达成率最好能按产线拆分异常报警故障等级和响应状态有没有人接单、有没有超时能耗异常哪条产线单位产量能耗明显偏高AGV 位置和电量尤其是低于阈值时的提醒。没被选上大屏的也有不少设备累计运行时长、点检记录、备件库存明细、质量追溯的批次追踪。这些信息适合在系统里翻不适合在大屏上滚动。我后来总结了一个筛选原则大屏只放“需要人做出反应”的信息纯记录型信息一律不上。3. 技术选型用 GPT-Image-2.5 和 GPT-6 Astra 搭配干活需求理清楚之后真正难的部分来了这个 3D 大屏项目用什么技术路线做传统方案成熟但流程长、成本高、周期不可控。我把三条路线摆在一起对比过最后选了“AI 辅助全流程”的路线。3.1 传统方案的成本构成先说传统的做法大部分可视化公司报 3D 大屏项目成本主要由三块构成一是建模成本。厂房、设备、产线全部做白模精度要求高的还要做贴图烘焙一个中等规模厂房场景外包报价通常在 3 万到 8 万之间周期 3 到 6 周。二是前端开发成本。3D 场景里要做视角旋转、缩放、设备点击高亮、数据标签绑定这些交互逻辑开发量不小少说也是 3 周起步的工作量。三是联调成本。前后端联调、真实数据替换 mock 数据、大屏分辨率适配很多项目光这一步就能拖一个月。这套路线最大的问题不是贵而是“改不动”。业务方看到第一版模型后提意见是必然的“这个设备颜色不对”“厂房布局好像反了”“能不能从侧面看”每改一次都要走建模—导出—导入—重新配交互的流程效率非常低。3.2 为什么是图像模型加编码模型的组合在这个项目里我最终选的技术路线是GPT-Image-2.5 负责所有视觉资产生成GPT-6 Astra 负责前端代码和接口逻辑底层渲染用 Three.js图表用 ECharts数据对接走 WebSocket。这套组合的考虑很简单GPT-Image-2.5 这类图像模型最擅长的是把一段文字描述变成高质量的图片素材。3D 大屏的场景里厂房外观、设备贴图、材质纹理、科技感装饰元素这些东西本质上都是图像资产。以前这些资产需要建模师用 3ds Max 或者 Blender 逐一制作现在我可以让模型先生成概念图和贴图再在三维场景里拼装。速度上是天壤之别。GPT-6 Astra 的优势则是它处理“结构化任务”的能力很强。它不像早期代码模型只能生成单文件 demo而是能理解整个前端项目的结构哪种组件放在哪个目录、状态管理怎么组织、接口返回的字段怎么映射到图表配置。我甚至可以直接对它说“把后端的告警列表接口接上并在顶部做一个滚动播报组件”它生成的代码可以放进项目里直接用。这两种能力互补性很强一个负责给大屏“化妆”一个负责给大屏“接脑子和手脚”。3.3 工具边界划分图像管视觉模型管代码用 AI 工具最忌惮的是边界不清。图像模型不是不能生成代码编码模型也能生成一些简单的 SVG 图形但跨领域使用时效率极低、幻觉极高。我在项目里给两个工具画了严格的分界线GPT-Image-2.5 只负责产生视觉素材场景参考图、设备单体图、材质贴图、UI 设计稿、科技感底纹。所有输出都是图片格式进入项目后交给前端工程师手动处理。GPT-6 Astra 只负责产生代码逻辑前端组件、状态管理、API 封装、ECharts 配置、WebSocket 客户端。它不直接决定视觉风格视觉风格由 GPT-Image-2.5 交付的设计稿定。这个分工的好处是我可以并行工作一边让图像模型生成下一批素材一边让编码模型写下一个功能模块。整个项目最忙的那几天我基本上是双线程推进的。4. 用 GPT-Image-2.5 生产 3D 视觉资产的实操过程3D 大屏的视觉资产说白了就是三样东西单体设备模型贴图、厂房场景底图、UI 界面元素。传统流程要做一个月的事情我用 GPT-Image-2.5 重新走了一遍大概花了 4 天。下面把过程和提示词策略完整讲讲。4.1 统一物料风格的三层策略AI 生图的一个老问题是“单张好看放一起打架”。我在第一个测试版本里生成了几十张设备贴图单独看每一张都很有质感但往场景里一摆整个厂房像一个风格混乱的拼贴画。有的设备偏写实、有的偏卡漫有的一张图里光影方向朝左另一张朝右拼起来非常别扭。后来我总结出一套三层策略来锁风格第一层锁统一的基础描述。所有设备贴图的提示词里都固定带上同一组风格词数字化科技风、深灰浅灰为主色、蓝色发光描边、等轴测视角、柔和环境光、干净背景。这组词就是整个场景的视觉锚点每次生图都原样复制进去不允许临时修改。第二层锁统一的光照参数。提示词里用“主光源方向左上、环境光均匀、无明显投影”这类描述保证不同设备贴图在合成进同一个三维场景时光影不打架。第三层锁统一的输出规格。所有单体设备图输出为正方形构图、透明背景、2048 分辨率。透明背景很重要这样我才能把生成的贴图直接拖到 Three.js 场景里作为精灵贴图或者模型贴图使用。4.2 提示词示例与后处理细节以“数控加工中心”单体设备为例我当时用的提示词大致是数字化科技风、深灰浅灰配色、蓝色发光描边、等轴测视角、数控加工中心的侧视全貌、简约科技线条、金属质感、柔和环境光、主光源方向左上、无明显投影、方形构图、设备居中、背景纯白、超清细节。生成结果会有一定的随机偏差比如个别图里 CNC 的防护门玻璃反光过大或者蓝色描边不均匀。我的处理方式是同一个提示词让 GPT-Image-2.5 生成 4 到 8 张候选图然后挑出最符合构图要求的一张作为底图再回到编辑器里做轻微裁剪和调色。这套流程虽然消耗了不少生成额度但比让建模师手工建模还是快得多。4.3 模型不能独立完成的部分必须说实话GPT-Image-2.5 并不能完全替代三维建模环节。厂房整体布局、设备之间的相对位置、产线走向这些需要精确空间关系的东西模型是生成不准的。我的做法是先下载了一个标准的工业厂房 SketchUp 模型利用它搭建基础结构再在 Three.js 里用 BoxGeometry、CylinderGeometry 这些基础几何体重新搭场景框架。GPT-Image-2.5 生成的贴图主要应用在两个层面一是一楼到三楼的厂房建筑外墙纹理二是设备单体图的透明底贴图用于场景中低精度设备模型的替代表示。只有点击某台设备做聚焦查看时才切换到一个稍高精度的模型并在旁边弹出数据面板。这种“低模 贴图”的方案在保证视觉观感的同时把材质数量和三角面数控制在了合理范围后续加载和渲染都很流畅。5. GPT-6 Astra 写前端从组件库到数据对接的真实效率视觉资产搞定了接下来是工程实现。整个前端是一个典型的中型 Web 应用Vue 3 单页应用状态管理用 Pinia3D 场景用 Three.js二维图表用 ECharts数据通道用 WebSocket。这些技术栈都是 GPT-6 Astra 训练数据里覆盖度极高的部分所以它的生成质量相当高。5.1 代码生成的实际工作方式我使用 GPT-6 Astra 的方式不是让它一句一句生成完整项目而是把它当成一个非常熟悉这个项目上下文的高级开发。我会分段给它喂信息比如把项目关键技术栈、目录结构、现有组件接口说明告诉它然后让它在已有代码基础上做增量输出。举一个具体的例子设备列表需要展示实时状态——绿色代表运行、黄色代表待机、红色代表报警、灰色代表离线。我给它一段需求描述包括状态字段名对应的含义它直接返回了完整的状态卡片组件代码。这个组件包含布局、状态对应的 CSS 类、点击后的详情弹出逻辑基本可以直接用。整段工作流程一般是这样我先把需求拆成小粒度任务再把每个任务描述给 GPT-6 Astra然后把它生成的代码粘贴进项目跑一遍看效果有出入再给它反馈让它修改。这种方式和传统开发的区别在于我不需要从头写每一行代码只需要关注逻辑是否正确、边缘情况是否被覆盖。5.2 三维场景与二维图表的数据联动大屏上用得最多的交互是点击左侧设备列表中的某一台3D 场景自动旋转视角对准那台设备同时右侧的 ECharts 图表切换成这台设备的历史数据曲线点击 3D 场景里的设备模型也能触发同样的联动。这个联动逻辑如果用传统方式写要自己维护相机的目标点、设备 ID 和图表系列的映射关系。在 GPT-6 Astra 的辅助下我描述清楚映射规则后它很快就给出了实现一个名为 focusOnDevice 的函数参数是设备 ID函数内部同时执行场景相机的移动和图表数据的更新。这里面比较有技术含量的部分是设备 ID 与场景中 Object3D 对象的关联我用的是 UserData 字段存设备 ID这套方式也是我跟它讨论后确定的方案——简单、可靠不会因场景加载顺序不同而出错。5.3 AI 编码模型的边界必须人工兜底的部分AI 编码确实能提速但这不意味着可以完全放手。这个项目里我至少遇到三处 AI 生成代码不靠谱的情况。第一处是 WebSocket 的断线重连。GPT-6 Astra 生成的客户端代码网络正常时跑得很顺但当我们模拟弱网环境时出现了一个问题连接断开后重连成功界面上的数据却不再更新了。原因是它生成的 onmessage 回调里没有重新处理历史消息积压新的状态没有触发视图更新。这属于典型的逻辑边界没有考虑全。第二处是权限控制。大屏上有部分区域的数据只有车间主任以上账号才能看比如产量对比、异常排名。AI 生成的代码把所有数据都渲染出来了只是在前端隐藏了 DOM 元素。按这样上线用户按一下 F12 就能看到全部数据这是不可接受的风险。最终这部分的权限校验全部改成了后端接口控制前端没权限连数据都不会下发。第三处是告警去重。AI 生成的告警列表把每一条 PLC 报警都原样展示同一台设备同一故障代码在短暂复位后再次报警时页面上会堆出几十条重复记录。我后来加了一层基于设备 ID 加报警代码加时间窗口的聚合逻辑这才满足用户实际使用习惯。6. 数据链路闭环从 PLC 到 3D 大屏的最后一公里视觉和页面都做完了剩下的问题就一个真实数据怎么稳定地流到大屏上。这条链路我拆成采集、汇聚、订阅、展示、回写五个环节。6.1 采集与汇聚多协议并存时代的工程现实设备侧的数据采集延续了厂里之前的架构新机床走 OPC-UA老机床走 Modbus TCPAGV 走 MQTT。这些数据先进入边缘网关网关里跑着采集程序以固定周期轮询或者订阅主题然后把数据统一转成 JSON 格式推给服务端。服务端的汇聚层我做得比较轻量没有引入重型数据平台只是用一个消息队列把网关上报的数据接入再通过一个简单的数据服务把最新的点位状态缓存到 Redis同时向前端提供 WebSocket 连接。这样做的原因很简单大屏场景需要的是“最新状态”而非全部历史真正需要看历史趋势的时候前端会单独调用 MES 或 SCADA 的查询接口。这种做法的一个直接收益是前端不再需要关心数据从哪个系统来它只需要订阅一个统一的数据通道拿到一个统一结构的数据对象。适配层在网关那边就已经做完了。6.2 前端订阅与实时渲染前端数据订阅是我的重点设计对象。我在项目里观察到一个现象如果每个组件都自己建一个 WebSocket 连接去订阅数据页面一打开就同时有十几个连接挂着网关压力大而且连接生命周期很难管理很容易出现内存泄漏。所以我把数据通道统一收敛成一个 ApiClient 模块前端全局只有一个 WebSocket 连接。后端推送数据时带一个 topic 字段前端收到后按 topic 分发到对应的状态仓库。比如 topic 为 device:status 的数据会更新 Pinia 里的设备状态模块topic 为 energy:summary 的数据会更新能耗模块。各个 UI 组件只需要订阅自己关注的状态片段不需要关心数据来源。在线更新方面设备状态类的数据我要求 2 秒刷新一次能耗类数据 5 秒告警实时推送。这个刷频率在 3D 大屏和图表之间没有造成明显的性能问题Three.js 场景里的设备颜色变化用的是材质颜色替换而不是重建网格所以开销可控。6.3 告警闭环从“看到”到“处置完”大屏的闭环最核心的是告警处置链路。我把它设计成设备报警后3D 场景里对应设备变红同时大屏右侧弹出报警卡片操作员在卡片上点击确认后报警状态变成“处理中”后台自动生成一条工单并推给对应班组长班组长在移动端处理完成后大屏上的报警状态变成“已处理”。这一圈走完才算真正闭环。这里有个小细节值得讲操作员点击“确认”这个动作不是只在前端改个样式而是向后端发送一条 HTTP 请求后端会同步更新工单系统和 SCADA 系统的报警确认状态。这样即使大屏重启、换人操作报警的状态也是可追溯的。这个设计是从一次需求评审会上学来的——业务方提出“你们大屏上显示处理完了但在我们 MES 里工单状态还是空的”我才意识到大屏不能自嗨所有状态变更都要回流到业务系统。7. 上线前后的踩坑记录这部分是我最想写的。项目做的时候踩了不少坑有些是 AI 工具特有的有些是传统开发也会遇到的。挑几个影响最大的都记在这里。7.1 AI 生成视觉资产的风格漂移GPT-Image-2.5 生成素材过程中遇到最棘手的问题是“同台设备的不同状态贴图风格不一致”。正常生产环境设备的运行、待机、报警三种状态应该用同一套模型的三种灯光效果来表达。但 AI 生成三张独立贴图时很容易出现轻微的角度差异、颜色偏移导致切换状态时画面会“跳一下”。我的解决方案是把“状态差异”由贴图改成程序化渲染设备正常运行和待机状态使用同一张贴图区别只在模型外圈加不加发光光晕只有报警这个状态额外调用 GPT-Image-2.5 生成一张红色高亮贴图切换过去。这样既保证了状态辨识度又避免了三张贴图之间的风格冲突。7.2 4K 大屏的字体与布局陷阱大屏物理分辨率是 3840 乘以 2160但很多开发者的设计稿是按 1920 宽度设计的。我第一版按 1920 设计、用 CSS 缩放去适配结果上真机后整个画面是糊的特别是文字边缘非常明显。后来我把整个页面的设计基准改成 1920但所有图标和字体资源使用 SVG 和字体文件确保缩放过程是矢量无损的关键文字用固定像素加媒体查询处理不让浏览器自动缩放导致模糊。还有一个小坑大屏通常挂在会议室的墙上观看距离在 3 到 5 米字号低于 24 像素根本看不清。第一版设计稿里有一堆 14、16 像素的注释文字上墙之后完全没用后来全部删掉或者调整为 28 像素以上。7.3 三维场景性能从 30 帧掉到 20 帧的排查过程性能问题是在接入真实数据后出现的。设备状态开始实时变化后每个设备模型为了表现“运行中”都加了一个缓慢旋转的零件动画再加上 AGV 的路径移动、发光描边的脉冲效果整个场景的帧率从 35 掉到了 20 左右大屏操作明显卡顿。我排查的步骤是这样的先用 Three.js 的 Stats 面板确认是 Draw Calls 还是渲染像素的问题发现 Draw Calls 高得离谱再逐个移除动画组件定位到“零件旋转”和“脉冲光描边”这两个组件占了大部分性能开销最后将所有设备的旋转零件动画从脚本动画改为渲染周期内的统一时间函数驱动由 GPU 统一处理而不是每个模型单独更新。改完之后帧率回到 30 帧附近操作流畅度可以接受。7.4 AI 生成代码引发的告警失效问题前面提到的 WebSocket 重连 bug后来升级成了一次线上事故凌晨两点网络抖动前端断线重连后后端已经推送过来的一批告警没有渲染出来但因为连接恢复界面显示正常。巡检人员第二天早晨才发现夜里有三台设备报警没人处理。这件事之后我对 AI 生成的网络层代码做了强制的人肉 code review重点检查断线重连期间的数据补偿逻辑。为了彻底解决这个问题我在 WebSocket 重连成功后加了一次全量状态同步客户端发一个 sync 请求后端把这个设备当前所有状态快照一次性推送过来客户端把本地状态更新到最新。这套兜底逻辑上线后再也没有出现过“断线丢告警”的情况。8. 复盘与下一步AI 参与大屏项目后工作方式变了项目交付一个月后回访业务方反馈说这块 3D 大屏已经成了每天晨会的默认打开页面。虽然没有做过精确的使用统计但从反馈来看至少“设备状态总览”和“告警处置”这两个模块被频繁使用。能耗对比和产量排名看的人确实不多——这跟我们调研阶段捕捉到的需求优先级是吻合的。这个项目让我最受触动的不是 AI 让代码写得快了而是它改变了项目里的人肉分工方式。以前一个 3D 大屏项目需要“产品经理调研、UI 设计师出图、建模师建模、前端开发写代码”四五个人协作现在更像一个“懂行的全栈工程师配了两个高级助理”助理负责把描述变成视觉素材把需求变成代码但审美、架构、数据模型、项目节奏仍然由人来把控。如果现在有人问我用 GPT-Image-2.5 和 GPT-6 Astra 做项目最大的心得是什么我会说AI 工具的上限取决于你对业务现场的理解深度。我之所以能把提示词写得精准、能让 AI 生成的代码一次通过率那么高是因为我在厂房里泡了两周。模型看过再多工业样例它也不知道这家工厂的 CNC-07 在三车间东边靠柱子的位置更不知道它的主轴温度报警阈值是 75 摄氏度而不是 80。这些信息只能来自现场。下一步我想把这个项目的成果复用到集团其他两个厂区已经把建模标准、提示词策略和前端工程目录整理成了内部模板。到时候换一套设备清单和数据源应该能更快地跑完一遍完整链路。