如何让 AI Agent 真正理解建筑？构建 AI 原生的 BIM 数据结构

项目开源地址： BimDown (GitHub)

TL;DR: 本文是对 BimDown 格式底层的纯技术细节与设计取舍探讨，不包含演示（Demo）。如果你更关注 AI Agent（如 OpenClaw）操作建筑结构的实际应用效果，请直接跳过本文，阅读系列文章的第二篇实战应用部分。

背景与问题

近几个月大家都在尝试将各种各样的 AI Agent 接入现有的工作流。在建筑领域，比较自然的想法是让 Agent 直接去操作和生成 BIM 模型。但在实际测试中，我们通常会遇到很多问题。目前主流的尝试主要有两条路：

第一条路是直接读取或生成 IFC 格式。IFC 是明文，看起来很适合让大语言模型（LLM）去写。但这在现实中不可行。为了描述一堵包含门窗的墙，IFC 采用复杂的边界表示法（B-Rep），这需要生成大量交错的节点和引用关系。它不仅会快速消耗掉模型的 Token 上下文，更致命的是，现阶段的 LLM 很难理解复杂的三维几何与拓扑嵌套。一旦中间某个引用节点（比如 #123）出现幻觉或计算错误，整个几何模型就无法正常打开。

第二条路是通过 MCP 协议调用 Revit 的 API。这种方法的主要问题在于对大模型（LLM）的执行机制不够友好：

工具调用次数过多与 Token 消耗：通过 API 驱动 Revit 模型需要大量切碎的工具调用（Tool Calling）。在系统的 KV Cache 机制处理不够好时，多轮调用往返会消耗过多的 Input Token。
模型注意力分散：模型需要将大量的注意力分配在确认工具调用逻辑和处理返回值结构上，这会影响它在处理主要空间建模任务时的核心推理能力。另外，不需要依赖和安装昂贵的 Revit 桌面端软件，这也是一个附加的好处。

方案：BimDown 的格式设计与取舍

如果我们希望 AI 能够顺畅地理解建筑，就需要换一种思路，去构建一个 AI 原生的中间态数据结构。这也是我将其命名为 BimDown 的原因，这个名字包含了我的两个核心设计理念：一方面，它是降维（Down）的 BIM，通过将由于大模型不擅长的 3D 几何特征降维来消除计算障碍；另一方面，我希望它能成为建筑信息工程领域的 Markdown，轻便、纯文本且极易被大模型读写。

受限于 AI 当下的空间计算能力，BimDown 并非用来去强行替代现有的主流工程格式。它选择主动牺牲掉一些细分段的使用场景，将“几何”和“属性”彻底分离，让 AI 回归用它最熟悉的方式去描述建筑。

1. 核心数据结构的载体

为什么属性使用 CSV？ CSV 非常省 Token，且没有嵌套树的层级结构，这也是 AI 和开发者最熟悉的数据表格式。它最大的优势是可以直接被 DuckDB 这种轻量级分析型数据库直接读取并进行复杂的 SQL 查询和过滤，对于日后 AI 编写自动化数据清洗脚本非常友好。

为什么几何使用 SVG？ 行业中很少使用 SVG 作为工程主数据，但 BimDown 选择将建筑的 3D 体块降维成 2D 的 SVG 轮廓保存。原因很简单：SVG 是 Web 开发中最主流的矢量格式，预训练模型在语料库中见过海量的 SVG 代码文本。各大科技公司目前都在把前端页面和 SVG 的生成质量作为展示其大模型空间推理能力的长期核心指标。工程行业的影响力有限，大厂不太可能专门去为 IFC 或 DXF 的结构专门做模型微调，但为了网页交互，他们一定会不断把 SVG 生成调到最好。我们采用这种格式，本质上是在顺应这一趋势。

最终呈现出来的是类似一般软件工程目录的书写逻辑。模型通过系统的目录树组织一系列的纯文本文件（如特定楼层文件夹下的 wall.csv 和 wall.svg），每个文件只负责一件特定的事，这刚好适配了现有 Agent 在 Coding 场景下的主要工作方式。

2. 针对 AI 特性的数据规约优化

