企业官网建设流程全解析

最近我刚把一个智慧厂房 3D 大屏项目从头到尾走完，从最开始的现场调研、需求梳理，到中间拿 GPT-Image-2.5 生成场景视觉稿和模型贴图，再靠 GPT-6 Astra 做需求拆解、数据口径问答和告警归因分析，最后到链路联调、验收复盘。这条链路看着不长，真走起来坑不少，但走完之后再回头看，我觉得这套“AI 辅助做工业可视化”的打法，已经完全可以复制到下一个项目里。

我以前做过不少 3D 大屏，这类项目最大的问题从来不是“3D 效果做不出来”，而是死在开头和结尾：开头需求说不清，反复改；结尾数据对不上，业务不认账。这次我用 GPT-Image-2.5 和 GPT-6 Astra 把两头堵住了，项目反而顺了。这篇文章不吹 AI 多神，主要把我这一路的思路、踩过的坑、写过的提示词、定过的技术方案都摊开来讲，想给准备做智慧厂房数字孪生、工业可视化大屏的朋友一个能直接参考的样本，尤其是想用 AI 工具提效但不知道插在哪一段的人。

1. 为什么这条链路值得完整走一遍

1.1 3D大屏项目的老问题：死在不闭环

先说说我见过最多的失败样板。很多团队上一套 3D 大屏，流程是这样的：销售拿几张酷炫的效果图去投标，中了之后 UI 照着效果图出视觉稿，前端用 Three.js 或者 UE 把厂房模型搭出来，再把数据库里能查到的几个指标挂上去，动画调得流光溢彩，领导来参观的时候一键切换到“演示模式”。结果一用起来就会发现：点位数据对不上、告警不及时、模型和真实产线布局有偏差、点了设备弹不出详情。最后这块屏就成了“领导来了开一下”的摆设，甚至过不了验收。

问题出在哪？出在整条链路是断的。需求调研段做的事情是“把 PPT 做漂亮”，开发段做的事情是“把模型做逼真”，实施段做的事情是“把接口连通”，但没有人把“业务到底关心什么、数据从哪里来、怎么证明屏上是对的”串起来。所以我在这次项目里给自己定的目标不是“做一块好看的屏”，而是“从调研到验收，把每个环节都闭环，让业务人员敢拿这块屏当日常管理工具用”。

1.2 这次用到的两个核心工具，分别解决哪一段

先交代工具分工。GPT-Image-2.5 是图像生成模型，我主要拿它来做三件事：生成厂房场景的效果参考图、生成 3D 模型贴图、生成大屏 UI 里的辅助视觉素材。它解决的是“视觉资产从哪来”的问题。厂房没有现成的三维模型、没有好看的质感贴图、UI 需要背景粒子效果，这些以前都得靠建模师和 UI 设计师慢慢磨，现在可以用它大幅压缩产出时间。

GPT-6 Astra 我把它当成一个能理解上下文、会调用工具、会做多步推理的智能体模型来用。它解决的是“信息链路”的问题：访谈纪要整理、需求结构化、指标口径对齐、数据查询条件生成、告警根因分析，这些以前都靠项目里的业务分析师和资深开发人工完成，现在有一半可以交给它先做初稿，我再校验。我给它写的提示词不是简单的一句话问答，而是带任务边界、带输出格式、带校验规则的结构化提示词，后面我会放几个模板。

1.3 适合谁看，看完能带走什么

如果你是在做工业互联网、智慧园区、智能制造相关项目的产品经理、前端开发、项目实施或者售前方案，这篇文章值得读完。代码级的东西我不会全量贴在这里，但我会把整个链路拆成六个阶段，给出每个阶段的具体做法、关键参数、提示词写法和验收标准。就算你团队里没有专职建模师、没有 AI 专家，照着这条链路走，至少能把 3D 大屏从“演示玩具”做成“业务工具”。

2. 调研不是开会，是把混乱变成清单

2.1 用GPT-6 Astra把访谈纪要变成需求池

智慧厂房大屏的需求方通常不止一个人。分管生产的要看到产线节拍和停机原因，分管设备的要看到关键设备健康度和点检计划，分管安全的要看到人员定位和风险区域报警，分管能源的要看水电气消耗趋势。四个人坐在一个会议室里，嘴上都说“做个大屏”，实际上想看的完全不一样。

