从数字化到数智化：3D 可视化大屏的下一个五年

这几年做 3D 可视化项目，有一个感受越来越明显：

大屏做得越来越漂亮，但真正被使用的功能，可能越来越少。

一个智慧工厂项目，打开就是厂区三维模型，设备在运转，管线有流光，四周排满了产量、能耗、设备状态、告警数量等指标。

一个智慧城市项目，打开就是城市三维地图，建筑有科技感描边，道路有动态光效，左右两侧堆满各种统计图表。

视觉效果确实不错。

但仔细想想，这些大屏的交互逻辑，其实和几年前并没有太大区别。

数据提前准备好，图表提前设计好，页面提前规划好。用户能看到什么、能操作什么，基本都由开发人员事先决定。

如果领导突然问一句：

"上周哪几个区域的能耗异常？"

或者：

"这条产线为什么今天的产量下降了？"

大屏可能就回答不上来了。

不是因为没有数据，而是因为我们没有提前设计这个页面。

这其实暴露了传统可视化大屏的一个问题：

我们一直在努力让大屏展示更多信息，却很少思考如何让用户更方便地获取信息。

进入"十五五"，随着数字化向数智化发展，我觉得 3D 可视化大屏也应该发生一次变化。

未来的大屏，不应该只是一块用来展示数据的屏幕。

它应该成为一个行业的统一交互入口。

一、从数字化到数智化，大屏需要重新定位

"十五五"时期，数智化成为数字中国建设的重要方向。

从数字化到数智化，看起来只是增加了一个"智"字，但对软件产品来说，背后的变化值得关注。

过去我们讲数字化，重点往往是把现实世界的信息变成数字。

设备运行状态可以采集，生产过程可以监控，城市基础设施可以映射到三维场景中。

于是，我们有了智慧工厂、智慧园区、智慧城市，也有了各种数据可视化大屏。

这些系统解决了一个重要问题：

让原本分散的数据变得可见。

但随着数据不断积累，新的问题又出现了。

一个行业可能有几十套业务系统，几百个数据指标，几千台设备。

如果我们继续沿用传统思路，把重要的数据全部放到大屏上，结果往往是屏幕越来越复杂。

左边是统计图，右边是排行榜，上面是关键指标，下面是实时告警。

为了让内容放得下，字体越做越小，图表越来越密集。

最后，一块原本用来提高信息获取效率的大屏，反而需要用户花更多时间寻找信息。

而 AI 的出现，提供了另一种可能。

用户不一定需要知道数据在哪个页面，也不一定需要理解每一个指标的含义。

他可能只需要提出一个问题：

"今天有哪些设备存在异常？"

系统就可以查询相关数据，定位异常设备，在三维场景中高亮对应对象，并展示异常原因和历史趋势。

这才是我理解的数智化。

不是在原来的大屏右下角增加一个 AI 对话框，而是让 AI 真正参与数据查询、场景控制和信息组织。

当然，这并不意味着传统图表和固定看板会消失。

对于需要持续监控的关键指标，固定展示仍然是最高效的方式。

真正需要改变的是：不再要求所有信息都必须同时出现在屏幕上。

二、一屏一行业：展示最小，交互最大

如果让我重新设计一套智慧工厂大屏，我会尝试遵循一个原则：

展示最小，交互最大。

这里的"展示最小"，不是让大屏变得空荡荡。

而是默认只展示最重要的信息，把复杂内容留给交互。

我认为未来的行业大屏，可以分成三个层次。

🍋1. 默认态：一眼看懂整个行业

打开大屏时，首先看到的应该是行业的整体状态。

以智慧工厂为例。

屏幕中央是一座完整的三维工厂，周围只保留少量关键指标：

今日产量

设备运行率

综合能耗

当前告警数量

生产计划完成率

其他信息暂时隐藏。

三维场景也不需要所有设备都在旋转、所有管线都在流动。

正常运行的设备保持低干扰状态，异常设备通过颜色、轮廓或适度动画突出。

用户进入系统后，首先应该知道：

工厂整体是否正常？

哪里存在问题？

有没有需要立即处理的事情？

大屏的默认状态，应该帮助用户快速建立全局认知，而不是展示开发团队做了多少功能。

这涉及一个很重要的设计理念：信息层级。

一块屏幕应该有明确的视觉焦点。

如果每一个数字都在发光，每一个图表都在闪烁，那么最终就没有任何信息能够真正突出。

