从第一次看到用自然语言直接生成CAD模型这个说法到我自己真正把一段产品描述变成可编辑的STEP文件中间隔了大半年。text-to-cad这个方向不算新但直到LLM能力爆发之后才算真正落地——它不是简单地把文字变成一张图而是要把人类的模糊意图翻译成精确的几何约束和建模操作序列。这篇文章我打算把底层逻辑、能直接上手的工具链、完整实操流程和我在上百次生成中踩过的坑一次说清楚给正在研究这个方向的产品设计师、机械工程师和3D打印玩家一条真正可复现的路径。1. Text-to-CAD到底在解决什么问题从模糊话术到精确几何1.1 传统建模的痛点在哪里我接触过的设计师和工程师绝大多数时间不是花在想设计什么上而是花在怎么把设计意图告诉软件上。打开Fusion 360或者SolidWorks画草图、拉约束、做拉伸、挖孔、倒角每一个动作都要手动完成。就算你已经是快捷键熟练工一个中等复杂度的零件从零开始建半小时到一小时是常态。问题不是软件不够强而是人机交互的带宽太窄——你脑子里已经有一个完整的三维形象但交给软件时只能一个特征一个特征地喂。text-to-cad要解决的就是这个带宽问题。它把描述设计意图和执行建模操作这两件事拆开了你只负责说清楚我想要什么剩下的草图、特征、布尔运算、参数化关系全部交给模型自动生成。对于像我这样经常要做快速原型验证的人来说这个价值极其直接——很多结构件我根本不需要手工精雕细琢能快速出一个能编辑、能改尺寸、能拿去3D打印或者做仿真分析的实体模型就够了。1.2 两种技术路线的分野端到端生成 与 代码中介生成现在市面上能跑的text-to-cad方案表面上看五花八门本质上只有两条路线。第一条是端到端生成。输入一段文字模型直接输出几何构型要么是体素表示要么是三角网格要么是点云有些研究性的工作还会直接生成BREP边界表示的拓扑结构。这条路线看起来很酷但有一个绕不开的问题CAD行业的根基是参数化和可编辑性端到端模型生成出来的几何往往是死的——你拿到一个STL网格想回去改某个圆角的半径不好意思没有特征树没有历史记录改不了。而且端到端模型在复杂结构、精确配合、大尺寸装配上表现得非常不稳定稍微偏离训练数据分布结果就崩给你看。第二条是代码中介生成这也是我目前主推的路线。它用LLM把自然语言翻译成一段程序化建模代码常见的有OpenSCAD脚本、CadQuery的Python代码或者更接近传统CAD语义的指令序列比如新建草图-画圆-拉伸-打孔。然后由对应的程序化内核去执行这段代码生成真正的实体模型。这条路线最大的优势是可编辑性代码本身就是参数化模型想改尺寸改位置改一行代码重新生成就行。它的缺点是建模能力受限于DSL领域专用语言的表达范围但对我们日常90%的机械结构件来说这个范围完全够用。1.3 为什么文字生成程序化建模指令是目前最靠谱的落地姿势我自己的体会是CAD建模这件事本质上是一个程序化过程。你在软件里做的每一个操作其实都对应一条建模指令画一个矩形、拉伸20毫米、减去一个直径8毫米的孔、给这条边倒个角。这跟写代码没有本质区别只是传统软件把它包装成了鼠标点击而已。所以用LLM去生成建模指令序列天然就更贴合CAD的底层逻辑。还有一个实际层面的原因可容错。LLM生成OpenSCAD代码如果语法错了、布尔运算失败了报错信息非常明确你让模型看错误信息重新生成就行改造成本远低于端到端模型重新跑一遍推理。有经验的玩家甚至会把生成代码→CLI渲染→报错回填→再生成做成一个自动循环最终收敛到可用模型。这种程序执行即验证的机制是端到端生成路线很难提供的。所以我的结论是别被输入一句话直接出模型的Demo迷惑真正能在生产环境里跑稳的几乎都是代码中介路线。2. 当前能直接上手用的工具与模型清单2.1 程序化代码路线LLM OpenSCAD / CadQuery先说我自己用得最多的组合Claude或GPT类LLM OpenSCAD。OpenSCAD是一个用代码描述几何的建模工具语法说白了就是CSG构造实体几何那一套union()做并集difference()做差集translate()做平移rotate()做旋转。它不像Fusion 360那样有交互式界面但正因为它是纯代码的LLM对它的掌握程度非常高——OpenSCAD语法稳定、函数少、没有版本遗留问题模型几乎不会生成幻觉API。CadQuery是另一个优秀选择。它用Python构建模型比OpenSCAD更接近传统CAD的特征建模概念先画二维草图再拉伸、开孔、倒角语义更丰富而且可以导出STEP格式能直接进SolidWorks、Fusion 360做后续设计。缺点是对LLM来说生成的代码偶尔会在Workplane的上下文切换上出错需要多调几次。2.2 专用Text-to-CAD模型与平台除了自己调LLM写代码现在也出现了专门面向CAD的深度学习模型和平台。像Zoo团队发布过Text2CAD的研究成果和配套数据集输入自然语言描述模型会输出一系列CAD建模原语加草图、加约束、拉伸等我能用到的成熟度还没到生产级但作为趋势参考很有价值。另一类是商业软件厂商提供的text-to-cad功能我记得Fusion 360那边做过类似的预览演示输入一个带四个安装孔的矩形底座就能自动生成带特征树的模型但这类功能往往限定在自家生态里导出和二次开发的灵活性反而没那么高。我的建议是在专用模型没有发展成能生成可编辑参数化模型之前用通用LLMDSL代码是最具性价比的组合。专用模型目前很多还是输出一个固定的体素网格或者一组固定指令序列对实际设计工作的帮助有限。2.3 网格生成路线的取舍还有一种路线经常被混进text-to-cad讨论里就是文本转3D网格比如常见的Meshy、Tripo、Point-E这类。输入一句话生成一个带纹理的三角网格模型。这类工具做视觉概念、游戏资产、效果图预览非常棒产出速度极快、造型自由度极高但它生成的网格基本不适合做工程结构件——不是实体模型没有厚度语义没有特征树不能做布尔减运算也不能进CAM软件做刀路。如果只是给客户看一个外形效果用它很合适如果要做装配配合、要出工程图、要数控加工那还是老老实实走程序化CAD路线。网格和实体之间的鸿沟不是靠后期转换能填平的。2.4 工具选型快照路线代表方案输出格式可编辑性适用阶段代码中介LLM OpenSCADSTL/CSG脚本强改代码即可结构件、3D打印快速原型代码中介LLM CadQuerySTEP/STL强Python参数化需要进专业CAD软件的场合端到端生成Text2CAD类科研模型指令序列或部分BREP中取决于产物研究探索、概念参考文本转网格Meshy/Tripo/Point-ESTL/OBJ网格弱不可参数化视觉预览、游戏资产3. 一次完整的Text-to-CAD建模实操把一句话变成可编辑的STEP文件3.1 场景定义与工具选型我拿一个真实的快速原型需求来演示要做一个无人机云台电机的安装支架一端是标准的25mm×25mm电机安装面四个M3通孔另一端伸出两个臂整体壁厚3mm。这种零件用传统方式建我大概要花四十分钟用text-to-cad我给自己定的目标是十五分钟拿到可编辑模型。选型上我用的是CadQuery路线原因有两个第一这个支架需要导出STEP文件后续要在Fusion 360里做轻微调整并出加工图STEP兼容性最好第二CadQuery支持真正的特征建模生成的代码结构清晰方便我拿到后手动改参数。如果你只是做3D打印验证OpenSCAD就够用了流程会更简单。3.2 提示词怎么写才能让结果一次成型这里有一个经常被忽略的关键点text-to-cad的提示词不是越口语化越好而是要遵循材料-结构-尺寸-公差-装配的五段式结构。我最后的提示词大概是这样的使用CadQuery创建一个电机安装支架。底座是一个25mm×25mm的正方形平板厚度3mm平板四角各有一个直径3.2mm的通孔孔心距离边缘5mm。底座中央上方是一个直径20mm的圆柱凸台高度8mm凸台中心有一个直径10mm贯穿底座的孔。从底座左右两侧分别向外延伸出一个安装臂长度为30mm宽度为12mm厚度与底座一致每个臂末端有一个直径4mm的安装槽。所有锐边倒角0.5mm。整体使用毫米作为单位。这段提示词里每一句话都对应一个明确的建模操作。我见过太多人只写帮我做一个电机支架结果模型完全不可用——不是模型能力不行是你的提示词信息量不够。对LLM来说它缺的不是想象力而是约束条件。3.3 代码生成到模型导出的具体流程拿到提示词之后让LLM生成CadQuery代码但不要直接跑。我习惯把生成过程拆成三步走第一步让LLM先生成结构清单用文字列出这个零件包含哪些特征底座、四个孔、凸台、贯穿孔、两个臂、两个槽、倒角。这一步是让模型自己检查一遍逻辑完整性如果它列出的特征和你的需求不一致这时候改比生成代码之后再改省事得多。第二步让它基于结构清单生成完整Python代码。CadQuery的代码大概是下面这个样子import cadquery as cq # 底座25x25x3mm平板 base cq.Workplane(XY).box(25, 25, 3, centered(True, True, False)) # 四个M3通孔孔心距离边缘5mm base (base .faces(Z) .rect(25 - 5*2, 25 - 5*2, forConstructionTrue) .vertices() .hole(3.2) ) # 中央圆柱凸台 hub (base .faces(Z) .workplane() .circle(20/2.0) .extrude(8) .faces(Z) .workplane() .hole(10) ) # 左右安装臂 arm_left (hub .faces(Z) .workplane() .center(-(25/2 30/2), 0) .rect(30, 12) .extrude(3) )注意这里有一个坑我用centered(True, True, False)指定了Z轴方向不居中这样模型会自动从Z0平面往上长后续加特征时坐标系更直观。这段代码不保证一次对LLM经常会漏掉faces(Z)的选定步骤导致新特征长在错误的位置上。第三步在本地执行代码。如果你装了CadQuery环境直接用cq.exporters.export(result, mount_bracket.step)导出STEP文件。但如果你不想折腾Python环境可以考虑用在线CadQuery编辑器或者通过Jupyter跑错误信息会直观很多。我第一次跑的时候果然报了错——错误是未找到治延伸的边后来让LLM看了错误信息它自动修正了倒角逻辑用edges(Z).fillet(0.5)替代了原来的全边倒角第二次跑通了。3.4 拿到模型后的倒角、孔位与参数修正代码跑通之后模型已经生成了但工作还没完。STEP文件导入Fusion 360之后我通常会做两件事第一件事是核对关键尺寸。生成模型的尺寸可能和你的设计意图有1-2毫米偏差比如孔位分布不居中、壁厚不一致。不要试图在CAD界面里直接拉伸修正那样会破坏特征结构。正确做法是改CadQuery代码里的参数重新导出再导入替换。反正有代码改起来就是改几个数字的事。第二件事是二次检查加工工艺问题。text-to-cad生成的模型天然缺少工艺意识。它不会帮你考虑加工时刀具能不能伸进去、注塑时的脱模斜度够不够、3D打印时悬垂能不能支撑。我那个支架生成出来之后两个安装臂是水平悬挑的直接上FDM打印会有很大的支撑面。我给提示词里加了一句安装臂底面从根部到末端做2度的倾斜让LLM补了一个rotate(1.0, 0, 0, 2)的操作悬垂问题就解决了。记住AI负责几何你负责制造意识。4. 避坑实录我在上百次生成中总结的高频失败原因4.1 提示词里的尺寸单位与坐标系歧义最常见的失败原因听起来很蠢单位没写清楚。CAD行业里毫米和英寸的分歧害死人LLM训练数据里两种单位都有。如果你说做一个50的方块模型可能默认成50毫米也可能50英寸同一个提示词跑两次能出两个相差25倍的结果。我现在的习惯是每一句涉及尺寸的描述后面都强制带上单位并且在提示词最后加一句所有尺寸均以毫米为单位。另一个高频问题是坐标基准。你说在左上角放一个孔左上角这个说法在三维空间里是模糊的——是在哪个平面上看是从哪边看的我会尽量用以底座中心为原点孔心距离左边缘5mm、距上边缘5mm这类明确表述。4.2 布尔运算失效与几何退化这是代码生成时最容易踩的技术坑。OpenSCAD和CadQuery底层都是靠几何内核做布尔运算的当两个几何体刚好共面、刚好相切、或者尺寸为零的时候内核经常会报错或者生成不可用的退化实体。典型场景是你挖一个和底座刚好一样大的通孔结果布尔差集把整个底座减没了或者你的凸台和底面刚好共面倒角时找不到那条边。我在流程里加了一步几何健康检查生成模型后马上用checkGeometry相关的特性做一次质量检查再拖到切片软件里看一眼有没有破洞。如果发现几何退化最简单的处理是在提示词里加一丁点重叠量比如孔的直径比标称值大0.01mm或者把拉伸高度多给0.5mm再裁掉。这看起来不优雅但非常有效。4.3 代码可读性与后续修改的冲突另一个容易被忽视的问题LLM生成的代码可能功能完全正确但可读性极差。它会莫名地把所有操作用嵌套函数串成一长条或者把参数全部硬编码在几十个魔法数字里。你生成的模型拿回来想改一个宽度得在一堆数字里找哪个对应宽度。我的解决办法是在提示词里明确要求使用变量定义所有尺寸参数并把关键参数放到文件开头的参数块中。下面是我常用的代码结构模板# 参数块 BASE_WIDTH 25 # 底座宽度 BASE_HEIGHT 25 # 底座长度 PLATE_THICKNESS 3 # 壁厚 HOLE_DIAMETER 3.2 # 通孔直径这样一来LLM生成的代码就有了参数与逻辑分离的结构后续手动修改和让LLM二次修改都轻松很多。让LLM修改代码时我只需要告诉它把BASE_WIDTH改成30它不会误伤其他逻辑。4.4 一个完整的失败排查链路我记录一个真实的坑帮你看清楚排查思路。有一次我用OpenSCAD生成一个带六边形阵列孔洞的散热面板结果渲染出来发现孔全是实心的等于面板没有透孔。我的排查链路是这样的第一步看代码我让LLM生成的代码里有一个linear_extrude和difference()的嵌套从语法上看完全没有问题。第二步看几何运算顺序问题就出在这里——它把difference()用在了所有板子的外包络上但六个六棱柱的挖孔操作全部写在了这个difference()之前于是挖孔操作的对象是原始矩形板而后面又被一个完整的板子盖住了。用大白话说你先在纸上剪了六个洞然后又把一张完好的新纸贴了上去。第三步是修复我让LLM把生成六棱柱的代码块移动到difference()的括号范围之内或者直接用for循环在一个difference()上下文中完成所有挖孔。修正后重新渲染孔全部正常。这个案例给我最大的教训是机器学习模型对布尔运算作用域的理解非常薄弱你必须自己人工检查代码里difference()里到底包含了哪些子操作。还有一个教训LLM生成OpenSCAD代码经常出现先translate再rotate和先rotate再translate搞反的问题。如果模型告诉你某个孔的位置偏移了10mm优先检查变换顺序而不是盲目改坐标数值。这个坑在旋转对称的零件中尤其频发我后来养成了习惯凡是涉及旋转的操作都会在提示词里明确写出旋转和位移分开写先旋转后平移。5. 边界条件与工作流进阶什么时候别用Text-to-CAD5.1 适合与不适合的场景对照text-to-cad不是万能钥匙我认为目前的适用边界可以画得比较清楚场景类型推荐程度原因快速原型验证3D打印结构件高度推荐需求明确、几何简单、迭代快标准零件/简单钣金件推荐描述逻辑清晰容易生成正确约束复杂自由曲面外观设计不推荐语言描述自由度太高几何不精确大型装配体/运动机构不推荐装配约束关系不是自然语言能描述的参数化系列产品尺寸变型非常推荐代码参数化天然适合做同构变体精密配合面/公差敏感件谨慎AI生成几何缺少公差语义需人工复核我见过很多人拿text-to-cad生成复杂外壳产品期望AI直接给一个可量产的造型结果失望而归。不是技术不行是方向不对——自然语言最擅长描述规则明确的结构逻辑不擅长描述需要审美判断的自由形态。自由曲面的设计老老实实用细分曲面工具吧。5.2 参数化模板与自然语言结合的经验text-to-cad最有价值的生产力场景我总结为结构模板 参数抽取的组合。具体做法是把我自己常用的结构件模板比如电机座、轴承座、外壳底座用CadQuery写好参数化代码存成模板文件。然后建一个提示词配方让LLM做从自然语言描述中抽取参数这件事——比如用户说需要一个适合42步进电机的安装座LLM负责把42电机对应的轴径、孔距、安装面尺寸查出来回填到模板的参数里输出新的代码生成定制的模型。这样做的好处非常明显几何结构是人工验证过的可靠模板LLM只做语义解析和参数映射犯错概率大幅下降。我去年做入门教学的时候用这套思路搭过一个小工具学员只需要填几句话描述需求就能生成可用的3D打印零件效果比我预想的好得多。这才是自然语言和CAD的正确协作方式——AI做翻译模板做保障工程师做决策。5.3 团队协作中如何沉淀文本到模型的资产如果你想让text-to-cad在团队里真正发挥作用光靠个人玩是不够的需要做资产沉淀。我现在会在每个项目的CadQuery代码目录里保留三样东西提示词原文、生成代码、最终使用的模型导出文件。下次遇到同类需求直接把提示词拿出来改几个参数就能复用。更进一步我会把历史生成过程中修正过的典型纠错对话整理成片段下次让LLM生成类似零件时直接把片段贴给它相当于把你的踩坑经验喂给了模型。这招本质上是在做小规模的提示词微调实测下来能让生成成功率从六成提升到八成以上。我还发现让LLM生成代码之前的结构清单确认环节特别适合团队协作。我习惯让LLM把设计分解成底座、凸台、安装孔、倒角这些建模特征然后发给机械工程师人工确认一遍再执行。工程师看到的是结构特征清单而不是代码沟通效率高很多。这个工作流跑顺之后设计师能腾出大量时间去做真正需要创造力的部分而不是在一个个拉伸、挖孔操作里消耗精力。我自己用下来最顺手的一套组合还是在LLM和OpenSCAD/CadQuery之间反复迭代先用结构清单跟模型对齐意图再生成代码跑失败就让模型自己看错误修最后导出STEP进专业软件精调。这个循环里最值钱的不是哪一步而是参数化代码这个中间产物——它让AI生成的东西不再是一次性的死模型而是可以被反复改、反复用的活资产。如果你也想试试text-to-cad别追求一步到位先拿一个你平时十分钟就能建完的小零件当试验品跑通一遍流程再逐步增加复杂度。最后分享一个小技巧把常用的建模约束写成一个提示词片段放在笔记里比如所有尺寸使用毫米倒角值不要小于0.5mm圆孔阵列优先使用for循环每次生成前附上你会发现整个过程的稳定性和可预期性会有质的提升。
