1. text-to-cad到底在解决什么事1.1 一句话说清这个项目的定位做3D建模的朋友应该都有过这种体验脑子里已经想清楚一个零件长什么样了但打开CAD软件新建草图、画轮廓、拉伸、切除、倒角一步步操作下来等你真把模型建出来当初那股动手的兴致早就被消磨干净了。text-to-cad就是冲着这个痛点来的——用一句自然语言描述直接生成可用的3D模型文件。说起来很简单你输入“一个带圆形散热孔的矩形外壳长120mm宽80mm高40mm孔直径5mm”它给你输出一个STL或STEP文件。目前社区里能实际跑通的项目比较有代表性的以Autodesk Research开源的Zoo Text-to-CAD为主另外像MeshGPT这类基于Transformer直接生成三角形网格的方案以及让大模型输出CadQuery脚本再程序化建模的路线也都归属于text-to-cad这个方向。我下面讲的实操部分主要以我实际跑过的Zoo Text-to-CAD开源实现为例。这个项目适合三拨人一是3D打印玩家想快速把脑子里的想法变成可打印的STL二是机械设计和工业设计从业者用来做概念方案的快速论证三是对AIGC感兴趣、想看看自然语言生成的三维物体目前到底有几斤几两的开发者。1.2 为什么是现在才火起来text-to-cad不算是一个全新的想法早在几年前就有人在搞“文本转三维模型”的研究但效果一直很粗糙。以前的做法多半是拿一个文本编码器加一个生成网络出来的东西经常是“看着像但没法用”的模糊体素块。现在这个方向能变成一个像样的项目原因是三块拼图凑齐了。第一块拼图是多模态模型的成熟。CLIP这类文本-图像对齐模型让机器对语言描述的理解能力上了一个台阶后面接的生成模型也能从文本语义里提取出更准确的几何约束。第二块是数据集。训练text-to-cad模型需要海量“文本-模型”配对数据Zoo那边用了HuggingFace上的2700万个CAD模型做训练集虽然数据噪声很大但量级摆在那里模型能学到的东西完全不一样。第三块是3D打印硬件的普及生成出来的STL文件可以直接进切片软件验证这让text-to-cad从一个学术demo变成了人人可上手的东西。换句话说text-to-cad是继文本生成图片、文本生成视频之后AIGC往三维实体世界延伸的自然一步。图片生成解决的是“视觉草图”text-to-cad解决的是“能摸到、能打印、能装配的实体”。2. 主流路线的技术拆解2.1 端到端生成派把网格当成语言来生成Zoo Text-to-CAD和MeshGPT这类项目走的是端到端路线输入文本输出网格中间不经过任何显式的CAD操作。这背后的核心思路是——把三维网格当成一种“语言”来处理。具体怎么做呢三维模型本身是由一堆三角形面片组成的每个三角形有三个顶点坐标和法线信息。如果把这些三角形按顺序排列起来本质上就是一个token序列和自然语言的词序列没有本质区别。于是你可以直接套用Transformer架构训练一个模型去预测“下一个最合理的三角形”是什么。MeshGPT用的就是这个思路它先用一个类似VAE的结构把三角形序列压缩成离散码本再让Transformer在码本空间里生成最后解码成网格。Zoo Text-to-CAD的不同之处在于它在训练时加入了一个强化学习对齐环节。第一步是在海量CAD数据上预训练生成能力第二步是让人类给生成结果打分再用打分信号通过强化学习调整模型让模型逐渐偏向“人类觉得好看、好用”的输出方向。这一步在实际体验中感受非常明显Zoo生成出来的模型虽然偶尔也会有奇怪的拓扑问题但整体观感比早期方案好了太多。端到端路线的优点在于灵活什么形状都能试着生成不用局限于预先定义的CAD操作模板。缺点也很突出生成的模型本质是三角网格没有参数化历史你没法回去修改某个特征尺寸而且遇到带精确装配关系的机械零件模型往往会把布尔运算搞砸。2.2 程序化语法派让大模型学会写CAD脚本另一条路线思路完全不一样——不让模型直接生成网格而是让大模型学会生成CAD脚本再由CAD内核去执行脚本、生成实体模型。比如让模型输出一段CadQuery Python代码或者OpenSCAD的脚本这些脚本内部写着“画一个矩形、拉伸30mm、打三个直径6mm的孔”跑一遍就能得到带完整特征历史的实体模型。这条路线的优势非常明显。第一是可修改性生成的是参数化脚本你改一个数字再跑一遍模型就变了这完全符合工程设计的习惯。第二是精度CAD内核执行的是精确的几何运算出来的模型是真正的B-Rep实体不是靠三角形拼接出来的近似表面。第三是约束可控脚本里加一句“保证最小壁厚不低于2mm”只要代码逻辑对出来的零件就能直接加工或打印。那为什么这条路线的热度好像没有端到端那么高关键瓶颈在于代码生成的正确率。大模型写代码本身就会出错写CadQuery这种相对小众的API更是容易出毛病。一个螺丝孔的位置算错一点整个零件就废了。目前我看到的可行做法是用RAG检索增强生成把常用CAD操作模板喂给大模型让它照着模板改参数而不是从零开始瞎写。这条路更适合偏机械结构和钣金件这类规则形状不适合做曲面造型。2.3 文本编码与几何对齐模型到底怎么“听懂”你的话不管是哪条路线都得先把自然语言变成模型能用的向量。这块技术上的关键点在于如何让文本编码器具备“几何感知”能力。通用文本编码器对“红色的球”和“直径30mm的球”的理解方式不太一样前者是视觉语义后者是带数值约束的工程语义。text-to-cad模型在预训练阶段通常会让编码器和几何解码器一起微调让文本向量在几何空间里形成有意义的分布。实测下来的感受是模型对名词和形容词的响应很好比如“圆角”“通孔”“法兰”但对数值的响应相当不稳定你说直径10mm它可能给你一个直径8到12mm之间的结果。这一点后面会讲到怎么用提示词去弥补。文本编码这块还有个有意思的细节CLIP这样的模型本身是在“图片-文本”对上训练的而CAD数据集里往往没有对应的渲染图很多项目会用离线渲染器把模型渲染成多视角图片再拿CLIP做对齐。这就解释了为什么text-to-cad模型对纯文本输入的泛化能力有限——它实际上是从文字跳到图片语义再跳到几何中间的损耗不小。3. 亲手跑通一个text-to-cad项目3.1 环境准备与模型下载以我实际跑过的Autodesk Zoo Text-to-CAD开源实现为例整个部署过程不算复杂但有几个坑值得提前说清楚。硬件方面显卡显存建议8GB以上。官方项目在推理时默认会加载一个较大规模的生成模型显存不够的话会直接OOM。没有独显的机器也能跑但生成一个模型可能要等上好几分钟甚至更久我试过在仅有CPU的云主机上跑256分辨率的输出等了大约十分钟体验比较煎熬。内存建议16GB起磁盘预留10GB以上因为模型文件和依赖库都不算小。环境方面Python建议直接用3.10或3.11太旧的版本容易跟新依赖冲突。创建好虚拟环境后按官方README安装PyTorch和对应的依赖包即可。需要注意的一点是项目里的依赖清单里有些包的版本是写死的如果你用了最新的CUDA版本和最新版PyTorch可能会出现某个包编译不过的问题。稳妥的做法是照README里锁定的版本装不要自己升级。模型权重一般需要从HuggingFace下载国内网络环境可能需要配置镜像。下载过程比较考验耐心模型文件有好几个GB断点续传不一定可靠建议用HF的下载工具而不是直接wget避免下到一半失败还要重来。下载完成后把权重放在项目指定的目录再跑一个小demo确认加载成功。3.2 用自然语言生成第一个STL模型环境配好之后真正生成模型倒是非常快的。Zoo Text-to-CAD提供了一个命令行入口大致用法是这样python generate.py --prompt a rounded rectangular box with four mounting holes in the corners --output output.stl --resolution 256如果你想一次性生成多个候选再加一个batch参数就行。我当时第一次跑的时候输入的描述是“一个圆柱形的齿轮中心有通孔齿数为20”等了大约三四十秒输出目录里多了一个STL文件。把文件拖进MeshLab或者Windows自带的3D查看器里一看整体形状是对劲的齿轮的齿形也能看出来但齿数并没有严格等于20大概数了一下是18个齿。这就是前面提到的数值不稳定问题工程上还需要后续校准。项目也自带了一个Gradio界面跑起来之后在浏览器里输入文字就能看到生成的三维预览。这个界面我用得反而更多因为可以直接在网页上旋转、放大查看模型的细节比每次命令行生成完再开外部软件检查要高效很多。界面里通常还有一个seed参数seed不同即使同样的文本描述生成的结果也会有差异。多试几个seed再挑一个最好的这是最实用的用法。3.3 把生成结果变成可打印零件生成STL只是第一步能不能真正打印出来还要过切片软件这一关。我用OrcaSlicer和PrusaSlicer分别验证过几个生成模型整体感受是形状简单的模型问题不大稍微复杂的模型就容易踩到“非水密”的坑。所谓的非水密通俗讲就是网格模型存在空洞空气能从表面漏进去。切片软件在计算层高和填充的时候默认模型是实心的一旦网格有破洞切片结果就会出现各种奇怪的问题比如某几层突然只有轮廓没有填充或者打印路径直接乱掉。解决办法有两个方向一是用网格修复工具比如微软的3D Builder、MeshLab、Blender的3D打印工具箱跑一遍自动修复二是在生成的时候尽量提高分辨率Zoo里256分辨率比128分辨率生成出来的网格质量高不少虽然生成时间也相应增加。壁厚是另一个大问题。AI生成的模型往往追求“形似”不会主动考虑打印工艺里的最小壁厚约束。我试过生成一个壁厚不足1mm的薄壳结构切片软件倒是能切出来但打印的时候因为层间粘附力不够直接就打穿了一层。所以打印之前最好在切片软件里仔细看几层截面图确认最薄的位置能不能打。与其后期修补不如在提示词阶段就加一句“所有壁厚不小于2mm”让模型从源头避开这个坑。4. 提示词工程与生成质量控制4.1 给AI写CAD描述的四个要点text-to-cad模型的生成质量很大程度上不取决于你用了多贵的显卡而取决于你的提示词怎么写。我试了非常多组不同的描述方式总结下来好的CAD提示词必须包含以下四类信息。一是尺寸信息。默认情况下你不写尺寸模型会自己发挥一个比例。虽然生成出来的模型也是长宽高俱全但很可能完全不符合你的要求。二是拓扑结构。中文里说“钻四个孔”没问题AI也懂但如果你说“在底板的四角各打一个贯穿孔”生成成功率会明显提高——它把空间关系说得更清楚了。三是相对方位。描述清楚部件之间是上下堆叠、左右对齐还是插入关系。四是工艺约束。比如最小壁厚、是否有倒角、是否需要圆角过渡这些词对最终模型的可用性影响极大。我自己的习惯是默认写一个完整的句式模板先给整体形状和类别再给主体尺寸然后描述特征位置最后给约束条件。举个例子“一个L型角码主体尺寸60mm乘以40mm厚度5mm两条边上各有两个直径4mm的安装孔所有外角倒圆角R3。”这么一段话写完生成的模型基本不会跑偏太远。4.2 尺寸与基本面约束的语言表达尺寸在text-to-cad里面是个“玄学”。第一版你写“直径10mm的孔”可能出来一个8mm的不写尺寸它可能出来一个直径20mm的。我的实测经验是模型对“大于”“小于”“左右”这类模糊词的理解完全不可控反而直接写具体数值会好一些但也只能保证“大致在那个量级”。有个比较有效的技巧是给整体外加一个包围盒约束。比如在提示词末尾加上“整体轮廓在80mm乘60mm乘30mm以内”模型会更倾向于把内部的特征尺寸按比例缩小而不是某一个孔突然特别大。另一个技巧是多次生成再筛选——生成时开batch一次出来好几个候选然后统一量一下尺寸挑一个最接近的。单位问题也要注意。模型训练数据里混杂了英寸和毫米两种单位体系的描述所以同样一句“长度为30”它可能按英寸理解也可能按毫米理解。保险的做法是把单位写清楚并同时给出一种隐性的尺度参照例如“一个能握在手里的鼠标外壳长宽高约120mm、60mm、35mm”。这样模型既知道物理尺度又知道它在真实世界里的比例关系。4.3 多部件组合描述的常见坑多部件描述是提示词翻车的高发区。最典型的问题就是你说“一个桌子的桌面和四条腿”模型生成出来的结果经常是四条腿跟桌面融合成一体分界处完全没有间隙看起来像一个奇怪的雕塑而不是能组装的桌子。这背后的原因是AI生成的是三角形网格它并没有“装配体”的概念所有部分默认是一个水密的整体形状。我刚开始也在这个问题上浪费了不少时间后来总结出一个可行的替代方案把复杂模型拆成多个子部件分别生成再用简单的布尔运算或者手工拼接组合起来。比如做一个带把手的杯子先用“一个圆柱形杯身直径70mm高100mm壁厚3mm顶部开口”生成杯身再用“一个U形把手整体宽度30mm厚度8mm”生成把手最后在Blender里把两个模型拼在一起。这种方式虽然多几步操作但每个子部件都能保持相对干净的质量比一次性让AI生成整杯子的成功率高出太多了。另外一个常见的坑是方向歧义。描述“在顶部开一个直径10mm的圆孔”时模型可能把孔开在侧面因为它对“顶部”的理解依赖于坐标轴的隐含假设。对策是尽量用绝对的方位描述比如“在Z轴正方向的那一面开孔”或者“在圆柱体的端面上开孔”这类描述通常会得到更稳定的结果。5. 常见问题和排查实录5.1 生成结果不水密或破孔这是text-to-cad生成结果里最普遍的问题没有之一。三角网格模型在训练和生成过程中偶尔会出现面片重叠、顶点错位、法线反向的情况导致切片软件把它判定为破损模型。我的排查顺序是固定的先把模型导进MeshLab用“Mesh Repair”那一组工具跑一遍自动修复如果还不行就用Blender的3D打印工具箱逐个检查非流形边和锐边最后实在救不回来就回炉重新生成加一个“这是一个封闭的实体模型”的提示词。注意加这句话确实有用虽然听起来很玄学但模型在生成时确实会倾向于输出更封闭的网格。如果是打印这种用途还有一个更省事的工具微软的3D Builder。这个软件虽然看起来不起眼但对网格的自动修复能力相当强很多MeshLab处理不好的模型扔进3D Builder点一下“修复”就全搞定了。这个工具是我在打印现场发现的神器推荐大家都装一个。5.2 生成模型比例失控比例失控的表现有两种一种是整体尺寸和预期差一个数量级你想要的100mm的零件它给你生成10mm的另一种是内部特征尺寸离谱比如一个60mm长的零件上打了直径30mm的孔。第一种情况主要靠包围盒约束解决。在提示词里明确写出“整体最大尺寸不超过100mm”这类描述模型在生成时会把这个约束作为整体强约束来遵循。第二种情况比较难搞因为生成模型对部件间的相对比例理解确实不够好。我的办法是提前在提示词里把孔和主体的比例关系写清楚不要只写孔径而是写成“直径为主体的五分之一”。数值形式的比例关系比绝对尺寸更稳定当生成器把主体放大或缩小时孔会跟随缩放比例就不会跑偏。如果你已经生成了但比例不对后处理也能救。用Blender或MeshLab对整个模型做等比缩放就能把整体尺寸拉回目标值。唯一要注意的是如果所有尺寸都乘以一个固定系数壁厚也会跟着变这可能会违反打印工艺的壁厚下限需要额外检查。5.3 生成结果是网格没法直接当CAD文件用这是最多人问的问题也是text-to-cad目前最大的边界。很多搞机械设计的人拿到STL文件之后第一反应是往SolidWorks里拖然后发现它只能当一个可视化的“小玩具”来看根本没法编辑特征更没法出工程图在软件里连剖视图都生成不了。原因前面已经说了STL是三角网格模型里面只记录了表面位置的离散采样点完全没有“拉伸”“旋转”“孔”“特征”这些参数化信息。而真正的CAD文件比如STEP、SLDPRT记录的是一个完整的建模历史过程是一个带逻辑的“故事”不是一个“照片”。现阶段想绕过这个限制有三条路。第一条是用程序化语法派的方案也就是让大模型直接生成CadQuery脚本输出的就是真正的参数化实体。第二条是用逆向曲面软件做模型转换把STL拟合成NURBS曲面再导出为STEP但这个过程对复杂模型来说误差很大。第三条也是我目前用得最多的就是调整预期——如果是做3D打印、手板验证、外观评审STL完全够用如果是做正式的开模件和工程交付直接用text-to-cad生成STL再转STEP这条路目前走不通不如老老实实让AI帮你生成CadQuery脚本框架然后你在CAD软件里修参数。5.4 生成速度慢、显存不足怎么办速度慢主要和三个因素有关模型尺寸、生成分辨率、显卡性能。Zoo Text-to-CAD的默认分辨率大概是256你降到128生成速度能快不少但网格质量肉眼可见地变粗糙。建议先把分辨率固定在256只通过调整seed和提示词来控质量不要轻易降分辨率。显存不足的问题有一个比较实用的变通办法用半精度加载模型。很多勾选了fp16/bf16这种半精度选项显存占用直接减半虽然生成结果的细节可能会有轻微损失但总比崩了要好。如果12GB显存都跑不动那大概率是某个库的版本不对导致显存泄漏重启进程或者换个PyTorch版本会有改善。CPU推理虽然慢但不是不能跑。我试过只用一个6核的CPU跑256分辨率一次生成大约要6到10分钟如果你只是做简单概念的筛选这个速度还是可以接受的。真正难受的是多候选批量生成一次开8个候选CPU模式下基本要挂机等一个小时。所以有显卡还是用显卡哪怕是一张老的1080Ti体验都完全不一样。6. 这个方向后续还能怎么玩6.1 从单向生成到交互式编辑闭环目前text-to-cad基本都是“一次性生成不满意就换个seed重来”本质上是一个单向通路缺少编辑能力。你想改某一个孔的直径只能重新输入一遍提示词碰运气这非常不像一个工程工具。现在已经有项目在做“生成-编辑”闭环了比如基于MeshAdapter这类组件的方案在保持整体拓扑结构不变的前提下把用户选中的局部区域用另一个文本描述重新生成。你可以跟它说“把这块凸起的部分改成圆角”模型会保留周边区域的状态只对选中区域做局部重生成。这个能力一旦成熟text-to-cad就从“概念生成器”进化成了“概念设计师”实用性会提升一个量级。我自己其实已经在工作流里模拟这个闭环了先生成一个大方向的模型导入Blender做粗略的局部修改再把修改后的模型图截出来配合文字描述让AI生成一版更接近的。虽然比较笨但确实比反复写提示词高效。等本地化编辑工具再成熟一点这一整套都能在GPU上实时完成。6.2 把text-to-cad当搜索引擎用第二个我觉得特别有潜力的方向是拿文本语义做CAD模型检索和资产复用。制造企业的历史图纸库里存着大量CAD文件很多时候工程师要找一个结构相似的零件只能在系统里输入型号、名称或者一层层翻目录效率非常低。text-to-cad背后的多模态模型如果反过来用就成了一个“语义搜索引擎”——你输入“带四个吊耳的底板”它直接匹配出库里所有符合这个描述的CAD文件不用人工打标签。这个方向意义在于它把“生成新模型”和“复用老模型”打通了。很多时候设计师要的不是从零生成而是“我记得以前有一个类似的件帮我找出来改一改”。语义检索比关键词检索强的地方在它能跨越描述方式的差异你说“法兰盘”还是“带安装孔的圆形连接件”都能找到同一个东西。我记得海外已经有创业公司在做这个方向把企业内部的模型库建立成文本索引再配合生成模型做“旧件变体”。这个玩法离钱更近落地场景也明确算是text-to-cad技术栈里商业价值最高的细分赛道之一。6.3 制造业和创客圈会分道走再往后看text-to-cad的演进路线大概率会分化成两条一条面向消费级和创客级市场追求的是快速、好玩、低门槛生成结果只要3D打印能通过就行另一条面向工业制造追求的是参数化特征、公差约束、可制造性分析和DFM检查生成结果必须直接能被CNC编程和开模流程接受。创客这边工具会越来越像一个“3D提示词玩具”和AI生图的使用逻辑完全一致生成完直接切片、打印、上手。工业那边端到端生成网格的路线短期内拿不到入场券反而是程序化语法派或者“LLMCAD API”的组合更有机会。大型CAD厂商也已经把生成式设计集成进了自己的生态它们手里有大量的参数化模板库和用户操作数据一旦接入大模型可以做到“用一句话调起一整套工程特征”这个护城河不是开源社区的小模型能轻易越过的。我个人的判断是未来半年到一年text-to-cad在消费端的体验还会有一次明显的跃升但在工业端的落地会慢很多。如果你想跟进这个方向建议把精力放在理解程序化生成和模型后处理这两条线上比纯等模型版本迭代要有用得多。最后分享一个我踩过几次坑之后才养成的习惯任何生成模型拿过来第一时间不是看它生成的模型多漂亮而是先看它能不能稳定地复现“你指定的孔位、尺寸、数量”这三个工程约束。只要这三个基本点过关后面的优化才有意义。text-to-cad当玩具玩怎么玩都行想让它真正干活还是得拿工程尺子去量它的输出在一次次的失败里把提示词打磨顺手。