“车门内板的最新数模发我一下。”
“PLM里有，你直接下载就行。”
“系统里那个是最新的吗？”
“还不是。我昨天为了避让玻璃升降器，
又改了3mm，还没发布。”
“那你先在群里发我吧，我装进去看看。”
这段对话，很多汽车研发工程师都不陌生。
公司花了很多钱建设 PLM。
图纸进系统了，EBOM 进系统了，
版本、权限、变更和发布流程也都管起来了。
但工程师真正开始设计时，
最新数模可能还在某个人的电脑里。
于是，一个看起来很矛盾的现象出现了：
企业的数据管理越来越规范，
工程师却仍然依靠“人找人”完成协同。
这并不一定说明 PLM 没有价值。
它更可能说明，
企业已经解决了“正式研发结果如何管理”，
却还没有真正解决：
在整车研发过程中，
各专业如何基于不断变化但彼此关联的产品状态协同工作。
01、一个 3mm，为什么不是一个零件的问题？
假设车身工程师为了避让玻璃升降器，将车门内板的局部结构向内调整了 3mm。
对他来说，这可能只是一次普通修改。但这 3mm 可能同时影响：
玻璃升降器的运动空间；
线束和连接器的布置；
扬声器的安装位置；
车门内饰板的局部结构；
密封条的压缩状态；
装配工具的操作空间；
供应商正在设计的支架。
如果内饰工程师拿到的是前天的车门内板，线束工程师使用的是昨天的状态，供应商手里又有一份通过邮件发送的数模，问题就出现了。每个人都认真完成了自己的设计。每个零件单独检查也可能都是正确的。却发现装不上了。这就是整车研发中最典型、也最容易被低估的问题：零件正确，不等于整车正确。复杂产品真正困难的，从来不只是把一个零件设计好。而是让车身、内外饰、电气、软件、CAE、工艺和供应商，始终基于彼此正确匹配的产品状态工作。所以，这 3mm 不只是一个尺寸问题，也暴露了状态同步问题。如果各方未能基于彼此正确匹配的状态协同，它就可能进一步引发空间、接口、性能和制造问题。
02、 “最新”不是每次保存都通知所有人
问题似乎很简单：工程师修改数模以后，立即同步给所有相关人员，不就可以了吗？现实中并没有这么简单。汽车研发本身就是一个不断探索的过程。车身工程师上午把结构向内移动 3mm，下午发现刚度不足，可能又改回 2mm。第二天经过 CAE 分析，又增加一条加强筋。再过一天，工艺提出圆角半径不利于冲压成形，局部结构还要继续变化。其中很多状态只是临时尝试，并不值得所有人立即跟进。如果每次保存都通知相关人员，工程师一天可能收到几十次甚至上百次变化。大家很快就会被无效信息淹没。但如果一直等到数模正式发布以后再通知，其他专业又可能已经基于旧状态工作了几天。所以，真正的协同并不是：让所有人随时看到所有数据。而是：让正确的人，在正确的时间，看到对自己有意义、并且可以被依赖的变化。系统不仅要知道数模变了，还要理解：
变化发生在哪个区域；
可能影响哪些零件、接口和专业；
谁正在进行修改；
当前状态是个人尝试，还是团队可以共享的方案；
它能否进入整车集成；
下游是否可以把它作为工作依据。
这比简单地问“哪个文件时间戳最新”困难得多。
03、为什么传统 PLM 更擅长管理研发结果？
一款汽车定型并进入量产后，企业大部分时候执行的是一个相对确定的过程。使用什么零件、按照什么工序、采用什么设备、达到什么质量要求，这些内容应该尽可能稳定、标准、可信和可重复。但新车型研发完全不同。项目开始时，很多答案本来就是未知的。
车身结构能不能继续减重？
碰撞性能是否满足要求？
电池包布置会不会影响乘员空间？
线束能不能通过？
冲压和焊接工艺是否可行？
为什么要做方案 A？因为不知道借用的总成到底行不行。
为什么又要做方案 B？因为仿真或者试验发现借用总成存在问题。
为什么设计做到一半又推翻？因为总布置、CAE、工艺或者供应商提出了新的约束。
所以研发的本质不是按照既定流程执行一个已知答案，而是：不断提出方案、验证方案、否定方案，最后逐渐找到答案。研发过程数据因此天然具有几个特点：临时、不完整、快速变化、存在分支、可能相互矛盾，而且大部分最终会被淘汰。
企业受控系统偏好的数据则完全不同：稳定、结构化、状态明确、责任清楚、可以审批、可以追溯。这就是很多 PLM 建设中的根本矛盾：企业想要“管”，工程师需要“试”。当企业试图用正式零件、完整属性、升版、变更原因、配置关联和审批流程去管理每一次尝试时，治理成本很快就会超过工程师能够接受的程度。然后，工程师会做出最现实的选择：先保存在本地。等方案基本稳定以后，再放进 PLM。企业原本希望通过加强管理获得更多过程数据，最后反而把过程数据赶出了系统。
04、整车研发天然存在两个数据空间
一个车型的研发过程，天然存在两个不同的数据空间。第一个是探索空间。这里允许快速试错、频繁修改、方案分叉、临时数模、不完整数据和个人判断。它追求的是低摩擦。
第二个是企业受控空间。这里要求零件对象唯一、车型配置明确、版本和成熟度可信、责任清楚、经过审核，并且能够作为采购、试制和生产的正式依据。它追求的是高可信。问题不在于企业应该选择哪一个空间。真正困难的是，在两者之间建立一条既清晰、又不过度沉重的路径：
个人探索状态；
专业团队可共享状态；
整车集成工作状态；
可供下游使用的设计基线；
企业正式发布状态。
不同状态对应不同的可信程度，也对应不同的使用范围。企业不需要把工程师每一次鼠标操作都纳入正式治理。但企业必须能够判断：什么仍然在探索，什么已经值得协同，什么可以被其他专业依赖，什么能够进入整车基线，什么最终成为正式产品定义。
05、真正有价值的，不是保存了多少个版本
不是所有研发过程数据都具有长期管理价值。一名工程师一天可能保存几十次数模。其中很多只是“试一下”“看看效果”“发现不行”“立即撤销”。如果企业把所有状态都永久保留，得到的可能只是更多文件，而不是更多知识。真正值得沉淀的是：
为什么选择这个结构；
为什么放弃另一个方案；
哪一次 CAE 分析推动了设计修改；
哪个碰撞、NVH 或刚度指标否决了方案 B；
哪个冲压或装配约束改变了原有设计；
哪些专业和供应商受到影响；
团队何时认为这个状态可以进入整车集成。
增加版本数量，最多只能告诉企业发生过变化，却无法解释为什么变化。这也是为什么很多企业的 PLM 中保存了几百万份文档，新工程师接手一个车型时，仍然要去找老工程师问：“当年为什么要这么设计？”数据还在，图纸还在，最终数模也还在。但形成这个结果的上下文已经消失了。
06、工程师需要的不是文件，而是整车设计上下文
车门工程师真正需要的，从来不只是一个车门内板文件。他还需要看到白车身门洞、铰链和限位器、门锁、玻璃及其运动包络、密封条、内饰板、线束、扬声器，以及不同车型配置下的差异。这些对象共同构成了车门系统的设计上下文。
过去，工程师需要自己寻找这些信息：查 EBOM、找数模、问同事、下载文件、拼装临时总成，然后再问一句：
“这些都是最新的吗？”
在真正的协同研发环境里，系统应该直接告诉他：
与当前零件相关的周边数模是什么；
它们处于什么版本和成熟度；
当前适用于哪个车型配置；
谁正在修改；
哪些状态可以用于参考，哪些可以被下游依赖；
最近的变化影响了哪些空间、接口和分析结果。
工程师不一定需要拥有所有数据。但他必须知道：自己正在基于怎样的整车状态开展设计。数字样机审核也不应该只在项目节点做一次“期末考试”。数模每天在变化，整车集成检查也应该持续进入设计过程。当某个变化可能影响空间、接口、性能或者制造可行性时，相关专业应该尽可能早地发现。因为汽车研发有一个非常朴素的规律：问题发现得越晚，牵连的专业越多，修改成本越高。
07、3DEXPERIENCE 真正要连接的，是两个世界
讲到这里，就能理解达索系统 3DEXPERIENCE 平台的价值所在。业内常把它简称为 3DE。它不是简单地给传统 PLM 增加一个更大的文件库，也不是要求工程师把每一次保存都变成正式发布。它真正试图建立的是一个统一的协同环境：把人员、产品数据、配置、任务、问题、变更、数字样机、仿真和制造上下文连接起来，让探索过程与企业治理不再是两个彼此断裂的世界。在这个环境中，“实时在线管理过程数据”至少意味着五件事。
第一，过程状态不必等到正式发布才进入团队视野
在制数据可以留在受控的在线环境中，相关人员能够按照角色和权限看到必要状态，而不是等工程师通过群聊发送副本。
第二，所有人看到的不是同一个“最新”，而是适合自己的“可信状态”
个人探索、团队共享、整车集成和正式发布可以具有不同成熟度。系统需要控制谁能看、谁能改、谁可以依赖，而不是简单地用文件时间戳决定一切。
第三，数模不再脱离配置和产品结构独立存在
工程师看到的不只是一个 CAD 文件，而是它在具体车型配置、产品结构和整车上下文中的位置，以及它与周边对象的关系。
第四，数字样机和仿真可以更早进入迭代过程
当 CAD、BOM、配置、数字样机和仿真结果处在连续的数据环境中，整车审核就可以从节点式检查转向更持续的验证。
第五，企业开始有机会沉淀“为什么这样设计”
当问题、评论、分析、任务、变更和决策都围绕同一个产品上下文发生，AI 才有可能进一步识别设计为什么变化、影响了谁、哪项分析推动了决策，以及团队如何形成共识。
所以，3DEXPERIENCE 是在把 PLM 从“正式结果的管理系统”，演进为“整车协同研发的工作环境”。
08、蔚来、小米、小鹏，为什么都在走向同一个方向？
这并不是一个停留在概念层面的东西。中国头部新能源汽车企业的公开案例，已经展示了平台如何真正进入研发现场，并持续支撑整车业务。
蔚来、小米、小鹏三家智能电动车企的 3DE 研发平台均由钛闻参与实施交付，覆盖研发数据管理、协同研发、历史数据迁移、工艺流程及供应商协同等业务环节。
蔚来：10 年持续演进，让过程数据与发布数据进入同一平台
蔚来汽车自 2017 年起稳定运行 3DE 平台，并在 2022 年完成大版本升级，将协同范围进一步扩展至供应商，支撑 3,000 多名研发用户开展全球协同。在这个平台上，中国、德国和美国的工程师可以协同开展新产品和设计工作；合作伙伴能够接入，相关角色可以访问同一份产品数据，无论它处于 设计过程状态，还是已经正式发布。过程数据可以在线、可见、可协同，同时仍然通过角色、成熟度、配置和流程保持清晰边界。
小米：2 个月，让协同设计从项目启动走向上线
小米汽车自 2021 年启动汽车业务后，选择 3DEXPERIENCE 以及新一代 CATIA、DELMIA用于实时、多专业、配置化的产品开发，并连接硬件与软件研发流。从项目启动到 CATIA V6 协同设计版块上线，仅用了 2 个月时间。
小鹏：5 个月，上线整车研发业务全流程
2025 年，小鹏汽车选择 3DEXPERIENCE 平台，并与达索系统建立战略合作，以加速数字化研发、加强跨职能协作、改善开发效率与上市周期。在项目实施过程中，企业用 5 个月完成了历史数据迁移、周边系统衔接及整车研发业务流程上线。对于大型汽车企业而言，存量数据和周边系统的解耦迁移往往是转型中最复杂的部分。小鹏项目说明，平台价值已经不只是 CAD 工具层面的提效，而是进入跨专业研发、历史资产承接和企业级协同体系。
要让这些平台能力真正落地，除了平台本身，还需要实施团队完成流程、数据和组织层面的连接。从小米 2 个月快速上线，到小鹏 5 个月完成整车研发流程切换，再到蔚来 10 年持续升级演进，钛闻交付的不只是软件系统，而是一套能够快速落地、持续扩展的汽车研发数字化方法。平台决定协同能力的上限，实施决定这些能力能否真正进入研发现场。当汽车研发速度越来越快、跨专业耦合越来越深，企业既需要统一的 3DE 平台，也更需要能够把平台、流程、数据和组织真正融合起来的专业实施伙伴。
09、PLM 的下半场：从管理产品数据，到沉淀决策上下文
汽车研发的数字化，下一阶段不应该只回答：“这辆车正式是什么样？”它还应该逐渐回答：“为什么最终把它设计成这样？”
过去，这个问题很难回答，因为工程师没有精力把每一次修改、每一个分析结果、每一场评审和每一个供应商约束手工结构化。未来，当过程数据在统一平台中持续积累，AI 才可能从数模变化、CAE 结果、数字样机问题、设计评论、任务记录、评审结论和工程变更中，自动识别设计决策形成的上下文。那时，企业沉淀下来的不再只是最终图纸、数模和 EBOM。还包括：我们为什么最终把这辆车设计成这样。这意味着 PLM 要从管住研发结果转到沉淀研发知识。
回到文章开头的那句：“最新数模谁有？”表面上看，工程师只是在找一个文件。但它真正暴露的是：企业还无法把正确的整车研发上下文，在正确的时间交给正确的人。真正的数字化，不是让数模存放在系统里。而是当整车发生变化时，相关人员能够及时理解变化，判断变化是否值得跟进，并继续基于彼此关联的状态工作。这正是 3DEXPERIENCE 等最新一代协同研发平台希望解决的问题。也是汽车企业从“管住研发结果”，走向“在线管理研发过程、应用和沉淀研发知识”的关键一步。
钛闻软件专注于制造业研发数字化及达索系统3DEXPERIENCE平台的咨询与实施，曾参与蔚来、小米、小鹏等车企的研发平台建设。如果你也在关注研发协同、过程数据管理或PLM落地，欢迎在评论区留言交流。
关于钛闻软件
上海钛闻软件技术有限公司源自于上海江达科技发展有限公司，自2024年1月1日起，钛闻软件全面承接上海江达的人员、业务和相关资质。
钛闻软件在全国设有7个办事处，拥有超过200余人的专家顾问团队和近30年的行业经验，公司致力于向交通运输、工业装备、基础设施、航空航天、高科技电子及生命科学等行业客户提供先进的数字化解决方案及企业级应用系统。
作为达索系统重要的合作伙伴，钛闻软件在中国拥有1700多家客户。这些客户长期使用达索系统从需求、设计、工艺、仿真到制造的全生命周期解决方案，总装机量超过30000多套。钛闻软件非常注重客户的实施服务和应用支持，紧扣客户需求，引入最佳实践，让先进软件发挥卓越价值。
