★ FEATURED ARTICLE 最近大半年“text-to-cad”这个词在CAD圈子里出现的频率越来越高。起因很简单想做一个零件不想打开SolidWorks一点点拉草图、标约束、选拉伸深度而是直接敲一句话——一个直径40mm、厚度5mm的带法兰圆盘——然后让AI把模型建好。听起来很玄乎但实测下来已经不是纯概念了有些项目确实能端到端跑通输出可以直接拿去3D打印或者做结构分析。这篇文章我从技术原理、主流实现、实测过程到落地姿势完整拆一遍这个方向。适合三类人看搞AI应用开发想找新场景的、做机械设计想用AI提效的、以及纯粹对自然语言转三维模型这个技术方向感兴趣的爱好者。先说结论这条路目前还做不到替代人工建模但作为快速验证和探索工具已经实用化了。1. 从画图到写作文text-to-cad到底在解决什么痛点1.1 CAD学习曲线的隐性成本CAD建模真正的难点不在画线本身而在约束思维。你画一条线系统只记录坐标但你要的是这条线相对于其他特征的位置关系、尺寸关联、修改后能否自动更新。这个思维转换初学者至少需要几周才能适应。熟练CAD工程师做一个中等复杂度的零件快则十几分钟慢则一两个小时大部分时间其实没有在建模而是在做拆分把脑子里想好的零件拆成草图、拉伸、切除、圆角、阵列这些特征操作再逐个命令喂给软件。text-to-cad想省掉的恰好是这层操作转化。它的思路很激进用户脑中的设计意图是自然语言形式的机器理解语言的能力现在成熟了那就让机器直接去生成建模程序替我完成特征拆分和参数定义。1.2 参数化模板为什么不够有人会问传统参数化设计不是早就实现了改个参数自动变模型吗比如一个法兰盘模板改直径、改孔数几十秒就能出一堆变体。但参数化模板的局限很明显模板只能覆盖预先定义好的结构。你今天要变体法兰盘明天要变体齿轮箱壳后天来一个异形支架每个都得手搭模板这个前置成本极高。而且模板内置的设计逻辑一旦固化很难模仿一个新手设计师换个思路重新做的状态。text-to-cad的价值在于把写模板这个行为本身自动化。它不是在给定参数集合里调参而是从语言描述中重新推断出建模步骤。这相当于把一个可以用自然语言重新描述的零件都变成了隐式参数化模型。实测下来它的优势不在精度而在覆盖率你不需要预先给每种结构准备模板。1.3 text-to-cad的三种输出形态理解这个方向之前必须分清输出形态。目前业内主流有三种生成构造历史序列CAD命令流输出一组建模操作步骤比如创建草图、定义圆、拉伸15mm、切两个通孔类似用脚本控制CAD软件。代表是Text2CAD项目输出DeepCAD格式。生成程序化建模代码输出一段代码脚本比如OpenSCAD或CadQuery代码执行后生成三维模型。代表是ZOO项目的Text-to-CAD输出JSON格式的几何描述并转成OpenSCAD代码。生成中间表示体素/点云/网格再转CAD先用扩散模型或GAN生成体素或点云表示再逆向重建为CAD实体。这个路线目前研究多、落地少因为从网格转B-rep边界表示CAD软件内部真正的数据格式成功率不高需要后处理。三种路线对应不同的工程成本。第一种最接近真正的CAD——因为构造历史可以进特征树能改参数重编辑第二种最灵活——代码即模型版本管理都方便第三种最直觉但是几何质量最不稳定。选型时建议优先考虑前两种。2. 一篇论文和一票工程实现主流技术路线的底层逻辑2.1 Text2CAD为什么把建模拆成序列生成而不是图像生成Text2CAD是最早把这个方向做成完整系统的工作之一核心思路来自卡内基梅隆大学的研究团队。他们没走文生3D那套扩散模型路线——给一组噪声点让模型去噪出一个体素网格——而是选择让大语言模型直接输出CAD建模命令序列。这个选择的根本原因在于CAD模型和图像、网格的数学本质完全不同。一张图片可以用像素矩阵精确描述体素化之后每个格子有一个占据值但CAD模型在计算机内部的真实表示是边界表示B-rep由拓扑面、边、顶点和NURBS曲面构成是一个复杂的图结构不是均匀网格。如果先生成网格再转B-rep精度损失和重建难度都是灾难级的。反过来想CAD建模软件里每一根轴、每一个拉伸特征的背后都对应一条命令比如AddSketch、AddCircle、AddExtrude。如果模型能把一段自然语言映射成一系列CAD命令行那渲染出来一定是CAD原生的、可直接编辑的实体。LLM做序列生成的能力已经过验证因此Text2CAD选择了生成CAD构造序列。训练数据用的是DeepCAD数据集里面有大几十万条从Onshape导出的真实建模构造历史每条记录都包含完整的命令序列和对应模型。它们把建模过程抽象成标记序列Sketch命令、Circle命令、Extrude命令、布尔运算命令依次排列LLM的训练目标就是给定语言描述预测后续命令序列。这个思路相当于把三维建模问题降维成了用语言写程序设计说明书——很适合大语言模型。2.2 数据从哪来DeepCAD数据集与监督信号的价值想训练一个描述-建模步骤的映射模型你得先有大量描述-建模步骤对。CAD建模数据的获取难度远超图像网上没有铺天盖地标注好的STEP/IGES文件可以拿来做训练集。DeepCAD就是解决数据问题的关键。它从Onshape公开的模型库中提取了大约17万条真实CAD建模过程每条记录包含完整的构造历史树以序列化的JSON形式保存。这个数据的质量直接影响最终模型能力。我在本地跑过DeepCAD的样例数据格式长这样一个模型会被拆成多个featureSketchExtrude以及布尔运算、圆角、倒角、孔等操作每个feature内部有参数数组比如圆的半径、拉伸高度模型之间以CSG构造实体几何的形式组织有了这个数据Text2CAD只需要把原始的构造序列「翻译」成自然语言描述再训练一个翻译模型即可。它用了一个课程学习策略先用简单模型两三个特征的训练再交给更复杂的模型最后全量训练避免模型一开始就被复杂序列搞懵。这里有一个值得关注的工程技巧训练时给LLM输入的不只是文本还拼接了一个基于视觉语言模型VLM生成的模型特征编码。也就是说它先让VLM看一遍渲染出的模型图像总结出关键特征再把这些特征描述作为额外提示词送给生成器。这个做法大幅缓解了纯文本描述和三维几何之间的信息鸿沟——因为同一句话带圆角的盒子在不同人的脑补里长得完全不一样但看一眼图就清楚了。2.3 ZOO项目视觉语言模型代码解释器的跑偏修正闭环如果说Text2CAD是学术界对端到端生成CAD的答卷那么ZOO项目的Text-to-CAD就是工业界产品化的代表。它的架构和Text2CAD有个关键区别不直接让模型生成CAD构造序列而是让GPT-4级别的视觉语言模型去生成OpenSCAD代码然后通过Python代码解释器执行再用渲染引擎把结果渲染成2D图片喂给模型自己检查——不对就迭代修改。这个生成-执行-渲染-反馈-再生成的闭环非常有意思。它解决了一个实际问题纯语言模型生成几何代码时经常出现代码语法对但几何语义错的情况比如两个布尔对象方向反了、坐标系搞错了这类错误靠语言模型自己很难在生成阶段发现但如果你把代码执行后的3D模型渲染出来和用户给的参考图做视觉对比错误就一目了然了。我在实际测试ZOO的过程中发现它的处理管线大体分四步用户输入文本可配图片模型生成初始OpenSCAD代码代码解释器执行代码生成模型渲染器出图模型对比渲染图 vs 期望来修正加上文本一致性打分这比直接输出代码再丢给你自己检查要强太多。它能自己检查作业把不可见的几何错误变成可见的视觉偏差然后循环修正。2.4 三条路线综合评估路线代表项目核心技术优点当前短板适合场景构造序列生成Text2CADLLM VLM 构造历史数据集输出是原生CAD特征树可直接编辑生成成功率约五成复杂模型易崩需要继续编辑、出工程图的场景代码生成自动修正ZOOVLM Code Interpreter 渲染闭环生成质量高有自我修正机制强制依赖高精度VLMAPI成本高快速概念设计、免编辑的单体件网格/体素生成文生3D类产品扩散模型形状自由度高输出是mesh而非B-rep无法CAD编辑可视化展示、动画场景非CAD需求选型建议如果你最终产物要进加工或出工程图优先考虑路线一如果只是概念验证、3D打印路线二足够灵活路线三目前基本不适合作为CAD生产力工具。3. 真正落地时绕不过的工程细节量纲、基准面与歧义3.1 自然语言里缺失的几何投影我最早测试text-to-cad时踩过一个大坑输入一个在顶面中间的直径10mm的孔模型生成出来孔跑到侧面去了。仔细一想问题其实出在语言本身——顶面中间这四个字在自然语言里看似明确但在三维空间中顶面到底指Y轴正方向还是Z轴正方向取决于建模者怎么摆坐标系。语言里缺了方向信息模型只能按训练数据的统计偏好猜。这暴露了text-to-cad的一个深层次问题自然语言是不完全投影。人类大脑做的是把模糊语言补全成完整几何而机器只能靠先验概率去猜。对哪个面是顶面这种问题不同的CAD软件、不同的模板建立习惯答案都不一样。实测建议描述零件时尽量显式给出基准面方向和尺寸比如以XY平面为底面、沿Z轴向上拉伸20mm准确率会大幅提升别用中间、旁边、差不多这类模糊词尽量用中心、距左端10mm这种可量化的表述如果工具支持配参考图强烈建议配图。一张草图/截图能消掉80%的歧义3.2 从文本到参数让LLM输出结构化数据目前在text-to-cad工程实现里最稳妥的做法是让LLM生成结构化中间表示而不是自由文本代码。从生成稳定性角度看限制输出格式是提高成功率的关键。ZOO之所以成功率高是因为它强迫模型输出一个JSON结构里面包含类型如flange或bearing、参数直径、厚度、孔数、可选特性圆角、过滤网等再由解释器把JSON翻译成OpenSCAD代码。我们在本地复刻类似管线时发现把OpenSCAD代码生成任务降级为JSON定义能减少语法错误。因为LLM直接写几何代码容易在函数调用上出问题但填充JSON字段不容易错。还有一个小技巧给模型的prompt里加入例子few-shot提供两三个带完整参数定义的零件样例模型的遵循率会高很多。3.3 单位、坐标系与配合标准化的坑CAD模型讲究的是可配合。零件上的安装孔必须和对接件上的孔对得上轴和轴承要过盈配合。而text-to-cad在生成过程中对单位换算的容忍度很低。我遇到过最头疼的问题是单位错乱模型生成时把毫米当成英寸结果一个标注直径20mm的零件实际生成出来是20英寸——视觉效果差25.4倍。原因在于OpenSCAD本身是无单位制所有的数值依赖用户在场景里约定单位。建议在prompt里显式声明单位例如所有尺寸均以毫米为单位并在后处理代码里加一层比例尺。另一个经验是在生成JSON参数时把尺寸都写成带单位的形式如{diameter: {value: 20, unit: mm}}而不是裸数字这样即使模型理解错上下文后处理也能统一修正。3.4 输出必须是合法模型验证与修复链路text-to-cad生成的三维模型它输出的是三角网格Mesh不是CAD原生的B-rep实体。真正要进入CAD工作流就得做验证和修复。这套链路建议在管线中直接集成。我用过的验证工具主要是以下几个层次基础检查用MeshLab或CloudCompare检查网格是否封闭watertight、是否有非流形边、法线是否翻转轻度修复Blender的3D打印工具箱可以做去重叠面、补空洞这类基础修复严谨方案把网格导入SolidWorks/Fusion 360的曲面模块做曲面缝合生成真正的BREP实体。这个过程自动化程度有限但零件简单时成功率尚可网格生成和CAD实体之间还隔着一道曲面化工序。如果模型很复杂比如螺纹、齿轮齿形目前的方案还不具备可靠性如果只是一个简单的壳、板、法兰座这条链路是通的。你在选择模型生成方案时务必要看看它输出的到底是带特征树的CAD历史还是孤零零一个STL前者才是CAD原生格式后者只是一堆三角形。4. 实测踩坑记录我跑通一次text-to-cad的完整过程4.1 环境准备与模型选择我跑的是ZOO开源版代码在GitHub上可以直接拉下来跑。环境上主要需要Python 3.10OpenSCAD命令行以及一个可以调用视觉语言模型的API。硬件要求其实不高——因为LLM推理全走API本地只需要做渲染和执行。如果你完全在本地做推理那就得看模型规模了7B级别的小模型在语言理解上勉强够用但要表达复杂几何关系就明显吃力推荐直接用大模型API。配置OpenSCAD这一步容易卡壳。安装后一定要把OpenSCAD的可执行文件路径加到系统PATH里否则代码解释器执行openscad命令时会报命令未找到。另外OpenSCAD的渲染依赖CGAL库有些Linux环境下需要手动安装CGAL和Boost建议看官方issue列表别自己硬刚编译器。4.2 一次真实prompt从输入到STL的全程记录我挑了一个中等难度的描述一个圆柱体底座底部直径80mm、高10mm顶部中心有一个直径25mm的圆柱凸台凸台高30mm凸台顶部中心有一个直径10mm的通孔。把这段话喂给ZOO后系统走完整个流程语义解析出JSON参数底座外径80、高度10、凸台直径25、凸台高度30、孔径10生成OpenSCAD代码两个cylinder命令叠放 一个cylinder做差集布尔减代码解释器执行生成STL渲染器出图模型自动比对确认无误整个流程耗时约2分钟含API调用和渲染生成很顺利。这个模型的几何很简单——本质是两个圆柱叠起来再挖个孔属于text-to-cad最擅长处理的零件类型。但如果描述变成圆角过渡斜角切割阵列分布这类特征成功率就开始明显下降了。4.3 翻车案例非流形几何、浮空体、镜像翻转测试中有一个很典型的翻车案例。我输入一个L形支架由两块板组成一块垂直板120mm高、8mm厚、60mm宽一块水平板100mm长、8mm厚、60mm宽两块板沿边线连接。 系统生成的模型在预览图里看着像L形但导入到PrusaSlicer切片时直接报错——非流形边。用MeshLab检查后发现两块板的连接处没有做一个真正的融合而是生成了两个部分重叠的立方体边界处形成了悬空面和交错边。原因是OpenSCAD生成代码时用的是并排放置而不是并集布尔运算导致两个实体相交区域没形成水密边界。修复方法是在生成STL前用union()把它们做一次布尔合体。所以在你的代码生成prompt里一定要强调所有体素必须用布尔并集合并成一个实体这个提示词能显著减少非流形问题。另一个闹心的问题是镜像方向。一次描述里我说朝X轴正方向伸出凸台结果生成模型时凸台跑到了X轴负方向。这又是坐标系歧义问题没有可靠提示词能完全避免只能在渲染后加人眼检查。ZOO的自我修正环节对这类错误有一定作用但前提是你能提供一张参考图让它对比。4.4 后处理工具链与质量控制模型从生成到可用我的标准流程分三步几何检查用MeshLab打开STL看一眼Edges元素里有没有Non-Manifold Edges标记。如果有优先用参数化方法修复OpenSCAD加一句union而不是等切片的自动修复尺寸校准拿卡尺量一下生成模型的最大包络尺寸核验和输入值是否一致。因为OpenSCAD无单位制我在后处理脚本里统一乘以25.4英寸转毫米来校正单位切片验证直接在PrusaSlicer的修复环节做一次空切片看有没有自交面、悬空岛的警告。这一步能发现渲染预览看不到的体积问题这套链路走完模型才敢真正拿去加工。目前在简单件上的成功率一次生成直接可用大约只有30%但配合手动修复最终成品率能到70%以上。和传统建模比它省下的不是精度而是头脑到草图的中间过程。5. 把text-to-cad接进真实设计流程的三种姿势5.1 概念探索阶段快速生成多个候选人工挑选text-to-cad当前最划算的使用场景就是概念前期。传统做法是设计师脑子里有三个备选方案逐个建出来看效果——一个方案建完其他两个还没动。用text-to-cad快速敲把三个描述一次性发出去几分钟内就拿到三个对应的模型文件。重点是拿得到文件就能评估。这一步不追求精度也不追求可直接制造只为了看大致造型、比例、装配干涉。实测一个技能描述同一零件可以故意换说法比如带圆角的矩形盒子和四角R8倒角的方壳其实是同一个东西但模型生成的风格差异能提供意外灵感。这个用语言穷举变量的能力是传统建模工具不可能的——我手动改参数要半分钟生成一句新prompt只要十秒。5.2 参数驱动的变体设计怎么让文本语言和参数表共存到了后期零件往往要支持系列化变更孔距可变、长度可变、直径可选。text-to-cad如果只是一次性生成固定模型在这个环节就没有用武之地了。让我说清这一点真正有价值的做法是让它生成一个可参数化模板。你在prompt里明确定义变量名称比如以变量L为总长度以变量D为孔间距生成的OpenSCAD代码里会留下变量定义和赋值后续只要改.py里的数值模型自动更新。我在项目里做过类似实践输入一个带4个安装孔的面板长度L可调宽度W可调孔径固定Φ6生成的代码是含有变量L和W的OpenSCAD文件。之后每次改尺寸就在代码里调L 200W 150重新渲染即可。这个方案下text-to-cad本质上成了程序化建模的参数表编写工具。这比让模型每次从零生成一个模型要稳定得多——因为只有数值变化建模逻辑完全复用。5.3 再往后设计-仿真-生成闭环如果更长期地观察text-to-cad最有想象力的部分不是文本转摸具而是把CAD设计集成到更自动化的迭代流程。例如把生成模型直接送去跑有限元仿真仿真结果反馈给LLM太厚了削掉2mm这样反复几次就能自动得到一个满足强度要求且重量更小的零件。这种设计-仿真-再设计闭环人工参与成本极低本质上是在做优化设计。近期已有一些探索比如拿贝塞尔曲面做造型生成的论文以及把力学性能作为训练反馈的生成式设计工作。虽然离实用还早但方向和text-to-cad完全兼容。我的实操体会是不要指望text-to-cad一夜之间取代SW和CATIA但完全可以把它当做一个会看图说话的设计助手来用。一个新工程师把它作为帮你搭基础结构的工具能省出大量时间一个老工程师把它用作探索设计空间的加速器也能尝到甜头。顺着这个方向往下走从文字到图纸的门槛已经在明显下降剩下的就是谁先用起来、用出经验来。
阅读完成 · 觉得有帮助？
