智能生成数字孪生驾驶舱,EasyV真的“Easy”

0 阅读10分钟

易知微的产品叫EasyModel、 EasyV、EasyTwin、EasyHuman。Easy,是写进产品哲学里的承诺:让用户更轻松地达到他想要的目的。

但有一个问题,我们思考了很多年:产品设计的初衷是让业务人员直接用,但现实中,做出一个真正可用的数字孪生应用或数据驾驶舱,始终绕不开专业团队的深度介入。

问题的根源在于这个领域本身足够复杂——数据接入、空间建模、视觉规范、交互逻辑、业务规则,每一层都需要专业判断。于是,"Easy易用"这个目标,长期停留在一个尴尬的位置:终点就在那里,但一直没有一条路能直接走过去。

直到这一轮 AI 浪潮真正到来。

AI的上半场与下半场

上个月,GPT-Image-2的图像生成新模型刷屏了整个行业。一段简短的提示词,就能生成一张细节丰富、布局精良的数据驾驶舱概念图——指标模块分区清晰,数据样式逼真,视觉质感已经接近可以拿去汇报的程度。

图:基于GPT-Image-2生成的孪生场景驾驶舱

这件事在行业里引发了两种截然不同的反应:一种是"AI 要抢饭碗了",另一种是更值得思考的追问——它做到的,到底是哪一半?

我们把这个问题拆成两段。上半场,是从需求到概念的视觉化呈现——把一个业务想法"画出来",让人看得懂、能讨论、有画面感。下半场,是从概念到可以真正运行的工程产品——数据要接进来,交互要跑得通,业务规则要嵌进去,最终交付一个客户能日常使用的系统。

现阶段的图像生成模型,已经相当漂亮地解决了上半场。但上半场和下半场之间,隔着的正是整个行业多年积累的专业门槛。 跨越这道门槛,靠推理能力更强的模型远远不够。

通用大模型,卡在哪里?

一个直觉上的误解是:既然大模型足够聪明,我只要把需求描述清楚,它应该能生成一个可用的驾驶舱或孪生场景。事实并非如此,原因很具体。

在数字孪生驾驶舱这个垂直领域,通用大模型见过大量 dashboard 截图、前端代码和可视化设计资料,但真正缺少的是可交付系统所需要的结构化领域知识:指标如何组织、组件如何约束、布局如何服务业务优先级、交互如何联动、数据如何接入真实系统。 这些知识存在于每一个做过数字孪生项目的团队的经验里,从没被系统性地结构化出来。

DeepSeek、Qwen、GPT、Gemini,这些模型能生成一张看起来专业的驾驶舱概念图,但概念图和可运行的工程产品之间,横着一整套领域配置规则。看起来是个驾驶舱,但能跑起来的产品,是另一回事。

AI 要真正进入下半场,关键在于具备一套结构化、领域专属的知识基础。这套基础从哪里来?

底层的设计系统,才是 AI 智能生成的真正燃料

理解这个问题,需要先理解一个概念:设计系统(Design System)。

Google 有 Material Design,把所有 Android 应用的设计规范原子化——组件有多少种类型、布局支持哪些形态、颜色与字体如何约束。微软有 Fluent Design,国内开发者熟悉的 Ant Design,本质上做的是同一件事:把"如何做出一个好的前端应用"这件依赖经验的事,提炼成一套结构化的、可被调用的规则体系。

图片 5.2026-05-21 11_23_06.gif

这套体系一旦建立,好处是双重的:人可以按规则快速做出符合规范的产品,AI 也可以理解这套规则并在其框架内生成合规的输出。

易知微在数字孪生和数据驾驶舱领域,做的正是同一件事——只是更难,因为这个领域从来没有人系统性地做过。

从成立至今,在大量真实项目的交付过程中,我们逐渐沉淀出了属于这个领域的设计系统:每一个 Panel 支持哪些数据类型,不同业务场景的布局优先级如何排布,指标模块有多少种最小组合单元,孪生场景中哪些空间要素具有通用性。这些内容超越了产品文档和设计规范的范畴,是真正意义上的领域知识结晶。

做 Product+AI,易知微从一个更根本的问题开始:AI 要生成真正可用的产品,它需要学什么、调用什么、在什么框架内发挥?答案正是这套多年沉淀的设计系统。

把经验编码进系统:Product+AI 的真正含义是什么

当设计系统被系统性地语义化和结构化之后,下一步才是 AI 的介入。

以 EasyV 的驾驶舱生成为例,整个过程遵循的是一套精心设计的协同机制:

第一层,是有约束的自由。 AI 工作在明确的边界内,但边界内有充分的推理空间。比如,一个布局区域可以放 3 个模块,也可以放 5 个,但超过 6 个就会破坏视觉秩序——这个边界由设计系统给出,AI 在边界内根据业务语义自主判断最优解。给 AI 留下推理空间,同时避免它在无结构的空白上自由漂移,这是整个工程体系的核心哲学。

