1. 这是一个什么样的项目当自然语言遇上CAD建模我最早注意到“text-to-cad”这个方向是看到团队里一位结构工程师在吐槽客户发来一句“一个圆柱体底座上面有一个M6螺纹孔”就这种需求他得坐在SolidWorks前面折腾半个多小时。我当时脑子里闪过一个念头——如果这句话能直接变成CAD文件就好了。没错text-to-cad干的就是这件事。它的核心目标是把人类用自然语言描述的几何形状、装配关系、尺寸约束直接转换成计算机辅助设计软件能够打开、编辑、再加工的参数化模型。注意关键词是“参数化”而不是“生成一个多边形网格”。这两者的差别非常关键后面我会详细展开。这个项目之所以在近两年突然火起来本质上是因为大语言模型和多模态模型把“理解文字”这一关打通了。过去我们也有参数化建模脚本但需要人手工写代码也有文本生成3D的方案但生成的是游戏用的mesh工业上没法用。text-to-cad恰好把这两条路合并成了一条让模型既能看懂自然语言又能输出结构化的CAD原语序列。这个方向适合谁研究如果你是做AI算法开发的这里有完整的“语言模型几何表示”技术栈可以研究如果你是用CAD吃饭的工程师你不需要去训练模型但了解它的边界能帮你判断哪类活儿可以交给AI干如果你是做工业软件SaaS的产品经理那更应该关注这个方向因为它直接关系到下一代设计工具的产品形态。我整理的这篇内容会从技术原理、方案选型、实操落地、问题排查四个维度来拆解text-to-cad。你可以把它当成一份技术笔记也可以当成一份踩坑手册来读。2. 核心概念与行业背景text-to-cad到底在解决什么痛点2.1 “文本生成3D”不等于“文本生成CAD”很多刚接触这个方向的人会把text-to-cad和文本生成3D模型混为一谈。其实两者技术路线完全不同输出的东西也完全不是一回事。文本生成3D模型比如DreamFusion、Point-E这类输出的是三角网格或者神经辐射场适合渲染展示能放入游戏引擎、VR场景、影视特效里。但这些网格没有设计意图没有特征树也没有可编辑的草图和约束你在SolidWorks里打开一个OBJ文件基本是废的——你不能修改它的直径不能改变倒角大小更不能在孔位上加一个公差标注。而CAD文件的核心价值恰恰在于“可编辑的参数化历史”。一个CAD模型背后是一连串的操作序列先画一个草图拉伸成实体再选一个面打孔再添加圆角——每一步都记录在特征树里。这个过程决定了CAD工程师的产出物不是一个“形状”而是一棵“设计倒树”。text-to-cad要做的就是直接从文本生成这棵“倒树”。它输出的不是顶点坐标数组而是一段CAD操作命令序列或者说是一组参数化原语的组合。比如circle(cx0, cy0, r5); extrude(h10); hole(d6; depth8)这样一条指令流。这才是真正的技术分水岭。它要求模型具备几何推理能力用户说“穿过中心”模型得知道要计算圆心坐标用户说“沉头孔”模型得知道先钻通孔再扩锥形孔用户说“法兰盘上均匀分布六个螺栓孔”模型得会做圆周阵列。我见过不少文本生成3D的demo做得很惊艳但一落到CAD领域就全线失灵原因就在这里——它们根本没理解“参数化”这三个字的分量。2.2 工业界的真实痛点为什么这事值得做我接触过的机械设计团队每年在三维建模上耗费的人工工时非常惊人。一个稍微复杂一点的支架从拿到需求到完成建模熟练工程师至少要两到三个小时如果是带曲面、带复杂装配关系的零件半天就过去了。更麻烦的是很多需求场景里“建模”本身并不是高价值的创造工作而是把已有方案重复落地的体力活。比如非标自动化行业里客户定制一个带有特定规格安装孔的底板每次都要重新画一遍。再比如标准件库的扩充——工程师需要根据厂商手册生成成百上千个规格的螺栓、轴承、法兰模型这些工作本质上是“文本参数 标准流程 模型”简直是为text-to-cad量身定制的场景。另一个值得关注的场景是概念设计阶段的快速验证。设计师脑子里有一个初步想法想快速看看大致的形态是否合理。以前的做法是画概念草图或者手工拉一个粗糙的实体模型。有了text-to-cad直接输入一句话“一个240x180x12的铝合金面板四角倒R8圆角中心一个直径22的孔四边居中位置各开一个U型通槽”系统就能在几十秒内给出一个可旋转查看的初步模型。虽然这个模型大概率还需要人工细调但用来做早期沟通和方案筛选效率提升是数量级的。当然我不能只吹不黑。目前的text-to-cad技术远谈不上成熟复杂装配体、精密公差、真实材料属性这些“硬骨头”还啃不动。但它解决的问题边界在迅速扩大哪怕只是把建模效率提升30%对整个制造业的研发周期来说都是巨大的杠杆。3. 主流技术方案拆解从架构层面看text-to-cad的实现路径3.1 三类主流实现路线对比我梳理了当前学术圈和工业界的text-to-cad实现方案大体可以分成三条技术路线。每条路线的设计出发点不同适用范围也完全不同。技术路线核心思路代表方案优点缺点文本到序列生成将CAD建模过程分解为token序列把建模任务转化为序列生成任务Text2CAD、DeepCAD衍生方案模型架构成熟依赖LLM生态输出可直接编辑需要大量配对数据复杂几何表达能力有限文本到中间表示先生成剪影图/多视图等中间产物再重建为CAD模型基于扩散模型的方案对自由曲面表达能力更强可视化过程直观中间表示到CAD的反向回归困难编辑困难文本到程序合成文本直接映射到CadQuery/OpenSCAD等程序语言代码LLM CadQuery / FreeCAD脚本工程质量高可利用编译器校验逻辑可审计依赖LLM的代码生成能力对复杂空间推理仍有不足先说第一条路线。DeepCAD大概是这个方向最早的代表作之一它的思路是把CAD建模命令草图、拉伸、剪切、圆角等编码成离散token然后用Transformer类的模型去做自回归生成。用户输入的自然语言文本先通过语言编码器变成向量再喂给序列生成模型。Text2CAD进一步把这条路线做完整了先用GPT系模型理解自然语言再把语义转化成CAD命令序列最后用专门的草图/特征解码器还原成CAD文件。第二条路线走的是“图生CAD”的迂回策略。这类方案通常先用文本生成多视角投影图或者深度图然后用这些二维图像约束三维重建算法生成CAD-friendly的曲面和实体。它的好处是能拿图像生成领域的预训练模型直接迁移对于用户难以用语言精确描述、但可以“看一眼就懂”的形状尤其有优势。但问题在于从图像回到参数化CAD模型这一步目前还没有特别稳定的方案生成的模型往往需要大量手工清理。第三条路线最近热度上升很快。既然大语言模型在写代码这件事上表现出色而CadQuery这类库本身又是用Python写出来的——那为什么不直接让LLM生成CadQuery代码呢这样做有个人尽皆知的好处代码可以运行运行的结果可以用FreeCAD或CadQuery的可视化工具直接渲染。如果代码有bug编译器会报错还能让LLM根据报错信息自我修正。我实验室里最近在尝试的一个工具链就是基于这个思路实测对中等复杂度的零件成功率能达到六成以上。3.2 为什么“序列生成”路线在工业界最受关注虽然前面提到LLM生成代码的路线很有潜力但如果要让text-to-cad真正做到“输出稳定、可复用、不炸模”我还是要说序列生成的路线是当前工业界改造力度最大、落地最快的方向。原因其实很朴素序列生成路线的输出是离散token我们完全可以借用自然语言处理里已经成熟的那套工具——beam search、采样温度控制、重复惩罚——来调节生成质量。你告诉模型“生成一个M8的螺纹孔”它可以输出一组长度可变但语义正确的token序列。更重要的是输出的token序列可以逆映射回CAD建模操作这就保证了“每一次生成结果都是合法的CAD操作流”。程序合成路线虽然灵活但大语言模型写代码会有个问题它能写出语法完全正确的代码却在语义上自洽性不足。比如它可能生成一段调用polygon()画六角头的代码但里边的点坐标算错了导致实际画出来是个歪的。这类问题在文本生成CAD文件里非常致命因为你无法在代码编译阶段发现它只能等渲染结果出来才能看到。序列生成路线的另一个优势是数据集生态相对完整。以Fusion 360 Gallery Dataset和ABC Dataset为代表的CAD建模序列数据集已经在学术界积累了好几年里面的“形状-建模步骤”配对数据非常丰富。而程序合成路线需要有“自然语言描述-CadQuery代码”的配对数据这类数据的构建成本更高目前也没有统一的大规模公开数据集。3.3 模型输入输出设计怎么把一句话变成建模指令关于如何把自然语言映射成CAD建模指令我认为有四个核心设计环节值得展开。第一是文本编码。这里包含词汇层和句子层两个视角在词汇层要识别出大量的领域实体比如“沉头孔”countersink、“法兰”flange、“倒角”chamfer这些词必须映射到精确的特征类型在句子层要解析空间关系比如“a plate with 4 holes on the corners”和“a plate with a central hole”这两句话都需要识别“孔”这个特征但空间位置完全不同需要句法层面的语义解析。这里不能只靠通用LLM的隐式理解最好在模型顶部加一层领域约束机制否则很容易出现“听懂了话但建模偏差很大”的局面。第二是几何推理。CAD建模空间里的几何推理包括尺寸计算比如“内径30的管道”需要明确壁厚才能推出外径、位置关系比如“对称分布在四角”需要找到参考面并计算坐标、拓扑关系比如“这个孔贯穿三个零件”需要做布尔运算。现在的序列生成模型对常见几何约束的把握能力还可以但一遇到需要多步推理的情况比如“法兰上六等分分布的孔”就很考验模型内部的几何先验了。这一块目前业界还在探索还没有看到特别惊艳的成果。第三是特征序列的表示。CAD软件里的每个特征都可以表示为一个五元组特征类型、草图平面、几何参数、布尔运算类型、参考依赖关系。而模型需要把这些信息组织成离散token。常用的编码方式是把建模命令按“参数类型 数值”的方式拼接比如lineLength[4.5]、circleRadius[6.0]、extrudeDepth[12.5]。这些token再按操作顺序组合成完整的序列。一个中等复杂的零件建模序列通常在200~1000个token之间这个长度对Transformer来说完全在可接受范围内。第四是解码策略。在推理阶段beam search通常比贪心解码效果好得多但beam size不能太大我在实践中的经验是5到10之间比较平衡。温度参数要调低一点太高的温度会让模型输出语义漂移的序列。另外一定要加重复惩罚否则模型很容易陷入重复生成同一特征的死循环。4. 实操从零搭建一个text-to-cad的最小验证系统4.1 环境与依赖选型理论说完接下来上点真东西。我这里给出一套可以在自己机器上跑通的最小验证方案。这套方案基于公开数据集和开源工具不需要你有顶级显卡一张RTX 3090或者A100级别的卡就够了甚至如果有耐心用CPU跑小规模训练也不是不行。环境清单如下组件推荐选择说明操作系统Ubuntu 20.04 / 22.04CUDA环境最省心Windows也可以但编译依赖容易折腾Python3.9以上3.10稳定深度学习框架PyTorch 2.x生态成熟社区方案多CAD解析库CadQuery 2.x OCP用于把生成的命令序列转为STEP文件预览可视化Jupyter Lab trimesh快速查看生成结果辅助工具FreeCAD可选用于手动检查生成文件显卡方面我多说一句如果你之前只跑过纯文本模型会觉得这个任务的显存需求还能接受。序列长度不长模型规模在100M到300M这个量级就够实验了。但如果要跑支持复杂几何的大规模训练那还是建议准备多卡环境。4.2 数据集准备文本描述从哪里来训练一个text-to-cad模型最核心的资源就是“CAD模型文本描述”的配对数据。目前学术界有一些公开数据集可以白嫖包括Fusion 360 Gallery Dataset由Autodesk开源包含超过一万个真实用户创建的CAD模型附带完整的建模操作序列。这是目前最有价值的训练数据来源。ABC Dataset包含超过一百万条CAD模型数据主要用于几何重建方向的训练需要自己从中提取建模序列。DeepCAD Dataset从Fusion 360数据集中提炼出的紧凑CAD命令序列数据集同时也配套了过滤和清洗后的版本。Text2CAD Dataset2024年发布的专门面向text-to-cad任务的配对文本描述数据集直接拿来用就行。我自己的经验是光用公开数据不够还需要准备一些小批量的人工标注数据来校准模型的文本语义理解。做法很简单找十来个典型零件用一两个工程师半天时间把每个零件写成三到五种不同的自然语言描述。比如同一个法兰既要有“同心法兰”这种口语化说法也要有“外径60内径25的带四个对称安装孔的圆盘”这种参数化描述。这些数据用来做模型微调效果提升非常明显。4.3 模型训练与推理完整流程我这里给出一套简化的训练流程基于DeepCAD的Transformer Backbone加上CLIP风格的文本编码器。这个方案的技术栈相对成熟跑通一次大概需要一到两天时间。第一步数据预处理。把CAD建模命令转换成token序列需要定义词表。我的处理方式参考了DeepCAD官方实现对每种特征类型设置独立的参数token范围。比如拉伸特征会包含拉伸距离、拉伸方向、是否对称拉伸等参数每个参数占用几个token。文本描述用基础的Tokenizer处理即可不需要专门训练一个CAD领域的分词器。第二步构建模型。整体架构是一个双塔结构左边是文本编码器右边是CAD命令序列生成器。文本编码器可以加载现成的BERT或者T5模型CAD序列生成器是一层多层的Transformer Decoder。文本向量和命令序列之间通过Cross-Attention机制交互。我给出一个精简的模型定义思路具体实现可以参考HuggingFace Transformers库class TextToCADModel(nn.Module): def __init__(self, text_encoder, cad_vocab_size, d_model512, nhead8, num_layers6): super().__init__() self.text_encoder text_encoder # BERT/T5 encoder self.cad_decoder nn.TransformerDecoder( nn.TransformerDecoderLayer(d_model, nhead, batch_firstTrue), num_layers ) self.token_embedding nn.Embedding(cad_vocab_size, d_model) self.position_embedding nn.Embedding(1024, d_model) self.output_layer nn.Linear(d_model, cad_vocab_size) def forward(self, input_ids, attention_mask, cad_token_ids): memory self.text_encoder(input_idsinput_ids, attention_maskattention_mask).last_hidden_state tgt self.token_embedding(cad_token_ids[:, :-1]) tgt tgt self.position_embedding(torch.arange(tgt.shape[1], devicetgt.device)) output self.cad_decoder(tgt, memory) return self.output_layer(output)第三步训练参数配置。这个部分的参数选择我踩过好几轮坑直接给结论学习率3e-4配合warmup占比5%的cosine schedule训练更平稳batch size32到64比较合适如果显存吃紧就降到16epoch20到30轮建议在验证集上跟踪token-level accuracy和CAD文件可打开率损失函数标准的交叉熵损失掩码掉padding位置的loss即可优化器AdamWweight decay设为0.01第四步推理。推理的时候输入的自然语言描述先经过text_encoder编码然后CAD decoder开始自回归地生成token序列。每生成一个token就拼接到输入里直到产出终止符。解码策略用beam searchbeam size设为5温度0.8重复惩罚系数1.2。推理得到的token序列要交给一个后处理模块把token还原成CadQuery代码然后执行生成STEP文件。这个环节有一个非常容易踩的坑token序列在数值上正确但特征顺序不符合CAD建模逻辑。比如还没有基准平面就试图打孔或者布尔运算引用了不存在的实体ID。这种问题只能靠规则引擎来兜底不能指望模型自学到这些约束。4.4 效果评估怎么判断模型好坏评估text-to-cad模型不能只看生成序列的token准确率那玩意儿有严重的信息偏差。我在实际评估过程中会看三个维度的指标第一维度是CAD文件合法性。生成的STEP文件能否被主流CAD软件无警告打开有没有破面有没有非流形边缘。这一条不满足其他指标都白搭。我的经验是给这个维度设置最高的权重因为一个打不开的文件没有任何工程价值。第二维度是几何相似度。用IoUIntersection over Union和Chamfer Distance来比较生成模型和参考模型的三维形状差异。这部分可以借用点云处理的能量库来计算不需要自己从头实现。但不建议过度依赖这个指标原因很简单CAD模型讲究的是参数对不对而不是外形像不像。一个轴可能外形差了几个毫米但公差设计完全不一样单纯从几何相似度上是看不出来的。第三维度是语义一致性。把生成的模型再交给人来判断“这个模型是否满足了原始文本描述的所有要求”。这个指标主观但恰恰最贴近工业应用。我建议准备一个评估表逐项核对原始描述中的功能要求比如“是否包含螺纹孔”、“是否有倒角”、“孔的直径是否与描述一致”每个单项打分最后汇总出语义准确率。在模型达到可以用的程度之前这个评估流程需要在每次迭代后都跑一遍不能省。我自己吃过亏某次在token准确率提升了8个百分点的情况上沾沾自喜结果拿给工程师一看生成的零件全是封闭不了的破口。5. 常见问题与排查技巧实录那些文档里不写的东西5.1 生成结果总是“四不像”怎么办如果你跑出来的模型经常出现“语义理解正确但几何不对”的问题——比如用户说“圆柱体”模型画出来一个棱柱体——大概率是训练数据的几何多样性不足。DeepCAD数据集中圆柱体确实存在大量以多边形近似表示的情况。另外如果模型生成的模型经常出现面数异常、实体封闭失败建议检查数据预处理阶段的归一化方式。我见过不少团队在把CAD模型转为离散表示时把单位从毫米转换成了抽象单位导致模型的输出尺寸和文本描述完全不匹配。这个问题排查起来非常隐蔽因为从token序列看一切正常直到用户输入“直径50mm的孔”生成出来的孔实际只有5mm。排查方法是检查数据归一化的基准值。我建议所有数值在预处理时都把1个单位映射为1毫米确认真实物理含义后再开始训练。这一步虽然基础但能避免百分之八十的“四不像”问题。5.2 输出CAD文件打不开模型生成结果常见三大坑结合我测试过的多个text-to-cad开源方案输出文件打不开的原因基本集中在下面三种情况。第一种是实体拓扑错误。CAD建模中每个独立实体都有一个唯一的拓扑ID模型在生成过程中可能会引用不存在的拓扑实体进行布尔运算。比如对一个尚未拉伸的草图直接做圆角操作最终的B-Rep边界表示就是非法的。这类问题可以用CadQuery的Workplane.validate()方法在生成后校验一遍发现非法就重新采样生成。第二种是坐标系统错乱。我看到有些模型的推理阶段输入了错误的坐标变换矩阵导致生成的零件在空间上发生了旋转或者翻转。比如文本描述里要求“圆柱轴垂直于顶面”生成出来的结果是水平的。这个问题在评估阶段特别容易漏掉因为形状本身看起来是自洽的但方向不对。第三种是尺寸精度不足。CAD软件处理尺寸时通常使用双精度浮点数而模型输出的离散token只能表示有限精度的数值。如果量化步长选得太大比如用0.1mm作为最小单位那某些微小尺寸比如0.05mm的公差带就会被直接吞掉。我的经验是离散化时对尺寸小、相对误差敏感的参数比如圆角半径、薄壁厚度要用更高的精度表示。token空间不够的话可以对这些参数单独建立一个回归头而不是一刀切地走序列生成。5.3 推理速度慢到不可用该怎么优化text-to-cad模型的一次完整推理通常包含文本编码、CAD token序列生成、CadQuery执行三个步骤。如果每个步骤都按最朴素的方案来做端到端推理时间可能要30秒以上。对交互式应用来说这完全不可接受。我试过的优化手段里效果最显著的一个是给CAD token序列生成引入分阶段解码。不是一次生成全序列而是先生成草图阶段的序列再生成特征阶段的序列。草图阶段和特征阶段之间有明确的依赖关系分阶段解码可以让模型在生成特征阶段时看到已经确定的草图上下文减少无效搜索。这个改动配合知识蒸馏后的轻量化文本编码器能让推理时间从30秒压到5秒左右。另一个优化点是KV Cache的维护。生成CAD序列时每个特征内部有一定的自注意力依赖但在不同特征之间相对独立。可以用类似block-attention的方式压缩跨特征注意力减少显存和计算消耗。这个方法在实测中能带来20%到30%的加速且对精度几乎没有影响。5.4 如何把模型接到现有CAD工作流最后聊一下部署层面的问题。一台本地工作站上训练好的text-to-cad服务怎么接到企业现有的CAD工具链里我总结了两个稳妥的套路。第一种是“中间文件交换”模式。模型生成STEP文件然后通过STEP格式导入到SolidWorks、Fusion 360或者FreeCAD。这个方案实现成本低通用性最好缺点是STEP文件是“死模型”导入后特征树是空的没法做参数化修改。第二种是“脚本驱动的原生模型生成”模式。模型直接输出CadQuery代码或者对应软件的API调用代码然后由CAD软件执行脚本生成原生模型。这种模式下特征树完整保留所有参数都可编辑。缺点是需要针对不同CAD软件做不同的代码适配。我建议初创团队优先选第一种模式把自己的AI能力包装成插件挂载在主流CAD软件的命令行接口上快速验证市场。等到有明确付费用户了再考虑第二种。不要一上来就想着打通所有CAD平台那会陷入无止境的兼容性泥潭。6. 后续可以怎么扩展从单零件到装配体再到设计助手现阶段text-to-cad大多数方案关注的是单个零件的生成而且以机械加工特征孔、槽、倒角、螺纹为主。我比较看好的扩展方向有三个。第一个方向是从零件到装配体。输入文本变成“一个法兰盘用四颗M8螺栓固定在底板上中间有导向定位销”这需要多实体生成能力和装配关系规划能力。技术难度比单零件高一个量级但工业界对这个能力的需求大得多。想想看非标设备设计中大量的“标准零件组合”工作如果能把装配级生成做出来那才是真正的生产力革命。第二个方向是融合仿真分析。文本描述里可以直接携带性能约束比如“一个支撑架结构刚度不低于某某值重量小于某某克”模型在生成CAD模型的同时给出仿真结果。这个方向需要text-to-cad模型和有限元分析做端到端的联合优化本质上变成了生成式设计。虽然短期内做不到但我判断三到五年内有希望出现初级版本。第三个方向是逆向交互。现在的接口是“一句话生成模型”下一步应该是“一句反馈修改模型”——比如“改大孔直径”、“孔往左移两毫米”、“把圆角去掉换成倒角”。这需要模型具备局部编辑能力而不只是重新生成整个模型。我在实验中发现这可以通过给模型额外输入“当前模型的token序列摘要”来部分实现但距离工程可用还有距离。我个人的体会是text-to-cad真正能普及的临界点不在于模型能不能生成足够复杂的形状而在于它生成的模型能不能无缝融入现有设计流程。这个融入包括特征树完整、参数可驱动、工程规范符合、支持后续编辑。做AI的人容易只盯着“生成效果”这一个指标但从制造业一线工程师的视角看能不能改、好不好改往往比“像不像”更重要。