我以前的做法是会后自己熬夜整理纪要，提炼出几十条零散需求，再逐条找业务确认。这次我把整理的工作丢给了 GPT-6 Astra。调研结束后，我会把每一段访谈录音转成文字，再给模型一段提示词，让它按固定结构输出：角色、关注点、核心指标、数据来源、使用频率、痛点。比如我会写：

“下面是一段访谈文字稿。请提取该业务角色对3D大屏的明确需求和隐含需求，按表格输出：角色、关注的核心指标、希望看到的数据维度、当前数据来源、使用大屏的场景频率。不要补充文稿中没有的信息，不确定的标注为待确认。”

这样跑完三轮访谈，我就拿到了一份按角色分好类的需求池。真正省时间的点在于，以前我整理纪要前心里已经有一套模板，但总怕漏掉业务随口说的关键信息，现在让模型先做一轮结构化，我再把“待确认”项逐个去问，效率至少翻倍。这个阶段我也踩过坑：模型偶尔会把业务人员的口头表达脑补成精确指标，比如对方说“看看温度正不正常”，它会写成“温度超过35℃报警”，这是典型的过度推断。所以所有 AI 产出的指标阈值，没有业务方确认之前一律不算数。

2.2 指标口径和点位清单：不确认就会返工

调研阶段有个很容易被轻视的活，叫“指标口径对齐”。同一个“设备开机率”，生产部门算的是“设备运行时间/计划生产时间”，设备部门算的是“设备运行时间/日历时间”，口径不一样，屏上的数字就不一样。这块大屏一旦出现两个部门指着同一个指标争论谁的算法对，项目信任度就归零了。

所以我在需求池基础上，又单独建了一张指标口径表，字段包括：指标名称、业务定义、计算公式、数据来源、统计周期、负责人。这张表我同样让 GPT-6 Astra 帮我生成初稿，但每条都拉上业务部门确认。这一步做完，后面做数据接入时基本不会返工。

点位清单也是同期要拉的。智慧厂房大屏要展示的数据来自 PLC、传感器、ERP、MES，每个系统的点位命名规则都不一样，有的叫“T-204_TEMP”，有的叫“1#线_炉温”。不提前把点位编号、点位中文名、单位、数据类型、报警阈值、采集频率整理清楚，到开发阶段就会被数据接入折磨到崩溃。这段没有太多技术含量，但绝对值得花两天时间做完，而且要给每个点位找一个“业务负责人”，后面数据对不上的时候知道找谁。

2.3 现场勘察能省则省？不能省

这一步我在很多项目里看到有人偷懒，觉得有 CAD 图纸、有无人机倾斜摄影就够了，不去现场。我的经验是：现场必须去，而且最好是在出视觉稿之前去。厂房里有哪些柱子、横梁、消防管道、AGV 通道、安全门、设备围栏，这些在图纸上都有，但真实的空间尺度和视线遮挡，只有站在现场才有体感。

我这次去现场拍了三百多张照片，重点拍了设备布局、墙面颜色、装饰风格、Logo 区域。这些照片有两个用处：第一，回来之后我直接把照片打包喂给 GPT-6 Astra，让它从中提取“这个厂房视觉上有哪些标志性元素，放在3D场景里更容易让人一眼认出来”；第二，我把它们作为 GPT-Image-2.5 生成视觉稿的参考图，保证 AI 产出的厂房效果不是标准化的“科幻仓库”，而是接近真实环境的定制化场景。只要前期把这件事做了，后面建模和空间布局就有据可依。

3. 方案与视觉：先让所有人看到同一个东西

3.1 GPT-Image-2.5出图，不是画着玩

视觉稿在传统项目里是 UI 设计师和建模师的主场，但我觉得这里恰恰是这次提效最大的地方。以前出效果图，最快也要一周，而且改一版累半死。这次我用 GPT-Image-2.5 做“视觉锚点”，意思是我不靠它直接产出最终模型，而是靠它快速生成多版场景效果图，用来和业务方对齐空间布局、大屏风格、镜头视角、配色方向。

