把一句自然语言变成可编辑的CAD模型——这个需求我在过去两个项目里都实打实撞上过。机械那边同事问能不能输入“直径30mm的圆盘中心开直径8mm的通孔”直接生成模型做方案评审的客户也提过类似想法。传统参数化建模得手动选草图平面、画约束、拉伸切除而从一句话到完整模型中间隔着的其实是语义空间到几何表示空间的鸿沟。text-to-cad这个方向要解决的就是这个事让大模型听懂设计意图再把它转成CAD软件能打开、能编辑、能继续改参数的模型文件。这个方向最近一两年的进展真的很快。从早期只能出体素、出mesh的粗糙结果到现在能生成带参数化特征树的步骤序列变化可以说是质的。这篇文章我会把text-to-cad从原理到实操拆开讲清楚包括技术路线选型、数据怎么处理、模型怎么训、推理时有哪些坑以及怎么把生成结果导入到CAD里验证。适合正在做AIGC方向、或者想在企业内部做智能化设计工具的朋友参考也适合那些刚接触这个方向、想评估“值不值得投入”的人。1. 从“会听”到“会画”text-to-cad到底在解决什么问题1.1 为什么现在的AI建模工具都卡在“翻译”这一步先说结论问题不在“生成”而在“表示”。这俩词听起来差不多区别非常大。文本生成图像之所以在2022年后爆发式增长核心原因是图像可以用像素网格表示扩散模型的输出是一个固定尺寸的二维矩阵连续性很好误差一点点在视觉上也能接受。可CAD模型不是像素网格它是边界表示、是特征树、是带约束的草图。我举个具体例子。一张图片里画一个圆像素半径差一两个点人眼基本看不出来。但在CAD里一个直径30mm的圆盘你给生成成29.5mm这就不是“看不看得出来”的问题而是直接没法用因为整个装配体、加工路径全基于这个尺寸。误差是毫米级、微米级的问题不是一个“像不像”的问题。所以text-to-cad真正困难的点在于模型输出的表示形式必须足够精确同时还得保留参数化语义。你生成的不只是一堆三角形面片而是一个可以继续修改的草图平面、拉伸深度、布尔运算顺序。这就导致最朴素的“文本扩散模型直接生成几何”的方案在工程界基本走不通因为结果要么是网格要么是隐式场拿来摆个造型可以拉到CAM里做加工路径就是灾难。这也是为什么这个方向的研究路线会分化成两大类下面展开说。1.2 两条技术路线序列生成与几何生成目前text-to-cad的学术和工程探索主要有两条路线一条叫序列生成一条叫几何生成。各有各的拥趸但说到底它们对“CAD模型是什么”这件事的假设不同。序列生成路线把CAD建模看作一个程序或操作序列。一个零件的建模过程可以分解为“创建草图-在草图平面上画圆-拉伸-在中心画小圆-拉伸切除-倒角”等一系列指令。只要模型能输出正确的指令序列就能用CAD内核一步步执行生成可编辑的真实模型。代表性工作就是Text2CAD和基于DeepCAD改进的一系列模型用大语言模型把自然语言直接翻译成“CAD操作程序”。几何生成路线则更激进直接用神经网络生成几何形状。比如在体素空间或点云上做生成再用后处理算法提取边界、拟合曲面。这个路径的优点是形状自由度更高理论上能表达任意复杂的曲面缺点是精度很难达到工程标准拟合出来的曲面要么不光滑要么偏差大而且输出结果基本不具备参数化信息。修模成本比从头画一个还高所以在实际工程场景里用得很少。我个人的判断是短期内能落地的必然是序列生成路线。因为它天然复用了CAD内核的精度模型只需要保证语义和操作顺序正确而几何精度由内核自己保证。这就像让模型写代码而不让它自己算加减法——加减法由编译器搞定模型的压力小得多。2. 核心技术点拆解文本到CAD模型的完整链路2.1 数据从哪来自然语言描述与参数化模型配对的瓶颈如果想稳妥圈定text-to-cad这个方向第一步就得认清数据现状。深度学习领域有句老话叫“有多少数据就有多少智能”在text-to-cad上体现得特别明显。普通图像数据集好找爬虫随便抓几千万张图就有。CAD数据完全是另一回事。一方面真实工业模型涉及公司机密车企、芯片设备商手里的模型不会开源另一方面那些模型即使给你也未必有配套的自然语言描述——很多企业内部的三维模型连命名都是乱的。目前学术圈常用的公开数据源就那几个ABC数据集、Fusion 360 Gallery dataset、DeepCAD dataset。ABC数据集是参数化CAD模型的大规模集合用来做几何学习很好用但它本身没有文字描述Fusion 360 Gallery dataset有建模操作序列也有部分用户描述DeepCAD dataset则把Fusion 360的序列数据清洗过一轮把建模步骤导出成了一种类似代码的紧凑表示。麻烦的地方在于“文本-模型”配对。要让模型学会从自然语言到操作序列的映射光有模型和序列还不够文本从哪来早期工作用模板自动生成比如“创建一个半径为X的圆柱高度为Y”好处是便宜、可控坏处是语言表达太单一。后来Text2CAD专门花了很大力气做人工标注和半自动扩充才让模型的泛化性有一点提升。如果你要自己搞我建议不要一上来就自己采数据先把公开数据集跑一遍再根据你的垂直领域微调。比如做机械零件的可以在文本模板上做术语替换和句式扩充把“打一个沉孔”这类行业说法加进去。这一步性价比远高于从零标注。2.2 模型怎么设计把自然语言“翻译”成CAD建模指令搞清楚了数据再来看模型结构。目前text-to-cad主流的框架基本是“多模态编码器-序列生成器-语法约束解码器”三段式。编码器负责把自然语言变成向量。可以直接用T5、LLaMA这类预训练语言模型也可以是一个独立的BERT类编码器。在实践中我更倾向于直接用更大的生成式语言模型而不是只取编码部分因为后期如果想做多轮对话式的建模用户说“左边再开个孔”模型在已有模型上继续改生成式模型天然更合适。序列生成器是核心。DeeplCAD那套思路是用Transformer解码器逐token输出建模指令Text2CAD则进一步把语言模型的输出约束到合法的CAD操作序列上。这一步非常关键——Transformer在生成时对token概率做采样很容易产出非法的结构比如拉伸一个不存在的草图、引用了未定义的坐标系、边界值超出了参数范围等等。所以必须用语法约束解码类似constrained decoding每一步只能从合法的操作集合里挑。还有一个细节值得注意操作序列的表示设计。好的表示要同时考虑紧凑性和可学习性。如果每个操作都存成庞大多层嵌套自回归模型不太容易学得动如果过于压缩又可能丢失关键参数。DeepCAD那套用了向量化表示把草图图元、约束、尺寸、拉伸、布尔操作全部编码成定长向量每个零件有固定数量的操作每个操作有固定字段。这个方案的好处是数据规整适合做batch训练和精度评估。我实际操作中体会比较深的一点是CAD序列不是自然语言序列它对规范性的要求极高。自然语言里你预测错一个词读者可能靠上下文猜出来CAD操作序列里预测错一个字段整个后续操作全部崩盘。因为这种级联性推理时往往需要加beam search而不是单纯贪心解码。2.3 坐标系、单位和约束那些容易被忽略的“脏细节”很多人第一次跑text-to-cad模型生成出来的东西看着还行一导入CAD就发现单位不对、坐标全跑偏、草图欠约束。这些问题不是模型架构的错而在数据预处理阶段就埋下了。第一个坑是单位。ABC数据集里很多模型的单位并不统一有的用毫米有的用英寸有的干脆是无量纲相对坐标。如果你的模型训练时混了这些数据网络学出来的语义是“30就是30无所谓单位”那生成的结果自然随机。处理办法是在预处理阶段统一缩放要么全部归一化到[-1,1]要么全部转换到毫米并保留真实尺寸。从工程使用角度我强烈建议保留真实尺寸因为下游要加工装配相对坐标意义不大。第二个坑是坐标系。CAD模型里的坐标系有全局和局部之分草图平面有自己的局部坐标系特征操作引用的是局部坐标。如果序列表示里不区分坐标系模型会把所有坐标混在一起学出现“拉伸方向横七竖八”的诡异结果。好的实践是把每个操作涉及的坐标显式标注它所属的坐标系并在训练时通过数据增强随机旋转全局坐标系逼着模型学会相对关系而不是死记绝对坐标。第三个坑是约束。真实CAD模型里草图是会带约束的比如两条线平行、两个圆同心。自动导出的操作序列往往丢掉了这些约束信息只保留了最终几何。这带来一个问题模型学到的其实是“画一个最终的形状”而不是“如何用合理的约束去控制形状”。后果是生成结果虽然几何上正确但草图的自由度乱来用户想改一个尺寸整个形状就变形。这个问题目前公开数据集基本都没解决属于已知痛点。现实的做法是生成后导入CAD用自动约束求解或手工补约束。3. 实操在本地跑通一个text-to-CAD流程3.1 环境准备与依赖安装这一节我基于自己在项目里实际跑过的流程来写参考的是Text2CAD和DeepCAD的公开方案不同的模型仓库细节略有差别但大框架是通用的。你如果跟着做建议用一台显存24GB以上的GPU机器因为序列模型的batch和序列长度对显存要求不低。内存至少32GB起步数据集解压之后很占空间建议预留200GB以上磁盘。基础环境就是这三板斧Python 3.10、PyTorch 2.x带CUDA、HuggingFace transformers库。其他辅助库包括numpy、tqdm、tensorboard、trimesh。如果是处理STEP/IGES格式还需要pythonocc-core这个包pip直接装经常失败我后来是从conda-forge渠道装的稳定很多。conda create -n text2cad python3.10 -y conda activate text2cad conda install -c conda-forge pythonocc-core -y pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install transformers datasets tensorboard trimesh numpy tqdm装完之后建议立刻跑一个小的渲染测试确认OpenCASCADE的OCC库能正常加载。这一步能提前暴露几十个“看起来装了其实没装好”的问题。3.2 数据准备与预处理从原始STEP到训练token拿到公开数据集之后原始文件通常是STEP或JSON描述建模历史这些不能直接喂给Transformer。我建议把预处理管线拆成三步第一步从模型中提取“建模操作序列”。如果你用的是Fusion 360 Gallery datasetJSON建模范式里已经有操作步骤但需要做清洗合并。比如有些模型的建模历史里有非常多琐碎的移动和视图操作这些都是噪声要过滤掉。我只保留三类核心操作草图创建、拉伸/切割、布尔运算。这三类基本覆盖了90%以上的机械零件表达。第二步序列序列化。所有操作转成定长token序列。以拉伸为例需要编码的信息包括草图平面索引、草图上的图元类型与坐标、拉伸方向、拉伸距离、布尔类型。这一步特别讲究字段顺序要设计成模型容易学的那种结构比如把固定长度的几何参数放在前面、把布尔等语义参数放后面。调试时我习惯打印十几条token序列人工检查确认每个字段的对应位置都没偏。第三步文本描述构建。公开数据里如果自带文本就用没有的话只能从模板扩展到半自动配文。我在项目里用的是术语词典替换法——基础模板“创建一个半径为X的圆柱”替换“创建”为“生成”“画一个”“半径为X”为“直径X”“圆柱”为“圆形凸台”再随机组合句式。虽然不如人工标注自然但在资源有限的情况下已经够用。3.3 训练与推理参数配置和避坑经验训练阶段有两个超参数最影响最终效果一个是序列长度一个是temperature。序列长度决定了模型能处理的建模复杂度。设得太短会截断复杂模型的操作序列设得太长训练开销大而且注意力机制容易发散。我的经验是通用零件用128到256如果专注做复杂结构件可以到512以上。temperature则直接影响生成的多样性和可靠性。这个参数在生成阶段用训练时不涉及。如果你要的是“能用的零件”temperature设0.2到0.4之间低一点更稳定如果你在跑实验、看模型的泛化能力可以调到0.8以上看看发散程度。过低温度会带来重复生成问题同一个步骤反复输出我项目里最大批量出现过连续12个token都是一样的数值。推理时还有一个我踩过多次的坑beam search的beam size。Text-to-CAD和普通自然语言生成不太一样beam size太大会导致不同的beam候选之间高度雷同因为他们共享了前面大部分token只在最后几个参数上微调浪费算力。我用的时候beam size5到10之间就够了再大没有明显收益反而会把每个序列的基础生成时间拉长几倍。输出验证是推理流程里必须做的一步。模型生成的是token序列得先反序列化成建模操作然后调用CAD内核执行这些操作如果某个操作引用了不存在的草图整个序列就会报废。我建议写一个脚本对每个候选序列做执行合法性检查发现非法参数就直接杀掉这个候选而不是等渲染出来再发现。3.4 把生成结果导出STEP并在CAD里打开验证生成完成后最关键的验证步骤是导入真实CAD环境看可编辑性。这一步很多人图省事直接用trimesh看渲染图我强烈不建议——渲染图只能看出“形状像不像”完全看不出“可不可编辑”。正确做法是把操作序列交给OpenCASCADE逐个执行生成B-Rep实体再导出为STEP文件然后导入SolidWorks、FreeCAD或Fusion 360里。你可以尝试修改某个草图的尺寸值如果模型能跟随变化说明参数化关系保留得好如果一改尺寸整个模型撕裂说明数据里丢约束的问题在模型上也复现了。这里给一个用pythonocc导出STEP的参考片段from OCC.Core.STEPControl import STEPControl_Writer, STEPControl_AsIs from OCC.Core.TopoDS import TopoDS_Shape def export_step(shape: TopoDS_Shape, output_path: str): writer STEPControl_Writer() writer.Transfer(shape, STEPControl_AsIs) writer.Write(output_path)在实际项目里这一步跑完之后我会再做一个工业级检查项列表边长是否精确等于设计值拉伸方向是否正确零件是否封闭成实体watertight布尔运算是否生成了多余的碎片面这些都是模型token序列里看不出来的只有CAD内核执行时才会暴露。4. 常见问题与排查技巧实录4.1 七类高频问题速查手册我在实际调模型的过程中整理了下面这张问题对照表各位可以直接拿来当排查手册用。每一类都是我或组里同事真实遇到过、排查过、有结论的。现象根因处理方式生成结果所有尺寸都偏大或偏小训练数据未统一单位/未归一化模型学到的是相对尺度统一缩放所有模型到同一单位制再训练拉伸方向朝反方向序列表示中方向符号与数据不一致或草图平面法向定义混用检查草图平面法向约定与CAD内核保持统一零件出现大量碎片面布尔运算类型预测错误把“差集”预测成“并集”检查布尔类型字段的数据分布增加差集操作的训练样本模型只生成一个固定形状序列长度太短复杂操作的token被截断或temperature过低增大序列长度微调temperature到0.3~0.5同一个操作反复输出decoder在长序列后半段失去长期依赖重复低熵字段降低temperature、增大beam size或检查位置编码长度CAD打开显示无界几何输出参数非法如半径为负、拉伸距离为0但未被语法拦截增加解码器约束对参数范围做合法性校验编辑草图尺寸时模型整体撕裂训练数据缺乏约束信息生成后补约束或数据阶段用自动约束求解补充约束4.2 关于评估指标的迷思IoU高不等于CAD可用评估text-to-cad模型很多人习惯看IoU或Chamfer Distance这两个指标在论文里很常见。但实操中我必须泼一盆冷水IoU高和“这个模型能用”之间差了十万八千里。举一个我遇到的极端案例。某个模型生成的形状和真实目标相差不大体素IoU高达0.85但导入CAD一看零件内部全是空腔而且布尔运算顺序完全不对压根不能加工。原因是IoU指标只是在体素空间衡量“重叠体积占比”它完全不关心拓扑结构、不关心面数、不关心特征是否连续。一个实体和一个内部挖空很多小洞的实体体素表示可能几乎一致但可制造性完全不同。所以正确做法是多维度评估。除了IoU和显著性还要做三类检查一是CAD可执行性即序列能否被CAD内核成功执行而不报错二是参数范围合法性所有拉伸深度、直径、距离是否落在合理区间三是人工抽检每批次随机抽10%用SolidWorks打开微调尺寸看参数化响应是否正常。我在项目里把这三项做成了一条评估流水线比单看论文指标靠谱得多。4.3 数据增强的独家技巧随机旋转与局部坐标扰动前面提到过坐标系问题这里给一个我实测有效的小技巧全局坐标随机旋转增强。很多CAD序列数据集里模型总是摆在一个固定的“正方位”上。模型学到的其实是“绝对的方位角”而不是“零件本身的形状”。一旦用户输入一句描述模型就会在训练数据的那个方位画零件而不是在用户期望的姿态上画。处理方式很简单训练时对每个样本把整个坐标系随机旋转一个角度并把所有坐标和方向向量按照同样的旋转矩阵变换。这样一个模型就学不到“全局坐标系的绝对意义”只能学习“相对几何关系”泛化性和对用户指令的响应能力都会提升。这个增强在公开数据集规模不大时特别管用我直观感受是把文本描述的尺寸准确率拉高了十几个百分点。另一个增强技巧是局部坐标扰动。对草图上的图元坐标加一个极小的高斯噪声让模型学会容忍浮点数误差避免训出来的模型对精确数值过拟合。加了这层扰动之后beam search采样出来的候选序列不合法比例明显下降。5. 工具选型解析从开源库到商用CAD的取舍5.1 开源工具链OpenCASCADE、FreeCAD与pythonocc的定位处理text-to-cad生成结果开源工具链的选择直接决定调试效率。这个领域绕不开的是OpenCASCADE一个开源的几何建模内核市面上很多CAD软件的内核就是基于它或它的衍生版。FreeCAD是直接用OpenCASCADE做的完整CAD应用pythonocc则是OpenCASCADE的Python绑定。我的分工习惯是OpenCASCADE做底层的B-Rep生成和操作执行pythonocc负责写脚本批量化处理FreeCAD只做最后的人工检查和简单修改。OpenCASCADE的缺点是学习曲线陡峭文档少且老旧pythonocc的API风格更现代社区活跃度高FreeCAD虽然界面一般但胜在能打开STEP文件、检查属性、做基础编辑。三者组合基本能覆盖生成-验证-手改全流程。如果你要做二次开发直接嵌入FreeCAD的Python环境是个不错的起点因为它把很多OpenCASCADE的繁琐细节封装掉了。不过FreeCAD的脚本接口经常随着版本变化工业部署时建议固定版本别跟着最新版追。5.2 商用CAD的自动化接口为什么还是得回到SolidWorks/Fusion 360生成完的STEP文件最终要给人用。开源CAD虽然免费但在参数化编辑体验、工程图出图、CAM集成方面还是跟商用软件有差距。机械工程领域的现实是客户要的就是SolidWorks原生的、带特征树的文件。商软接口这块SolidWorks提供了API可以用C#或Python调用能把STEP文件自动转成SolidWorks原生格式并按特征类型重新构建特征树。这个转化过程常常需要微调因为STEP格式丢失了参数化特征历史转过来的模型往往是一个大实体不是一个个特征。Fusion 360也有类似API而且基于云端批量处理能力更好。我的建议是如果只是验证模型正确性用FreeCAD就够了如果要交付给客户或做后续工艺必须走商软API做特征识别和重建。有些商业软件自带特征识别功能能把导入的实体自动拆解成特征树就是成本高中小企业不一定愿意花这个钱。这个时候text-to-cad模型如果本身输出的就是操作序列反而是一个巨大优势——每台机器执行序列就能重建特征树完全不需要依赖识别算法。6. 一些独立判断与方向展望6.1 从“能生成”到“能修改”多轮交互才是工程落地的关键当前text-to-cad的公开工作大多还停留在“一句话生成一个完整零件”的阶段。但我在真实需求调研中经常听到的诉求不是这个。工程师更想要的是“我已经画好了一个底座你说‘把左侧支撑臂改成斜的’它能直接帮我改”。这需要模型理解三维模型的当前状态并结合自然语言做局部修改逻辑上就复杂了一个量级。学术界把这个方向叫CAD编辑或局部生成目前还没有像Text2CAD那么成熟的公开基线。但我觉得这才是从玩具走向生产力的关键一跳。如果你在公司里做内部工具选型建议优先关注这个方向因为“从零生成一个零件”的频次多数时候远低于“在已有模型上改一处地方”。从技术路径上看多轮编辑大概率要走“视觉编码器语言模型参数化序列生成”的结合体。模型需要把当前模型的几何或特征树编码为上下文再理解新增语句输出局部修改操作。类似于代码编辑里的diff生成问题只不过这里的“代码”是CAD操作序列。6.2 工业落地参考非标件库、概念评审与知识沉淀最后聊聊具体的落地场景。从我接触到的项目看有三个适合早期切入的场景每个都有不同的技术侧重点。第一个是非标零件库的快速检索与生成。企业在几十年的积累里有海量历史非标件CAD文件是分类归档的但没有统一的文字描述。用text-to-cad反着做——给一段描述从库里生成对应模型——可以帮选型工程师快速获得近似模型再人工微调。这个场景对精度的要求相对低因为下游会有人工修改兜底。第二个是概念设计评审。前期方案阶段需要出很多示意式的三维模型来讨论结构可行性这个场景下模型精度要求不高但要求生成速度足够快、形态多样性足够丰富。用大温度采样一次生成多个候选用渲染图做脑暴替代人工一个个画。第三个是知识沉淀与传承。老设计师退休前留下的建模思路如果能用自然语言记录下来再关联到对应的CAD操作序列那对年轻工程师的价值非常大。text-to-cad模型在这个场景里更像一个“建模行为的编译器”把文字经验变成参数化流程。这个方向真正落地需要的不是更强的生成模型而是更完善的语义关联和检索机制。6.3 数据飞轮如何用生成结果反哺模型迭代最后分享一个我们正在尝试的闭环思路。企业内部的CAD活动每天都在产生大量新模型这些模型本来是躺在服务器里的死数据。如果把“自然语言指令-AI生成序列-人工修改后的最终模型”作为一个元组记录保存下来每经历一次人机协同建模就产生一条高质量的训练样本。积累一段时间后再拿这些真实反馈数据微调模型效果会比公开数据集训练好得多。这需要系统和流程上的配合不是模型层单独能搞定的。但技术可行性已经在多个场景被验证了AI生成粗模、工程师修改细化、修改记录存入数据库、定期回流训练。形成这个飞轮之后text-to-cad系统在垂直领域的能力会越来越强这是通用模型很难做到的护城河。我现在手里的验证项目就是这么设计的第一期只切了“法兰类零件少量型材”这个小范围评估指标里除了形状相似度更多看修改时的工作量下降比。等数据积累够了后面再逐步扩展零件类型。如果你正准备从零开始做text-to-cad我真心建议先把范围圈小用强约束保证输出合法性然后再考虑扩展——起点越小能跑通的概率越大。