达索系统：让共同数据环境（CDE）真正服务于施工阶段

寂静回声

全球每年有超过13万亿美元投入建筑建造，但其中30%的成本源于返工和低效。更令人惊讶的是，尽管BIM（建筑信息模型）技术已经发展了二十多年，85%的建筑项目在施工阶段依然依赖纸质图纸和人工核对。
问题出在哪里？数据在设计和工程阶段流转顺畅，却在最关键的施工现场戛然而止。就像一条高速公路修到了工地门口，却没有最后通向现场的那几百米。
近日，buildingSMART国际组织举办了一场网络研讨会。在研讨会上，达索系统建筑、工程与施工（AEC）解决方案的产品负责人Marion Senesi用了45分钟时间，讲述了一个看似简单实则深刻的问题：如何让共同数据环境（CDE）真正服务于施工阶段？
Marion的演讲标题故意设置了一个"陷阱"：《让我们谈谈CDE——施工数据环境》。她知道有人会在LinkedIn上质疑她是否清楚CDE通常指的是"Common Data Environment（共同数据环境）"而非"Construction Data Environment（施工数据环境）"。
但这正是她的用意。她想强调的是：在建筑项目的全生命周期中，施工阶段往往是数字化断层最严重的环节。设计师、工程师各自拥有精美的BIM模型，但现场的施工经理和工人却拿着打印出来的图纸，在泥泞的工地上艰难对照。

以下是Marion Senesi演讲的主要内容：
各位朋友，很高兴能和大家坐在一起聊聊。我是Marion Senesi。今天我们的主题可能听起来有点拗口，我们要谈的是CDE。我知道，在座的各位专家肯定会第一时间想到“公共数据环境（Common Data Environment）”，这几乎是BIM界的常识。
但我今天故意玩了个文字游戏，把标题定为“施工数据环境（Construction Data Environment）”。为什么？因为在现有的建筑数字化流程中，我们发现了一个令人痛心的现象：在设计和工程阶段被吹上天的信息流，往往在踏入工地大门的那一刻就消失了。
现在的BIM重点，并没有理所当然地延伸到现场执行。这就导致了像现场经理、施工监督员这些真正流汗的人，在需要决策数据时，手里拿到的往往是过时的图纸或者是信息缺失的模型。这种“数据断流”正是我们要通过这场研讨会去弥补的鸿沟。
我们要探索的，是如何让现场团队能够真正“挪用”并利用这些数据。我们要把那些躺在服务器里的信息，转化成能够驱动效率、协作和项目成功的行动见解。这不仅是技术的更新，更是一场关于施工逻辑的重新发明，让CDE成为施工阶段的强力武器。
在开始深度解析之前，我要特别感谢主持人AidenMer以及buildingSMART的支持。作为主讲人，我带着达索系统的使命而来，旨在打破这种数字化的砖墙。接下来的45分钟，我们将不仅讨论概念，更会通过具体的虚拟孪生案例，展示如何实现这种端到端的追踪性。
为了让大家保持清醒，我想先请大家看两张图，玩一个“找不同”的游戏。左边是著名的路易威登基金会（Louis Vuitton Foundation），它的设计师是刚刚去世的伟大建筑师弗兰克·盖里。我保留这张幻灯片，也是为了向这位改变了现代建筑定义的先驱致敬。
右边是一个看起来非常普通的城市住宅项目。大家可能会觉得这两个项目完全没有可比性。但事实是，无论是个性张扬的艺术杰作，还是追求实用主义的民生工程，它们都是使用达索系统的虚拟孪生解决方案建造出来的。这意味着什么？这意味着技术的本质是普适的。
路易威登基金会在2014年完工时，其数字化程度在当时是惊人的。全球15个团队协作，处理着400个模型，每个模型的大小甚至达到了100GB。为了实现那些复杂的曲面，我们生成了19,000个独特的玻璃面板模型和超过3,000个曲线桩。
而右边的住宅项目，虽然外表普通，但其内部创新同样惊人。它在法国实施了最高标准的2D预制件技术，并满足了目前最严苛的环境标准。在如今经济压力巨大的时代，这个项目证明了：通过高标准的设计与施工整合，我们可以让这种高标准的环保住宅变得经济实惠。
这两个项目的成功都指向了一个核心逻辑：如果你从设计的第一天起，就深度考虑如何让建设发生，并利用工程思维去思考如何落地，那么任何复杂的设计或极高的标准都是可以负担得起的。这种从设计到施工的集成，就是我今天要深入拆解的效率密码。

