IFC遇上glTF：BIM模型交给AI前要打通什么-BIM资源网

IFC遇上glTF：Khronos与buildingSMART联手，BIM模型交给AI与数字孪生之前要先打通什么

导语：模型要出门了，两个开放标准先握了手

2026年11月2日，buildingSMART International 与 Khronos Group 宣布达成一项新的联络协议（liaison agreement），要一起推进 IFC 与 glTF 之间的互操作。这条消息看起来像是两个标准组织之间的技术往来，但它真正值得 BIM 人留意的原因很实际：BIM 模型正在越来越多地走出设计软件——交给 AI 做设计审查、交给数字孪生做运维、放到网页和手机上给各方查看。模型一旦“出门”，“信息不丢、几何能看”这两件事就必须同时成立，而这正是 IFC 与 glTF 各自擅长、又一直没完全接上的地方。

先把口径说清楚：这次宣布的只是合作的起点和对话框架，不是一个已经发布的新产品，更不能说“从此 IFC 与 glTF 已无缝互通”。具体哪些工具会支持、什么时候落地、转换精度能提升多少，目前都还没有公布。下面这篇文章，就讲这次合作到底在解决什么问题，以及在它真正落地之前，BIM 人现在就该做对哪几件事。

IFC 与 glTF：一个管“信息”，一个管“看”

很多人第一次听到 glTF 会问：BIM 不是已经有 IFC 了吗，为什么还要一个 glTF？答案是，两者分工本来就不同，缺了谁都不完整。

IFC（ISO 16739-1:2018）：buildingSMART 的开放标准，负责结构化建设资产信息的交换。墙是什么墙、门是什么门、构件属于哪个系统、有哪些属性，IFC 管的是这些“看不见但很要紧”的信息。
glTF（ISO/IEC 12113:2022，glTF 2.0）：Khronos 的开放标准，负责 3D 场景与模型的高效传输与加载。模型在网页、手机、交互式 3D 应用里能不能快速打开、流畅旋转缩放，glTF 管的是这个。
共同点：两者都是免版税的开放标准，不绑定某一家软件。这也是它们能坐到一张桌子前的前提。

一句话概括：IFC 让模型“说得清”，glTF 让模型“看得快”。BIM 模型要服务 AI 与数字孪生，这两件事缺一不可。

为什么是现在？AI、数字孪生和 Web 应用把需求推到了台前

这次合作的背景，官方表述里点得很明确：AI、数字孪生、Web 应用和交互式 3D 在建筑环境里的应用越来越多。这不是一句套话，对应的是三类正在变多的真实场景：

IFC结构化信息与glTF轻量化3D模型对照示意图

AI 要“读懂”模型：AI 做设计审查、合规检查、算量辅助时，读的是结构化信息。属性丢了、分类乱了，AI 再聪明也只能对着一堆没有语义的几何体猜。
数字孪生要“连得上”模型：运维阶段的数字孪生要把传感器数据、设备台账挂到具体构件上。挂不上去，孪生就只剩一个好看的 3D 壳子。
Web 端要“打得开”模型：业主、审图、施工、运维各方越来越多地在浏览器里看模型。几百兆的模型传半天打不开，再准确的信息也没人用。

这三类场景凑在一起，就逼出了一个老问题：从 IFC 到 glTF 的转换，到底该丢什么、该留什么、留下的东西还准不准？这正是双方协议要先研究的内容：探索共享用例与技术需求，审视现有的 IFC 到 glTF 转换做法，找出可以改进的地方，并考虑为软件开发者提供实务指引。

这次合作到底要做什么？三件已经明确的事

按双方公布的内容，这次联络协议首先搭建的是技术对话与知识共享的框架，具体工作集中在三个方向：

方向	内容	对 BIM 人的意义
共享用例	探索在交互式 3D 应用里可视化与流式传输建筑资产模型的用例	明确“模型出门后”到底要满足哪些场景，而不是各做各的转换
审视现有转换	回顾现有的 IFC 到 glTF 转换做法，找出可以改进的地方	转换丢信息、属性对不上这类老问题，有机会被系统性地梳理
开发者指引	考虑为软件开发者提供实务指引	工具厂商有了共同参考，转换结果有望越来越一致

注意这张表里没有的：没有新产品发布，没有明确的时间表，没有精度提升的具体数字。任何把这次合作写成“问题已经解决”的说法，都是过度解读。它的真正价值在于，两个标准的制定方第一次正式联手，把“IFC 的信息如何可靠地带进 glTF 的 3D 世界”列为共同课题。