提示词我是这么写的：“生成一张智慧厂房内部3D场景效果图，视角为俯瞰斜45度，风格偏工业科幻但不夸张，保留真实厂房中常见的黄黑警示条纹、钢结构立柱、AGV通道标识，设备表面为灰白色金属质感，地面为环氧地坪漆浅灰色，主色调为深蓝+青色，光线通透，不要出现人物。以这张图作为空间布局的参考底图。”

这一步的价值在于，业务方看到效果图之后会立刻说“我们厂房没有那么多设备”“这个视角看不到东侧的立库”之类的话，调整成本极低。如果没有这版图，等模型做出来再改，那就不是改图，是推翻重来。我用 GPT-Image-2.5 一个上午出了六个视角共十二张效果图，然后和业务方一起筛出两个方向，这个环节放在以前至少需要两周。

3.2 架构选型：数据从哪来，接到哪去

视觉之外，方案设计的另一半是数据链路。智慧厂房 3D 大屏的架构层级，我自己一般会分成四段：感知层（PLC、传感器、摄像头、AGV调度系统）、接入层（OPC UA / Modbus TCP / MQTT 网关）、处理层（Kafka、数据清洗、时序数据库）、展示层（后端 API + WebSocket 推给前端大屏）。

这次项目的关键设备是空压机、循环水泵、配电柜、AGV 小车和一条总装线。空压机和水泵通过 OPC UA 从 PLC 采集运行状态和温压数据，AGV 调度系统走 MQTT 上报位置和任务状态，MES 系统提供生产工单和产量数据。前端 3D 场景里每个可交互的模型节点，都会绑定一个 realAssetId，后端根据这个 ID 把实时数据推过来。这个绑定关系我会提前整理成一张映射表，字段是：模型节点ID、模型名称、所在区域、绑定点位ID、告警规则ID。这张表是整个大屏的“神经连接图”，后面所有功能都绕着它转。

技术选型上，这次我前端用的是 Three.js 做 WebGL 渲染，模型格式统一转成 glTF，压缩使用 Draco。没用 UE 是因为项目交付后需要浏览器直接打开，用户不想装客户端。大屏 UI 叠加层用 ECharts 做图表，数据交互走 WebSocket，保证设备状态变化能在 1 秒内反映到模型颜色上。这套选型不是最炫的，但它是工业项目里最稳的。

3.3 提示词技巧：如何让AI生图贴近厂房现场

用 GPT-Image-2.5 的时候，我发现最影响效果的不是模型能力，而是你喂给它的参考信息够不够。如果你只说“画一个智慧厂房”，它会给你一个好莱坞科幻片布景，好看但完全不像真实厂房。要让画面贴合现场，得在提示词里塞三个维度的信息。

第一是空间信息：厂房格局、设备大致数量、有没有立库、有没有行车、楼层的层高。第二是材质信息：地面是什么材质、墙面是什么颜色、设备做没做保温层、管道刷的什么漆。第三是标志物信息：厂牌、警示标语、逃生通道、特定品牌设备的大致轮廓。把现场拍的照片作为参考图一起传进去，会比纯文字描述准确很多。

我的习惯是先把现场照片和一段背景说明交给 GPT-6 Astra，让它帮我生成结构化的视觉描述词，再拿这段描述词去问 GPT-Image-2.5。相当于一个模型负责把现场信息整理成提示词，另一个模型负责把提示词画成图。这个配合用完就回不去了，我一个人就能完成以前一个视觉小组的初稿工作量。当然，AI 出的图不能直接当施工图，建模师还是要根据真实 CAD 尺寸来建模型，但 AI 图已经帮建模师省掉了“从文字想象空间”的那一关。

4. 数据接入和场景建模：真正费时间的段落

4.1 点位表是3D大屏的命根子

我一直跟团队讲，3D 大屏的皮是模型，骨是数据。数据接不进来，模型再漂亮也只是个壳。这次项目我在数据接入阶段花的时间最多，因为厂房里的设备品牌杂、年代不一，有的 PLC 支持 OPC UA，有的只能走 Modbus TCP，还有几个老设备根本没有数采接口，只能靠人工点检上报。

