先把话说清楚这两年text-to-cad这个词频繁出现在各种技术社区的讨论里不少朋友一上来就问我“能不能推荐一个工具输入一句话直接生成可编辑的CAD模型”。说实话目前还没有那种科幻电影里“说一句就给完整工程图”的成品软件但围绕这个方向的一系列模型、开源项目和实验性工作已经能把“文字描述”转化成看得见、摸得着的三维几何了甚至一部分能直接导出STEP、IGES这类CAD标准格式。这篇文章想做的就是把text-to-cad这个方向背后的技术逻辑、常见实现路径、工程落地时要注意的坑以及我自己实测下来的一些经验完整梳理一遍。不管你是搞机械设计的工程师还是做AI应用开发的程序员又或者只是对3D生成感兴趣的产品经理这篇内容应该都能给你省下不少自己摸索的时间。1. 先搞清楚难在哪传统CAD建模与text-to-cad的天然沟壑1.1 为什么CAD建模这么“反人类”如果你用过SolidWorks、Fusion 360或者FreeCAD应该能理解我的意思传统的参数化CAD建模本质上是一个“精确操作”的过程。你要画草图、标注尺寸、添加约束、拉伸切除、倒角圆角每一步都必须给出明确的数值和几何关系。软件不会猜测你脑子里想的那个“带四个圆角的金属支架”到底圆角是R2还是R5更不会主动帮你决定壁厚是3毫米还是5毫米。这种精确性保证了工程模型的可制造性和可装配性但代价就是学习曲线陡峭操作效率低入门门槛高。而自然语言描述恰恰是模糊的、定性的。你说“一个带安装孔的L形托架”不同工程师脑子里出现的模型可能完全不同——孔径多大多小L形两臂的比例是多少倒角要不要孔在什么位置这些信息全都没说清楚。所以text-to-cad的第一个难题跟图像生成不一样它不只是“生成一个看起来像的东西”而是要生成“一个符合工程语义、可以继续编辑、理论上能拿去加工的几何体”。这两个目标之间存在巨大的鸿沟。1.2 大模型时代为什么突然给了这个方向新机会大概在2023年前后text-to-cad方向的进展突然加速原因很直接大规模语言模型和跨模态模型尤其是CLIP这类文本-图像对齐模型成熟了3D生成领域又积累了一批可用的数据集和生成框架。以前做文本到3D常见的做法是检索——在模型库里找找有没有现成的、描述接近的模型找到就返回找不到就拉倒。现在不一样了扩散模型、隐式神经场这些生成式方法让“从零生成一个全新几何体”变成了可能AI不再只是做匹配而是真的在“创作”几何。不过要特别留意很多顶着text-to-cad名头的开源项目实际生成的是mesh或者点云并不是传统意义上CAD系统里的B-Rep边界表示模型。mesh和B-Rep的区别简单说就是mesh是一堆三角形面片的组合适合渲染和3D打印但丢给SolidWorks做参数化编辑基本不可能B-Rep才是CAD系统的核心数据格式包含精确的曲面方程和拓扑关系可以被特征树记录、被参数驱动修改。理解了这两个层次你就能看懂为什么有些demo看起来很惊艳真正落到工程流程里却用不上了。1.3 把text-to-cad理解成一个“跨模态翻译”任务我习惯把整个问题拆成四层来看这样不管是读论文还是看开源代码心里都有数第一层自然语言理解把用户输入的文字描述转成结构化的意图表示比如提取主体形状、关键特征、尺寸约束、空间关系。第二层三维几何表征选择用什么样的数据格式来表示要生成的模型比如体素网格、点云、隐式符号距离场、mesh、参数化特征序列等。第三层生成模型用什么样的生成框架来产出这个三维表征常见的有扩散模型、自回归模型、生成对抗网络、变分自编码器等。第四层CAD化后处理把生成的三维表征转换成真正的CAD格式并做拓扑修复、特征识别、参数化重建。每一层都有各自的坑。把文本理解做差了后面的生成再漂亮也是白搭表征方式选错了可能根本没法导出成可用的CAD文件生成模型能力不够出来的几何体漏洞百出、没法修复。所以我说text-to-cad不是一个“单一模型问题”而是一个“系统工程问题”这也是为什么目前成熟的商业化产品几乎为零——整条链路的难度远比表面看起来要大。2. 核心原理拆解从自然语言到三维几何的完整链路2.1 语言编码这关怎么过文本输入的第一步是编码目前主流做法是用预训练语言模型比如BERT、T5或者GPT系列把文字描述转成语义向量。这步听着简单但有个容易被忽视的细节预训练模型是在“通用语料”上训练的而CAD领域的描述往往有很强的行业特殊性比如“通孔”、“沉头孔”、“腰形槽”、“加强筋”这些词在通用语料里出现频率很低模型对它们的语义理解未必准确。我自己在实测里就遇到过很明显的例子输入“带沉头孔的不锈钢板”有些开源模型生成出来的孔是直的完全没有锥头段。后来我仔细检查了训练数据才发现模型训练时用的文本标注里很多“沉头孔”和“通孔”的标注是混用的标注人员自己都分不清。所以现在稍微靠谱一点的项目都会在语言编码前做一次领域适配比如用CAD领域的语料做继续预训练或者干脆手工构造一批模板描述来微调语言模型。这个细节看着不起眼但对生成结果的准确性影响非常大。2.2 三维表征选型体素、点云、隐式场还是参数化序列这是整个text-to-cad方向最核心的决策点我把几种主流方案摊开来讲。体素Voxel就是把三维空间划分成一个个小立方体格子每个格子标记是否被模型占据。优点是简单直观缺点也很明显——分辨率低的时候细节全丢分辨率高的内存爆炸。比如一个128x128x128的体素网格光布尔数据就超过200万项再往上加分辨率显存直接爆掉。所以纯体素方案在text-to-cad里基本已经边缘化了更多是作为辅助监督信号存在。点云Point Cloud用一组离散的三维点来表示表面。优点是可以直接利用点云处理网络缺点是没有拓扑连接关系后续重建曲面时需要额外的步骤判断哪些点属于同一张面。不过因为点云在自动驾驶、机器人领域积累了大量现成工具不少text-to-cad项目选择先“文生点云”再做表面重建。隐式神经场NeRF/SDF用神经网络表示一个符号距离场模型里每个点都能查出一个“到最近表面的带符号距离”。这种方法能生成任意拓扑的模型细节表现力强OpenAI的Shap-E、Point-E走的都是这个路子。缺点是查询速度慢而且直接拿到的隐含函数要转成mesh得靠Marching Cubes这类算法转出来的mesh质量也时好时坏。参数化特征序列这是目前最接近“真CAD”的方向。把CAD建模过程理解成一个操作序列比如“先画一个矩形草图拉伸10mm在顶面上再画一个圆拉伸切除5mm”。然后用自回归模型生成这个序列最后直接导入CAD软件执行得到的就是一个完整可编辑的特征树。代表工作有MIT那边的DeepCAD、Text2CAD这类研究。思路非常诱人但实现难度也最大——序列数据标注成本高模型生成的序列经常出现“执行到一半参数对不上”的尴尬情况。我在后面实操部分会专门讲这条路的坑和应对方法。三种方案怎么选取决于你最终要什么只是做视觉展示和3D打印点云网格重建就够了要进CAD软件做二次编辑那参数化特征序列才是真正的终点。2.3 生成模型这块扩散模型和自回归模型谁更香生成模型的选择跟三维表征是配套的。目前扩散模型在视觉生成领域占据了统治地位三维生成也大量复用这一套逻辑本质上是学习“从噪声分布逐步去噪到真实数据分布”的过程。但三维扩散模型的计算量比二维图像大得多一张512x512的图像代表的是26万个像素点而一个像样的三维模型往往需要数百万甚至上千万个面片所以大部分项目要么是在潜空间做扩散先压缩再生成要么是降低生成目标的分辨率来换取可行性。自回归模型在参数化特征序列方向更常见因为CAD特征序列本身就是类似语言的离散token序列。把每个特征操作和参数值都token化就能用训练语言模型的方式训练一个“CAD建模动作预测器”。这个思路跟“代码生成”本质上是一样的代码有语法规则CAD操作序列也有它的合法性约束。但代码生成错了顶多程序跑不通CAD操作序列错了可能直接生成一个无法挽救的破面模型所以对模型的约束要求更高需要引入物理约束和几何约束作为额外监督。2.4 从mesh到CAD后处理环节容易被人忽视很多开源项目只展示“文本进、mesh出”然后就说自己是text-to-cad。但真正要落地到工程流程必须把mesh转成B-Rep并且尽可能识别出可编辑的特征参数。这个逆过程叫“逆向工程Reverse Engineering”或者“B-Rep重建”难点在于mesh只是个三角形壳里面没有面的数学方程没有特征树也没有参数约束。我见过不少团队在这个环节翻车。一个从点云重建出来的曲面可能是由几百个微小的细分面片组成的导进SolidWorks后整个文件卡得动不了又或者重建结果虽然长得像但相邻面的边界没完全对齐一检查就有缝隙根本无法做后续的布尔运算。所以要做出真正能用的text-to-cad工具后处理环节其实要单独花大力气开发需要做特征识别认出哪些三角形属于同一个平面/圆柱面/圆锥面、拟合几何方程、重建拓扑关系、推断参数化特征树每一步都有专门的算法文献和工具库。3. 工程落地的现实路径几条值得关注的技术路线3.1 纯生成式路线从文本直接产出参数化特征序列这条路以DeepCAD和Text2CAD为代表核心思路是建立一个“CAD操作序列”数据集每个序列包含一系列图元绘制、尺寸标注、约束添加、拉伸切除等操作。训练时文本描述通过编码器转成向量和操作序列一起喂给自回归模型让模型学会“根据文字预测下一步应该做什么操作”。实测下来效果如何坦白说对简单零件轴套、垫片、简单支架这一类效果已经很不错了生成的模型在CAD软件里打开就是完整特征树可以随意修改参数。但遇到复杂造型、多特征交叉、非规则自由曲面效果就有点拉垮偶尔还会出现操作序列语法正确但几何结果完全不是想要东西的情况。另外这种方案极度依赖训练数据的质量目前公开的CAD序列数据集基本都来自参数化CAD建模大赛或者逆向工程自动生成覆盖的零件类型和行业特征有限。3.2 两阶段路线先“文生网格”再做“网格参数化”这种路线是从纯生成式方案妥协来的第一步用成熟的开源模型比如Shap-E、Meshy这一类工具快速从文本生成一个mesh第二步再用网格参数化工具比如FreeCAD里的一些逆向工程插件、或者商业软件如Geomagic Design X把mesh转成可编辑的B-Rep模型。这条路线最大的优势是每一阶段都有相对成熟的工具可以组合不用从零训练模型。缺点也很明显第一步生成的mesh质量直接决定了第二步的效果上限而通用文字描述生成的mesh在工程语义上往往漏洞百出——破面、自交、非流形结构、比例失调都很常见。你拿着这种网格去做参数化逆向工具经常识别出几百个毫无意义的曲面片或者直接提示“无法识别”。我自己测试过几轮用同样的文字描述“盘类零件直径80mm中心通孔直径20mm四个等距分布的M6螺纹孔”不同网格生成工具出来的结果差异极大有的能一眼认出特征有的完全乱来。所以两阶段方案现阶段更适合做“概念原型验证”或者“非标快速设计”离“生成即生产”还差着距离。3.3 模板驱动路线在特定领域里先把问题约束住我自己实际做项目时发现最靠谱的还是模板驱动方案。思路是用一个预定义参数化模板库每个模板对应一类常见零件法兰盘、托架、齿轮坯、轴套等文本理解模型只负责判断“用户想要哪类零件”以及“用户提到的关键尺寸和特征参数是多少”然后把参数填进模板生成模型。打个比方你让模型“生成一个带六个均布孔的圆形法兰”文本理解模块识别出模板类别是“法兰盘”再抽取关键参数“孔数6”剩下的孔直径、法兰外径、厚度这些没有提到的都用默认值填充。这种方案看似不够“酷”但胜在稳定可靠生成结果永远是完整的、参数化的、可加工的模型而且文本理解的难度大幅下降——你不需要模型理解千变万化的几何语义只需要做分类和关键参数抽取。模板驱动路线适合的场景是企业内部小范围的自动化设计工具比如为某个标准件系列或客户定制件做“自然语言选型和参数化出图”。它解决不了完全自由的文本到CAD生成问题但能以极低成本创造实际工程价值。如果你要做商业落地我非常建议先从这种路线切入。4. 实操案例我实际搭建的一个最小可用text-to-cad流程4.1 环境准备和技术选型为了验证上面这些思路我自己搭过一个最小可用的实验流程用的全部是开源工具目标很简单输入“一个直径50mm、厚10mm、中心通孔直径10mm的圆柱法兰”输出一个能在FreeCAD里打开并编辑的实体模型。技术选型如下文本理解用了一个轻量级的中文文本分类模型微调了几百条我们自己的标注数据专门识别法兰、轴、套、板、支架这几类常见零件同时用正则加规则的方式提取直径、厚度、孔数、孔径等关键词参数。这块其实也可以用GPT-4级别的API直接做但我为了成本可控和部署方便选择了小模型规则兜底。参数化模板在FreeCAD里建了五个模板文件每个模板的参数都定义成了Spreadsheet电子表格里的单元格。法兰模板的参数就是外径、厚度、中心孔径、螺栓孔数、螺栓孔径、螺栓分布圆直径、倒角大小。执行逻辑文本理解模块识别出的类目和参数会生成一个JSON然后一个Python脚本用FreeCAD的Python API打开对应模板修改Spreadsheet里的参数值重新计算f.recompute()最后导出成STEP和STL。整个流程跑起来单次从文本到出模型大概3秒以内模型的每个参数都能在FreeCAD里看到和修改这让我第一次真正感受到text-to-cad在工程上落地的可能性。4.2 核心代码思路和参数提取逻辑参数提取这块我踩过很多坑。一开始我试图完全靠大语言模型来抽取参数发现它的输出不稳定同样的描述换个说法返回的JSON字段就变了。后来改成“小模型做意图分类正则表达式做参数抽取”的组合稳定性大幅提升。正则表达式的规则其实很简单比如外径.*?(\d{2,3})\s*(?:mm|毫米)用来匹配“外径50mm”里的数字“螺栓孔\D{0,6}(\d)\D{0,6}孔”用来匹配孔数。但中文描述实在太灵活什么“六个孔”、“6个均匀分布的孔”、“均布六个M6孔”都指向同一个意思规则得写很多变体还要考虑缺省值的情况。我的策略是能抽到的参数就填用户值抽不到的用模板默认值同时把“哪些参数是用户提到的、哪些是默认值”记录在日志里方便后续人工审核。这部分的代码我给个简化版思路def parse_params(text): params { outer_diameter: 60, # 默认值 thickness: 10, center_hole_diameter: 20, bolt_count: 4, bolt_diameter: 6, bolt_circle_diameter: 50, chamfer: 1.5 } if 外径 in text: m re.search(r外径\D{0,6}(\d)\s*(?:mm|毫米)?, text) if m: params[outer_diameter] int(m.group(1)) if 厚 in text: m re.search(r厚\D{0,4}(\d)\s*(?:mm|毫米)?, text) if m: params[thickness] int(m.group(1)) # 其余参数按同样逻辑处理 return params用这种思路扩展十来行代码就能覆盖大部分描述方式。要注意的是正则规则写的顺序要先长后短、先具体后通用避免“外径50mm”被“孔50mm”的规则先匹配掉。这些细节不值钱但真能决定工具好不好用。4.3 FreeCAD脚本化调用的几个关键细节FreeCAD的Python API跟很多CAD软件相比文档算是不太友好的这里把容易踩的坑提前说一下。首先是打开模板并修改Spreadsheet参数的代码import FreeCAD as App import FreeCADGui as Gui doc App.openDocument(flange_template.FCStd) sheet doc.getObject(Parameters) sheet.set(outer_diameter, str(params[outer_diameter])) sheet.set(thickness, str(params[thickness])) doc.recompute() doc.saveAs(output.FCStd)注意set函数里传的是字符串不是数字我第一次用的时候传整数结果Spreadsheet单元格显示正常但参数驱动没有生效排查了很久才发现是类型问题。另一个关键是recompute()之后一定要检查模型有没有报错。参数改得太极限比如外径改成10毫米但螺栓分布圆直径还是50毫米会导致几何生成失败FreeCAD不会主动告诉你只是模型变成红色或者部件树里出现警告符号。所以我在脚本里加了校验逻辑检查模型的Shape.Volume是否大于0以及有没有null shape之类的异常。导出STEP文件的代码import Import Import.export([doc.getObject(Body)], output.step)这个接口的名字就叫Import第一次不熟悉的人很容易找不到。导出的STEP文件可以被所有主流CAD软件直接打开而且保留特征树和参数信息这才是真正的“CAD模型”不是一堆三角形面片。4.4 测试效果和局限实测跑下来对法兰、轴套、垫片这几类简单零件文本描述跟真实生成结果的匹配度大概有八成以上剩下两成主要差在用户描述了模板不支持的参数比如“双排螺栓孔”。对超出模板范围的零件系统会直接提示“暂不支持该类型”不会硬生成一个垃圾结果凑数。这套流程的局限也很明显模板覆盖的零件类别有限规则引擎能理解的描述方式也有限整体泛化能力跟论文里那种“任意文本生成任意模型”差了十万八千里。但作为工程验证至少证明了text-to-cad在特定场景下可以做到“能用、可控、可解释”。5. 常见问题与排查技巧实录5.1 描述模糊导致的生成偏差这个问题在自由生成路线里极其常见。你输入“一个有趣的支架”或者“一个现代风格的桌面金属零件”模型根本不知道你在说什么。目前所有靠谱的方案都要求文本描述在功能语义上尽量明确比如“一个带四个安装孔的直角支架一边长100mm另一边长80mm厚5mm”。所以我的建议是在面向用户的输入界面里一定要做结构化引导比如提供“零件类型下拉框参数填空自由描述框”的组合而不是给一个朴素的文本输入框让AI自由发挥。越是给用户无限自由生成结果越失控这跟很多做文生图产品的公司踩过的坑是一样的。5.2 几何错误和拓扑问题排查生成网格模型时常见的几何错误有自交面面片互相穿透、非流形边一条边连接了三个或更多的面、孤立顶点、法线翻转。这些错误会导致导出STL后切片软件崩溃或者导入CAD后无法执行后续操作。排查方法我推荐两板斧一是用Meshlab的“Cleaning and Repairing”菜单做自动修复它能处理大部分简单问题二是写一个简单的检测脚本遍历所有三角形检查单条边关联的面数是否不等于2如果是就标记为非流形。修复非流形边没有万能算法很多时候得人工介入所以我的经验是“尽量在生成阶段避免而不是在后期修复”。5.3 文本描述里的尺寸尺度不一致这是个很隐蔽但很要命的坑。用户描述“直径5厘米的套筒”模型生成出来的可能是个5毫米的小东西因为训练数据里很多标注根本没写明单位模型默认以为数值对应的就是基准单位。更麻烦的是有些模型内部用归一化坐标跟物理尺寸之间根本没有确定的映射导出的STL模型实际大小完全看随机性。解决方案是在生成模型和应用层之间增加一个“尺寸校准层”。比如输入里如果检测到“毫米”、“cm”、“英寸”这类单位词先统一换算成毫米再决定缩放倍数。如果输入没有单位词就用默认合理尺度比如中等零件100mm左右做基准同时把实际尺寸写进输出的元数据避免下游环节拿到的模型尺寸完全对不上。5.4 显存和算力不够时的工程化降级方案三维生成模型对显存的要求普遍不低一个能用扩散模型生成小尺寸体素或mes h的实验环境至少需要8GB以上显存复杂的模型24GB也未必够用。对个人开发者来说成本确实有点高。我的实操建议是三步降级第一尽量用潜空间扩散模型而不是原始空间扩散模型能省不少显存第二把生成分辨率分成两阶段先低分辨率快速出一个轮廓再在局部区域做高分辨率细化第三如果条件实在有限直接用现成的API服务做第一阶段的“文生网格”本地只跑参数化重建这样对硬件要求最低。6. 后续可以扩展的方向和个人一点真实体会6.1 从零件级走向组件级目前text-to-cad的研究基本都在“单个零件”这个尺度上但工业设计里更常见的是“装配体”——一个产品由多个零件组成零件之间还有配合关系螺丝拧进螺纹孔、轴穿过轴承位等。把文本生成扩展到装配体的难度不只是生成多个零件还要在语义层面理解零件之间的约束关系比如“这个孔是为了跟那个轴配合的”这需要额外的关系建模和约束求解能力。我觉得未来如果哪个团队在这个方向上做出突破那才真正的改变设计流程。6.2 和逆向工程、自动化仿真做结合另一个值得关注的方向是把text-to-cad跟仿真分析打通。以前设计一个零件要先建模再仿真流程很长。如果文本能直接生成可仿真的模型就能快速迭代多个方案——“这个支架太重了减重20%”“这个圆角加大一点看看应力集中是否改善”把设计意图用自然语言直接表达让工具自动完成修改和仿真验证。虽然离产品化还有距离但这个闭环一旦跑通对中小企业的设计能力会是巨大的杠杆。6.3 我在实际使用中的几点体会零零散散写了这么多最后分享几条真正有价值的经验。第一别迷信端到端模型分阶段拆解、每个环节用最合适的工具整体效果远好于一个“全能大模型”这跟做菜一个道理好的食材分开处理再组合比一股脑全下锅强。第二文本描述的质量决定结果的上限投入精力做一套好的输入模板比花大把时间调模型参数更划算。第三任何生成结果都必须走一遍“CAD软件打开–检查特征树–重新计算尺寸”这样的验证流程肉眼看着像没有用工程上必须能打开、能编辑、能出图、能对接加工缺任何一环前面的工作都等于白做。text-to-cad这条路还很长但现在恰恰是入局的好时机工具链在快速成熟数据也在不断积累谁先找到适合自己的场景把它落地谁就能在这波生成式设计浪潮里站住脚。
