返回 BIM 与 IFC 博客
交付与 ISO 19650 · 2026-08-07 · 9 分钟
移交 IFC 模型时，除了 IFC 文件本身还应附上哪些资料
每一次交付都是一项声明：这个模型在这个版本上满足这个用途。证据能把这项声明变成接收方无需重复你的工作就能核实的东西，也能避免同样的争论发生两次。
移交 IFC 模型时，除了 IFC 文件本身还应附上哪些资料 — IFC Viewer Online article cover
每一次 IFC 交付都是一项声明：这个模型在这个版本上满足这个用途。文件本身并不承载这项声明，它承载的是几何和数据。一切能让这项声明得到核实的东西，都应该随文件一起交付，而在大多数项目中，这些东西几乎一样都没有。
这就是为什么同样的对话总要发生两次。第一次，有人检查了模型，认为可以接受。第二次是一个月后，换了一个人、换了一道关口，又有人重新检查一遍，因为第一次检查没有留下任何人都能信赖的记录。
五份资料，其中四份你手上已经有了
| 资料 | 回答的问题 | 受众 |
|---|
| 验证报告 | 检查了什么、发现了什么 | 接收方的协调员 |
| 检查记录 | 证明检查确实做过，针对的正是这个文件，时间是何时 | 信息经理、业主、审计人员 |
| 问题文件（BCF） | 哪些问题还没修复，去哪里看 | 需要采取行动的人 |
| 资产数据（COBie） | 建筑里有什么，以数据形式呈现 | 业主和运维（FM）团队 |
| 文件传递单 | 版本、状态、评分、规则集、豁免项 | 所有人，以及存档记录 |
五份资料第一次准备大约需要十分钟，之后每次都会更快。它能让每次交付少发大约四封邮件，也决定了一次交付是被直接接受，还是被拿来反复讨论。
1. 验证报告
把它导出、附上，不要在邮件正文里转述。一份报告要对运行时不在场的人有用，需要具备三个特点：
- 它写明规则集，而不只是结果。没有规则集的评分无法解读，也无法与下一个版本比较。
- 它说明覆盖范围：哪些检查运行了，哪些没有。一份分不清“已通过”和“未执行”的报告，只是营销材料。
- 它带有构件标识符，每个问题都能直接定位，而不必到处搜寻。需要你自己去翻找的报告，没人会用第二次。
如果你不确定报告中哪些问题值得汇报、哪些只是噪音，最常见的 IFC 模型错误是一份不错的分诊清单：其中结构性的问题，正是接收方关心的。
2. 检查记录
每个质量流程中最薄弱的一环在于：检查和声明是两回事。任何人都可以说某个模型得了 92 分。检查记录把这个数字与具体文件绑定：文件自身的指纹、规则集、模式、时间戳和评分。
这样的记录要比一张面板截图更有价值，需要具备两个特点：
- 它由文件内容推导而来，因此只要模型改动了一个字节却沿用同一份记录，就能被发现。
- 接收方可以独立核实它，无需你参与。只有你自己的软件才能确认的记录，只是一种承诺，而不是证据。
3. 问题文件
BCF 的存在，是为了让问题在离开你的屏幕之后依然完整保留。它的全部价值在于视点：一个相机位置、一组选择和一条评论，三者结合，接收方只需十秒就能找到问题，而不是十分钟。
BCF 文件是被处理还是被忽视，取决于两条约定：
- 每个原因一个主题，而不是每个构件一个。四千个构件缺少某个属性集，应该是一个带有代表性视点的主题，而不是四千个主题，让文件根本打不开。
- 用规则标识符和修复方法作为主题标题，而不是症状。“缺少属性集：在导出模板中添加所需的 Pset”可以直接执行；“属性缺失”只是一句抱怨。
4. 资产数据
COBie，或业主要求的其他任何数据表，是模型质量在商业上变得显而易见的节点，因为它交付给的是一个从不打开模型、也无从理解任何借口的人。
它还有一个实用的作用：检验你的验证工具。没有名称的空间、没有制造商的类型、没有分配到空间的组件：这些缺口会以空白列的形式出现，设施经理一眼就能看到。如果从你的模型导出的 COBie 会让人难堪，那么无论几何看起来如何，这个模型都还没准备好。
5. 文件传递单
只需六行，就能避免大多数交付争议：
Container: {filename}
Revision/status: {rev} - {suitability code}
Schema: {IFC2X3 | IFC4 | IFC4X3}
Checked: {date} - rule set {name} - {n} of {n} checks completed
Health Score: {score}/100
Open by agreement: {rule id - reason - agreed with - date}
Not suitable for: {e.g. quantity take-off, fabrication}
最后一行是大家最常跳过的，而它恰恰是保护你的那一行。说明一个信息容器不适用于什么，并不是在推卸责任：这正是信息需求等级的定义，而且是在唯一有人真正会读它的时刻交付的。
这一切意味着什么
这里没有任何新技术，也不需要任何你还没有的工具。它需要的只是把交付当作一项必须能被他人核实的声明。这只是心态上的一个小转变，却能大幅减少被退回的交付。
接收方对这一切采用的标准，详见 IFC 验收标准；让这些标准具有约束力的条款，详见真正能防止糟糕 IFC 交付的 BIM 执行计划（BEP）条款。关于这三者背后的 ISO 19650 框架，请参阅 ISO 19650 IFC 交付检查清单。
移交 IFC 模型时，除了 IFC 文件本身还应附上哪些资料