点位表的作用这时候就体现出来了。我把最终版点位表导进数据库，让后端按点位 ID 统一暴露数据接口，前端不管底层协议是什么，只认 JSON 里的点位编码。这样做的好处是，底层某个 PLC 换了、某个传感器坏了，只要替换点位映射，前端模型不用改代码。我在这道环节上还让 GPT-6 Astra 做了一次“非法点位识别”，把点位表里单位缺失、数据类型不匹配、报警上下限填反的记录全筛出来，省了 DBA 不少事。

这里有个特别值得说的经验：点位数据的“时间戳”一定要带时区，而且前后端要用同一个标准。工业现场经常有设备 PLC 时间是本地时间、服务器是 UTC 时间的情况，曾经出现过一条趋势曲线整体偏了 8 个小时，排查了大半天才发现是时区问题。AI 再聪明，它只能根据代码上下文猜问题，这种隐含的时间口径不一致，最后还得靠人看数据才发现。所以做数据接入时，所有点位我一律要求“时间戳统一到毫秒，统一用服务器时区”，谁都不许自己转。

4.2 用GPT-6 Astra做数据口径问答和清洗

数据清洗这个活以前是最枯燥的。点位表几百行，要查空值、查越界值、查跳变值、查重复值。我这次让 GPT-6 Astra 直接读样本数据，给定几条规则让它输出异常数据清单。提示词可以这样写：

“你是一名工业数据分析工程师。以下是一份空压机运行数据的 CSV 样本（字段：点位ID、采集时间、排气压力、排气温度、运行状态）。请检查数据质量，输出：1. 空值记录清单；2. 明显越界的数值记录（压力单位 MPa，正常范围 0.4-0.9；温度单位 ℃，正常范围 0-120）；3. 时间戳乱序的记录；4. 建议的处理方式。不要编造样本里不存在的记录。”

这一步跑完之后，我拿到一张异常清单，再回去让数据源侧确认是传感器故障还是数据录入问题。系统里有历史数据集，点位又有语义化的中文名，GPT-6 Astra 还能做一件事——自然语言问数。业务方问“昨天上午空压机的排气温度最高多少”，模型能自动找到对应点位、生成查询条件、返回结果。这在以前得靠开发临时写 SQL，现在大屏里直接做一个 AI 助手输入框就能实现。商业项目里这种功能非常给验收加分，因为它让大屏从“看得见”变成了“问得着”。

4.3 模型资产处理：CAD、倾斜摄影与AI生成贴图的配合

再聊模型。智慧厂房的 3D 场景一般有两个来源：一是土木或工艺专业给的 CAD 图纸，用于搭建建筑结构和产线布局；二是无人机倾斜摄影得到的实景模型，用于还原场地全貌。但这两个源都不适合直接上大屏：CAD 没有材质光照，倾斜摄影面数爆炸，浏览器直接加载不死机也卡成 PPT。

我的处理路径是：CAD 图纸导入建模软件重新拓扑出结构体，厂房墙面、地面、设备基座按照真实尺寸建模；倾斜摄影模型只用来做空间位置参考，不直接渲染。设备模型能简则简，一个空压机模型我控制在 600 到 1500 个三角面。贴图这块是 GPT-Image-2.5 发挥作用的地方：锈蚀的管道纹理、环氧地坪裂缝、设备铭牌、墙体斑驳，这些以前得去图库找或者自己用 PS 画，现在直接生成 512 或 1024 分辨率的无缝贴图，拖进 PBR 材质通道就能用。

画质和性能永远是矛盾的，体验上我定了一条线：首屏加载控制在 5 秒以内，正常操作帧率不低于 30fps。为了达到这条线，我把整个厂房拆成 LOD 三层，远处模型用低面数版本，镜头靠近时再切换到高精度模型。纹理贴图不超过 1024，能复用材质的地方绝不开新材质球。这套优化做完，一块原本建模师说“跑不动”的厂房场景，在普通工作站浏览器里跑得挺稳。

5. 大屏端开发：把“能看”做成“能用”

5.1 技术选型：我为什么选了Three.js这条路