图片-2.2026-05-21 11_25_29.gif

图片 1.2026-05-21 11_31_12.gif

第二层,是原子化的知识调用。 用户的自然语言输入,经过多模态理解、业务主题识别,被拆解成对设计系统中具体组件、模板、布局规则的精准调用。本质是基于结构化知识的语义推理——更接近一个真正懂产品的工程师,而非做图案匹配的搜索引擎。

第三层,是可沉淀、可演进的能力结构。 每一次新的项目交付、每一个新的行业场景,都会反哺这套知识体系,让 AI 下一次面对类似问题时表现更好。这是一个正向飞轮:项目经验越丰富,AI 生成能力越强;AI 能力越强,交付效率越高,又带来更多项目沉淀。

EasyTwin 的三维场景生成遵循同样的逻辑,只是复杂度更高一个量级。以港口码头为例,整个过程分三层推进:第一层是多模态解析——用户输入一张卫星影像或无人机 DOM,AI 完成场景类型识别、空间要素识别和风格偏好提取,把图像里的岸桥、集装箱、堆场、建筑等要素逐一标定,并为每个区域赋予唯一的语义标签。这一步做的事情,本质上是让 AI 读懂现实空间的"空间语法"——哪里是功能区、哪里是通道、哪里是核心作业区域。

第二层是空间要素组织——基于解析结果,AI 完成底层规划与区域划定、模型资产匹配、对象关系组织,并给出场景布局建议。这里调用的正是易知微多年项目中系统性整理和标注的几何模型资产库:岸桥有多少种规格对应哪类操作场景,集装箱的堆叠规则是什么,不同吨位的船型如何与泊位关系对应。AI 的工作不是凭空搭建,而是在一套有行业深度的空间规则上完成推理和匹配。

第三层才是场景配置生成——输出可直接进入 EasyTwin 编辑环境的完整场景,支持自动校验修正,并保留结果的可视化二次编辑能力。三层走完,原本需要专业建模人员逐一整理模型、手工编排空间关系的过程,变成了一次有结构、可复用、可持续迭代的生成式构建流程。

这一轮的底层变化,比看起来更深

Product+AI 到底改变了什么?

表面上看,是效率——原来需要专家配置的事情,现在自然语言就能完成,某些典型场景的建设效率可以提升 5 到 10 倍。

但更深层的变化,是产品与用户之间的关系被重新定义了。

过去的产品逻辑是:工具越来越强大,但使用者需要不断学习才能驾驭工具。产品做得再好,也有一道"学习成本"的墙横在用户和价值之间。真正能发挥产品全部能力的,永远是少数专家。

Product+AI 改变了这个逻辑的根基:专业知识被编码进了系统。用户只需要清楚地表达自己的业务意图,系统处理剩余的一切复杂性

这是产品哲学层面的一次真正跃迁——"人与产品之间边界"的重新划定,远比一次功能迭代意义深远。

易知微到底想Easy什么

做 Product+AI 有两条路径。

第一条:有了 AI,再去找场景。接入大模型,做一层对话界面,快速推出"AI 驾驶舱"。这条路的问题在于:AI 生成的原料是什么? 缺少结构化的领域知识支撑,大模型只能在通用知识上发挥,生成的结果可以看,但跑不起来。

第二条:先有积累,再接 AI。在真实业务场景中做了足够多的项目,把经验提炼成设计系统,把设计系统语义化为 AI 可调用的知识,再在这个基础上构建生成能力。这条路很慢,但最终生成出来的是真正可用的产品。

易知微走的是第二条路。原因很朴实:在 AI 大规模应用之前,我们就已经在做这件事的前半段了——产品体系的建设、设计系统的沉淀、模型资产的积累。这些工作的初衷是交付更好的产品,它们恰恰成了 AI 生成能力最关键的燃料。

某种意义上,其实是AI 的发展赶上了易知微一直想做的事。

写在最后

Easy 这个词的含义,从来比"操作简单"更深一层:用户应该把精力放在业务判断上,产品的职责是把复杂性挡在用户视线之外。

这个目标,在数字孪生这个领域,比大多数行业都更难实现——因为这个领域的复杂性是真实的、多层的。Product+AI 给了我们第一次真正接近这个目标的可能。AI 站在易知微多年积累的肩膀上,有足够的知识可以调用,有足够清晰的边界可以遵守,有足够成熟的产品可以承载输出。

从概念到工程,从生成到可用,从专家操作到人人可达——

这一步,易知微准备了很久。

访问易知微官网:易知微 - 数字孪生仿真渲染引擎与可视化应用