🍋2. 交互态：从行业到设备，逐层深入

当用户对某个区域产生兴趣时，再展示更详细的信息。

例如点击工厂中的一栋车间。

镜头平滑移动到车间位置，其他建筑适当弱化，界面出现车间的生产状态。

继续点击某条产线。

镜头进一步靠近，展示产线设备、运行状态、产量和能耗。

再点击某台设备。

系统展示设备参数、实时数据、历史曲线、维护记录。

整个过程可以形成一条清晰的交互路径：

工厂 → 车间 → 产线 → 设备 → 业务数据。

这里有一个容易被忽略的细节：

三维模型不应该只是一个视觉装饰。

每一个需要交互的三维对象，都应该能够关联到业务实体。

例如模型中的设备对象具有唯一 ID：

device_001

通过这个 ID，可以找到对应的设备信息、实时数据、历史记录以及相关业务接口。

这样，点击三维设备就不再只是弹出一个提前写好的介绍面板。

而是进入对应的业务上下文。

这要求我们在设计三维场景时，就考虑模型与业务数据的映射关系。

未来的三维场景，不只是模型的集合，更应该是行业业务关系的空间表达。

🍋3. 智能态：用户提出问题，系统组织界面

前面两层，其实通过 Three.js、Cesium 和常规前端技术就能实现。

第三层才是 AI 真正能够带来变化的地方。

假设用户打开智慧工厂大屏，直接输入：

"帮我找出上周能耗异常的产线。"

传统大屏可能需要用户进入能耗页面，选择时间范围，再逐个查看产线数据。

而接入 AI 后，可以设计成另一种交互流程。

首先，AI 理解用户想查询的是产线能耗异常。

然后调用业务系统提供的数据查询工具，获取符合条件的产线。

接着，通过产线 ID 找到三维场景中的对应对象。

镜头自动移动到相关区域，高亮异常产线。

最后，系统根据查询结果生成一张临时的能耗趋势图，并展示异常时间、偏离程度以及相关指标。

如果用户继续问：

"和前一周相比呢？"

系统可以保留当前上下文，继续查询并更新图表。

如果再问：

"把异常最严重的设备定位出来。"

镜头就可以进一步移动到对应设备。

注意，这里有一个很大的变化。

过去是开发人员提前设计页面，未来可以是系统根据用户的问题动态组织页面。

当然，这需要一个前提：

AI 必须能够通过可靠的工具访问业务数据，并且具备明确的场景控制能力。

它不能仅凭语言模型生成一段看似合理的设备分析。

真实数据必须来自业务系统。

设备定位必须基于明确的对象 ID。

异常判断需要可追溯的规则或模型。

对于控制设备、修改参数等高风险操作，还必须设置权限和人工确认机制。

所以我更倾向于将 AI 定位为一个智能交互调度层。

它负责理解意图、调用工具、组织信息。

而不是让 AI 凭空生成整个业务系统。

三、3D 模型怎么来，未来不再需要自己建模

聊完交互，再回到 3D 可视化工程师最熟悉的问题。

模型从哪里来？

过去做一个智慧工厂项目，模型生产可能占据相当一部分时间。

厂房需要建模，设备需要建模，管线需要建模，场景还需要不断调整。

如果客户提供了 CAD 或 BIM 文件，情况也未必轻松。

模型可能非常精细，但直接放到浏览器里，性能往往无法接受。

这几年，随着 AI 生成 3D、程序化建模和自动化工具的发展，模型生产方式正在发生变化。

我觉得未来做行业大屏，不应该只依赖某一种建模方式。

而应该根据资产类型选择最合适的技术。

🍋1. 核心资产，仍然需要专业建模

比如智慧工厂中的核心生产设备。

这些设备可能需要展示内部结构、运行原理、拆解动画。

有些还涉及复杂的机械运动。

这种资产对精度、拓扑结构和可控性要求比较高。

Blender、3ds Max 等传统建模软件仍然有不可替代的价值。

尤其是需要做设备动画、结构拆解和精细交互时，模型的组织方式比外观更重要。

一个看起来非常漂亮，但所有零件都合并在一起的模型，实际使用起来可能非常麻烦。

🍋2. BIM、CAD 和 GIS 数据，负责构建场景基础

对于厂房、建筑、管线以及城市级场景，通常没必要全部手工重建。

如果已有 BIM 或 CAD 数据，可以通过转换工具生成适合 Web 端使用的三维资产。

但这里有一个关键问题：