在制定具体规范（Schema）时，BimDown 针对大语言模型在数值计算和三维几何处理上的短板，做了一些针对性的优化设计：

计算字段隔离机制：LLM 通常不擅长精确的浮点数运算。因此规范明确规定，像构件长度（length）、房间面积（area）、包围框（bbox）等衍生数据都被设定为 computed: true（自动计算的只读字段）。Agent 仅需输入基本参数或提供一条基础的 SVG 路径，后续的面积与拓扑计算全部交由 CLI 引擎在编译阶段（build）自动生成。这避免了模型在生成纯文本时产生数值幻觉。
门窗通过二维坐标附着墙体：在传统三维操作中，墙上开门窗通常需要切分墙体或执行布尔运算，这对直接输出代码的 AI 不太友好。BimDown 规定墙体在 SVG 中必须保持为连续不断的线段。门和窗则仅通过在 CSV 中提供其中心点坐标（host_x, host_y）或沿墙体的一维相对距离（position）来标识位置。实体的布尔开洞操作被推迟到渲染与转译环节处理。
基于种子点的空间边界生成：要求文本模型完美闭合一个多边形的多个顶点序列往往容易出现坐标偏移。因此 BimDown 简化了空间（Space）单元的生成逻辑。Agent 只需要在 space.csv 中给出一个位于房间内部的二维种子点坐标（Seed Point X/Y）。CLI 在构建时会通过算法自动向外追踪周围的实体墙壁，提取出准确且封闭的房间边界。

类似的针对性优化还有很多。这些设定都是在反复的实验测试中，找到大模型容易产生困惑或频繁犯错的边界场景后，逐步迭代优化而来的。

目前，BimDown 规范已经涵盖了绝大多数常见的建筑结构与机电分析场景，总计支持以下 30 种核心实体类型： beam (梁), brace (支撑), cable_tray (桥架), ceiling (天花板), column (柱), conduit (线管), curtain_wall (幕墙), door (门), duct (风管), equipment (设备), foundation (基础), grid (轴网), level (标高), mep_node (机电节点), mesh (网格模型), opening (洞口), pipe (管道), railing (栏杆), ramp (坡道), roof (屋顶), room_separator (房间分隔线), slab (楼板), space (空间), stair (楼梯), structure_column (结构柱), structure_slab (结构板), structure_wall (结构墙), terminal (风口/末端), wall (墙体), window (窗户)。

关于上述每一种构件完整的类型定义树以及具体的字段提取规范，可以前往开源仓库中 /spec 目录下的具体 YAML 配置文件进行查阅。

3. 格式定位与 Revit 交互

我知道我不可能推出一种被行业广泛认可的新格式，而且 BimDown 在客观上也确实无法去满足工程后端 IFC 和 RVT 中的那一套复杂构件特性。我把它定位成：只有当某个业务节点切实需要引入 AI 进行批量自动化操作，或是在 Web 端需要轻量级加载建筑结构数据时，才作为补充使用的中间态格式。合适的场景包括早期的能耗建模分析、施工进度中的动态流水段排布管理等。在这些场景下，Revit 的整体依赖过于笨重，而 IFC 的树状解析又过于复杂。

在工作流对接上，我开发了 Revit 的配套插件，用于实现 BimDown 和 Revit 模型间的数据交互。这套机制保证了，如果一份模型从 Revit 导出到 BimDown，经过外部的 Web 端或 AI 工具修改后，再次导入 Revit 时能够进行参数差异的增量更新，而非粗暴的整体覆盖。在面对目前 BimDown 无法支持的少数复杂 Revit 族特性时，深层关联信息可能会丢失，几何图元也会 Fallback 降级为无法被参数化二次编辑的纯网格模型（关于不支持特性的详细排查清单，请参见文末附录）。对于导出的需求我也做了兼顾：通过 Web 编辑器可以顺利转出为基础的 IFC 模型文件以作他用，但考虑到 IFC 文件树的极度复杂性，目前并没有反向导入 IFC 的计划。

4. 基于 CLI 的类似编码工作流

BimDown 的整体流程是在尽可能模仿常规软件的开发模式。现有的 AI Agent，包括 OpenClaw、Claude Cowork 等即使是非编程专门用途的 Agent，其底层其实也都是以 Coding Agent 作为基础的。因此，整个建筑建模过程也就尽可能地去模仿软件开发的方式。