作为一个软件公司，达索系统诞生于1981年的飞机制造世界。我们在那个时候就建立了一个信仰：虚拟孪生（VirtualTwin）。很多人经常问我，Marion，虚拟孪生和BIM有什么区别？毕竟大家看到虚拟孪生时，第一反应往往就是一个三维模型。
想象一下，BIM就像是一张非常精细的快照，它告诉你这栋楼“长什么样”。而虚拟孪生，除了告诉你它“长什么样”，还涵盖了两个至关重要的维度：它“如何被建造”的过程数据，以及“谁”在什么时间对什么部分负责。
在虚拟孪生的世界里，每个人都有自己的视角。为了让协作顺畅，我们不需要每个人都去盯着一个包含所有信息的超级模型。因为那样会导致信息过载，你会浪费大量时间去剔除那些你根本不需要的杂讯。我们追求的是一种“数据各司其职”的优雅状态。
为了说明这一点，我们来看一根普通的梁。如果你去问不同的人，他们对这根梁的看法完全不同。建筑师关心的是这根梁的位置是否影响美观，尺寸是否符合空间布局；而结构工程师则盯着强度、重载密度以及合规性，这是他们的生命线。
到了施工经理这里，视角又变了。他不关心那些复杂的受力计算，他关心的是：这根梁怎么运进场？怎么和其他工作包协调？今天的供应能不能到位？这就是为什么LOD（详细程度）不应该只是一个随时间推进的单一指标，而应该是基于职能的视角切换。

在传统的BIM流程中，我们经常看到人们试图往一个模型里塞进几千个属性。这种“单体式（Monolithic）”的方法往往是灾难性的。我们总是在想，这么多的数据最后真的会被用到吗？还是仅仅成了管理者的负担？这种做法其实是在扼杀每个职位的自由度。
我们提出的是一种更聪明的方法：让每个人都拥有自己的“真相版本”。这并不意味着这些真相是冲突的，而是每个人都基于自己的专业知识对元素进行解释。我们要做的，是建立一种连接机制。比如在施工阶段，我可以引用上游的建筑模型，但我并不直接修改它。
作为施工方，我会在这个基础上补充我特有的信息，比如混凝土的标号，或者特定的施工步序。这些信息是我拥有的，我不需要别人替我输入。当上游的设计发生微调时，我希望系统能够根据我预设的规则，自动更新我的施工数据，而不是让我手动重做一遍。
这种自动化的核心在于“规则数字化”，也就是基于规则的自动化（Rule-based Automation）。我们开发了一些数字代理（Agents），它们就像是施工现场的虚拟助手。如果我决定采用预制施工法，我的代理就会自动根据这种施工逻辑去深化模型。即便原始的设计模型里没有这些细节，我的系统也能自动补充出来。
这样做的最终目的，是为了释放人的创造力。我们通过自动化和对承包商诀窍（Know-how）的资本化，把那些繁琐的数据准备工作交给机器。这样，施工团队就能把精力放在解决现场的实际难题上，而不是整天埋头在电脑前调整那些琐碎的参数。
我们发现，施工中的很多问题都发生在“接口”处。比如两个工作包的交接，或者是某种特殊材料的安装。这些细节往往是施工经理最头疼的地方。遗憾的是，目前大部分项目在处理这些细节时，依然依赖于打印出来的纸质图纸，因为数字化成本太高。
但现在情况不同了。我们认为基于代理的自动化技术已经到了可以大规模应用的阶段。我们把复杂的构造逻辑拆解成一个个小的组件，我们称之为“砖块（Bricks）”，也就是模块化施工逻辑单元（Modular Construction Logic Units）。这些砖块能够根据施工人员的习惯，自动衍生出他们需要的详细视图。

