返回 BIM 与 IFC 博客
- 44 — 检查的质量规则数
- 100 — 满分（不一定是目标）
- 80+ — 公共数据环境（CDE）交付的目标分
- 0 字节 — 验证时上传的数据量
IFC Health Score 究竟是什么，又不是什么
每个 BIM 项目的 BEP 里都有一条含糊的质量要求：“交付高质量的 IFC。”在模型被 CDE 退回、一次碰撞检查会议白白耗在孤立构件上，或者移交资料包缺了一半资产数据之前，没有人会去定义它到底指什么。IFC Health Score 的作用，就是把这条含糊的要求变得具体：一个数字，每次都按同样的方式计算，无论在哪台机器上、由哪个实现了它的工具来算，结果都一样。
但最常见的错误，是把它当成百分比。它不是。73 分并不意味着有 73% 的东西是对的。它是一个经过加权、按严重程度调整、并按对数缩放的质量信号。理解这一区别，会改变你设定阈值的方式、解读结果的方式，以及向不直接接触 IFC 文件的项目干系人说明质量状况的方式。
Health Score 是
- 对结构质量和数据质量的 0–100 加权汇总
- 可写入合同的交付标准，应当写进 EIR
- 一个决策信号：这个模型今天能交付吗？
- 每次运行验证都会更新的进度指标
- 可在不同模型版本、专业和团队成员之间横向比较
- 受严重程度影响（错误的扣分多于警告）
- 按对数缩放（10,000 条命名警告 ≠ 10,000 × 1 条命名警告）
Health Score 不是
- 通过验证规则的百分比
- 衡量设计是否正确、项目是否准确的指标
- IDS / EIR 符合性检查的替代品
- 属性值在语义上正确的保证
- BIM 协调员专业审查的替代品
- 绝对的衡量标准：阈值因项目和阶段而异
- 某个工具专属的分数：同一模型在任何实现相同规则的工具中得分都相同
为什么传统验证报告让人无从决策
对于一个中等复杂度的 Revit 导出文件，标准验证报告通常包含 200 到 1,200 条问题，分布在 8 到 12 个规则类别中。它什么都告诉了你，又什么都没告诉你。信息经理看到 847 条问题，直接退回模型；BIM 协调员打开报告，翻过 620 条命名规范警告（全是同一条规则），才在第 12 页找到三个真正致命的错误。
问题在于，不按严重程度加权，原始的问题数量就说明不了什么。一个有 800 条命名警告、零结构错误的模型，与一个有 12 处空间层级断裂、还缺少 IfcProject 的模型，性质完全不同。Health Score 把这种差别浓缩成一个可据以行动的数字，而它下方的规则明细则给出按优先级排列的行动清单。
一份有 847 条问题的报告，只告诉你存在问题。Health Score 74 分告诉你今天能不能交付；34 分则告诉你：修好之前，暂停协调。
IFC Viewer Blog
Health Score 如何计算
计算从 100 分开始，每有一项规则未通过就扣分。有两个机制保证分数不会沦为简单的问题计数：
按严重程度加权
模式（Schema）错误（结构性故障：缺少 IfcProject、聚合关系断裂、循环引用）的扣分是质量警告（名称为空、缺少分类）的 3 倍。这反映了实际影响的轻重：结构性故障会让下游工具出错，命名警告则不会。
对数衰减
某条规则第一次未通过扣的分，比第一千次多。一个有 10 个重复 GUID 的模型和一个有 10,000 个重复 GUID 的模型，严重程度确实不同，但并不相差 1,000 倍。对数缩放避免了文件大小干扰质量信号。
Conceptual scoring model:
score = 100
for each failing rule:
base_penalty = rule.severity_weight × log(1 + issue_count)
score -= base_penalty
Severity weights:
schema_error → 3.0× (missing IfcProject, broken hierarchy, duplicate GUIDs)
quality_error → 1.5× (missing property sets, wrong container placement)
warning → 1.0× (naming conventions, missing classifications)
info → 0.3× (optional metadata gaps, non-critical omissions)
score = max(0, score)
Note: The actual formula is proprietary to each tool implementation.
This is the conceptual model — the penalty shape, not the exact coefficients.
决定分数的 11 个质量维度
44 条验证规则归为十一个质量维度。弄清是哪一类在拉低分数，你就知道在下一次验证之前应该把整改精力放在哪里：
- 模式完整性：文件中是否恰好只有一个 IfcProject？所有聚合关系是否都指向存在的实体？是否存在循环的空间引用？
- GlobalId 的唯一性与格式：文件内所有 GlobalId 是否唯一？首字符是否落在 IFC base-64 字母表中有效的 0–3 范围内？
- 空间层级：所有构件的包含链 Project → Site → Building → Storey → 实体构件是否完整？
- 构件包含关系：是否有实体构件成了孤立构件（没有空间容器），或者被直接放在 IfcBuilding 或 IfcSite 下，而不是某个楼层中？
- 构件命名：所有代表实体构件或空间的 IfcRoot 实体，其 Name 和 Description 字段是否都已填写？
- 属性集完整性：在需要标准属性集（Pset_WallCommon、Pset_SpaceCommon 等）的构件类型上，这些属性集是否存在且已填写？
- ISO 19650 元数据：IfcProject.LongName、Description 和 ObjectType 是否已填写？FILE_NAME 文件头中的 author 和 organization 字段是否非空？
- 分类：实体构件是否带有 IfcRelAssociatesClassification 关系？整个文件的分类体系是否一致？
- 材料指定：结构、建筑和装饰构件是否定义了材料层组（material layer set）或材料轮廓组（material profile set）？
- 几何完整性：是否存在退化面、自相交曲面或非流形几何？这些都会导致碰撞检查和工程量统计出错。
- LOD 一致性：属性集的丰富程度是否与声明的发展程度（Level of Development）相符？LOD 300 交付如果缺少面积和体积工程量，就无法通过这项检查。
分数段：每一档的含义与应对
- 97/100 — 优秀：可满足 ISO 19650 交付
- 89/100 — 很好：可交付 CDE
- 77/100 — 合格：正式交付前需审查
- 61/100 — 较差：需要大量修正
- 38/100 — 严重：不得交付
| 分数范围 | 等级 | 解读与处理 |
|---|
| 95 – 100 | 优秀 ✅ | 适用于所有正式交付，包括 ISO 19650 提交。规则未通过项很少或没有。无需处理。 |
| 85 – 94 | 很好 🟢 | 存在少量数据完整性问题。可上传 CDE 用于常规协调。在进入 LOD 300+ 之前解决剩余的未通过项。 |
| 70 – 84 | 合格 🟡 | 存在明显的数据质量缺口。可用于内部审查和概念设计。在任何跨专业协调或上传 CDE 之前，必须审查并改进。 |
| 50 – 69 | 较差 🟠 | 存在严重的结构或数据问题，不适合用于协调。先修复所有模式错误，再处理影响最大的数据质量规则。 |
| 低于 50 | 严重 🔴 | 根本性的结构故障：孤立构件、层级断裂、缺少 IfcProject、循环引用。退回建模软件处理。任何情况下都不得交付。 |
这些分数段只是一个起点框架。适合你项目的阈值，取决于交付阶段、合同要求，以及接收方的工具能容忍到什么程度。为 GIS 系统接收基础设施 IFC 文件的公路管理部门，可能要求每次交换都达到 ≥ 90；做内部协调的小型住宅设计事务所，在设计深化阶段以 ≥ 70 为标准也完全可行。上述分档反映的是行业共识，而不是一条固定不变的规则。
三个真实项目场景：结合具体情况看 Health Score
抽象的阈值，放到真实模型上看过之后才更容易运用。以下场景综合自建筑、机电（MEP）和基础设施 IFC 交付中常见的情况。
场景 1：建筑专业 IFC，得分 95
一栋中型商业办公楼，LOD 300，由 ArchiCAD 27 导出。验证报告显示 43 条问题：38 条命名规范警告，出现在通用注释构件上（名称是“Annotation-001”，而不是描述性名称）；另有 5 处幕墙嵌板缺少材料指定。没有模式错误，没有重复 GUID，空间层级完整，IfcProject 元数据填写齐全，ISO 19650 文件头完整。得分 95。BEP 要求 CDE 交付达到 ≥ 85。决定：按现状交付，在文件传递单中把命名问题注明为非阻断性意见，并安排在下一版中修正材料指定。
场景 2：机电 IFC，得分 68
一个完整的暖通与电气机电模型，LOD 250，由 Revit 2025 MEP 导出。得分：68。规则明细按优先级列出了原因：214 个重复 GlobalId（高严重程度：Revit 导出配置重新生成了 GUID，与从一个旧链接模型中复制过来的构件发生冲突）；89 个构件直接放在 IfcBuilding 下，而不是某个楼层中（空间包含关系错误：跨越多个楼层的暖通立管被放在了建筑层级，而没有锚定到地下室楼层）；44 个 IfcFlowTerminal 构件没有分类（EIR 要求使用 Uniclass）；以及配电箱上的 312 条命名警告。空间包含错误和重复 GUID 属于模式层面的问题：它们会破坏 BCF 引用，并导致运维（FM）导出失败。这个模型不应交付。修复 GUID（可自动修复），修正立管的楼层归属，补充分类，然后重新验证。整改后的预期得分：≥ 83。
场景 3：基础设施 IFC，得分 82
一个 IFC4.3 道路线形模型，通过定制导出器从 Civil 3D 导出，覆盖 4 km 路段，包含排水和路缘石构件。得分：82。主要扣分来源：67 个构件没有分类（要求使用 Uniclass Table J）；104 个路缘石构件缺少工程量集（合同要求在 BaseQuantities 中给出明确的长度）；IfcProject.LongName 不一致（文件头显示的是文件名，而不是正式的项目名称）。没有结构错误，没有重复 GUID。业主的技术规范要求施工阶段的模型交换最低得分为 80，模型通过。协调员记下了三处需要修正的地方，要在正式的设计冻结提交之前完成，届时阈值将提高到 90。
BIM 团队如何在项目全生命周期中使用 Health Score
Health Score 融入项目的日常节奏时最有用，而不是只在交付时才用一次。任何能在浏览器中打开的模型，验证都应在 30 秒内完成，运行它的成本几乎可以忽略。而不运行它的代价，是到了 CDE 关口或协调会议上才发现结构性故障，损失要以天计。
设计深化阶段的每周质量检查
在模型创建的活跃期，每周运行一次验证，并在项目日志中记录分数趋势。如果分数在两个周五之间下降了 15 分，说明有东西变了；现在排查，远比六周后模型复杂一倍时容易得多。
每次协调会议之前
每个专业都应在会议前达到各自的阈值（内部 ≥ 70，跨专业 ≥ 80）。用得分低于 60 的文件搭建的 Navisworks 或 IFC 整合协调模型，只会产生毫无意义的碰撞：构件位置错误、机电管线成了无法引用的孤立构件、BCF 问题指向空无一物的地方。
IDS / EIR 验证之前
IDS 验证的前提是一个结构良好、数据完整的基础模型。对空间层级断裂或存在重复 GUID 的模型运行 IDS 检查，结果并不可靠：IDS 引擎可能误识别构件、漏掉基于包含关系的适用性规则，或者给出虚假的通过结果。任何 IDS 检查之前都应要求 ≥ 75，才能得到可信的结果。
每次模型交换之前
在每份传递单上都把 Health Score 作为一个表头字段附上。这样接收方专业在打开文件之前就能立刻了解情况，同时也为整个项目中模型质量的变化留下审计轨迹。一些 CDE 支持自定义元数据字段，这正是值得利用的一个。
CDE 交付关口
这是没有商量余地的检查点。模型上传前必须达到 BEP 规定的阈值。信息经理不应人工审查未经验证的模型；分数报告（含时间戳、工具版本和分数）应作为传递单的必备附件。低于阈值的模型退回给提交方，分数就是客观的理由。
- 从建模软件导出 IFC，并启用稳定 GUID 设置。
- 在浏览器验证工具中打开：对大多数项目模型而言，验证在 30 秒内即可完成。
- 查看分数。如果低于当前阶段的阈值，打开规则明细。
- 按严重程度对问题列表排序（错误优先）。先处理模式错误，再处理数据警告。
- 能自动修复的就自动修复（GUID 重复、格式错误）；层级和命名问题需要手动修复。
- 用修正后的设置（稳定 GUID、正确的楼层归属）从建模软件重新导出，然后重新验证。
- 达到阈值后，把分数报告附在传递单上，再上传到 CDE。
完整的质量体系：分数 → 规则 → IDS → BCF → 交付
Health Score 是四层质量体系中的一层。每一层回答的问题不同，彼此不能替代。理解这个体系，是建立稳健的 BIM 质量控制工作流程的概念基础：
┌──────────────────────────────────────────────────────────────────┐
│ IFC Model File │
│ (exported from authoring tool) │
└──────────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ 44 Quality Rules → Health Score (L1 + L2) │
│ Schema · GUIDs · Hierarchy · Names · Psets · ISO 19650 │
│ Question: Is this model well-formed and data-complete? │
│ Output: 0–100 score + prioritised rule-level issue list │
└──────────────────────────┬───────────────────────────────────────┘
│ if score ≥ stage threshold
▼
┌──────────────────────────────────────────────────────────────────┐
│ IDS Validation (L3 — Level 3) │
│ Project-specific EIR/AIR information requirements │
│ Question: Does this model satisfy our contractual spec? │
│ Output: Pass / Fail per IDS spec + element-level evidence │
└──────────────────────────┬───────────────────────────────────────┘
│ on failures found
▼
┌──────────────────────────────────────────────────────────────────┐
│ BCF Issue Report │
│ Structured coordination issues linked to elements │
│ Question: What specifically needs to change, and who owns it? │
│ Output: BCF 2.1 file shared across authoring tools │
└──────────────────────────┬───────────────────────────────────────┘
│ when all layers pass
▼
┌──────────────────────────────────────────────────────────────────┐
│ Formal CDE Delivery │
│ Model + score evidence + IDS report on transmittal │
└──────────────────────────────────────────────────────────────────┘
第 1–2 层：Health Score
44 条规则，覆盖模式完整性、GUID 唯一性、空间层级、属性完整性、命名、ISO 19650、分类、几何和材料。这是通用的质量底线，适用于任何 IFC 文件，与项目类型无关。低于 80 分的模型没有达到底线，不应进入下一层。
第 3 层：IDS 验证
由 EIR 编写者以机器可读的 XML 编码的项目专属要求。共有六个分面（facet）：Entity（哪些构件类型）、Attribute（哪些 IFC 属性字段）、Property（哪些 Pset 值）、Classification、Material 和 PartOf。Health Score 是通用的，IDS 则是定制的：每个项目、每个专业包都有各自的规范。
BCF 问题跟踪
当 Health Score 规则或 IDS 检查未通过时，这些问题会变成 BCF 议题（topic），即带有构件引用、视点和责任方的结构化协调事项。BCF 把验证体系发现的质量问题带进协调工作流程，在那里被分派、跟踪并解决。
CDE 交付
整个体系的终点。一个通过了 Health Score 关口和 IDS 关口的模型，就有了书面的质量证据。分数报告和 IDS 验证结果就是附在传递单上的正式质量证据，让信息经理有据可查，而不是凭猜测判断。
在 BEP 和 EIR 中设定阈值
没有合同依托的 Health Score 阈值只是一个愿望。EIR（Employer Information Requirements）是合同文件；BEP（BIM Execution Plan）是落实 EIR 的交付计划。阈值应同时写进两者，其中具有约束力的是 EIR 中的那一版。
── EIR clause (contractual, enforceable) ─────────────────────────────────────
5.4 Model Quality — IFC Health Score
All IFC information deliveries shall achieve a minimum Health Score
as specified below, validated prior to upload to the Common Data
Environment. The Health Score shall be calculated using [agreed tool]
with [agreed rule set version]. The validation report (including score,
timestamp, and tool version) shall be attached to the transmittal as
evidence of compliance.
Models that do not meet the applicable threshold shall be returned to
the Originator for remediation. Re-upload shall reset the revision
counter and generate a new transmittal record.
Minimum thresholds by LOD and delivery type:
Internal model review (LOD 100–150): ≥ 70
Cross-discipline coordination (LOD 200): ≥ 75
Detailed design CDE delivery (LOD 300): ≥ 80
Construction issue (LOD 350+): ≥ 85
As-built / FM handover (LOD 400+): ≥ 90
── BEP clause (operational, implementation plan) ─────────────────────────────
3.2 Validation Procedure
Prior to each CDE upload, the Information Originator shall:
1. Export IFC with stable GlobalId settings (see Section 4.1).
2. Run the agreed validation tool against the exported file.
3. Confirm the Health Score meets or exceeds the applicable threshold.
4. Attach the score report (PDF or JSON) to the transmittal record.
关于 IFC Health Score 的六个常见误解
误解 1：“越高越好，目标就是 100”
合适的分数完全取决于交付阶段。概念设计的目标应是 ≥ 70，而不是 ≥ 95。花几个小时把早期的体量模型提到 95 分，是把力气用错了地方：方案一改，三周后你修好的命名就会被全部替换。为各阶段定义合适的阈值，并以此为目标。把精力留给 LOD 300 之后的提分，那时的修改代价高昂。
误解 2：“100 分就意味着模型毫无问题”
100 分意味着模型通过了全部 44 条结构与数据质量规则。它不能说明属性值在事实上是否正确、模型是否满足项目 EIR、设计意图是否得到准确表达，也不能说明是否存在几何碰撞。一个所有 Pset 都填满占位文本的模型也能得 100 分。分数确认的是结构健康状况，而不是为内容背书。
误解 3：“Health Score 可以取代 IDS 验证”
两者回答的是不同的问题。Health Score 问的是：按照通用的质量标准，这个文件是否结构良好、数据完整？IDS 问的是：这个模型是否满足本项目、本专业包的具体信息要求？一个模型可能得 95 分却通不过 IDS 验证，原因可能是缺少 EIR 要求的 Uniclass 2015 分类，或者 IfcBuildingStorey 的名称不符合项目 BEP 中约定的楼层命名规则。两项检查始终都必不可少：它们互为补充，而不是相互重叠。
误解 4：“分数会告诉我该修什么”
分数告诉你是否交付，它下方按规则列出的明细才告诉你该修什么。只有 68 分而没有问题明细，就像油表亮了红灯，手里却没有地图。打开规则详情：按严重程度排序，阅读构件数量和说明，先修复严重程度最高的未通过项。下一次运行验证时，分数会立即更新。分数和明细这两部分信息，永远要一起使用。
误解 5：“Health Score 可以取代 BIM 协调员的审查”
自动化验证能发现结构性故障、数据完整性缺口和格式违规，但无法审查设计合规性、空间可行性、与进度计划是否一致或可建造性。一个得 92 分、却包含一个在结构上不可能成立的转换结构的模型，照样是 92 分。BIM 协调员或信息经理的专业审查永远不会被分数取代，而是得到分数的支持。分数替审查者滤掉了清单式的噪音，让他们把注意力放在真正重要的地方。
误解 6：“我的模型没问题，在 Revit 里打开没报错”
能在某个工具中无错误打开，只是最低的门槛。IFC 解析器有意设计得很宽容：能加载的就加载，加载不了的就悄悄丢弃或纠正。一个在 Revit、ArchiCAD 和 Navisworks 中都能顺利打开的文件，可能同时存在 300 个重复 GUID（导致所有专业的 BCF 失效）、80 个孤立构件（在每份碰撞报告中都缺席）、缺少 IfcProject.LongName（无法满足 ISO 19650 的可追溯性要求），而 Health Score 只有 41 分。“能打开”不是质量检查。
IFC Viewer Online 如何实现 Health Score
IFC Viewer Online 的 Health Score 在浏览器中对任意 IFC 文件运行全部 44 条质量规则，耗时不到 30 秒，而且不上传任何内容。具体实现涵盖以下方面：
44 条验证规则
完整覆盖 L1 模式完整性和 L2 数据质量：GlobalId 唯一性与格式、空间层级、孤立构件检测、命名完整性、ISO 19650 元数据、属性集是否存在、分类、材料指定以及几何完整性检查。
按严重程度加权的 Health Score
模式错误的扣分是警告的 3 倍。对数缩放避免大模型的分数被人为压低。同一模型每次运行都得到相同的分数：可复现，可审计。
按规则的明细与构件数量
每条未通过的规则都会显示问题数量、严重程度、受影响的构件类型以及整改说明。按严重程度排序，即可安排工作的优先级。明细是行动清单，分数是决策信号。
GUID 自动修复
重复和超出范围的 GlobalId 一键即可自动修复。系统会使用正确的 IFC base-64 字母表生成一个符合规范的 22 位新 GUID，首字符位于有效的 0–3 范围内。
非破坏性属性编辑
直接在收到的文件上修正名称、属性值和分类，无需退回建模软件。支持完整的撤销/重做。修改以 EditDiff[] 的形式按 GlobalId 存储，并在导出时应用，原始文件永远不会被就地修改。
IDS 验证 + BCF 导出
通过 Health Score 关口之后，针对全部六个分面（Entity、Attribute、Property、Classification、Material、PartOf）运行项目专属的 IDS 验证。将未通过项导出为 BCF 2.1，分发到 Revit、ArchiCAD、Solibri 以及任何支持 BCF 的协调工具。
在真实的 Revit 导出文件上运行 Health Score
这个 14 MB 的办公楼模型由 Revit 导出，是一个典型的中型建筑专业交付成果。打开它，看看 Health Score、按类别划分的规则明细，以及一个商业项目交付前的真实验证报告是什么样子。
IFC4 · 14 MB
打开交互式 IFC 查看器
故障排查：分数不见提升怎么办
已在 Revit 中修复问题，但分数没有变化
最常见的原因是：修改是在 Revit 模型里做的，但没有重新导出 IFC。验证针对的是 IFC 文件，而不是建模软件中的模型。修改原模型后务必重新导出，并验证新导出的 IFC，而不是上次修过的那个文件。
两次导出之间，分数从 81 骤降到 47
修订版之间分数下降超过 20 分，几乎总是意味着导出配置变了；具体来说，是 GUID 生成设置从“Keep Existing”改成了“Generate New”。这会产生成千上万个新的 GlobalId，验证工具会认为它们超出范围，或与之前的某个链接文件重复。检查 IFC 导出器设置，恢复稳定的 GUID 输出。
分数是 76，但信息经理要求 80
打开规则明细，按扣分贡献排序，而不是按问题数量排序。你与 80 分之间差的这 4 分，几乎可以肯定集中在 1–2 条规则上。先修复扣分最多的规则，通常是空间包含错误，或者某一类构件缺少属性集。解决这两条规则，重新导出并重新验证。由于扣分结构是非线性的，分数的提升往往超出预期。
分数 95，但 IDS 验证未通过
这是预料之中的，也是正确的。Health Score 和 IDS 针对的是不同的层面。95 分意味着模型在结构上非常出色；IDS 未通过则意味着它不满足某项具体的项目要求，比如某个 Pset 值、某个分类编码或某个材料层厚度。查看 IDS 未通过报告：它会指出具体的构件、期望值和实际值。在建模软件中修正，或者对收到的文件使用非破坏性属性编辑。
常见问题
什么是 IFC Health Score？
一个 0–100 的加权质量信号，依据 44 条验证规则，概括模型的结构完整性和数据完整性。它不是百分比，而是一个按严重程度加权、按对数缩放的分数：模式错误比数据警告的权重更高，某条规则的第一次未通过比第一千次扣分更多。
它是如何计算的？
分数从 100 开始。每一项规则未通过，都会根据其严重程度权重和问题数量的对数扣分。模式错误（结构性故障）的扣分是质量警告的 3 倍。对数缩放避免了在底层问题密度相同时，大模型看起来比小模型差得多。
BEP 中应规定多少 Health Score？
常规 CDE 交付和跨专业协调：≥ 80。ISO 19650 正式里程碑提交和 LOD 300+ 交付：≥ 90。概念阶段的内部审查：≥ 70。除了 BEP，也要写进 EIR（合同文件）。只有 EIR 才能形成具有法律约束力的质量关口。
模型得 100 分，还可能有质量问题吗？
可能。分数覆盖的是 44 条结构与数据质量规则，不涵盖 IDS 符合性（项目专属要求）、语义正确性（属性值在事实上是否准确）或设计意图。一个所有属性集都填着占位值的模型也能得 100 分。分数确认的是结构健康状况，而不是为内容背书。
Health Score 高，是否就可以跳过 IDS 验证？
不能。两者回答的是不同的问题。Health Score：这个模型是否结构良好、数据完整？IDS：这个模型是否满足本项目的具体信息要求？得 95 分却通不过 IDS 检查，是常见且在预料之中的结果：修复 IDS 未通过项，然后把两项都重新验证一遍。
每个模型都应该以 100 分为目标吗？
不应该。要设定适合各阶段的阈值。在概念设计阶段追求 100 分，会浪费本该投入设计深化的精力。目标应该是“模型是否达到了这个交付阶段的阈值？”在项目启动时就在 BEP 和 EIR 中定义这些阈值，然后以它们为标准进行验证，而不是以理论上的最高分为标准。
总结
一个在 Revit 中无错误打开的模型，并不是经过质量检查的模型，只是一个恰好能被解析的未检查模型。Health Score 就是这两者之间的区别，而要弄清你手里的是哪一种，只需要 30 秒。
IFC Viewer Blog
读懂这个数字
Health Score 是一个按严重程度加权、按对数缩放的决策信号。80 分以上表示可以交付 CDE，低于 60 分表示存在结构性问题。它不是百分比，而是一个质量结论。
写进合同
适合各阶段的阈值应写进 EIR（合同层面）和 BEP（执行层面）。没有 EIR 条款，阈值就无法强制执行。要在项目启动时、首次交付之前就把它加上。
融入日常节奏
设计深化阶段每周验证；协调会议前做会前检查；上传 CDE 前做关口检查。每份传递单都附上分数报告。让分数成为项目的例行工作，而不是交付当天的手忙脚乱。
用好完整的质量体系
Health Score → IDS → BCF → 交付。每一层回答不同的问题。分数是底线，IDS 是上限。两者都要用，并把未通过项导出为 BCF，以便在协调工作流程中跟踪和解决。
关于 44 条规则如何组织成三个验证级别的技术说明，请参阅 IFC 模型检查工具完整指南。关于浏览器与云端架构的选择，即敏感项目数据何时适合在本地处理，请参阅浏览器端与云端 IFC 验证对比。如果你收到的 IFC 文件需要在验证前修正属性值、GUID 或命名，免费在线 IFC 编辑器指南介绍了无需往返建模软件的非破坏性编辑方法。至于那些最常把分数拉到 70 以下的结构性故障，请参阅最常见的 7 种 IFC 验证错误。
IFC Health Score 权威指南：写给 BIM 协调员与 BIM 经理