工程模型不等于实时渲染模型。

BIM 模型包含大量工程信息和精细结构。

这些内容对工程设计有价值，但不一定适合在浏览器中实时渲染。

直接加载可能出现模型体积过大、Draw Call 过高、首屏加载缓慢等问题。

因此，模型转换之后通常还需要进行：

几何合并、实例化、材质整理、减面、LOD 处理以及纹理压缩。

对于城市、园区等地理空间场景，可以考虑 Cesium 和 3D Tiles。

对于规则化建筑、道路和地块，也可以利用 GeoJSON、OSM 等数据进行程序化生成。

例如一座城市的普通建筑白模，很多时候不需要逐栋手工制作。

只要有建筑轮廓、高度等数据，就可以批量拉伸生成。

程序化建模最适合解决重复、规则和规模化的问题。

🍋3. AI 生成 3D，适合补充大量非核心资产

AI 生成 3D 是我觉得值得持续关注的方向。

目前已经有 Meshy、Tripo、Rodin、腾讯混元 3D 等工具，可以通过文字或图片生成三维模型。

1.tripo:studio.tripo3d.ai/

我最常用的生成3D模型的网页，强烈推荐

2.meshy:www.meshy.ai/

比较少用，常用于做一些手办和萌宠。

3.Rodin:hyper3d.ai/

worldGen功能很吸引人。

4.腾讯混元：3d.hunyuan.tencent.com/

有免费20次的额度，生成效果也不错。

开源方向也有 TRELLIS 等相关项目。

对于大屏开发来说，这意味着一些原本需要寻找素材或者手动建模的资产，可以尝试用 AI 快速生成。

例如：

工业设备外壳、园区装饰设施、普通机械道具、仓储货架、物流容器等。

但实际应用中，不能只看生成效果。

模型能不能进入项目，比模型生成得漂不漂亮更重要。

一张 AI 生成模型的预览图，可能看起来很精致。

但下载后可能发现：

面数过高，拓扑结构混乱，材质数量过多，贴图分辨率不合理。

甚至一个很简单的设备，也可能生成几十万面。

放到浏览器里，尤其是在同时加载大量设备的情况下，很容易造成性能问题。

因此，在生成之前就应该明确资产预算。

例如普通场景道具可以控制在几千到数万三角面，重要设备则根据镜头距离、屏幕占比和运行设备性能单独评估。

这只是初始预算，不是适用于所有项目的固定标准。

生成之后，还需要经过一套标准化处理流程：

AI 生成 → Blender 清理 → 减面优化 → 材质整理 → GLB 导出 → 压缩 → Web 端验证。

其中 GLB 压缩可以结合 Draco、meshopt、KTX2 等技术。

但压缩并不意味着模型一定运行得快。

它们主要解决传输体积、几何编码或纹理存储等问题，实际渲染性能还取决于模型结构、材质数量、Draw Call 和 GPU 开销。

所以最终仍然需要在目标设备上测试。

🍋4. AI 驱动 Blender，可能更值得关注

相比单纯的文生 3D，我其实更关注另一种方式：

让 AI 参与传统建模软件的操作流程。

例如通过 Blender Python API，或者 Blender MCP 一类的工具，让 AI 根据指令执行场景搭建和批量修改任务。

假设现在需要生成一个包含 20 台设备的车间。

我们可以提前准备好标准设备资产，然后通过脚本完成排列、命名、材质设置和场景导出。

如果设备间距需要调整，也不必手动拖动每一个模型。

通过参数或者自然语言指令，就可以修改整体布局。

再进一步，可以结合 Codex 等 AI 编程工具生成和维护 Blender 脚本。

整个流程可能变成：

需求描述 → AI 生成脚本 → Blender 执行 → 模型检查 → GLB 导出 → Three.js 加载。

这种方式有一个优势：

它不是每次都从零生成模型，而是建立在已有资产和明确规则之上。

可控性和可复现性通常更好。

当然，AI 生成的脚本同样需要检查和验证，复杂场景仍然离不开人工调整。

但对大量重复性工作来说，这条路线非常值得探索。

我认为未来的 3D 可视化工程师，可能不需要亲手完成每一个模型。

更重要的是：

知道什么资产应该手工制作，什么资产可以程序化生成，什么资产适合交给 AI。

5. 3DGS 的兴起，让实景还原多了一条路线

除了手工建模、程序化生成和 AI 生成，真实场景的重建方式也在变化。

