做CAD自动化这个方向快十年最近被问得最多的就是text-to-cad。很多人一听说“用文字生成CAD模型”第一反应是“这不就是给stable diffusion换了个壳嘛”。真不是。我在本地环境把这一套流程完整跑过一遍之后最大的感受是text-to-cad的难点完全不在“文字理解”而在“CAD语义的几何落地”。它输出的不该是一张漂亮的渲染图而是一个真正能进加工厂、能装配、能出工程图的实体模型。这篇内容就是给想入坑的机械设计师、相关专业学生和准备做二次集成的开发者准备的我会把技术原理、可跑通的实操流程、参数调优思路和踩坑记录一次性讲透。1. 别把text-to-cad当成文字生图来玩这个赛道到底在生成什么1.1 从“文字生图”到“文字生模型”差的不只是维度文字生图本质上是像素分布的概率生成模型的任务是让颜色块在二维平面上看起来合理即使某个细节不符合物理规律只要视觉上“像”就行。但CAD模型是另一套评价体系几何必须闭合、边缘必须连续、孔位必须有实际直径、圆角必须能加工出来。一句话文字生图追求的是观看体验text-to-cad追求的是制造语义。我在刚开始接触这个方向时也走过弯路拿生成图片的思路去评估生成的三维模型结果发现完全没法用。因为CAD模型落到工业流程里最终是要导出成STEP格式进CAM软件或者转成工程图标注尺寸公差的。如果一个模型只是“长得像那么回事”曲面之间有空隙、实体边界互相穿插到了加工阶段就是废品。所以对text-to-cad的第一层认知必须是它不是3D版的文生图而是“自然语言直接翻译成可编辑、可制造的三维实体描述”。这个描述可以是参数化特征树也可以是带约束的边界表示B-Rep绝不是单纯的一层三角网格。1.2 机械零件、概念外形、可装配模型三类典型目标从实际需求来看text-to-cad按输出目标大致能分成三类每一类对技术方案的要求差异很大。第一类是机械零件级生成典型输入是“带法兰的轴套外径60mm内径25mm长度40mm均布4个M6螺纹孔”。这类目标是当前技术最成熟、也是最有实际价值的场景。它对应的是参数化特征建模底层特征基本就是拉伸、旋转、倒角、孔、螺纹这类基础操作模型只要能把特征序列生成对再结合数值控制结果就非常可靠。第二类是概念外形生成典型输入是“流线型的鼠标外壳”“具有有机曲面形态的灯具壳体”。这类目标看重外观建模方式偏向自由曲面和网格生成难度在于没有明确的参数边界。现在很多做工业设计概念探索的团队在试这个方向先把文本转成概念网格再在CAD软件里做曲面重建。第三类是装配级生成输入的复杂度直接上一个台阶比如“一个由底座、立柱和滑块组成的简易冲压模架”。这要求模型不仅要生成三个独立零件还要理解零件之间的装配关系、配合尺寸和相对位置。目前这个方向还处于早期探索阶段能跑的方案基本都是“先生成单体再用规则去拼装”距离真正的端到端还有不少距离。1.3 为什么“能画图”和“能生成CAD”是两码事很多人看到某些工具的演示视频觉得已经有产品级效果了但实际部署下来会发现演示案例都是精心挑选过的。真正复杂的工业零件比如带有拔模斜度、渐变壁厚、多基准面定位特征的注塑件现有的生成模型往往直接崩溃。核心原因在于CAD建模的本质是“记录建造过程”而不是“记录最终形态”。同一个法兰盘可以通过拉伸一个盘体再打孔得到也可以通过旋转一个截面再打孔得到。两条路径生成的几何在视觉上可能完全一致但特征树不同后续修改能力天差地别。当前大模型和扩散模型擅长的都是“结果分布”而不是“过程推导”。所以现阶段text-to-cad的落地方式几乎都是把自然语言转化为可执行的参数化程序然后交由传统CAD内核去重建实体这条路比端到端神经网络靠谱得多。2. 核心技术栈拆解从零开始理解text-to-cad的实现原理2.1 文本编码不是简单分词为什么要用CLIP或BERT做条件注入text-to-cad的第一步是让模型理解输入文本。这里的理解绝对不只是分词加词向量而是要抓住实体类型、尺寸数值、拓扑关系、特征操作顺序这些CAD专属语义。现在常用的文本编码器中CLIP擅长图文对齐但它在CAD这类精确数值任务上表现一般因为CLIP训练时面对的是自然图片对“直径36.5mm”这种精确数值非常迟钝。相对而言BERT、RoBERTa这一类经过MLM预训练的模型在处理带数字的工程描述时效果更稳。我实测下来把文本送入BERT得到768维向量再通过cross-attention注入生成网络比直接拼接嵌入向量的效果要好很多因为cross-attention能让模型在不同生成阶段动态关注文本的不同部分。还有一个文本工程细节很多教程不会提在输入中加入结构化的前缀模板能显著提升解析准确率。比如把“外径80 内孔36 四个均布螺栓孔”改成“类型:法兰盘;外形:圆形盘体;主尺寸:外径80mm,内孔36mm;特征:4个均布螺栓孔,直径8mm;”模型对参数的提取准确率能提升一大截。这个现象背后的原因也很好理解模型见过大量“键值对”式的机械手册文本结构化描述接近它的训练分布。2.2 三维表达能力对比点云、体素、网格、参数化B-Rep生成三维数据有几种主流表示方式每种都有明显的取舍。点云数据获取容易神经网络处理方便但点云本身不携带拓扑信息如果要转成实体模型还得额外做表面重建重建精度一旦不够就会出现壁厚不均、闭合失败。体素是三维的像素网格规则数据非常适合CNN和Transformer处理但内存开销随分辨率指数增长。256体素的网格已经需要好几个GB的显存要表达工业零件的薄壁特征和精细倒角体素分辨率至少要512起步这在当前硬件上非常吃力。网格是由三角面片组成的表面表示比体素轻很多对渲染友好但它仍然是“表面近似”一个看似平滑的圆柱面在网格状态下其实是成百上千个三角形拼出来的。如果直接拿网格去加工刀具路径会极度不平滑。最后是参数化B-Rep这是CAD真正的内核语言。一段拉伸特征从草图轮廓开始通过指定深度、拔模角、布尔运算生成精确的解析几何表面。这种表示的数据结构复杂难以直接用神经网络输出但它才是制造业真正认的东西。所以现在业界的主流思路是“两段论”神经网络生成参数化特征序列或程序再通过内核引擎完成B-Rep构建。这也是我要在实操部分重点展开的路线。2.3 生成模型选型扩散模型、自回归、条件VAE的优劣势这几种生成模型在text-to-cad里都有应用但侧重点完全不同。扩散模型当前最热它通过逐步去噪从随机噪声恢复出目标数据分布在三维网格和点云生成上表现出了极强的细节还原能力尤其适合自由曲面这种没有明确规律可循的形态。它的缺点是可控性差要精确生成“直径25mm的通孔”非常难而且采样速度慢生成一个模型动辄十几秒到数分钟。自回归模型最有代表性的是把CAD建模当作“下一个token预测”来处理。一个CAD文件被编码成草图指令序列和拉伸布尔操作序列然后模型像生成自然语言一样逐token生成。这种方案的优点是天然贴合参数化特征树结果可以直接在CAD软件里编辑可解释性强。缺点是序列一长就容易累积误差一个token偏了后续特征全部错位。这也是为什么它会先做草图轮廓再拉伸降低单步预测的压力。条件VAE的思路是把文本编码成隐向量再解码为三维结构训练稳定且推断快。但隐向量空间能承载的信息量有限生成的模型容易失真细节模糊。对于追求高效率的低保真预演场景可以选它否则还是优先考虑前两者。从工业落地的稳定度排序我个人看法是自回归特征序列先跑通扩散模型用来补足自由曲面VAE作为快速入口。现阶段把自己锁死在任何一个模型上都是不明智的。3. 实操干货手把手跑通一个本地text-to-cad流程3.1 环境与依赖准备在动手之前先把环境说清楚。纯CPU跑端到端模型基本不现实即使是很小的参数化自回归模型训练阶段没有GPU也很难推进。我这里给出的是一套已经被验证过的基础环境适合在单机单卡上做推理和微调。操作系统建议Ubuntu 20.04或22.04显卡优先选择NVIDIA系显存不低于12GB。RTX 4070Ti和RTX 4080都能勉强跑中等规模的模型但如果你要尝试扩散类方案建议直接上24GB显存的RTX 4090。软件环境方面Python版本用3.9或3.10PyTorch版本建议2.0以上并搭配对应版本的CUDA11.8或12.1。如果只是推理CUDA计算能力不是决定性因素但显存是。还需要装几个关键库trimesh用于网格加载和偏移处理open3d用于可视化和点云操作cadquery负责参数化实体构建numpy和scipy处理数值。用cadquery的时候要注意它依赖OCPOpenCascade Python Wrapper安装时建议直接用conda创建一个新环境避免和系统级的OpenCascade版本冲突。这里再强调一点不要用pip强行把所有包塞进base环境CAD相关库的依赖树非常容易出幺蛾子我在这上面吃过亏。3.2 文本解析与参数化特征生成的落地示例端到端模型目前还难以直接投放到生产环境所以我建议大家在本地先跑通一套工程可用的pipeline文本解析 - 参数提取 - 特征程序生成 - CAD内核构建实体。这套方案用到的每一环都是成熟技术虽然不如端到端模型“炫”但胜在稳定可控。文本解析这一步可以先用大模型做信息抽取而不是让模型直接输出几何。比如用户输入“M8内六角圆柱头螺钉头部直径13mm头部高度8mm螺纹长度20mm”大模型的任务是把它转成结构化的JSON字段{ type: screw, head_diameter: 13.0, head_height: 8.0, thread_length: 20.0, thread_type: M8 }拿到这个JSON再写一个参数化脚本用cadquery完成实体建模。下面这段代码是一个典型示例生成一个带中心孔的法兰盘import cadquery as cq def make_flange(outer_d, inner_d, thickness, hole_count, hole_d): disc ( cq.Workplane(XY) .circle(outer_d / 2.0) .extrude(thickness) ) disc disc.faces(Z).workplane().hole(inner_d) disc ( disc.faces(Z) .workplane() .rect(outer_d * 0.8, outer_d * 0.8) .vertices() .hole(hole_d) ) return disc flange make_flange(outer_d80.0, inner_d36.0, thickness10.0, hole_count4, hole_d8.0) cq.exporters.export(flange, flange.step)这段代码里最关键的是把“均布四个孔”转成cadquery的顶点孔操作它之所以能自动均布是因为在工作平面上绘制了与外圈同中心的方形并取四个顶点定位。这种“构建草图参考”的做法是参数化建模的精髓几何约束通过参考线落在草图里而不是硬编码四个坐标点。如果硬编码坐标孔的位置在修改外径后就会失配。pipeline再往后延伸可以把JSON参数绑定到一组预设的模板脚本上形成一个小型零件库。用户输入的自然语言命中某个模板后系统自动加载对应的脚本模板填入参数后生成模型。这个思路就是现在所谓“AI辅助设计”类工具背后的实际架构没什么魔法胜在工程可靠。3.3 prompt编写与参数调节的实战经验prompt对text-to-cad的影响比做文生图时还要敏感。因为在图像生成里模型有较大的容错余地描述偏差一点还能出个风格相近的图但CAD生成中一个数字错了整个零件就废了。我总结了几个最实用的prompt编写原则。第一固定格式比自然语言更稳。上面提到过的“类型:…;外形:…;主尺寸:…;特征:…”模板在多次测试中都优于“帮我设计一个圆形的法兰”这种写法因为它给模型提供了清晰的字段槽位。第二明确单位和基准面。同一个“长50宽30高20”用户可以指厘米也可以指毫米模型如果默认毫米而用户想的是厘米尺寸就差了十倍。在prompt里强制加“单位:毫米”和“主视图基准面:XY”能大幅减少这类风险。第三避免触发歧义的描述词。“中间打一个孔”到底是中心盲孔还是通孔“均匀分布六个螺丝孔”是沿圆周分布还是沿矩形边分布最可靠的做法是在prompt中直接给出阵列方式和参考位置例如“六个孔沿直径70mm的圆周均布”。除了prompt文本生成模型的参数也很关键。如果用的是扩散类生成器采样步数太少会出现表面噪声步数太多则耗时剧增。一般取50到100步之间比较稳妥。Classifier-Free Guidance的尺度控制在7.5到12之间太大容易导致几何过度锐化出现尖刺、薄壁这类不可加工特征。如果是自回归模型温度参数建议从0.8开始调温度过低会退化成重复的特征序列温度过高则生成出毫无逻辑的随机特征。4. 降伏生成结果后处理、尺寸检查与CAD封装4.1 生成模型的“手抖”问题为什么会输出不闭合或不规则曲面无论模型多强生成结果总会出现“手抖”一样的几何缺陷这在CAD领域是不可接受的。最常见的三种问题第一网格模型表面出现非流形边即一条边被三个或更多三角形共享第二模型表面有孔洞或悬空顶点实体无法水密闭合第三细小特征断裂比如筋板的根部没有和主体相连。这些问题根本原因是神经网络的输出本质上是离散采样的近似它没有“几何必须连续”这种物理约束。即便是扩散模型在去噪后期也无法完全消除采样点之间的拓扑矛盾。传统CAD内核没有这种问题是因为它的曲面由解析几何严格定义但神经网络输出的是数值化顶点坐标天然存在数值误差。要解决这类问题一方面在生成阶段使用约束扩散或者鉴别器增加拓扑正确性约束但工程上更直接的做法是放在后处理阶段用网格修复算法解决。trimesh库在这方面很顺手它能检测非流形边、修复倒置法线、填补孔洞下面这段代码可以做基础修复import trimesh mesh trimesh.load(output_mesh.ply) # 移除重复顶点 mesh.update_vertices(mesh.unique_vertices()) # 修复法线方向 mesh.fix_normals() # 填充简单孔洞 mesh.fill_holes() mesh.export(repaired_mesh.stl)4.2 模型修正流程实体化、壁厚检查与装配环境验证网格修复只是第一步真正进入CAD环境时还要做实体化。STL网格必须转换成可编辑的实体即B-Rep这一步难度不低。简化处理方法是用FreeCAD或cadquery的网格转实体工具通过“从网格构建形状”来生成面再缝合成实体。不过自动缝合在复杂模型上经常失败需要人工干预。壁厚检查也是至关重要的一环。注塑件、壳体件对壁厚有严格的下限要求生成模型如果给出0.1mm壁厚加工时根本没有刀具能稳定成型。建议用数值化的方式检测先求模型实体的最小厚度。在OpenCascade里可以借助距离变换法或者对多组剖面做内切圆检测简单一点的办法是用射线检测从外表面射向内表面记录穿过的介质距离。装配环境验证更花时间。单个零件生成得很好不代表装配后没有问题常见的坑包括轴孔配合尺寸正负号设计反了、装配基准面没有对齐、螺栓孔与螺纹孔位置偏移零点几毫米。在本地验证时我习惯把所有生成的零件导入同一个装配环境手动添加配合约束观察是否出现过约束或欠约束。这套流程自动化程度还很低但能拦住绝大部分“看着漂亮装不上”的问题。4.3 导出格式STL、STEP、IGES的分工与选择很多新手在最后导出环节犯懵不知道该存成什么格式。这要分场景来看。STL是三角网格格式只有表面几何没有任何拓扑和参数信息。适合3D打印、快速原型、有限元分析的前处理但不适合直接用于数控加工和二次修改。如果一个模型后续还需要改尺寸别用STL作为交付格式不然只能从头建模。STEP是当前工业数据交换的核心格式支持完整B-Rep实体能保留精确几何和部分拓扑信息可以被主流CAD软件原生读取。只要涉及机械加工、出图、装配一律首选STEP。IGES是更老的格式处理样条曲面和复杂曲面时有过一定优势但现代CAD系统对STEP的支持明显更好。现在只有在对接一些老旧系统或特殊曲面定义时才需要额外导出IGES。总之一条经验网格用STL实体用STEP特殊情况才考虑IGES。5. 常见问题与排查技巧实录5.1 运行期报错整理与对策实际跑起来会撞上不少报错我把遇到最多的列成一张速查表报错现象常见原因对策CUDA out of memory输入分辨率过高或batch size过大把体素分辨率从256降到128关掉并行数据增强OCC版本引发的cadquery导入失败python包和OpenCascade链接库版本错位用conda创建独立环境并安装匹配的OCP版本生成模型无法连接文本提示词文本编码器与生成网络维度不匹配检查cross-attention层投影维度是否对齐输出网格存在非流形边采样点数不足或后处理缺失增加采样点并用trimesh修复STEP文件导入CAD显示“面丢失”网格转换时磨光不完整降低网格转实体的公差参数并打开缝补选项显存不足是最容易在开始时踩的问题特别是不理解显存占用机制的用户。体素模型四倍分辨率会带来约64倍的显存增长而网络参数本身的增长反而不起决定作用。所以遇到OOM优先降输入分辨率再尝试做梯度累积或混合精度。5.2 生成质量低下的调优方向生成结果质量差不要盲目调一大堆参数先确认问题出在哪一层。我的排查顺序是文本解析是否正确 - 条件注入是否生效 - 生成模型是否收敛 - 后处理是否破坏了拓扑。文本解析如果失败任何生成模型喂进去都是垃圾。可以在输入输出之间加一层可视化把解析出来的JSON字段打印出来看一眼。“直径”被识别成“半径”、“M8”被识别成普通孔这类错误直接改prompt或做正则兜底更有效。如果文本解析正常但几何质量仍然差就要考虑采样温度、步数和引导权重。在自回归模型里温度过高会出现多余的特征令牌。在扩散模型里引导权重过高容易出现壁厚不均。每次只调一个参数记录结果不要同时改多个否则根本分不清楚是哪个参数导致的。我做过一次实验同样的文本描述温度从0.6调到1.0生成的零件特征数量直接多了三分之一出现了大量原本不存在的小圆角。这类问题必须通过参数回归实验来校准不能凭感觉。5.3 显存占用与控制技巧显存控制是text-to-cad本地部署绕不开的关卡。即便不使用体素基于点云的扩散模型在生成1024个点附近的形状时占用也有好几GB因为网络中间层的特征图数量非常庞大。几个有效的控制手段第一开启AMP混合精度把FP32降到FP16显存几乎减半精度损失在CAD草图和简单形体生成上基本可忽略。第二限制batch size推理阶段一次只处理一个样本训练阶段用梯度累积模拟大batch。第三及时释放中间变量很多框架里在循环中反复调用生成器旧的计算图不释放导致峰值显存翻倍。如果用了PyTorch建议在每个推理循环结束后调用torch.cuda.empty_cache()同时用with torch.no_grad():包住整个推断过程。6. 扩展方向与个人体会6.1 从单体生成到装配体与多模态输入text-to-cad的下一个明显趋势是装配体生成。现在的单体生成已经有不少能落地的案例但工业设计永远不是零件堆砌。装配体生成要求模型具备坐标系对齐、尺寸链约束和配合关系建模能力这些问题在生成领域还很难处理成标准的概率分布。多模态输入也是一个值得关注的方向。用户一边画草图一边说“这个孔再大一点”系统同时理解图像和语音很容易比纯文本更精确。我在实际测试中发现同一个零件加一张参考草图之后生成结果的尺寸漂移率明显下降。这说明文本在几何细节表达上天然有局限多模态互补应该是以后的方向。6.2 我在实际使用中积累的三个判断第一条判断不要追求一次生成直接可用。当前技术大概率做不到强行追求端到端只会让自己陷入“为了AI而AI”的泥潭。合理的姿态是让text-to-cad承担“初级方案生成器”的角色生成出来之后由设计师做参数调整和拓扑优化。第二条判断数据质量比模型架构更重要。自回归类text-to-cad模型的性能上限其实是被CAD特征序列数据的规模和多样性决定的而不是被注意力的层数决定的。如果准备进入这个领域先把精力用在做数据清洗和特征序列规范化上收益比换一个更大的骨干网络高得多。第三条判断可解释性比玄学更重要。如果系统输出一个特征设计师应该能清楚地知道它为什么出现在这里对应文本里的哪个词。一旦做不到这一点它在真正的工业流程里就很难被信任。为每一个生成的参数和特征保留日志并且能映射回原始prompt这是我目前认为text-to-cad能被规模化应用最重要的前提。这行当远没有到成熟的阶段但正是这种“差一点就能用”的状态反而让人觉得值得折腾。我自己的体会是不要被演示视频的酷炫效果带偏盯住“能否进CAM、能否出图、能否被修改”这三个工程标准方向就不会错。最后再分享一个小技巧每次跑批之前先把全部prompt过一遍文本解析管线把解析结果打印成JSON肉眼扫一眼再进生成环节这个习惯帮我省下了大量无效算力。
