Vibe随想 | 在AI时代把工程数据留在自己手里,把积累带向未来

你好，吃饱了没？

最近在想一件事：假如明天的 AI 又聪明了一大截，它来到我们的项目里，能接着今天的工作往下做吗？

打开文件夹，模型有好几版，图纸有好几套，问题记录在表格里，修改原因留在聊天记录中。老师傅知道这里为什么要绕，协调人员记得那个方案为什么被否决，可这些判断，未必跟着成果一起留下来。

这让我越来越在意：我们每天做的工作，能否成为自己真正持有、持续使用的数字资产？

我正在探索的一个方向，是在开放标准下构建开放的 CDE。推动我做这件事的，是一个朴素的愿望：好的 AI 产品，应当把人从重复、枯燥的劳动中解放出来，让时间回到设计、判断、沟通，以及生活中那些有意义的事情上。

CDE 是 Common Data Environment 的缩写，中文可称为“共用数据环境”。简单说，就是让项目各方按照共同约定，收集、管理和共享模型、图纸、文档等信息的工作环境。

如果你用过 OA，可以借它来理解 CDE：OA 帮助我们组织日常办公中的申请、审批和文件流转；CDE 则围绕工程项目，组织模型、图纸和技术资料的协作。

比如一张图纸，除了知道谁审批了，还要分清它对应哪一版模型、当前能用于专业协调还是施工，以及修改后会影响哪些相关资料。CDE 包含软件工具，也包含管理规则和协作流程，可以由多个系统共同支撑。

项目从设计走向施工、运营，会换团队、工具和关注的问题。信息如果只能在特定软件里被理解，每次交接就得重新解释、整理，积累也难以延续。

openBIM，可以理解为基于开放标准的 BIM 协作方式。设计、施工、运营各方可以使用不同软件，按照共同约定交换和使用工程信息。它强调的是跨工具协作和信息长期可用。

在我看来，openBIM 是建设工程实现数据自持有、维护数据主权的最佳路径。

这里的“持有”，包括保存数据，也包括持续读取、维护、迁移它的能力。项目各方依据约定，能够决定数据交给谁、用于什么工作，更换软件或服务商时，仍能接续自己的积累。

开放标准提供了共同的表达基础，让模型、属性和关联记录有机会沉淀为标准化的数字资产。这份资产的长期价值，需要超越某款软件的使用期限。

IFC 为对象、属性和关系提供共同定义，帮助不同工具理解同一份工程信息。^[1]

最近关注下一代 IFC 的演进，也让我想到这一点。2026 年 8 月，buildingSMART 公布了 IFCX 核心与模块化项目计划获批的进展，目标是建立精简、模块化、可扩展的数据基础。这是项目推进的节点，距离成熟应用还有工作要做。^[2]

在 IFCX 的探索中，值得关注的是，不同参与方如何围绕共同的对象补充信息，再把这些贡献组合起来。官方早期示例已经展示了分层组合的思路，但仍用于探索和测试。^[3]

说到 CDE，很容易先想到一个集中存放模型和文档的平台。我更在意的是，资料进入以后，能否带着明确的身份、版本、状态和用途，继续参与工作。

模型、图纸、问题和复核记录之间的关系留下来，信息才有机会在不同环节之间接续。

openCDE 提供公开的 API（应用程序接口）标准，约定软件如何交换文档、版本信息和协调问题。平台实现并开放相应接口，就为个人工具、工作流和智能体（Agent）接入企业与项目公共 CDE 提供了基础。“公共”指授权参与方共用，访问仍受权限管理。^[4][5][6]

个人智能体可以通过适配工具访问开放 API，也可以借助 MCP（模型上下文协议）连接平台能力。例如，将文档查询、版本核对、问题提交等 API 封装成 MCP 工具，让智能体按任务调用。^[7]

进一步，个人智能体还可以与企业或项目智能体交换任务、进度和结果。这样的通信需要另行约定协作机制；openCDE 负责工程信息交换，MCP 支持工具与上下文接入，任务如何分派、复核和交接，则由协作流程组织。

开放还要经得起迁移检验：离开平台，工程参与方能否带走约定范围内的数据、关系和历史，并继续使用？与之又衍生出该如何从系统层面约束数据权限和范围等问题。

网络安全需要从平台架构开始考虑：加密传输、身份认证、项目间隔离，以及对外部连接和数据外发的控制，都应落实。开放接口的访问范围，要与项目保密要求相适应。

对 Agent，要明确它代表谁、正在执行什么任务、能读取哪些资料、能调用哪些操作，并按任务给予最小权限。读取、修改、删除和正式发布分别授权，关键操作经过审批，任务结束后收回临时权限。MCP 接入也要遵守这些边界，平台服务端应校验每次调用。^[8]

这也是我理解的 CDE Harness 化：在平台内部建立组织和约束 Agent 运行的机制。管理智能体的身份、任务、工具清单和执行状态，按项目隔离上下文，记录调用过程与结果；越权或异常时能够中止任务。内部 Agent 同样需要受控，外部 Agent 交来的内容也要经过校验，文档中的文字不能变成扩大权限的指令。

