前阵子有个做非标自动化的朋友发我一段需求，原话是：“我要一个外壳，能装下一个80×50×30的电机，壁厚3毫米，四个角要能过M4螺丝，出线口在侧面。”他问我能不能直接让AI把这句话变成能拿去加工的3D模型。这个需求，正是text-to-cad这个方向在解决的核心问题：用自然语言直接生成CAD模型。我花了两周时间把主流路线都试了一遍，也搭了一个能跑通的最小工作流，这篇文章就聊聊它到底是什么、能干什么、现在有哪些坑，以及我建议的用法。适合被建模需求折磨的工程师、想快速出原型的产品经理、刚接触CAD的新人，还有做自动化前期方案的人看。
先说结论：text-to-cad远没到“你描述一句，机器直接吐完美工程图”的程度，但作为需求沟通和方案初稿工具，已经非常好用了。关键是选对技术路线、管好Prompt、接受它的边界。
1. text-to-cad是什么，它在“翻译”什么
1.1 一句话原理：把自然语言翻译成建模操作序列
传统CAD建模的核心是什么？是特征历史树：先画一个草图，拉伸，再切一个槽，倒角，阵列。最终三维模型不是凭空出现的，而是一串有序操作在时间轴上累积的结果。而人类自然语言描述一个零件的时候，完全不会按照这个顺序来。
你说“一个带法兰的圆筒”，大脑里出现的是一张整体图，根本不会自动拆解成“先圆柱拉伸、再做法兰盘、然后布尔求和”。text-to-cad要做的，本质上不是“看图识物”，而是把模糊的自然语言意图，翻译成一行行有序的、参数化的建模操作。这个过程在学术界叫sequential decision（序列决策）：每个操作都会改变几何状态，下一步操作必须在正确的位置上接着做。
所以你会发现一个有趣的现象：让AI生成一个圆筒很快很稳，因为圆筒就是一个旋转拉伸；让它生成一个“带6个均布孔的圆盘”就容易翻车，因为“均布”两个字暗示了一个阵列操作，AI得自己决定起始角度、分布半径、孔的数量和布尔减法顺序。这不是尺寸问题，而是操作序列的规划问题。
1.2 当前三条主流技术路线对比
我实测下来，现在市面上能跑通的技术路线大概分三类，各有各的脾气：
| 技术路线 | 原理 | 输出物 | 成熟度 | 典型工具 |
|---|---|---|---|---|
| LLM生成参数化建模代码 | 大模型直接写Python代码（CadQuery/OpenSCAD） | 可参数化修改的代码+模型 | 最高，最稳 | CadQuery、OpenSCAD+LLM |
| 扩散模型生成隐式3D再转B-rep | 文生3D模型，再把网格转成实体边界表示 | 网格/自由曲面，难以参数化修改 | 中等，几何丰富但不可编辑 | 各类文生3D工具 |
| LLM做Agent驱动现有CAD软件 | 通过API、宏录像让AI操作AutoCAD、Fusion等 | 原生CAD文件，保留特征树 | 低，仅部分软件支持、速度慢 | 各CAD厂商的AI实验特性 |
我更倾向于第一类，也就是“LLM直接生成参数化建模代码”。原因是它有两个天然优势：第一，生成的代码本身就是建模历史，任何一个参数（直径、高度、孔距）都可以直接改，实用性远超一锤定音的网格模型；第二，代码可以反复执行，验证成本极低。AI写错了？重新跑一次就知道，不占用任何CAD软件许可。
2. 一条能跑通的最小工作流：LLM + CadQuery
2.1 为什么选CadQuery而不选OpenSCAD或直接操作AutoCAD
OpenSCAD是老牌程序化建模工具，学习成本低，但它基于CSG（布尔运算拼几何体），生成复杂零件时代码非常反人类，嵌套一堆（union/intersection/difference），LLM很容易写着写着括号就乱套。CadQuery则是面向“机械零件思维”的Python库，它把建模步骤组织成链式调用：先建工作平面，画轮廓，拉伸，选面，再挖孔。这跟人类用SolidWorks的操作习惯更接近，LLM生成这类代码的成功率明显更高。
另一个选项是让LLM直接去驱动AutoCAD或SolidWorks的宏，我试过一次就放弃了：各软件的API千差万别，代码一长串，调试一个宏的时间够我手动画三遍零件。CadQuery的接口简洁，文档齐全，而且能直接导出STEP、DXF、STL这些通用格式，后端可以和任何CAD软件对接。
2.2 环境准备：只装Python，不用碰大型CAD
这一步非常清爽。只需要Python 3.10以上版本，然后安装CadQuery即可。对于被“CAD安装包动不动几个G、卸载还不干净影响二次安装”折磨过的人来说，这种轻量方案简直是解脱。
pip install cadquery如果你习惯用Jupyter做交互实验，可以再装个配套显示插件，直接在笔记本里预览三维结果。整个环境加起来不到十分钟，期间不会弹任何激活窗口，也不会和系统里的C++库打架。我自己的习惯是单独建一个虚拟环境，避免和别的Python项目冲突。
python -m venv cq_env source cq_env/bin/activate # Windows下执行 cq_env\Scripts\activate pip install cadquery jupyter cadquery-jupyter需要注意CadQuery对Python版本有要求，2.x版本推荐3.10或更高，太老的版本会出现依赖编译问题。装完之后可以用一行命令验证：
python -c "import cadquery; print(cadquery.__version__)"能打出版本号就说明环境通了。
2.3 Prompt怎么写：把工程约束显式化
跟LLM配合建模，最忌给一句口语就撒手。我自己踩过几次坑之后，总结出一套比较稳的Prompt模板：显式声明单位、坐标系、输出格式、变量名，以及“只允许使用哪些API函数”。
你是CAD建模助手。请把用户的自然语言描述改写成CadQuery Python代码。 要求： 1. 只输出纯Python代码，不要注释，不要markdown代码块标记。 2. 必须使用cq.Workplane("XY")作为起点。 3. 默认单位是毫米，直径和半径不要混淆。 4. 如果描述了“均布孔”，必须使用polarArray并按指定数量生成。 5. 结果变量名固定为result，代码必须可以直接运行。 6. 不要创建任何多余变量，不要print。 用户需求：一个直径50mm、高20mm的实心圆柱，底面中心开一个直径10mm、深8mm的盲孔。为什么要这样限制？因为LLM自由发挥的空间越大，翻车概率越高。你让它“只输出代码”，它就不会给你一段夹杂说明文字的Markdown；你固定变量名，后续执行逻辑就不用解析它随意生成的命名。
2.4 完整可运行的示例脚本
假设我现在要建模上面那个需求，调用LLM后它会返回类似这样的CadQuery代码：
import cadquery as cq result = ( cq.Workplane("XY") .circle(25) # 直径50 -> 半径25 .extrude(20) # 高度20 .faces(">Z") # 选中顶面 .workplane() .hole(10, depth=8) # 直径10、深8的盲孔 )然后我用一个简单的Python脚本去执行它并导出STEP：
import cadquery as cq # 这里存LLM返回的代码 generated_code = """...上面那一段...""" namespace = {"cq": cq} exec(generated_code, namespace) result = namespace["result"] # 导出STEP，方便后续用任何主流CAD打开 cq.exporters.export(result, "output.step") # 也可以导出DXF用于二维表达 cq.exporters.export(result, "output.dxf")跑完之后，把output.step拖进SolidWorks、中望CAD、Fusion 360都能打开。你甚至可以进一步拿它转成PDF发确认图，对应很多人习惯的“CAD转PDF”流程。
注意：上面用exec执行LLM生成的代码，只适合本地Demo。生产环境必须做代码沙箱或白名单校验，否则AI一旦生成恶意代码（或者只是写了段死循环），你的机器就遭殃了。我在本地测试时用的是进程隔离加白名单函数检查。
3. 实测：同一批零件描述，AI的表现到底怎么样
3.1 测试集设计：从简单到“有点阴间”
为了不凭感觉下结论，我准备了一组测试用例，按工程复杂度递增：
| 编号 | 自然语言描述 | 涉及的关键操作 |
|---|---|---|
| T1 | 直径20mm、高30mm的圆柱 | 简单拉伸 |
| T2 | 直径40mm、厚5mm的圆盘，中心一个直径8mm的贯穿孔 | 拉伸+切除 |
| T3 | 长80mm、宽40mm、高20mm的长方体，四个竖直棱边倒角C5 | 拉伸+倒角 |
| T4 | 直径100mm、厚10mm的法兰盘，中心一个直径20mm的孔，外圈6个直径6mm的均布孔，分布在直径70mm的圆上 | 拉伸+多孔+阵列 |
| T5 | 一个L形支架，底板80×40×8，竖板高50、厚8、宽40，竖板与底板相交处加一道三角加强筋 | 多实体+布尔合并 |
T1到T3是常见的单特征零件，T4开始有阵列，T5则涉及多个特征块和布尔运算。每个用例我用同一套Prompt模板跑三次，取最稳定的结果。
3.2 结果总览：简单零件很稳，复杂零件看运气
三次测试后我做了个简单的成功率和主观评分：
| 用例 | 几何是否能跑通 | 尺寸是否全对 | 特征顺序是否合理 | 主观评分（5分制） |
|---|---|---|---|---|
| T1 | 是 | 是 | 无需纠结 | 5 |
| T2 | 是 | 是 | 合理 | 5 |
| T3 | 是 | 是 | 合理 | 4 |
| T4 | 偶尔失败 | 是（修正后） | 阵列参数容易错 | 3 |
| T5 | 第一次失败，换Prompt后通过 | 修正后 | 加强筋位置偏差 | 2.5 |
结论：纯拉伸、旋转、单孔类的零件，LLM接近“指哪打哪”；一旦涉及阵列、多实体布尔合并，尤其是“加强筋”这种需要依赖几何位置的实体，AI就要开始猜了。猜对的时候很惊艳，猜错的时候你得去代码里找哪里多偏移了几个毫米。
3.3 翻车现场：AI最容易错在四个地方
我把我遇到的失败案例汇总了一下，共性问题非常集中：
尺寸单位漂移。这是最常见的错。“直径50mm”有时候AI会理解成半径25然后写circle(25)，这算好的；更阴间的是“直径50，厚度3”它会把50当成半径直接circle(50)，导致整个零件大一倍。我后来在Prompt里强制加“直径和半径不要混淆”才压住了这个错误。你不加这句话，它大概率在某个不显眼的地方翻车。
“壁厚”的歧义。如果你说“壁厚3毫米的圆筒”，AI大概率会生成一个外径和内径差3毫米的空心圆柱。但如果原意是“在实心圆柱外面包一层3毫米厚的壳体”，两个理解的结果就完全不同。工程语言里我们觉得这句话很明确，但对LLM来说“壁厚”这个词天然包含了空心结构的暗示。
布尔运算顺序错乱。典型例子是把孔挖在实体还没拉伸的位置上。比如先写了hole(10)，下一步才extrude，拉伸出来的圆柱又是实心的，孔没了。CadQuery是顺序敏感的，LLM偶尔会忘记“先有几何，再选面，再切除”的依赖关系。这个错误在T5这种复合零件里特别容易出现。
“均布”被自由发挥。有一次我让AI做“6个均布孔”，它直接理解成“随机分布6个孔”，角度和半径完全没有规律。后来我强制要求用polarArray并给出分布半径，正确率才上来。这其实反映了LLM的一个本质问题：它知道“均布”这个词的意思，但不会自动推算出极坐标阵列的具体参数，你必须喂给它“沿什么圆、几个、起始角是多少”。
3.4 影响成功率的三个因素
跑完几十次之后，我发现影响结果的主要不是模型本身，而是三个可控因素：
- 术语规范度：“直径50”永远比“大概五厘米”成功率高；“贯穿孔”永远比“通的”成功率高。
- 特征顺序是否显式：在Prompt里写“先画底板，再立竖板，最后加筋”，成功率能提升一截。因为LLM的序列推理能力没有你想的那么强，你把顺序喂给它，它就不需要自己规划。
- 形状类型：旋转拉伸类（圆柱、法兰盘）成功率远高于异形钣金或自由曲面。“L形支架加加强筋”的难度大概是“圆筒”的十倍。
4. 为什么它还不能直接进生产：绕不开的限制
4.1 工程信息在这里是彻底的“黑洞”
你在自然语言里说的“孔要跟M4螺丝刚好配合”，对AI来说只有一个“直径大概4mm的孔”，但“刚好配合”四个字背后是一整套公差带：是间隙配合还是过盈配合？孔径上限是多少？下限是多少？表面粗糙度要求多高？要不要倒角方便装配？这些信息在text-to-cad的整个链路里是彻底缺失的。
即使AI生成的模型几何完全正确，你也只能把它当作“形状对了”的初稿，距离能下发给车间的图纸还有十万八千里。材料牌号、热处理、表面处理、未注公差标准，随便哪个都够一个零件被打回重做。
4.2 装配体和运动关系：当前基本无能为力
单个零件还能勉强对付，一旦涉及装配体就暴露了。你描述“一个齿轮箱，里面有大小两个齿轮啮合”，AI可以画出两个齿轮形状，但绝不会自动计算中心距、不会设定正确的啮合相位角、更不可能告诉你齿轮的模数是多少。参数化零件拼装成装配体，涉及的不只是布尔运算，还有大量约束关系、配合面、自由度。这些属于“设计意图”，目前没有任何一条技术路线能可靠地从一句话还原出完整设计意图。
4.3 数据主权和私有化部署的现实问题
工程图纸在很多公司是核心机密，不可能为了尝鲜就把图纸描述发给云端API。想要私有化部署，本地模型在复杂几何理解上的精度又差了不止一个档次。这是一个很现实的矛盾：精度高的云端方案不敢用，敢用的本地方案不够聪明。目前折中做法是只把“零件需求描述”发给模型，不发完整图纸，但即便如此，很多企业法务依然不批准。
4.4 和现有CAD生态的衔接：交出去的STEP是“死模型”
这是最容易被忽略的一坑。CadQuery生成的STEP文件，任何CAD都能打开，但它没有特征树——接收方看到的是一坨“哑实体”，没法直接改参数，只能重新建模或者做布尔修补。真正的设计协作需要交换原生格式（比如SolidWorks的SLDPRT、Fusion的F3D），而这些格式都是各家私有协议，开源工具基本无法生成。所以AI生成的模型到了同事手里，通常只能当参考，不能当修改起点。
此外，很多下游环节要的还是二维图纸。比如你最终要给供应商传一张带尺寸标注的PDF，那还是得把STEP导入CAD，重新出工程图。text-to-cad目前能把“形状”做出来，把“标注”“公差”“工艺要求”做出来还遥遥无期。
5. 我的选型建议和混搭工作流
5.1 现在就能用上它的人是谁
这轮测试做下来，我觉得最受益的是三类人：
一是做方案设计的人。跟客户聊需求时，当场用一句话生成一个初版三维示意，比画手绘图或者翻旧图纸高效太多。二是搞快速原型验证的创客，参数随便改，改完直接3D打印。三是做教学演示的，不用装大型CAD，直接在Jupyter里展示“一句话生成零件”的过程，学生很容易理解参数化建模的思想。
如果你是需要精确控制公差、材料、工艺的制造工程师，现阶段请继续手动建模，最多把AI当“草图生成器”用。
5.2 我推荐的“AI出初版-人工细化-软件收尾”三层流程
我自己日常使用的流程是四步：
- 用文本描述需求，让LLM生成CadQuery代码，跑通后导出STEP。
- 在本地CAD软件（我用Fusion和SolidWorks切换）里打开STEP，重新做特征识别，把关键尺寸改到标准值。
- 补全工程要素：公差、粗糙度、材料、热处理要求。
- 出工程图，导出PDF发确认。
这个流程里AI负责最无聊的“从0到1”，人负责所有需要判断力的“从1到10”。实测一个之前要半小时起步的支架类零件，现在十分钟内就能出初版，再花二十分钟收尾，整体效率翻倍。
5.3 如果你现在就想试：最省事的组合
开源路线首选Python+CadQuery+任意大模型API。成本极低，验证快，踩坑了也容易改。商业层面，一些现代化CAD工具已经在集成生成式AI功能，但可用性参差不齐，我的建议是先拿开源路线跑通思路，再决定要不要升级。
5.4 进阶玩法：把公司标准件库变成“AI可调用的积木”
这是我这段时间觉得最有价值的实践，也建议所有想在生产里用text-to-cad的人参考：与其让AI从零画一个轴承座、一个螺栓连接、一个带法兰电机壳，不如先把这些常见结构封装成CadQuery函数，比如：
def bearing_block(bore_diameter, block_width, block_height): """生成一个带轴承安装孔的方块""" ... def bolt_hole_pattern(plate, pitch_circle_diameter, bolt_count, hole_diameter): ...然后让LLM只负责“调用这些函数并传入参数”，而不是写一整段几何操作。这样AI的自由发挥空间被大大压缩，错误率肉眼可见地下降。我不需要AI发明新的建模方法，只需要它把我验证过的零件按需求拼装起来，这正好是LLM最擅长的事。
我自己的体会是，text-to-cad现在最大的价值不是“替代工程师”，而是“压缩从需求到初稿之间的等待时间”。它把一个原本必须先开软件、建文件、画草图、一步步拉伸切除的过程，压缩成一句人话加几秒钟的代码执行。对于任何需要快速把想法变成三维形状的人来说，这已经够值得用起来了。但我也劝你保持冷静：所有需要工程判断力的部分，目前仍然必须由人来兜底。真正的创造力，依然在你自己手里。