这就涉及到一种“翻译”的智慧。每个人都有自己理解数据的方式。如果你习惯通过某种特定形式的草图来理解节点，那系统就应该反馈给你那种形式。数字化不应该强迫人去适应机器，而应该是在后台自动完成所有的对齐、汇总和精确计算。
通过这种方式，我们可以在保证用户体验的同时，获得极其精准的信息流。无论是精确的工程量统计，还是详细的采购清单，都能从这些“砖块”中自动提取出来。这对于施工阶段的成本控制和调度安排来说，简直就是一种质的飞跃。

让我们深入聊聊进度调度（Scheduling）。如果你去过任何一个工地，你肯定见过那张巨大的、贴在墙上的进度计划表。施工人员喜欢在上面用马克笔涂涂抹抹，标出哪些完成了，哪些还没动工。这其实就是最原始的“现场状态数据采集”。
我们并不打算消灭这种直观的工作方式。相反，我们把这种精益施工（Lean Construction）的逻辑搬进了虚拟孪生中。你看到的界面可能依然很像那张熟悉的图纸，但它的背后连接着真实的BIM模型。当你勾选“今日浇筑某段墙体”时，系统正在后台进行复杂的计算。

系统会根据模型中精确的几何数据——考虑到墙体上的每一个开洞、每一处转角——自动计算出今日所需的混凝土精确方量。这种基于信任的自动化，让施工经理不需要再拿着尺子去核对。他只需要关注执行本身，而数据会自动流向它该去的地方。
更进一步，我们允许施工人员在执行过程中补充关键数据。比如某项任务的实际完成时间、具体的工时消耗、以及实际投入的劳动力资源。这些数据一旦输入，系统就能立即生成实时的KPI报告。这让项目管理不再是“事后审计”，而是变成了“实时洞察”。
这就是我们理解的虚拟孪生在施工中的具体应用：它是可访问的、可补充的，并且能以你喜欢的方式呈现。只有当数据对现场的人变得有用，他们才会去信任它、维护它。最终，这种准确性会回馈给整个项目，让每一个人都从中受益。

施工现场唯一不变的就是变化。我们都知道，即使准备得再充分，变更也总是不期而至。这通常是模型管理团队最痛苦的时候：一次小小的设计微调，可能意味着要重新调整几十张图纸、重新计算上百个预留孔的位置。
我给大家展示一个具体的例子。假设上游设计师决定移动一个窗户的位置。在传统的连接模式下，这可能导致所有的施工准备工作作废。但在我们的连接模型中，系统会自动捕捉到这个变化，并询问你是否同意按照预设规则进行同步更新。
当你点击确认后，魔法就发生了。系统会自动重新生成电梯预留孔图纸、钢筋排布图以及最新的施工指令。所有的产出物都是基于那个连接的输入数据自动衍生的。你不需要花费数小时去重新绘图或核对，你只需要扮演好那个“控制者”和“决策者”的角色。
上游修改 → 触发预设规则 → 自动更新关联视图（如预留孔图纸） → 施工方确认生效，这种管理变更的方式，本质上是把低价值的重复劳动交给了机器。我们坚信，在施工项目中，连接不同职能的好处应该体现在每一个细微的调整中。这种基于连接模型的方法，让从输入数据到交付物产出的过程变得透明且高效，这是施工成功的关键。

刚才我们讨论了很多技术层面的细节，但要让这一切发生，还需要一种方法论。我们不能指望所有人突然之间就变得默契十足。我们需要一种机制，让每个利益相关者都能理解彼此的约束条件。
很多时候，我们在工作中无意中给别人制造了麻烦，但我们自己却并不知道。为了解决这个问题，我们会组建一个核心团队，让工程设计、施工执行、现场监督甚至采购部门的人坐在一起。我们要讨论的是：什么是对你至关重要的数据？这种变化会对你产生什么影响？
我们把这种流程称为“基于模型的设计（Model Based Design）”。这不仅仅是画个模型那么简单，它是对业务逻辑的数字化形式化。我们会制定一系列的规范、约束和规则。什么时候你可以做决定？什么时候你必须停下来咨询下游的意见？
通过这种前置的沟通，施工团队可以非常早地向工程团队反馈：嘿，这段跨度太大了，我们现有的吊装设备处理不了；或者，这个设计无法被施工。这种反馈闭环能极大地减少后期的返工成本。我们追求的是一种“在虚拟世界里错千百次，在真实世界里一次成功”的状态。
这种方法论最终会体现在不同级别的详细模型中。这就好比我之前举的那个技术竖井的例子。通过MBSE，我们明确了不同层级模型之间的链接关系。每个人都只处理自己专业范围内的数据，但通过云端的连接，整个项目像一个有机体一样协同运作。

