1. text-to-cad到底是什么它和传统的text-to-3D哪里不一样我第一次注意到text-to-cad这个方向是在翻某篇三维生成相关论文的引用列表时。当时我手头在做一个工业零件的自动建模工具平时接触最多的还是text-to-image、image-to-3d这一套流程看到一个用自然语言描述直接生成CAD模型的关键词第一反应是这玩意儿和传统text-to-3D有什么本质区别后来我花了两周时间在两条不同的技术路线上各跑了一轮实验踩了不少坑也沉淀了一些自己的判断。这篇东西就是把这段实测记录整理成文给同样想入手text-to-cad的开发者、算法工程师或者三维建模工具链的维护者做个参考。先说结论text-to-cad和text-to-3D虽然都叫文字生成三维内容但难度和落点完全不在一个量级。你要是拿Midjourney生成一张梵高风格的椅子图没人会追究这椅子的椅腿能不能承重但如果你跟一个工程师说帮我生成一个带四个沉头孔的法兰盘他期望拿到的是一份可以被CAD软件二次编辑、能上CAM机床加工、带尺寸和约束特征树的三维模型。这就是text-to-cad和普通三维生成的本质差异——它要求的不只是看起来像而是能被CAD生态消费。我曾经和一个做机械设计的老师傅聊过这个方向他的原话很直接我用SolidWorks画一个零件哪怕慢一点每个特征都是我知根知底的你让AI给我一个黑盒模型我看着是这么个形状真出了问题我连draft都没法改。这句话基本就点出了text-to-cad面对的核心矛盾生成结果不仅要几何正确还要在语义上符合CAD的构造逻辑。基于这个认知我决定按两条路线分别做实验一条是直接用跨模态模型生成网格/隐式场另一条是让大语言模型直接输出参数化CAD脚本看看哪一条更接近能用的标准。1.1 一个根本差异CAD可编辑表达 vs 静态网格传统text-to-3D任务的输出通常是Mesh、SDF或者NeRF体积场这些表达的共性是结果锁定——模型一旦生成你很难把它拆解成若干可修改的特征。CAD模型的本质是特征历史树一个法兰盘可能是由拉伸圆柱切除四个孔倒角串起来的每一步都是一个参数化操作改一个直径整条链自动更新。这个差异直接决定了text-to-cad的算法设计不能照搬text-to-3D。如果你用一个SDF网络生成法兰盘的隐式场视觉上可能很逼真但导出成STEP格式后在SolidWorks里就是一堆三角网格没任何特征信息等于和CAD工作流断开了。所以我在选型时的判断是要么用生成模型直接输出B-Rep类的结构描述很难当时没有现成工具链要么换一个思路通过中间语言把CAD构造过程也表达出来。1.2 两条技术路线的分野与我的选型判断实际试验时我把市面上的方法归成了两种流派。第一派是跨模态生成派用CLIP或者类似模型把文本和三维形状拉进同一个隐空间然后通过扩散模型或生成对抗网络产出体素、点云或者网格。这条路线快速、直观工程上有很多现成组件可以复用。第二派是程序化生成派利用大语言模型的代码能力让GPT这类模型直接写OpenSCAD、FreeCAD脚本或者导出STEP文件本质是把问题从几何生成转成了代码生成。我的选型判断是这样的第一派适合做概念原型和快速可视化尤其是在数据量极少、只关注视觉相似度的场景下第二派虽然依赖大模型在代码生成上的上限但一旦跑通产出的结果能真正落到CAD工具链里具备实际工程价值。所以我决定两条都跑先短平快验证第一派再花更大的精力啃第二派。接下来分别说实测过程。2. 第一条实测路线CLIP跨模态对齐驱动的形状生成我最早动手的是这条路线原因是它的组件最成熟。基本思路是把文本描述和三维形状同时映射到一个共享的CLIP特征空间文本进来就能在形状空间里检索或者生成最匹配的几何体。为了快速验证我没有从零训一个大规模生成模型而是采用CLIP特征预提取隐式占用场生成器的组合拳。2.1 数据准备CAD模型多视角渲染与CLIP特征预提取这一步是整个流程的地基也是最容易翻车的地方。我当时从公开数据集里拉了一批机械零件模型格式大致是STL/OBJ但原始数据质量参差不齐很多模型是没有归一化方向、没有单位标注的。我的处理流程是模型归一化把所有模型统一缩放到单位立方体并对齐坐标轴——默认Z轴向上这是机械CAD里最常见的朝向约定。多视角渲染每个模型从4个固定视角正等测、侧视、俯视、正视各一张渲染成512x512的图用Blender的Python API批量完成渲染时关闭光照阴影只保留纯色材质加边缘轮廓降低CLIP对材质、纹理的干扰。特征预提取用CLIP的ViT-B/32模型把每张渲染图编码成512维向量取四视角向量的均值作为这个形状的全局语义向量存成npy文件后面训练时直接加载不用每次前向算CLIP。这步做完我统计了一下数据规模一共两万三千个零件模型去掉渲染失败的、明显残缺的剩下一万八千个左右。坦白说这个量级对跨模态生成来说偏少我一度怀疑后面会过拟合但观察下来CLIP特征空间本身的先验帮了大忙小数据也能勉强跑出语义相关性。提示渲染视角的选择直接影响CLIP特征质量。我一开始只渲染正视图像结果CLIP把很多类似轮廓的零件比如圆盘和垫片混在一起加入等测视角后语义区分度明显改善。2.2 生成器骨架从文本特征到三平面占用场模型结构上我参考了当时比较流行的三平面tri-plane隐式场做法没有直接用全量体素。原因主要有两个一是体素分辨率受显存限制256立方体网格即便在A100上也很吃力而三平面只需要维护三个平面特征隐式查询时CPU/GPU都不用扛太大数据二是三平面本身比较适合后期接mesh提取的Marching Cubes算法工程上顺滑。具体结构可以拆成三段文本编码CLIP text encoder冻结输入一句描述得到512维文本向量。平面特征生成文本向量过一个两层MLP映射成三个与文本条件相关的平面特征张量每个平面大小是128x128x32通道数32。隐式占用场解码任意给一个三维坐标点投影到三个平面分别采样特征拼接后过一个小型MLP输出这个点的占用概率再用Marching Cubes在256分辨率网格上提取零等值面得到mesh。训练这个结构时文本编码器完全冻住只更新MLP和解码器。最初我尝试过也冻结CLIP图像编码器、直接用预提取向量但发现图像特征和文本特征在CLIP空间里虽然共享坐标却存在一致性缺口——文本向量描述的是抽象语义图像向量还带着材质、视角等视觉细节直接对齐容易互相干扰。后来我在投影层里加了一个可学习的线性适配层专门负责从视觉特征向纯几何语义压缩效果明显见好。2.3 训练Loss设计对比约束与几何约束缺一不可刚开始我只用了一个简单的CLIP对比损失把生成形状的渲染图和文本描述在CLIP空间里拉近。跑了两百个epoch之后发现问题很明显——生成形状能匹配语义但几何结构一塌糊涂很多模型看起来是个抽象轮廓实际无法闭合边缘全是散落的伪影。于是我拆了三个loss出来对比损失生成mesh渲染图与输入文本的CLIP相似度权重设0.5负责语义对齐。占用场交叉熵真值体素占用和预测占用之间的二元交叉熵权重设1.0保证几何基本盘是对的。平滑正则对占用场输出加一个梯度惩罚让生成的表面不会出现频繁的凸凹突变权重设0.1。训练参数方面我用了一张A100 80Gbatch size为128AdamW优化器初始学习率3e-4配合cosine退火大约20个epoch后验证损失曲线开始不再下降。总耗时六小时多一点整个训练过程其实不算长主要开销在CLIP渲染图和体素查询。2.4 实测效果复盘离散伪影、薄壁特征丢失、局部语义错乱训练完我用自己攒的二十条测试描述做了定性评估比如带四个圆形通孔的法兰盘阶梯轴带键槽带加强筋的L形支架。第一眼看上去语义关联性是有的描述法兰盘时生成结果大概率是圆盘状描述支架时会有明显的转折结构。但细看问题不少。首先薄壁和孔类特征丢失很严重四孔法兰盘经常只生成出两三个完整的孔孔的位置也歪歪扭扭。我分析下来主要还是数据里精细特征占比少加上CLIP特征本身对几何细节不敏感——你让CLIP区分四孔法兰和六孔法兰它基本无能为力。其次模型在局部区域容易产生离散伪影比如零件表面偶尔多出一块漂浮的凸起Marching Cubes提取后表面也不够光顺。最后是语义错乱描述里同时出现两个实体时比如一个圆柱体上放一个方块模型往往会合成一个不伦不类的形状这说明它的组合性推理能力几乎为零。这一轮跑完我的结论是这条路线做快速原型可以但完全达不到CAD级输出标准。于是我把重心转移到第二条路线上。3. 换一条务实路线让大模型直接编写OpenSCAD参数化代码相比生成网格再想办法转CAD更直接的做法是让大模型生成CAD自己看得懂的东西。我盯上了OpenSCAD原因后面细说。这条路线拼的不是生成模型的几何能力而是大语言模型的代码推理能力以及你对Prompt的控制能力。3.1 为什么选择OpenSCAD做中间语言市面上可选的CAD脚本语言其实有好几个OpenSCAD自带一种函数式语言、FreeCAD有Python API、SolidWorks有宏录制、OnShape也有FeatureScript。我选择OpenSCAD作为第一落点有四个现实原因纯文本即模型OpenSCAD的源文件就是一段段代码没有复杂的二进制格式大语言模型天然擅长处理文本生成结果可以直接进版本管理。参数化能力强所有尺寸、位置、布尔运算都是显式的改一个数字整个模型跟随更新和CAD的feature思想对得上。命令行渲染方便openscad命令可以无头渲染PNG或者导出STL非常适合做自动化闭环验证不需要打开图形界面。生态轻量相比SolidWorks的宏录制OpenSCAD没有任何隐式历史状态模型完全由代码决定对AI生成来说容错空间更大。当然OpenSCAD也有短板比如不支持B-Rep直接输出STEP曲面造型能力弱NURBS曲面什么的别指望。但作为验证LLM能否构造CAD逻辑的中间语言它的成本最低。3.2 Prompt设计把自然语言描述翻译成带约束的CAD指令有了中间语言核心问题就成了Prompt怎么写。直接丢一句生成一个法兰盘给GPT-4模型确实会给你一段OpenSCAD代码但出来的尺寸大概率是乱编的没有公差、没有标准件常识甚至有时候孔位方向反了。我调试了一版相对可靠的Prompt模板核心是把约束显式化我在系统提示词里固定了以下几类信息单位约定默认毫米所有尺寸必须是实际可加工尺寸不能写相对值。命名规范每个特征模块独立成函数函数名体现语义比如hex_head_screw()、mounting_hole_circle()。模型构造模式只能用lazy union或显式union禁止用difference嵌套多层后再做整体渲染防止计算异常。布尔运算约束先定义主体再依次做切除、倒角确保特征顺序可读。参考常识常见标准件螺栓、轴承位、通孔要按常用公称尺寸取整比如M6螺纹孔底径5mm这是加工常识。输出要求返回纯OpenSCAD代码禁止解释性文字。举个例子对一个带四个均布沉头孔的法兰盘外径80mm内径30mm厚度10mm这句描述模型生成的代码骨架大致是module flange_80() { difference() { cylinder(h10, r40, $fn64); cylinder(h10, r15, $fn32); for (i [0:90:270]) { rotate([0, 0, i]) translate([28, 0, 0]) cylinder(h10, r4.2, $fn16); } } }这段代码可以渲染出正确几何孔位也均匀分布但要注意一个细节真正的沉头孔应该是圆柱段加锥形沉头两段构造如果描述里明确写了沉头模型有时只给一个直通孔需要在Prompt里追加一句沉头孔需区分通孔段和沉头段。这个小坑我和同事都踩过后来我在模板里加了所有孔类特征必须描述为多段组合的硬性规则。3.3 迭代闭环命令行渲染检查与参数微调生成代码本身不是终点关键还要闭环验证。我把整个过程接成一个shell脚本大概流程是拿到LLM输出的OpenSCAD代码先做基础解析检查括号匹配、是否有语法错误。用openscad无头模式渲染成PNG两三个固定视角。同时导出STL用脚本统计体积、外包围盒尺寸和描述里的尺寸做一致性对比。如果不匹配把渲染结果和差异描述重新喂给LLM让它修正代码最多迭代三次。然后我遇到了一个特别典型的坑cylinder函数默认的高度方向是Z轴正方向当描述里说水平放置的圆柱时模型会直接生成竖直圆柱除非Prompt里明确要求坐标方向。类似这种CAD空间常识问题在生成网格的路线里完全不存在因为网格没有严格的方位概念。但恰恰也是这种约束让OpenSCAD路线在工程上可验证——渲染出来的图一眼就能看出方向对不对。我在这一轮实测中最大的体会是OpenSCAD路线的质量上限不在大模型的代码能力而在Prompt能否把设计意图翻译成CAD构造意图。你要是能把自己的描述拆成主体形状切除特征倒角圆角阵列这四层最终输出质量会高出很多。3.4 与大模型对话式改图的连带经验迭代过程中我还尝试了对话式修改不是一次生成到位而是多轮交互。比如先让模型生成一个基座再追加一句把四个安装孔直径从6.5mm改到8.2mm模型会保持整体结构不变、只修改相关参数。这个能力比一次性生成更实用因为实际设计过程中需求本来就是逐步明确的。不过也有翻车的时候。有次我让模型把这个支架的壁厚从3mm改到5mm同时保证最大外形尺寸不变模型把所有偏移量都改了但其中两个孔的定位基准是从内壁延伸的结果外形虽然没变孔位却跑偏了。这说明模型对参数之间的依赖关系理解还是浅依赖的参数边界容易被忽略。要缓解这个问题我在Prompt里加了改尺寸时只能修改被指定的参数关联特征按原约束不变比不加约束的情况稳定很多。4. 两条路线实测对比输出质量、可编辑性、时序成本两条路线都跑通了demo之后我把它们放在一起做了个横向对比。对比维度我选的是几何精度、特征可编辑性、生成速度、语义理解深度、工程集成难度。下面这个表是我个人实测数据的总结不代表所有方案都这样但趋势是有参考价值的。对比维度CLIP跨模态生成路线OpenSCAD程序化生成路线几何精度中低薄壁和孔特征易丢失高尺寸精确由参数决定特征可编辑性低输出mesh基本不可继续特征化高代码即特征历史生成速度训练完成后单次推理约0.8秒LLM推理约2-5秒加渲染验证另计语义理解深度中能对整体类别和粗粒度属性有反应较高能按多段构造逻辑拆解描述工程集成难度低Python端到端中需要额外做代码检查和渲染闭环真实CAD软件兼容性差需二次转STEP/特征识别中OpenSCAD可转STEP但流程绕从这个表可以明显看出两条路线各有各的用武之地。CLIP路线胜在速度和对视觉语义的联想能力适合做概念草图阶段的灵感生成OpenSCAD路线胜在几何可控性和参数可编辑性适合做工程建模的有力辅助。4.1 五个维度的实测结论与选型建议结合我自己的场景机械零件快速建模我的结论很明确真正做text-to-cad产品OpenSCAD程序化生成路线的潜力远大于CLIP路线。但这不代表CLIP路线没有价值。在概念设计、灵感发散、非标件预研阶段CLIP路线能快速给出形态参考哪怕不可编辑也是有用的。最优解其实是把两条叠加起来用。我给一个混合思路先用CLIP路线生成一个粗糙的视觉参考mesh辅助设计人员确认形状方向再用LLM编写OpenSCAD代码构造参数化模型。两边的结果相互校验。实测过程中用reference mesh喂给多模态模型做视觉提示词能显著提升OpenSCAD代码生成的一次通过率尤其是复杂曲面过渡的描述视觉参考图比纯文字约束有效得多。4.2 有趣的反向发现精细描述反而导致代码膨胀还有一个有意思的发现Prompt里的描述越精细代码越长大模型出错的概率反而增大。比如你描述一个长度100mm、宽度60mm、高度25mm的长方形盒子顶部均匀分布六个直径5.5mm的安装孔四角R5倒圆角模型能稳定输出。但如果你追加侧面有一个深度2mm的凹槽距离顶面15mm宽度和凹槽所在面的宽度一致模型在推导凹槽位置时偶尔会用错坐标基准或者忘记把槽底留够壁厚。我试过把描述拆成更小的构造块每个块单独生成再组合比一个巨大的Prompt整体生成要稳定。宁可多花几次LLM调用也别让模型在长上下文里迷路。提示如果你准备自己做text-to-cad的Prompt模板我的建议是把约束写在硬约束区把描述写在软约束区。硬约束比如单位、方向、命名规则、布尔运算顺序一次性写死软约束比如大小、形状、孔位可以灵活调整。5. 数据、评估和生产落地的真实阻力实验做到这个阶段表面上两条路径都能跑通了但把镜头拉远看text-to-cad离规模化落地还有三座山要翻数据、评估、工具链对接。这三个问题我在项目里都正面撞上了各自说下体会。5.1 配对数据稀缺合成数据是唯一的现实起点text-to-image有LAION这种几十亿规模的图文对数据text-to-3D有大量粗粒度的描述数据但text-to-cad需要的自然语言描述参数化CAD模型配对数据目前公开的非常少。原因很好理解CAD模型不像图片那么好爬而且很多专业模型有商业授权限制自然语言描述更是要工程师逐条写成本极高。所以实际做法通常是合成数据把CAD模型的参数和特征树自动转成伪描述。比如一个法兰盘模型从特征树里抽出cylinderholefillet这些操作拼成模板句子a cylinder with four holes and fillets。这类数据能训练模型理解构造性指令但有一个隐患模板句子覆盖面窄模型对真实自然语言的泛化能力有限一旦用户描述里出现带台阶的圆盘这种非模板表达效果就掉。我在实验里试着用大模型把特征树描述改写成语义更自然的句子数据质量为之一变后续生成也稳定了一些。5.2 现有评估指标刷分容易却被语义正确性骗过评估text-to-cad的生成质量常见指标是Chamfer Distance、IoU、CLIP score但这些指标挡不住语义错误。我举一个实测例子描述带螺纹孔的圆形底座模型生成了一个圆盘加一个圆柱凸起Chamfer Distance比生成真实螺纹孔还要低因为后者在几何距离上更接近圆盘小圆柱的组合。如果你只看指标会觉得模型做得不错实际上语义完全错了。我后来加了一个简单的人工评估维度让CAD工程师给每个生成结果打三个分一是语义正确性、二是几何完整性、三是可编辑性。虽然主观但比纯数值指标可靠得多。自动化评估在没有更好的语义对齐度量之前很难替代人工。5.3 从Demo到CAD工作流特征树、约束、单位制都要对齐就算模型生成了一段完美的OpenSCAD代码把它接入真实的产品设计流程依然有很长的路要走。OpenSCAD代码虽然参数化但导出成STEP格式后在FreeCAD或者SolidWorks里看到的往往是一个整体形状而不是可逐个编辑的特征。也就是说OpenSCAD的参数化和CAD原生特征树之间本质上还隔着一层模型约束和特征命名不会自动传递过去。我在做集成验证时处理方式是在OpenSCAD里严格控制函数模块的拆分粒度每个函数对应一个工程语义比如base_plate()、mounting_hole()、fillet_edge()导出后借助FreeCAD的Python API做特征识别能部分还原出打孔、切除这类特征但复杂的放样和曲面操作基本无能为力。想做到真正的text-to-native-CAD-features可能得让大模型直接输出FreeCAD的Python脚本甚至对接更底层的B-Rep建模内核这条路的工程量比很多人预想的大得多。最后再分享一个我踩过无数次的小坑希望后来的人能绕开无论是CLIP路线还是OpenSCAD路线单位制不一致都会引发灾难性后果。CLIP路线训练前不做尺度归一化生成结果在导出3D打印时可能直接放大十倍OpenSCAD路线如果不强制约定毫米单位LLM可能会次次都输出英制渲染时察觉不到等到装配阶段尺寸全乱。所以我在所有代码路径的统一入口都加了一行单位检查没有单位声明的生成结果一律拒绝使用宁可多一次迭代也不把隐患带到下游。text-to-cad这个方向现在的状态有点像是概念已经验证、工程还没闭合。两条路线各有各的舞台概念设计靠视觉生成工程建模靠程序化生成短期很难互相取代。如果让我给刚入坑的人一个建议我会说先别追求端到端通用生成找个具体零件品类往下钻把Prompt闭环和数据管道做好比堆模型规模有价值得多。