1. 一句自然语言凭什么能变成可编辑的三维模型如果你在工位上接过这样的需求同事发来一段话“帮我建个法兰盘外径80内径25厚度10中心孔周围有个2mm高的凸台螺栓孔6个均布分度圆直径60”然后你打开CAD软件从草图、拉伸、打孔一路做到下班。那你应该能立刻理解text-to-cad这个方向的价值——它想做的事情就是让上面这种“语音转需求”的场景直接变成“文字转模型”而且转出来的不是一张“看起来像”的图片不是STL网格而是一份带参数、带特征历史、能继续改孔改尺寸的完整CAD文件。我在本地搭过好几套不同技术栈的text-to-cad原型从早期玩票式地让大模型直接输出STL到后来老老实实让大模型写参数化脚本中间踩的坑比想象中多得多。这篇文章想把这些经验整理出来包括技术路线为什么绕不开“脚本生成”这条老路落地时哪些环节最容易翻车以及我是怎么把一套能跑通的链路搭起来的。适合正在做CAD自动化、做AI设计和工具集成的人参考也适合那些想给自己的3D打印、非标设计流程提效的工程师。先说一个经常会误导新人的点text-to-cad不是“文字生成图片”套了一层CAD皮。图片生成追求视觉合理性网格可以有瑕疵、可以夸张比例但CAD模型是要拿去加工、拿去装配、拿去出工程图的它必须精确到小数点后至少两位必须能被选中面、改草图的尺寸必须是一棵可回溯的特征树。哪怕你只想要一个3D打印的手柄你也希望回去改改圆角半径而不是重新生成一遍。所以“能生成什么”和“能不能被工程师接受”之间隔着一整条野路。我最后跑通的方案本质上是一个组合拳先用大语言模型把自然语言需求拆解成结构化参数和特征顺序再让它生成一段CadQuery脚本最后由OpenCASCADE内核执行这段脚本并导出STEP。整个过程跑下来一个中等复杂度的机械零件从文字到可用模型稳定的话两分钟之内能完成不稳定的时候它会给你演示什么叫“一本正经地胡说八道”让你深刻体会到AI建模离全自动还差着一段必须由人来兜底的路。2. 为什么技术路线选的是“生成建模指令”而不是直接生成网格2.1 CAD和Mesh的底层差异一张照片和一份可编辑工程图的区别很多人第一次接触text-to-cad时会下意识想到扩散模型、点云生成、神经辐射场那一套。这些技术在生成图片和3D扫描重建上确实猛但放在CAD领域就水土不服原因不是你模型不够大而是输出的数据格式从根上就不是CAD的菜。一张STL网格本质是一堆三角形的顶点和法线它记录了“表面长什么样”但没有记录“这个面为什么在这里”“这个孔是通孔还是盲孔”“倒角半径是多少”。你拿到一个STL法兰盘想改内孔从25变成30不好意思你得重新雕刻网格或者走一遍逆向建模流程那活儿的痛苦程度堪比让设计师用像素画板画画。CAD模型的底层是B-Rep边界表示更关键的是它带着特征历史树——拉伸、切除、倒角、阵列、镜像每一步都是可回放的“操作记录”。所以text-to-cad如果只输出一个光秃秃的网格那它解决的只是“可视化”问题不是“建模”问题。工程上要的不是一张好看的照片而是一份能拿回去改尺寸、更新装配关系的“原文件”。这也是为什么我一开始就排除了“用扩散模型直接生成网格”的路线。你让扩散模型画一个法兰盘画出来十有八九是视觉上很圆润、孔位很对称的漂亮网格但真要导入Fusion 360再编辑一次全部特征都变成“网格化实体”修改自由度几乎为零。换句话说它像一个能说会道但不会画施工图的乙方交付物漂亮但不顶用。2.2 现在真正在跑的几条路从“直接生成网格”到“生成脚本”我翻了从论文到开源项目到商业工具的一大圈之后把text-to-cad的技术路线归成下面四类实际选型时基本绕不开这个四分法。第一条文本转图像再转网格。典型玩法是先从文字生成多视角图再通过单目重建或点云拟合得到几何体。这条路胜在通用理论上什么形状都能“编”出来但输出基本没有参数化信息曲面拟合也是靠猜精度勉强够做概念示意不够做加工。第二条直接训练模型输出CAD操作序列。把构建历史当成自然语言一样去训练模型一个token一个token地吐“创建草图、拉伸30mm、打孔”。这个方向学术界很热因为理论上最接近真实建模行为。但它的问题在于训练数据极难搞——需要大量带完整特征树的CAD源文件而且操作序列的排列组合复杂度远高于自然语言模型很容易在前面几步就崩掉目前离工程可用还有距离。第三条让大语言模型生成CAD脚本再交给传统内核执行。给LLM一个目标格式比如CadQuery、OpenSCAD、FreeCAD的Python API让它把文字需求翻译成代码脚本跑出来的结果直接就是带特征历史的B-Rep模型。这条路线没有重新发明建模轮子而是把LLM当成一个“翻译官”翻译成本被大幅压缩。第四条文本转点云或深度图再逆向拟合成CAD曲面。相当于多了一条信息中间层比文本直接跳模型更容易对齐语义但拟合出来的往往是NURBS曲面块不是工程师习惯的拉伸、旋转、倒角特征后续修改依然要重新“伺候”一遍曲面。2.3 我为什么最终选了CadQuery 大模型脚本生成综合对比下来上面第三条路是我能最快跑通、且交付物最满足工程要求的方案。原因很现实LLM最擅长的事情之一就是写代码而CadQuery的代码本身读起来就和自然语言非常接近。你看下面这段import cadquery as cq result ( cq.Workplane(XY) .circle(40) # 外径80mm .extrude(10) # 厚度10mm .faces(Z) .hole(25) # 中心孔内径25mm )就算你没写过CadQuery也能猜出这个模型是什么形状。对LLM来说这种“用英语写建模指令”的任务天然比直接生成B-Rep数据要顺手得多。另一个原因是后端内核成熟CadQuery基于OpenCASCADE生成的实体就是标准的B-Rep可以导出STEP、STL可以和主流CAD软件互通也可以直接拿去做有限元仿真前置。FreeCAD的Python API我也试过它的接口比CadQuery更接近原生OCC能力上限更高但语法臃肿、容易把LLM绕晕OpenSCAD的文本语言对布尔运算友好但圆角、倒角、复杂放样这些操作写起来就费劲。最后我的选择很明确复杂曲面和装配级应用交给专业CAD软件text-to-cad原型统一用CadQuery做主力输出格式因为它的“脚本即特征历史”属性最适合让大模型发挥。3. 从文本到CAD的完整落地链路环境、数据与核心流程3.1 环境准备与工具清单别在安装这一步就卡住整个链路不复杂但环境依赖处理不好会浪费半天时间。我按可复现的方式把工具列一下Python 3.10以上建议用虚拟环境隔离别直接装进系统PythonCadQuery负责把脚本变成B-Rep实体它装完会自带OpenCASCADE内核trimesh用于把STEP或STL加载进来做快速体积、水密性检查一个大语言模型闭源API或本地部署都可以关键是代码能力要强小模型写CadQuery经常漏括号一个简单的文件输出模块把生成的STEP按零件编号归档安装命令在这里pip install cadquery pip install trimesh如果你在Windows上装CadQuery耐心等它拉预编译的OCC包就行体积挺大但基本不会失败。Mac M系列芯片我踩过坑需要先确保有可用的OpenCASCADE依赖实在不行就换Docker跑反而省心。3.2 提示词结构比“模型聪明”更关键很多人一上来就给大模型丢一句“生成一个法兰盘”然后抱怨输出质量差。这其实跟CAD做图一样你给需求方一张白纸他怎么知道你要什么。我试了几十轮之后固定下来一套自己的提示词模板效果稳定很多。我要求模型始终按照四个区块输出需求理解把用户文本里的尺寸、特征、约束提取出来列成结构化清单建模思路用自然语言描述特征的先后顺序CadQuery代码只输出一个代码块不要夹杂解释自检说明指出输出里哪些尺寸可能是猜测的哪些特征存在歧义比如你输入“做一个带6个螺栓孔的法兰盘”模型会先给你列外径多少、厚度多少、孔分度圆直径多少如果没有给就明确标记为“猜测值”。这一步太重要了。CAD建模最怕的不是模型不会画而是模型默认了某个尺寸你却毫不知情。3.3 核心流程与自检回路生成脚本只是开始我的完整处理流程是一个五段式回路缺一不可文本解析从自然语言里抽取实体类型、关键尺寸、特征列表、约束关系脚本生成让大模型按提示词模板输出CadQuery代码内核执行运行代码生成实体捕获异常和警告几何校验检查实体是否有效、体积是否合理、孔的数量对不对反馈迭代如果校验不过把错误信息回灌给模型让它修正重试这里最容易被忽略的是“反馈迭代”。很多人跑一次生成就放弃了觉得模型不行。实际上让模型看到报错信息再改成功率会直线上升就像代码调试没人规定第一版必须能编译通过。我实测下来一个中等复杂零件平均需要1到2次修正才能达到可用状态第一次就完美的情况大概只有四成。下面这段代码是我用来做几何快速校验的简化版import cadquery as cq from pathlib import Path def build_flange(): result ( cq.Workplane(XY) .circle(40) .extrude(10) .faces(Z) .hole(25) ) return result model build_flange() solid model.val() print(体积:, solid.Volume(), mm^3) print(是否有效:, solid.isValid()) bbox solid.BoundingBox() print(长:, bbox.xlen, 宽:, bbox.ylen, 高:, bbox.zlen)校验逻辑不复杂但能筛掉大部分明显翻车的生成结果。比如模型生成的实体体积出现负值、边界盒尺寸和预期完全不符或者实体有效性校验直接报false这种情况基本不用看细节直接让模型重新生成就对了。4. 实测拆解让模型生成一个法兰盘的完整记录4.1 输入描述与约束拆解为了让你直观感受这条链路跑起来是什么效果我用一个实际例子过一遍。用户原始输入是“外径80mm、内径25mm、厚度10mm中心孔周围做一个2mm高的凸台凸台外径30mm法兰平面均布6个直径8mm的螺栓孔螺栓孔分度圆直径60mm。”这段描述在人类工程师眼里几乎没有歧义但模型不一定。我先让LLM做需求拆解它输出的结构大概是这样主体圆柱体外径80厚度10中心孔直径25贯穿凸台以中心孔为轴线外径30高度2螺栓孔6个直径8均匀分布在直径60的分度圆上角度间隔60度特征顺序先拉伸主体打中心孔再凸台拉伸再凸台打孔最后阵列螺栓孔如果你直接用这句话去生成大概率会得到一堆“看着对但实际错位”的结果。关键问题是特征顺序。如果先打螺栓孔再做凸台拉伸凸台会盖住部分螺栓孔。让模型先把特征顺序列出来再写代码这类低级错误会明显减少。4.2 生成脚本与执行结果整理并修正后的CadQuery代码如下import cadquery as cq result ( cq.Workplane(XY) .circle(80 / 2) .extrude(10) # 主体法兰 .faces(Z) .workplane() .hole(25) # 中心孔 .faces(Z) .workplane() .circle(30 / 2) .extrude(2) # 凸台 .faces(Z) .workplane() .hole(25) # 凸台内的中心孔 .faces(Z) .workplane() .polarArray(60 / 2, 0, 360, 6) # 分度圆直径60均布6个 .hole(8) # 螺栓孔 )保存成flange_gen.py之后直接执行python flange_gen.py输出会生成一个STEP文件同时打印实体体积和有效性信息。我这边跑出来的时间大约0.6秒非常快。真正的时间都花在LLM生成和修正脚本上CPU执行CAD内核反而是整个链路里最不愁的一环。4.3 模型可用性验证别只看“像不像”生成完不是结束我会额外跑一遍几何检查因为靠肉眼判断孔位对不对很容易被渲染器骗过去。solid result.val() print(体积:, solid.Volume()) print(是否有效:, solid.isValid()) bbox solid.BoundingBox() print(边界盒:, bbox.xlen, bbox.ylen, bbox.zlen)这个模型的理论体积可以手算主体圆柱体积约40212立方毫米减去中心孔约3927加上凸台环体积约 2π(15² - 12.5²)再减去6个螺栓孔的体积最后应该落在45750立方毫米左右。如果模型输出的体积偏差超过2%我会判定生成有问题直接回灌给模型调整。孔的数量和分度圆位置我会额外用代码检查遍历实体上的圆柱面统计直径8的孔数量是不是6个直径25的孔是不是2个。这种自动化检查比肉眼靠谱得多毕竟LLM最擅长干的事之一就是“少打一个孔但不告诉你”。4.4 第一次实测的翻车现场角度单位与特征顺序我也不是一开始就跑得这么顺。印象最深的一次失败是模型把polarArray里的起始角度从0度写成了math.pi/2又把360写成了2 * math.pi。表面看没错6个孔还是均匀分布但实际上整组孔相对于法兰的相位转了90度。如果这是个需要和对接法兰配对的零件装配时就会对不上螺栓孔。另一个高频失败是特征顺序错乱。有一次模型先做了凸台拉伸再打中心孔结果凸台上留下一个完整的圆孔但主体上的孔和凸台孔中间出现了台阶面。从渲染图看似乎没问题但实际加工时这个台阶面就是干涉隐患。所以我现在把“特征顺序”单独列为提示词必填项并且要求模型在自检说明里逐条核对直到“主体拉伸 主体孔 凸台 凸台孔 阵列孔”这个顺序完全正确才放行。5. 目前阶段最容易踩的坑和我的应对习惯5.1 语义歧义同一个“凸台”有无数种建模方式CAD里的术语在不同人口中经常指不同的东西。“凸台”可以是圆柱凸台、矩形凸台、带斜度的凸台甚至可以是旋转体凸台“倒角”可以是等距倒角、不等距倒角或者圆角。LLM不会主动追问你是哪一种它会按训练数据里的高频统计猜一个默认答案。我遇到过一次用户说“做一个带凸台的底座”模型生成了圆柱凸台但用户其实想要的是矩形凸台。应对办法很简单别让模型猜。我在提示词里加了一个术语表把“凸台圆柱拉伸体斜度默认0倒角默认C1”这种约定写死模型就不会自由发挥。如果需求方自己都说不清楚那就让模型把所有理解成多个方案并输出人再选一个这比让它猜一个“看起来合理”的方案稳得多。5.2 尺寸幻觉与单位问题这是text-to-cad最让工程师抓狂的坑。同一个数字模型可能有时理解成毫米有时理解成厘米甚至有时为了“形状好看”直接把某个尺寸偷偷改了。我遇到过模型把内径25写成了“25mm”结果实际生成时用了25英寸的逻辑虽然输出文件里数字是25但实体尺寸差了几十倍。我的铁律是全项目统一单位并且在提示词第一行写明“所有尺寸默认毫米只能是数字不允许换算不允许单位换算不允许四舍五入。”如果用户输入“1cm”我会让模型先换算成10mm再写进代码最后在自检说明里明确标出“原输入为1cm已转换为10mm”。很多尺寸错误不是因为模型不会换算而是它懒得确认就自行发挥了。5.3 特征顺序和布尔运算冲突CAD建模像做菜先后顺序错了味道就完全不对。最常见的错误是“先倒角后打孔”。如果模型先给某个边加了倒角再打一个孔孔和倒角的边界相交位置会出现诡异的曲面碎片或者整个布尔运算直接失败。反过来先打孔再倒角通常就没事。我在校验环节专门加了一个“特征顺序检查器”规则很简单拉伸必须在切除之前打孔必须在凸台之后倒角必须放在所有影响面确定之后。如果生成的代码不满足这个约束就标记为失败让模型重写。这些规则听着笨但自动化流程里没有这些笨规则模型就会反复用同一个错误逻辑挑战你的耐心。5.4 评估指标怎么定不被“看起来像”迷惑很多人给text-to-cad系统评价一看渲染图觉得“很厉害”就放过去了。这是大忌。工业场景要的是数值可验证的结果我给自己定了一套最低通过标准检查维度通过标准实体有效性solid.isValid() 为True无自相交面尺寸精度关键尺寸偏差小于0.5%特征完整性孔数量、阵列数量、凸台数量完全一致体积误差与理论体积偏差小于2%导出互通能导出STEP并在其他CAD软件正常打开这套标准不算苛刻但能显著筛掉“看起来能用”的模型。事实上很多生成结果连第一关都过不了实体有效性直接就是False。所以如果你的text-to-cad流程里没有自动校验那你就等于在高空走钢丝全靠肉眼当安全网。6. 把text-to-cad放进真实工作流后我的几个变化跑了大半年之后我的建模习惯确实被改变了。最明显的一点是以前接到一个非标零件的建模需求我第一反应是打开CAD软件开始画草图现在我的第一反应是先在文档里把需求描述写清楚尺寸、公差、特征顺序、默认单位全部结构化。因为如果这段描述能让LLM生成一个靠谱模型那这段描述本身已经足够让我自己快速建模了。说白了text-to-cad逼着我养成了“先定义清楚再动手执行”的习惯。第二个变化是建模时间分布完全变了。以前画一个中等复杂度的零件画草图加拉伸加打孔加阵列熟练工大概15到20分钟其中有10分钟其实是在做机械性操作。现在让LLM生成加校验稳定情况下3分钟以内能出一个版本但校验和修正时间增加了。我每天做的不是“更快地建模”而是“更快地判断这次生成是不是靠谱”。第三个变化是协作模式。以前别人找我建模要把需求写得很详细我再翻译成CAD操作现在同事只需要在群里发一段自然语言我把它整理成结构化需求扔给模型生成省掉了中间反复沟通的成本。当然我依然会在关键尺寸和装配关系上自己过一遍这种事没法偷懒。最后说一个很实际的体会你不需要等text-to-cad成熟到“输入一句话就得到精准能加工模型”再用。现在这个阶段它已经能在标准件、结构件、简单壳体这类建模中帮你省掉大量重复劳动。它不稳定、会犯错、需要你兜底但就像一个能帮你打草稿的实习生方向感大致对细节要你检查用好了效率提升非常明显。如果你打算试我最想提醒的就是务必把校验环节做扎实否则你省下的时间都会在后期修改模型时加倍还回去。
