前阵子朋友扔给我一句话：“给我生成一个带四个沉头孔的法兰盘”，我打开电脑，对着终端敲了一行命令，还真就输出了一份可以直接拿去加工中心出活的STEP文件。这就是text-to-cad最朴素也最让我兴奋的场景：把“脑子里的想法”直接翻译成“机器能读懂的模型”。这个方向最近在机械设计、3D打印、机器人抓取这些圈子热度很高，我也花了几周时间把能跑的开源方案、能踩的坑都过了一遍，今天这篇就把从原理到实操的完整链路拆开讲清楚。
如果你是一个机械工程师、独立产品设计师，或者哪怕只是业余玩3D打印的爱好者，只要你受够了“对着软件画草图—拉伸—打孔”这种繁琐步骤，这篇内容都值得看完。当然，我也不打算把它吹成“AI取代建模师”的玄学，text-to-cad现在能做的、不能做的，我分别在后面用真实案例说明。
1. 需求本质：建模入口从“动手画”变成“开口说”
1.1 传统CAD建模的痛点在哪
传统CAD建模流程，本质上是一个“翻译+执行”的过程：你脑子里有一个法兰盘，先用草图把它投影成二维轮廓，再通过拉伸、旋转、打孔、倒角这些特征一步步堆叠出三维实体。这个过程的瓶颈从来不是“思路”，而是“操作”：一个简单的圆盘加四个孔，在SolidWorks里最快也要两到三分钟，新手可能还要翻菜单找“圆周阵列”藏在哪个选项卡下面。
text-to-cad想解决的就是这个翻译环节。它把“自然语言描述”直接映射成“建模操作序列”，省掉人和软件之间的图形界面沟通成本。在批量生成相似零件、快速做概念验证、以及给非CAD专业人士提供建模能力的场景里，这个优势非常明显。但要注意，它不是替代整个建模流程，而是把“建模指令”这部分自动化了，后面的工程分析、配合干涉检查、出工程图，仍然需要你动手确认。
1.2 为什么是现在这个时间点爆发
text-to-cad并不是今天才有的概念。早年间有些论文尝试用模板匹配或者传统NLP把文字转成建模宏，效果一言难尽，因为自然语言的歧义性和建模参数的结构化之间隔着一条巨大的鸿沟。真正的转折点是大语言模型（LLM）把“语义理解”和“代码生成”这两件事同时做到了可用的水平，而现代CAD系统本身又越来越依赖脚本化、参数化接口，比如CadQuery、OpenSCAD、Cascade Studio，恰好给LLM提供了一个结构化输出目标。
换句话说，LLM擅长把模糊需求整理成结构清晰的指令，脚本化CAD系统擅长把指令变成精确几何，两者合在一起，text-to-cad就成了一个工程上可行的产品。我自己的体会是：这个时间点入场，你不需要理解Transformer的数学细节，只要能写好提示词、会跑通一条完整的命令链路，就已经能比大多数人先吃到红利。
2. 技术路线：底层其实是一个“映射问题”
2.1 路线一：自然语言直接转参数化脚本
目前工程上最成熟、也是我个人最推荐的路线，是让LLM输出一段可执行的CAD脚本。只要脚本语法正确、运行环境完整，CAD内核就会自动构建出实体模型，并导出STEP、STL等通用格式。这有点像让AI写网页：LLM不直接生成像素，而是生成HTML/CSS，浏览器负责渲染。在这里，脚本就是HTML，CAD内核就是浏览器。
以CadQuery为例，它的建模方式非常符合机械直觉：先用Workplane建立基准面，然后.circle()、.extrude()定义实体，再用.faces()、.hole()添加特征。LLM经过训练后，能比较稳定地把“直径60毫米的圆盘，厚度10毫米，中心通孔直径12毫米”翻译成对应的代码。我实测下来，只要提示词里把尺寸和特征说清楚，生成的第一版脚本改写两次以内就能通过语法检查并导出几何体。
这条路线最大的优势是“可编辑”。生成的脚本保留了完整的参数关系，你可以回头改一个数字重新生成整个模型。对于需要频繁调整尺寸的零件，这种参数化特性比直接生成网格模型实用太多。要手动修改时，打开脚本改个数值就行，整个工作流是透明、可控的。
2.2 路线二：直接输出B-Rep表示或者构造历史
另一条更“硬核”的路线是让模型直接生成B-Rep（边界表示）几何或完整的CAD构造历史。比如DeepCAD那批工作，训练模型输出的是“草图类型+拉伸深度+旋转角度”这种结构化的序列数据，最后再交给几何内核重建出实体。这种方式的优势是生成的模型天然符合CAD数据的规范，不需要经过脚本解析这一层折中，缺点是数据获取难、训练成本高，而且一旦生成结果是错的，你很难像改脚本一样直接改一行参数。
Text2CAD这类工作也是类似的逻辑：构建大规模的自然语言-建模指令配对数据集，训练模型从一句话直接生成对应的CAD操作序列。这条路线更接近学术界对“AI辅助设计”的理想定义，但离“拿来当生产力工具”还有距离。目前开源社区里能直接跑的模型，绝大多数还是走脚本生成路线，因为它可以借用LLM已有的代码生成能力，不用从零训练一个几何专用模型。
2.3 当前工程落地的选择逻辑
如果你是个人用户或者小团队，想快速在项目里用上text-to-cad，我建议不要一上来就折腾论文复现，而是先选一条已经跑通的脚本生成链路。用现成LLM API写CadQuery脚本，或者在本地部署一个开源模型跑Cascade Studio脚本，都能在一天内看到效果。等你确认这个方向能解决实际问题，再考虑要不要收集数据、微调一个专属模型。
我自己试过几个方案之后，总结出一个判断标准：看它能不能导出STEP，而不是截图或者网格。STEP是机械设计领域的通用交换格式，带精确曲面信息，能进CAM软件做刀路，也能进仿真软件做有限元分析。如果哪个text-to-cad工具只能导出STL网格，那它在机械加工场景里基本只能当玩具，因为网格模型无法直接作为加工依据，还需要重新曲面化，这一步的精度损失和人工成本都不小。
3. 能跑起来的工具与数据基础
3.1 开源工具速览
这个方向在GitHub上已经有不少能直接跑的项目，我挑几个实际体验过的列出来，可以按自己的硬件条件选择：
| 工具/项目 | 输出形式 | 运行门槛 | 适合场景 |
|---|---|---|---|
| CadQuery + LLM API | Python脚本 / STEP | 只需要Python环境 | 个人批量建模、参数化设计 |
| Zoo（Text-to-CAD开源模型） | Cascade Studio脚本 / STEP | 需要Docker和较大显存 | 想完全本地化、离线生成 |
| OpenSCAD + LLM | OpenSCAD脚本 / STL | 极低，网页IDE即可 | 快速生成3D打印模型 |
| FreeCAD宏生成 | Python宏 / STEP | 中等 | 需要进入FreeCAD继续编辑 |
Zoo是近期热度比较高的一个开源项目，用7B参数模型微调，输入一句话，输出的是Cascade Studio脚本，再经过Cascade内核导出STEP。它官方推荐用Docker跑，模型比较大，我实测在8GB显存的卡上可以推理，但速度偏慢，一个中等复杂度的零件大概要等一两分钟。如果你不想折腾本地环境，其实用LLM API生成CadQuery脚本是性价比最高的方案，成本低、迭代快，而且CadQuery本身就能直接导出STEP。
3.2 数据从哪来：Text2CAD与DeepCAD
text-to-cad的模型能力很大程度上取决于训练数据。目前公开的比较有代表性的数据集是Text2CAD和DeepCAD。DeepCAD提供了几万个带建模指令序列的CAD模型，每个模型都记录了一步步的草图、拉伸、旋转等操作；Text2CAD则在这个基础上做了自然语言描述与建模序列的配对，大概有接近20万条指令级数据，让模型学习“一句话到一系列操作”的映射。
这些数据集的价值不仅在于训练模型，普通人也能拿来当“题库”用：你可以随机抽几条人工标注的数据，看看模型是怎么把一段话分解成建模步骤的，这比直接读论文更容易理解text-to-cad的行为方式。我自己看了一百多条数据之后，最大的收获是：所有好用的提示词都有一个共性——先描述整体形态，再描述每个特征，最后明确尺寸和位置关系。这不是AI教育我，而是数据集的标注方式本来就是这个逻辑。
3.3 提示词在pipeline里的真实地位
很多人以为text-to-cad只要装了模型就万事大吉，实际用下来发现，提示词写得好不好，直接决定结果能不能用。一个模糊的“做一个支架”，模型可能给你生成一个随机的L形实体；一个清晰的“做一个L形支架，底板尺寸100x80x5，立板高60厚度5，底板边角倒R5圆角，底板上开两个直径8的安装孔”，生成的模型基本就能直接进装配了。
这背后的原因是：LLM本质上是在做模式匹配，你给的信息越接近训练数据中标注的结构，它匹配到的建模方案就越可靠。不要把提示词想成“跟AI聊天”，要把它想成“给一个执行力强但理解力有限的实习生写需求单”。尺寸、位置、数量、倒角半径，这些硬参数一个都不能少，最好是按“整体→特征→参数”的顺序组织成一段话，模型输出的稳定性会明显提升。
4. 本地实操记录：从一句话到STEP文件
4.1 环境准备：我用的轻量方案
为了降低门槛，我用的是最轻的方案：Python环境 + CadQuery库 + LLM API，整个过程不需要本地显卡，一台普通办公笔记本就能跑。CadQuery的安装很简单，在终端执行pip install cadquery就能装上，它会自动带OCCT几何内核，负责把脚本变成真正的实体模型。
如果你之前没用过CadQuery，建议先跑一个最简示例验证环境：
import cadquery as cq result = ( cq.Workplane("XY") .circle(10) .extrude(5) ) cq.exporters.export(result, "demo.step")这段代码生成一个直径20mm、高5mm的圆柱体，并导出STEP文件。如果这一步成功，说明几何内核和导出链路都没问题，后面就可以放心交给LLM生成更复杂的脚本了。我自己第一次跑的时候，卡在“找不到OCCT依赖”上，后来发现是Python版本太新，换个旧一点的虚拟环境就解决了。这种环境问题很像木工活里的“工具没调好”，不影响你最终的技术路线判断，但会消耗不少耐心，提前备好一个干净的Python 3.10环境比较省事。
4.2 写提示词的通用模板
我试过几次之后，沉淀了一套自己能稳定复用的提示词模板：
请生成一个CadQuery脚本，构建以下零件： 1. 整体描述：{这里是总体形状，比如“一个圆形法兰盘”} 2. 特征列表： - {特征1，比如“底部圆柱体，直径60mm，高度10mm”} - {特征2，比如“中心通孔，直径12mm，贯穿”} - {特征3，比如“四个安装孔，直径6mm，均匀分布在直径44mm的圆上”} 3. 所有尺寸单位均为毫米。 4. 只输出完整可运行的Python代码，不要加解释。注意，最后一句“只输出代码，不要加解释”非常重要。LLM默认倾向于在代码前后加一段说明文字，如果混在完整脚本里，复制到Python运行时就会语法报错。使用规则里明确要求输出纯代码块，能让解析过程省掉很多麻烦。还有一个细节：明确写“所有尺寸单位均为毫米”，因为CadQuery默认虽然用毫米，但很多训练数据里混杂了英寸标注，模型偶尔会把数字理解岔了，写清楚能显著降低尺寸跑偏的概率。
4.3 案例：用text-to-cad生成一个法兰盘
我拿前面提过的法兰盘做一次完整演示。假设需求是：外径60mm、厚度10mm的圆形法兰盘，中心一个直径12mm的通孔，另外四个直径6mm的螺栓孔，均布在直径44mm的节圆上。按照上面的模板，我把描述交给LLM，它返回了下面这段CadQuery脚本：
import cadquery as cq result = ( cq.Workplane("XY") .circle(30) # 外圆半径30mm .extrude(10) # 拉伸10mm .faces(">Z") # 选择顶面 .workplane() .hole(12) # 中心通孔直径12mm .workplane(offset=0) .pushPoints([(22, 0), (-22, 0), (0, 22), (0, -22)]) .hole(6) # 四个螺栓孔直径6mm ) cq.exporters.export(result, "flange.step")这段代码的逻辑很清晰：先在XY平面画圆拉伸成圆柱，再选中顶面，打中心孔，然后在顶面工作平面的四个坐标点上打螺栓孔。pushPoints接收四个位于半径22mm的坐标点，正好满足“四孔均布在直径44mm节圆上”的要求。我把这段代码保存成make_flange.py，在终端执行python make_flange.py，几秒钟后目录下就多了一个flange.step文件。
这里有一个从我自己的角度来说比较重要的验证步骤：不要直接把这个STEP丢给加工厂，先用一个能看模型的工具检查。我习惯用FreeCAD或者在线查看器打开STEP，确认孔的数量、位置、直径和需求一致。曾经有一次LLM输出的螺栓孔坐标没有落在节圆上，而是落在圆柱体内部，视觉上看起来孔是“藏”在实体里的，如果直接出STEP，后续加工必废。问题就出在坐标计算上，它把直径44mm算成了半径44mm，用了一点三角知识检查坐标值后才发现不对。
4.4 从脚本到实际模型：导出与验证
导出格式上，我强烈建议优先选STEP而不是STL，原因前面说过：STEP保留精确几何信息，后续做CAM、仿真、装配都不需要重新建模。CadQuery里导出STEP只需要一行：
cq.exporters.export(result, "flange.step")如果只是给3D打印机用，STL也够，但要注意STL是三角网格，精度取决于导出参数，放得很大之后会出现棱角。CadQuery导出STL时可以通过exportOptions控制弦高误差，我不太建议在这里省时间，打印模型出现“台阶感”通常就是网格太粗。要做尺寸验证，可以从导出的STEP文件里用代码读取实体属性，也可以直接用FreeCAD的测量工具点两个面看距离，后者更直观。
5. 常见故障与排查技巧实录
5.1 高频问题速查表
在我折腾text-to-cad的过程里，遇到的大部分故障其实不是模型“笨”，而是链路里某个环节没对齐。整理一个速查表，供你遇到问题时直接对照：
| 现象 | 常见原因 | 处理方法 |
|---|---|---|
| 脚本运行报错：NameError | LLM用了CadQuery不存在的API | 在提示词里指定“只用circle/hole/extrude/faces/workplane等标准方法” |
| 导出的STEP打不开 | 布尔运算失败，生成了非流形实体 | 简化特征，减少环面交叉，分步生成再合并 |
| 孔的位置偏了 | 坐标计算把直径当成半径 | 手动验证pushPoints的坐标与节圆半径是否匹配 |
| 尺寸单位不对 | 模型把英寸当成毫米 | 提示词里加一句“所有尺寸单位是毫米” |
| 输出内容夹杂解释文字 | 提示词约束不严格 | 要求“只输出代码块，前后不要任何文字” |
| 模型卡住不动 | 生成脚本太长，上下文超限 | 拆分成多个特征分步生成，再组装 |
| 生成结果与自己预期完全不符 | 描述缺少特征级拆解 | 按“整体→特征→参数”结构重写提示词 |
5.2 三个特别容易忽略的细节
第一个细节是布尔运算的顺序。CadQuery的hole打孔，本质上是在已有实体上做减法布尔运算，如果两个孔的深度方向、起始面选择不对，很容易出现“怪形状”：比如中心孔明明是通孔，结果底部多了一层薄壁。这是因为hole的贯穿深度默认是穿破当前实体的，但如果你在错误的工作平面上打孔，它会往实体外侧而不是内部钻。我个人习惯是在打孔之后，额外检查一下模型的Volume数值是否合理，比用眼睛看更准。
第二个细节是阵列的生成方式。要实现四孔均布，我看到不少AI会生成四个单独的hole()调用，坐标手工写死，比如(22,0)、(0,22)、(-22,0)、(0,-22)。这种写法没问题，但如果要改成六孔，就得改多处代码。更好的方案是让LLM用polarArray或者循环生成均布点，不过目前模型对这两个方法的输出稳定性不如手写坐标。务实起见，我先接受手写坐标，等模型能力再强一点，再要求参数化阵列。
第三个细节是倒角与圆角的顺序。很多零件需要fillet，但倒角放在打孔之前和打孔之后，效果完全不同。LLM经常给出一个先打孔后倒角的脚本，结果孔的边缘也被倒角了，这在某些装配场景里不符合要求。如果模型错了，不要让它重写整个脚本，而是直接告诉它“把fillet移到打孔之前”，局部修正的准确率比重写高很多。这也是脚本生成路线比黑盒生成路线更优势的地方：你能介入生成过程，精准定位错误。
5.3 一个“看起来对，实际很糟”的典型案例
有一次我让它生成“一个带U型槽的安装底板”，模型输出的脚本语法完全正确，STEP也能打开，表面上看起来就是一块长方板在中间开了一个U型槽。但我放进FreeCAD做剖面检查时发现，槽的底部没有圆角过渡，而是直角边，如果这是要加工成形的零件，铣刀根本没法定刀，因为直角内角对加工特别不友好。模型并没有错，是我需求描述里漏了“槽底部需要铣削圆角，半径至少3mm”这个关键加工约束。
这个案例让我意识到：text-to-cad能理解设计意图，但它不懂加工工艺。你在提示词里不写的约束，它默认不存在。所以在设计提示词时，除了尺寸和特征，还得把与制造相关的工艺要求显式列出，比如“所有内角倒圆角R3”“避免封闭凹槽”“板厚不小于2mm以适应激光切割”。这一步能帮你挡掉一大批不合格的生成结果，省得后面反复修。
6. 实际业务场景里的落地建议
6.1 3D打印快速原型工作流
在我自己玩3D打印的工作流里，text-to-cad目前已经能真正帮上忙，主要用在“快速出原型”这个环节。以前我想到一个零件要花20分钟用建模软件“画”出来，现在只需要把需求说清楚，让LLM生成CadQuery脚本，再导出STL直接切片打印。一个简单的带卡扣的电池盒，从想到拿到实物，压缩到了半小时以内，而且因为脚本保留着参数，改个尺寸重新生成只花几十秒。
这种方式尤其适合做“探索性设计”：不确定某个结构好不好用，那就快速生成三五个变体，每个改一个参数，打出来实际装配感受一下。用传统方式做同样的事情，时间成本会高到让你放弃尝试。但也要明确一点，text-to-cad生成的模型目前主要面向“形状正确”，对打印方向、支撑结构、壁厚均匀性这些工艺优化并不敏感，这类调整仍然需要你在切片软件里完成，或者在提示词里就把壁厚、公差这些参数写清楚。
6.2 机械装配与参数化备件
另一个我觉得很有潜力的场景是备件管理。工厂里有大量设备，备件图纸往往不全，或者老设备根本没有三维模型。现在可以用一段自然语言描述生成一个初版模型，比如“一个直径40mm、厚度15mm、带6个M6螺纹孔的法兰”，然后导入装配体里试装，不对的地方再回改脚本。整个迭代过程的效率，比从零开始测绘建模高不少。
在参数化方面，脚本路线有一个天然优势：如果你的零件有系列化需求——同一个法兰有50mm、80mm、120mm三个规格，用text-to-cad生成一次基本脚本，之后只需要修改脚本里的直径变量，就能批量输出多个规格的STEP文件。这一点对设备改造、工装设计、非标自动化场景特别实用。不过要提醒一句，装配环境下的配合公差（比如孔距精度、圆柱配合间隙）不能靠AI凭空生成，那些必须按工程手册或实际测量来定，AI只是帮你省掉了“建模”这个动作。
6.3 数据集与模型微调的下一步
如果你背后有团队，想从“用别人的模型”走向“训练自己的模型”，目前比较现实的路径是先采集企业内部的零件库和设计规范，整理成“指令-脚本”配对数据，然后在开源模型基础上做指令微调。现阶段公开的Text2CAD数据覆盖的是通用机械零件，对特定行业（比如航空钣金、注塑模具、建筑构件）的效果可能不够好，垂直微调的空间很大。
我个人的看法是，text-to-cad并不会让CAD工程师失业，它更像是给CAD配了一支“手写笔”：以前键盘鼠标操作繁多，现在多了一种直接输入想法的通道。最终工作流大概率是“AI生成初稿，工程师修改参数和工艺约束，再进入正式评审流程”，人的角色从“一笔一笔画”变成了“审稿和决策”。这个转移不降低设计质量，但会明显压缩重复劳动时间。
6.4 个人经验：从哪一步开始上手最稳妥
如果你看完这篇内容想自己动手试，我的建议是别先急着部署本地大模型。先从最简单的链条开始：申请一个你常用的有代码能力的LLM API，装好Python和CadQuery，然后用一篇工程师需求文档里最基础的小零件作测试，比如垫片、支架或者安装板。第一次跑通之后，你会对这整个流程建立直觉，知道模型在哪些环节容易出错，也就能更有针对性地写提示词。
等这套轻量链路用顺了，再决定要不要上重型开源模型。千万别跳过中间的验证步骤：每一次生成后都要在FreeCAD里打开、测量尺寸、检查特征；否则漏掉一个孔的偏心错误，后面整个装配方案都会跟着歪掉。我踩过最大的坑就是太相信模型第一版输出，直到最后一刻才发现螺栓孔不在节圆上——那一次之后，我给自己立了一条规矩：text-to-cad生成的任何模型，未经测量验证一律不进入下游环节。
说到底，text-to-cad真正改变的不是“你会不会建模”，而是“你从想法到实体之间的距离有多短”。工具还在快速迭代，但“描述清楚需求、验证生成结果、把工艺约束写进提示词”这三个习惯，放之任何版本的模型都管用。先从最简单的圆柱开始，给自己生成一个零件，那种“一句话变成实物”的感觉，是真的会上瘾。
