从第一次看到"用自然语言直接生成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那边做过类似的预览演示，输入"一个带四个安装孔的矩形底座"就能自动生成带特征树的模型，但这类功能往往限定在自家生态里，导出和二次开发的灵活性反而没那么高。

我的建议是：在专用模型没有发展成"能生成可编辑参数化模型"之前，用通用LLM+DSL代码是最具性价比的组合。专用模型目前很多还是输出一个固定的体素网格或者一组固定指令序列，对实际设计工作的帮助有限。

2.3 网格生成路线的取舍

还有一种路线经常被混进text-to-cad讨论里，就是文本转3D网格，比如常见的Meshy、Tripo、Point-E这类。输入一句话生成一个带纹理的三角网格模型。这类工具做视觉概念、游戏资产、效果图预览非常棒，产出速度极快、造型自由度极高，但它生成的网格基本不适合做工程结构件——不是实体模型，没有厚度语义，没有特征树，不能做布尔减运算，也不能进CAM软件做刀路。如果只是给客户看一个外形效果，用它很合适；如果要做装配配合、要出工程图、要数控加工，那还是老老实实走程序化CAD路线。网格和实体之间的鸿沟，不是靠后期转换能填平的。

2.4 工具选型快照

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, forConstruction=True) .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轴方向不居中，这样模型会自动从Z=0平面往上长，后续加特征时坐标系更直观。这段代码不保证一次对，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-CAD

5.1 适合与不适合的场景对照

text-to-cad不是万能钥匙，我认为目前的适用边界可以画得比较清楚：

我见过很多人拿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循环"，每次生成前附上，你会发现整个过程的稳定性和可预期性会有质的提升。