★ FEATURED ARTICLE 去年我第一次看到text-to-cad这个词的时候第一反应是这玩意儿该不会又是拿大模型包装的玩具吧。毕竟AI生成图片、生成代码已经见怪不怪了但CAD这种精密到小数点后几位的工程文件怎么可能靠一句话就生成直到我实际跑通了一个开源项目对着命令行敲下一句一个带法兰盘的40mm管道接头真的给我输出一个可编辑的STEP文件时我才意识到这个方向不是噱头它真的在重构三维建模的起点。text-to-cad字面意思就是从文本到CAD模型。但它的价值不在于生成一个好看的形状而在于把自然语言转化为结构化的、可参数化、可继续编辑的工程模型。它不是生成一张图片让你看看效果而是生成了一个你能继续在SolidWorks、Fusion 360或者FreeCAD里二次修改的真实模型文件。这意味着什么意味着设计师可以把大部分重复性建模工作交给AI打底然后专注于修改和优化——就像代码生成工具不是替代程序员而是替代那些重复的CRUD接口一样。这篇文章我从实际应用的角度出发聊聊text-to-cad背后的技术逻辑、现有工具链怎么选、一个普通人怎么用最短路径跑通一个完整流程以及我在实际使用中踩过的那些坑。不管你是机械工程师、产品设计师还是纯粹对AICAD感兴趣的技术爱好者这篇内容应该都能给你一些实在的参考。1. 为什么text-to-cad突然火起来了1.1 建模工作的真实痛点做机械设计或者三维建模的朋友应该都有这种体验模型本身不复杂复杂的是那些照着规范搭积木的时间。标准件、法兰、螺纹孔、加强筋、安装凸台——这些结构用CAD软件画翻来覆去就是拉伸、旋转、倒角那几板斧但每换个尺寸、换个位置就要重新来一遍。我见过一个做了五年非标自动化设备的工程师一天八小时里至少有四个小时在画另存为修改版的重复模型。text-to-cad瞄准的正是这个环节。它不追求直接生成一个复杂的装配体而是先把单个零件的参数化建模这件事自动化。你描述功能需求它生成几何结构你拿到手之后微调参数继续用。这就像写代码从写一行行命令变成了你告诉助手我要一个读取CSV并画出折线图的脚本助手给你生成基础版你再改改样式和逻辑。从行业趋势来看制造业数字化走到今天瓶颈已经不是三维软件的功能了而是从需求描述到三维模型之间的转化效率。传统的转化路径是需求 → 图纸/草图 → 手工建模这条链路长且依赖个人经验。text-to-cad把路径压缩成了需求 → 模型生成。中间那一段画草图再拉伸切槽的机械劳动正在被模型吃掉。1.2 大模型技术怎么改变了CAD生成text-to-cad能火本质上是多模态大模型的成熟。过去搞CAD自动生成主流方案是参数化模板加规则引擎你定义好一类零件的所有参数程序根据输入参数自动调整尺寸。这套方案的优点是可控、精度高缺点是每新增一类零件就要写一套规则维护成本极高而且用户不可能把每个想法都描述成参数表。基于深度学习的三维生成则走了一条完全不同的路。它不依赖人去定义规则而是从海量三维数据中学习文本描述与几何结构之间的对应关系。你提到法兰盘模型内部并没有一个法兰盘的参数化模板它学到的是无数个法兰盘样本中提炼出的几何分布规律。这种思路最大的优势是泛化性哪怕你描述一个训练数据里从没出现过的新奇结构模型也能尝试组合它学到的几何特征给你拼出来。具体到技术实现目前主流做法是借助大语言模型作为中间翻译官。文本先被LLM理解并拆解成结构化的建模操作序列比如创建草图、画圆、拉伸、打孔、圆周阵列然后由另一个模块把这些操作序列转换成真正的几何实体。这个思路挺妙它实际上是把自然语言翻译成了CAD操作语言而不是直接生成网格或者点云这样出来的模型天然就是参数化可编辑的。2. 从文本到几何的技术链路拆解2.1 通俗理解文本是如何一步步变成模型的把text-to-cad的技术链路拆开看其实很像一个翻译公司在干活。第一层是理解你的话第二层是规划怎么画第三层是真正动手画。每一层干的事完全不一样但配合起来才是完整流程。理解层负责把你说的一个底座上有四个对称分布安装孔的方形法兰变成结构化的语义标签比如形状方形、基础特征法兰、孔数量4、阵列方式对称。这层现在基本都是靠大语言模型来做好在这些标签本身不是特别依赖物理常识只要语言理解能力强就行。规划层拿到语义标签后要把它变成建模指令序列。这层是技术难点所在因为同样一句话建模路径可以完全不同。用拉伸建模是一种做法用旋转建模又是另一种先从主视图画还是先建基准面最终模型的建模树长得完全不一样。目前开源的方案里大多是通过强化学习或者模仿学习让模型学会预测识图建模的数据集中人类工程师的操作步骤。换句话说这个层学的是人的建模习惯。执行层就比较实在了就是把规划好的指令逐条在CAD内核里执行。比如调用了Open CASCADE这样的几何内核创建草图、约束、拉伸、布尔运算一步步把几何实体真正构建出来最后导出成STEP或者BREP格式。这一步不涉及智能化纯粹是工程实现但容错率要求很高每一步操作参数的微小误差都会导致最终的实体出问题。2.2 主流技术路线对比分析目前市面上做text-to-cad的方案我大致分成三类各有取舍。第一类是LLM 程序化CAD库代表思路是让大语言模型直接生成一段构建脚本脚本调用CadQuery、build123d这样的Python库来建模。优点是很灵活模型不需要理解底层的B-Rep数据结构只要会用代码调库就行生成结果天然可参数化、可编辑。缺点是语言模型经常会在代码逻辑上犯迷糊生成一长串建模代码时容易在中间的坐标变换或者布尔运算上出错需要不断调试修复。第二类是端到端的几何生成直接从文本或者条件向量生成体素、点云或者三角网格然后通过逆向工程算法转成CAD模型。优点是形状自由度大能生成很自由曲面的形态缺点是转出来的STEP文件质量堪忧曲面很可能不是一个精确的解析曲面而是由大量小平面片近似组成的在工程软件里后续编辑麻烦。第三类是检索 参数化调整先在模型库中检索到最相近的模型然后用文本中提取的参数去驱动这个模型进行变体修改。优点是稳定性和可靠性高因为底子是一个已经验证可用的模型缺点是覆盖范围受限于模型库的种类太新颖的结构就无能为力了而且本质上更像换参数而不像生成。从我自己的使用体验来说如果目标是做真实可加工的机械零件第一类是当前最靠谱的路线。第二类适合做概念设计阶段的外观探索第三类适合企业内部有大量标准件库的场景。没有哪个方案是绝对最优的关键看你交付物的去处——是要直接上机床加工还是停留在效果展示阶段这决定了你该选哪条路。3. 实操落地从零跑通一个text-to-cad项目3.1 环境准备与工具链选型想实际体验text-to-cad不用非得自己从零训练模型现在有一些开源项目和在线服务可以直接拿来用。我个人建议新手从Text2CAD这个开源项目入手原因很简单它不依赖商业软件闭源接口技术栈相对透明训练和推理代码都公开而且它的思路正是上面说的LLM 程序化CAD库路线生成结果是逐步可解释的出错了你能看到是文本理解的锅还是建模执行的锅排查起来特别方便。环境方面如果你只是想跑通推理一台带8GB以上显存的消费级显卡就够用。但如果你想微调模型适应自己的领域数据建议还是上云租卡否则训练一次能把人等崩溃。操作系统我推荐Ubuntu 22.04 LTS省去很多依赖冲突的麻烦。需要提前装好的基础依赖包括Python 3.10以上、CUDA 11.8或者12.x、PyTorch 2.x以及Open CASCADE相关的Python绑定。这里有一个很重要的安装细节项目依赖的CadQuery版本和系统里的Open CASCADE库版本必须严格对应否则你在构建3D实体的时候会遇到各种奇怪的报错比如BRep_API: command not done这种让人一头雾水的信息。我当初就是没注意版本对应浪费了整整一个晚上在排查环境问题。建议直接跟着项目仓库的requirement.txt来别自己随手装最新版本稳定压倒一切。3.2 用Text2CAD生成第一个模型项目跑通之后第一次实测我选了一个非常经典的例子一个中心带通孔的圆形法兰外圆直径80mm内孔直径25mm圆周一共有6个直径为6mm的螺栓孔等距分布。这句话里包含了关键几何参数也包含了阵列信息用来测试文本理解和建模执行能力都有代表性。启动推理之后整个流程分两段。第一段模型把这句话解析成结构化的草图命令包括画一个半径40的圆、画一个半径12.5的圆、创建6个直径6的孔位置沿圆周均布。这个解析结果会以代码的形式展示在终端里你能清楚地看到模型的理解过程。我当时看到它把螺栓孔直径6mm识别成孔特征而不是拉伸特征就知道这个模型的语义理解确实学到了机械制图的基本常识。第二段才是真正激动人心的环节模型自动调用CadQuery接口去逐个执行这些命令构建出三维实体并导出STEP文件。当终端上打印出STEP file saved的时候我的第一反应不是哇模型好厉害而是这玩意儿居然真的能用。紧接着我在FreeCAD里打开了那个STEP文件检查了几处关键尺寸——外圆直径、孔距、孔数——全部正确那一刻我基本相信了这个方向的实用性。3.3 模型微调的实用技巧如果你想把这个工具用于自己公司的特定产品线开箱即用的基础模型往往不够。比如你公司常年做液压阀块大部分零件结构是长方体阀体 各种油口 安装孔阵列这个领域特征基础模型是不知道的因为它训练数据里更多的是通用机械零件。这时候就需要微调。微调的第一步是数据准备这是整个过程中最花时间也最影响效果的环节。你需要收集或标注一批文本描述 对应CAD建模脚本的数据对。文本描述要注意覆盖你领域内的说法习惯比如你行业里管那个凸台叫油口法兰座就不要只写凸台要让模型学会你公司的黑话。建模脚本则建议统一风格让所有数据都用同样的建模顺序和函数命名模型学起来会轻松很多。我自己的经验是与其一股脑堆几千条数据不如先精心准备200条高质量的数据对把模型跑通再根据失败案例逐步补充数据。这样做的好处是试错成本低你能清楚地知道每个改动带来的影响。LaTeX格式的指令数据不好找但你可以通过半自动化的方式生成先用基础模型自动生成一批脚本再人工修正脚本和文本描述修正过的数据就是很好的训练样本。4. 真实使用中踩过的坑与排查经验4.1 文本描述的语义陷阱text-to-cad最常见的失败模式不是模型不行而是你的描述方式里藏了歧义。比如你说一个带支撑的L形支架模型可能把支撑理解为加强筋也可能理解为安装底座。如果你在机械领域里说的支撑指的是特定结构最好用更工程化的表达方式比如在L形折弯内侧添加一条三角形加强筋厚度3mm。另外一个高频问题是隐含的默认值。人跟人沟通的时候很多信息是靠上下文脑补的。你告诉工程师做一个法兰盘他心里默认是国标法兰的形状比例但模型没有这个行业默认值它只知道法兰盘这个概念在训练数据中的统计规律。所以跟text-to-cad模型对话要多一步把心里默认的常识显式说出来。你要主动补充材质厚度、倒角大小、哪个面是安装面等信息。还有一个小技巧是分步描述而不是一次到位。如果模型对一句话生成的模型不符合预期不要反复随机改措辞碰运气而是把需求拆成几步对话先生成基体再追加特征。比如先创建一个50x50x10mm的方形底板然后在底板上表面的中心位置添加一个直径30mm高度25mm的圆柱凸台最后在凸台中心打一个直径10mm的通孔。这样每步模型都能专注于单一任务成功率会高得多。4.2 几何精度问题的排查策略生成结果出现几何精度问题首先要分清是模型理解错了还是建模执行出错。有个简单的方法打开生成过程可视化界面或者看中间输出的脚本如果脚本里的参数正确但执行出来的实体不对那是内核或者脚本层的bug如果脚本参数本身就错了那是模型理解的问题。这两个问题的排查方向完全不一样前者要查CadQuery版本和操作顺序后者要调整文本表达方式。我遇到过一种很隐蔽的情况文本描述和处理结果都正确建模脚本也不报错但生成的模型里出现了悬空的边或者零厚度的面。这类问题往往是布尔运算的容差设置引起的两个几何体之间的间距特别小0.001mm量级时内核的容差处理会把它们合并成一个有瑕疵的实体。遇到这种情况把建模脚本中的统一公差值调大一些比如从1e-7改到1e-5很多时候就恢复正常了。还有一种高频问题是对称特征的丢失特别是包含阵列、均布这类要求的描述。模型在文本理解时把阵列识别成了在指定坐标复制但如果你的描述里缺少阵列中心或者阵列平面信息模型就靠猜。结果就是阵列出来的特征位置看似合理但尺寸链对不上。我的习惯是每次涉及阵列和镜像时都要在文本里同时给出阵列中心位置和阵列个数两个信息不给模型任何猜测的空间。4.3 效率优化与批量建模建议text-to-cad真正能解放生产力的场景是批量建模。比如你要为一个系列产品生成几十个尺寸不同的底座模型若一个个手工画工作量大且无聊但用text-to-cad结合脚本批量调用很快就能拿到一系列可编辑模型。我做批量建模时一般把流程拆成三步。第一步是把产品的系列参数整理成一个表格每行代表一个规格每列是一个尺寸参数或特征描述第二步是写一个Python脚本遍历表格里的每一行把参数拼成规范的文本描述然后调用模型批量生成第三步是自动校验把生成的模型与参数表里的关键尺寸逐一比对不匹配的自动标记出来人工复查。这个流程跑通之后你基本可以做到上班把参数表丢进去下班回来收模型。但这里有一个重要前提你的文本模板必须极其规范把所有可能的参数变化都考虑进去。模板里的描述语言越固定模型生成的成功率越高。不要频繁更换措辞方式比如今天说直径明天说外径后天说圆径模型的稳定性会被这些无谓的变化拖累。5. 扩展到实际工作流中的思路5.1 与现有CAD软件结合的使用模式很多人误以为text-to-cad是要替代SolidWorks或者AutoCAD这个理解走偏了。它真正的价值是给CAD软件当前端输入设备直接生成可编辑的模型文件进入常规软件流程。我现在的使用模式是用text-to-cad生成基础几何结构把STEP文件导入SolidWorks在软件里继续补加工特征、公差标注、表面粗糙度等工程信息。这样融合起来用避开了大模型不擅长处理精细工程要求如公差、粗糙度的短板也避免了从零建模的繁琐。另一个值得推荐的思路是结合PDM/PLM系统做自然语言模型检索。企业内部积累了海量的历史CAD模型大多数是死数据——存了但再也没人打开过。通过text-to-cad的文本理解能力你可以让工程师用自然语言描述需求系统先从历史模型库中检索相似模型再通过参数化调整生成新品。这相当于把企业历史资产变成了活的模块库虽然需要额外开发接口但投入产出比相当可观。5.2 团队落地时的组织配合工具落地的最大障碍通常不是技术而是团队习惯。根据我自己带项目的经验如果你直接要求工程师以后画图都用AI生成打底抵触情绪会非常大。比较有效的推进方式是先选一个对创新接受度高的工程师作为试点用户让他用text-to-cad处理一个实际项目里的非关键零件。等他把全流程跑通并且总结出适合你团队的文本描述规范后再由他给其他人做内部分享这样推广阻力会小很多。同时要建立一个失败案例库。text-to-cad生成的模型总会有不达标的时候每遇到一次失败就把文本输入、生成结果、失败原因分析记录下来。三个月之后你就会发现大多数失败其实是集中在少数几类问题上针对性地修改团队描述规范和补充微调数据成功率会显著提升。不要零散地处理失败一定要系统化地积累这个资产的价值会越来越大。5.3 后续可以尝试的进阶方向如果你已经不满足于基础用法我建议往三个方向探索。第一个是装配体生成现在大多数text-to-cad工具还停留在单零件级别但真实工程中更多的是多个零件的配合关系。尝试让模型一次生成相互配合的多个零件重点观察它如何处理零件之间的尺寸约束关系这个方向一旦跑通价值巨大。第二个方向是逆向文本化就是把已有的CAD模型自动描述成一段结构化文本。你导入一个模型文件工具输出一段描述文本然后你再修改其中的几个参数生成变体模型。这相当于给历史模型建立了一套可索引、可修改的语言身份证在系列化产品设计中特别有用。第三个方向是约束增强生成。目前的生成模型对几何关系如平行、垂直、相切等敏感度还可以但对尺寸链与公差配合逻辑的理解还很弱。如果你做的是精密装配相关的产品设计可以尝试在文本描述中显式标注公差约束然后观察模型是否能生成带约束信息的模型。这需要额外的后处理工程软件配合但方向是对的也是text-to-cad走向工程实用的必经之路。最后分享一点个人经验跑通text-to-cad到现在我的整体感受是这个技术离全自动设计还很远但离帮你省掉重复劳动已经非常近了。不要指望它一次生成直接可以投产的最终模型而是把它当作一个擅长出初稿的工具。你在工程上的判断力、对加工工艺的理解、对设计规范的把握才是决定最终模型质量的关键。工具越强大对使用者鉴别力的要求反而越高。如果你准备上手试试我唯一的建议就是别怕第一次生成的模型烂。用文本描述→生成模型→修改描述→重新生成这个循环快速迭代你会发现它能很快找到你真正想要的结构。这种实时反馈带来的建模体验跟传统CAD软件里拉草图手柄是完全不一样的思维方式你一旦习惯就回不去了。
阅读完成 · 觉得有帮助？
