做机械设计和3D打印这几年我一直觉得“描述一句需求自动生成CAD模型”是只存在于演示视频里的东西。直到我把text-to-cad当关键词认真试了一圈然后被它当前的完成度惊到了从“给一个法兰底座板上均布5个通孔中心孔直径20毫米”这样的自然语言到能导出的STEP文件中间可能只需要几十秒而且中途几乎不用手画一条线。这篇东西不是科普推广是我自己从模型生成、参数调整、导出验证到踩坑修复的一线记录。无论你是做3D打印、搞机械结构验证还是单纯想给传统CAD建模找条捷径都可以参考。先说清楚text-to-cad不是把文字变成一张“好看的效果图”它要的是能进制造流程的实体模型。理解这一点后面所有的技术选型才有意义。1. 为什么text-to-cad不是噱头从建模门槛说起1.1 传统CAD建模的痛点三维CAD软件的核心一直是“通过几何操作构建精确边界表示”。你要画一个轴、一个法兰、一个支架每一步都在跟坐标、草图、约束、特征树打交道。这种交互方式对工程师来说是优势对没有受过训练的人来说就是极高的门槛。具体痛点集中在三块。第一学习曲线陡。草图约束、特征依赖、基准面选择任何一个概念没吃透模型就会崩。很多初学者画一个简单支架要反复修改多数时间并不是花在设计上而是花在“找回某个被删掉的参照”上。我见过不少动手能力很强的人建模软件用了三个月还只会最简单的拉伸切除。第二重复劳动多。同一类零件比如不同尺寸的安装底座无非是板厚、孔径、孔位在变但你还得重新建一次特征树。参数化做得好的团队会建模板库可模板库本身也是成本维护不及时就成了一堆没人敢动的废墟。第三从想法到模型之间隔着“语言转译”。工程师脑子里想的往往是功能定义这块要支撑、那里要通孔、相对位置是多少。而建模软件需要的是几何操作。这个转译过程不仅累还特别容易丢信息。你说“这里加个加强筋”换个人来建可能就建在完全不同的位置上。text-to-cad的价值不是取代CAD而是把“功能描述到几何定义”这一步自动化。它没有降低“模型必须精确”的要求只是把实现精确几何的过程从手动操作变成人机协作甚至自动生成。1.2 大语言模型到底在text-to-cad里扮演什么角色要理解这个方向先要厘清大语言模型在这场变革里的边界。很多人以为用了语言模型就意味着模型自己“理解”了机械设计。从我实测看远没到那一步。目前的语言模型真正做得好的是三件事。第一把自然语言解析成结构化参数。你说“四个M6通孔均布在直径80的圆上”它能准确抽取出数量、规格、布局方式和直径。第二生成可执行的程序化建模代码。它见过大量脚本能写出语法基本正确的几何生成代码。第三在提示词足够明确时给出合理的默认值比如材料厚度、倒角半径、螺纹底孔尺寸。但它在一件事上仍然很弱空间推理。你描述一个复杂装配关系或者要求它“让这两个面贴合的同时保证另一侧不影响运动”它的表现会大打折扣。这也是为什么现在实用的text-to-cad方案几乎都不是让语言模型直接输出网格而是让它生成可执行代码由CAD内核去做确定性计算。我打一个生活化的比方。语言模型像一位特别会写菜谱的厨师朋友他可以把“一盘鱼香肉丝”描述得明明白白但真正把食材切成丝、下锅炒熟还得靠后厨的设备。在text-to-cad里后厨就是CAD内核负责所有的几何计算和布尔运算。2. 技术路线全景实现text-to-cad的三种主流路径2.1 路径ALLM生成程序化建模代码最接近落地的路线程序化建模是我目前最推荐的切入方式。它的本质是语言模型输出CAD脚本代码然后由解析器执行并构建实体模型。典型代表是OpenSCAD和CadQuery。为什么这条路线最现实关键在于确定性。OpenSCAD本质是CSG布尔构造实体几何的脚本描述CadQuery则更接近传统特征建模的Python接口。无论语言模型在格式上怎么自由发挥最终执行的是经过语法检查的脚本而不是凭空生成的三角形网格。布尔运算、倒角、拉伸都交给底层几何内核做精度由内核保证而不是由模型“猜”出来。另外代码本身就是参数化模型。你今天让模型生成一个“40x30x8的底板四角M4通孔”拿到的不只是一个模型而是一份可以改参数的源文件。下次需要50x40的版本要么直接改脚本要么再喂给语言模型做增量修改这比传统重新建模高效得多。我自己的经验是CadQuery路线生成工业件的成功率远高于直接文本生成网格的路线。但代价是它对语言模型的代码能力要求高生成的脚本偶尔会有语义错误需要人工修一下。后面实操部分我会给出完整的例子。2.2 路径B端到端几何生成模型看着惊艳但离加工很远端到端生成是指用神经网络直接从文本生成三维几何常见输出包括体素、点云、隐式场或者网格。这类工作在视觉结果上非常抓眼球你说“一把椅子”模型真的会给出一把看起来像椅子的表面网格。问题在于几何模型要用于工程不是“看起来像”就够。工程模型要求边界表示是封闭的、流形的、无重叠面、尺寸可测量。而神经网络直接生成的网格往往要经过网格修复、简化、体素化等一系列后处理才能用。即便修完也丢失了特征树的语义没有拉伸特征、没有旋转特征、没有圆角历史后续改一个孔径都无从下手。它们做视觉概念预演可以但离“输出到加工”还有一条不小的鸿沟。还有一个被低估的问题是计算资源。这类模型通常要在GPU上跑推理部署成本比纯代码生成高得多。对于个人创客或小型工作室这个成本常常是劝退因素。2.3 路径C特征模板与约束求解被低估的工程化路线第三种路线我管它叫“模板参数映射”。它的思路是先准备好一批常用的工程特征模板比如法兰、轴承座、齿轮、壳体、标准件每个模板内部是完整的参数化逻辑然后通过语言模型或者规则解析把文本中的需求映射到模板参数上最后用内核重建模型。这条路线的好处非常明显。第一只要是模板覆盖范围内的零件生成结果几乎不会出问题因为几何逻辑已经写死了。第二参数都能回到特征树里后续修改很自然。第三对语言模型的依赖小甚至用传统自然语言处理也能做得很稳。缺点同样明显——覆盖范围有限。它本质是“在罐头里选罐头”一旦需求超出模板库比如一个不规则的支撑肋支架就没有任何发挥空间。从产品化角度来说我认为路线C最容易做到“开箱即用”路线A上限更高路线B更适合做预研和视觉展示。选哪条取决于你要解决的是“快速出可用零件”还是“探索全新造型”。比如我现在手头有一个小批量自动化设备项目里面大量的传感器安装支架、电机座、线缆固定板都属于典型模板件路线C完全够用。而一旦遇到非标铝型材连接件模板覆盖不到我就会切到路线A让语言模型直接生成CadQuery脚本再手动调整。3. 实操用LLM生成CadQuery代码从一句中文到STEP文件3.1 环境准备我用的组合是Python环境加CadQuery加上一个对话式语言模型来生成脚本。CadQuery的安装可以直接用pip推荐在虚拟环境里操作避免污染系统Python。python -m venv cadenv source cadenv/bin/activate pip install cadquery安装完成后先验证一下内核是否正常import cadquery as cq b cq.Workplane(XY).box(10, 10, 10) print(b.val().BoundingBox())如果打印出包围盒坐标说明OpenCASCADE内核已经就位。CadQuery底层用的是OpenCASCADE这个内核本身就是工业级CAD内核所以执行的布尔运算、倒角、拉伸精度都有保证。3.2 一个完整的例子设计一个法兰底座我拿一个典型的工程件来演示法兰底座。最初我给语言模型的提示词是这样的用CadQuery生成一个法兰底座模型。基板为长方形长80毫米、宽50毫米、厚10毫米。基板顶面中央有一个直径20毫米的圆柱凸台凸台高15毫米。凸台中心有一个直径10毫米的通孔。基板上围绕凸台中心均匀布置4个M6通孔直径6.5毫米分布在半径25毫米的圆周上。所有棱边不要求倒角导出STEP。第一次得到的代码大概率能跑但细节上往往会有问题比如孔洞跑到了基板外面或者凸台和基板没有合并。我这边手动修正后的完整代码如下import cadquery as cq # 基板长80、宽50、厚10 base cq.Workplane(XY).box(80, 50, 10) # 圆柱凸台直径20高15 boss cq.Workplane(XY).circle(10).extrude(15) # 把凸台移到基板顶面之上。基板厚10中心在Z5处 # 所以凸台底面圆心要平移到Z10这里translate((0,0,5))即可。 boss boss.translate((0, 0, 5)) # 合并基板和凸台 part base.union(boss) # 中心孔直径10 center_hole part.faces(Z).workplane().pushPoints([(0, 0)]).hole(10) # 四个螺栓通孔直径6.5均布在半径25的圆上 bolt_holes ( center_hole.faces(Z) .workplane() .pushPoints([(25, 0), (-25, 0), (0, 25), (0, -25)]) .hole(6.5) ) cq.exporters.export(bolt_holes, flange_base.step)这里我要专门提醒一点。CadQuery里打不同直径的孔最稳的方式是分两个步骤先选中心点打中心孔再选其余四个点打螺栓孔。用一次pushPoints把两组点混在一起再统一给一个孔尺寸是新手最容易犯的错误它会把中心孔也打成6.5毫米。执行完这段代码用任意一个能打开STEP的软件检查你会看到基板、凸台、五个孔都齐了。3.3 对比一下OpenSCAD路线同样一个法兰底座用OpenSCAD写出来是这样的difference() { union() { cube([80, 50, 10], centertrue); translate([0, 0, 5]) cylinder(r10, h15, centerfalse); } // 中心孔 translate([0, 0, -1]) cylinder(r5, h30); // 四个螺栓孔 for (a [0, 90, 180, 270]) rotate([0, 0, a]) translate([25, 0, -1]) cylinder(r3.25, h30); }两条路线没有绝对优劣。OpenSCAD胜在语法简洁语言模型生成它的成功率更高社区里也积累了海量的脚本可以直接喂给模型做示例。CadQuery胜在编程范式更接近传统特征建模对复杂实体、装配体支持更好而且Python生态能轻松做批量校验、体积计算和脚本化管理。我做批量零件族的时候倾向于CadQuery因为可以写一个循环一次性生成几十个尺寸变体。我只是随手验证单个零件形状的时候会优先用OpenSCAD因为代码短语言模型几乎不会写错。3.4 提示词模板让生成结果稳定下来纯靠“说一句话”让模型自由发挥结果不稳定。我现在习惯把常见的零件类型整理成提示词模板关键参数用占位符替换给模型一个结构化的输入。下面是我实际在用的一个模板样式生成一个{连接件类型}模型用于{用途描述}。 主体尺寸长{长度}毫米宽{宽度}毫米高{高度}毫米。 安装孔{数量}个直径为{孔径}毫米中心位于{位置描述}。 单位所有尺寸均为毫米。 坐标系长度沿X轴宽度沿Y轴高度沿Z轴。 输出格式{CadQuery | OpenSCAD}代码并附导出STEP文件的语句。这个模板看起来啰嗦但它把最容易引起歧义的维度、坐标系、输出格式都约束住了。我实测下来结构化的提示词比随意口述的成功率高出很多尤其是生成结果的尺寸准确率能提升一个量级。3.5 导出与三层验证生成模型只是开始验证才是重头戏。我通常做三层检查。第一层是代码层检查主要看有没有语法错误、特征名错误、布尔运算是否成功。CadQuery的异常信息一般很直接比如“无法找到Face”就说明面选择语句写错了。第二层是几何层检查用包围盒和体积来判断模型是否符合预期import cadquery as cq part cq.importers.importStep(flange_base.step) box part.val().BoundingBox() print(长:, box.xlen, 宽:, box.ylen, 高:, box.zlen) print(体积:, part.val().Volume())如果包围盒是80x50x25说明基板尺寸和凸台总高都对得上。体积也可以反推粗算基板80×50×10是40000立方毫米凸台大约3.1416×10×10×15约4712立方毫米减去孔的体积应该在42000立方毫米上下。如果偏差巨大赶紧回头查特征。第三层是工艺层检查。这一步我会看最小壁厚、孔边距、是否能顺利脱模。有些模型几何上没问题但孔离边缘太近加工时会崩边这就不是text-to-cad的问题而是设计本身的问题。4. 场景拆解text-to-cad最适合做什么以及不适合做什么4.1 真正好用的场景以我接触的项目来看text-to-cad在下面几个场景效率提升最明显。第一非标支架和底板。许多自动化设备调试时都需要临时支架、传感器安装板、电机座。它们结构简单但尺寸各不相同。过去每个都要重新建模现在只需要用文字描述长宽高、孔位布局和安装高度生成脚本后微调下单到3D打印或激光切割整个流程可以压到一小时内。第二标准件变体管理。法兰、端盖、齿轮毛坯这类零件家族化特征强。把常用规格整理成提示词模板每次需要新规格时直接套用不仅出图快还天然保持格式统一。我有个习惯每次做完一个满意的零件就把提示词和生成的代码一起归档累积起来就是一个小型知识库。第三教学演示和方案评审。做方案时最怕“讲了半天对方脑子里没有形状”。text-to-cad可以快速生成示意模型让评审会从空对空变成对着模型讨论。它不一定能达到最终精度但足够把沟通成本降下来。我甚至见过有同事用它当场改方案客户说“孔距再大一点”他改一句提示词几十秒后新模型就投到了屏幕上。4.2 目前还不适合的场景我也踩过坑所以必须泼几盆冷水。第一高精度装配。如果你的目标是做一套齿轮啮合的装配体文字生成出来的齿轮大概率不能直接配合。齿形、模数、齿厚、变位系数这些参数语言模型很难一次性生成到位往往需要后续用专门的模块重做。第二复杂曲面。涉及流体外形、表面自由曲面、人体工学造型时端到端生成或者程序化生成都很难覆盖。这类设计本质上依赖人的迭代和判断不是一句描述能交代清楚的。第三包含运动链的机构。text-to-cad生成的是几何体不是运动学模型。它不会替你判断连杆长度是否满足运动范围也不会告诉你电机扭矩够不够。指望它做机构设计现在还太早。我在实际使用中的体会是把text-to-cad定位成“需求到几何草样”的加速器而不是“设计替代者”会舒服很多。它帮你跳过重复建模但设计判断还是要你自己做。5. 常见问题与避坑指南5.1 生成结果不稳定同一句话两次生成不一样这是语言模型的老毛病。同样一句“四个M6通孔”第一次给你生成4个第二次可能生成6个第三次直接理解成沉头孔。我现在的习惯是把提示词写成固定模板关键参数用占位符替换不给模型自由发挥的空间。比如生成一个{长度}x{宽度}x{厚度}的{连接件类型}上面有{数量}个直径{孔径}的通孔孔位于{位置描述}。同时建议在比较专业的CAD生成场景里合理控制对话中的随机性。降低随机度能显著减少结构性变化。5.2 布尔运算失败或孔洞消失几何内核做布尔运算时如果两个面正好共面或者一个实体完全包住另一个实体可能会出现奇异的结果。最典型的坑是你要在一个圆柱凸台中心打孔结果孔和凸台没有相交代码却不报错只是孔深度不够。排查思路分三步。第一步看生成代码里的实体是否真的相交可以用包围盒比较两个实体的范围。第二步检查拉伸方向负方向拉伸容易把特征做到另一侧。第三步实在找不到原因就把布尔操作拆开用最小示例逐步检查。其实很多布尔运算的问题是语言模型对“坐标系原点”的理解偏差造成的。比如CadQuery的box默认是中心对称的而OpenSCAD的cube默认是角点定位的。如果模型把这两条路线的坐标习惯搞混生成结果就会错位。5.3 尺寸语义模糊直径、半径、轮廓还是实体文字交流最大的问题就是语义歧义。你说“直径20的圆”模型可能给你生成半径20的圆你说“长80宽50的板”模型可能把80当成总宽而不是长度。我这里有一条实用经验提示词里主动把所有几何关键词跟单位绑定并且加上“中心”“边界”“外廓”等限定词。比如“基板外形为长方形长度沿X方向80毫米”“凸台中心对齐基板顶面中心”。限定词越具体模型犯错的概率越低。5.4 单位与坐标系混乱工程上毫米习惯根深蒂固可模型的世界里单位未必是毫米。如果某个生成脚本里出现25.4这种数字先怀疑是不是英寸混进来了。在提示词里显式声明“所有尺寸单位均为毫米”看起来多此一举其实能省很多排查时间。坐标系方面CadQuery默认工作平面是“XY”初始方向可能跟你的预期不一致。建议生成后先用包围盒打印检查一下长宽高分布别到了后面装配才发现长宽反了。5.5 生成模型的“看着像”和“能加工”是两回事最后一条经验最重要。很多端到端生成模型给你一个兔子、一把椅子图片上完美无缺你一导入切片软件就发现网格是破的根本无法打印。工程领域要的不是“视觉像”而是“拓扑对”“尺寸对”“可制造”。所以在引入text-to-cad工具时一定要先明确它输出的格式是STEP这种边界表示还是STL这种网格表示。前者能进CAD流程后者通常只适合3D打印展示。我自己的项目里凡是最终要交付加工的一律要求输出STEP并且做一遍体积和包围盒校验。凡是只做视觉参考的才允许输出STL。这条底线守住了基本不会出大事故。下面把最常撞上的三个问题整理成速查表方便你直接对照处理现象可能原因处理方式同一提示词两次结果不同生成随机性过高改用结构化模板降低随机度孔深度不够或孔消失布尔运算基准面选错用包围盒检查实体位置调整拉伸方向尺寸全部偏大或偏小英制单位混入提示词显式声明毫米检查脚本中的25.46. 后续可以怎么扩展这个方向还远没有到天花板我觉得值得试的几个扩展方向如下。第一把text-to-cad和3D打印切片流程串起来。生成的STL直接丢进切片器快速出实物原型。对非标零件这个链路能把“想法到手指摸到实物”的时间压缩到以小时计。我做过一个测试从文字描述一个线缆固定夹到3D打印机开始工作总共用了不到四十分钟其中大部分时间还是在等切片。第二接入本地零件库。把团队沉淀的常用参数化零件导入CadQuery模板再用语言模型做自然语言检索和调参。相当于给老图纸装上了“语音控制”。工程师说“我要一个直径60的法兰四个安装孔”系统直接调出模板生成模型比翻图库、找旧图快得多。第三多模态输入。文字描述加一张手绘草图或者加一张参考照片能显著提升生成准确性。虽然多模态模型已经开始普及但在CAD领域如何把图像中的拓扑约束稳定地转成参数仍然有大量工程细节要打磨。如果你也想上手我建议从CadQuery加语言模型这个组合开始花一个下午把文中法兰底座的例子跑通然后换成你自己最常画的零件试一次。几轮试下来你会逐渐摸清哪些话术有效、哪些描述会被误解形成属于你自己的提示词模板。这个摸索过程本身就是text-to-cad从“网红词汇”变成“生产力工具”的关键一步。最后再分享一个小技巧每次用text-to-cad成功生成一个零件我都会把最终版的提示词和代码存成一个Markdown文件放到同一个目录里。几周之后回头翻这些文件就是你自己的最佳实践手册比任何网上的教程都更贴合你的实际工作。