前阵子有个做非标自动化的朋友发我一段需求原话是“我要一个外壳能装下一个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、OpenSCADLLM扩散模型生成隐式3D再转B-rep文生3D模型再把网格转成实体边界表示网格/自由曲面难以参数化修改中等几何丰富但不可编辑各类文生3D工具LLM做Agent驱动现有CAD软件通过API、宏录像让AI操作AutoCAD、Fusion等原生CAD文件保留特征树低仅部分软件支持、速度慢各CAD厂商的AI实验特性我更倾向于第一类也就是“LLM直接生成参数化建模代码”。原因是它有两个天然优势第一生成的代码本身就是建模历史任何一个参数直径、高度、孔距都可以直接改实用性远超一锤定音的网格模型第二代码可以反复执行验证成本极低。AI写错了重新跑一次就知道不占用任何CAD软件许可。2. 一条能跑通的最小工作流LLM CadQuery2.1 为什么选CadQuery而不选OpenSCAD或直接操作AutoCADOpenSCAD是老牌程序化建模工具学习成本低但它基于CSG布尔运算拼几何体生成复杂零件时代码非常反人类嵌套一堆union/intersection/differenceLLM很容易写着写着括号就乱套。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, depth8) # 直径10、深8的盲孔 )然后我用一个简单的Python脚本去执行它并导出STEPimport 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是是无需纠结5T2是是合理5T3是是合理4T4偶尔失败是修正后阵列参数容易错3T5第一次失败换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 如果你现在就想试最省事的组合开源路线首选PythonCadQuery任意大模型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现在最大的价值不是“替代工程师”而是“压缩从需求到初稿之间的等待时间”。它把一个原本必须先开软件、建文件、画草图、一步步拉伸切除的过程压缩成一句人话加几秒钟的代码执行。对于任何需要快速把想法变成三维形状的人来说这已经够值得用起来了。但我也劝你保持冷静所有需要工程判断力的部分目前仍然必须由人来兜底。真正的创造力依然在你自己手里。