现在，得益于云技术，我们可以把这些复杂的协作链条串联起来。在以前，要连接这些不同的数据流是非常困难的，但云端环境改变了游戏规则。每个人都可以只分享他们想分享的信息，保护好自己的核心知识产权（IP），同时又不影响整体协作。
让我们来看看Victor的故事。Victor负责技术竖井的具体实施。因为他需要采购每一个细小的组件，所以他需要访问极其详尽的模型细节。他甚至需要通过模型向现场工人演示：看，这个阀门应该这样安装。对他来说，详尽的数据就是生产力。
而Zavier的情况完全不同。Zavier负责整个建筑的结构。他不需要知道技术竖井里每个螺栓的型号，他只需要知道竖井的位置、尺寸以及它是否会和他的钢筋发生冲突。所以，当Zavier登录系统时，他看到的只是一个简化的、用于协调的综合视图。
这就是云端协作的魅力：按需分配。我们不再需要把一个巨大的、打不开的文件传来传去，而是通过动态的连接，让数据在最合适的人手中发挥最大的价值。无论是Victor需要的微观细节，还是Zavier需要的宏观视角，都在同一个云端孪生中和谐并存。

主持人Aiden：谢谢Marion，非常感谢你的演讲，非常有趣。我想谈几个话题。第一个是云环境的普及，你如何看待它在未来发展方面的作用？你认为在未来一两年内，随着云变得更加普及，它可能会在CDE中的信息访问和信息流方面带来什么？
Marion：如果说过去五年我们解决了“数据获取”的问题，那么未来两年的关键词一定是“信任”。
现在获取数据已经不是难事，但难的是你敢不敢相信你拿到的数据。尤其是在现场这种高压环境下。我认为我们应该致力于建立更好的数据治理和质量控制体系。云技术为我们提供了访问的便利，但我们需要建立起那种“易于访问且值得信赖”的行业信誉。

Aiden：这也许引出了我的下一个问题，达索系统如何看待标准化在建立这些访问、信任以及通过CDE的数据可访问性方面的作用？显然buildingSMART国际组织开发标准，你如何看待我们在确保这成为可能方面所扮演的角色？
Marion：虽然我今天开了个 CDE 的玩笑，但我非常尊重 buildingSMART 的标准工作。标准是共同语言，没有它我们根本没法对话。但我认为标准之上应该有“分支”。每个公司都有自己的“烹饪秘诀”，也就是他们的 IP。我们应该在保护这些秘诀的同时，使用标准语言进行交流。

Aiden：你认为LOIN（信息需求层级）能在未来几年内集成到你们的3DEXPERIENCE解决方案中吗？信息质量控制如何实现？
Marion：关于 LOIN（信息需求水平）的集成，我们也已经在 3DEXPERIENCE 解决方案中提供了这种切换能力，帮助用户在概念模型和详细模型间无缝流转。
我们也有IP保护，我们相信需要在'我想分享'和'我有自己的烹饪方法'之间找到平衡。"
如果你想让人们使用这个配方，你需要信任它。对我们来说，我们客户的IP是我们最信任的，在某种意义上，他们拥有的所有这些知识，如果他们将其数字化，我们需要找到一种方式让他们分享它而不分享这些知识。他们只需要分享结果。
这就是IP保护，让模型工作，但同时只是隐藏一小部分，也就是核心IP，这样即使你自动化了，每个利益相关者的IP仍然受到保护。而不是因为你自动化了，你就必须创建完全断开连接的东西来让它发送到世界各地。

