在深智城任职期间，我负责 SZ-IFC 转换插件和报建自检工具的需求分析与改进，整理用户反馈，与清华及相关技术团队沟通具体问题。
两款工具服务于同一条 BIM 报建流程：设计人员在建模软件中完成模型，通过转换插件导出 SZ-IFC 文件，再用自检工具检查模型数据，完成后提交报建。
BIM 建模 → SZ-IFC 转换 → 报建自检 → 模型提交
把模型里的数据读明白
当时，合作双方在业务范围上存在分歧，项目推进较慢，实际完成的迭代有限。这段时间里，我投入了很多精力研究 IFC 标准。
IFC 是建筑信息模型交换所使用的数据标准。一个模型在不同软件之间流转，需要传递构件的几何形状，也需要保留属性、位置和构件之间的关系。理解这些信息怎样写入文件，是讨论模型转换与检查问题的基础。
我查阅标准文档和相关论文，结合实际 IFC 文件研究数据的组织方式。以一根梁为例，沿着文件中的实例编号，可以继续查找它的位置、几何表达和关联信息。我把这些对应关系逐项拆开，研究实体的继承、属性的表达，以及材料等信息怎样与构件关联。
文件为什么会变大、哪些信息可以复用、不同软件为什么会读出不同结果，也都是研究的内容。这些问题与报建工具遇到的构件偏移、信息缺失和模型转换耗时直接相关。
写成手册，向团队和合作单位讲清楚
我把研究整理成《IFC 标准简介》，从标准的发展背景、数据架构讲到实体与属性，再结合文件实例说明数据如何表达，并讨论文件压缩和实际应用中的问题。
在此基础上，我准备了培训 PPT 和讲解稿，给公司同事做 IFC 专题培训。在与外部单位交流时，相关的技术介绍也由我承担。讲解时，我会用具体构件和文件里的对应关系说明概念，让同事能把标准定义与实际模型联系起来。
回到报建工具的具体问题
工具的需求仍然来自实际使用。我负责整理问题、核对场景，再与技术团队讨论原因和处理方式。其中既有软件缺陷，也有模型数据或操作方式带来的问题，需要分别处理。
模型转换耗时就是一个例子。用户修改模型后需要重新导出，再到自检工具中检查。团队增加了 Revit 内的预检功能，让部分问题在导出之前就能被发现，并通过构件编号帮助用户定位修改；导出后的文件仍由自检工具检查。
我也参与了模型落到城市信息模型平台时的坐标需求讨论。对格式错误或明显无效的坐标值，检查需要拦截；对超出深圳范围的坐标，则提示用户复核。两种情况的处理不同，需要把工具能够判断的范围和仍需人工确认的部分说清楚。
研究 IFC 的过程中积累的理解，让我能够跟进这些具体的技术讨论，也能向同事和合作单位解释模型数据是怎样被组织、转换和检查的。