其中一个值得关注的方向，就是 3D Gaussian Splatting，简称 3DGS，中文通常称为三维高斯泼溅。

2023 年发表的代表性研究，将高质量的新视角画面合成与实时渲染结合起来，为实景三维提供了一条新的技术路线。它利用多视角照片，优化大量具有位置、形状、颜色和透明度的高斯体，再通过这些高斯体的叠加还原场景外观。原始论文（https://arxiv.org/abs/2308.04079）

对可视化大屏来说，这意味着我们可以尝试把实际拍摄的厂区、园区或室内空间，重建为能够自由切换视角的实景场景。

它和过去常用的倾斜摄影有什么区别？

这里需要先区分两个概念。

倾斜摄影主要描述影像的采集方式，3DGS 则是一种场景表示与渲染方法。

常见的倾斜摄影建模流程，是通过多角度拍摄，经过影像匹配、空间重建，生成点云、三角网格和纹理。3DGS 则将采集到的影像用于优化高斯表示。同一批覆盖充分、质量合适的倾斜影像，也可以用于不同的重建路线。如今已有实景建模工具同时提供网格与高斯泼溅成果。Esri 成果类型说明（https://doc.esri.com/en/arcgis-drone2map/latest/get-started/product-output-types.html）

所以，更准确的比较对象，是传统倾斜摄影生成的纹理网格与 3DGS 场景。

比较维度	传统倾斜摄影纹理网格	3DGS 场景
场景表示	三角面构成表面，再附加纹理	大量高斯体叠加，重现不同视角下的外观
细节表现	取决于网格与纹理质量，细碎结构可能被简化	在采集充分时，细线、植被等细节可呈现得更自然
编辑方式	围绕顶点、面、纹理进行处理	围绕高斯体选择、裁剪与变换，不能直接照搬网格编辑流程
项目侧重点	便于接入已有网格处理与空间分析流程	适合强调真实观感的环境展示与漫游

不过，画面更逼真，并不意味着测量一定更准确。

无论采用哪种方式，涉及设备尺寸、空间距离或工程量计算，都需要可靠的尺度、坐标基准和精度验证。3DGS 中的高斯中心，也不能直接当作物体表面的测量点。

交互同样需要单独设计。

现在已有 Web 引擎支持对高斯场景进行点击拾取。但要进一步识别"这是一台水泵"，并关联设备编号、告警和维护记录，仍然需要对象分割、标注或额外的业务模型。传统倾斜摄影网格也不会自动具备这些业务含义。PlayCanvas 拾取文档（https://developer.playcanvas.com/user-manual/gaussian-splatting/building/picking/）

另外，3DGS 的性能也需要实际评估。

高斯数量、透明叠加、显存占用和屏幕分辨率，都会影响运行效果。进入大屏项目后，同样要考虑压缩、分块、LOD 和按需加载，并在现场设备上验证。PlayCanvas 性能文档（https://developer.playcanvas.com/user-manual/gaussian-splatting/building/performance/）

如果让我设计一套智慧园区大屏，我会考虑一种混合方案：

用 3DGS 还原园区的真实环境，用独立的设备模型承载拆解、动画和精细交互，再通过统一的坐标与对象 ID 关联业务数据。

对于以空间测量和分析为主的项目，则优先评估经过精度验证的摄影测量网格、点云或工程模型。

这也让模型选型多了一个判断维度：

需要真实环境观感时，可以考虑实景重建；需要精确结构、可控动画和业务交互时，就要为这些能力准备相应的模型与数据。

四、如何做好大屏，拼的都是细节

技术方案确定之后，最终效果仍然取决于很多细节。

这些细节可能不会出现在项目介绍里，但用户每天都能感受到。

🍋1. 信息层级比炫酷效果更重要

很多大屏喜欢使用发光边框、渐变背景、粒子动画和各种装饰线条。

这些元素并不是不能用。

但如果所有内容都在争夺注意力，就会影响真正重要的信息。

我更倾向于让三维场景成为主要视觉区域。

其他图表根据业务需要出现。

正常状态保持克制，异常状态明确突出。

特别是红色。

如果一块屏幕到处都是红色装饰，那么真正发生告警时，红色就失去了提醒作用。

颜色应该表达业务含义，而不只是营造科技感。

🍋2. 字体和数字，影响的不只是美观

大屏通常需要展示大量实时变化的数据。

例如产量从 999 变成 1000。

如果使用普通比例数字字体，数字宽度变化可能导致布局抖动。

