早上客户发来一张手绘草图旁边配一行文字“一个带四个安装孔的法兰盘孔径8mm孔距40mm外径70mm”然后问我下午能不能把可加工的模型给到。这场景很多人不陌生——几句话能说清楚的需求落到CAD软件里却要拉草图、加约束、做阵列再导出STEP半小时起步。要是建模工具能直接听懂这句话把概念草图阶段的时间压缩到几分钟很多重复劳动就省下来了。text-to-cad 要做的正是这件事输入自然语言描述输出可编辑、可加工、符合工程语义的三维CAD模型。它和市面上常见的“AI生成3D模型”完全是两条路。大多数AI生图生成的是mesh网格模型长得像但没法进装配、没法出工程图、更没法上数控机床。而 text-to-cad 的目标是从文本直接生成B-rep边界表示模型要么是STEP/IGES这类标准交换格式要么是参数化特征历史拿到手就是一个能继续改、能算重量、能出加工代码的正经CAD零件。这篇文章我就围绕 text-to-cad 这套技术栈从原理拆解到实操流程再到我踩过的坑尽量讲透。1. text-to-cad 到底在解决什么问题1.1 从“看到图”到“直接听懂人话”的建模方式变化过去二十年CAD软件的操作逻辑其实没变过你告诉软件“画一个圆”然后给圆加直径约束再拉伸成圆柱再打孔。每一步都是离散的指令软件负责执行人负责决策。这种模式的好处是精确可控坏处是——学习成本和操作成本都高尤其当你只是想快速验证一个想法的时候过程非常拖沓。text-to-cad 想改变的是把“人把想法翻译成操作指令”这个过程直接省掉。想法本身就是语言而CAD模型本质上是“一组有序操作的最终结果”。那么能不能让模型学会输入一句话输出一整套能重建出正确几何体的操作序列这件事在五年前听起来有点天方夜谭因为CAD命令序列是结构化的、有严格先后顺序的还涉及坐标系、草绘平面、约束关系。但Transformer架构流行之后大家发现一个有意思的类比CAD的命令序列其实很像自然语言里的“句子”。它有词法合法命令、有语法命令的先后与嵌套、有语义最终生成的形状。既然语言模型能学会写文章那它理论上也能学会“写”出一段CAD建模指令。这就是 text-to-cad 的第一条核心逻辑把建模任务重新定义为序列生成任务。1.2 为什么说 mesh 生成不等于 CAD 生成这里必须说清楚一个容易混淆的点。现在跑得火热的“文本生成3D”大多数输出是mesh网格或者隐式场SDF/NeRF。你拿它生成的模型去3D打印一个手办、做游戏道具完全没问题但拿去机械设计里用基本等于自找麻烦。原因有三条。第一mesh模型没有设计意图。法兰盘上那个孔在mesh里就是一堆三角形的顶点坐标你不知道它是一个孔特征也不知道它的直径是8mm、轴线在哪个位置。想改孔径没有参数改不了只能整个重新生成。第二mesh模型的几何精度不够。机械零件很多配合面要求公差等级平面度、圆柱度、同轴度这些mesh根本给不了。数控编程需要的刀轨是基于精确曲面计算的mesh转过去到处都是台阶差。第三mesh文件没法进标准工作流。工程师交付给供应商的文件是STEP、IGES或者原生格式不是OBJ、GLTF。你在mesh里“看着像”的零件下不到车间。text-to-cad 从设计上就避开了这些问题。它要么生成B-rep边界表示精确曲面拼接而成要么生成特征历史树从草图→拉伸→切除的完整记录本质上是“会自己建模的CAD操作员”而不是“会捏黏土的雕塑家”。这也是我一开始接触这个方向就非常看好的原因它输出的东西确实能直接干活。1.3 这类工具适合哪些场景和人群先别把 text-to-cad 想成“替代工程师”的东西它现阶段最实际的价值是三个场景。第一个场景是概念设计阶段的快速验证。设计师脑子里有个初步方案嘴上描述一遍系统先给出一版粗略的几何体确认方向对不对再进入细化的手工建模。这个流程以前是先开软件手搭发现方向不对再推翻重来浪费大量时间。第二个场景是标准件和重复零件库的建设。很多企业有几百上千个类似结构的零件只是尺寸不同。用 text-to-cad 把这堆变体零件用文字参数化描述出来配合脚本批量生成比维护一大堆CAD文件要高效得多。第三个场景是非专业用户。比如做采购的同事想快速看一眼供应商报价的零件长什么样或者创客想把自己的想法变成可加工的模型他们的CAD能力有限但能说清楚需求。这类工具拉低了建模的门槛。当然它离“完全取代人工建模”还远但它作为一个“超级辅助”已经非常有价值。下面我会把技术方案、数据集、训练过程和推理细节全部展开你可以直接照着搭一套最小的 demo。2. 主流技术路线怎么选2.1 大语言模型驱动 CAD 命令序列这条路线是当前最主流、也最接近“可落地”方向的思路。核心做法把CAD建模过程表示为一系列命令比如“新建草图 → 画圆(圆心, 半径) → 拉伸(距离) → 切割(范围)”然后把这一串命令当作序列数据用一个类似GPT的Transformer模型来生成。代表性工作之一是 DeepCAD 数据集和配套方法。DeepCAD 从 Fusion 360 的教学/示例文件中提取了大量真实建模操作序列每个模型对应一段 JSON 格式的命令历史包含草图实体类型、约束、尺寸参数、操作类型等。模型的任务就是输入文本/条件预测这段命令序列。训练完成后拿到预测的命令序列用CAD内核重新执行一遍就能得到最终的B-rep模型。这条路线最大的优点是结果完全可编辑。因为输出的是构建历史你可以进到软件里修改某个拉伸距离、换一下草图圆直径模型自动更新。它保留了CAD的核心价值——参数化。执行这条路线需要注意命令序列的字典长度不大几十个Token但每个Token可能带不同数量的浮点参数这对解码策略提出了要求。常见做法是把参数离散化成固定范围的整数比如0-255让Transformer直接分类预测或者用一个多头模型同时预测命令类型和连续参数如基于混合密度网络。前者简单但精度受量化步长限制后者实现复杂但参数可以精细一些。这类方案的代表开源项目是 AutoCAD 生成方向的一些工作以及基于 DeepCAD 语法的 Text2CAD 论文ACCV 2024文本转机械CAD模型的端到端框架。后面实操章节我会用一个简化版本走一遍流程。2.2 直接生成 B-rep 几何另一条路线是绕开“命令序列”直接用生成模型去预测B-rep曲面信息。输入文本/图像输出是一系列面Face、边Edge、顶点Vertex以及它们之间的拓扑关系或者先预测一个占用场/符号距离场再从场里提取表面。这种方式的好处是跳过CAD内核执行环节不需要考虑命令序列是否合法只要把几何形状拟合出来就行。坏处也很明显生成的B-rep经常出现面与面之间的微小间隙、重叠、自相交实体化修复非常头疼。而且它生成的是“结果模型”不带参数历史后续修改能力弱很多。不过这条路线在“复杂自由曲面”场景有优势。机械里的曲面造型件手机壳、灯具外壳、叶轮之类很难用传统的拉伸/切除命令序列表达用场生成B-rep提取反而更自然。现在也有研究在探索混合方案先用生成模型给出粗略几何再反向拟合出参数化特征但工程成熟度还不够。如果你只是想做一个快速原型的 text-to-cad 工具我建议优先选命令序列路线成熟度更高也更符合下游生产需求。2.3 多模态引导文本 图像 点云真实的工程场景里用户手里往往不只有一句描述可能还有一张参考图、一个粗糙的点云扫描甚至是一张手绘草图。所以现在的 text-to-cad 系统普遍往多模态方向发展。做法上文本和图像分别接入编码器文本用CLIP的文本编码器图像用CLIP的图像编码器或ViT提取到的特征在Transformer的交叉注意力层里融合再与命令序列解码器对接。训练时同一模型可以灵活使用不同的条件模态——只有文本就用文本文本图就一起用图不清楚时文本兜底。多模态融合带来的提升非常明显。纯文本描述“一个带圆角的矩形底座上面有一个圆柱凸台”其实有歧义凸台在中心还是偏一侧“圆角矩形”长宽比多少但如果你配一张参考图语义就清晰多了。我在实测里发现多模态模型生成结果的几何尺寸准确率能比纯文本模型高出两三个百分点。2.4 三套方案的取舍给你一张选型表特性命令序列生成DeepCAD路线B-rep直接生成多模态融合路线输出形式建模操作历史可参数化B-rep网格化边界命令序列或B-rep可编辑性高改参数自动更新低改形状等于重新生成取决于底层生成器几何精度高由CAD内核保证中低需要修复高若走命令序列实现难度中高较高数据需求中等十万级命令序列高需要大量配对B-rep中高多模态配对适用场景机械零件、参数化设计自由曲面、外观造型工程实际项目有参考图我个人现阶段最推荐的是第三张表里的“多模态命令序列”组合用文本做主要条件、图像做辅助条件底层还是让模型生成命令序列然后用CAD内核执行。这样既有灵活度又不牺牲可编辑性和精度。3. 实操从文本描述到可编辑 STEP 模型的完整流程3.1 环境准备与数据集设计先说环境。理论上 text-to-cad 的训练可以纯用PyTorch跑但如果你想验证生成结果能不能实体化成STEP文件需要准备一个CAD内核环境。推荐用 FreeCAD 的 Python 接口内部封装了OpenCASCADE可以执行命令序列并导出STEP免费且社区活跃。我搭的最小验证环境是这样的Python 3.10 PyTorch 2.xTransformers 库用于加载文本编码器和Transformer结构OpenCASCADE / FreeCAD用于命令执行与导出DeepCAD 数据集约 17 万条CAD建模命令序列Fusion 360 Gallery 也可以作为补充数据集要先做预处理。DeepCAD 的原始数据是 JSON每条记录包含一个模型的所有草图实参、约束和拉伸切割操作。为了让模型学得动我做了这些处理过滤掉命令数超过 60 的样本长序列既难学又容易累积误差把连续参数比如圆的半径、圆心坐标按比例缩放到 [0, 1]再离散成 0-255 的整型Token给每个模型生成 3-5 条不同措辞的文本描述比如“一个带四个圆孔的方形法兰板”和“方形板四角各有一个通孔”。这里多说一句文本描述的质量直接影响模型上限。如果描述里只有形状名词没有尺寸、数量、位置关系模型学到的条件约束就会很弱。我后来在数据里特意增加了带尺寸描述的子集“一个直径30mm的圆柱高50mm”模型对数值的理解明显提升。3.2 文本编码与命令序列生成模型的结构整体结构上我参考了常见的“条件Transformer”设计但做了两个小改动。模型输入分成两路。一路是文本用 CLIP 的文本编码器或者一个轻量BERT得到整句编码向量和一个Token级特征序列。另一路是命令序列被展平成一个Token列表比如下面这样sketch_plane: 0 line: [p1_x, p1_y, p2_x, p2_y] dimension: [值] extrude: [深度, 方向]处理时把命令类型和参数都当作离散Token用过词嵌入层映射成向量送到因果Transformer类似GPT里做自回归预测。第一处改动是在文本特征和命令序列之间加了交叉注意力层。不同于普通的“把文本向量拼在序列头部”的做法交叉注意力能让每一步命令预测都显式地“看到”文本Token。实测下来这比单纯加一个全局向量做条件要稳特别是在生成长命令序列时模型不容易“忘了用户说了什么”。第二处改动是在输出端加了一个“参数是否有效”头。除了预测下一个Token模型还额外输出一个二分类当前预测的这组参数比如圆心坐标是否落在合理范围。这是在推理阶段用来做过滤的。训练Loss就是标准的交叉熵命令类型和离散参数一起算。batch size 32学习率 2e-4用 AdamW在单张24G显存的卡上跑了大约 8 万步。验证集上的命令序列准确率能到 78% 左右但注意序列准确率不完全等于几何准确率——最后能否实体化成有效模型还得看CAD内核执行。3.3 推理阶段不只是“跑一遍模型”而已训练完模型之后真正决定项目能不能用的是推理阶段的细节。我总结了三步第一步束搜索 温度采样混合。纯用贪婪解码或者beam search很容易生成千篇一律的简单形状。纯采样又容易产生乱码序列。我的做法前 10 个Token用 beam searchbeam4保证命令的大框架正确后续Token切到 top-kk40加温度 0.8 的采样保持多样性。第二步命令合法性过滤。预测出来的命令序列必须通过语法检查。比如“line”命令需要4个坐标参数但如果模型只预测了两个参数直接修复或丢弃这一段。条件运行后如果连续两次生成都无法通过语法检查就回退到“纯文本引导的模板生成”保底方案。第三步CAD内核执行与修复。合法序列交给 FreeCAD 的 Python API 逐条执行。执行过程中报错很常见我整理了最常见的两类草绘约束冲突比如两条线被约束成垂直又显式给了角度值。特征操作无法生成实体比如拉伸方向不当导致布尔运算失败。这些情况我一般不重新采样而是采用一个非常实用的“参数回退”策略把出错的参数按 90%、80%、70% 比例缩放重试直到能生成实体为止。与其让交互卡住不如先给一个近似结果让用户确认。3.4 导出 STEP 并在传统CAD软件中打开实体生成后用 FreeCAD 的 Shape 对象导出 STEP 格式再在 SolidWorks / 中望 / 浩辰 等软件里打开验证流程闭环。下面这段是我常用的导出脚本精简过import FreeCAD import Part import Mesh # 假设 shape 已经由命令序列执行后得到 shape doc.getObject(Generated_Shape).Shape # 导出 STEP Part.export([shape], /path/to/output.step) # 如果想看可视化预览可以先转成网格方便在浏览器/报告里展示 mesh Mesh.Mesh() for face in shape.Faces: mesh.addFacet(face.tessellate(0.5)) # 0.5mm 的弦偏差这里有个反直觉的坑直接从模型生成 STEP 文件、图片预览却看起来是黑乎乎一团这通常是法线方向反了。B-rep的面法线方向是有含义的如果你的模型在修复合入时没统一法线方向导出STEP的文件在别的软件里一样能打开但渲染和某些CAM计算会出问题。最快的排查方法是用 FreeCAD 自带的 Part → Reverse Shape 功能强制翻转法线再导出。另外一个细节是单位。DeepCAD 数据集内部用的是毫米训练时我们直接按这个尺度走。如果你要输出英寸单位的STEP必须在导出时做一次缩放除以25.4不要想着在STEP文件头里改单位字段很多软件不认。4. 衡量模型效果不只是视觉像不像4.1 几何精度指标很多刚接触 text-to-cad 的人第一反应是“用CLIP score或者看渲染图像不像”。这不够。工程模型要的是定量精度。几何层面我建议用三个指标Chamfer DistanceCD在两个点云之间做双向最近邻匹配衡量表面位置差异。越小越好。IoUIntersection over Union把GT模型和生成模型都转成体素栅格计算交集/并集。0.8以上说明形状整体重合度不错。F11%在表面采样大量点对每个预测点找GT中距离最近的点统计距离小于GT模型包围盒对角长度1%的点的比例。这个指标比CD更能反映局部细节恢复程度。实操时要留意采样密度。点云太稀疏CD会偏低虚高太密集计算量爆炸。我常用的组合是每个模型表面采 4096 个点CD的阈值经验上设为小于 0.05 就算不错。4.2 结构有效性指标几何像不代表“能用来生产”。结构有效性才是一票否决项。我自己的评估集里会统计三个指标命令序列语法合法率解码结果通过语法检查的比例。这个值一般要高于 95%否则使用体验稀碎。实体生成成功率语法合法且能通过CAD内核实体化的比例。这个值决定了最终交付STEP的良品率我最低底线是 80%。特征错误数量生成模型的拓扑与真实模型的特征树相比多了几个或少几个特征。比如GT里“两个孔”生成模型只给了一个就算一次特征级错误。特征错误数量是容易被忽略但实际最影响用户体验的指标。用户说“四个孔”你给一个三孔的零件几何上再像也没有意义。4.3 评估时容易踩的坑第一个坑是只盯平均指标。我会把测试集按命令长度分段统计——短序列10-20个命令和长序列40个命令分开看。长序列模型的精度会衰减得很快平均指标好看但长序列部分其实不可用。落地方案要能对长序列触发降级策略要么提示用户简化描述要么切分生成。第二个坑是文本描述太单一。我见过不少项目用模板化的描述做测试集比如“一个圆柱体”就完事了。真实场景里用户会说“一个直径50mm、高度30mm、底部带四个均匀分布安装孔的圆柱座”。因此评估集必须包含“带尺寸”、“带相对位置关系”、“带多个特征”的子集否则模型上了实际业务基本报废。第三个坑是没有人工评审。自动指标筛掉明显失败的例子后剩下那些“看起来都过了”的结果我会随机抽50个渲染成图让两个机械工程师盲评“是否能直接用于装配”。这个环节能撞出很多指标反映不出来的问题比如特征方向反了、基准面选错属于隐性问题自动指标测不出来。5. 常见问题与排查技巧实录5.1 文本描述被模型忽略生成结果和描述无关这是 text-to-cad 训练中最常见、也最恼火的问题。你输入“带四个孔的法兰盘”模型给你一个光溜溜的圆柱。排查思路按概率排序文本编码器的特征和CAD命令序列的分布差距太大。预训练的CLIP文本编码器是在互联网图文对上训练的它的特征分布跟CAD草绘坐标、长度、角度这类数值型Token完全是两个世界。解决办法是在训练时冻结文本编码器但给它后面加一个适配层Adapter让文本特征被“翻译”到CAD序列的语义空间。这个适配层的参数必须参与训练。文本影响被自回归模型稀释掉了。命令序列长、起步早模型生成到后半段时文本信息在注意力里衰减得很厉害。我建议在解码的每层都插入交叉注意力而不是只在第一层加一次。数据里文本描述太弱。如果训练数据里大量是“零件”这种宽泛描述模型学不到“文本→具体特征”的对应关系。重写数据让描述里明确出现特征名词和尺寸这个投入非常值得。5.2 模型“鸵鸟化”永远生成同一个简单形状用自回归Transformer常见的病训练到后期模型发现预测“圆柱”、“矩形块”这些高频简洁形状的Loss最低于是不管什么文本都往简单形状上靠。对策有几个层面。数据层面把训练集里的简单形状采样率降下来可以给命令数超过30的样本加大权重。训练层面温度参数不能太低否则随机性没了推理时用 top-p0.9 top-k50的组合避免过于贪心。如果这些都试了效果还是不行大概率是模型的容量不够。文本和CAD命令序列属于两个强模态一个2亿参数的小模型学起来非常吃力我建议起步用 5 亿参数以上的模型训练步数拉长到 10 万步以上再评估。5.3 生成的 B-rep 自相交、开壳实体化失败即使走命令序列路线CAD内核执行时也经常碰到无法生成实体的怪毛病。最典型的是草图里两条线段虽然看起来闭合但因为离散误差端点没有真正重合导致“壳”无法形成实体。遇到这种问题我有两把刷子。第一把OpenCASCADE 的 ShapeFix 系列工具。FreeCAD 里可以直接调Part.ShapeFix能自动修复微小的间隙、重叠边和法线方向问题。大多数情况下一跑就好。第二把布尔运算兜底修复。如果ShapeFix修不了就让模型用几个实体的布尔并集来逼近。比如预测的命令序列里有一段拉伸和一段旋转旋转体执行失败就退回成“拉伸体 另一个拉伸体 布尔并集”的组合。形状可能略有偏差但最终一定能得到有效实体。这个方法虽然丑但对于需要“快点看到结果”的交互场景非常实用。5.4 渲染预览“黑模”材质和坐标系乱掉模型生成完想在Web界面里给用户一个实时预览结果一渲染黑乎乎一片。这个问题的根源通常是法线方向和单位尺度。法线网格化之前必须统一法线朝外。FreeCAD 里可以用Part.Solid的check()方法检查体积是否为负负值说明法线反了。尺度DeepCAD 按毫米训练但WebGL渲染时换成任意单位。如果尺寸差距太大相机裁剪面把模型裁没了。先把模型归一化到以原点为中心、最长边为 1 的立方体里再做预览就稳了。还有个不算技术问题的建议给Web预览配一个简单的“爆炸视图”按钮。用户输入“一个带底座和盖子的盒体”里面有两个零件模型如果只生成到一起用户根本看不出结构。我用shape.translate()按特征方向给零件做整体位移让用户在预览里能直观看到每个特征的形状这个体验提升非常明显。6. 几点实操体会供你参考做这个项目之前我以为最大的难度在生成模型本身——怎么让模型“听懂”自然语言。做下来才发现真正耗时的是数据预处理、命令合法性约束、CAD内核执行修复以及各种奇奇怪怪的边角情况。这跟传统软件工程的规律一脉相承核心算法只占一小块周边工程化能力决定了一个技术能不能从论文变成能用的工具。如果你要自己搭一个 text-to-cad 的demo我给三个建议。第一先别上大数据大模型。拿 DeepCAD 的一个小子集跑通“文本→命令序列→实体→STEP”全链路再逐步加数据。链路通畅比精度重要得多。第二文本描述一定要带上尺寸和相对位置关系。纯形状名词的模型做出来也是玩具。第三给生成结果加一个人工确认的交互环节。让用户在预览里选中一个特征能改尺寸、能删除这比自动生成再自动输出有用得多。不要追求一次生成完全正确而是让用户能用最少的操作把它改对。text-to-cad 这个方向的终局也许就是“设计意图输入生产就绪模型输出”。但走到那一天之前先把自己的小闭环跑通比什么都强。