大屏渲染技术，市面常用的有几条路：WebGL 原生、Three.js/Babylon.js、Unity/UE 导出 WebGL、云渲染推流。我的选择是 Three.js，理由有三个。第一，团队里前端能直接上手，维护成本低；第二，Three.js 对 glTF 支持好，工业模型管线成熟；第三，社区案例多，遇到渲染问题基本都能搜到解法。

Babylon.js 其实也强，物理效果和内置调试工具更完善，但 Three.js 生态在我接触到的工业项目里更常见。Unity/UE 做出来的视觉效果确实天花板更高，但导出到 Web 后体量大、内存占用高，而且客户端安全要求严的时候，很难通过审查。云渲染推流效果最好，适合超大场景，但要额外部署渲染服务器，成本高不少，普通智慧厂房项目没必要上。

大屏端除了渲染，还要考虑图表和数据状态展示。我这次把所有图表类内容都放在 DOM 层，用 ECharts 渲染，没有把图表做进 3D 场景里。原因是 3D 场景里放大量文字和二维图表，既影响性能又影响可读性。3D 层负责“空间关系”，2D 层负责“数值信息”，两者通过交互联动，点击模型弹右侧面板，面板里是图表和表格。这个分层逻辑对后期维护特别友好，设计师要改样式时不会碰到渲染代码。

5.2 信息层级设计：大屏不是放动画片

很多 3D 大屏做出来像放动画片，镜头一直在转，粒子一直在飘，飞线一直在闪，看起来很热闹，但业务人员根本抓不住重点。我这次在信息层级上做了很克制的设计，归纳成三个层级。

第一层是全局态势：默认镜头俯瞰全场，设备正常显示绿色，告警设备显示红色并带呼吸灯效果，AGV 用轨迹线表示运行路径，顶部 KPI 区域展示产量、能耗、OEE、异常数量。这些信息让参观者和管理者在 10 秒内知道工厂整体状况。第二层是区域详情：点击某个车间或产线，镜头平滑推近，展示这条产线的节拍、在制品、设备状态、当前报警列表。第三层是设备单体：再点击单台设备，弹出右侧面板，显示设备档案、实时参数、历史趋势、点检记录。

交互逻辑上我要求“点哪看哪，看哪不重”，每个层级的返回路径都清晰。把这些做成规则之后，前端写起来也不容易乱。AI 在这里的参与是：我把三层的设计规则录入给 GPT-6 Astra，让它根据业务需求池自动补充每层应该展示的指标清单，比如在设备单体层它建议把“上次保养时间”和“累计运行时长”放进去，理由是这两项直接关联预防性维护。这个建议确实是我在需求池里漏掉的，AI 帮我把业务逻辑闭环了一格。

5.3 接上GPT-6 Astra，做真正的智能交互

大屏上放一个 AI 助手框，在工业大屏里已经不是新鲜事，但大多数做得太浅，只做了一个闲聊对话。我把 GPT-6 Astra 接到大屏上的方式有三条。

第一条是自然语言问数，用户输入“昨天哪个班次停产时间最长”，模型解析语义，映射到点位表和指标口径，生成查询条件，后端执行后把答案返回大屏。第二条是告警归因，当大屏弹出设备告警时，AI 助手会结合当前设备参数、关联设备状态、最近维护记录，给出可能的故障原因和排查建议。第三条是预案生成，安全生产场景里出现异常事件时，AI 根据事件类型输出标准处置流程和通知对象。

要让这三条路径稳，提示词的写法很关键。核心经验是：给模型“专家角色 + 任务边界 + 已知数据字典 + 输出格式 + 禁止做的事”。比如告警归因的提示词模板：

“你是一个空压机故障诊断专家。当前空压机（设备ID：A-201）触发排气高温报警，实时数据：排气温度98℃，环境温度32℃，冷却水进水温度28℃，出水温度36℃，本次已连续运行6小时。请按以下格式输出：1. 最可能的3个故障原因（按概率排序）；2. 每个原因的判断依据；3. 建议立即检查的动作；4. 如果10分钟内温度未下降，建议的升级处理方式。不要给出需要停机之外的具体维修操作，不要编造数据中不存在的参数。”