近几个月以来，随着 Agent Skills 这种方式逐渐被证明是现阶段 AI Agent 的最佳扩展方式，越来越多的软件都在被重新封装成 CLI 供系统调用。这些 CLI 工具就是 Agent 的“手脚”。顺应该趋势，我开发了一整套 BimDown CLI 来支持这套工作流。它提供了 AI 要使用 BIM 所需的各种基础能力，可以说是专门写给 AI 用的 Revit。对于 Agent 来说：

创建与验证：这套流程是以运行 bimdown init 初始化项目开始的。碰到不熟的构件，通过相关的 spec 命令查询字段规范。模型修改完成后，通过调用 bimdown build 来触发编译器规则验证模型。本地引擎生成的各种边界、错误及干涉问题都会通过标准错误输出（Stderr）反馈给 Agent，促使其自行进行后续的代码修改及拓扑迭代。
多模态反馈检查循环（Render机制）：Agent 会随时运行 bimdown render 来生成预览图。为啥需要 render 呢？其实这不是用来给人看的，而是用来给 AI 自己看的。现阶段 AI 对于矢量图形底层的文本理解能力非常有限，但是多模态模型（比如 Qwen、Gemini）已经具备了非常强的视觉能力，它们可以通过查看渲染出来的 PNG 图片来直接判断当前的布局是否正确。在我的实测中，即使是目前最强的 Gemini-3.1-Pro 模型，第一次根据图纸直接生成房间布局时也会产生不少错误。但是在这个反馈循环里，通过让它随时查看渲染结果并自我修正迭代 2-3 次，哪怕是用比较轻量的 Flash 级别模型，也能准确地按图纸还原出小体量的建筑模型。
空间数据的 SQL 清洗查询：当对建筑数据存在高复杂度追随和过滤诉求时，bimdown query 可以结合嵌入好的 DuckDB spatial 拓展直接执行高级纯量及几何复合查询。而且借用事先维护好的特定机电节点拓扑规则构建，让 LLM 当场起草一条具备递归属性的公用表表达式（CTE）语句，就能够便捷解决常规方法中极难穿透系统路径的网络路由及相关机电系统的寻标问题。
扩展定制处理：对于再复杂一点的纯计算操作逻辑情况。由于其基础信息已变为纯粹的前端结构，我向外部提供了一些能够加载解析 JS 并封装对应数据到开源多边形类库中的接口，使得即便在需要面临要依照某种特殊规划、基于一些边界或是既有网格把大面块分割切分这种场景时，直接利用简单的几何脚本就能平稳的去拆解，无需陷入 3D 下传统的布尔剪接噩梦中去。

横向评测

为了量化大模型对不同 BIM 数据形式的适应性，我使用 Gemini-3.1-Flash 基于 Revit Advanced Sample Project 进行了一次完整的基准测试。测试包含新建形体 (Model)、复杂属性查询 (Query) 和深层构件修改 (Modify) 三个常见任务，测试阵列包含 BimDown 不同子格式、IFC 以及直接挂载 Revit 底层 API 等情况，综合测试结果如下：

数据格式	工具配置	创建 (Model)	查询 (Query)	修改 (Modify)	综合得分	消耗 Tokens	总成本
bd-csv-svg	配备 bimdown-cli	8/8	4/5	5/5	89%	760k	$0.304
bd-csv-geojson	裸跑 (无工具)	8/8	3.5/5	5/5	87%	712k	$0.285
bd-csv-svg	裸跑 (无工具)	8/8	2.5/5	5/5	83%	799k	$0.467
bd-csv	裸跑 (无工具)	6/6	4/5	3/5	80%	1,385k	$0.453
Revit MCP	挂载底层 API	5/6	2.5/5	2/5	59%	1,458k	$0.467
ifc-webIfc	搭配 web-ifc 类库	6/6	1/5	0/5	40%	1,543k	$0.498
ifc-text	纯文本硬性读写	4/6	0/5	0/5	13%	9,198k	$1.318

从上述数据中可以得出以下三个技术性结论：