Harness 负责组织执行，权限由平台落实，成果经过检查和必要复核。这样，内部智能体和个人智能体的协作，才有可追溯、可撤销授权的管理基础。^[9]

一次管线调整，除了最终位置，还应留下问题对象、适用条件、方案取舍和复核结果。检修空间、施工顺序等考虑跟着记录留下来，后来的人和 AI 才更容易理解当时的判断。

这些数字资产，也能成为 AI 的养分。可以先让 AI 在授权范围内查阅和使用资料，分清来源与版本，遇到缺口时知道还缺什么。是否进一步用于训练，则应另行明确用途和授权。工程参与方需要保有这种选择权。

当然，标准化也有它需要耐心的地方。两个团队用了同一个字段，未必理解一致；一次成功的处理，也未必能直接搬到另一个项目。适用条件和例外，需要跟着经验一起留下。

我希望设计师能把更多精力放在设计本身：推敲空间、比较方案、解决真实需求。重复填参数、转换格式、搬运资料这些工作，应当尽量交给工具处理，让符合要求的数据随着设计过程自然形成。

现场人员需要核对一段管线时，我希望他用手边的手机或平板，就能轻松找到对应模型、图纸和问题记录，看清版本与状态。为了看一眼模型，背着沉重的笔记本去现场，再等软件启动、文件加载，这些负担值得研发去消除。

如果每增加一项能力，就要求现场再学一个软件，工具就把衔接的麻烦留给了人。我的期待是，信息流通得更自然，需要时触手可得，现场人员能够把注意力留给眼前的工程。

研发可以据此衡量：重复录入和系统切换是否减少，查找资料是否更容易，检查是否可靠？确认后的结果回到 CDE，才能成为下一次可用的积累。

对于行业发展，先把共同的规则建起来。

在已有开放标准上，逐步对齐对象分类、属性含义、单位和交付要求，让不同企业、软件之间有共同语言。专业场景需要扩展时，也把定义和映射关系说明白，减少重复造轮子。

还可以围绕真实交付，形成可公开的样例、检查规则和跨软件验证方法。换一个工具，信息能否正确接续，要拿结果验证。让项目中的问题回到标准完善和软件改进中，行业才能共同积累。

对于企业，把项目经验沉淀为自己的数字资产。

从高频业务入手，搭建标准数据，梳理工作流和生产标准化路径：输入是什么，经过哪些处理与复核，产出什么，怎样验收，异常如何处理。把这些要求逐步落实到模板、规则库和工具中，并安排持续维护。

企业和项目的公共 CDE 平台，应开放符合 openCDE 标准的接口，按需提供 MCP 工具。验证互通和迁移能力的同时，明确安全管理责任、Agent 接入审批与内部运行边界，让个人工作流有序接入。

对于个人，把“我会做”整理成能够复用的方法。

从一类数据、一段流程或一次判断开始，写清依据、条件、步骤和例外。比如“检查信息是否完整”，可以拆成哪些对象必须具备哪些属性、取值范围是什么、缺项如何反馈。

我希望更多工程人通过 VibeCoding，开始搭建属于自己的自动化，再把它对接到企业和项目公共 CDE 平台的自动化流程中。 从每天反复整理的一张表、一次属性检查做起，把需求和判断依据讲给 AI，协助自己编写、调试工具，再用真实样例检验结果。专业经验越能说清楚，工具就越有机会做对；生成的程序，也需要自己核对。

个人自动化可以通过平台开放的 API 接入，个人智能体则可以借助 MCP 工具，取得获准的模型文档、执行检查并提交问题，再由平台的自动化流程或项目智能体接续分派、复核和归档。让自己顺手的方法进入团队工作流，经验便能在一次次使用和修正中，逐渐沉淀下来。

行业建立共同规则，企业组织持续积累，个人贡献专业方法。 三者接起来，经验才能被团队复用、被程序执行、被 AI 在合适的任务中调用，持续反哺工程。

我还无法确定，几年后的工程软件会长成什么样。但我清楚自己希望它为谁服务：那些每天设计、协调、检查和建设的人。

以开放标准维护数据主权，把积累变成数字资产，再让 AI 帮助工程人更轻松地使用它们。这条研发路线最终要回到人的感受：设计师能专注设计，现场能轻松看懂模型，大家少一点重复劳动，多一点时间处理真正重要的事情。

让工程人把时间用在值得的地方，是我想继续做下去的理由。🍜 ✨

参考资料

【1】buildingSMART IFC 介绍

【2】buildingSMART IFCX 项目进展

【3】buildingSMART IFCX 开发示例说明

【4】buildingSMART Foundation API

【5】Documents API

【6】BCF API

【7】MCP 官方架构说明

【8】MCP 授权安全说明

【9】《Harness 对 CDE 构建的启示》