对 BIM 人最直接的影响：三种交付场景正在变

场景一：AI 设计审查，模型要“经得起读”

AI 审查的第一步永远是解析模型：构件分类对不对、属性全不全、防火分区、疏散宽度这些信息能不能被机器读到。如果交付给 AI 的只是一个转成 glTF 的轻量化几何体，审查结果很可能看着漂亮、实则无据可依。反过来，只给 IFC 又可能在 AI 的可视化环节卡住。未来更合理的做法，是让 AI 同时拿到“能看的几何”和“能读的信息”，并且两者能对上号。

场景二：数字孪生运维，模型要“挂得上数据”

数字孪生的价值不在模型本身，而在模型与实时数据的绑定。设备编号、系统归属、安装位置这些信息一旦在转换中丢失，后续再想补回来，成本会成倍增加。IFC 与 glTF 的衔接如果做好，孪生平台就能直接用上带属性的轻量化模型；做不好，运维团队就得一遍遍手工对表。

场景三：Web 端协同，模型要“人人打得开”

图审、报建、汇报、远程协同，越来越多环节要求模型能在浏览器里直接打开。glTF 的轻量化优势在这里最明显，但前提是轻量化不能以牺牲关键信息为代价。哪些属性必须保留、哪些几何可以简化，正是这次合作要讨论的技术需求之一。

这三个场景还有一个共同背景：合规与交付的要求本身也在收紧。全球多地BIM强制令加速落地，广东图审政策对BIM交付提出明确要求，模型早已不是“做着玩”的加分项。标准打通得越好，合规交付的成本就越低。

在标准真正落地之前，BIM 人现在就该做对的 4 件事

等标准组织把一切都定好再行动，至少要晚一轮。下面这 4 件实务建议，不依赖这次合作的任何后续进展，现在就能做：

AI设计审查与数字孪生运维场景中的BIM模型示意图

保留源文件与版本：每次转换、每次交付，都保留原始 IFC 或原生模型文件，并记录版本号。源文件在，转换丢了信息还能追溯；源文件丢了，任何补救都是猜。
记录转换设置：用什么工具、什么版本、哪些导出选项、LOD 如何设定，写下来、随交付物一起归档。同一模型用不同设置转出来可能完全不同，没有记录就无法复现，也无法定位问题。
抽查代表构件的几何与属性对应：不必全量核对，但要抽几个有代表性的构件：几何位置对不对、尺寸有没有走样、属性字段有没有错位或丢失。抽查要覆盖结构、机电、建筑不同专业各至少一类构件。
交付时区分两种交付物：“只给看”的交付物（轻量化、可快速打开的 3D 模型）和“带属性验证”的交付物（可核查、可追溯的完整信息模型），用途不同、要求不同，不要混成一个文件交出去，再让对方猜。

这 4 件事的共同逻辑是：把“信息不丢、几何能看”从口号变成可检查的动作。标准打通之后，这些习惯只会更值钱，不会过时。

容易踩的 3 个误区

误区一：转成 glTF 就等于交付完成了。轻量化模型只是“看得快”，不是“信息全”。没有属性验证的交付，审图、算量、运维环节都可能不认。
误区二：IFC 导出一次就万事大吉。不同软件、不同版本的 IFC 导出质量差异很大，导出后不检查、不抽查，等于把问题留给下游。
误区三：把这次合作当成“马上能用”的工具。目前公布的是合作框架与研究方向，不是已发布的新产品。跟进它的进展值得，但项目交付不能等它。

归档环节同样值得顺手规范：61号令对BIM归档的要求已经明确了模型与数据要怎么留存，转换记录、版本记录按归档标准整理，等于提前备考。

常见问题

Khronos 与 buildingSMART 这次合作宣布了什么？

2026年11月2日，双方宣布达成一项新的联络协议，目标是推进 IFC 与 glTF 之间的互操作。第一步是探索如何把结构化建筑资产信息更可靠地带进交互式 3D 应用，搭建技术对话与知识共享的框架。

IFC 与 glTF 有什么区别？

IFC 是 buildingSMART 的开放标准（ISO 16739-1:2018），负责结构化建设资产信息的交换；glTF 是 Khronos 的开放标准（ISO/IEC 12113:2022，glTF 2.0），负责 3D 场景与模型的高效传输与加载。两者都是免版税的开放标准，一个管“信息”，一个管“看”。