干了十几年CAD/CAE相关的工作，第一次看到“text-to-cad”这个词的时候，说实话我愣了一下——把文字直接变成CAD模型，这不就是把我早年带徒弟时嘴里念叨的那些话给自动化了？后来真正上手试了一圈，我的评价是：这东西目前的定位不是“取代你画图”，而是“帮你把脑子里还没完全成型的想法，快速变成一个可以继续改、可以拿去出图加工的三维模型”。
text-to-cad，简单理解就是输入一段自然语言描述，系统自动生成对应的CAD三维模型。主流的输出格式是STEP这类通用且带参数语义的格式，也有不少实现会直接给出一段可复现的模型构建代码。这篇文章我从实际使用的角度完整拆一遍：它有哪些实现路线、核心技术点卡在什么地方、真实工作流里到底怎么用，以及我亲测踩过的那些坑。
如果你是机械设计、产品结构、3D打印方向的工程师，或者在搭自动化设计工具链，又或者团队想把CAD入门门槛降下来，这篇对你都有参考价值。下面全部是实操层面的东西，没有空谈。
1. text-to-cad 到底在解决什么问题：从聊到图，而不是从图到图
1.1 传统CAD的抱怨循环与生成式设计的交汇点
做设计的都知道一个很尴尬的场景：领导或客户过来说“这个底座给我加四个孔，最好能跟现有的安装位置对得上”，或者“我们要一个类似法兰盘的东西，但比现在这个薄一点”。你打开软件，建草图，标约束，拉伸切除，折腾二十分钟，交付的其实就是一个你脑子里早就想清楚的东西。
卡点从来不在“怎么画”，而在“把语言描述翻译成几何操作”这层转换。text-to-cad想干掉的就是这个转换。
但这里要泼一盆冷水：它和市面上那些“输入一句话生成一个3D模型”的AI玩具完全不同。那些玩具生成的是mesh网格模型，拿来当游戏资产还行，拿去做机械加工就是灾难——没有特征树、没有参数、没有公差概念。真正意义上的text-to-cad，输出应当是参数化CAD模型，或者至少是带明确几何语义的BREP实体，能导入SolidWorks、Fusion 360、FreeCAD继续编辑，甚至直接生成STEP给CAM编程。
这才是它和文生3D素材的本质区别。它服务的是工程场景，不是视觉场景。
1.2 两条主要技术路线：生成代码 vs 直接生成几何
我试过的text-to-cad实现，基本可以分成两大类。
第一类是“代码生成路线”。系统把自然语言描述转换成一段程序，最常见的是生成CadQuery或OpenSCAD脚本，然后由这个脚本在本地或云端执行，构建出三维模型。这个路线的最大好处是可复现、可编辑、可审计——你觉得生成的模型不对劲，可以直接看代码，改一个参数重跑一遍就有新模型。MIT那边有个Text2CAD的工作就是走这个方向，Zoo（zoo.dev）的text-to-cad API也是这个思路的典型代表。
第二类是“直接几何生成路线”。用一个大型生成模型直接输出STEP文件或BREP体，中间不经过显式的代码表示。这条路线的优势是语言理解可以做得更“端到端”，但缺点是生成结果像个黑盒，出了问题不好定位，而且STEP文件这类CAD数据没有像图像那样成熟的生成模型可以直接套用，目前鲁棒性普遍还偏弱。
两条路线我都跑过，现阶段做实际项目我更推荐代码生成路线。不是说直接生成几何不好，而是它太依赖训练数据里见过的形状，稍微复杂一点的装配关系、孔位分布，十次里有七八次要出幺蛾子。代码生成路线哪怕模型理解偏了，你还能通过改代码强行纠偏。
1.3 为什么说它适合作为设计前端的“概念加速器”
我的粗浅判断是，text-to-cad目前最合适的定位，是概念设计阶段的加速器。
早期方案探讨的时候，模型需求往往是模糊的：“大概这么大”“中间有个通孔”“四角倒圆角”。以前我得画一版草图跟人对，来回改三五次才能敲定方案。现在我把这些模糊描述扔给text-to-cad，一分钟内拿到一个能转能看的初版，大家对着它聊，语义立刻具象化。等需求明确了，再回到传统CAD里做正式建模。
这个过程节省的不是画图时间，而是“沟通迭代”的时间。对做非标设备、工装夹具、产品结构设计的人来说，这个节省非常可观。
2. 核心技术点拆解：从一句话到一份STEP文件，中间要闯几关
2.1 语义理解层：如何把“一个穿通的孔”翻译成特征
第一个核心关卡是语义理解。这听起来是NLP的事情，但实际上它需要的是“工程语言理解”，比普通自然语言理解更刁钻。
举个例子，你说“中间有个孔”，普通AI理解成图片里一个圆形区域就够了。但CAD系统必须搞清楚：这个孔是通孔还是盲孔？直径多少？轴线方向是什么？是相对于哪个面定位？要不要加螺纹？孔底是平底还是锥底？这些信息一句话里往往没写全，系统就得靠上下文推断或者主动设定默认值。
我见过不少翻车案例，问题都出在“常识性的省略”上。人会默认“法兰盘中间的孔是通孔”，但模型可能会给你生成一个盲孔，因为训练数据里的“孔”可能更多对应盲孔。解决这个问题的思路，要么是在prompt里强制要求描述完整特征类型，要么是在模型层做工程规则校验——比如检测到“法兰盘”这个关键词，自动套用法兰的常见特征模板。
这里有一个很重要的技巧：描述特征时，尽量使用工程图纸上的标准术语，而不是日常口语。说“通孔”比说“穿过去的洞”好使，说“沉头孔”比说“螺丝头能藏进去的坑”好使。模型对规范术语的学习更充分，歧义也更少。
2.2 几何约束与参数化：最被低估的硬骨头
第二关是几何约束的建立。这是text-to-cad和文生3D之间真正的分水岭。
一个合格的CAD模型，其特征之间是有拓扑关系的：螺栓圆的直径必须与法兰外径保持某种比例、孔的位置必须相对于中心轴对称、拉伸深度必须与壁厚关联。传统CAD里这些关系靠草图的几何约束和尺寸驱动来表达，而text-to-cad生成的模型，最怕的就是“一堆孤立的特征凑在一起，互相之间毫无约束”。
我实际拿到过一份text-to-cad生成的STEP文件：四个安装孔的位置是对的，但它们之间没有对称约束，也没有参考边。我试着在FreeCAD里把它转成可编辑的草图，结果一移动整个模型就散架。这种模型如果只是拿去看一眼倒无所谓，但想复用到参数化设计流程里就非常痛苦。
所以现在做得好的text-to-cad系统，都会在生成过程中显式维护一个特征依赖图：孔的定位要引用到所属平面、孔的中心要约束到基准轴、草图轮廓要和拉伸特征绑定。用户后面修改一个尺寸，关联特征要能同步更新。这也是为什么很多实现宁可走代码生成路线——代码天然能表达这种依赖关系，CadQuery里的每个workplane操作都自带上下文，比用网络直接输出几何要靠谱得多。
2.3 输出格式与下游兼容性：为什么最后都得回到STEP身上
第三关是输出格式。这一点做设计和制造的人一定要重视，因为它决定了模型能不能真正进入你的工作流。
text-to-cad的输出五花八门：有的直接给STEP，有的给原生代码，有的给用CadQuery序列化的JSON，还有的给glTF或STL。我个人的建议是：工程落地场景一律要求STEP格式。
原因很简单：
- STEP是ISO标准，几乎所有的CAD、CAM、CAE软件都能直接读写。
- STEP保存的是BREP实体几何，带拓扑和精度信息，可以用于数控编程和测量。
- STEP不依赖任何一家CAD厂商的私有内核，不会出现“Fusion 360里打开是实体、SolidWorks里打开变成了曲面”这种破事。
而STL这种网格格式，对工程来说是纯粹的坑。网格模型没有拓扑连续性，倒角、孔、螺纹在STL里都是离散的三角面片，你没法在CAD软件里对STL模型做一个干净的局部修改。哪怕是做3D打印，我建议也先从STEP导出STL，而不是直接把text-to-cad的网格结果拿去切片——前者至少有正确的单位和封闭实体，后者经常出现破面。
另外要关注单位。CAD行业老生常谈的问题，在text-to-cad这里被放大了：系统默认毫米，你说“一个3寸的法兰”，它可能真给你生成3mm。所以每次生成后，我做的第一件事永远是核对全局单位。
3. 实操：用text-to-cad生成一个可继续编辑的法兰盘零件
3.1 工具选型：API优先，还是本地开源栈优先
先说工具。目前能直接上手用的text-to-cad工具不算多，我实测下来靠谱的有三类。
一是Zoo的text-to-cad API。它快速、输出质量稳定，直接给STEP文件，和传统CAD工具的兼容性最好。适合验证想法、快速出概念模型。缺点是免费额度有限，自动生成的模型在复杂装配上还是会犯迷糊。
二是开源模型或大模型API加CadQuery的组合。做法是让GPT-4这类大模型理解你的描述，直接让它写CadQuery代码或者你自己写，然后本地执行。这条路完全可控，不依赖第三方生成服务，代码还能沉淀成公司内部的标准化库。缺点是CadQuery有学习成本，团队里得有一个人会写。
三是直接用ChatGPT等聊天工具配合它内置的代码解释器，把生成的CadQuery或OpenSCAD脚本在云端跑，导出STEP再下载。这种适合个人临时用，但在生产环境里不推荐——你很难保证每次生成的是同一个代码执行环境，库版本一变，模型就重建不出来。
我个人目前在用的组合是Zoo API做初步探索 + 本地CadQuery做正式模型。前者看方向，后者做落地，效率最高。
3.2 Prompt设计：一份能稳定出图的描述模板
prompt是text-to-cad里成本最低、提升最明显的环节。下面这套模板是我反复调出来的，直接抄就能用：
描述对象：法兰盘，用于连接DN25管道 整体外形：外径80mm，厚度10mm的圆柱体 中心特征：中轴线上有一个直径30mm的通孔，贯穿整个厚度 阵列特征：以中心轴为基准，在直径60mm的螺栓圆上，均匀分布4个直径6mm的通孔 倒角处理：外圆两个端面的锐边倒角C1 单位：毫米 坐标系：底面位于XY平面，中心轴沿Z轴几个关键点解释一下：
- 一定要交代单位。前面吃过亏，吃了好几次。
- 一定要交代坐标系或者说底面位置。不然生成结果的朝向完全看模型心情，导入到装配体里还得来回旋转。
- 特征与特征之间用“以什么为基准”来串联，这能引导系统建立正确的约束关系。
- 说清楚是“通孔”还是“盲孔”，是“倒角”还是“圆角”，工程术语宁可多写也不要留白。
如果你用代码生成路线，可以把这段描述直接作为注释贴在CadQuery代码头部，这样后面维护的人能看到原始需求，代码和需求能对应上。
3.3 生成、检查与导入CAD验证的完整流程
下面是我实测过的完整流程，以Zoo API加FreeCAD为例。
第一步，把上面的prompt发给text-to-cad服务，返回一个STEP文件下载链接。这个过程通常需要十几秒到一分钟。第一次生成的结果通常是这样的：外径、厚度、中心孔、四个螺栓孔都在，倒角也在，但有一个典型问题——生成结果的边缘锐度跟预期有偏差，C1倒角变成了C0.5。
第二步，把STEP文件导入FreeCAD。导入后打开Part工作台，检查实体的体积、面积、几何类型。这里一定要看属性里的“Solid”类型是不是“Solid”，不是的话说明是壳体或面片，后面没法直接做布尔运算。
第三步，用测量工具核对关键尺寸。我会逐个检查：外径80、厚度10、中心孔直径30、螺栓圆直径60、螺栓孔直径6。这一步通常能抓到80%的问题。
第四步，如果尺寸没问题，再做一次几何检查。FreeCAD里的Part > Check Geometry功能，检查有没有破损的面、非流形边。做过一次检查，有两次结果是因为螺栓孔做成了非贯通而报错，重新生成时在prompt里强调“贯穿”两个字就解决了。
第五步，确认没问题后，把模型另存为一个本地模板，再手动补上工程图需要的公差标注和表面粗糙度。text-to-cad目前不可能替你做完这些，但至少比从零画省了一个大块时间。
3.4 另一种落地路径：让大模型直接写CadQuery代码
如果你想完全自己掌控生成过程，强烈建议学一下CadQuery的代码生成路径。下面是我写过的真实示例，基于上面的法兰盘需求：
import cadquery as cq flange = ( cq.Workplane("XY") .circle(40) # 外圆直径80 .extrude(10) # 厚度10 .faces(">Z") # 选顶面 .workplane() .hole(30) # 中心通孔直径30 .faces(">Z") .workplane() .pushPoint([(30, 0)]) # 螺栓圆半径30 .pushPoint([(0, 30)]) .pushPoint([(-30, 0)]) .pushPoint([(0, -30)]) .hole(6) # 4个直径6的安装孔 ) # 倒角：外圆两端端面锐边 flange = flange.edges("|Z").chamfer(1) show_object(flange)这段代码生成的是一个完整实体，单位默认毫米。输出STEP只需要一行：
cq.exporters.export(flange, "flange.step")相比直接调用生成API，这个路径的好处是：你完全清楚每个特征是怎么来的，改一个数字就能得到变体，团队里甚至可以做成一个“按参数生成标准件”的内部工具。缺点是写代码需要一些积累，但CadQuery的学习曲线比传统CAD二次开发要平缓得多。
3.5 从概念模型到可制造零件：边界条件与工程可行性
最后一个环节，也是很多人会忽略的：text-to-cad给出的模型只解决了“长得像”的问题，还远没解决“能不能造出来”的问题。
法兰盘这种简单零件还好，一旦涉及壁厚、脱模斜度、最小圆角半径、加工余量，问题就出来了。我试过一个带矩形槽的壳体类零件，text-to-cad生成的内腔圆角半径是R0.2，而实际车间铣刀最小半径是R1.0。如果直接拿这个模型去报价或编程，做出来的零件跟设计完全对不上。
所以我的习惯是：text-to-cad的模型只用于方案评审和结构可行性讨论，进入详细设计和工艺评审之前，必须用传统CAD重新做一次完整的特征建模。有一些工具链比较完整的团队，会把text-to-cad生成的模型直接接入DFM（可制造性设计）检查脚本，自动检测最小壁厚、孔径比、倒角合理性，这个方向非常值得做，能省掉大量人工校对时间。
4. 常见问题与排查技巧实录：我踩过的坑，你大概率也会踩
4.1 描述语义歧义导致的结果跑偏
最常见的坑，没有之一。同一个描述，不同措辞可能得到完全不同的结果。
我做过一个测试，分别写“底部开一个矩形槽”和“底面铣削一个矩形槽通道”，前者生成的是一个小凹坑，后者生成的是贯穿侧面的通槽。区别就在于“铣削”暗示了刀具沿路径运动，而“开槽”更偏向一个盲槽的语义。
排查思路很简单：如果结果形状和预期差异很大，先不要怀疑模型能力，先回头检查prompt里有没有歧义词。把“槽”明确成“通槽”或“盲槽”，把“孔”明确成“通孔”或“盲孔”，把“倒角”明确成“C角”或“R角”。工程图纸里怎么写，prompt就怎么写，准确率能提升一个档次。
4.2 尺寸单位与坐标系混乱
这个问题我至少遇到五次以上。单位问题前面说过了，这里说坐标系。
有次生成一个L形支架，描述里写了“底面在XY平面，两臂分别沿X和Y方向延伸”，结果系统生成的是把底面放在YZ平面、一臂伸向负X方向。原因是训练数据里“L形支架”常见的摆放方向和我的习惯不一样。这种事无关对错，但放到装配体里就是天差地别。
排查方法：导入CAD后先看包围盒的方向，再用“对齐视图”观察主轴方向。如果方向不对，不建议在CAD里手动旋转去将就——因为旋转操作会破坏特征坐标的一致性。正确做法是在prompt里明确写出坐标轴方向，重新生成。
4.3 特征缺漏与几何错误排查
text-to-cad生成的模型偶尔会出现特征缺漏。比如四个螺栓孔只生成了三个，或者倒角只倒了半边。
这种问题分两种：一种是语义层面漏了，解决方法是把特征数量写明确，不要写“四个孔”而是写“均匀分布4个直径6mm的孔”。另一种是几何构建失败，常见原因是生成引擎在构建特定拓扑时出故障，把某个特征静默丢弃了。
处理思路是先区分是哪一种。看输出日志或返回的代码，如果是代码生成路线，直接检查代码里有没有对应的特征创建语句。没有，就是语义漏了；有但模型里没有，就是几何失败，让系统重新生成一次通常能解决。我实测下来，同样的prompt让Zoo API重新生成三到五次，生成失败的概率会明显下降，这大概是因为每次生成都是独立采样。
4.4 避坑心得：迭代策略比精确首猜更实用
用了一段时间后，我最大的体会是：不要指望一次生成就完美，text-to-cad的工作模式应该是“快速迭代逼近”。
我的标准流程是：第一版用宽泛描述跑出大致形状，第二版根据结果细化尺寸和特征，第三版加入倒角、公差、孔位细节。每一步都只改一到两个变量，这样出了问题很容易定位。千万不要一开始就写一个事无巨细的prompt，想着一步到位——描述越长，模型越容易在某个点上理解偏差，而且你很难判断到底是哪里带偏了。
举个例子，我做一个带安装座的传感器外壳，第一版只描述“方形外壳+两侧安装耳”，第二版加上“外壳壁厚2mm、安装耳上有直径4mm通孔”，第三版才加上“底面四个支脚高度3mm”。每版生成时间通常不到一分钟，三轮下来也就三五分钟，比在CAD里从头画还是快不少。
另外有个小建议：把每一次成功生成的prompt记录下来，自己维护一个prompt库。不同零件类型、不同特征组合的成功描述，都存成模板。这比依赖任何工具的“智能”都可靠——因为它们是你在自己行业、自己的零件族里验证过的。
我个人在实际操作中的体会是，text-to-cad目前更像一个“理解力不错但经验不足的实习生”：你给它足够清楚的指令、足够的上下文，它能交出不错的草稿；但你不能指望它直接交出能上机床的正式图。成熟工程师拿它做方案前期的发散和沟通，效率提升非常明显；新手拿它学建模思路，能快速看到“描述语言如何变为几何操作”的对应关系，其实也是一种不错的入门方式。
最后再分享一个实用小技巧：如果你生成的STEP模型在导入CAD后发现某个孔的位置不对，别急着删掉整个模型重新生成。很多text-to-cad工具支持“基于现有模型追加描述”的对话式修正，比如直接追加一句“把左上角那个孔的直径从6改为8”。这种方式比重新描述整个零件有效得多，因为它保留了前面已经正确的特征，只修改你指定的部分。用顺了这个功能，你会觉得手里那个“实习生”突然变得好沟通了。
