如果你最近同时在关注AIGC和工业软件这两个圈子大概率会在某个技术新闻或者论文推送里撞见 text-to-cad 这个词。第一次看到它的时候我第一反应是这不就是把一句话翻译成一堆几何体吗能有多难后来自己动手把几个开源项目跑了一遍才发现这里面的坑比我预想的多得多既要处理自然语言的歧义又要保证生成结果能被CAD软件正常打开、编辑、再导出中间涉及的环节根本不是“文本生成一个模型文件”这么简单。text-to-cad 的核心目标很直白让用户用自然语言描述一个零件或结构系统自动生成对应的CAD模型、建模操作序列或者可编辑的CAD文件。它适合的读者也很明确——如果你是做机械结构设计、非标自动化、产品外观构思或者你是搞AI应用开发的工程师想给工业设计工具加上“说话就能建模”的能力这个方向都值得花时间了解。这篇文章不打算只做概念科普我会把技术流派、底层原理、开源项目、踩坑经验都摊开来讲最后给出我自己实操下来的判断。1. 核心定义text-to-cad 到底在做什么1.1 一句话解释与三种落地形态打个比方传统的CAD建模是“手工雕刻”你打开SolidWorks或者Fusion 360选基准面、画草图、拉伸出体、倒角、打孔每一步都要亲手操作。text-to-cad 想做的是“口述加工”你说一句“做一个直径50毫米、高度30毫米的空心圆柱壁厚3毫米”系统直接把对应的建模过程做完甚至直接给你一个可以继续编辑的文件。但要注意“生成CAD模型”这个描述太笼统实际落地时有三条明显不同的路线直接生成模型文件用深度学习模型输出体素、点云或者隐式曲面再通过后处理转成STL、STEP这类格式。这条路看着最“AI”但生成的模型往往只是“长得像”没有参数化特征树后期改尺寸很痛苦。生成建模操作序列模型输出一个类似“画圆→拉伸→倒角”的指令序列目标是让CAD内核或者脚本环境按顺序重新执行一遍。这条路生成的结果保留了特征历史是我个人最看好的方向。生成代码/宏让大模型直接输出AutoCAD的AutoLISP、FreeCAD的Python脚本、OpenSCAD的代码或者某个CAD软件的API调用。这条路工程上最容易落地因为不涉及训练模型只需要把大模型的代码能力用好。所以如果你跟别人介绍text-to-cad建议先说清楚是哪种形态。不同形态的技术难度、实用价值和适合的团队完全不一样。1.2 为什么这个方向值得关注我自己的判断是text-to-cad 之所以在近两年爆发不是因为某个单一技术突然突破了而是三条线刚好汇到了一起。第一条线是大语言模型带来的语义理解能力。GPT系列和开源模型让机器在“听懂人话”这件事上达到可用水平这是最基础的底座。第二条线是CAD数据的数字化积累。过去十几年各大软件厂商和学术机构积累了大量标注好的三维模型库和建模历史数据比如公开的零件数据集里包含几百万条“草图拉伸倒角”的操作日志这些数据用来训练操作序列生成模型刚刚好。第三条线是三维生成模型的成熟。像点云扩散模型、NeRF、隐式曲面这些技术在视觉领域已经证明了能力自然语言到三维的跨模态生成也就有了技术参考。三股力量合流之后“文本到CAD”就从一个实验室里的玩具变成有实际落地可能的工程问题。对于做设计的人来说它能缩短从“想法”到“第一个可用模型”的时间对于做AI平台的人来说它是一个比“文生图”更难也更有商业壁垒的垂直方向。我甚至觉得这个方向的长期价值不亚于编程助手因为三维设计软件的用户基数虽然比不上程序员但单个用户的付费意愿和工具链迁移成本都很高。2. 技术流派与开源项目盘点2.1 生成式建模从文本直接到模型先聊学术界最活跃的一派直接用神经网络生成CAD模型。这类工作绕不开一个绕不开的起点——DeepCAD。它提出了一个非常关键的思路把CAD建模过程拆解成“草图平面、二维曲线、拉伸、布尔运算、圆角、倒角”这样的参数化操作序列然后像处理自然语言一样把整个操作序列token化训练一个自回归Transformer。简单说就是让模型学会“读一段建模历史再写出下一段建模历史”。在此基础上后来出现了Text2CAD这个典型项目。它的设计思路是双编码器结构一边用预训练语言模型把文本描述编码成语义向量另一边用另一个编码器处理CAD操作序列然后通过对比学习把两者拉进同一个向量空间。推理的时候用户输入一句话文本编码器算出语义向量模型在这个向量条件下逐步自回归地生成CAD操作序列最后调一个CAD内核把序列执行成实体模型。这类方案的优点是上限高生成的模型带有完整构造历史用户拿到手还能回到CAD软件里改尺寸、改草图这是纯几何生成做不到的。缺点也很明显——训练成本高、数据要求大而且推理速度不如直接输出网格快。目前公开的论文里这类方法能稳定生成的模型复杂度还比较有限适合做简单机械零件一遇到自由曲面、复杂装配体就容易露馅。2.2 代码/宏生成让文本驱动建模命令另一条路我管它叫“LLMCAD API”路线。核心想法很朴素不训练专门的模型而是把大模型当作一个能写代码的机器让它输出目标CAD软件能执行的脚本或宏。比如有人用GPT系列模型生成OpenSCAD代码OpenSCAD本身就是一种用编程语言描述三维几何的工具模型只要学会生成合法的模块化代码就能直接得到模型。还有人在FreeCAD层面做二次开发让大模型输出Python脚本调用FreeCAD的Part模块、PartDesign模块完成建模。比较典型的工作是CAD-CLM它探索了如何让大语言模型在CAD的命令行层级生成操作指令把复杂的建模流程拆成一条条可执行的命令序列。这条路的工程可行性最高因为不需要准备海量训练数据、不需要跑大规模训练任务开箱即用。问题在于稳定性和可控性大模型生成的代码经常有语法错误、参数越界、几何引用错误必须靠外部的校验和重试机制兜底。我实测下来的感受是对于“创建圆柱、打孔、做矩形阵列”这类常规操作成功率还算能接受一旦涉及复杂的关联约束比如“让这个孔的圆心始终与那个边的中点保持重合”模型就很容易翻车。2.3 检索与约束求解偏工程的轻量方案还有一类更偏工程的方案严格来说不算生成但产品上常被归到text-to-cad里检索参数化模板。做法是先建立一个零件库每个零件都带有文字标签、参数化模板和约束关系。用户输入一句话系统先做语义检索匹配到最相似的零件模板然后用大模型或者规则抽取用户文本里的关键参数比如长度、直径、孔径、数量填入模板生成最终模型。这种方案特别适合标准件、常用件这类“有大量历史数据和明确参数表”的场景比如生成不同规格的螺栓、法兰、轴承座。它的优势是稳定可靠、速度快几乎不会出现几何错误劣势是只能覆盖模板库里的类别遇到没见过的结构就无能为力。在我看来真正的产品级text-to-cad最后大概率是这三种方案的组合模板检索做兜底代码生成做灵活建模操作序列生成做高上限的新模型。单押任何一种都是偏科。3. 核心原理CAD 为什么那么难让AI学会3.1 CAD数据的“历史记录”特性要从根上理解text-to-cad的难点得先明白CAD数据和普通三维模型数据有一个本质区别普通三维模型比如OBJ、STL、PLY只有“结果”没有“过程”。它们是三角形网格或者点云描述的是模型表面的几何形状而CAD文件比如STEP里带的BREP数据除了结果还保留了建模的“历史记录”——这个凸台是从哪个草图拉伸出来的、那个圆角是在哪个边上生成的、倒角半径是多少。这个区别直接决定了两类生成模型的难度。文生图领域可以容忍“生成的图像看起来像”就算成功因为图片本身就是最终形态但CAD如果只生成一个“看起来像”的网格工程师拿过去没法修改、没法做装配、没法再设计价值就大打折扣。所以真正有用的text-to-cad要求模型生成的不是“形状”而是“一个可复现、可编辑的建模流程”。这相当于要求AI不仅会画画还得会告诉你每一笔是怎么画出来的、用什么颜料、用了什么笔法。这也是为什么直接借用图像领域的扩散模型去做CAD效果不好的原因——扩散模型擅长学习高维几何分布但它不擅长学习离散的、强约束的操作序列。你让扩散模型生成一个椅子点云它生成得很漂亮你让它生成一个带精确直径和同轴约束的法兰它就懵了。3.2 中间表示把建模操作变成token为了把“建模流程”交给Transformer学术界想出的关键招数是“中间表示”。DeepCAD贡献最大的一点就在这里它定义了一套CAD建模的序列化格式把常见的建模操作抽象成一系列参数化节点。举个简化例子一个空心圆柱的建模序列可以表示成开始 - 在XY平面建立草图 - 画一个圆心在(0,0)、半径25的圆 - 退出草图 - 拉伸30毫米 - 在同一平面建立草图 - 画一个圆心在(0,0)、半径22的圆 - 退出草图 - 拉伸30毫米 - 执行布尔求差 - 倒角可选 结束这套序列里每个节点都有类型和参数比如“圆”节点需要圆心坐标和半径“拉伸”节点需要深度和方向。把所有节点映射成离散token再把数值参数拆成整数序列或小数序列就得到一串和自然语言长得差不多的token序列。然后就可以拿来训练一个标准的因果语言模型——输入前n个token预测第n1个token只不过这次的“语言”是CAD建模语言。中间表示方案要成功还得解决两个额外问题一是参数数值的token化。CAD里面的尺寸往往有小数精度比如半径25.637毫米直接当一个token会导致词表无限大所以一般要数字化成科学计数法、定长整数形式或分桶离散化。二是序列的合法性。模型的输出可能在语法上是合理的但语义上不合法比如拉伸高度为负数、布尔操作的对象不存在这就需要在推理后加一个合法性校验器。3.3 跨模态对齐文本与CAD序列的翻译问题模型学会了生成CAD序列但还没学会“听人话”。要让自然语言能控制CAD序列的生成需要做跨模态对齐。Text2CAD那类项目采取的方式是给每一条CAD序列配一句自然语言描述然后把文本编码器和序列编码器做对比学习。通俗讲就是让模型看“这句话”和“这段建模操作”是不是描述同一个零件。经过这样的训练文本编码器输出的语义向量和CAD序列编码器输出的向量会在同一个空间里逐渐对齐。推理的时候系统用用户输入的文本算出向量再作为条件引导CAD序列解码器逐个生成token。实际操作中为了让对齐效果更好往往还要加一层指令微调把“描述文字对应CAD序列”拼成一段训练样本让模型学会“看到这条指令就输出对应的序列”。这个步骤非常吃数据质量——公开数据集里CAD序列很多但配套的自然语言描述比较少所以不少团队会自己写一批模板句比如“创建一个宽度为X的槽”再做数据增强把描述里的量词、顺序、同义词替换一下。跨模态对齐里最容易翻车的点是“文本明明说的是这个意思模型却理解成另一个意思”。比如用户说“做一个带法兰的管”模型可能只生成了一个管子忘了法兰或者把“带法兰”理解成了一个圆盘而非管口端的凸缘。这类问题归根结底是训练数据里关于“法兰”的文本-序列配对不够多样模型没有学到“法兰”这个概念的几何对应关系。4. 实操过程跑通一个 text-to-cad 最小示例4.1 环境准备依赖与数据来源这一章节我以一个典型的开源复现流程为例给大家讲清楚text-to-cad从环境准备到拿到模型文件的完整链路。先说清楚不同项目脚本差异很大我这里按最常见的技术栈来写你拿到别的项目也能举一反三。文本到CAD的项目大多基于PyTorch建议直接用conda创建环境conda create -n text2cad python3.10 conda activate text2cad pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install transformers datasets tqdm numpy如果你只想做推理不需要训练那CUDA环境不是必须的CPU也能跑只是速度慢一些。数据方面最常用的公开数据集是DeepCAD数据集里面有大量的CAD建模序列。部分项目会提供处理好的子集下载的时候优先选择带“text description”标注的版本不然你还得自己给序列配文本那是额外的工作量。开始之前建议先检查GPU显存。我自己的经验是8G显存只能跑最小的配置batch_size调到8以内模型维度压缩到128想要训练出能泛化的效果至少需要24G以上显存。用云GPU按小时付费反而是最划算的训练小规模模型也就跑几个小时。4.2 数据预处理与模型训练简化流程拿到原始数据后第一步要做的是转换成统一的中间表示。假设数据是一个JSON文件每条记录包含“sequence”字段里面是一个包含多个操作的列表。预处理脚本的核心逻辑类似def parse_cad_json(cad_data): tokens [] for cmd in cad_data[sequence]: op map_op_to_token(cmd[name]) # 例如 extrude 映射成 5 tokens.append(op) for param in cmd[params]: tokens.append(float_to_discrete(param)) # 数值离散化 return tokensfloat_to_discrete这一步我建议用保留两位小数乘以100取整的方式不要直接用原始浮点因为浮点数在语言模型里很难学而且容易因为极小扰动导致几何失效。预处理后把tokens序列和对应的文本描述如果数据集里有组装成训练样本文本部分用分词器处理成另一个id序列。训练时模型一般由一个文本编码器和一个自回归Transformer解码器组成。文本编码器可以是预训练的BERT或T5的encoder解码器用GPT风格的causal模型。loss就是标准的交叉熵只算CAD序列部分的token文本部分的token不参与loss计算。一个值得注意的细节是CAD序列里的几何坐标token在训练中权重占比很大如果数据集里小尺寸零件和特大尺寸零件分布不均模型很容易偏向生成常见尺寸我后来在loss里做了分桶加权才缓解了这个问题。4.3 推理、后处理与导出常见格式训练完模型推理阶段通常是这样的输入文本经过文本编码器得到条件向量再由自回归解码器逐token生成CAD序列。解码的时候必须加合法性过滤——比如这一步输出的token如果是一个“拉伸深度”但模型给了一个负数直接弹回把概率第二大的token顶上。这个策略比事后校验省事得多因为事后校验往往不知道该改成什么值而解码期过滤可以直接换候选。生成完CAD序列之后就进入后处理环节。最常见的做法是写一个脚本把序列“翻译”成具体的几何建模命令比如调用CadQuery这个Python库来重建实体模型import cadquery as cq result ( cq.Workplane(XY) .circle(25) .extrude(30) .faces(Z) .circle(22) .cutBlind(-30) ) cq.exporters.export(result, output.step)CadQuery是我目前用过最顺手的后端它能把建模操作链直接映射成程序命令和中间表示的“草图-拉伸-布尔”结构天然契合。导出格式优先选STEP因为它保留精确几何和部分语义信息后续导入FreeCAD、Fusion 360、SolidWorks都不会丢面如果只需要3D打印导出STL也行但再编辑就基本不可能了。我试用过的一个简化流程里从输入“创建一个外径50毫米、内径44毫米、高30毫米的套筒”到生成STEP文件整个推理过程大约20秒其中模型推理只占3秒大部分时间花在后处理和STEP导出上。这个速度已经达到了可以嵌入交互式工具的水平。5. 常见问题与排查技巧实录5.1 语义歧义一句话可能对应十种建模方案text-to-cad碰到的第一个拦路虎不是模型而是语言本身。同一个描述不同工程师脑子里想的可能是完全不同的结构。比如“做一个支架”什么是支架L型折弯板是支架带加强筋的三角支撑也是支架甚至一个简单的矩形框加四个安装孔也可以叫支架。模型训练时如果只给一个标准答案它就会学得特别死板。我建议在准备训练数据的时候对每条CAD序列配上多条语义等价的文本描述比如“做一个侧边带孔的方盒”和“在方盒侧面打一个孔”应该指向同一类模型。推理阶段如果用户输入过于笼统可以在界面上给几个“候选歧义问题”让用户选到底是哪种结构。这是产品设计层面的兜底但比死磕模型要高效得多。5.2 单位、精度与坐标系问题CAD不同于文生图尺寸是硬指标。用户说“做一个长100的板”到底是100毫米还是100英寸模型生成的坐标到底落在第一象限还是直接出了工作范围这些在实际跑通流程的时候全都会遇到。我踩过的坑是数据集里的尺寸范围太窄。如果训练数据基本都是毫米级的小零件模型就学不会生成米级的大结构如果坐标基准类型单一模型生成的模型就会偏向某个象限。解决办法是在预处理的时候做数据增强——把整个模型绕Z轴旋转几个角度、把尺寸归一化到一个标准范围、必要时整体平移。我在一个项目里还做过坐标抖动给坐标token加上很小的随机噪声这对防止过拟合有明显帮助。执行CAD操作的时候还要考虑精度有些模型生成的坐标落在了STEP文件的不精确位置上导出时会出现0.001毫米级的微小碎面后期在CAD软件里做布尔运算时报错。碰到这种情况最有效的排查方式是在导出前做一轮“几何净化”把距离过近的点合并把重复面去掉。5.3 模型训练期的“幻觉”与数据泄漏和纯文本模型一样CAD序列生成模型也会“一本正经地胡说八道”。常见表现是生成序列在语法上完全没有问题但几何上根本没法构建比如拉伸方向不一致、布尔操作对象缺失、草图上引用了不存在的点。这类问题我通常用两步来解决。第一步是在训练loss之外加一个“拓扑合法性”辅助loss做法是在解码器的隐藏层上面接一个小分类头判断每个操作在当前状态下是否合法。这个小分类头不增加太多计算量但能让模型在采样的时候少走弯路。第二步是推理后强制验证生成完序列后用CadQuery直接执行一遍如果抛异常或者生成结果体积为零就换一个随机种子重新采样。最多试3次还不行就把这条文本丢到“需要人工介入”队列。这个方法很笨但实测能把成功率从60%左右提升到85%左右。数据泄漏是个更隐蔽的问题。如果数据集在划分训练/测试集时按“随机打乱”来做同一个零件家族的不同变体很可能同时出现在训练和测试集里导致模型看起来分数很高一碰到新结构就拉胯。正确做法是按“零件类别”或“来源文件”划分比如一个装配文件下的所有零件只能同进同出。5.4 CAD软件侧导入与再编辑的兼容性很多人在开源demo上生成模型很顺利一导入商业CAD软件就出问题。最常见的原因是STEP文件里没有带特征树信息只有BREP面片数据结果用户在SolidWorks里打开后发现特征管理器是空的整个模型是一块“死模型”想改一个孔的直径都无从下手。这个问题的根源在于STEP格式主要保存边界表示BREP而各CAD软件的特征历史Feature Tree是私有格式。AI模型如果直接输出STEP哪怕几何完全正确也丧失了“可编辑性”。要解决它有两条路一是让模型输出“建模操作序列”并在CAD软件里通过API把这些操作重放一遍生成原生特征二是输出各软件的中间交换格式比如Fusion 360的Fusion Archive、SolidWorks的FeatureManager设计树数据。目前开源方案大多走第一条路也就是用CadQuery这类脚本库重放操作但脚本库生成的模型导入商业软件后特征仍然可能被简化。所以如果你要做一个对设计师友好的产品一定要在架构设计阶段就想清楚生成结果交付的是“纯几何”还是“可编辑特征”。后者难度大得多但用户体验完全不同。6. 经验总结从工程师角度聊聊实用边界6.1 哪些场景真正适合现在就用text-to-cad经过一段时间的实际使用我的判断是现在的text-to-cad技术还远没到“全能设计师”的水准但它已经可以在特定场景里帮人省下大量重复劳动。最适合的场景是第一轮方案草图。接到需求说“做一个直径30、高50的圆柱底座中心打一个直径10的通孔”手工建模要一两分钟text-to-cad几秒钟生成虽然还得人工检查一遍但整体效率提升明显。第二个适合的场景是参数化标准件生成比如不同管径的法兰、不同规格的轴承座只要模板库里覆盖过生成的稳定性和速度都很理想。第三个场景是给已有的简单模型做“变体”你说“把原来的板加长20毫米再加两个直径8的孔”模型在原有序列基础上做修改比从零建模靠谱得多。不适合的场景我也要泼一盆冷水复杂的自由曲面造型比如汽车内饰、消费电子外壳、大型装配体的协同建模、高精度的工程配合比如公差标注、表面粗糙度这些目前都不是text-to-cad的菜。别指望AI现在能给你一个能直接拿去开模的模具图那是误把自己和未来两三年后的技术作对比了。6.2 我的下一步玩法与工具链建议如果你看完文章想自己上手我建议按这个顺序来先跑通一个生成代码的路线比如让大模型输出OpenSCAD代码这个门槛最低一天就能看到效果然后试试生成CadQuery脚本熟悉一下中间表示和后处理的配合最后再碰训练类项目。训练一个text-to-cad模型确实需要资源和时间但如果你手里有特定行业的零件数据那自训练的回报会非常大因为通用模型对你所在领域的行话理解一定不如你喂出来的专属模型。工具链个人推荐的是“开源模型自家数据CadQuery后端”组合再加一个Python FastAPI服务层做封装前端接一个对话框。用户输入描述、点击生成、预览模型、导出STEP这个流程在体验上已经接近一个可用的MVP。最后再分享一个小技巧训练数据的文本描述不要只写“圆柱体”“长方体”这种机械名词要多写“安装在电机底部的支撑座”“用来固定线束的卡扣”这样的功能性描述。模型见多了功能描述之后才能在面对“给传感器做一个安装支架”这种开放性指令时推理出传感器支架大概是什么结构。这个点是我在多次实验后最强烈的感受——text-to-cad模型的“设计直觉”本质上还是来自于它看到过多少“带意图的建模故事”。