Aiden：谢谢。之前分享了一些标志性的建筑项目，有其他真正具有挑战性的标志性项目使用达索系统CDE吗？如果有，你能列举一些吗？
Marion：Frank Gehry在使用它。你是否知道北京大兴国际机场？是Zaha做的。这就是典型的标志性项目。CATIA的信念是你可以塑造任何东西。我们现在正在做的是协调这种一次性建造，通过自动化、资本化，让它适用于所有类型的项目。

Aiden：北京大兴国际机场非常漂亮，设计得非常美。下一个问题是，基于进度的图纸显示，文件大小会不会过度膨胀？你如何保持文件大小的可管理性？
Marion：关于进度安排的文件大小。我们做的工作是，你可以看到在右下角，人们可以在进行规划时放大，在进行报告时缩小。这通常是我们的做法。我们也会创建PDF提取报告。

Aiden：你对从资本支出（CAPEX）重点向设施管理资产管理的数字化转型有什么看法？考虑到生命周期成本的85%以上通常在运营支出（OPEX）中，信息管理CDE是否需要在任何项目的早期建立，以确保顺利过渡和生命周期有效性？
Marion：是的，完全正确的，这确实是一个痛点，因为 85% 的生命周期成本发生在运维阶段。我们正在帮助业主在早期就指定他们需要的数据。这样，当项目从建设移交给运营时，他们拿到的就是一份干净、精准、不多也不少的数字资产，而不是一堆毫无用处的数据垃圾。

Marion Senesi的这场演讲揭示了建筑行业数字化转型中一个经常被忽视但至关重要的环节：施工阶段的数据断层问题。
这不是一个新问题，但Marion提供了一个新视角。她没有将焦点放在技术本身的先进性上，而是放在了"人如何使用技术"这个更根本的问题上。
BIM技术发展了二十多年，我们已经能够创建极其精细的三维模型，能够在虚拟环境中模拟建筑的各个方面。但问题在于，这些精美的模型往往停留在设计师和工程师的电脑里，到了施工现场，工人们依然在用纸质图纸和卷尺工作。

当一个BIM模型包含上千个属性时，施工经理如何知道哪些数据是可靠的？谁填写了这些数据？这个人有没有资格和责任提供这些数据？
这就是为什么很多施工项目虽然会参考BIM，但所有关键信息还是要根据承包商的图纸重新核对、重新填写。这种重复劳动的根源，就在于缺乏对数据来源的信任。
达索系统提出的"虚拟孪生"概念，试图从根本上解决这个问题。
虚拟孪生不是一个模型，而是一个生态系统。在这个生态系统中，每个参与者都有自己的"真相版本"，但这些版本是相互关联的。建筑模型、工程模型、施工模型是独立但互联的实体。

施工模型可以引用上游提供的关键信息（因为这些是必须遵守的约束），但也可以添加自己独有的元素（比如具体的施工方法、供应商选择等）。当上游发生变更时，下游可以自动感知并更新，但这种更新是可控的、可追溯的。
这种方法的核心是"翻译"而非"替换"。上游提供的是他们的真相（设计意图），下游需要的是自己的真相（施工方法），系统的作用是在两者之间建立可靠的映射关系。
建筑行业的数字化转型，走到今天这个阶段，已经不再是"要不要数字化"的问题，而是"如何数字化才能真正有用"的问题。
Marion的演讲给出了一个答案：不要追求一个包罗万象的超级系统，而要建立一个灵活、可信、高效的协作生态。在这个生态中，每个人都能以自己最熟悉的方式工作，同时贡献于共同的目标。

正如Marion在演讲开始时说的那个"陷阱"标题：让我们谈谈CDE——施工数据环境。她想强调的不是术语的对错，而是对施工阶段的重视。
因为无论设计多么精美，工程多么精确，如果无法顺利施工，一切都是空谈。
而虚拟孪生技术，正是要将"如何建造"这个问题，从现场的临场发挥，变成设计阶段就要认真思考的核心议题。
这是一个思维方式的转变，比任何具体的技术创新都更加深刻。
当施工经理能够像飞行员信任驾驶舱仪表一样信任BIM数据时，当现场工人能够通过熟悉的界面获取精确的施工指令时，当变更管理能够自动化、可追溯、低成本时，建筑行业才真正进入了数字时代。