给我生成一个M6内六角圆柱头螺栓长度30mm。第一次在网上看到有人用这句话直接在浏览器里生成并下载STEP文件的时候我第一反应是又一个营销噱头。直到自己亲手跑通把这个文件拖进FreeCAD看着特征树里真真切切躺着一个可编辑的实体模型才意识到text-to-cad这件事已经走到能落地用了。简单说text-to-cad就是通过自然语言描述让AI直接生成可用的CAD模型文件。它解决了传统三维建模里会画图的人和懂设计的人不是同一个这个老大难问题——概念设计阶段工程师脑海里的想法转成三维模型过去要么自己啃建模软件要么排队等专职建模的人现在可以直接用一句话先拿到一个基础模型做方案验证。这篇文章我会围绕text-to-cad的技术原理、主流工具、实操流程和踩坑记录做一次完整梳理适合机械工程师、创客、产品经理以及对AI生成三维模型感兴趣但一直没弄明白它跟AI绘画到底有什么不同的读者。1. text-to-cad是怎么工作的一句自然语言如何变成几何实体1.1 核心思路是文本转代码而非文本转图形很多人第一次接触text-to-cad很容易拿它跟Midjourney、Stable Diffusion做类比以为AI是直接画出一个三维模型。实际完全不是这回事。目前最主流、工程可用性最高的text-to-cad方案本质上是文本生成代码再用代码驱动几何内核生成模型。这条链路是这样的你输入的自然语言 → 大语言模型理解语义并生成一段程序化建模代码通常是Python里的CadQuery库或者OpenSCAD脚本 → 代码在本地或云端执行 → 几何内核计算并输出STEP/STL文件。这就解释了为什么text-to-cad生成的结果是精确的、可编辑的、带尺寸的而不是像AI绘画那样输出一张像素图。因为LLM在一开始就没有直接去想象几何形状它做的是它最擅长的事——写代码。这个思路的高明之处在于它把生成三维几何这个对AI来说极其困难的连续问题转化成了写一段生成几何的程序这个LLM相对擅长的离散问题。用生活化的类比来说AI绘画是让一个画家听了你的描述直接画一幅画给你text-to-cad是让一个程序员听了你的需求帮你写了一个能生成CAD文件的程序你自己运行一下就能在CAD软件里打开。显然后者更符合工程需求。1.2 为什么偏偏是CadQuery参数化建模的天然优势搞过机械设计的朋友都知道传统三维CAD软件里建模的核心操作其实是特征Feature——拉伸、旋转、打孔、倒角、阵列每一步都记录在特征树里模型因此是可以参数的、可回溯的、可改尺寸的。而CadQuery这个Python库恰好就是用代码来表述特征的框架它底层调用的是**OpenCascadeOCCT**几何内核。OCCT是一个工业级的B-Rep边界表示几何内核跟FreeCAD、KiCad用的是同一套。这意味着CadQuery生成的不是一堆拼凑的三角面片mesh而是真正有拓扑结构的实体——有面、有边、有顶点能进行布尔运算、倒角、抽壳能被下游CAM软件识别用于加工路径规划。相比另一个流行的程序化建模工具OpenSCADCadQuery的语法更接近传统CAD的设计直觉。OpenSCAD用的是纯函数式描述做简单的方块减法还行但遇到圆角、扫掠、放样这些高级特征就很别扭CadQuery则用面向对象的方式组织建模流程支持链式调用写起来跟GUI操作的感觉高度一致。这也是为什么目前几家主流的text-to-cad工具都不约而同选择了CadQuery作为输出后端——它生成的文件能最大限度兼容现有的工程软件生态。1.3 大语言模型在里面对应什么位置大语言模型在这条链路里承担的是语义到程序的翻译工作。GPT-4级别以上的模型在训练语料里见过海量的CadQuery、OpenSCAD代码所以它能够理解一个带通孔的圆柱体该用什么函数、什么参数来表达也大致了解M6螺栓意味着6mm外径、1mm螺距这些工程常识。但LLM毕竟不是CAD专家它对几何的理解是概率性的。它知道倒角对应chamfer()方法但不一定能精确算对你的倒角该是0.5mm还是1.5mm它知道法兰通常是一个圆盘状的凸缘但不一定清楚法兰厚度该跟轴套总长保持什么比例。这就是为什么做text-to-cad的提示词工程如此重要——你的提示词越接近几何语义LLM生成出来的代码就越可靠。2. 工具生态盘点2025年能用的text-to-cad方案有哪些2.1 ZOO Text-to-CAD把一句话生成零件做成了产品先聊目前普通用户最容易上手的工具——ZOO Text-to-CAD。这个平台的思路很直接浏览器里输入提示词后台调用大模型生成CadQuery代码实时预览3D效果满意就下载STEP或STL文件。我实测下来的感受是对于标准件简单轴类零件带孔板件这类几何特征明确的对象ZOO的生成成功率相当高。比如输入M8 hex nut它会给你一个带正六边形轮廓和中心螺纹孔的实体输入bracket with two 6mm holes它能给出一个L形或U形的支架。ZOO的特点在于交互设计做得好——它会把CadQuery代码同时展示在预览窗口旁边如果你懂一点Python甚至可以直接手动修改代码参数再重新生成相当于把AI生成和参数化设计串在了一起。免费额度对尝鲜够用量大的场景就需要付费了。2.2 本地部署路线用CadQueryAPI自己搭一套对数据保密要求高的公司或者需要把text-to-cad批量集成到内部流程里的团队完全可以在本地自己搭一套。核心组件就三样一个能调用大模型API的Python脚本、一个CadQuery环境、一个输出验证工具。工作逻辑是把用户的自然语言提示词打包进system prompt让模型输出规定格式的CadQuery代码然后本地执行这段代码最后导出STEP文件并做基本的几何校验。这里有个关键细节永远不要让模型直接返回文件而是让它返回代码。因为代码是可审查的、可校验的、可追溯的文件是一条死数据。我在实际项目中甚至会让LLM在生成代码后再另外生成一段自检测试代码用CadQuery的val.isValid()接口确认生成的是不是有效实体再决定是否进入下一步。成本方面按目前主流API定价生成一个中等复杂度的零件大约消耗0.1到0.5美元token批量做成内部工具之后单件成本能压到几毛钱人民币在原型验证场景下性价比已经可以接受了。2.3 别混淆Fusion 360的生成式设计不是text-to-cad还有一个常见的误区需要澄清。很多人听说Autodesk有生成式设计Generative Design以为那就是text-to-cad的官方工业版两者完全不是一回事。Fusion 360的生成式设计是基于你预设的载荷、约束、材料、保留区域由拓扑优化算法自动推演出材料分布最合理的结构形状。它解决的是在给定力学条件下如何设计最优结构的问题输入是边界条件输出是一个有机形态的网格体。而text-to-cad的方向恰恰相反——它是把你脑子里的概念描述直接翻译成可编辑的工程模型一个是从性能反推形状一个是从语义直译形状。两者未来可能互补但当前是完全独立的两条技术线。3. 实操全流程把一个带法兰的轴套说出来3.1 提示词设计把外观语言翻译成几何语义这是整个text-to-cad流程里最核心的一步。我发现80%的失败案例都源于同一个问题——用户用描述外观的词汇去要求一个几何引擎。比如你输入一个好看的支架LLM完全不知道该怎么办。它需要的是一个L形支架长边80mm短边50mm厚度5mm长边远端有一个直径8mm的通孔。你在提示词里给出的几何约束越详尽、越量化生成的结果就越接近可用状态。通用的提示词模板我总结了一个可以直接抄生成一个[零件类型]整体外形是[基本几何描述] 关键尺寸[尺寸1][尺寸2][尺寸3] 表面特征[孔/槽/螺纹/倒角]的位置、数量、大小 材料默认不做考虑单位使用[毫米/英寸] 需要导出的格式STEP反面教材和正面案例对比如下反面提示词问题改进后的提示词一个连接电机和泵的轴完全没给尺寸和传动结构一根实心圆柱轴直径20mm长度100mm两端各有一个5mm宽、5mm深的键槽一个圆形的盖子圆形是外观描述未定义边界一个圆盘外径60mm厚度3mm边缘均布6个直径5mm的安装孔孔心距圆心距离25mm带法兰的轴套缺少法兰和轴套的相对位置一个带法兰的轴套主体外径30mm内径18mm长度25mm法兰外径50mm、厚度4mm法兰位于轴套一端并与其同轴注意text-to-cad是对真实工程物品的简化跟Midjourney那种追求视觉华丽的提示词完全不兼容。如果不给尺寸LLM就会按训练数据里的常见值随机填充出来的模型99%不可用。3.2 完整生成过程演示法兰轴套我用ZOO平台实际跑一个例子。最终提示词如下A flanged bushing, body outer diameter 30mm, inner diameter 18mm, body length 25mm, flange diameter 50mm, flange thickness 4mm, flange located at one end of the bushing, share the same axis. Four mounting holes on the flange, diameter 5mm, positioned on a bolt circle with radius 20mm, evenly spaced at 90 degrees.需要说明的是这里的平台操作部分基于我用ZOO和本地CadQuery的实践经验梳理不同版本界面可能有微调但核心流程是通用的。提交后大约10到20秒平台返回一段CadQuery代码预览窗口出现模型。如果满意直接下载STEP文件。我习惯把每个生成结果都下载后拖进FreeCAD做一次体检确认实体有效性、测量关键尺寸防止直接进入下游流程后才发现尺寸偏离。3.3 关键代码逐段看假设我们选择本地CadQuery方案模型生成的代码核心部分是这样一段import cadquery as cq # 主体外径30mm 内径18mm 长度25mm body_outer_d 30 body_inner_d 18 body_length 25 # 法兰参数 flange_d 50 flange_t 4 # 安装孔参数 hole_d 5 hole_radius 20 hole_count 4 # 先创建主体圆柱(外径 - 内径 → 轴套壁) bushing ( cq.Workplane(XY) .cylinder(body_length, body_outer_d / 2) .faces(Z) .hole(body_inner_d / 2) ) # 在轴套一端创建法兰 result ( bushing .faces(Z) .workplane() .circle(flange_d / 2) .extrude(flange_t) ) # 在法兰面上开安装孔 result ( result .faces(Z) .workplane() .pushPoint((hole_radius, 0, 0)) .circle(hole_d / 2) .cutThruAll() # 旋转复制其余3个孔 .pushPoint((0, hole_radius, 0)) .circle(hole_d / 2) .cutThruAll() .pushPoint((-hole_radius, 0, 0)) .circle(hole_d / 2) .cutThruAll() .pushPoint((0, -hole_radius, 0)) .circle(hole_d / 2) .cutThruAll() ) cq.exporters.export(result, flanged_bushing.step)这段代码的核心逻辑值得拆一遍先用cylinder画一个外径15mm的圆柱用hole打出18mm的孔得到轴套壁然后在轴套顶面新建工作平面画一个半径25mm的圆并拉伸4mm生成法兰最后在法兰面上定位4个点逐个开直径5mm的贯通孔。每一行代码对应的都是一个你平时在SolidWorks里点击按钮的操作代码跑完模型也就建好了。这里要注意hole()方法默认是从选定面打孔到实体另一侧如果轴套壁没穿透就需要指定depth参数安装孔我用了cutThruAll()确保完全贯通这在某些工程场景下是必须的。这种细节问题LLM十次里有三四次会漏掉人肉检查代码时重点看这些地方。3.4 下游处理从STEP到可用的工程零件拿到STEP文件只是第一步。我建议的执行流程是这样的打开检查用FreeCAD或任意支持的CAD软件打开先看几何树是否干净是否存在重复面、退化边。尺寸验证用测量工具核对所有关键尺寸特别是孔距、配合直径。这一步不能省LLM对bolt circle radius 20mm的理解可能跟你不一样——它可能理解成直径20也可能理解成半径20实测经常出错。特征重构建如果你要在自己常用的CAD里做参数化修改最好把导入的哑体重新用本地特征覆盖一遍比如删掉原孔用自己软件的孔命令重打这样才能获得完整的参数化能力。干涉检查如果是装配体里的零件生成后第一时间在装配环境里做干涉检测尤其是配合面。经验之谈下载后直接用原样建模软件出图加工现阶段风险很大。text-to-cad更适合做方案级验证拿到的是讨论基础不是最终图纸。4. 常见问题与排查技巧实录4.1 能预览但下载后打不开或者打开是空实体这个问题我至少遇到过十几次原因基本都在单位和布尔运算失败上。CadQuery默认走毫米单位但有些平台后端在导出时会丢单位信息一些复杂的多实体模型在布尔求差时如果出现面重叠会生成无效实体invalid solidCAD软件打开后表现为空白或不可选。排查思路先不要直接用目标CAD软件打开改用CadQuery自己重新导入验证在Python里执行以下检查import cadquery as cq part cq.importers.importStep(flanged_bushing.step) print(part.val().isValid()) # 输出True才是有效实体如果输出False基本确认是布尔运算出错让LLM换一种布尔策略重新生成把多次cutThruAll()改成先建一个多孔集合再一次性做差。4.2 螺纹、倒角细节缺失或者生成了但出不来LLM默认倾向生成简化模型——你让它做螺栓它大概率给你一个光杆加六角头没有螺纹。这其实不是Bug是模型对螺栓这个概念的默认泛化测试集里大量代码都是简化表示的。如果螺纹必需提示词里必须显式声明比如with M6 screw thread profile或者actual helical thread, not simplified。但这一条也不是100%可靠因为CadQuery本身的螺纹绘制就需要用到import外部库或者复杂扫掠LLM未必每次都写得出来。我的建议是螺纹这类纯细节特征用text-to-cad生成完主体结构后自己在CAD里补。既保留效率又保证可控性没有必要在这上面跟AI较劲。4.3 修改提示词后结果差异巨大不可控这是LLM的随机性导致的。同一个提示词跑两次结果可能一个是对的一个完全跑偏。解决办法有两个一是尽量把提示词写死减少歧义空间。a bracket with holes改成a flat rectangular plate, 100mm x 50mm x 5mm, with four round through holes of diameter 6mm at the four corners, each hole center 10mm from the nearest edgeAI发挥的空间被压缩到近乎为零输出自然稳定。二是在本地部署方案里给API调用固定temperature建议0到0.2之间开启seed固定参数。温度设得越低生成结果越稳定代价是偶尔会有过于保守的倾向但在工程场景里稳定性远比创造力重要。4.4 生成结果尺寸对不上整体比例失调比如你要求法兰直径50mm、轴套外径30mm生成结果里法兰看起来跟轴套差不多粗。这是因为LLM对绝对数值的敏感度远低于对相对关系的敏感度。它知道法兰应该比轴套大但50对30这个具体比例它不一定算得准。解决方法是把相对关系也写进提示词不给它猜的机会flange diameter is 50mm, which is significantly larger than the body diameter of 30mm。或者更直接给关键尺寸加上明确的数学表达flange_d / body_d 50 / 30。4.5 平台生成超时或高复杂度零件直接失败text-to-cad生成的零件复杂度如果超过一定阈值比如特征超过30个、涉及扫掠/放样/多实体布尔云端平台很容易超时。这不是你的提示词写得不好而是LLM生成代码的可靠性在长序列下急剧下降。我的处理原则是分而治之把一个复杂零件拆成三到五个可单独生成的子零件分别生成最后在CAD里装配。比如一个带法兰的异形壳体先生成壳体主体旋转体抽壳再生成法兰盘再生成加强筋最后在CAD软件里用布尔合并。整个过程仍然比传统建模快得多而且每一步的稳定性都大幅提升。5. 实战效果对比与工具选型建议5.1 text-to-cad与text-to-3D的关键区别这两个概念经常被放在一起提但目标完全不同。维度text-to-cadtext-to-3D输入自然语言几何尺寸描述自然语言外观语义描述输出STEP等B-Rep实体文件OBJ/GLB/STL网格文件几何精度可精确到毫米级只有视觉大概形状可编辑性可导入CAD软件二次编辑通常不可逆地坍缩成网格工程可用性可直接进入仿真/CAM流程仅可用于渲染、展示、3D打印代表工具ZOO、CadQueryLLMMeshy、Tripo、Stable-Dreamfusion一句话总结text-to-3D追求的是看起来像text-to-cad追求的是造得出来。前者服务于视觉和游戏资产行业后者服务于工程制造行业。如果你的目标只是快速拿到一个模型做3D打印看效果text-to-3D反而更省事如果要进装配体做干涉检查、要出工程图、要CNC加工那只能走text-to-cad。5.2 什么场景真的适合用什么场景先别用基于我跑了上百个案例的经验以下场景是text-to-cad目前的舒适区方案快速选型同时生成三种不同结构的支架打印出来对比装配可行性标准件与非标简洁件法兰、轴套、垫片、外壳底座、固定块教学演示让学生直观看到文本描述如何被翻译成特征操作个人创客原型丢给3D打印机之前快速验证外形和孔位设计沟通跟客户/同事对齐我要的零件大概长这样不建议用的场景复杂装配体设计一个有几百个零件、互相约束的产品text-to-cad完全无能为力外观设计导向的零件消费电子外壳、汽车内饰这些形态自由度高的对象网格生成方式更合适需要严格公差标注的零件AI生成的是几何不是工艺GDT公差标注还得靠人批量标准件选型有现成标准件库的情况下没必要让AI重新发明一个M8螺母5.3 这条路的下一步会往哪走从发展趋势看text-to-cad正在从单轮生成走向多轮对话式设计。当前工具基本都是你给一句话它出一个结果不满意再重新写一句话——这个体验其实还停留在搜索引擎早期阶段。真正工程化的方向应该是能基于上一轮结果做局部修改比如法兰厚度再厚2mm安装孔改成腰形槽而不是每次都从零生成。另一个值得关注的方向是text-to-cad跟仿真分析的联动。既然生成的是带参数的实体会话模型那在STEP文件落地之前直接让AI调用一个轻量级仿真求解器做快速强度校核不满足条件就自动调整参数重新生成相当于把设计-仿真-迭代链路压缩到分钟级。目前已经有一些科研团队在探索这个方向估计一两年内会有产品化落地。我自己现在的工作流是概念阶段用text-to-cad先丢出三五个候选方案STEP文件统一拖进FreeCAD做尺寸复核选定后导入Fusion 360做详细设计。从一句自然语言到第一个可讨论的原型过去最快也得半天现在基本十分钟内能搞定这省下来的时间全都能花在真正值钱的方案权衡和细节推敲上。最后补充一个自己的体会text-to-cad输出的是方案的起点不是设计的终点。别指望一句prompt能替代工程师的设计判断。把AI当合作伙伴而不是替代者这个工具才会真正为你创造价值。这也是我特别想把这篇实战记录整理出来的原因——希望大家少走弯路尽快越过生成即垃圾不知如何调整的挫败阶段真正用起来。