返回 BIM 与 IFC 博客
交付与 ISO 19650 · 2026-08-07 · 10 分钟
IFC 验收标准：如何不起争执地接收或退回模型
“这个模型根本没法用”对上“模型没问题”，这种争论永远没有尽头。在首次交付之前商定好一页纸的验收表，就能把它变成一次五分钟的检查，并留下有据可查的结论。
IFC 验收标准：如何不起争执地接收或退回模型 — IFC Viewer Online article cover
每个项目都会有这样一个时刻：协调员打开一份交付的模型，花了二十分钟才发现它没法用，然后写了一封以“很遗憾”开头的邮件。接下来会怎样，几乎完全取决于一件事：有没有人事先把“合格的交付是什么样子”写下来。
如果写了，这封邮件就会简短、客观，不会引起争议。如果没写，这封邮件就成了一场谈判的开局，争的是该用谁的标准，而且在项目余下的每个阶段节点上，这场争论都会被重新翻出来。
验收是一张检查清单，而不是个人意见
思路上的转变很小，却能改变一切。审核一份交付并不是在评估质量，而是把商定好的标准应用到一个文件上。这会带来三个值得明确指出的结果：
- 审核人除了那张商定的表格之外，不需要任何额外的权威。他不是在评判建模人员的能力，而是在报告一个结果。
- 建模方在提交之前就能预判结果。凡是能预判的，就能预防，这正是关键所在。
- 即便出现分歧，争的也是标准本身。这样的讨论可以心平气和地进行一次，而不是每个月在交付进行到一半时反复上演。
你不能因为一份交付不符合对方从未认可的标准而退回它；你只能因为它不符合双方都认可的标准而退回。
验收标准表
核心就是这张表：十行、一页纸，作为附件附在 BIM 执行计划（BEP）或信息交换要求（EIR）之后。第三列是故意留空的，由项目在首次交付之前填写，而真正的共识，正是在填写这一列的过程中达成的。
| 标准 | 出现以下情况即退回… | 项目约定 |
|---|
| 结构完整性 | 出现任何严重程度为“错误”的模式（Schema）或空间问题 | 退回 / 附说明接收 |
| Health Score（健康评分） | 低于商定的阈值 | 阈值：__ /100 |
| 检查覆盖 | 有任何检查被报告为未运行或运行失败 | 退回 / 要求重新运行 |
| 标识符稳定性 | 两个版本之间的 GUID 变动率超过商定比例 | 最大变动率：__ % |
| 命名 | 文件名不符合商定的命名规范 | 退回 / 重命名并记录 |
| 地理配准 | 模型未对齐到项目共享参考点 | 退回 |
| 单位 | 长度单位不是公制 | 退回 |
| 分类 | 构件没有分类引用 | 适用起始阶段：__ |
| 属性集 | 按所声明的信息需求等级，缺少必需的属性集 | Pset 清单：__ |
| 空间 | 空间缺少名称、长名称或楼面面积 | 适用起始阶段：__ |
这张表的目的不在于严格，而在于明确。一张大家都认可的宽松表格，胜过一张随退回邮件才第一次出现的严格表格。前三行分量最重，却也最常被遗漏。如何从一开始就把它们写进 BEP，请参阅真正能杜绝劣质 IFC 交付的 BEP 条款。
第 3 行值得单独展开：检查覆盖
大多数验收表检查的是验证运行的结果，却几乎没有一张会检查这次运行是否真的发生了。这个漏洞大到足以让一整份交付蒙混过关。
没有运行的检查，看起来和通过的检查一模一样：两者都是零个问题。大文件超时、工作线程崩溃、依赖几何的检查悄悄放弃，报告却干干净净地返回一个满分。这份交付于是被接收了，但它只是名义上被检查过。
| 覆盖状态 | 含义 | 验收处理 |
|---|
| 已运行 | 检查已完成。零个问题就是真的零个问题。 | 可以信任结果。 |
| 未运行 | 尝试过但没有产出结果，通常是超时或运行被取消。 | 接收前重新运行。绝不能视为通过。 |
| 失败 | 检查过程出错。 | 要如实报告。基于失败检查算出的评分，不能与一次干净的运行相比较。 |
五分钟审核一份交付
- 打开信息容器，运行项目规则集。大多数专业模型用时不到一分钟。
- 先看检查覆盖，再看结果。如果有任何检查没有运行，就先停下：你还没有完成一次真正的审核。
- 先对照阈值看评分，再看严重程度为“错误”的问题。其余的都只是备注，而不是关口。
- 与上一个版本对比。新出现的问题才是重点；已解决的问题则证明上一次审核的意见得到了落实。
- 把结果记录在文件传递单或公共数据环境（CDE）的备注中：评分、规则集、覆盖情况，以及经协商接受的所有问题。
第 1 步与发送方在提交前本该执行的流程完全相同；交付前如何检查 IFC 模型从发送方的角度逐步介绍了这一流程。当双方运行相同的检查时，审核就不再是一次检验，而是一次确认。
如何写退回意见
措辞和内容同样重要，因为收到邮件的人通常已经落后于进度，而问题又很少是他个人造成的。三条规则：点明的是标准，而不是模型；给出原因，而不只是症状；说明哪些工作被卡住、会卡多久。
Hi {name},
We've run the agreed pre-acceptance check on {filename} (rev {n}) and it
comes back at {score}/100, below the {threshold} we set in clause {x} of
the BEP.
The two findings driving that are:
- {rule id} — {plain description} ({n} elements)
- {rule id} — {plain description} ({n} elements)
Both look like export settings rather than modelling, so they should be
quick — the report is attached with the element references.
We'll hold coordination on this container until the next issue.
注意其中没有的东西：没有任何评价模型的形容词，也没有对问题成因的揣测。只有一个数字、两个规则标识符、一个可能的原因和一个后果。收到这样的消息，没有人需要为自己辩护，所以对方会去处理，而不是把事情闹大、层层上报。
什么时候可以接收未通过的模型
有时，正确的答案仍然是“接收”：缺失的信息超出了该阶段的信息需求等级，或者某个供应商尚未交付，又或者不接收就意味着项目停摆。接收一份未通过的交付是正当的决定；悄无声息地接收则不是。
一个被豁免的问题需要附上三样东西：理由、同意豁免的人和日期。“接受了的问题”与“被忽视的问题”之间的全部区别就在于此，也正是这三样东西，能防止同一个问题在两个阶段之后作为危机被重新发现。
这些豁免记录应当写进文件传递单，与报告以及随信息容器一起移交的其他资料放在一起，参见IFC 模型移交时应附带哪些资料。
IFC 验收标准：如何不起争执地接收或退回模型