干智慧厂房大屏这行的朋友应该都有体会需求方一开始说的“搞个3D大屏”背后往往藏着一条从现场设备到数据中台、再到可视化渲染的超长链路。我这次接到的项目也是一样最开始只有一句“把厂房做成3D的数据要实时”但真正落地时调研、建模、编码、联调每一步都像踩在棉花上。后来我把 GPT-Image-2.5 和 GPT-6 Astra 组合起来用一个管视觉资产生成一个管代码实现和方案梳理才真正把“从调研到闭环”这条链路走完。这篇就把我的完整做法、提示词思路、踩过的坑和最终效果复盘都写出来给准备用 AI 做政企大屏项目的朋友当个参考。1. 项目概述这条“链路”到底长在哪先说结论智慧厂房 3D 大屏不是一个纯前端项目它是一条数据链路加一条视觉链路的交汇。数据链路从 PLC、传感器、MES 系统出来经过采集、清洗、存储最后通过接口推送到大屏前端视觉链路则是把厂房的三维结构、设备模型、动效状态组织成可交互的 3D 场景。两条链路任何一条断了大屏就是“好看不能用”或者“能用不好看”。1.1 我到底做了什么这个项目的核心目标是把一个占地 2 万平方米的机加工车间做成 3D 可视化大屏需要展示产线运行状态、设备开机率、能耗数据、报警信息并且支持鼠标交互查看单台设备的实时参数。整个项目周期原计划是 8 周最后实际用了 6 周半其中 AI 工具帮我省掉的大头在两个方面一个是 GPT-Image-2.5 生成的厂房场景概念图和 UI 资产省去了大量找参考图、抠素材的时间另一个是 GPT-6 Astra 在需求分析、代码生成、问题排查上提供的连续辅助相当于多了一个随时在线的资深同事。1.2 为什么选这个场景做闭环验证我选智慧厂房 3D 大屏作为 AI 辅助开发的完整链路验证有三个原因。第一它足够复杂涉及 3D 渲染、数据可视化、后端接口、实时通信单一模型很难全包正好能测试多工具协同。第二它有明确的价值闭环——大屏不是摆着看的而是要真正帮助车间管理人员发现产线异常、分析产能瓶颈这意味着最后必须做效果验证而不是“做完就交付”。第三这个场景的成果可量化设备开机率有没有提升、报警响应时间有没有缩短都是硬指标适合用来判断 AI 辅助开发的最终产出到底靠不靠谱。2. 调研阶段用 GPT-6 Astra 把模糊需求拆成可执行清单很多人拿到这类项目会直接开干我吃过这个亏。上一回做园区大屏做到一半客户才说“我要的不是看园区多漂亮是要看到每个门禁的通行记录”结果整个数据模型重做。所以这次我把调研当成独立阶段来做而且不是自己去硬啃访谈记录而是让 GPT-6 Astra 参与需求拆解。2.1 现场调研与数据摸底先去现场转了一圈记录了车间里三台关键设备的型号和通信协议、DCS/SCADA 系统的数据接口方式、以及网络拓扑。这里有个容易被忽略的点智慧厂房大屏的数据大多来自 OT 网络而大屏展示区通常位于 IT 网络两边打通需要经过工业网闸或者防火墙策略。我这次在调研阶段就把网络链路的打通方式确认了用的是单向数据推送方案避免反向控制带来的安全隐患。调研后我整理了一份原始访谈记录里面包含车间主任的原话、设备清单、已有报表截图。这些材料很零散直接看效率很低我的做法是把文字材料全部丢给 GPT-6 Astra让它按“角色、痛点、数据需求、展示需求”四个维度输出结构化需求表。它给出的结果已经比较接近最终需求文档的雏形我再结合现场情况修正把“想看到产能情况”这种模糊表述改成了“需要按小时统计每台设备的有效运行时长与待机时长”。2.2 用 AI 做需求分析时的三个技巧第一不要把原始材料囫囵丢进去要先做脱敏和分段。设备 IP、人员姓名去掉访谈记录按话题切块一次只让模型分析一块输出的精度会高很多。第二要让模型同时输出“需求项”和“对应的数据来源”这样能提前发现数据拿不到的需求。比如客户想要“订单进度”但现有 MES 里根本没有订单维度的数据这就是需求与数据的冲突需要尽早和客户确认口径。第三要求模型给出“如果数据缺失可以用什么替代指标”这个提示词很管用它会让模型站在落地角度思考而不是只做文字搬运。提示需求调研阶段最忌讳“客户说什么就是什么”。用 AI 整理需求时要专门加一句“请指出需求中依赖的数据是否常见于制造业系统并给出无法获取时的替代方案”。这句提示词帮我在开工前排掉了至少三个后期返工的风险点。调研阶段的产出是一份《需求与数据映射表》这张表贯穿了后续所有开发。字段包括业务需求、展示形式、数据源系统、接口方式、刷新频率、负责方。后面开发、测试、验收都拿这张表核对客户提新需求也先回到表里看数据能不能支持。这是我这次能快速闭环的底层原因——不是 AI 有多神而是 AI 帮我把地基打得比之前扎实。3. 设计阶段GPT-Image-2.5 生成 3D 视觉资产的全流程三弟大屏的视觉效果直接决定客户的第一印象。以前的做法是去模型网站淘模型或者请设计外包出图既要等又贵。这次我用 GPT-Image-2.5 生成概念设计和部分贴图素材把视觉方案的确认周期从两周压缩到了三天。3.1 提示词工程让图像模型输出可用的厂房场景GPT-Image-2.5 这个模型的优势在于对工业场景的理解比之前的版本明显更好能输出带透视关系、灯光氛围和材质细节的室内场景图。但直接用“帮我画一个智慧厂房”这种提示词得到的只是概念海报没法直接用于开发。我试下来比较有效的提示词结构是场景类型 视角 关键设备 风格关键词 输出用途。举个例子我给大屏的背景场景用的提示词是“现代机械加工车间内部高视角俯视可见数控机床排列整齐、AGV 小车在通道运行、顶部有蓝色氛围灯带工业风格写实渲染适合作为 Web 端 3D 可视化大屏的背景层。”这样生成出来的图干净、有纵深感而且视觉重心在车间中部方便后续叠加数据面板和标注信息。生成之后不是直接用而是拿去做环境贴图和氛围参考。我在 3D 引擎里搭场景时把 GPT-Image-2.5 生成的车间图作为背景底图前景用 Three.js 的几何体搭建厂房框架和主要设备这样既保证了视觉丰富度又控制了模型面数和开发成本。3.2 从概念图到可落地的 UI 资产除了场景视觉大屏的 UI 风格也很关键。客户要求“科技感、数据感”但不能花哨到影响信息读取。我用 GPT-Image-2.5 生成了一批设计语言探索图包括数据面板的配色方案、标题栏质感、按钮和标签样式。做法是给模型一张我手绘的线框布局图再配合文字描述让它输出多种视觉风格然后从里面挑选两套给客户确认。这个过程中我发现了图像模型的一个明显特点它对“细节一致性”支持得还不够。比如要求输出四个相同风格的图表卡片它可能画出四种边框粗细不一样的卡片。所以我的处理方式是把生成的图当“风格提案”确认后还是在设计稿里重新绘制标准化的 UI 组件只把 AI 生成图里的色彩搭配、光效质感作为规范依据。图像模型的价值是帮我快速找到“客户想要的感觉”而不是直接替代 UI 设计。3.3 视觉资产管理的注意事项设计阶段容易出现一个混乱AI 生成的图散落在各个对话里最后找不到哪个是最终版本。我这次用一个固定目录来管理素材按“场景/设备/UI/动效参考”分文件夹文件名带日期和版本号。GPT-Image-2.5 的对话历史里保留 prompt 原文每生成一版就截图存档这样客户提出“上一版感觉更好”时能立刻找回当时用的提示词重新生成。另外要提醒一点生成工业场景时设备数量不要贪多。AI 画太多设备会产生不符合实际的排列方式比如通道被堵死、设备尺寸比例失调。我验证过提示词里明确“显示 6-8 台机床保持通道畅通”比让它自由发挥的效果好得多。自主可控的几何体建模加 AI 生成的纹理贴图是目前性价比最高的组合。4. 开发阶段GPT-6 Astra 辅助编码与数据链路打通到了开发阶段GPT-6 Astra 才真正发挥核心作用。这个模型支持比较长的多轮上下文我可以把整个项目背景、技术栈、接口文档甚至报错堆栈都放在同一段对话里让它输出贴合当前项目的代码而不是泛泛的示例。这一点在链路打通阶段尤其重要因为大屏项目的问题往往不是一个文件里能解决的而是跨前后端的数据流转问题。4.1 技术选型与技术栈确认在调研阶段我就用 GPT-6 Astra 对比过技术方案最终定了前端用 Vue 3 Three.js3D 场景用 glTF 模型加载数据层用 WebSocket 推送实时指标历史数据用 ECharts 展示。后端沿用客户现有的 Java Spring Boot 服务新增一个数据聚合接口从 MES 数据库读取设备状态并推送到前端。这个选型看起来常规但关键是 GPT-6 Astra 帮我提前辨认了几个大屏项目的坑它提示我 Three.js 在高分屏下的像素比设置需要手动限制否则大屏 60 帧容易掉到 30 帧WebSocket 断线重连需要带心跳机制否则设备数据会静默中断。这些点在后来的联调中全部应验如果没提前处理上线后光排查这两类问题就要花掉好几天。4.2 用 Astra 生成 3D 场景代码3D 场景的搭建我一开始担心 AI 生成代码的可用性实际试下来发现只要给足上下文效果比预期好。我给 Astra 的上下文包含项目需求摘要、Three.js 版本、模型文件路径、相机初始位置、以及大屏分辨率为 3440×1440。它生成的场景初始化代码基本可以直接跑包括模型加载、灯光设置、地面网格和轨道控制器。比较关键的是设备交互模块。要求是点击厂房里的任意一台设备周围弹出数据浮窗显示实时温度、转速、运行状态。这段代码我只描述了一件事“点击设备模型时从设备列表中找到对应 ID 并调用后端接口获取实时数据再在设备位置生成 HTML 浮窗”。Astra 输出的代码用了 Raycaster 做射线检测这是 Three.js 的标准做法而且它处理了模型分组嵌套导致 raycast 失效的常见坑——从 intersects 数组里向上查找父节点来匹配设备 ID。这个细节如果没有经验很容易忽略模型是从 glTF 导入的所有设备都是子节点直接判断当前 mesh 的 ID 永远匹配不上。4.3 数据链路打通设备数据实时上屏数据链路是整个项目里最容易出问题的地方也是我花最多时间调优的部分。整体设计是PLC 数据进 SCADASCADA 每 5 秒生成一条设备状态记录写入时序数据库后端通过定时任务读取最近一条记录缓存到内存再通过 WebSocket 推送给前端。大屏端收到数据后根据设备 ID 更新 3D 模型上的状态颜色和 UI 面板上的数字。在联调的时候我发现一个典型问题客户端直接订阅了所有设备的数据设备一多前端每秒要处理的 JSON 长到数百条浏览器主线程崩了。Astra 给我出的优化方案是“按需订阅”——点击设备才订阅该设备的详细数据未选中时只接收设备状态变更的轻量消息。这个方案把实时消息量降了 85%页面响应明显变快。数据映射是通过一个 JSON 配置表完成的每个设备 ID 对应模型节点名称、显示名称、状态颜色、数据单位。这个配置表由后端接口下发前端加载好处是新增设备时不用改代码只改数据库配置就能上屏。5. 联调、上线与闭环迭代开发和联调其实是交错进行的。我把 3D 场景、数据接口、大屏页面三个模块并行开发每周做一次集成演示。这期间 GPT-6 Astra 最大的价值不是写多少代码而是在我报错时能结合项目上下文给出排查方向省去了大量搜资料的时间。5.1 大屏性能优化从卡顿到稳定 40 帧第一轮集成后大屏在 3440×1440 分辨率下只能跑到 20 帧左右肉眼可见的卡顿。我们定位到三个性能瓶颈场景里设备模型总面数超过 300 万、实时数据更新时频繁重建 DOM 节点、以及透明材质数量过多导致法线计算量大。处理方法是对设备模型动刀把高模替换成简化版保留轮廓和关键特征这部分模型优化花了团队两天DOM 更新改成虚拟滚动和数据绑定只更新数值变化的部分透明材质数量从十几个减少到三个。优化后帧率稳定在 40 帧以上对大屏展示场景完全够用。我个人的经验是3D 大屏的帧率目标定在 30-45 帧就好不用盲目追求 60 帧。因为大屏不是游戏它的核心任务是把数据讲清楚帧率过高反而占用 GPU影响后续叠加的数据动效。5.2 从“能看”到“能用”功能闭环的关键第一次演示时客户看完说了一句话“挺好看的但我能拿它干嘛”这句话点醒了我——大屏如果只是把数据搬上去那它就是个昂贵的显示器。真正的闭环是让大屏成为一个可操作的决策工具。现场车间主任反馈最想要的功能是设备报警时大屏能直接定位到设备并显示报警原因和处置建议。于是我们开发了报警联动功能前端收到报警消息后相机自动飞行到报警设备位置调高设备高亮颜色同时弹出故障代码和最近一次维护记录。这个功能开发本身不复杂但涉及跨模块协作。我用 GPT-6 Astra 帮忙梳理了报警消息的字段结构、前端相机动效的触发逻辑、以及后端需要提供的接口。它给出的实现方案里有一个设计很关键报警消息必须带设备坐标而不是前端再去查一次设备位置表。这避免了报警消息量大的时候前端频繁查询位置信息导致延迟。5.3 复盘AI 辅助开发的价值边界项目上线后我做了个粗略统计GPT-6 Astra 帮我处理的事情包括需求梳理、技术方案选型、核心代码生成、报错排查、性能优化建议、以及文档整理。真正由它直接写出并实际使用的代码约占整体业务代码的三成剩下七成还是团队写或者基于它给的方案改写。但它的间接价值更大——把每个人从搜索引擎和文档堆里解放出来决策速度明显快了。AI 的边界也很清楚它不理解客户那些没有说出口的隐性需求也不了解现场设备安装的位置是否适合展示。比如客户要求的“办公室视角”到底是办公室哪个窗户能看到车间这种问题只有人到现场才能判断。工具负责提速行业经验和现场感知负责兜底这是我认为比较健康的协作关系。6. 常见问题与排查技巧实录做这种长链路项目问题永远比预期多。我这里把这次遇到的典型问题整理成一份速查表给做同类项目的朋友一个参考。虽然这些现象不一定和你的环境完全一样但排查思路是通用的。问题现象可能原因排查顺序本次的解决方法大屏数据偶尔无刷新WebSocket 静默断开先看心跳日志再看防火墙会话超时配置前端增加心跳重连后端缩短空闲会话超时时间点击设备无反应模型分组嵌套导致 raycast 命中子节点先打日志确认 intersects 是否为空向上遍历父节点匹配设备 ID3D 场景加载后白屏模型贴图路径或格式问题检查控制台资源加载错误统一使用相对路径贴图转成 WebP数据更新时页面卡顿DOM 频繁重建用 Performance 面板查看长任务改为按需更新已绑定数据节点某些设备状态一直离线设备未注册或数据映射缺失核对设备配置表和后端日志增加启动时的数据校验日志缺失即报警6.1 AI 生成代码不可用的应对用 AI 写代码最常见的抱怨是“生成的代码跑不起来”。我的应对经验有三条。第一条不要给 AI 太大任务一个函数、一个组件地生成比让它一次写整个系统可靠得多。第二条把项目的关键依赖版本、运行环境告诉它上下文越具体错误越少。第三条接受“改代码”是常态AI 生成的代码在架构层面可以参考但细节还要靠人打磨。这次所有 AI 生成的代码我都要求团队成员过一遍 code review效率反而比从零写要高。6.2 提示词和上下文管理的经验GPT-6 Astra 支持长上下文但用久了会发现一个问题对话越长模型越容易“忘记”最开始设定的背景。我的做法是定期发送一个摘要消息把当前已确认的技术决策、已完成模块、当前待解决问题重新陈述一遍相当于给模型做一个记忆刷新。这个技巧非常管用尤其是在跨天继续同一个项目对话时。6.3 最后再分享一个小技巧这个大屏项目上线后客户提出希望手机端也能看关键指标。我们没有专门开发 App而是让 GPT-6 Astra 基于现有的大屏接口生成了一个简化版移动端页面重点展示报警信息和开机率。整个页面做成后大约只花了一天时间接口和数据模型完全复用大屏的只是展示层重新做了适配。这件事给我的启发是链路一旦打通延展新场景的成本会大幅降低。AI 工具的意义不在于替代谁而在于让一个团队有精力去做更多以前做不过来的事。