1. 这个方向为什么突然火了先说结论text-to-cad解决的核心问题是“把脑海里的三维结构直接变成可编辑、可制造的CAD模型”。不管是给你自己做个手机支架还是给公司设计一个非标零件以前都得老老实实打开SolidWorks或者Fusion 360从草图开始一点点拉。现在不一样了。你输入一段自然语言——比如“一个直径30毫米、厚度5毫米的圆盘中心有一个直径8毫米的通孔”系统直接输出对应的CAD文件。要么是生成一段参数化建模脚本要么直接生成可编辑的三维实体文件。这个方向之所以值得关注是因为它把CAD的“使用门槛”和“生成效率”两个痛点同时打了一针。传统的建模流程本质上是人脑先构型再通过软件把构型翻译成几何约束和特征树。一个熟练的工程师画上面那个圆盘大概也要半分钟到一分钟。而text-to-cad这类工具输入文字后几秒到几十秒出结果而且输出的不是一张渲染图是可以继续编辑、导出STL去3D打印、或者直接用来出工程图的三维模型。这对非机械专业出身的人比如创客、工业设计师、电子工程师是一个很实在的效率杠杆。这篇文章的定位很清晰如果你对AI辅助设计感兴趣但不想只停留在“AI能生成模型”的概念层而是想知道“它具体是怎么做到的、有哪些工具现在就能用、我在实操中会遇到什么坑”那接下来的内容是为你准备的。我会从底层思路拆解、工具选型、完整实操流程到问题排查全部过一遍确保你看完能自己动手跑通一个最简单的text-to-cad流程。我没有把这件事当成科幻来看而是当成一个“终于有人把CAD的语法糖做出来了”的现实生产力工具来分享。原因很简单——这个领域的核心不是AI从零创造几何而是AI学会了“把自然语言翻译成CAD软件能懂的几何操作序列”这几年在语言模型和程序合成两个方向的积累让这件事真正到了可落地的阶段。2. 内容整体设计与思路拆解2.1 技术路径的三种流派text-to-cad看起来只是“文字进、模型出”但背后选了一条什么技术路线直接决定了生成结果的质量、可编辑性和应用边界。市面上主流的有三条路线我有必要把它们拆开讲清楚否则你选错了方向后面的体验会完全不一样。第一条是直接生成体素或网格模型。这类方案通常用三维扩散模型类似二维图像生成的Stable Diffusion的思路只不过生成空间从像素变成了体素。输入文字描述模型直接输出一个三维体素场然后通过Marching Cubes之类的算法提取出网格。优点是非常直观文字能描述到的形状基本都能“画”出来适合做概念设计、造型探索、游戏资产。缺点也很致命生成的网格质量差、拓扑混乱、有大量自交面而且基本不具备参数化可编辑性。你拿着一个网格模型去改尺寸只能整体缩放改不了“把圆角从2毫米改成5毫米”这种操作。第二条是生成CAD命令序列或程序代码。这是当前学术和工业界认为最有落地价值的一条路Text2CAD、Zoo Text2CAD这些代表性项目都走这个方向。系统把“文字描述”通过大语言模型翻译成一串CAD操作指令比如画草图、加约束、拉伸、打孔、倒角本质上是在写一段“建模操作程序”。这样做的好处非常明显生成的结果自带参数化结构、特征树完整你可以回到CAD软件里去编辑任何一个步骤。缺点也有因为输出的是程序化指令遇到“雕塑感很强、曲面自由”的描述会比较吃力那是细分曲面和参数化曲面的强项不是参数化实体建模的长处。第三条是检索式的方法。系统先从数据库里检索相似模型再通过文本控制做局部变形生成一个新模型。这类方案适合“我要一个类似XX但稍微不同的零件”的场景缺点是数据库覆盖面决定上限你的需求稍微偏一点结果就开始“牛头不对马嘴”。你看这三条路线没有一条是“银弹”理解了它们的区别你才能明白为什么这个领域目前最主流、工具链最成熟的方案是“文字→建模代码→CAD实体”这一条。它是唯一能做到“生成的模型真的能用、能改、能制造”的路径。2.2 为什么“先生成代码”比“直接生成模型”更聪明我最早接触text-to-cad时有个疑问为什么不直接让AI输出一个STEP文件非要让它先输出一段CadQuery或者OpenSCAD代码然后再花时间执行和转换这不是多此一举吗后来在实际用过的项目里我才彻底想通这个问题。核心原因有三个每个都很现实。第一代码是可验证的。CAD软件里的大多数操作比如拉伸、旋转、布耳运算对几何精度要求极高。如果让AI直接吐一个网格你很难从“一堆三角形”里看出来它有没有做错。但如果输出的是代码你可以一行一行地审哪里错了改哪里甚至可以让另一个AI来检查这段代码的语法和逻辑。也就是说“代码”作为一个中间表达给了整个系统一个中断、检查、修正的机会这是端到端黑盒生成不具备的。第二代码是可编辑的。工业界的模型不是生成出来就完事了。客户过来说“把这个槽宽改小2毫米”AI生成的参数化代码可以直接改参数变量重新执行一次就得到新模型整个过程可能只需要几秒钟。你如果让AI直接生成网格等着重新训模型或者手动雕刻吧。第三数据集是现成的。当前几乎所有公开的CAD数据集比如ABC、Fusion 360 Gallery、Text2CAD数据集都可以自动转成CAD操作序列。语言模型本身就是文本处理工具让它学习“从自然语言到建模代码的翻译”简直顺理成章。这也是为什么短短两三年这个方向的模型能力突飞猛进因为技术基座——LLM——本身就成熟了。说人话就是让AI写“怎么做模型”的说明书再让CAD内核按说明书执行比让AI直接凭空变出模型靠谱得多。这也是为什么我下面所有实操内容都围绕“文字→代码→实体”这条链路展开。3. 工具选型与核心细节解析3.1 现在能直接用的主流工具一览table:工具/项目基础模型输出形式特点与适用人群开源情况Zoo Text2CADLlama-3.1-8B-Instruct微调CadQuery代码部署轻量效果稳定入门首选开源Text2CAD (MIT等)自训练模型 LLMCadQuery代码学术性强含数据集研究参考价值高开源CAD-GPT多种LLM微调自定义CAD命令序列约束求解能力强适合复杂参数化零件研究性开源Autodesk Fusion 360 生成式设计扩展内置AI原生Fusion特征模型商业级集成适合专业工程师闭源光看这张表可能没有太大感觉我用实际的体感来传达一下。Zoo Text2CAD目前算是“最不折腾、最接近开箱即用”的一个它面向的对象就是像我这样想快速验证流程的人。它的精度虽然不能和商业软件PK但作为流程验证和原型生成效果已经足够惊艳。Text2CAD是真正把这个概念做成严格论文和多模态数据集的项目模型的训练数据本身就是从大量CAD建模过程里提炼出来的“文字-操作对”。你看它的论文会发现团队甚至专门做了“草图和特征融合”的编码器让文字描述能和CAD特征一一对应起来。这个项目的意义不在那个demo能生成多复杂的模型而在它给整个领域提供了标准和数据基础。CAD-GPT这种方向就更“硬核”了它不是简单生成CadQuery脚本而是想直接预测一套包含约束求解的策略再交给CAD内核去求解。这个路线的上限更高但复杂度也明显更高项目主要还是停留在研究和预印本阶段。3.2 实操首选CadQuery的两个决定性理由每个工具都有自己的建模语言为什么我在实操里首选CadQuery而不是OpenSCAD不是因为它一定更强而是它的设计哲学跟“AI生成”这件事最匹配。CadQuery是一个基于Python的CAD库它的工作方式是用代码构建一个“实体序列”。你今天拉伸一个圆台明天打个孔每一步操作都作用在当前实体上最后得到一个复合实体。这种链式调用方式和语言模型逐字生成代码的思考方式几乎完美契合。更实际的意义有两个。第一CadQuery天然支持参数化。你定义一个变量d30后面所有用到直径30毫米的地方都引用这个变量改一处全图更新。这对AI生成的代码来说是刚需因为AI不可能每次都准确得像人类一样心里的数一点不错参数化给了你“事后调整”的容错空间。第二CadQuery背后是OpenCASCADE几何内核这是工业级的内核导出的STEP、STL文件质量远不是普通网格工具能比的。当然OpenSCAD也不差它尤其在“CSG布尔运算”和“纯数学建模”的场景下很简洁代码更像数学表达式。但它的生态和Python生态的距离比较远AI生成的代码在CadQuery里报错了你还能用标准的Python调试工具去查在OpenSCAD里就不太好查了。一句话总结如果你想认真玩text-to-cad这条链路选CadQuery做建模后端是当前综合体验和踩坑率最低的选择。下面的实操部分我也会全程用它。4. 实操过程与核心环节实现4.1 环境准备30分钟搭好一个可运行的text-to-cad实验台别急着先下载大模型我建议的路径是先把推理环境跑通再处理数据。为什么要先跑通推理因为电脑上只有“模型真的能跑起来”你后面调试提示词、调参才有真实反馈否则你在网上看的那些示例永远跟你没关系。我用的是一台配备RTX 4090显卡的机器显存24GB推理Zoo Text2CAD默认量化版本完全没压力。如果你的显卡弱一些也没关系可以把模型量化为4bit或8bit显存占用能降到8GB左右。第一步创建独立的Python虚拟环境避免把系统Python搞乱。conda create -n text2cad python3.11 conda activate text2cad第二步克隆Zoo Text2CAD的仓库并安装依赖。git clone https://github.com/zoo-group/zoo-text2cad.git cd zoo-text2cad pip install -r requirements.txt第三步下载模型权重。这一步很关键仓库里提供了多个档位的模型我实际用的是“Llama-3.1-8B-Instruct-text2cad-v1”这个基于微调的版本文件名里一般会带有“8B”字样。放到本地目录后需要改一下推理脚本里的模型路径具体每个人目录结构不同但我建议在配置里用一个绝对路径不要用相对路径省得到后面发疯不知道模型在哪。第四步验证环境。跑一个仓库自带的demo提示词比如“a flat head screwdriver”正常情况下的输出应该是CadQuery代码而不是报错信息。如果这段代码能成功执行你就获得了最基本的“从文字到CAD模型”的能力。4.2 写提示词的三个层次从能出结果到出好结果“写个手机支架”这种提示词任何模型都会懵。不是说它不知道手机支架长啥样而是它不确定你要多宽的手机、多大的倾斜角、是否需要充电口开槽。这个领域对提示词的要求远比写文案生成要高因为你描述的是精确的几何和空间关系。根据我的经验提示词可以拆成三层递进结构。第一层是主体形状描述。锁定大方向它是一个平板一个圆筒一个L形支架?需要说清楚“是什么形状的什么物体”。第二层是尺寸约束。这是model能不能用的关键。建议优先使用“直径、高度、厚度、壁厚、中心距”这种标准工程词汇并且单位明确。比如可以直接这样写A cylinder with a diameter of 40 mm and a height of 60 mm。第三层是特征操作描述。也就是你要在上面加什么或减什么中心开一个直径10毫米的孔底部加一个厚度2毫米的底座外沿倒角1毫米。这些描述对应到CadQuery里就是一个个具体的operation模型能不能准确翻译出来也跟你的描述颗粒度有关。我来给你看一个我实际跑通的提示词这是一个可用性极高的压缩机阀片简化模型提示词A circular valve plate with a diameter of 50 mm and a thickness of 3 mm, featuring five holes of 6 mm diameter arranged in a circular pattern with a pitch circle diameter of 34 mm, and a center hole of 8 mm diameter.这段英文提示词看起来比较长但没有一个词是浪费的。它把“是什么形状圆盘、尺寸50mm直径、3mm厚、特征数量5孔、位置PCD直径34mm均匀分布、中心孔大小直径8mm”全部交代清楚了。实际生成的代码是这样的这是Zoo Text2CAD输出的简化版逻辑完全一致import cadquery as cq diameter 50 thickness 3 pcd 34 hole_diameter 6 center_hole 8 result ( cq.Workplane(XY) .circle(diameter / 2) .extrude(thickness) .faces(Z) .workplane() .center(0, 0) .circle(center_hole / 2) .cutBlind(-thickness) )注意模型生成的可能不是完整代码而是片段或伪代码这很正常。你需要自己补全CadQuery语法。但这恰恰是text-to-cad目前最实用的使用场景AI不是直接给你成品而是给你一个高完成度的草稿你负责补全和验收。整个过程从一个空白的Fusion 360界面开始画画到这里拿到可编译的代码总时间通常不超过两分钟。4.3 从代码到实体把CadQuery脚本转成STL或STEP拿到代码之后下一件事就是把它变成真实的三维模型文件。这一步我强烈建议直接在CadQuery的脚本环境里做不要复制到在线CAD里随便跑因为离线执行会给你更多调试和查看的自由度。将以下代码存成一个valve_plate.py然后运行import cadquery as cq diameter 50 thickness 3 pcd 34 hole_diameter 6 center_hole 8 valve_plate ( cq.Workplane(XY) .circle(diameter / 2) .extrude(thickness) .faces(Z) .workplane() .center(0, 0) .circle(center_hole / 2) .cutBlind(-thickness) ) for i in range(5): angle_rad math.radians(360 / 5 * i) x pcd / 2 * math.cos(angle_rad) y pcd / 2 * math.sin(angle_rad) valve_plate ( valve_plate.faces(Z) .workplane() .center(x, y) .circle(hole_diameter / 2) .cutBlind(-thickness) ) cq.exporters.export(valve_plate, valve_plate.stl) cq.exporters.export(valve_plate, valve_plate.step)运行后你会得到两个文件STL格式用来3D打印或渲染渲染预览STEP格式用来导入SolidWorks、Fusion 360、FreeCAD等主流工具做进一步编辑。到这一步一个“从文字描述到可制造模型”的完整闭环已经跑通了。有一点值得提一下实际跑通之后你会发现AI生成代码的“一次通过率”可能只有五六成。最常见的问题是import漏了、某个变量没有定义、布尔运算时选的面不对。这些错误都不是致命伤用标准的Python调试思路逐行查就好了。真正麻烦的是下面这节要讲的几类“看起来没报错但结果不对”的隐性坑。5. 常见问题与排查技巧实录5.1 最坑的不是报错而是“运行成功了但模型明显不对”我接触text-to-cad一年多最头疼的问题从来不是“代码运行报错”而是“CAD渲染出来一个奇形怪状的玩意儿但它不报错也不警告”。这种项目里最经典的现象包括第一坐标系理解偏差。语言模型对英文的“top face”“side face”理解通常是语义级的但CAD里的面是有严格方向和法向的。提示词里说“在顶部打孔”模型可能在“Z”面上打完孔之后又用同样的坐标去给底面剪了个盲孔看上去代码逻辑完整但实际模型多了一个你根本不需要的特征。第二单位不一致。模型有时候会默认你在用英寸但我们的CadQuery脚本默认是毫米。一个直径2.0的圆柱你以为生成2毫米直径的小销钉结果模型给它解释成2英寸然后换算成50.8毫米的大圆盘。这类问题排查起来非常费劲因为你从代码上看不出任何毛病只有把视图放大到合适比例才恍然大悟。第三布尔运算顺序错误。CadQuery里先后顺序很重要。你是先画一个圆盘再打孔还是先画一个圆环再拉伸得到的结果完全不一样。前者会产生一个带孔的实体后者可能产生一个“悬浮”的圆环。AI生成的代码经常会在布尔运算的链路上出现这类问题而且极难从文本角度发现。我自己的排查习惯是拿到AI生成的代码后不要急着转STL。先在CadQuery的查看器里用“逐步执行”的方式把每一步生成的中间几何结果都输出一遍看到底哪一步异化了。这一步多花两分钟能省下后面半小时的徒劳调试。5.2 快速排查表给你的text-to-cad项目备一份table:现象可能原因排查方案模型尺寸和预期差太多单位混用mm与inch查看生成代码里的尺寸参数强制性在提示词中注明units in millimeters打孔的位置完全错位中心坐标计算错误检查pitch circle diameter的计算是否除以2检查循环里的cos/sin角度是否用了弧度制生成模型有大量自交面布尔运算顺序问题或直接生成网格改用CadQuery或OpenSCAD代码路径避免端到端直接输出STL网格拉伸方向反了对法向面的理解错误在提示词中明确“extrude in positive Z direction”生成代码运行报错“name X is not defined”模型漏掉了变量声明在提示词里把每个需要的尺寸都先定义成变量让AI形成“先定义变量再写操作”的习惯渲染出来是个空壳拉伸深度为0或过薄检查extrude的深度数值确认它和零件的高度一致出图的拓扑混乱导出的STL是底层网格直接拟合优先导出STEP再用Meshlab等工具进行网格修复这张表看起来是问题清单但它背后其实有一个共同的方向别把AI生成的CDA模型当成不可质疑的“成品”把它当成一个需要验收的“毛坯方料”。这个意识一旦建立你的排查效率会大幅提升。5.3 实用小结跑通一遍之后你会发现现在text-to-cad真正的瓶颈不再是“生成能力”而是“可控性”。你让模型生成一个龙头把手它带你三个风格各异的方案但你让它把按钮直径做成25毫米它可能会把25毫米理解成半径然后给你做成一朵“向日葵”。所以我的建议很直接用这个技术要克制一点。它不是用来替代严谨的机械设计的而是用来快速产出原型、探索造型、生成思路草稿的。一个极佳的使用场景是“我给客户出了三个方案用text-to-cad在两小时里弄出了六个方向”而不是“这个核心承力件我让AI直接写代码开模”。另外如果你打算长期用这个工作流我建议把常用提示词模板沉淀下来。我是用一份简单的笔记维护的里面存着“圆盘类零件”“轴类零件”“法兰类零件”等常见基础形状的标准提示词模板用的时候直接改数字就行。这份提示词资产某种意义上比模型权重更值钱——因为模型一直在更新而你对业务需求的描述方式才是真正属于你的竞争力。6. 写在最后聊到这里text-to-cad在我心里的定位已经很明确了它不是一个“取代CAD工程师”的威胁者而是一个“把工程师从重复劳动里解放出来”的杠杆。说句大实话我刚开始接触Zoo Text2CAD时心里也有“这靠谱吗”的怀疑。直到我连续跑通了十几个零件从磁性手机支架到散热风扇外壳确认它能在几分钟内给出一个能编辑、能出图、能打印的基础实体时才真正意识到这个工作流已经远不是玩具。这篇文章里的所有步骤我都按“从零到一”的顺序走了一遍你照着做大概率能在一个晚上以内构建出属于你自己的“文字到CAD模型”流水线。哪怕你只是一个业余的3D打印爱好者从这段经验里映射出的能力也足够让你的创意从文案直接跨进车间。我个人实际操作中的体会是这个工具的爽点不在“它能做出来的那个最终模型”而在“它让你敢于去描述、去构型那些以前根本不敢碰的东西”。你不再需要精通每一个拉伸、旋转、扫掠的按钮顺序你只需要知道你想要什么。这种“意图驱动创作”的感觉是我用这个工作流之后最大的收获。最后分享一个小技巧先学会给AI“打草稿”而不是一开始就追求完美成品。你每一次让AI生成的模型本质上都是在给你的“文字描述能力”做标注训练——描述得越准确、越工程化下一位AI同学给你的模型就越靠谱。把这当成一种技能来练习你会发现text-to-cad的价值会随着时间的推移不断放大。 
长河君 · 2026/10/8 21:47:16 · 阅读 1.2k text-to-cad实战：用自然语言生成可编辑CAD模型的AI辅助设计
1. 这个方向为什么突然火了先说结论text-to-cad解决的核心问题是“把脑海里的三维结构直接变成可编辑、可制造的CAD模型”。不管是给你自己做个手机支架还是给公司设计一个非标零件以前都得老老实实打开SolidWorks或者Fusion 360从草图开始一点点拉。现在不一样了。你输入一段自然语言——比如“一个直径30毫米、厚度5毫米的圆盘中心有一个直径8毫米的通孔”系统直接输出对应的CAD文件。要么是生成一段参数化建模脚本要么直接生成可编辑的三维实体文件。这个方向之所以值得关注是因为它把CAD的“使用门槛”和“生成效率”两个痛点同时打了一针。传统的建模流程本质上是人脑先构型再通过软件把构型翻译成几何约束和特征树。一个熟练的工程师画上面那个圆盘大概也要半分钟到一分钟。而text-to-cad这类工具输入文字后几秒到几十秒出结果而且输出的不是一张渲染图是可以继续编辑、导出STL去3D打印、或者直接用来出工程图的三维模型。这对非机械专业出身的人比如创客、工业设计师、电子工程师是一个很实在的效率杠杆。这篇文章的定位很清晰如果你对AI辅助设计感兴趣但不想只停留在“AI能生成模型”的概念层而是想知道“它具体是怎么做到的、有哪些工具现在就能用、我在实操中会遇到什么坑”那接下来的内容是为你准备的。我会从底层思路拆解、工具选型、完整实操流程到问题排查全部过一遍确保你看完能自己动手跑通一个最简单的text-to-cad流程。我没有把这件事当成科幻来看而是当成一个“终于有人把CAD的语法糖做出来了”的现实生产力工具来分享。原因很简单——这个领域的核心不是AI从零创造几何而是AI学会了“把自然语言翻译成CAD软件能懂的几何操作序列”这几年在语言模型和程序合成两个方向的积累让这件事真正到了可落地的阶段。2. 内容整体设计与思路拆解2.1 技术路径的三种流派text-to-cad看起来只是“文字进、模型出”但背后选了一条什么技术路线直接决定了生成结果的质量、可编辑性和应用边界。市面上主流的有三条路线我有必要把它们拆开讲清楚否则你选错了方向后面的体验会完全不一样。第一条是直接生成体素或网格模型。这类方案通常用三维扩散模型类似二维图像生成的Stable Diffusion的思路只不过生成空间从像素变成了体素。输入文字描述模型直接输出一个三维体素场然后通过Marching Cubes之类的算法提取出网格。优点是非常直观文字能描述到的形状基本都能“画”出来适合做概念设计、造型探索、游戏资产。缺点也很致命生成的网格质量差、拓扑混乱、有大量自交面而且基本不具备参数化可编辑性。你拿着一个网格模型去改尺寸只能整体缩放改不了“把圆角从2毫米改成5毫米”这种操作。第二条是生成CAD命令序列或程序代码。这是当前学术和工业界认为最有落地价值的一条路Text2CAD、Zoo Text2CAD这些代表性项目都走这个方向。系统把“文字描述”通过大语言模型翻译成一串CAD操作指令比如画草图、加约束、拉伸、打孔、倒角本质上是在写一段“建模操作程序”。这样做的好处非常明显生成的结果自带参数化结构、特征树完整你可以回到CAD软件里去编辑任何一个步骤。缺点也有因为输出的是程序化指令遇到“雕塑感很强、曲面自由”的描述会比较吃力那是细分曲面和参数化曲面的强项不是参数化实体建模的长处。第三条是检索式的方法。系统先从数据库里检索相似模型再通过文本控制做局部变形生成一个新模型。这类方案适合“我要一个类似XX但稍微不同的零件”的场景缺点是数据库覆盖面决定上限你的需求稍微偏一点结果就开始“牛头不对马嘴”。你看这三条路线没有一条是“银弹”理解了它们的区别你才能明白为什么这个领域目前最主流、工具链最成熟的方案是“文字→建模代码→CAD实体”这一条。它是唯一能做到“生成的模型真的能用、能改、能制造”的路径。2.2 为什么“先生成代码”比“直接生成模型”更聪明我最早接触text-to-cad时有个疑问为什么不直接让AI输出一个STEP文件非要让它先输出一段CadQuery或者OpenSCAD代码然后再花时间执行和转换这不是多此一举吗后来在实际用过的项目里我才彻底想通这个问题。核心原因有三个每个都很现实。第一代码是可验证的。CAD软件里的大多数操作比如拉伸、旋转、布耳运算对几何精度要求极高。如果让AI直接吐一个网格你很难从“一堆三角形”里看出来它有没有做错。但如果输出的是代码你可以一行一行地审哪里错了改哪里甚至可以让另一个AI来检查这段代码的语法和逻辑。也就是说“代码”作为一个中间表达给了整个系统一个中断、检查、修正的机会这是端到端黑盒生成不具备的。第二代码是可编辑的。工业界的模型不是生成出来就完事了。客户过来说“把这个槽宽改小2毫米”AI生成的参数化代码可以直接改参数变量重新执行一次就得到新模型整个过程可能只需要几秒钟。你如果让AI直接生成网格等着重新训模型或者手动雕刻吧。第三数据集是现成的。当前几乎所有公开的CAD数据集比如ABC、Fusion 360 Gallery、Text2CAD数据集都可以自动转成CAD操作序列。语言模型本身就是文本处理工具让它学习“从自然语言到建模代码的翻译”简直顺理成章。这也是为什么短短两三年这个方向的模型能力突飞猛进因为技术基座——LLM——本身就成熟了。说人话就是让AI写“怎么做模型”的说明书再让CAD内核按说明书执行比让AI直接凭空变出模型靠谱得多。这也是为什么我下面所有实操内容都围绕“文字→代码→实体”这条链路展开。3. 工具选型与核心细节解析3.1 现在能直接用的主流工具一览table:工具/项目基础模型输出形式特点与适用人群开源情况Zoo Text2CADLlama-3.1-8B-Instruct微调CadQuery代码部署轻量效果稳定入门首选开源Text2CAD (MIT等)自训练模型 LLMCadQuery代码学术性强含数据集研究参考价值高开源CAD-GPT多种LLM微调自定义CAD命令序列约束求解能力强适合复杂参数化零件研究性开源Autodesk Fusion 360 生成式设计扩展内置AI原生Fusion特征模型商业级集成适合专业工程师闭源光看这张表可能没有太大感觉我用实际的体感来传达一下。Zoo Text2CAD目前算是“最不折腾、最接近开箱即用”的一个它面向的对象就是像我这样想快速验证流程的人。它的精度虽然不能和商业软件PK但作为流程验证和原型生成效果已经足够惊艳。Text2CAD是真正把这个概念做成严格论文和多模态数据集的项目模型的训练数据本身就是从大量CAD建模过程里提炼出来的“文字-操作对”。你看它的论文会发现团队甚至专门做了“草图和特征融合”的编码器让文字描述能和CAD特征一一对应起来。这个项目的意义不在那个demo能生成多复杂的模型而在它给整个领域提供了标准和数据基础。CAD-GPT这种方向就更“硬核”了它不是简单生成CadQuery脚本而是想直接预测一套包含约束求解的策略再交给CAD内核去求解。这个路线的上限更高但复杂度也明显更高项目主要还是停留在研究和预印本阶段。3.2 实操首选CadQuery的两个决定性理由每个工具都有自己的建模语言为什么我在实操里首选CadQuery而不是OpenSCAD不是因为它一定更强而是它的设计哲学跟“AI生成”这件事最匹配。CadQuery是一个基于Python的CAD库它的工作方式是用代码构建一个“实体序列”。你今天拉伸一个圆台明天打个孔每一步操作都作用在当前实体上最后得到一个复合实体。这种链式调用方式和语言模型逐字生成代码的思考方式几乎完美契合。更实际的意义有两个。第一CadQuery天然支持参数化。你定义一个变量d30后面所有用到直径30毫米的地方都引用这个变量改一处全图更新。这对AI生成的代码来说是刚需因为AI不可能每次都准确得像人类一样心里的数一点不错参数化给了你“事后调整”的容错空间。第二CadQuery背后是OpenCASCADE几何内核这是工业级的内核导出的STEP、STL文件质量远不是普通网格工具能比的。当然OpenSCAD也不差它尤其在“CSG布尔运算”和“纯数学建模”的场景下很简洁代码更像数学表达式。但它的生态和Python生态的距离比较远AI生成的代码在CadQuery里报错了你还能用标准的Python调试工具去查在OpenSCAD里就不太好查了。一句话总结如果你想认真玩text-to-cad这条链路选CadQuery做建模后端是当前综合体验和踩坑率最低的选择。下面的实操部分我也会全程用它。4. 实操过程与核心环节实现4.1 环境准备30分钟搭好一个可运行的text-to-cad实验台别急着先下载大模型我建议的路径是先把推理环境跑通再处理数据。为什么要先跑通推理因为电脑上只有“模型真的能跑起来”你后面调试提示词、调参才有真实反馈否则你在网上看的那些示例永远跟你没关系。我用的是一台配备RTX 4090显卡的机器显存24GB推理Zoo Text2CAD默认量化版本完全没压力。如果你的显卡弱一些也没关系可以把模型量化为4bit或8bit显存占用能降到8GB左右。第一步创建独立的Python虚拟环境避免把系统Python搞乱。conda create -n text2cad python3.11 conda activate text2cad第二步克隆Zoo Text2CAD的仓库并安装依赖。git clone https://github.com/zoo-group/zoo-text2cad.git cd zoo-text2cad pip install -r requirements.txt第三步下载模型权重。这一步很关键仓库里提供了多个档位的模型我实际用的是“Llama-3.1-8B-Instruct-text2cad-v1”这个基于微调的版本文件名里一般会带有“8B”字样。放到本地目录后需要改一下推理脚本里的模型路径具体每个人目录结构不同但我建议在配置里用一个绝对路径不要用相对路径省得到后面发疯不知道模型在哪。第四步验证环境。跑一个仓库自带的demo提示词比如“a flat head screwdriver”正常情况下的输出应该是CadQuery代码而不是报错信息。如果这段代码能成功执行你就获得了最基本的“从文字到CAD模型”的能力。4.2 写提示词的三个层次从能出结果到出好结果“写个手机支架”这种提示词任何模型都会懵。不是说它不知道手机支架长啥样而是它不确定你要多宽的手机、多大的倾斜角、是否需要充电口开槽。这个领域对提示词的要求远比写文案生成要高因为你描述的是精确的几何和空间关系。根据我的经验提示词可以拆成三层递进结构。第一层是主体形状描述。锁定大方向它是一个平板一个圆筒一个L形支架?需要说清楚“是什么形状的什么物体”。第二层是尺寸约束。这是model能不能用的关键。建议优先使用“直径、高度、厚度、壁厚、中心距”这种标准工程词汇并且单位明确。比如可以直接这样写A cylinder with a diameter of 40 mm and a height of 60 mm。第三层是特征操作描述。也就是你要在上面加什么或减什么中心开一个直径10毫米的孔底部加一个厚度2毫米的底座外沿倒角1毫米。这些描述对应到CadQuery里就是一个个具体的operation模型能不能准确翻译出来也跟你的描述颗粒度有关。我来给你看一个我实际跑通的提示词这是一个可用性极高的压缩机阀片简化模型提示词A circular valve plate with a diameter of 50 mm and a thickness of 3 mm, featuring five holes of 6 mm diameter arranged in a circular pattern with a pitch circle diameter of 34 mm, and a center hole of 8 mm diameter.这段英文提示词看起来比较长但没有一个词是浪费的。它把“是什么形状圆盘、尺寸50mm直径、3mm厚、特征数量5孔、位置PCD直径34mm均匀分布、中心孔大小直径8mm”全部交代清楚了。实际生成的代码是这样的这是Zoo Text2CAD输出的简化版逻辑完全一致import cadquery as cq diameter 50 thickness 3 pcd 34 hole_diameter 6 center_hole 8 result ( cq.Workplane(XY) .circle(diameter / 2) .extrude(thickness) .faces(Z) .workplane() .center(0, 0) .circle(center_hole / 2) .cutBlind(-thickness) )注意模型生成的可能不是完整代码而是片段或伪代码这很正常。你需要自己补全CadQuery语法。但这恰恰是text-to-cad目前最实用的使用场景AI不是直接给你成品而是给你一个高完成度的草稿你负责补全和验收。整个过程从一个空白的Fusion 360界面开始画画到这里拿到可编译的代码总时间通常不超过两分钟。4.3 从代码到实体把CadQuery脚本转成STL或STEP拿到代码之后下一件事就是把它变成真实的三维模型文件。这一步我强烈建议直接在CadQuery的脚本环境里做不要复制到在线CAD里随便跑因为离线执行会给你更多调试和查看的自由度。将以下代码存成一个valve_plate.py然后运行import cadquery as cq diameter 50 thickness 3 pcd 34 hole_diameter 6 center_hole 8 valve_plate ( cq.Workplane(XY) .circle(diameter / 2) .extrude(thickness) .faces(Z) .workplane() .center(0, 0) .circle(center_hole / 2) .cutBlind(-thickness) ) for i in range(5): angle_rad math.radians(360 / 5 * i) x pcd / 2 * math.cos(angle_rad) y pcd / 2 * math.sin(angle_rad) valve_plate ( valve_plate.faces(Z) .workplane() .center(x, y) .circle(hole_diameter / 2) .cutBlind(-thickness) ) cq.exporters.export(valve_plate, valve_plate.stl) cq.exporters.export(valve_plate, valve_plate.step)运行后你会得到两个文件STL格式用来3D打印或渲染渲染预览STEP格式用来导入SolidWorks、Fusion 360、FreeCAD等主流工具做进一步编辑。到这一步一个“从文字描述到可制造模型”的完整闭环已经跑通了。有一点值得提一下实际跑通之后你会发现AI生成代码的“一次通过率”可能只有五六成。最常见的问题是import漏了、某个变量没有定义、布尔运算时选的面不对。这些错误都不是致命伤用标准的Python调试思路逐行查就好了。真正麻烦的是下面这节要讲的几类“看起来没报错但结果不对”的隐性坑。5. 常见问题与排查技巧实录5.1 最坑的不是报错而是“运行成功了但模型明显不对”我接触text-to-cad一年多最头疼的问题从来不是“代码运行报错”而是“CAD渲染出来一个奇形怪状的玩意儿但它不报错也不警告”。这种项目里最经典的现象包括第一坐标系理解偏差。语言模型对英文的“top face”“side face”理解通常是语义级的但CAD里的面是有严格方向和法向的。提示词里说“在顶部打孔”模型可能在“Z”面上打完孔之后又用同样的坐标去给底面剪了个盲孔看上去代码逻辑完整但实际模型多了一个你根本不需要的特征。第二单位不一致。模型有时候会默认你在用英寸但我们的CadQuery脚本默认是毫米。一个直径2.0的圆柱你以为生成2毫米直径的小销钉结果模型给它解释成2英寸然后换算成50.8毫米的大圆盘。这类问题排查起来非常费劲因为你从代码上看不出任何毛病只有把视图放大到合适比例才恍然大悟。第三布尔运算顺序错误。CadQuery里先后顺序很重要。你是先画一个圆盘再打孔还是先画一个圆环再拉伸得到的结果完全不一样。前者会产生一个带孔的实体后者可能产生一个“悬浮”的圆环。AI生成的代码经常会在布尔运算的链路上出现这类问题而且极难从文本角度发现。我自己的排查习惯是拿到AI生成的代码后不要急着转STL。先在CadQuery的查看器里用“逐步执行”的方式把每一步生成的中间几何结果都输出一遍看到底哪一步异化了。这一步多花两分钟能省下后面半小时的徒劳调试。5.2 快速排查表给你的text-to-cad项目备一份table:现象可能原因排查方案模型尺寸和预期差太多单位混用mm与inch查看生成代码里的尺寸参数强制性在提示词中注明units in millimeters打孔的位置完全错位中心坐标计算错误检查pitch circle diameter的计算是否除以2检查循环里的cos/sin角度是否用了弧度制生成模型有大量自交面布尔运算顺序问题或直接生成网格改用CadQuery或OpenSCAD代码路径避免端到端直接输出STL网格拉伸方向反了对法向面的理解错误在提示词中明确“extrude in positive Z direction”生成代码运行报错“name X is not defined”模型漏掉了变量声明在提示词里把每个需要的尺寸都先定义成变量让AI形成“先定义变量再写操作”的习惯渲染出来是个空壳拉伸深度为0或过薄检查extrude的深度数值确认它和零件的高度一致出图的拓扑混乱导出的STL是底层网格直接拟合优先导出STEP再用Meshlab等工具进行网格修复这张表看起来是问题清单但它背后其实有一个共同的方向别把AI生成的CDA模型当成不可质疑的“成品”把它当成一个需要验收的“毛坯方料”。这个意识一旦建立你的排查效率会大幅提升。5.3 实用小结跑通一遍之后你会发现现在text-to-cad真正的瓶颈不再是“生成能力”而是“可控性”。你让模型生成一个龙头把手它带你三个风格各异的方案但你让它把按钮直径做成25毫米它可能会把25毫米理解成半径然后给你做成一朵“向日葵”。所以我的建议很直接用这个技术要克制一点。它不是用来替代严谨的机械设计的而是用来快速产出原型、探索造型、生成思路草稿的。一个极佳的使用场景是“我给客户出了三个方案用text-to-cad在两小时里弄出了六个方向”而不是“这个核心承力件我让AI直接写代码开模”。另外如果你打算长期用这个工作流我建议把常用提示词模板沉淀下来。我是用一份简单的笔记维护的里面存着“圆盘类零件”“轴类零件”“法兰类零件”等常见基础形状的标准提示词模板用的时候直接改数字就行。这份提示词资产某种意义上比模型权重更值钱——因为模型一直在更新而你对业务需求的描述方式才是真正属于你的竞争力。6. 写在最后聊到这里text-to-cad在我心里的定位已经很明确了它不是一个“取代CAD工程师”的威胁者而是一个“把工程师从重复劳动里解放出来”的杠杆。说句大实话我刚开始接触Zoo Text2CAD时心里也有“这靠谱吗”的怀疑。直到我连续跑通了十几个零件从磁性手机支架到散热风扇外壳确认它能在几分钟内给出一个能编辑、能出图、能打印的基础实体时才真正意识到这个工作流已经远不是玩具。这篇文章里的所有步骤我都按“从零到一”的顺序走了一遍你照着做大概率能在一个晚上以内构建出属于你自己的“文字到CAD模型”流水线。哪怕你只是一个业余的3D打印爱好者从这段经验里映射出的能力也足够让你的创意从文案直接跨进车间。我个人实际操作中的体会是这个工具的爽点不在“它能做出来的那个最终模型”而在“它让你敢于去描述、去构型那些以前根本不敢碰的东西”。你不再需要精通每一个拉伸、旋转、扫掠的按钮顺序你只需要知道你想要什么。这种“意图驱动创作”的感觉是我用这个工作流之后最大的收获。最后分享一个小技巧先学会给AI“打草稿”而不是一开始就追求完美成品。你每一次让AI生成的模型本质上都是在给你的“文字描述能力”做标注训练——描述得越准确、越工程化下一位AI同学给你的模型就越靠谱。把这当成一种技能来练习你会发现text-to-cad的价值会随着时间的推移不断放大。