4.1 协同工作环境

4.1 协同工作环境

本节摘要：协同工作环境，通俗说就是"所有人在同一个信息场里干活"的地方。它的核心是 CDE（公共数据环境）——一个分了四层、权限分明、版本可追溯的信息仓库。这一节讲三件事：CDE 的四层分区怎么让信息一步步"毕业"、权限怎么控制"谁能动什么"、版本怎么管住"改了哪些、能不能回退"。读完你会明白，协同平台的关键不在云盘容量，而在它强制规定了一套信息流转和追责的规矩。

学习目标

阅读完本节，你应当能够：

1. 说出 CDE 和普通共享文件夹的本质区别
2. 画出 CDE 的四层分区，说清每层谁在操作、信息处于什么状态
3. 解释权限管理的三个维度：角色、区域、阶段
4. 说明版本管理里"版本收敛"和"血缘追溯"各自解决什么问题
5. 判断一个新项目该从哪层分区开始搭协同环境

一、从"共享文件夹"到"公共数据环境"

先讲一个很常见的场景。项目一开始，大家建了个共享盘，目录按专业分：建筑、结构、机电各一个文件夹。结构工程师改完梁，把文件存进去，然后在群里喊一声"新版梁模型好了"。机电工程师下载下来一看，发现梁底标高变了，自己刚排好的风管全撞上了。

问题出在哪？不是云盘不好用，而是这套"存文件、喊话、各自下载"的做法，本质上还是把模型当成一摞图纸在传。文件是死的，谁在什么时候改了哪一处、为什么改、改完影响了谁，这些关键信息全丢了。你只能看到"有一个新文件"，却看不到这个文件背后那串决策。

CDE（公共数据环境，Common Data Environment）要解决的正是这个。它不只是一个更大的云盘，而是一套信息治理的规矩：每个模型从草稿到正式交付，必须经过明确的几道门，每道门都有状态、有审核、有留痕。你可以把它想成一栋办公楼的收发室——不同的人从不同的门进来，文件按成熟度分层存放，签收和签发的记录都存在案。你什么时候想查"三月份那版结构模型是谁发的、发之前谁审过"，翻台账就有。

这个区别，决定了协同到底是"真协同"还是"假协同"。

💡 关键直觉：协同环境的核心不是"能存多少"，而是"能不能让所有人始终看到同一份可信的信息"。容量是最不值钱的指标，规则才值钱。

二、CDE 的四层分区：信息的一步步"毕业"

CDE 最常见的划分是四层，也有人简并成三层，但我更倾向四层，因为"归档"这一步在项目后期特别值钱——它直接决定运维阶段能不能接着用。四层分别是：临时工作区、协作主干区、正式发布区、长期保管区。

第一层是临时工作区。这是设计师自己的"画室"，自由度最高，可以随便试、随便改，改了不满意就回退。但这里的东西不算数——你没"发布"，别人就看不到，也不用看。很多人舍不得这一层，觉得"我直接传上去不就行了"，结果协作区堆满了半成品，谁也不知道哪个是能用的。

第二层是协作主干区。各专业把自己认为"能拿出去协调"的模型发布到这里，大家在这里对模型、查碰撞。这一层的关键是版本收敛：结构发了 2.1 版，建筑还停在 1.9 版，系统不会悄悄覆盖，而是把差异摆出来，让双方确认，或者由 BIM 经理裁定。这是四层里最热闹、也最容易乱的一层。

第三层是正式发布区。凡是交给业主、发施工指令、做阶段验收的东西，都从这里签发。这一层的内容被加了"封印"，不能再随便改，改一次就留一次记录。它的价值在于"法律效力"——拿到正式发布区的文件，才谈得上交付。

第四层是长期保管区。项目结束后，模型归档到这里，保证几十年后还能打开、还能读懂。它不管访问速度，只管"长久可读"。这一层常被忽略，但运维阶段的人最懂它的分量：楼都盖完了，图纸找不到了，模型又在哪。

四层的本质，是给信息一个明确的"成熟度刻度"。同一份墙模型，在临时区可能是 LOD 100 的概念体块，进了协作区要补上材质和洞口，到了发布区就得带着完整的防火等级和构造做法。信息不是一蹴而就的，它在四层之间一步步变"熟"，而每一层的门槛，就是一次质量的闸门。

举个完整的例子。一面外墙，建筑师先在临时区画了个 LOD 100 的体块，纯粹比划比例，谁也不用当真。他觉得方向定了，就把它发布到协作区，结构工程师在这上面加了梁柱关系，机电工程师标了穿墙套管的位置，幕墙顾问补了分格。这一版大家对齐了，碰撞也清了，就冻结进正式发布区，作为这轮设计交付给业主。项目结束，这面墙连同它经历过的十几个版本一起，归档进长期保管区——十年后要改造，运维团队还能把它翻出来，看当年每一版改了哪里。

三、权限管理：谁能动什么

CDE 分区解决的是"信息放在哪、处于什么状态"，权限解决的是"谁能动它"。传统共享盘里，权限就是"谁能编辑哪个文件夹"，一刀切。真到项目里你会发现不够用：同一个机电工程师，对 B 栋三层的管线有编辑权，对 A 栋地下室的管线只能看；同一批人，在"深化设计"阶段能改，到了"出图冻结"阶段就不能动。于是 CDE 的权限通常拆成三个维度来看。