可以使用支持等宽数字的字体，或者通过 CSS 设置：

font-variant-numeric: tabular-nums;

中文字体则优先选择清晰、稳定的无衬线字体。

例如思源黑体、阿里巴巴普惠体等。

另外，设计时不能只盯着电脑显示器。

一块 55 英寸屏幕和一块会议室里的大型拼接屏，实际观看距离完全不同。

字号应该根据屏幕尺寸、分辨率和观看距离进行验证。

而不是设计稿上看着合适就结束。

🍋3. 行业配色应该有自己的逻辑

不同行业的大屏，不一定都需要使用蓝色科技风。

制造业可以使用钢蓝灰作为背景，通过工业橙强调设备状态。

能源行业可以采用深蓝与青色，突出能源流向和设备运行信息。

医疗场景更适合低饱和的青绿体系，避免过度发光。

农业和环保项目可以结合深绿、土黄等自然色系。

交通物流则可以使用深灰与琥珀色，突出路径、车辆和运行状态。

但这些都只是视觉方向。

真正重要的是建立统一的颜色语义。

例如：

正常状态使用绿色，警告使用琥珀色，严重异常使用红色。

同一种颜色在不同页面中尽量保持一致的业务含义。

这样用户才能形成稳定的认知。

🍋4. 动效应该服务于信息

在 3D 场景中，镜头动画非常重要。

点击设备后，镜头如何移动？

从全厂切换到车间时，如何避免用户迷失方向？

定位异常对象时，如何让用户知道目标在哪里？

这些其实都是交互设计问题。

好的镜头动画，不是飞得越炫越好。

而是让用户在空间切换过程中始终知道自己在哪里。

例如从厂区进入车间，可以先移动到车间外部，再逐渐拉近到设备。

而不是直接瞬移到设备内部。

对于频繁操作的功能，还应该允许用户跳过动画。

动效的价值是帮助理解变化，而不是单纯展示渲染能力。

🍋5. 性能决定大屏能不能长期运行

这一点做过实际项目的人应该很有感触。

开发电脑上运行流畅，不代表部署到现场就没有问题。

现场可能使用不同性能的显卡。

可能需要同时驱动多块屏幕。

也可能要求系统连续运行几天甚至几周。

因此，性能优化不能等到项目最后才做。

从建模阶段开始，就需要控制资源预算。

例如合理使用 InstancedMesh、LOD、纹理压缩、按需加载等技术。

对于 Three.js 项目，需要持续关注 Draw Call、三角面数量、纹理内存和渲染耗时。

对于 Cesium 项目，则要关注瓦片加载、缓存策略、相机高度与细节层级之间的关系。

除了渲染性能，还要考虑系统稳定性。

接口断开后如何恢复？

WebSocket 重连之后如何同步数据？

长时间运行是否存在内存泄漏？

数据为空时展示什么？

模型加载失败怎么办？

这些问题听起来没有 AI 和数字孪生那么吸引人。

但真正部署到现场后，往往比某个特效重要得多。

能稳定运行的大屏，才有资格谈智能化。

五、AI 真正改变的，可能是大屏的开发方式

前面讲的是产品形态的变化。

但从工程师的角度看，我觉得还有一个更值得关注的趋势。

未来，大屏的开发方式本身也可能发生变化。

传统的大屏开发流程通常是：

产品确定需求，设计师完成页面，建模师准备模型，前端工程师开发交互，后端提供接口。

每增加一个业务页面，往往都需要重新走一遍开发流程。

但如果大屏开始具备动态组织信息的能力，很多东西就可以逐渐从固定页面转变为可配置的能力。

例如图表组件。

过去我们需要提前开发能耗分析页面、产量分析页面、设备故障分析页面。

未来可以先建立一套标准化的图表组件。

AI 根据用户的问题选择合适的图表类型，再结合真实查询结果组织展示。

三维场景也是一样。

过去点击设备 A，执行一段固定代码。

点击设备 B，再执行另一段代码。

未来可以将镜头控制、对象高亮、设备定位、图层切换等操作封装成标准工具。

例如：

locateObject(deviceId)

highlightObjects(deviceIds)

flyToArea(areaId)

showDataPanel(config)

这些工具可以由普通交互调用，也可以由具备权限的 AI 调用。

这样一来，AI 不需要理解 Three.js 或 Cesium 底层的所有实现细节。

它只需要知道系统提供了哪些可靠的操作能力。