这种提示词的核心是“限制”，而不是“发散”。我发现很多人用 GPT-6 Astra 总觉得它不够专业，其实大部分时候是提示词写得太泛，没有给它数据和约束。给定足够的信息边界和输出结构，模型的推理质量会明显上一个档次。

6. 联调、验收和复盘：闭环在这里落地

6.1 性能调优的几个硬指标

大屏项目上线前最重要的一道关卡是性能，这一关过不了，演示当场翻车。我给这次项目定了几个硬指标，并且用脚本在联调阶段每天跑一遍：首屏加载时间不超过 5 秒；场景操作帧率保持在 30fps 以上，低配测试机不低于 24fps；内存占用不超过 2GB，长时间运行无明显上涨；数据刷新延迟小于 1 秒。

实际调优过程中，最大的性能杀手是灯光和阴影。工业场景里设备多、结构复杂，如果每个发光体都开实时阴影，帧率会直接掉到十几帧。我的方案是：环境光 + 一个方向光做主光源，重点设备区域用点光源点缀，阴影只给最重要的几台设备开，其余全部用假阴影贴图。粒子效果和飞线也做数量上限，超过阈值自动降级或隐藏。纹理压缩用 Draco 和 KTX2，模型在构建阶段就完成压缩，运行时不再做处理。

性能问题还有一类是数据造成的。WebSocket 推送频率过高，前端每秒渲染几千次变化，再好的显卡也扛不住。我给数据推送做了“按区域聚合、按变化量触发”的规则：设备状态变化 100ms 内推送，温压这类模拟量超过阈值或变化超过死区才推送，前端收到数据后再批量更新 UI。这样既保实时性，又避免渲染线程被刷爆。

6.2 数据不准，AI再聪明也没用

验收阶段最容易出的问题，不是功能缺失，而是数据对不上。这个阶段我用了一个很土但很有效的方法：人工抽检。拿三个时间点的数据，分别从 DCS 组态界面、数据库表、3D 大屏三个地方提取，对比是否一致。总共抽了六十个点位，发现三个问题，其中一个让我印象很深：某台水泵的排放压力在大屏上显示为 0.45，但 DCS 上是 0.44，差了 0.01。原因不是采集错误，而是点位表里该设备的压力单位标错了，显示端默认按 MPa 做了两位小数，真实值其实是 0.445，四舍五入后变成 0.45。这种问题 AI 很难发现，因为它看到的是处理后的数据，而不是原始数据。

所以我在团队里立了一条规矩：所有 AI 生成的结论，最终都要能在原始数据上反查到出处。大屏上每个数字点击后都要能看到数据来源、采集时间、更新时间。这个设计看似简单，却是让业务人员建立信任感的关键。数据可溯，AI 的建议才有人敢采纳。GPT-6 Astra 在排查阶段也帮了忙，我把 0.44 和 0.45 的疑点丢给它的前身模型做数据链路分析，它提示我检查“四舍五入精度”和“单位换算”，一查果然命中。但这种分析只是提效，最终确认还得靠人去现场核对。

6.3 复盘：这次用AI干活，到底值不值

项目收尾后我做了一次复盘，直接说结论：值，但不是所有环节都值。最值的是调研和视觉阶段，以前要花三周去对齐的事情，这次压缩到一周，GPT-6 Astra 的结构化输出和 GPT-Image-2.5 的快速出图帮了大忙。中段的数据接入和模型优化没有捷径，该采的点位要采、该优化的模型要优化，AI 只能做辅助检查，不能替你接设备。后端的智能交互是加分项，但前提是前期的数据质量和口径都过关，否则 AI 回答得再流畅也是错的。

如果要我给后来者一句建议，那就是：先用 AI 武装好“链路中最混乱的那一段”，通常是需求和数据口径，而不是一上来就追求 AI 自动建模、AI 自动生成立即交付的完整大屏。先让 AI 帮你把定义搞清楚，再用传统工程手段把数据做扎实，最后把 AI 放在交互和归因层，这样的组合目前最落地。这条链路走完之后，我现在接任何智慧厂房 3D 大屏的项目，第一件事就是把这篇复盘里的六张表拿出来，按流程重新填一遍。你会发现，链路一旦闭环，项目就没那么慌了。