第一个是角色维，也就是"你是谁、你的岗位允许你做什么"。结构工程师能改结构构件，不能动机电的系统定义；造价师能读工程量，不能改几何。这一层最直观，也最容易先定下来。

第二个是区域维，也就是"动哪块空间"。超高层项目里，同一专业的几个人可能各管几层，权限按楼层或分区切，避免两个人同时改同一面墙。这一层经常被漏掉，导致"我能改全楼"这种过度授权。

第三个是阶段维，也就是"什么时候能动"。方案阶段大家放开手脚，到了出图冻结，多数人只剩只读权，只有少数人有修改权，而且每次修改都要触发通知。

⚠️ 常见坑：三个维度只做了"角色"一个。区域和阶段没跟上，就会出现"权限给太宽、出了事找不到人"的局面。权限不是越严越好，而是越"恰到好处"越好——严到没人敢动，协同就死了。

拿一个机电工程师说。他平时能改自己专业的管线，这是角色维；但楼里空调机房那一块归另一个小组，他只有只读权，这是区域维；到了出图冻结之后，他连只读之外的修改权也没了，想改得发起变更申请，这是阶段维。三个维度叠下来，他每天能动的，其实是一小片"当下该他动"的地方。

三个维度合起来，规则是取"最小交集"：角色、区域、阶段同时放行，操作才生效。听起来复杂，但落到系统里就是一张权限表，配一次、复用一类项目。配权限这件事，最怕的不是配错，而是没人肯坐下来把"谁该动什么"说清楚——这又回到第 4.2 节要讲的角色体系。

四、版本管理：改动怎么追、怎么回退

分区管状态，权限管访问，版本管的是"时间"。一个协同项目每天可能产生几十次提交，没有版本管理，两周后你就说不清"现在主模型到底是哪个"。

版本管理的第一个作用，是版本收敛。多个专业同时改，各自产生了自己的版本，谁的是"主干"？靠的不是嗓门大，而是规则：要么双方对完差异签字确认，要么由 BIM 经理裁定并记下理由。收敛之后，协作区里永远只有一个"被共识过"的快照，而不是一堆版本拼贴。

这里有个典型场景：结构专业把核心筒的梁往上抬了二十公分，建筑专业的墙还按旧标高画着。两边各自发布了版本，系统一比对，标出这处高差。这时候不能静默覆盖——覆盖了，建筑的墙就悬空了；也不能放着不管。正确动作是把差异推给双方协调员，确认是结构改、建筑跟，还是结构改回去。定了之后，才算收敛。

第二个作用，是血缘追溯。任何一条属性值——比如某根梁的混凝土强度从 C30 改成了 C35——都能回溯到源头：是结构计算书要求的，还是业主技术规格书里写的，还是某次会议纪要拍板的。真到返工扯皮的时候，这条血缘线就是证据。

第三个作用，是回退。改错了，能沿版本线退回任意一个历史快照。但要注意，回退不是"删掉后来的一切"，而是"基于旧版本开一条新分支"，把这次回退也记下来。否则你回退了，别人不知道，又拿新版本接着干，乱上加乱。

这张状态图说的是单个文件的一生：草稿、已发布、已归档，中间来回几次退回修改，最后归档。把它铺到整个项目上，就是几百个文件各自走这套流程，再由版本收敛把它们焊成一份可信的模型。

五、一张图看懂协同环境架构

把前面三块——CDE 分区、权限、版本——叠在一起，就是协同工作环境的完整骨架。左边是信息按成熟度一步步"毕业"的四层分区，右边上半是权限的三维交叉，右边下半是版本沿时间线往前滚。三块不是并列的模块，而是咬合在一起：分区管"状态"，权限管"谁能动"，版本管"时间"。少了哪一块，协同都会变形：只有分区没有权限，谁都能动别人还没定的东西；只有权限没有版本，改了没法追溯；只有版本没有分区，大家分不清哪个文件是正式交付。三者凑齐，才谈得上"可信"。

图：协同环境架构——CDE、权限与版本的三层结构

这张图值得贴在协同平台首页。它提醒每个进场的人三件事：你手里的模型属于哪个区、你被授权动哪一块、你改的每一步都会被记在版本线上。真出了争议，回头查这三样，比翻十次会议纪要都管用。

本章回顾

• CDE 不是大云盘：它是一套信息治理规矩，靠状态、权限、版本三样把协同立起来。
• 四层分区是成熟度刻度：临时工作区、协作主干区、正式发布区、长期保管区，信息一步步"毕业"。
• 权限要三维看：角色、区域、阶段同时放行才生效，只做角色维最容易翻车。
• 版本收敛靠规则不靠嗓门：多方版本冲突时，摆差异、签字确认或由 BIM 经理裁定。
• 血缘追溯是证据：每条属性都能回溯到源头，返工扯皮时有据可查。
• 回退不是删除：沿版本线开新分支，把回退本身也记下来。
• 先定规则再谈工具：选哪款平台是次要的，先写清"谁负责什么、什么算交付完成"。

下一节我们把视角从"环境"转向"环境里的人"：CDE 再完善，如果 BIM 经理和各专业角色的边界没划清，规则照样没人执行。第 4.2 节就来讲组织与角色体系。