前端则负责把这些操作转化为具体的视觉表现。

再往下，是统一的行业数据模型。

一台设备属于哪条产线？

一条产线位于哪个车间？

一个车间对应哪些能耗指标？

哪些业务数据可以通过设备 ID 查询？

只有把这些关系建立起来，AI 才有可能准确理解用户的问题，并将结果映射到三维场景。

所以，未来的大屏可能会逐渐形成一种新的架构：

行业数据模型 + 三维场景引擎 + 标准交互组件 + AI 调度层。

这里的 AI 调度层，并不是直接操作所有底层系统。

更合理的方式是通过受控工具调用，由业务系统负责数据权限、查询规则和操作校验。

对于前端工程师来说，这意味着工作重点可能发生转移。

我们不再只是根据设计稿开发固定页面。

而是需要建立一套能够被用户交互和 AI 共同调用的可视化能力。

这也意味着，未来的 3D 前端工程师除了掌握 Three.js、Cesium、WebGL 等技术，还需要理解：

数据模型如何设计，三维对象如何与业务实体关联，交互能力如何封装，以及 AI 如何安全可靠地调用这些能力。

当然，不是每个项目都需要一步到位。

对于很多企业来说，先把设备数据打通、把场景交互做好，就已经能够创造明显价值。

AI 可以在此基础上逐步接入。

没必要为了追求数智化，把一个原本简单稳定的系统变得复杂。

六、下一个五年，3D 可视化工程师的价值在哪里？

回头看这几年，3D 可视化技术已经发生了很大变化。

以前做一个复杂的三维场景，可能需要花大量时间处理模型、材质和渲染效果。

现在有了更成熟的三维引擎、模型处理工具和 AI 辅助开发能力，很多事情的门槛正在降低。

可以预见，未来生成一个漂亮的三维场景，可能会越来越容易。

甚至生成一套完整的数据可视化页面，也可能不再需要太多时间。

那么，3D 可视化工程师的价值在哪里？

我觉得答案不是把模型做得更复杂，也不是把动画做得更炫。

而是理解业务，并且把复杂的业务系统转化为直观、可操作的交互体验。

比如智慧工厂。

用户真正关心的不是设备模型有多少面，而是设备有没有异常。

不是产线动画有多流畅，而是生产效率为什么下降。

不是能耗图表有多漂亮，而是哪里存在能源浪费。

三维可视化的价值，是把这些抽象的数据和业务关系，放回用户能够理解的空间场景中。

而 AI 的价值，是进一步降低用户获取和使用这些信息的门槛。

两者结合，才可能让大屏真正从展示工具变成业务工具。

当然，这个过程不会一蹴而就。

行业数据治理、模型准确性、接口标准化、权限控制，以及 AI 输出的可靠性，都会影响最终效果。

但方向已经值得我们认真思考。

过去，我们评价一块大屏，首先看它漂不漂亮。

模型够不够精细，动画够不够流畅，视觉效果有没有科技感。

这些依然重要。

但未来，我觉得还应该增加几个问题：

用户能不能快速找到自己关心的信息？

能不能从一个异常指标定位到具体设备？

能不能通过自然语言查询复杂的业务数据？

能不能根据分析结果进一步触发实际业务流程？

如果这些问题都能得到很好的解决，那么即使屏幕上没有那么多图表，没有那么多发光特效，它仍然可能是一块非常优秀的大屏。

甚至可能比传统意义上的炫酷大屏更有价值。

因为它真正进入了用户的日常工作。

写在最后

我一直觉得，3D 可视化不应该只是把现实世界搬进浏览器。

如果只是还原一个工厂、一个园区或者一座城市，我们最终得到的可能只是一个可以旋转、缩放的三维模型。

真正有价值的，是让这个三维世界与背后的业务数据连接起来。

让用户能够通过空间理解数据，通过交互探索问题，再通过 AI 更高效地获取信息。

这也是我对未来行业大屏的一个判断：

一块屏幕，不需要同时展示一个行业的所有信息，但应该能够成为访问整个行业信息的入口。

默认展示可以很克制。

交互能力却可以不断扩展。

从看数据，到查数据，再到问数据、用数据。

从固定页面，到场景交互，再到 AI 动态组织信息。

这可能就是从数字化走向数智化之后，3D 可视化大屏值得探索的方向。

下一个五年，我们要做的，或许不再是一块让人抬头看的大屏，而是一个让人真正用起来的行业交互系统。