改造项目里最费的环节不是扫描。一天的架站、扫站，能把一栋老楼扫得清清楚楚；难的是扫完之后，要把那堆点云变成一份能改、能出图、能进 IFC 的模型。现在的做法基本是人工重画：拉墙、切洞口、量厚度、对关系，一栋几万平方米的楼要几个月。10 月 21 日挂上 arXiv 的 CRAB 想动的就是这个瓶颈，而它改的不是扫描精度，是「用什么表示重建结果」。
一、Scan-to-BIM 卡在表示，不是精度
点云是表面测量：一堆带坐标的点，没有构件概念。BIM 是另一套东西：墙是一个有厚度、有高度、有材料、有承重属性的构件实例，门附着在某面墙上，洞口属于墙，柱和梁有结构关系。两者之间隔着的不是坐标变换，是「把面重新组织成体」这件事。
现有的自动重建方法大致走三条路。一条是规则管线：先分割，再拟合平面，再做拓扑优化，最后人工修。它的问题是每一步都要人调参数，换一类建筑就得重来。一条是学习类方法，多数输出二维户型线或者三维平面——房间分得对，但墙有多厚、门窗洞口有多高、这个构件是什么身份，都没有。第三条是把户型或平面结果在后处理里「挤出」成体量，这条路在简单住宅上还行，到了非标准结构就开始错。
深圳大学与圭尔夫大学这篇论文的判断是：问题出在表示上。只要中间结果不是「带参数的构件体积」，后面怎么后处理都补不回来。
二、CRAB 的两段结构
CRAB 的做法是把重建结果直接定义成「构件长方体」：墙、门、窗、梁、柱，每一个都是一个带语义的长方体，参数是中心线、厚度、高度、洞口尺寸，语义和参数对齐 IFC。墙用中心线参数化而不是通用有向盒，是这篇文章的关键设计——理由后面再说。
整个流程分两段。ProposalNet 先看图，用自回归的方式吐出一批粗长方体：哪面墙、哪扇门、在什么位置、大概多大。AssemblyNet 负责精修，它把每个长方体编码成一个带语义、关系和编辑标记的 token，通过三种注意力——构件内部、构件之间、构件与点云之间——来修正几何，同时用一个关系头预测结构依赖：哪两面墙相邻、门属于哪面墙。修正用的是关系感知的 Flow Matching。
输出之后还有一步工程化处理：同一张「长方体加关系」的图，可以拼成三种建模习惯——角部有独立节点的、十字交叉有独立节点的，以及把节点并进整面墙的。意思是重建结果不是一张死模型，按国内与国外的建模规范都能落地。
训练数据是这篇文章的另一半工作。团队把公开的 Structured3D 补上了构件级长方体标注，又程序化生成了 3,000 个带模拟扫描噪声的场景，合起来叫 CrabSet，已经放在 HuggingFace 上。训练用 8 张 RTX 4090，50 个 epoch，输入点云按 2.5 厘米体素下采样。
三、数字：墙厚和洞口高度是差距所在
对比对象里最有参考价值的是 SpatialLM——目前公开的、用三维平面表示场景的方法。两者在同一份测试集上的差距，集中体现在体积参数上，而不是轮廓上。
| 指标 | SpatialLM（三维平面） | CRAB（构件长方体） |
|---|---|---|
| 外墙构件匹配 Match-F1 | 92.40% | 93.78% |
| 内墙构件匹配 Match-F1 | 91.48% | 92.57% |
| 内墙中心线偏差 | 3.10 cm | 3.01 cm |
| 内墙厚度平均误差 | 3.89 cm | 2.80 cm |
| 墙厚误差在 3 厘米以内占比 | 24.98% | 79.50% |
| 门洞高度误差 | 77.36 cm | 2.86 cm |
| 窗洞高度误差 | 122.86 cm | 9.23 cm |
| 门／窗匹配 Match-F1 | 89.03% / 77.90% | 91.14% / 88.97% |
这组数字里最值得看的是第五行。墙厚误差的平均值两者只差 1 厘米，但「误差落在 3 厘米以内」的比例从 25% 跳到 79.5%——意思是计划方法虽然平均下来还行，但多数墙是错的，只是错得不多；CRAB 是多数墙对了，少数墙错得厉害。对建模交付来说，这是两种完全不同的返工体验。
门洞高度那一行差距更大。平面方法本质上不表达洞口高度，后处理里只能靠推断，误差到几十厘米甚至一米以上；长方体表示里高度是显式参数，误差降到 2.86 厘米，这个量级已经接近现场用激光测距仪复核的水平。
合成数据之外，论文还在两个真实扫描数据集上做了对比：BIMNet 上墙体匹配从 68.6% 到 72.5%，门从 49.6% 到 68.8%，窗从 37.4% 到 48.5%。真机上提升幅度比合成集小，门窗的绝对水平也不高——这是这篇文章最诚实的地方。
四、为什么「中心线长方体」比「有向盒」强
墙是一种长细比极端的构件：长度可能十几米，厚度只有二十厘米。通用的有向盒用一个中心点、三个边长、一个转角来描述，长度和厚度在数学上被平等对待，噪声沿着长方向一放大，厚度就跟着飘。中心线参数化把两件事拆开：一条中心线决定走向和长度，一个厚度值单独管厚薄。
消融实验给出了代价：换成通用有向盒，内墙「厚度误差在 3 厘米以内」的比例从 79.50% 掉到 71.74%。门和窗上两者差不多，甚至通用盒略好——因为门窗本来就是紧凑构件，不存在长细比问题。这也解释了为什么这个设计是给墙量身定做的。
第二个结论更反直觉：长方体不只是更好的输出格式，它也是更好的优化目标。团队做了一个扰动实验，把真值墙移一点、缩一点，再让模型修正回来。用平面表示修正，端点误差是 30.29、13.07、33.21 厘米；用长方体表示修正，是 3.60、5.18、5.66 厘米。原因不难理解：平面的小偏差在墙提取和后处理里会被放大，而长方体每个构件自带范围与厚度，改一个构件不会牵动邻居。
局限也写在论文里。只能处理单层室内场景；以正交布局为主，曲线和极不规则结构会被简化；整块缺失的构件仍要人先粗放地摆一个位置，模型再修；梁的匹配只有 57.83%（柱是 97.15%），因为梁在真实测试集里出现太少；真实数据只覆盖 BIMNet 与 ISPRS 两个集。
五、对 BIM 工程师意味着什么
可以开始准备的几件事
- 改造项目的工作结构会变。现在的活是「画」，这类方法成熟之后是「核」——检查构件对不对、改错的地方。同一份工时，从建模转到审模，签字的人要能看懂点云偏差在哪儿。
- 点云质量仍是前置条件。论文把输入按 2.5 厘米体素下采样，说明源数据得比这更细。站距、遮挡、玻璃与镜面反射，还是得靠现场控制，算法补不了。
- IFC 语义是硬要求。墙厚、洞口高度能进参数，重建结果才有交付价值。只追求渲染好看的重建，在审查和算量环节用不了。
- 注意「可编辑」这件事的复利。构件级表示把重建和编辑合成一件事，改造项目多轮变更时省下的是返工，不是首次建模的时间。
- 别把演示当生产工具。CrabSet 与在线 demo 都放出来了，可以试，但训练分布是住宅式室内场景，厂房、机房、医院这些管线密集的空间没有验证。
六、行业含义
国内 Scan-to-BIM 真正有人付钱的场景很集中：既有建筑改造、城市更新、竣工模型补测、历史建筑测绘。共同点是「没有原始模型」，所以重建这件事绕不过去。这类研究往前走一步，先影响的是工具，接着影响的是计价方式——按平方米收建模费的报价单，迟早要改成按合格构件数和修改轮次来算，因为模型的价值本来就在构件上，不在面积上。
另一个变化在交付口径。过去点云交付和模型交付是两件事，前者给测量队，后者给建模组，中间靠人转译。如果重建结果本身带 IFC 参数和关系，两者可以合成一条链：扫描、重建、复核、出图。这条链真正跑起来之后，改造项目最贵的那段人工就少了一半。至于什么时候能跑起来，取决于真实场景上的准确率能不能再往上走一截——门窗 48.5% 这个数字，还不足以让人放心签字。
这篇研究要打折扣的地方
- 结论来自学术论文，主要评测集是合成数据（Structured3D 加了模拟扫描噪声），真实场景只有 BIMNet 与 ISPRS 两个公开集，不是工程实测项目。
- 只处理单层室内场景，多层、错层、大跨结构未验证。
- 与 Cloud2BIM 等方法的对比条件不完全等价：部分基线是重新训练版本（论文标了星号），不能直接等同于官方发布版本的表现。
- 梁的匹配率只有 57.83%，且仅程序化场景评测；柱 97.15% 同样来自程序化场景。
- 未开源完整训练代码，可复现性依赖 CrabSet 数据集与在线 demo。
信息来源：arXiv:2610.29257《CRAB: Cuboid-based Representation for As-built BIM from Point Clouds》（2026-10-21 提交，SIGGRAPH Asia 2026 录用）；项目页 vcc.tech/research/2026/CRAB；CrabSet 数据集与演示（HuggingFace）。文中两张配图均取自论文项目页。本文为智曦知行原创分析，基于公开论文整理，不构成工具选型建议。