1. 认识Text-to-CAD从“画图建模”到“对话建模”过去十年不管是机械设计、工业设计还是3D打印爱好者都离不开一个繁琐的流程先在脑子里想清楚结构打开CAD软件画草图、加约束、拉伸出实体、倒角、打孔再反复修改尺寸。整个流程的学习成本很高SolidWorks、Fusion 360这类专业软件的快捷键和操作逻辑就能劝退一批新人。而现在Text-to-CAD的出现把这件事压缩成一句话直接告诉AI你要什么形状、什么尺寸、什么功能让它把可编辑的CAD模型给你生成出来。这个概念听起来很“科幻”但2024年到2025年间相关的开源项目和商业工具已经扎堆出现比如以GPT-4为核心的开源工具Zoo、基于Llama-3在浏览器里本地运行的tlDraw、学术界提出的Text2CAD和CAD-LlamA等。它们的核心逻辑是统一的把自然语言描述转换成参数化建模指令或代码再通过CAD内核如OpenCASCADE执行最终得到带特征历史、可继续编辑的B-Rep实体模型。这篇内容适合谁看如果你是搞机械设计、产品结构设计的工程师想知道这个技术能不能帮你提效如果你是对3D建模感兴趣的创客想免费用自然语言生成可打印的模型又或者你是做AI应用的开发者想接住这波技术红利做工具。下面我会从原理、方案选型、实操、避坑四个维度把Text-to-CAD讲透最后直接给出一套能在本地跑通的开源方案。2. 为什么是“生成代码”而不是“生成模型”2.1 直接生成Mesh的坑先说一个普遍的误区。很多人第一次接触Text-to-CAD会以为后台是类似Midjourney那样直接“画”出三维模型。本质上有一类方案确实是这样的——直接生成体素Voxel或点云Point Cloud再用Marching Cubes之类的算法重建Mesh。但实际用下来这类方案在CAD领域几乎站不住脚。原因很简单CAD模型的核心不是“长得像”而是“可制造、可编辑、可约束”。一个由几百万三角面片组成的STL网格导入SolidWorks后就是一团“死数据”没法改倒角半径没法重设孔径没法变更厚度更没法在工程图里标注公差。而制造业和结构设计真正依赖的是参数化特征树——每一步拉伸、旋转、布尔运算都记录在案修改一个参数就能让整个模型跟着变。所以Text-to-CAD的成熟方案几乎全部绕开了“直接生成Mesh”这条路。另一个原因是计算稳定性。扩散模型直接生成体素或点云很容易出现拓扑错误比如面片重叠、非流形边、孔洞、反法线——这类网格在3D打印切片软件里就是灾难轻则打印变形重则直接报错。相比之下程序化建模生成的B-Rep实体天然是流形的、封闭的、可计算的出错的概率低得多。2.2 程序化建模语言成为“中间语言”的必然性既然不能直接生成Mesh那总得给AI一个“表达方式”。很自然的思路是让AI生成一段程序化建模的脚本由CAD内核去执行。目前主流的三类程序化建模语言是OpenSCAD基于CSG构造实体几何用布尔运算组合基本体语法接近C语言极其简洁适合生成机械零件和参数化模型缺点是曲面造型能力弱。CadQuery基于Python构建在OpenCASCADE内核之上API风格是“选择面、拉伸、开孔”非常贴近人类建模思路适合大多数机械件。Build123dCadQuery的继任者同样是Python但API设计更现代建模上下文管理更清晰社区活跃度正在上升。选择代码作为“中间语言”有几个天然优势。首先代码是文本大语言模型最擅长的就是生成文本。其次代码是可执行的通过CAD内核跑一遍就能得到实体模型方便实时预览和校验。再次代码是可修改的——用户嫌孔太小直接让AI“把孔径从5毫米改成8毫米”模型的历史树仍然完整。正是这三条让“Text-to-Code-to-CAD”成了当前所有主流Text-to-CAD方案的共同底座。3. 主流技术路线解析通用大模型、专用模型与本地部署3.1 通用大模型路线用GPT-4或Llama-3直接写CAD脚本目前最“野蛮生长”的一类方案是直接用通用大模型生成OpenSCAD或CadQuery脚本。典型代表是开源工具Zoo它的第一版就是让GPT-4直接输出OpenSCAD代码再用OpenSCAD引擎实时渲染预览。Zoo还支持多轮对话你可以在预览图上直接提“把上面的圆角加大”它会重新生成代码。用通用大模型的好处是泛化能力强你不需要为它专门准备训练数据什么“法兰盘”“齿轮箱”“散热器支架”它都见过。坏处是它经常“胡编乱造”比如调用一个不存在的CAD库函数或者把OpenSCAD的语法和Python的语法混在一起。所以这类工具普遍做了一个关键处理在后端捕获代码执行异常把报错信息再塞回给大模型让它“自己纠错”。实测下来加上这一层自我纠错循环执行成功率可以从60%拉到85%以上。这类方案另一个关键点是“工具调用”。Zoo不直接把所有上下文一次性丢给模型而是把OpenSCAD代码执行器封装成工具让GPT-4在必要的时候“调用”它。这也意味着你的设计过程是可视化的——代码生成一步模型更新一步每一步都可以回溯。3.2 专用微调模型路线Text2CAD与CAD-LlamA学术界更偏好专用模型这条路。典型代表是2024年提出的Text2CAD它采用两阶段架构先用一个轻量模型把文本描述解析成“CAD命令序列”再把这些命令喂给一个类似G-code执行器的东西生成B-Rep模型。CAD-LlamA则是基于Llama-2/3做指令微调让它学习从自然语言直接映射到CAD操作指令的分布规律。和通用大模型相比专用模型的优势是输出结构更可控不会乱用API生成的脚本语法错误率低很多。劣势也很明显——训练数据稀缺。CAD命令序列不像网页文本那样海量可得目前可用的公开数据集主要是ABC、Fusion 360 Gallery等规模不过几万个零件泛化能力远赶不上通用大模型。实际体验下来你描述一个数据集里没见过的“异形曲面支架”它大概率会输出一个四不像。我这里给的结论是如果你只是尝鲜或做原型验证直接上通用大模型路线成功率最高如果你要针对特定品类比如只做齿轮、只做法兰做专用工具可以收集几千个同类零件数据微调一个Llama-3-8B推理成本能压到极低。3.3 本地部署方案从API依赖到完全离线很多人关心数据保密问题。设计图纸在不少公司属于核心资产把几何描述发到云端API确实让人心里打鼓。针对这个需求tlDraw这类工具支持完全本地化运行模型用Llama-3-8B量化后约6GB显存脚本执行用本地OpenSCAD或CadQuery整个流程不依赖任何外网服务。本地部署的性价比要仔细算。一个8B模型在A100上生成一个中等复杂零件的脚本大约需要510秒在消费级RTX 3090上需要1530秒比云端GPT-4慢不少。但换来的是零API费用和完全的数据隔离对中小团队来说这个权衡是可以接受的。我个人更推荐的折中方案是用云端强模型做初稿再用本地小模型做局部修正两者结合速度和成本都能兼顾。4. 实操落地在本地跑通一套Text-to-CAD工作流4.1 环境准备与工具链选择下面直接给出一套我实测过、能跑通的本地方案。核心组合是“远程大模型生成CadQuery代码 本地OpenCASCADE执行”整套环境约30分钟可以搭完。首先准备Python环境建议用3.10或3.11版本避免CadQuery对3.12的兼容性问题。核心依赖就三个pip install cadquery pip install openai pip install jupyterCadQuery安装时会把OpenCASCADE内核一起编译好电脑上暂时不用安装独立的CAD软件。OpenAI库用于调用大模型API这里我用OpenAI兼容接口如果接本地Ollama服务只需要改base_url和model名称。接下来验证CadQuery环境是否正常跑一个最简单的拉伸示例。能输出实体体积就说明内核工作正常import cadquery as cq result cq.Workplane(XY).box(10, 20, 5) print(result.val().Volume())4.2 提示词工程决定成败的“说话方式”同样的模型提示词写法不同生成质量可以差出几个量级。我总结了五条实测有效的规则规则一先描述整体形状再描述局部特征。正确的说法是“一个长40毫米、宽30毫米、高20毫米的长方体顶部中心有一个直径10毫米的通孔四个角做半径为3毫米的圆角”,而不是“我要一个带孔和圆角的盒子”。规则二明确单位不要有歧义。直接说“毫米”不要只说“40×30×20”。CAD的尺寸病很常见AI经常默认使用英寸然后你导出一个340毫米的“小零件”。规则三把制造特征说清楚。是通孔还是盲孔螺纹孔还是光孔倒角是C角斜切还是R角圆角这些术语直接影响生成代码的差异也直接影响后期能不能加工。规则四多用“相对”描述少用绝对坐标。说“在顶面中心开孔”比“在坐标(20, 15, 20)处开孔”可靠得多因为AI算绝对坐标经常翻车。规则五一次只设计一个零件先不要提装配体。让模型生成一个装配体是灾难零件间的配合关系它现在还处理不好先出单体再手工装配更实际。这里我加一个可直接套用的提示词模板实测生成可靠度很高用CadQuery生成一个机械零件尺寸单位是毫米。 零件整体是一个长{长度}、宽{宽度}、高{高度}的立方体。 在顶面中心加工一个直径{直径}毫米的通孔。 在底面的四个角分别做一个半径{半径}毫米的圆角。 将生成的实体赋值给变量result。注意最后一句“将生成的实体赋值给变量result”非常关键它告诉模型上下文里后续代码应该怎样引用你的零件。4.3 完整实操一段话生成一个可编辑的法兰座下面用一个真实案例串联整个工作流。我的目标是生成一个“四孔法兰安装座”——带中心通孔和四个螺栓孔的矩形法兰盘。提示词这样写用CadQuery生成一个矩形法兰座毫米单位。 底板长80、宽60、高10底板四角做R5圆角。 在底板中心上方拉伸一个外径40、内径25、高30的圆筒圆筒与底板一体。 圆筒顶部向外有一个直径70、厚5的圆形法兰盘法兰盘与圆筒一体。 法兰盘上沿圆周均布4个直径6.5的通孔孔中心所在圆直径为55。 所有锐边做0.5毫米的倒角。 最终实体赋值给result。把这段提示词发给大模型返回的CadQuery代码骨架如下已整理核心逻辑import cadquery as cq # 底板 base cq.Workplane(XY).rect(80, 60).extrude(10).edges().fillet(5) # 圆筒 cyl cq.Workplane(XY).circle(40/2).extrude(30) cyl cyl.faces(Z).workplane().circle(25/2).cutBlind(-30) # 顶部法兰盘 flange cq.Workplane(XY).workplane(offset30).circle(70/2).extrude(5) # 合并 part base.union(cyl).union(flange) # 挖4个螺栓孔 part (part.faces(Z).workplane() .polarArray(55/2, 0, 360, 4) .circle(6.5/2).cutBlind(5)) # 倒角 part part.edges().fillet(0.5) result part执行这段代码后用CadQuery的导出功能生成STEP文件cq.exporters.export(result, flange.step)然后可以直接把STEP文件拖进Fusion 360或FreeCAD查看。整个流程从输入文字到得到可编辑的STEP文件大约2分钟。如果中间有语法报错把报错信息原样贴回给模型让它修正最多两轮基本能跑通。我实测这个“报错回传”机制能解决80%以上的生成失败问题。5. 避坑指南常见翻车现场与排查手记5.1 尺寸单位混乱这是出现频率最高的问题。提示词里没写“毫米”模型就会按它训练数据里的默认习惯来——很多英文训练语料默认是英寸。你期待一个80毫米的零件结果得到一个80英寸的庞然大物导入软件后缩放比例完全不对。解决办法提示词里第一句就绑定单位并且生成代码后马上检查关键尺寸。我在工作流里加了一段自动校验逻辑读取生成零件的主要包围盒尺寸跟输入的期望值对比偏差超过10%就直接触发重生成。另外要注意CadQuery里如果直接写80默认单位是毫米但如果模型把Constrain表达式写成带括号的计算式有时会引入浮点误差导致尺寸公差超标。检查时保留3位小数即可不要被尾数干扰。5.2 布尔运算失败与“坏实体”这是第二个高频坑。模型生成了两个相交的实体要做union或cut操作时OpenCASCADE报错“BRep_API: command not done”。原因往往是两个实体刚好有共面或相切的情况布尔运算遇到这种临界几何就罢工了。我的排查套路分三步走。第一检查是否真的相交把其中一个实体做微小平移或旋转破坏临界条件。第二把共面相交改成微小重叠——比如两个长方体长度分别是20和20.001用0.001的余量去覆盖相接面。第三如果前两步都不行改用面-面拼接的思路用Workplane选面继续extrude而不用union。实际上很多“union失败”的本质是建模思路不对更好的方式是直接在已有实体的面上继续拉伸成体。5.3 选错面导致特征加错位置模型有时会在错误的面上去打孔或拉伸。典型场景是先拉伸出圆筒然后想在“顶面”开孔模型却在“底面”开了个孔。原因是CAD上下文里的面选择有歧义模型要的可能是Z最大Z值方向的面但代码写成了Z。这类问题靠肉眼检查代码比较费劲我的经验是在提示词里帮模型把方位限定好。比如“在最大Z值方向的顶面开孔”同时要求生成代码里必须包含.faces(Z)这样的限定符。如果生成代码里没有这类方位限定直接打回让它重写。我给读者整理了一张高频问题速查表方便对照处理问题现象根因处理办法尺寸整体放大25.4倍单位默认为英寸提示词首行声明“毫米单位”并校验关键尺寸布尔运算报错共面/相切临界几何让实体微小重叠后再次尝试孔开到了底面选了错误的面限定.faces(Z)或.faces(Z)圆角位置全错边缘选择未过滤限定“底面上表面的四条边”用.faces(Z).edges()嵌套生成时间过长实体面数过多检查代码是否有大量fitPoints或扫描适度简化API返回空字符串上下文过长拆分为多轮或压缩历史记录导出STEP失败实体非流形先做check()检查边界表示完整性5.4 上下文爆炸与多轮修改失忆Text-to-CAD走对话式设计时用户会逐步提修改需求。但上下文长度一长模型就容易“失忆”——你说“把上一个孔移到左边3毫米”它可能把之前的圆角删了。这个问题我用了一个小技巧每轮修改只回传“当前完整代码 本次修改指令”不把聊天记录全部塞进上下文。实现上很简单在程序里维护一个“当前最新代码”变量每次对话前把这段代码全文贴进系统提示词然后附上用户的修改意图。这种方法实测修改成功率大幅提升因为模型总是基于最新的代码状态而不是记忆来工作。最后再提醒一个细节工作目录里最好建一个models/子目录每个版本导出STEP时带上时间戳比如flange_20250127_0930.step。对话式设计迭代很快没有版本编号你根本分不清哪个是最新状态。这个习惯帮我省了很多麻烦。6. 真实使用体验与技术边界聊到这儿我把这段时间日常使用Text-to-CAD的真实体会也说一下。它能解决的是“标准化零件快速建模”问题——法兰、支架、壳体、齿轮座这类规则件一条提示词就能搞定比手动建模至少快5倍尤其适合前期方案评审时快速出多个备选形状。但如果你的目标是非对称的复杂曲面件比如鼠标外壳、人体工学手柄这套方案目前还是比较吃力模型对自由曲面的文本描述理解力有限输出的结果往往偏“方块感”。给新入坑的人一个个人经验排序先花一下午把Zoo或tlDraw跑通体验什么是“对话建模”再花一天把CadQuery环境搭好因为它是你调试和兜底的核心工具最后才考虑要不要微调专用模型——大多数情况下通用大模型加良好的提示词模板已经能覆盖80%的日常需求。技术迭代很快但掌握这套工作流之后不管底层换成哪个模型你的使用逻辑都不会被淘汰。