现阶段大模型难以有效处理 IFC 格式：即使借助外置解析库，面对存在大量嵌套关联特征的 IFC 实体树，模型推理也极易中断。在纯文本读写测试环节，模型不仅耗费了大量的 Token，在处理复杂修改时甚至会产生“虚假报告执行成功”的代码幻觉，实际底层文件未发生任何更改。
直连 Revit API 表现受限于任务类型：向大模型直接暴露 Revit 专有底层指令时，其在正向生形搭建（Model）任务上效率极高。但由于模型缺乏对 Revit 内核类型与实例分类法的先验知识，导致在稍复杂的跨层级查询中极易输出错误数据。此外，当遇到缺少预定义接口而试图动态编译 C# 脚本操作时，模型极易因预料滞后而陷入反复报错代码的循环。
BimDown 的分离表达结合专属 CLI 可以实际降低成本：通常认为反复调用外部 CLI 提取信息会大幅增加交互轮次从而推高成本。但在本实验中，由于底层工具包代劳了 XML 等树形结构的低效正则解组，有效节约了模型上下文的对齐能力（Attention）。测试表明 BimDown 结合 CLI 的综合路线不仅取得了最高成功率，其 Token 开销与成本相比纯文本硬写方式反而实现了较大幅度的下降。

总结

BimDown、IFC 与 Revit 之间的关系，其实很像 Markdown、LaTeX 和 Word 的关系。

Revit 就像是大而全的 Word，界面直观、功能强大，但数据被封闭在它的私有生态里；IFC 就像是追求完美的 LaTeX，拥有严谨的大一统标准，但现阶段让普通人或者 AI 直接去手写它的源码，是一件极其痛苦且容易出错的事。

而 BimDown，就是我想为包含建筑在内的空间工程提供的一个 Markdown。

几年前网上大家还在争论“哪门语言是世界上最好的编程语言”时，我们大概谁都不会想到，到了 AI 爆发的时代，全网每天被大模型生成最多、大家用得最顺手的语言，居然会是 Markdown——一个最初看起来无比简陋、只是用来写博客的标记语言。

BimDown 的核心理念也在于此。不去追求大而全的新标准，只是提供一种在当下，AI 和人类都能无负担地读取、修改和理解的最简单的格式。

附录：BimDown 不支持的 Revit 特性完整清单

不支持项将回退为网格模型导出，所以难以进行编辑，但不影响展示。

1. 几何抽象限制 (Geometry Limitations)

自由曲面/NURBS：概念体量、自适应构件、形状复杂的内建族。
非严格圆弧曲线：不支持椭圆弧、样条曲线墙（注：标准的正圆弧是在支持范围内的）。
带坡度的楼板：楼板子图元形状编辑、坡度箭头、变厚度楼板。
被编辑过的墙轮廓：非矩形的墙体立面轮廓边界（例如带有斜顶的山墙）。
幕墙细分细节：独立且每块不同的嵌板材质、嵌板内嵌套的门窗、非矩形嵌板。

2. 数据结构限制 (Data Limitations)

多层复合构造：墙体、楼板及屋顶的材料切层结构（如细分核心层、饰面层、保温层）。
族类型与计算公式：Revit 的完整类型系统、实例参数、公式驱动以及系统约束。
修改与版本控制台：工程阶段（Phases，如现有/拆除/新建）以及多方案设计选项（Design Options）。
复用和组织引用：参数化的组（Groups）、阵列（Arrays）、嵌套族（Nested Families），以及工作集（Worksets）和外部链接模型（Linked Models）。

3. 专业深度限制 (Discipline Limitations)

结构计算：荷载工况、特殊边界条件、钢筋布置深化明细。
MEP 物理计算：风量、管网水压降、电气荷载、冷热系统负荷计算等参数。
能耗模拟依据：详尽的材质热工属性（U值、SHGC）、人员与设备的逐时作息表。
项目场地与红线：地形实体（Toposolid）、场地红线划分、非参场地植被构件。
家具与洁具：不再保留其动态参数调整能力，统一降级为基于固定网格的 GLB 图元。
图纸与批注视图：剖面图、立面图、截面详图、所有图面文字与尺寸标注（Annotation）、报表/明细表（Schedules）。