最近几个月，AI生成3D模型的讨论热度一直没降，但真正让我觉得“有点意思”的，是text-to-cad这个方向。它跟文生图、文生视频不一样，不是给你一个渲染出来的“好看的形状”，而是直接给你一个参数化的、可编辑的CAD模型文件。这意味着，你从自然语言描述出发，拿到的不是一张图片，而是一个能放进SolidWorks、Fusion 360或者FreeCAD里继续改、继续出工程图的东西。这篇文章，我想从实际工程视角来聊聊text-to-cad到底能做什么、底层怎么实现的、现在有哪些能跑通的方案，以及我在折腾过程中踩过的坑和总结的经验。
我先把结论放在前面：text-to-cad目前还没有成熟到“输入一句话就直接出符合国标图纸”的程度，但在概念设计、方案验证、零件初稿生成这类场景，它已经能实打实地节省时间。适合的人群包括机械设计工程师、产品设计师、自动化设备开发者，还有做AI应用落地的人。如果你期待的是“一句话生成可开模的塑料件”，那还早；但如果你需要的是“一句话生成一个带参数特征的毛坯模型”，现在已经有几条路可以走了。
1. 整体思路拆解：为什么text-to-cad比你想的更复杂
1.1 它到底解决了什么核心问题
传统CAD建模的痛点很明显：一个稍微有点复杂度的零件，哪怕是一个带加强筋、安装孔和倒角的支架，熟练的工程师也要花十几分钟甚至更久。如果再算上查阅标准件尺寸、计算配合公差、调整草图的完全约束状态，整个建模流程是相当耗时的。而text-to-cad想做的事情，是把“自然语言描述”直接映射成“参数化建模操作序列”，跳过人工逐步操作CAD软件的过程。
这个想法听起来跟文生图类似，但本质难度完全不同。文生图输出的是一堆像素，尺寸错了、透视崩了，人眼不仔细看看不出来，而且图片本身没有“可编辑性”的要求。CAD模型不行，它必须满足几何上的严格约束：面与面之间要闭合、边线要能倒角、特征之间不能自相交、拉伸体必须有明确的草图和方向。换句话说，text-to-cad生成的对象必须是一个“合法的实体”，而不只是一个“像那么回事”的形状。这个要求让生成难度提高了一个量级。
1.2 为什么用大语言模型来做CAD生成
几年前也有text-to-3D的方案，比如把文本编码成向量，再用生成对抗网络或者扩散模型输出体素或者点云。这些方案的问题在于，它们生成的是“离散的几何表达”，体素分辨率高了算不动，低了呢全是锯齿；点云虽然灵活，但后续要转成B-rep（边界表示）非常麻烦。而且无论是体素还是点云，输出都不是参数化特征，用户拿不到草图、拉伸深度、旋转角度这些“可编辑的参数”。
后来大家发现了一个关键点：CAD建模过程本身就可以看作是一段“程序”。你在SolidWorks里画一个草图、拉伸出凸台、再切一个孔，这些操作在底层都有对应的API调用序列。如果把建模历史记录下来，它本质上和一段代码没有区别。而大语言模型最擅长的恰恰是序列生成。于是思路就变成了：把CAD模型编码成一串操作序列，让LLM去预测这个序列——就像让它写代码一样。这等于把一个几何生成问题，转换成了一个代码生成问题，既绕开了离散几何的精度问题，又天然保留了参数化可编辑性。
1.3 这个方案的优势与代价
这个“LLM+序列生成”的路子，核心优势有三点。第一，输出结果直接是B-rep或者命令序列，可以无缝导入现有CAD软件继续编辑，不用做繁琐的格式转换。第二，因为LLM见过海量的代码，它对“先拉伸再打孔”这种逻辑性操作有天然的理解力，比从零训一个专用生成模型要容易上手。第三，用户可以通过修改文本来迭代模型，比如加上“底壁加厚2毫米”，得到的结果也会相应调整。
代价也很实在。第一，推理成本高，生成一个中等复杂度的零件可能要几十秒到几分钟。第二，数据稀缺，高质量的CAD模型加自然语言标注的配对数据，到现在也没有公开大规模数据集。第三，生成的模型需要后处理校验，不是每次都能保证实体合法性。这些代价意味着text-to-cad目前更适合做“生成初稿”，而不是“一步到位”。
2. 核心细节解析：主流技术路线与关键环节
2.1 CAD命令序列的编码方式
要让LLM理解CAD建模，首先得把建模过程变成一串它可以处理的token。目前比较有代表性的是DeepCAD数据集的做法：建模操作被归类为草图、拉伸、旋转、扫掠、圆角、倒角等基础特征，每个特征有参数，比如拉伸深度、旋转角度、圆角半径，再加上草图的几何参数（直线、圆弧、圆等元素的位置与尺寸）。然后把这些操作和参数转成固定格式的ID序列，模型只需要预测这一串ID，就能对应得到完整的建模历史。
这里有一个细节值得展开：草图参数的处理。你不可能让LLM直接输出“一条从(0,0)到(10,5)的线”，因为实数值的预测对LLM来说精度不够。实际做法是把连续数值离散化成若干个bin，每个bin对应一个token。比如把一个长度范围0到100毫米均匀切分成1024份，模型只需要预测“第512个bin”对应的token，反算回来就知道是50毫米左右。代价是精度受限于bin数量，这也是为什么生成结果经常需要手动微调尺寸的原因。
2.2 条件生成与训练策略
模型结构上，目前的主流做法是采用Transformer解码器，输入是自然语言描述对应的文本token序列，输出是CAD命令序列。训练时用的是teacher forcing：每一步都拿真实的上一帧token作为输入来预测当前token，配合标准的交叉熵损失。推理时就可以自由生成，直到输出结束标记或者达到最大长度限制。
还有一个重要问题是“条件注入”的方式。有些实现是把文本描述直接拼接在建模序列前面，用同一个Transformer处理；有些则是用单独的文本编码器提取特征，再通过交叉注意力注入到解码器。两种方式各有优劣。拼接方式简单直接，但对长文本支持不好；交叉注意力方式对文本的理解更充分，但训练复杂度和显存消耗更大。从实际效果看，拼接方式在短描述场景下已经够用，这也是很多开源实现的首选。
2.3 数据后处理与拓扑合法性校验
这是整个流程里最容易被忽视但又最关键的环节。序列生成出来的CAD命令，如果直接执行，经常出现草图不自相交但拉伸后自相交、圆角半径大于特征尺寸、切孔把实体切穿但目标面不存在等问题。因此，常规做法是在执行序列时逐条检查：每执行一步操作，都要用几何内核校验实体的有效性。如果某一步失败，常见策略是跳过该操作或者尝试缩小参数范围重新执行。
这一步的意义在于，它把纯模型的概率输出变成了“带约束的几何构造过程”。从工程角度看，宁可少生成几个特征，也不要生成一个坏实体。我在实际测试中就遇到过不少模型“看似聪明地生成了一个带阵列孔的法兰盘，但打开后发现孔的数量与位置跟描述对不上”的情况，这就是后处理校验没到位的结果。
3. 实操过程：把text-to-cad真正跑起来的几种路线
3.1 路线一：基于开源项目复现完整训练
如果你想自己训练一个text-to-cad模型，目前最值得参考的开源项目是Text2CAD和CAD-MLLM。前者是纯文本生成CAD命令序列的标准化实现，后者是融合了多模态能力的进阶版本。这里我以Text2CAD为基础，梳理完整的实操流程。
环境配置方面，建议使用Ubuntu 22.04、CUDA 11.8以上、PyTorch 2.x，GPU最好有24GB以上显存。虽然显存小也能跑，但batch size受限严重，训练效果会打折扣。数据方面需要下载DeepCAD数据集，里面包含大约17万个机械零件模型及其对应的命令序列。
训练过程按以下步骤来组织：
- 预处理：将DeepCAD原始数据转成指令序列，固定操作token数量，过滤掉无法解析的样例。这一步比较耗时，一个正规的预处理流程大概要跑几小时。
- 构建词表：统计操作类型、参数bin、草图元素的全部取值，生成统一词表，确保文本token和CAD命令token在同一个嵌入空间里。
- 训练Transformer解码器：输入是“文本描述+命令序列前缀”，损失函数只计算命令序列部分的交叉熵，文本部分不参与loss。
- 推理生成：输入自然语言描述，解码出完整命令序列，然后调用后处理脚本执行并验证实体。
我在测试中遇到的最大问题是预处理阶段的数据清洗：DeepCAD里有一部分模型的草图附着面指向不明确，直接解析会得到非法实体。当时的处理方式是设置一个“合法性过滤阈值”，只有通过校验的模型才进入训练集。这个过滤比例大概有15%到20%，别嫌浪费，脏数据训出来的模型一生成就崩。
3.2 路线二：调用现在可用的API，快速落地验证
如果不想从零训练，现在也有几个成熟的API方案可以接入。比如Zoo.dev的text-to-cad API，内部是基于他们自研的几何内核和数据集训练的，输入文本描述，返回STEP或B-rep文件。还有KittyCAD的相关接口，做同样的事情，只是侧重方向略有不同。
调用这些API的成本比自训低很多，尤其适合验证业务场景是否成立。我的建议是：先用API跑通端到端流程，确认你的场景确实需要text-to-cad，再决定是否要投入自研。API方式一天就能上线demo，而自研动辄数月，不值得为了“自己的模型”而盲目投入。
3.3 路线三：LLM+CAD软件二次开发，目前落地最稳的方案
这条路线被讨论得相对少，但它是我个人认为当下最落地、最快见效的路线，尤其适合已经有CAD软件使用习惯的团队。思路很简单：不用特地去训练一个CAD生成模型，而是直接利用通用LLM的代码能力，让它生成操控CAD软件的脚本。
举个例子，Blender Copilot这个项目就是这个思路的典型代表。它把Text-to-CAD转成了Text-to-Blender-API-Call：模型只需要生成Python脚本，通过Blender的bpy模块完成建模操作。由于Blender API已经封装好了从创建网格到布尔运算的所有功能，LLM要做的只是写对调用顺序和参数。
同样的思路也能用在FreeCAD、SolidWorks、Fusion 360上，这些软件都提供Python或宏接口。好处是LLM不需要理解复杂的CAD几何内核，只需懂API用法，而高质量代码生成恰好是LLM的强项。坏处是生成的脚本需要手动调试，而且每换一个软件就要换一套API知识。适合做内部工具而不是通用产品。
3.4 实操工作流实例
我整理了一个我最近在用的标准工作流，输入描述是“生成一个带四角安装孔和中心圆孔的方形法兰盘，边长80毫米，厚度8毫米，孔径5毫米，四个孔距中心40毫米”。这个描述很简单，但对精确性要求很高。
我用Zoo.dev API跑了一次生成，大约20秒后返回STEP文件。导入FreeCAD后检查，发现四个安装孔的位置确实在角上，但中心孔直径变成了5毫米而不是预期的“中心圆孔”。原因是模型把“孔径5毫米”关联到了中心孔，形成了歧义。后来我在描述里加了限定词，改成“四角螺栓通孔直径5毫米，中心通孔直径12毫米”，这次结果就完全正确了。
这个例子说明了prompt设计的重要性：CAD模型生成不像文生图，差了几个字结果就完全不对。用“特征+尺寸+位置”的三段式描述，成功率会高很多。
4. 常见问题与排查技巧实录
4.1 显存不够用，训练卡住怎么办
最常见的问题就是显存不足，尤其当你把batch size调到32或者输入序列长度超过1024时，24GB显存很快就会被打满。我的经验是先把序列长度限制在512以内，batch size从8开始慢慢调。如果显存还是不够，用梯度累积来模拟更大的batch。另外，建议开启混合精度训练，显存占用会降低接近一半，速度还有提升。在Text2CAD这类模型上，混合精度对生成质量的影响几乎看不出来。
4.2 生成的模型打开就报错或无法导入
频繁出现的情况是模型文件导入CAD软件后提示“无效实体”。这不是软件的兼容性问题，而是生成结果的拓扑确实不合法。排查思路分两步：先用网格或者可视化工具检查实体是否自相交，如果是，回看是不是某个特征的参数过大导致；再用几何内核的检查函数打印非法面ID，定位到具体的失败步骤。通常在命令序列后处理的步骤里，加入“每一步执行后校验实体”的逻辑能拦截90%以上的问题。比如拉伸深度超过毛坯尺寸，直接截断到毛坯厚度，就能避免生成悬空特征。
4.3 中文描述支持差，怎么处理
现在公开的text-to-cad模型训练数据几乎全是英文，中文输入直接跑效果很差。我的方案是加一层“翻译预处理器”：先用通用LLM把中文需求翻译成英文的工程描述，再用翻译后的文本去生成CAD模型。这个方法实测下来比中文输入的效果提升非常明显。也别想着去微调一个中文模型，数据稀缺，成本高，收益不值得。
4.4 生成结果像个“抽象派”怎么办
如果你生成的模型跟你脑子里想的完全不像，大概率不是模型太笨，而是描述本身太空泛。比如“一个支架”这种描述，模型会给你一个默认形状，但不一定是你想要的。优化方式是尽可能描述功能、载荷方向和装配关系，比如“用于固定直径20毫米圆管的U型支架，底部带四个安装孔”。信息越具体，生成结果越接近需求。还得注意，描述里尽量避免“好看的”“牢固的”这类主观词汇，模型无法理解这种抽象修饰，反而会干扰参数生成。
4.5 生成速度太慢，影响迭代体验
速度问题要从两个层面看。第一是模型推理本身就慢，尤其是用了大尺寸LLM做条件编码时。这种场景可以用“先粗生成再精修”的策略：先用小模型快速生成低精度草案，确认方向和布局没问题，再用大模型或手工修改做最终精修。第二是后处理脚本执行慢，这通常是几何内核做布尔运算耗时太长。优化方式是在不影响逻辑的前提下减少操作次数，比如能用一次多轮廓草图拉伸，就不要拆成两步操作。
4.6 问题速查表
| 现象 | 可能原因 | 处理手段 |
|---|---|---|
| 显存溢出 | batch太大或序列太长 | 降低batch、缩短序列、开启混合精度 |
| 实体非法 | 特征参数越界、自相交 | 每步操作后校验实体，参数截断 |
| 中文描述差 | 训练数据为英文为主 | 增加中译英预处理层 |
| 结果与期望差异大 | 描述过于抽象或歧义 | 采用“特征+尺寸+位置”三段式 |
| 生成速度慢 | 模型大或布尔运算多 | 小模型快速初稿+手工精修 |
5. 当前方案的对比与适用场景选择
5.1 从训练成本、精度、可编辑性三个维度评价
| 方案 | 训练成本 | 生成精度 | 可编辑性 | 场景适配 |
|---|---|---|---|---|
| 自训练LLM生成命令序列 | 高 | 中上 | 高 | 定制化需求、批量生成 |
| 商业化API | 零成本启动 | 中高 | 高 | 快速验证、少批量使用 |
| LLM+CAD软件API | 低 | 取决于LLM | 中上 | 内部工具、脚本化工作流 |
自训练LLM生成命令序列是理论上限最高的方向，因为训练数据和模型结构都可以自己控制，也是唯一能和自有数据集深度结合的方式，但成本摆在那里。商业化API的优势是零基础设施接入，而且产商在数据侧和质量调优上做了不少工作，如果你只是偶尔生成一两个模型，用API就够了。LLM+CAD软件API的方式适合已经有现成软件环境、不想引入上游依赖的团队，操作起来很灵活。
5.2 如何结合自身需求做技术选型
我的判断标准就三条：第一，你是否有大量定制生成的需求？如果有，值得走自训路线；如果只是零星生成，别碰训练。第二，你的团队是否具备CAD软件的使用经验？如果有，走LLM+CAD软件API是最快见效的；如果没有，推荐直接试用商业化API。第三，你需要在生成后做深度特征编辑吗？如果需要，那输出请认准参数化命令序列格式，而不是网格或点云。
6. 这个方向后续还能怎么做
6.1 多模态输入的趋势
当前text-to-cad大多只处理纯文本输入，但工程现场经常是“一张草图加一句描述”的组合。CAD-MLLM这类项目已经在这条路上探索了：模型通过视觉编码器读取草图或参考图，再结合文本提示生成建模序列。对实际工程来说，这个方向很有价值，因为我们表达设计意图时很少只用语言，手势、草图、参考件都是信息输入。
6.2 强化学习与CAD语法约束的结合
LLM直接生成命令序列的另一个潜在优化方向是引入强化学习。当前模型训练用的是交叉熵，优化目标是“token预测准确率”，而不是“生成的实体是否合法可用”。如果能把实体合法性、约束满足度、设计合理性作为奖励信号，用强化学习来微调模型，生成质量有希望再上一个台阶。这个方向目前还在学术界探索阶段，但思路是清楚且值得关注的。
6.3 草图和3D模型的语料积累
制约这个领域发展的一个重要瓶颈仍然是数据。OpenAI和各个实验室都在推进带标注的3D模型数据库建设，比如Objaverse-XL、ABO、DeepCAD等，但带有自然语言描述和CAD建模历史的配对数据依然稀缺。数据如果没有本质突破，模型能力的天花板就会很明显。对于想投入这个方向的团队，做数据采集和标注，也是一个颇有价值的切入点。
7. 关于text-to-cad，我个人的几点体会
做了这些测试和尝试之后，我最大的感受是：不要把它当成“AI替代工程师”的工具，而是当成“实习生”来用。实习生可能一开始画的图纸不够规范、特征顺序比较乱，但方向基本是对的；你花几分钟改一改草图约束、修一修尺寸，出一版初稿的速度比从零开始建要快很多。这个定位一旦摆对了，text-to-cad的价值就很清晰了。
最后分享一个小技巧。如果你用语言描述模型，尽量把“单位”写清楚。很多生成结果的尺寸和预期不符，就是因为在描述里没有标注单位，模型自己猜了一个默认值。凡是涉及到长度、直径、厚度的描述，强制带上毫米或者英寸；能加小数就加小数，比如“厚度3.5毫米”优于“厚度3毫米多”，这能明显减少后期调整的工作量。这个习惯成本为零，但省下来的时间很可观。
