Text-to-CAD入门：从自然语言到可编辑STEP模型的实现路径

做CAD设计的人应该都经历过这种折磨客户用一句“大概就是一个小盒子上面带几个孔”当需求你却要在软件里手动把尺寸、约束、特征一个个建出来。text-to-cad这类工具就是冲着这个痛点来的——它想在自然语言和三维模型文件之间直接搭一条路。所谓text-to-cad简单说就是输入一句描述输出一个真正能用的CAD模型文件而不是一张效果图。这不是渲染出来的图片也不是简单的点云是带拓扑关系、带参数特征、能进SolidWorks、FreeCAD、Fusion 360继续编辑的几何模型。如果你是做非标设计、结构件快速验证、3D打印模型生成或者想在课程设计里快速出个初版零件这条路值得认真看一下。这篇文章我会从原理、主流技术路线、开源项目选型、实操跑通、调优技巧到常见问题排查完整走一遍。1. 一句话生成CAD文件先搞懂它到底在解决什么问题1.1 传统建模流程的瓶颈在哪常规CAD建模流程里从需求到成品模型中间隔着一道很厚的墙。设计师拿到需求后先要在脑子里做几何分解这个零件由几个特征构成每个特征用什么草图、什么拉伸方向、什么布尔运算还要考虑草图的约束关系是固定值还是要留参数。等你把草图约束做完再逐个特征构建一个中等复杂度的零件花半小时到两小时很正常。更麻烦的是需求一旦变动比如孔位从4个改成6个整个特征树都得重新梳理。text-to-cad切换的其实是“交互范式”把建模过程从“人操作软件”变成“人和模型生成器对话”。用户提供语义描述模型替你做了几何分解、特征规划、参数生成这几件事。这不是简单的自动化脚本而是在自然语言的语义空间和CAD建模的操作序列之间搭了一座桥。从效率角度看它对早期方案探索、多方案比选、需求频繁变更这类场景帮助最大因为你不用再为每个小改动都重新拖一遍草图。1.2 为什么是现在才火起来其实“从文本生成三维模型”的研究早就有Text2Shape、CLIP-Forge这些更早的项目都做过类似尝试。但那时候的输出普遍是体素、点云或者粗糙mesh根本不能叫CAD模型没有倒角参数没有草图历史没有布尔特征放到实际工程里基本没用。最近一两年这个方向突然升温核心原因有两个。第一大语言模型的代码能力提升到了一个可用水平而CAD建模本质上可以用程序化语言来精确表达比如CadQuery的Python脚本、OpenSCAD的脚本语言它们本身就是“文字”和“几何”之间的桥梁。第二开源社区积累了大量的CAD命令序列数据像Fusion 360 Gallery、ABC数据集、DeepCAD这些为大模型提供了足够多的“文本-建模指令”训练对。有了这两个条件生成出来的东西才是工程师拿着能用的STEP文件而不是只能看不能摸的三角网格。1.3 典型的应用场景有哪些我盘了一圈目前text-to-cad最值得用的场景大概是这几类一是概念设计阶段的快速验证结构工程师想先看几个外形方案用文字出几个初版模型比手画快很多二是标准件变体生成比如不同规格的安装支架、法兰盘、外壳调整尺寸参数就能批量生成三是3D打印爱好者的模型生成描述一个外壳、夹具、转接件能直接导出打印格式四是教学演示给机械专业学生演示一个零件的特征树是怎么从需求推导出来的。这几个场景有一个共同点对模型的“可编辑性”要求比较高对加工级精度要求则没那么苛刻。反过来如果是要做精密配合、受力分析、公差设计那当前这类工具还需要人工大量介入不要抱太高期望。2. 背后的三条技术路线以及为什么有的方案“中看不中用”2.1 路线一让大模型直接写建模脚本这条路线最直观把CAD模型看作一段程序text-to-cad就变成了代码生成任务。具体做法是让大模型生成OpenSCAD脚本或者CadQuery的Python代码然后通过脚本解释器渲染出三维模型再导出成STEP、STL或者STEP格式。OpenSCAD的优势是语法简单、每个语句都对应明确的几何变换模型生成的成功率比较高CadQuery则更贴近现代CAD的参数化特征语义它基于Python适合后续二次编辑导出STEP文件后在FreeCAD里能看到完整的实体历史。这条路线是目前社区里最活跃的方向因为它巧妙地利用了LLM最强的能力——写代码。只要把任务限定在小范围内比如法兰、支架这类用拉伸、打孔、倒角组合就能完成的零件大模型的生成质量可以相当稳定。但它的局限也很明显对自由曲面、复杂扫掠、放样这类需要大量顶点控制的造型文本表达的成本会迅速上升生成结果经常跑偏。另外脚本语言通常没法表达局部光顺和美学过渡做出来的外形偏“工业块状风”。2.2 路线二两阶段pipeline先点云后建模指令另一条更“学院派”的路线是两阶段处理典型代表是Text2CAD这类工作。第一阶段用文本生成一个三维点云或者隐式场这一步的目的是把语义锚定到几何空间确定模型的大致形状第二阶段让一个CAD命令序列生成模型在这些点云的引导下输出具体的建模步骤比如“拉伸这个草图”“在顶部开孔”。这种做法的好处是把“自由形状生成”和“参数化建模”解耦点云阶段负责灵性命令阶段负责规矩。但也正因为解耦错误会在两个阶段之间累积。点云稍微偏一点第二阶段生成的命令可能就多一条或者少一条最终模型的拓扑和参考目标对不上。实际评测里这类模型在标准数据集上的几何指标往往不错但拿到真实工程零件上经常会出现“形状大方向对、细节不可编辑”的问题。如果你要复现这类工作要有心理准备两阶段pipeline的参数调节和工作量比单阶段要多不少。2.3 路线三直接预测B-rep操作序列还有一类尝试直接跳过点云和程序让模型输出B-rep边界表示层面的操作序列。B-rep是CAD文件里真正存储的拓扑结构包含面、边、顶点的连接关系以及曲面的数学方程。Fusion 360的建模历史记录、STEP文件内部的实体描述本质上都是这种表示。模型接收一段文本输出类似“草图平面取XY画一个半径25的圆拉伸20毫米顶部倒角R2”这样的指令序列然后由底层几何内核去执行。这套路线的天花板很高因为它生成的就是“CAD原生语言”不依赖OpenSCAD那套独立语法。但难点也摆在明面上B-rep操作序列的token长度比脚本语言长得多训练数据的规模和质量要求也极高深度学习模型很容易在长序列中间产生拓扑错误。目前公开可用的成熟项目不如脚本路线多更多还是论文级别的探索。不过这是最值得盯的方向因为一旦B-rep预测足够稳生成的模型质量会跨上一个台阶。2.4 绕不开的数据集和评测指标不管哪条路线数据集是地基。社区里常用的包括ABC数据集里面有大量用参数化脚本生成的CAD模型Fusion 360 Gallery带完整的建模历史树适合训练操作序列DeepCAD第一批大规模CAD命令序列数据集。Text2CAD论文里也构建了文本描述和CAD命令序列配对的数据集这些数据为训练模型提供了原料。评测指标方面传统AIGC领域常用的PSNR、SSIM在这里基本不适用。CAD领域常用的几何指标有倒角距离Chamfer Distance衡量两个点云的接近程度、交并比IoU衡量两个模型的体素/网格重叠度、F1分数兼顾查全率和查准率。但这些指标只能告诉你“形状像不像”不能告诉你“能不能编辑”“特征树对不对”。我见过不少指标很漂亮的生成结果倒进CAD软件后一查拓扑面之间根本没有共边关系连切个倒角都会报错。所以真正的工程评估一定要加一道人工检查打开STEP文件拖动一下特征树尝试修改一个参数看模型是否联动。3. 开源项目这么多怎么选才不踩坑3.1 Text2CAD入门必跑的基线Text2CAD算得上这个方向最容易被提到的开源基线之一。它走的是我上面说的两阶段pipeline文本先生成点云再基于点云生成CAD命令序列。项目仓库里通常会给出训练好的权重、推理代码和评测脚本环境配置不算太复杂大部分步骤都有现成脚本。对想入门研究的人来说它是理解“语义到几何再到建模指令”全链路的好样本。不过你要清楚它的定位。它的优势是可复现、有论文支撑适合做对比实验劣势则是两阶段累积误差在处理复杂装配体时会非常明显生成单个简单零件的成功率还算可以但稍微加点曲面特征输出的模型经常需要人工修复。如果你只是想要一个“能直接用的模型生成工具”它不一定是效率最高的选择。3.2 程序化CAD生成工具链LLM加CadQuery的组合比“跑论文模型”更接地气的方案是拿一个大模型GPT-4级别闭源API或者开源的CodeLlama、Qwen等和CadQuery/OpenSCAD组合起来直接在命令行里完成“输入描述、输出STEP”的闭环。社区里像Zoo这类项目就是沿这条路线做的也有不少人是自己写一套Prompt模板加后处理脚本拼出来的工作流。这类方案胜在灵活你可以随时换底下的LLM模型升级你跟着升级生成失败时还能看中间脚本手动改两行代码重新渲染。它还天然支持批处理——给一个CSV文件里塞几十条零件描述就能批量生成一整套模型变体。但方案的问题也很明显Prompt工程对最终质量影响极大同一个描述换一种表达方式生成结果可能天差地别。你得花时间总结一套适合自己行业的提示词模板并且保留一套CAD脚本的语法校验工具否则脚本报错时你连问题出在哪都不好查。3.3 授权、部署成本和效果怎么权衡开源模型和闭源API的取舍我建议看三个维度数据敏感性、硬件预算、质量要求。如果设计的零件涉及公司内部结构尺寸你肯定不希望描述文本被发送到外部API去这时候必须选本地部署的模型如果只是做个人项目、验证想法用闭源API其实更省事一次性生成成功率也更高。硬件上7B级别模型用4bit量化加载大约8GB显存就能跑13B或更高参数量的模型至少需要12GB以上显存而且生成一个中等零件往往要烧几十秒GPU时间闭源API则完全不用操心硬件按调用次数付费即可。质量方面闭源大模型在复杂描述的理解上明显更强但开源模型在专用CAD语法上通过微调也可以追得非常近。尤其当你的需求集中在某几类零件时用自家积累的零件描述和对应CadQuery脚本微调一下开源模型效果往往比通用大模型更稳因为通用模型经常“过于有创造力”把螺栓孔给你设计成六边形装饰孔这种事我见过不止一次。3.4 我的选型建议纸上谈兵没意思直接给结论。如果你只是想快速体验text-to-cad能干什么愿意花点小钱直接用闭源API加CadQuery脚本模板一天内就能搭出可用的工作流。如果你是研究者或者有数据保密需求先跑Text2CAD基线再自己构建一个小规模领域数据集做微调。如果你主要做3D打印模型生成不要求STEP可编辑性那么OpenSCAD加本地7B模型是最省心的组合。没有“全都能打”的方案但每个需求场景都能找到对应的高性价比解法前提是你别指望一个模型能从宇宙飞船一路生成到水杯。4. 实操跑通从环境准备到导出STEP文件4.1 环境准备和模型加载以我实测最顺手的“本地7B模型加CadQuery”工作流为例。硬件方面一张12GB显存的消费级显卡就够跑量化模型如果是纯CPU推理生成时间会非常感人一个简单零件等上两三分钟都算正常。软件环境用conda建一个干净环境Python建议3.10以上先安装好PyTorch对应CUDA版本再装transformers、accelerate、bitsandbytes这几个库CadQuery通过conda安装比较稳它能直接处理STEP导出而不需要额外依赖。conda create -n text2cad python3.10 -y conda activate text2cad pip install torch transformers accelerate bitsandbytes conda install -c conda-forge cadquery模型加载时用4bit量化是常规操作显存占用小生成质量损失在可接受范围内。权重要从Hugging Face下载国内网络环境下可以提前把模型文件放好路径离线加载。这里有个细节加载时记得设置trust_remote_codeTrue不少代码生成模型都需要执行自定义代码才能正常跑。4.2 一个能跑的最小推理脚本下面这段是我整理过的最小可用脚本作用是输入一句描述输出一个STEP文件import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name your/local/model-path tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, load_in_4bitTrue, torch_dtypetorch.float16, device_mapauto, ) prompt Create a CadQuery Python script that builds: A rectangular bracket 80mm x 50mm x 5mm, with two 6mm holes near the left edge. Only output valid Python code in a single block. inputs tokenizer(prompt, return_tensorspt).to(cuda) output model.generate( **inputs, max_new_tokens2048, temperature0.8, top_p0.9, do_sampleTrue, ) code tokenizer.decode(output[0], skip_special_tokensTrue) print(code)生成出来的代码往往包含Markdown代码块标记先清洗成纯Python文件再执行。执行成功后会得到模型文件再用CadQuery导出STEPpython generated_code.py如果generated_code.py里最后有show_object之类的交互命令记得换成export(output.step)这一步经常被忽视导致代码执行后什么都看不到。4.3 提示词怎么写才不容易翻车我反复试过text-to-cad提示词和文生图提示词完全是两套逻辑。文生图讲究氛围感和风格词text-to-cad需要的是“工程参数实体”。关键信息包括主体形状、全局长宽高尺寸、壁厚、孔直径和位置、圆角半径、单位、布尔操作类型、输出格式。拿“外壳”举例如果你只写“a small enclosure for electronics”生成结果十有八九是各种奇怪异形体。改成“an L-shaped enclosure, 120mm x 80mm x 30mm, wall thickness 2mm, with 6 M3 countersunk screw holes on the bottom, a 30mm x 20mm rectangular vent on the side, fillet R3, unit mm, output STEP”就要可靠得多。因为模型可以从描述里直接映射出建模步骤先画L形草图拉伸30mm抽壳2mm底面孔阵列侧面开槽最后倒角。信息越结构化模型做几何分解时越不容易自由发挥。4.4 输出格式的取舍text-to-cad直出的格式常见有STL、OBJ、STEP、OpenSCAD脚本、CadQuery脚本。我的建议是凡是后续还要改尺寸、做装配、做仿真的一律走STEP。STEP文件保存的是B-rep实体在FreeCAD里打开还能识别成可编辑实体STL只是三角网格一旦生成后发现壁厚不对你只能在MeshLab里当雕塑修或者在CAD软件里重新建模等于白干。如果项目只是3D打印且造型不会再改STL倒是够用了。而OpenSCAD脚本和CadQuery脚本的价值在于“可修改”你想换个孔位时只需要改一行参数再重新生成所以实操中我习惯把生成的脚本也一并存档后续做参数化变体特别方便。5. 怎么判断生成质量以及提示词的调优技巧5.1 别只看几何指标在线跑模型的时候很多人习惯看一眼倒角距离或者IoU就觉得“模型还不错”但这在CAD场景里是陷阱。几何指标衡量的是点云层面的相似度哪怕拓扑完全错误只要外轮廓点云接近指标照样好看。以前我碰到过一个输出从侧面看完全像个法兰但B-rep拓扑里内孔和外圆根本不在同一个实体上一进CAD软件特征树就崩。所以在我的流程里自动指标只用来做初步筛选真正决定留不留下这个结果必须靠人工检查这三件事STEP能正常打开、实体特征树完整、关键参数和描述一致。5.2 采样参数对生成结果的影响大模型生成CAD脚本时解码策略的影响比想象中大得多。temperature控制随机性调太高比如1.2以上模型会生成大量无意义的中间变量和重复特征调太低0.4以下模型容易陷入同一种建模套路输出“看起来差不多但细节完全不对”的结果。我实测下来0.75到0.9是比较舒服的区间既能保持一定多样性又不会放飞自我。top_p建议固定0.9用来裁掉概率分布长尾里的垃圾token。max_new_tokens一定要给够一个稍微复杂点的零件脚本轻松上千token给少了模型会在中间截断输出一个语法正确但缺胳膊少腿的半成品。5.3 让提示词具备“工程可读性”调优text-to-cad有一个非常反直觉的点提示词不该写得像自然语言反而该写得像一份采购图纸。很多工程描述里模棱两可的词比如“不大不小”“稍微倾斜”“圆润一点”模型没法把这些映射到精确几何参数。你要做的就是强制自己把模糊词翻译成参数词“最大外径不超过40mm”“倾斜角度15度”“圆角半径R2”。这一点不需要你有什么工程师证日常生活里的物体也能这么描述关键是别让模型猜。另一个技巧是分步骤描述。与其一句长难句把整个零件塞给模型不如拆成两三条简洁的建模要求“先创建底板”“在底板中心添加一个轴套”“在底板四角添加加强筋”。我在实测中发现分步描述时模型的中间脚本生成质量会明显提升因为它更容易对齐到底层建模API的调用顺序。最后再用一句“combine all features into one solid”这类约束收尾能有效减少模型把部件生成为相互独立实体的概率。5.4 生成失败后的轻量修复手段哪怕提示词写到极致模型也不可能次次成功。轻量修复我先看脚本能不能跑报错大概率集中在API拼写错误或者参数类型不对因为CadQuery的API对参数类型比较敏感。如果脚本能跑但几何不对那就得改脚本了。我最常用的办法是“保留特征骨架修局部参数”——把脚本里每个特征的参数打印出来对照描述孔的位置不对就改坐标壁厚不对就改尺寸。有些时候甚至不需要改脚本只需要换一个随机种子重新采样跑个五六次就能中一个满意的结果。6. 实测中的常见问题与排查手记6.1 显存不足、OOM和推理速度慢本地推理最常见的坎就是爆显存。处理方式优先级从高到低先用4bit量化加载然后把batch size降到1再限制max_new_tokens很多显存飙升其实发生在生成长序列时最后可以考虑把输入提示词缩短模型对超长提示词的显存占用增长非常线性。推理速度慢就靠beam search和batch的权衡了如果你想稳定出图num_beams设为4左右效果最好但耗时可能是采样生成的几倍实际操作中我更推荐减少beam数量、提高采样次数来换质量。6.2 生成的脚本能跑但模型在CAD软件里打不开这类问题多半出在STEP导出质量上。CadQuery导出的STEP正常情况下能被FreeCAD识别但如果你在代码里用了多个布尔对象却没有正确合并导出的STEP里会堆叠好几个独立的“壳”打开时可能出现空白或破面。排查路径是先在MeshLab或者FreeCAD里做一次网格检查看模型是不是watertight水密的。如果发现非流形边赶紧回脚本里检查布尔运算表达式重点看有没有缺少参数的union操作或者cut操作。另外单位问题也容易踩坑CadQuery默认毫米SolidWorks有些版本打开时会按英寸解释尺寸瞬间缩小25.4倍这个不是模型坏了是单位设置。6.3 中文提示词效果很差怎么办开源模型和不少商业API在纯中文描述上效果都不好原因很简单它们训练时用的CAD描述数据九成以上是英文。遇到这种情况我建议先做一个“术语翻译-结构化”的预处理把“四角各有一个沉头孔”翻译成“four countersunk holes at cornersM3depth 2mm”再把单位、数量、位置都显式写出来。还有个小技巧是“中文描述先用另一个通用大模型转成英文工程描述”这一招能显著改善小模型的中文理解问题。不过如果你的任务只涉及标准件和简单形状也可以尝试用开源模型的中文微调版本实测下来部分模型已经能应付基础对话但精度要求高时还是切英文靠谱。6.4 模型总是重复生成同一个特征生成长序列LLM有个通病重复。有时候模型会把一个孔位复制十几次导致脚本执行时间爆表。遇到这种情况先调temperature到0.9附近加一点随机性再对生成结果做后处理把重复的特征代码块删除。大多数项目生成脚本都是按“特征函数”组织的比如box()、hole()、fillet()所以我可以直接用正则统计相同特征调用的次数超过合理范围就删。最后设一个脚本执行的超时时间避免一个坏脚本把整个流水线卡死。6.5 常见问题速查表现象可能原因处理方法生成脚本报语法错误模型输出了Markdown标记或解释性文字清洗代码块后重试必要时用正则抽取Python代码模型打开后只有一堆碎面多个特征没有正确合并成单一实体检查布尔union/cut逻辑统一单位尺寸和描述差一个量级单位被当成英寸或者毫米理解错了在提示词里显式声明unit is mm输出STEP无法导入SolidWorks生成器版本兼容问题尝试用FreeCAD转档或用CadQuery另存为STEP AP214格式生成时间过长max_new_tokens设置过大或beam search太宽限制最大token数降低beam数量7. 最后避坑清单算是我的个人心得这条路我跑下来最大的感触是text-to-cad远没有到“一句话全自动”的地步但已经足够当“效率放大器”用了。几个让我少走弯路的经验顺手分享出来。第一永远保留中间脚本。很多人只存最终STEP文件等到改尺寸的时候才发现无能为力只能重新生成。我现在的习惯是“描述文本模型输出脚本最终STEP文件”三件套一起归档配合一个简单的参数值列表任何变更都能在几秒钟内重新生成新版本。第二生成之前先确认下游工具链。如果你要导出到SolidWorks就要关注STEP AP203和AP214的差异如果走3D打印切片你得先确保模型水密如果后续要做有限元分析可能还得重新简化模型并抽中面。不同的下游需求会影响提示词怎么写、模型怎么选这些都是在动手之前就该定下来的。第三别贪大模型。我在同样CadQuery任务上对比过大型模型在理解复杂描述时确实强但小型专用模型在“固定几类零件的模板化生成”上完全不虚而且推理更快、可以本地部署。如果你是做企业内部的标准件库、夹具库与其追最新旗舰模型不如沉淀自己的零件模板库用中等量级模型去适配。最后说一点方向上的体会。text-to-cad目前解决得最好的是“参数化零件”不是“自由曲面造型”更不是“工业级整机设计”。它的正确使用姿势是帮你把脑子里已经想清楚的结构快速变成一份可以继续用CAD软件深化的初稿而不是替你凭空发明一台机器。未来如果B-rep的直接生成和误差控制能做到接近人工那这个领域才真正算成熟。在那之前把它当成一个会写建模脚本的实习生来用你会舒心很多。