生成式 3D 这两年进步很快：给一张照片，模型能吐出一个三维形状，渲染图看着像那么回事。但一个东西“能看”，和“能造、能用”，是两件事。伊利诺伊大学厄巴纳-香槟分校与微软的联合团队把这道缝做成了评测：给智能体一张实拍照片和一句话，让它拼出一个真实物件——办公桌、轮椅、剪式千斤顶、3D 打印机、乐高消防车——然后不比渲染图像不像，而是逐项追问：构件之间连上了没有、会不会自相碰撞、立不立得稳、该有的功能部件在不在、关节能不能动、材料写没写、装配顺序能不能被机器人执行。项目页与论文（arXiv:2610.04292）在 10 月 7 日公开了 30 个系统的成绩。
考的不是画得像不像
LMBuild 的任务形式很简单：一张随手拍的照片，加一句“According to image W1, build a desk.”。智能体手上有一套工具——从零件库里检索现成构件、用代码新建任意几何的零件、把构件放到指定位置、检查之后返工调整。放完构件还不算完，它必须再声明三样东西：构件之间是什么关节（转动副、滑动副还是固定连接）、每个构件用什么材料、整个东西按什么顺序装起来。
也就是说，输出被要求表示成一个装配体，而不是一团网格：构件分解、运动学关节、材料、装配时序，四样齐全才叫交付。评分分四层共 12 项指标：稳固性看连通、碰撞和稳定性；功能可供性看整体几何、功能部件和运动学；设计质量看分解是否合理、外观和参考件对不对得齐；物理实现看装配顺序、材料信息，以及放进仿真里能不能真的操作起来。
题目不是凭空造的。团队把 BrickNet、BrickComposer、PartNeXt、Fusion 360 Gallery、Artiverse 和一批开源硬件 CAD 重新整理，从约 36.8 万个对象里筛出 2,549 个，其中 200 个作为核心评测集；再用 Wikipedia 与 Wikidata 给每个物件补上“这一类东西该有哪些功能部件、关节怎么动”的文本锚点。参评的 30 个系统里有 6 个闭源 API、13 个开源大模型、11 个专用生成器（BrickGPT、LegoACE、PartCrafter、PartPacker、Cube3D + CubePart、PhysX-Anything 等），同一套题还有三种交互协议：检索加新建、只许检索、只许自己新建。
把分数摆出来看
四层指标的均值（12 项指标的算术平均，项目页说明它只用于排名，论文里 12 项分开报）摆在一起，分化非常直白：
| 系统 | 稳固性 | 功能可供性 | 设计质量 | 物理实现 |
|---|---|---|---|---|
| Claude Fable 5.1 | 89.1 | 47.3 | 71.8 | 55.3 |
| GPT-5.6 Sol | 88.8 | 41.9 | 71.5 | 57.5 |
| Claude Opus 5 | 88.8 | 46.6 | 71.3 | 55.1 |
| GPT-6 Astra | 88.5 | 50.0 | 74.0 | 53.5 |
| Claude Sonnet 5 | 86.1 | 41.5 | 66.3 | 56.2 |
| Qwen3.5-27B（最强开源） | 82.9 | 28.3 | 52.7 | 57.2 |
| GPT-OSS-120B | 78.5 | 25.8 | 49.3 | 51.7 |
| Qwen3-VL-32B | 48.5 | 13.5 | 30.2 | 31.8 |
两个数字对比着看更清楚：连通、碰撞、稳定性这三项，前沿模型已经做到 88 分上下，单看碰撞甚至到 96 分以上；但一旦问到关节怎么动（运动学），最高的也只有 42.7 分；再到“把装配顺序和材料描述丢进仿真里跑一遍”，最高只剩 22.1 分。也就是说，这些系统交出来的东西，绝大多数经不起“装得起来吗、动得了吗”这一问。
三个发现，两个跟工程实践直接相关
第一，“看起来对”不再是瓶颈，“动得起来”才是。闭源模型在几何对齐和结构稳固性上已经没什么可挑的，缺的是功能可供性——尤其是关节。评测里说得很直接：模型能把铰链画出来，但生成的铰链常被自己生成的实体卡死。这正是工程语境里最贵的一类错误：图纸上装得上，现场装不上。
第二，强模型自己造零件，弱模型只会翻库。允许自由新建构件之后，强模型的表现反而更好，因为零件库本身就是约束；弱模型则在自由里迷失——Qwen3-VL-32B 在“只许检索”下能拿 61.7 分，改成“只许自己新建”就掉到 34.1 分。更值得记的是失败原因：闭源模型的零件创建调用成功率 95.7%，开源只有 51.7%，而且失败大多不是几何算错，是违反了 CAD 内核的约定或生成的程序结构本身不成立（Qwen3.5-27B 的 89.4% 是开源里的例外）。还有一条：开源模型会引用根本没放进场景里的零件，每 100 次调用 7.2 次，闭源是 0.3 次——用工程语言说，这叫“模型和图纸对不上”。
第三，把要求说清楚，比让它多改两轮有用。多两轮“看错误报告、再修一遍”的循环，只涨约 2 分；而把 Wikipedia 里关于这个物件功能部件的描述一起喂进去，功能部件一项涨 10.3 分、可操作性涨 12.0 分（p<0.001）。团队的解释是：智能体把明确写出的功能约束转成结构的可靠性，远高于它从一个物件名字里去猜。
这套评测要打折扣的地方
- 题目里的“物件”是乐高式拼装和开源硬件级别的小型装配体，不是建筑构件，不能直接外推成“AI 能不能生成一栋楼的模型”。
- 评分靠规则校验、视觉语言模型打分和仿真，不是真机实测。论文自己也写明，要接到制造和运行，还需要制造约束、物理装配和功能测试的验证。
- 核心评测集只有 200 个任务，分数接近的系统之间不宜过度解读差距。
- 分数是这批系统在当时条件下的成绩，换个协议（只检索、只新建）排名会变，不能当成模型的通用能力排名。
对 BIM 工程师意味着什么
四件事现在就能做
- 模型里的“关节”就是你的连接关系。评测里最差的一项，恰好是国内 BIM 交付里最常被省略的一项：构件之间是铰接、刚接还是滑动，可不可以拆。很多模型只做到几何上挨着，没有连接语义，导出到仿真或算量环节就废掉一半信息。
- 参数化生成能力正在变成分水岭。能按需求用参数和脚本造出非标构件的团队，和只能翻族库的团队，差距对应评测里 61.7 到 34.1 的那条曲线。族库不是资产，能生成族库没有的东西才是。
- 提需求时把功能写进去。10.3 分和 12.0 分这两个数字说明，告诉 AI“这面墙承什么、和谁连、能不能拆”，比让它反复改模型划算得多。这跟给设计人员交底是同一个道理。
- 材料和装配顺序要当模型属性交付，不要只写在说明文档里。可操作性一项只有 22.1 分，反映的是这类信息在数字交付里普遍缺失——缺了它，后面所有自动化环节都接不上。
行业意义
过去一年半，AEC 领域的生成式 AI 比的是“能不能生成”：能不能出方案、能不能画图、能不能建模。LMBuild 这类评测把标准换成了“能不能造、能不能用”，并且把标准拆成了可打分的 12 项。对设计院和施工单位来说，这个转向的含义很实在：AI 生成的东西必须过一遍可建造性检查——连通、碰撞、稳定性、关节、材料、装配顺序，六项里缺任何一项，交付出去就是返工。先把这套检查做进流程的团队，才谈得上真正用上 AI。
来源：LMBuild 项目页（lumos-jiateng.github.io/LMBuild，2026-10-07）、论文 arXiv:2610.04292《LMBuild: Evaluating LLM Agents for Generating Buildable and Functional Structures》、Hugging Face 数据集卡（Lumos-Jiateng/LMBuild）。文中分数取自项目页排行榜数据文件（LMBuild-Core，检索加新建协议）；四层均值为该层三项指标的算术平均，论文以 12 项指标分别报告。