做 CAD 这个行当的人，这两年应该都感受到了一股奇怪的压力：AI 都能写代码、画图、生成视频了，怎么打开 SolidWorks 还是得自己一个特征一个特征地拉？直到 text-to-cad 这个概念密集出现，才让人意识到，不是这方向没人做，是过去大家把路走岔了——大部分"文本生成 3D 模型"的工具，生成的其实是 mesh（网格），而 CAD 要的是参数化特征树。这两者之间的鸿沟，恰好就是 text-to-cad 真正要解决的问题。
我花了两周时间把市面上能试的 text-to-cad 项目、API、开源模型都过了一遍，包括直接用大模型写 CadQuery 脚本这种野路子。这篇文章不打算写成一个综述，而是想从一个实际使用者的角度，把这东西的原理、各家方案的差异、能复现的操作路径，以及最容易被忽视的质量评估方法讲清楚。如果你也是做机械设计、3D 打印、工业建模，或者单纯好奇"一句话生成一个能编辑的零件"到底怎么实现，这篇文章应该能帮你省下不少自己摸索的时间。
1. 先说清楚：Text-to-CAD 和"文字生 3D 模型"根本不是一回事
很多人第一次听到 text-to-cad，第一反应是"这不就是文生 3D 模型吗，Meta 那个、OpenAI 那个不都能做？" 这是一个非常自然的误解，但也是理解整个领域最关键的一道坎。
1.1 为什么 CAD 领域一直没跟上"文生图"的节奏
过去几年，文字生成 3D 内容的技术确实进步飞快，从早期的 CLIP 驱动形状优化，到后来的扩散模型直接生成神经辐射场，再到用多视图扩散重建网格，已经能生成相当精细的雕像、游戏道具、场景资产。但这些东西有一个共同特点：输出是三角形网格，或者隐式曲面，本质上是一堆点、面、法线、纹理坐标的集合。
网格模型对游戏、影视、3D 打印预览来说够用，但对工程师来说远远不够。你在 SolidWorks 里打开一个网格零件，会发现没有特征树、没有草图、没有拉伸切除的记录，想改一个孔的直径，对不起，改不了，只能整个重做。CAD 的核心资产是可编辑性，是参数化逻辑，是那个记录"怎么一步步把这个零件做出来"的特征历史。
text-to-cad 的目标恰恰是后者：生成的不只是一个形状，而是一套完整的建模过程、一颗参数化特征树，甚至是一段可以被 CAD 内核重放的建模指令序列。这也是为什么它比文生 3D 模型难那么多。
1.2 从特征树到 CSG：CAD 模型内部到底长什么样
要理解 text-to-cad 的难点，得先搞清楚 CAD 文件在底层是怎么描述一个零件的。这里有三层概念需要区分。
第一层是特征树（Feature Tree），也就是你在 SolidWorks、Fusion 360 里左侧那个树状列表。它记录的是"先拉伸出底板，再在顶面画草图切除一个孔，再倒角"这样的操作顺序。特征树的每一层都依赖前面的结果，中间任何一个草图尺寸改掉，后面的特征都会自动更新，这就是参数化建模的核心体验。
第二层是B-Rep（边界表示），它是 CAD 内核（Parasolid、ACIS、OpenCASCADE）真正用来存储几何的数据结构。B-Rep 把模型拆成一堆面（Face）、边（Edge）、顶点（Vertex），并记录它们之间的拓扑连接关系，还包含精确的曲面方程而非网格近似。B-Rep 保证了模型在数学上是精确的，但这个数据结构极其复杂，直接让语言模型去生成 B-Rep 几乎是不可能的。
第三层是CSG（构造实体几何），就是用基本体（立方体、圆柱、球）做布尔运算（并、交、差）来拼出复杂形状。CSG 很简单，适合做 AI 生成的中间表示，比如很多早期研究就是让模型直接预测 CSG 树。但 CSG 的问题也很明显：它表达不了一个带有复杂草图和拉伸特征的工业零件，而且最终还要再把 CSG 转回 B-Rep 才有实际意义。
这些概念不是考试重点，但它们决定了 text-to-cad 各家技术路线的走向。简单说：如果你想生成"看起来像零件"的东西，mesh 就够；如果你想生成"真正能用的零件"，就必须触及特征树、草图、拉伸、旋转、布尔运算这一整套东西。text-to-cad 这个名字本身，就已经表明它选了一条更难的路。
2. 核心原理拆解：把"建模过程"变成语言模型的下一句
AI 生成 CAD 模型的难点，本质上是一个表示问题：到底让模型预测什么，它才能输出可编辑、可制造的参数化模型？目前主流的技术路线，基本可以归纳成三类：序列生成、图生成、外加一套辅助的脚本/Agent 路线。
2.1 让模型学会"画草图加拉伸"：CAD 序列化的几种做法
最直观的思路，是模仿代码生成。既然代码可以表示成 token 序列让 Transformer 去预测，那么 CAD 建模过程为什么不能？
DeepCAD 是最早公开的开源工作之一，做法是把 SolidWorks 里的建模操作序列（也就是特征树的操作记录）转成一种紧凑的 DSL（领域特定语言）。比如"新建草图、画一个圆心在某个点的圆、拉伸 10 毫米、再切一个孔"这些操作，都被编码成固定格式的 token 序列。训练时，模型读取这些序列，学习的是"从建模语言到建模操作"的映射。推理时，模型直接生成一段建模序列，再用 CAD 内核重放成实体。
我在本地跑过 DeepCAD 的预训练模型，它生成的最简单的零件也就是"一个底板加一根柱子"这个级别的东西，复杂一点的会明显失真，比如出现悬空的面、拉伸方向乱掉、或者干脆生成了零厚度的退化几何。但它证明了一件很重要的事：语言模型完全有能力学会"拉伸""切除""倒角"这些操作的语法，序列化这条路是通的。
另一个代表性工作是 UCSD 的 Text2CAD 系列，他们在序列生成之外还加入了文本编码器分支，让同一个模型既能做文本到 CAD 的生成，也能做 CAD 到文本的描述，也就是模型同时学会了"看懂零件"和"生成零件"两件事。
2.2 合成数据与反向字幕：训练数据的来历
这类模型最大的瓶颈其实是数据。真实世界的 CAD 模型虽然存量巨大，但绝大多数都没有配套的文字描述。你想想，谁会在画完一个法兰盘之后，再写一句"这是一个带四个均布螺栓孔的法兰盘"存在文件里？几乎没有。
所以各家都想到了一个套路：反向字幕（reverse captioning）。先拿一批现成的 CAD 模型，解析成序列化的建模流程，再用一个已经训练好的"CAD 理解"模型（或者规则引擎）自动生成描述文字。这样就能得到海量的"文字-建模序列"配对数据。Zoo（就是 KittyCAD 那家公司）在发布他们的 text-to-cad 时，官方技术博客里明确提到，他们用合成数据和人工标注的结合方式来构建训练集，其中合成数据占了绝大部分。
这个做法听起来很顺理成章，但有个隐患：模型学到的描述和真实工程师的语言习惯有偏差。合成数据里描述的往往非常"教科书"，比如"一个凸台，直径 20 毫米，高 5 毫米，带一个直径 5 毫米的通孔"，而真实用户更可能说"一个用来固定传感器的支架底座"。语料分布的错位，意味着模型对"口语化需求"的泛化能力实际上很有限。
2.3 端到端生成与工具调用的 Agent 路线
序列生成是"一步到位"：文本进去，建模序列出来。还有一种路线是把 LLM 当调度器，让它调用外部工具。典型做法是用 GPT-4 或开源大模型写一段 CadQuery 或 OpenSCAD 脚本，然后执行脚本，从错误信息里迭代修正，直到生成合格模型。
我之所以专门提这条路线，是因为它目前反而是最容易被普通用户复现的。不需要训练数据，不需要 GPU，只需要一个能写代码的 LLM 和一套 CAD 的 Python API。后面我会用一整章讲怎么把它落地。
端到端模型和 Agent 路线的本质区别在于：前者把"建模知识"焊死在模型参数里，后者把"建模知识"外包给外部执行环境，LLM 只负责理解需求、写代码、根据报错改代码。前者上限高、但可控性差；后者每一步都可观察、可干预，工程上非常实用。我个人的判断是，短期内 Agent 路线的产品体验反而会更好，因为用户能眼睁睁看着模型"改稿"，出了问题也知道去哪找原因。
3. 各家的实际表现：Zoo、AutoDesk 和开源社区的真实差异
把原理过了一遍之后，我从实际体验角度说说目前几个代表项目的差距。你可以把这一章当成一份"选型笔记"，以后想在这块投入精力时知道该往哪个方向看。
3.1 Zoo Text-to-CAD：从炫技 Demo 到可用的 API
Zoo 的 text-to-cad 是 2024 年 9 月发布的，当时官方放了一个让我印象深刻的演示：输入一句"一个带有四个安装孔和一个中心孔的铝制安装板"，模型生成了一颗完整的参数化模型，特征树清晰，各个孔的直径、位置都能编辑。它背后用的是自家的 KittyCAD API 和底层的几何内核，所以从模型生成到几何运算都是闭环的。
我实际在 Zoo 的在线 playground 上试过几次。它的生成速度大概在十几秒到一分钟这个量级，生成结果分两种：一种是"标准件风格"的、特征非常规整的零件；另一种是稍微复杂一点的、需要多个特征叠加的零件。整体感觉是，它对机械工程师常用的"板-孔-凸台-倒角"这类特征的掌握已经很稳，但对自由曲面、复杂装配体、钣金件这些还是明显欠火候。
另外，Zoo 的商业化策略也值得关注。他们不仅提供在线生成，还把 text-to-cad 的生成能力封装成了 API，可以直接集成进别的软件。这就意味着，将来你在某个在线 3D 打印服务商、某个夹具设计工具里看到的"用一句话生成模型"按钮，很可能背后就是这种服务。
3.2 AutoDesk 和其他实验室的探索方向
AutoDesk 那边也有一个叫 Project Bernini 的内部项目（名字叫"贝尼尼"，很明显致敬那位雕塑家），它走的是多模态生成路线：不只是文字到 CAD，还能从图片、交互式输入甚至多个视角合成全新模型。AutoDesk 的优势在于他们有完整的 Fusion 360 / Inventor 数据生态和大量用户操作日志，这些东西如果用来做训练数据，上限非常高。目前公开的信息还不算多，但我比较确定的是，AutoDesk 对"可制造性"的要求会比初创公司高很多，因为他们知道真正的用户是拿来开模具、上机床的，不是拿来做个好看的渲染图。
学术界那边也有不少有意思的工作。除了前面提到的 DeepCAD、Text2CAD，还有把强化学习引入 CAD 序列生成的、用图神经网络做草图-拉伸特征预测的、以及专门研究"语言描述不够精确导致几何歧义"这个问题的。这部分工作虽然离产品很远，但它们在给整个领域探路。
3.3 开源社区的务实派：LLM 直接写脚本
最后是开源社区，这里目前最大的价值不是某个成品模型，而是"LLM + CadQuery/OpenSCAD"这条极其实用的路线。CadQuery 是一个用 Python 写参数化 CAD 的库，它天然适合做 LLM 的输出目标，因为脚本本身就是程序代码，可读、可调试、可版本管理。
我用这条路线跑了不少测试，结论是：GPT-4 级别的模型在写 CadQuery 时，对简单零件的成功率相当高，但对稍微复杂的装配、或者需要精确控制某些几何约束的情况，还是会出现"看起来合理、一执行就报错"的情况。不过好在报错信息是公开的，把报错喂回给模型让它自己改，两三轮之内通常能修好。这种"生成-执行-报错-再生成"的循环，本质上已经把大模型的推理能力和 CAD 内核的精确性结合起来了。
4. 现在就能上手的实践：让 LLM 帮你生成可编辑的参数化零件
前面讲了不少概念和现状，但读者的时间很宝贵，我直接进入可以复现的部分。
4.1 环境准备：为什么我选 CadQuery 而不是 OpenSCAD
第一步是选工具。OpenSCAD 也是脚本化建模，语法更简单，但它的建模方式偏向 CSG，不太适合表达"先画草图、再拉伸、再打孔"这种工业建模流程。CadQuery 更贴近主流 CAD 软件的操作习惯，生成的结果也能通过 FreeCAD 或自己转成 STEP 文件，生态更友好。
安装很简单：
pip install cadquery如果你需要更复杂的交互界面，可以考虑安装 CQ-editor，它是一个带 3D 预览的编辑器。另外，建议同时安装 FreeCAD，因为 CadQuery 的底层依赖 OpenCASCADE，而 FreeCAD 也是基于这个内核，两边的文件可以互通。
4.2 从自然语言到零件：两个完整的实战样例
我挑了两种典型场景，演示一下"让 LLM 把一句话变成 CadQuery 脚本"的全过程。
样例一：语音指令式的描述——"帮我做一个底板，长 80，宽 50，高 10，四角各有一个直径 6 的沉头孔。"
把这句话直接喂给 LLM，它通常会生成类似下面的脚本：
import cadquery as cq result = ( cq.Workplane("XY") .box(80, 50, 10) .faces(">Z") .workplane() .rect(80, 50, forConstruction=True) .vertices() .hole(6.0) ) cq.exporters.export(result, "plate.step")这个脚本你八成看不懂，但没关系，执行它就会得到一个 80×50×10 的底板，四角打了通孔。我实际执行后确认模型正确。
样例二：工程描述式的指令——"生成一个法兰：外径 100，内径 40，厚度 15，六个直径为 8 的螺栓孔均匀分布在直径为 75 的螺栓圆上。"
这句话的关键在"均匀分布在螺栓圆上"，LLM 需要理解极坐标和阵列的概念。我让模型生成之后，它给出的脚本核心部分大概这样：
result = ( cq.Workplane("XY") .circle(100 / 2) .extrude(15) .faces(">Z") .workplane() .circle(40 / 2) .cutBlind(-15) ) # 螺栓孔阵列 result = ( result.faces(">Z") .workplane() .polarArray(75 / 2, 0, 360, 6) .circle(8 / 2, forConstruction=False) .cutBlind(-15) )我把这个脚本放进 CQ-editor 执行，得到的是一个干净的法兰，六个螺栓孔按 60 度均匀分布，内孔贯通。这里的关键是"polarArray"这个 API，LLM 能准确调用它，说明它对 CadQuery 的常用方法已经很熟。
不过我也遇到过翻车的情况，比如同样一句话，换个模型（或者换个改写方式）它可能会生成 OpenSCAD 语法，或者把"沉头孔"理解成"埋头孔"、"通孔"理解成"盲孔"，这些语义偏差全靠人工盯着。
4.3 把需求写清楚：提示词的结构化写法
跑了几十个案例之后，我总结出一套相对稳定的提示词模板，特别适合让 LLM 生成 CadQuery 脚本：
- 指定建模基准：告诉它用 Workplane("XY") 作为默认平面，避免模型随机选面。
- 明确几何参数：能用数字就不用"稍微""大约"这种词，CAD 容不得模糊。
- 列出特征顺序：先主体后细节，信息组织方式就像你在跟一个实习生交代任务。
- 指定输出格式：要求用 CadQuery 脚本、带 export 语句，方便直接执行。
一个我自己用的提示词模板大概是这样的：
请写一段 CadQuery Python 代码，生成一个满足以下要求的零件。所有尺寸单位是毫米。建模时使用 cq.Workplane("XY") 作为起始平面。先创建主体，再依次添加孔、槽、倒角等特征。最后使用 cq.exporters.export 导出 STEP 文件。零件要求如下：...
这个模板本身不神奇，但它把模型最容易出错的几个地方（基准面、单位、特征顺序）都提前锁死了，实际成功率能提升不少。
5. 生成的东西能不能用？这是我建议的五步验收流程
text-to-cad 最大的坑不是生成不出来，而是生成结果"看起来能用，一加工就废"。这一章讲讲我怎么验收这些 AI 生成的模型。
5.1 几何层面最常见的坑：零厚度、悬空面、不闭合实体
网格生成出来的东西是"一张皮"，虽然有空洞、散面这些问题，但至少不会有"零厚度"这种概念。CAD 不一样，CAD 里一切都要有实体语义。我拿 AI 生成的 STEP 文件导入 FreeCAD 检查时，最常见到的问题就是：特征顺序不合理导致布尔运算产生退化几何，或者某个拉伸方向反了，导致面与面重叠、实体内部出现自由边。
检验方法其实很简单：在 FreeCAD 里用 Part 模块的"检查几何"工具跑一遍，或者尝试给模型做一个剖切视图。剖切面一看，内部是不是实体、有没有暗藏的零厚度缝隙，一目了然。
5.2 可编辑性：CAD 的命门
前面我一直强调可编辑性，这里具体展开。一个合格的 text-to-cad 结果，至少要满足三点：
- 特征树完整：模型不能是一整块"实心疙瘩"，要能从特征树里看到"底板-拉伸-打孔-倒角"的顺序。
- 尺寸参数可改：改一个孔的直径，整个模型要自动更新，而不是需要手动重建。
- 后续可继续建模：生成的模型还要能继续加新特征，比如在某个面上再画个槽。
这三点，序列生成类模型（比如 Zoo 的结果）做得比较好，因为它本质上就是重放建模序列，特征信息天然保留。而"LLM 写脚本"路线生成的结果，是否可编辑取决于脚本是不是用了参数变量。我见过不少 LLM 写出"魔法数字"写死的脚本，你要改一个数得满文件找，体验很差。所以我在提示词模板里会额外加一条：所有关键尺寸用变量定义，统一收在脚本开头。
5.3 我的五步验收流程
不管用什么工具生成，拿到模型后我都会走一遍这个流程，花不了几分钟，但能免掉后面的大坑：
- 打开 STEP 文件，旋转视角，肉眼检查外形和预期是否一致。
- 打开特征树，确认特征顺序合理、特征数量足够（不是退化合并成一坨）。
- 双击关键尺寸，改一个数，比如孔直径从 6 改成 8，看模型是否干净更新。
- 用剖切视图检查内部实体是否存在隐藏缺陷。
- 如果有 3D 打印或加工需求，再用切片软件或 CAM 里的自动检查过一遍，确认没有薄壁、倒扣这些制造禁忌。
这套流程甚至不限于 text-to-cad 生成的东西，从网上下载的 STEP 模型、同事发来的中间格式文件，我都建议先过一遍。
6. 当下面临的边界，以及我个人的下一步预期
最后聊聊这个技术的天花板在哪，以及它接下来大概会怎么走。这部分的判断带有我个人的主观色彩，只能代表我自己的观察。
6.1 语言描述的离散性 vs 连续几何的鸿沟
自然语言本质上是离散的、符号化的，而 CAD 几何是连续的、精确的。你用"外径 100，内径 40"这句话能描述一个法兰，但描述不了叶片泵里那个复杂的三维扭曲曲面。语言能表达的信息量是有限的，一句话说不完的细节，模型就只能在后台"猜"，猜出来的结果当然不一定符合你的意图。这也是为什么我现在仍然认为，在很长一段时间内，text-to-cad 最合适的应用场景是"快速生成标准件、简单零件、概念草模"，而不是替代工程师设计复杂产品。
6.2 装配体、制造约束与标准件的问题
大多数 text-to-cad 工作集中在单个零件，但现实工业里几乎没有孤立零件——哪怕一个最简单的传感器支架，也要和阀体、盖板、螺栓发生装配关系。生成一个零件容易，生成一套配合装配体难得多，因为涉及装配约束、间隙、公差、命名规则一系列问题。
另外，现在的模型基本没有"制造约束"的概念。它可以生成一个从渲染图上完全合理、但用数控机床根本没法加工的零件（比如无法装夹、刀具伸不进去的内腔）。所以我也在持续关注那些把"可制造性分析"接到 text-to-cad 后面的项目，这才是一条完整的产品链路。
6.3 关于工具和思路的建议
如果你问我现阶段普通人怎么用 text-to-cad 最划算，我的建议是：别追求"一步到位生成一个复杂零件"，而是把它当做一个**"参数化方向加速器"**。先用 text-to-cad 生成一个"意思对了"的初版，再导入专业 CAD 里把细节修正、把制造工艺加上。这样比从零开始画快很多，至少省了一张草图和一堆反复调整的时间。
我自己现在试得最多的还是"LLM 写 CadQuery"这条开源路线，因为每一步都可以审、可以改、可以用 git 管版本，出错也不会黑盒。Zoo 这类端到端服务则适合快速验证想法、生成演示用的 STEP 文件。两者不冲突，反而互补。
说句实在话，text-to-cad 还处在"玩具到工具之间"的位置，但它把 CAD 建模从"亲手画"变成"描述需求、审核结果"这个思路已经不可逆了。未来很快，标准件的生成会变成各种在线 CAD 工具的一个默认按钮；再往后，等模型学会读懂装配约束和加工工艺，它就会真正进入工程师的日常流程。到那个时候，回头再看今天这些生涩的提示词调优和特征树检查，大概会像现在看当年的人肉布线一样，既觉得麻烦，又觉得怀念。