我一直在摸索怎么把“自然语言描述”变成真正能用的三维模型。直到接触到 text-to-cad 这个方向我才觉得之前那些只生成图片的AI玩法终于开始碰工程实体的边了。这篇内容我想完整聊聊我从调研、选型到跑通一套最小工作流的全过程包括我给AI下指令的方式、后端怎么执行、中间踩过哪些坑以及它和日常CAD操作到底怎么衔接。如果你也在做机械设计、产品结构或者纯粹想用自然语言快速出个三维示意这篇文章应该能给你一套能直接照做的思路。说白了text-to-cad 就是把“给我一个直径50mm、高度30mm、带六个均布孔的圆盘”这句话变成一份参数化CAD代码再交给内核算出一个真实可编辑的实体模型。它跟我以前用鼠标在SolidWorks里拖草图完全是两条路但产出的东西是一样的Step文件、Stl文件甚至是带约束的草图。下面我就按自己的实践顺序来拆。1. text-to-cad 到底是什么从一个机械设计痛点说起刚听到 text-to-cad 的时候我以为就是让AI画个3D图后来发现完全不是那么回事。常规的AI生图工具输出的是像素而CAD要的是精确的几何拓扑和尺寸约束差一个毫米都没法加工。text-to-cad 的核心目标是把用户输入的文本描述解析成一组参数化建模指令再通过CAD内核生成带完整工程语义的模型文件。这个文件的B-rep边界表示里包含面、边、顶点、拓扑关系下游能做倒角、抽壳、布尔运算和CAM编程。我一开始的痛点其实很简单客户半夜发来一句“要一个法兰座外径120内径配合轴55厚度18四个沉头孔”我得摸黑开软件从基准面开始画。用 text-to-cad 之后这句话可以直接变成脚本剩下的事就是检查尺寸、微调特征顺序比从头建模快得不是一星半点。1.1 从自然语言到三维模型的完整链路不要以为中间只有AI模型一个环节。一条完整的链路至少包含四段意图解析把自然语言拆成实体类型板、轴、法兰、箱体尺寸直径、高度、孔数特征倒角、阵列约束同轴、固定、对称。代码生成把解析后的参数翻译成一段程序化建模代码最常见的是CadQuery、OpenSCAD乃至FreeCAD的Python API脚本。几何内核计算执行这份代码交给OpenCASCADE、Parasolid或ACIS内核去构建几何实体。格式输出与校验导出STEP、STL、IGES甚至自动生成工程图同时通过视觉检查、干涉检查和尺寸校验来兜底。这个链路里最容易翻车的是第一段和第三段之间。语言模型常会“一本正经地胡说八孔”比如总数对不上、尺寸单位看错、把孔径当成半径。所以我后来在提示词里强制要求它输出结构化的JSON参数再让代码生成器基于这个JSON写建模脚本歧义一下就少了很多。1.2 为什么是现在才火起来技术成熟度分析其实“用对话生成CAD”这个概念十几年前就有科研项目在做当时靠的是规则模板遇到没见过的描述直接歇菜。现在重新火起来离不开三个变化第一大模型对代码的生成能力足够稳。CAD建模本质上是“面向几何的程序设计”代码模型恰好是大模型最擅长的领域之一它知道CQCadQuery里Workplane.circle()后面应该接extrude()不会自己瞎发明API。第二开源几何内核和Python包装层成熟了。CadQuery把OpenCASCADE的复杂底层封装成了链式调用的风格AI学起来容易跑起来也快。以前要在商业CAD里做自动化脚本API又乱又贵现在完全可以用免费的组合。第三硬件和推理成本不再是瓶颈。本地跑一个小尺寸的开源模型也能完成简单零件生成不需要每次调用都上云端遇到敏感图纸也不担心数据泄漏。这直接促成了text-to-cad从Demo走向实际工作台。2. 核心技术拆解模型选型与数据集的那些坑想做 text-to-cad先得选实现路径。我试过纯规则、端到端生成、LLM驱动代码生成三条路线各有各的脾气。下面这个表是我自己的经验总结实现路线代表方案输出形式优点缺点纯规则模板关键词匹配 参数映射脚本/模型稳定可控不依赖网络泛化极差换种说法就废端到端生成Text2CAD扩散模型、Point-EMesh/B-rep自由度高能生成异形精度低无法编辑工程价值有限LLM代码生成GPT-4 CadQuery、本地CodeLlama参数化脚本可编辑、可追溯、精度高需要做沙箱和错误重试Prompt成本高2.1 三类主流实现路径纯规则、端到端、LLM驱动纯规则模板适合固定的零件族比如只生成同一种航空插头外壳。每来一句话就用正则表达式抽取“长宽高外径内径孔数”填进预设模板。这种方案最大的问题是不具备常识你只能说“60×40×30”不能说“比上一版再加厚5mm”稍微口语化就解析失败。端到端生成是这两年论文的热门方向。研究者让深度网络直接从文本生成三维点云或体素再重建成网格。试过几个开源权重生成形状倒是够新颖但输出的是三角面片没有倒角半径的显式参数也没法在CAD里改特征树。做产品外观调研还行做零部件设计我基本不指望它。LLM驱动代码生成是当前最务实的方案。让大语言模型理解自然语言再转换成CadQuery或OpenSCAD脚本最后用几何内核执行。脚本本身是参数化的我随时能改一个数字重新生成。这条路对模型的要求不再是“知道螺栓长什么样”而是“知道怎么用代码画螺栓”后者在代码语料里实在太多了。2.2 我为什么最终选了“LLM代码生成”这条路线理由有三个可编辑性、可追溯性、可集成性。可编辑性上脚本就是源文件改个参数比在GUI里重新拉伸更直接。可追溯性上每一步都能复盘模型生成什么代码、代码干了什么出了问题日志里清清楚楚。可集成性上CadQuery的脚本本来就可以塞进Python批处理工具链比如用Python批量对CAD修改尺寸、自动导出PDF。当然这条路也有代价。大模型生成CadQuery代码时经常出现“记忆错觉”比如把radius属性写成.r()或者在一个平面对象上调用三维布尔函数。所以我必须在执行层做两层保护先做静态语法检查再在沙箱里跑最后用布尔运算和尺寸查询做验证。3. 从零搭建一套可用的 text-to-cad 工作流我建议所有想上手的人都按下面这套顺序来先搭Python环境再设计提示词模板最后套上执行和导出层。3.1 第一步设计结构化提示词把自然语言变成建模参数不要直接把用户说的话丢给模型先做一步“信息抽取”。我现在的提示词模板大概是这个思路你是一个CAD参数提取助手。请把下面的机械零件描述解析成JSON对象只输出JSON不要解释。 JSON字段包括part_type, length, width, height, outer_diameter, inner_diameter, hole_count, hole_diameter, flange_thickness, chamfer, fillet。 如果字段在描述中未出现就填null。 描述一个带法兰的圆管外径50内径40管长80法兰外径80法兰厚度6四个安装孔直径5。这一步输出的JSON会干净得多{ part_type: flanged_tube, outer_diameter: 50, inner_diameter: 40, length: 80, flange_outer_diameter: 80, flange_thickness: 6, hole_count: 4, hole_diameter: 5 }再把JSON和一段“CadQuery代码生成规则”一起交给第二层模型。规则里写死单位是毫米、必须用cq.Workplane(XY)开始、孔要用Cylinder布尔减而不是Workplane.hole、所有尺寸以变量形式声明。这样生成出来的代码基本能一次跑通。3.2 第二步让AI生成CadQuery代码而不是直接生成Mesh为什么很多AI模型默认会输出STL网格但在实际生产里STL是个“哑巴”不知道哪个面是圆柱面、哪个是平面做不了布尔运算也不能上CAM精加工。CadQuery生成的才是正经B-rep实体能导入FreeCAD继续编辑也能直接导出STEP给供应商报价。我让大模型生成的代码模板类似于import cadquery as cq outer_d 50.0 inner_d 40.0 length 80.0 flange_od 80.0 flange_thk 6.0 hole_d 5.0 tube ( cq.Workplane(XY) .circle(outer_d / 2) .extrude(length) .faces(Z) .circle(inner_d / 2) .cutThruAll() ) flange ( cq.Workplane(XY) .circle(flange_od / 2) .extrude(flange_thk) ) part tube.union(flange) for i in range(4): part ( part.faces(Z) .workplane() .polarArray(radius(flange_od outer_d) / 4, startAngle0, angle90, count4) .circle(hole_d / 2) .cutThruAll() ) cq.exporters.export(part, flanged_tube.step)你会注意到CadQuery的API是链式的每一步都返回一个新的Workplane这种风格对大模型非常友好它只要按着“画圆→拉伸→再画圆→切穿”的顺序组织代码就行。不过这段代码我做了简化真正的版本里孔径计算和孔位阵列的半径需要根据法兰外径和管外径重新算这是我踩坑后专门加进去的规则。3.3 第三步沙箱执行与文件导出AI生成的代码不能直接在你本机裸奔万一模型抽风调用了os.remove就麻烦了。我在本机用Python的subprocess拉起一个受限子进程Linux下用python3 -I隔离用户site-packages再配合resource.setrlimit限制CPU和内存在Windows上可以借助容器或虚拟机做一层保险。执行成功后导出格式我一般同时要STEP和STL。STEP给工程、给CAMSTL给3D打印预览。如果还想生成2D工程图可以加一段from cadquery import exporters shape cq.importers.importStep(flanged_tube.step) exporters.export(shape, flanged_tube.svg)SVG再转PDF或者直接塞到已有图纸里做装配示意这就和日常CAD转PDF的流程接上了。4. 实操全过程记录从“一个带法兰的圆管”到STEP文件下面记录我第一次完整跑通text-to-cad的真实过程包括我输入的文本、中间生成的JSON、AI写的CadQuery代码以及最后的验证结果。4.1 一次完整运行的输入输出实录我给的用户输入是帮我生成一个法兰管。管子外径50内径40长度80。法兰在管子一端外径80厚度6。法兰上均匀分布4个直径5的安装孔。所有单位毫米。第一层模型输出的JSON和文章开头那个基本一致。我把JSON喂给第二层提示词要求它“生成可执行的CadQuery代码不要解释不要markdown代码块标记”。它给出的代码和上面3.2节的版本差不多但因为模型常在polarArray半径上取巧第一版生成的4个孔全落在管壁中间不是法兰面上。我又加了一条硬规则“安装孔必须以法兰顶面为参考面孔中心所在圆周半径必须严格等于(flange_od / 2 outer_d / 2) / 2”。重跑之后模型终于算出正确的半径是(80/2 50/2)/2 32.5mm四个孔绕着法兰中径圆周均匀分布这才算对。最终生成的STEP文件在FreeCAD里打开特征树的显示是“一个拉伸圆柱再加一个拉伸圆环再四个布尔减”完全符合预期。4.2 生成代码讲解AI写的模型靠谱吗不能因为程序能跑就说它靠谱。那次代码我逐行检查过发现三个潜在问题特征顺序有问题先建管体再建法兰最后做孔。其实完全可以把法兰作为一个独立的特征体再和管体做union。AI这么写能跑但后期想改法兰厚度就得重新生成整段代码。单位假设很强模型默认所有数字都是毫米但这个假设必须在提示词里写死否则遇到“3cm”就会直接按3毫米建模。阵列中心位置第一次孔阵列的圆心放在了法兰顶面的圆心这没问题但因为初始workplane是从面Z创建的如果这个面碰巧是管子的顶面而不是法兰面孔的位置就会错。所以我给自己定了个规矩AI生成的代码只当草稿必须人工做“三步校验”看特征树、量关键尺寸、做布尔干涉检查。4.3 效率对比传统建模 vs text-to-cad我来做个简单对比。传统方式我用SolidWorks画同样的法兰管新建零件、选基准面、画两个同心圆、拉伸、再切四个孔熟练也得3分钟。text-to-cad从输入到拿到STEP文件跑完大约40秒其中还有一半时间花在我检查代码和重新计算孔位上。表面上只省了2分多钟但真正的价值在批量修改。客户改口说“孔径从5改到6”传统方式要进草图改四个圆再退出重新生成text-to-cad改一行JSON重新跑一次就行。如果再配合Python批量对CAD修改几十个法兰管一起改尺寸完全能做到几分钟内全量更新。5. 应用中绕不开的坑常见问题与排查技巧text-to-cad刚跑起来的时候失败率远比你想象的高。我这里记录五个我实际踩过、且细想起来有共性的坑。5.1 我实际踩过的5个典型故障故障一生成的代码直接报AttributeError最常见的错误是模型把CadQuery方法名写错比如把.cutBlind()写成.cutThroughAll()或者.polarArray()的angle参数写成了相对角度而实际API要求绝对角度。排查方法很简单先看报错堆栈再去CadQuery官方文档对照方法签名。我现在的做法是让模型在代码生成后再输出“用了哪些API”由程序比对白名单记过两次错就直接要求它重写。故障二布尔运算后模型内部有碎面两个实体union后可能因为面重合产生奇异的拓扑结构FreeCAD导出的STEP文件在其他软件里打开却报“几何错误”。根治方案是让AI在union之前把两个体用.fuse(other, tol1e-5)而不是简单的.union()小数容差给清楚能减少很多奇异面。故障三尺寸幻觉模型特别容易把“内径40”理解成“半径40”。我的对策是在JSON抽取后加一层单位计算管壁厚度(outer_d - inner_d)/2 5mm如果算出来小于0.5mm程序直接报“尺寸疑似不合理”不让它往CAD内核送。故障四孔位阵列半径计算错误像我在第4节遇到的那样AI不知道法兰孔的分布圆半径应该按中径计算而是随手给了个数字。这个只能靠提示词里的硬规则治比如“孔中心分布圆直径 (法兰外径管子外径)/2”。故障五导出STEP后中望CAD打不开不同CAD软件对STEP的解析器不完全一致有时模型用了OpenCASCADE特有的高级面转成老版本STEP格式会丢信息。我现在的导出策略是同时生成AP203和AP214两个版本兼容性大幅提升下游用AutoCAD、中望CAD、瑞丽服装CAD这类软件打开也更保险。下面这个表格可以当速查用问题现象可能原因解决办法AttributeErrorAPI名称幻觉API白名单校验、重新生成内部碎面布尔容差不当使用fuse并指定tol尺寸错了10倍半径直径混淆JSON抽取后做物理合理性检查阵列位置偏移分布圆半径错误提示词写死半径公式STEP打不开版本不兼容同时导出AP203/AP2145.2 质量校验三板斧可视化、尺寸检查、布尔运算验证我每生成一个零件都会做这三步。可视化是最直观的把STEP导回FreeCAD转成显示模型用剖视图看一眼有没有“穿帮”的地方。尺寸检查是用程序查询边界框和关键面距离。CadQuery里可以这样bb part.val().BoundingBox() assert abs(bb.xlen - 80) 1e-5 assert abs(bb.zlen - max(80, flange_thk)) 1e-5为什么是max(80, flange_thk)因为法兰厚度6mm叠加在管长方向上最终总高是80还是86这个细节要看法兰放在哪个端面AI经常在这里含糊。所以程序校验时不能只看总体尺寸还得单独查询法兰外圆柱面是否存在。布尔运算验证是最后一道防线把成品和一个标准圆柱做“求交”看结果是否符合理论体积。比如法兰管的理论总体积 管体积 法兰盘体积 - 4孔体积程序算一遍再和STEP文件里查询的Volume()对比误差超过0.1%就判定建模失败。6. 进阶扩展从单零件到装配体和图纸单零件能生成只是第一步要把text-to-cad用进实际流程还得往装配、出图和批量管理方向走。6.1 把text-to-cad接入现有CAD工作流我在本地搭了一个简化流程text-to-cad生成STEP后自动调入FreeCAD的装配工作台和其他标准件做配合约束。约束关系也可以用Python写死import FreeCAD as App import Assembly assembly App.ActiveDocument assembly.addObject(Part::Feature, FlangedTube) assembly.getObject(FlangedTube).Shape part.shape对于已经有AutoCAD图纸的环境生成的STEP可以导入到布局空间里再用AutoCAD自带的发布功能转PDF。这一步直接把“生成模型”和“编制造图文件”连在一起省去了手工重新画三视图的功夫。如果想把多个零件合并到一个文件里也可以把多个STEP实体导入同一个FreeCAD文档再用Python统一设置颜色、图层最后导出成一个多实体STEP相当于自动“图纸合并”。以后再配合Blender或CAD查看器线上评审就变得很轻量。6.2 注意法律合规与版权问题用text-to-cad生成几何模型本身没有版权争议但要小心两件事。第一私有训练数据的泄漏如果你在公司内部用云端大模型生成代码等于把设计参数发给第三方。对于高压容器、军工件这类敏感零件我建议改用本地开源模型跑代码生成或至少做脱敏处理把真实尺寸先做归一化再输入。第二不要直接生成别人专利中的外观形状。text-to-cad可以按描述生成但如果描述来自某个受保护的产品那生成结果仍然可能构成侵权。模型不懂法律使用者得懂。从长远看我把text-to-cad当成一个“设计意图编译器”它没有替代工程师只是把重复的建模动作压缩了。以后如果继续扩展我打算把生成的零件按照参数类型自动分类做成本地可检索的“参数化零件库”下游再需要类似结构时连文字都不用写直接按参数组调用。最后分享一点个人经验我在实际使用中最深的体会是text-to-cad的成败不取决于模型有多聪明而取决于你有没有把工程约束写进提示词和执行层。AI负责“把话翻译成代码”你负责“把代码翻译成真理”。所以别指望输入一句话就拿到完美零件正确的姿势是让AI出草稿你出规范两者合成才能进车间。另外CadQuery这套库本身值得花一个下午熟悉它会让你理解程序化建模和鼠标画图的本质区别。最后的小技巧所有尺寸参数都集中写在代码头部哪怕AI生成的代码只有这一段是正确后面全是垃圾你也只需要改头部就能重新输出。这是我跑了几百次后觉得最实用的一条经验。