这个方向我从去年开始盯到现在text-to-cad算是把“一句话变成三维模型”这件事真正推进到了可落地阶段。它跟之前那些文生图完全不同不是给你一张看起来像那么回事的渲染图而是直接输出可以编辑、可以加工的参数化CAD模型。简单说你输入“带四个安装孔的方形底座中心有一个直径20毫米的圆孔”系统会给出一个包含草图、拉伸、打孔操作的完整建模过程导出的STEP文件能直接拖进SolidWorks或者Fusion 360里改参数。这玩意儿解决的痛点很直接传统CAD建模的学习成本高一个稍微复杂的零件新手光是搞明白草图约束就要折腾几天对非设计岗的工程师来说想快速验证一个结构方案又不想求人画图。text-to-cad能把这个过程从“几小时”压缩到“几秒”哪怕生成结果只是粗胚也能极大缩短前期沟通的循环。现在这个方向特别适合三类人关注一是做AI应用开发、想找新场景的工程师二是机械设计或产品设计领域想提效的从业者三是做3D打印和创客项目的玩家——用文字描述就能拿到可切片打印的模型这种体验一旦用上就回不去了。1. 整体设计拆解text-to-cad到底在做什么1.1 核心思路把三维建模变成“文本翻译”任务要理解text-to-cad先要放下一个思维定式CAD模型不是一堆三角面片而是“操作序列”。你在SolidWorks里画一个零件本质上是在执行一串带参数的指令——画一个矩形、标注尺寸、拉伸20毫米、在某个面上再画圆、切除。这些指令带有明确的先后顺序和几何参数就像一段程序。所以text-to-cad的技术路线就变得清晰了把自然语言描述映射成一段CAD操作序列。这个词法层面的转换比传统的文生图更接近“编译”而非“绘画”。一段中文描述“这是一个长100、宽50、高20的平板四角有直径8的通孔”对应的CAD操作序列大约是新建草图→画矩形起点0,0尺寸100×50→拉伸20→选择上表面→画四个圆位置分别靠近四个角→切除贯穿。这个思路我第一次看到的时候就觉得方向对了因为它解决了一个关键问题输出是可解释的。你用AI生成一个stl网格文件出来的模型不能改、不能编辑工艺上基本是死路但生成操作序列每一个步骤都是结构化的参数用户拿到手可以随便改尺寸、删除特征、重排顺序。这也是text-to-cad区别于普通“文本生成三维网格”方案的核心价值。1.2 两条技术路线的取舍生成式与检索式现在做text-to-cad主要有两条路一条是纯生成式用大模型直接预测CAD操作序列另一条是检索式先根据文本找一个最相似的现有模型再做局部修改。纯生成式的优势在于能做“无中生有”文本描述里包含的特征组合方式只要在训练数据里出现过模型就能组合出新的结果。劣势也很明显对罕见结构的泛化能力有限而且训练需要高质量的“文本-CAD序列”配对数据数据成本相当高。检索式的思路更讨巧先从库里找到语义最接近的模型再把文本作为修改指令让模型在已有模型上做局部编辑。这个方案在小规模场景下非常好用尤其是企业内部积累了大量历史图纸的情况——大多数新设计往往是对旧设计的改版做检索增强能稳定输出可用度很高的模型。我在实际项目中更倾向于混合路线先检索候选如果相似度不够高再走生成式兜底既能保证大部分场景的精度又不至于让用户等太久。关于这个方向之所以难做核心在于CAD操作序列的“离散长尾分布”——常用的操作拉伸、切除、打孔就那么几十种但参数组合空间是连续的同一个圆柱体可以用“画圆拉伸”实现也可以用“旋转体”实现这就给模型学习带来了歧义。所以数据预处理时统一操作表示、尽量消除多义性比单纯增加数据量更有效。2. 关键技术拆解数据、模型与训练细节2.1 数据从哪来MLCAD数据集与“文本-序列”配对所有做text-to-cad的人几乎绕不开MLCAD数据集。这套数据从Onshape公开模型库中整理而来包含大约17万组“CAD模型文本描述”的配对每个模型的描述词通常是一段简要英文比如“bracket with two holes”这种级别。它不像图片描述那么丰富却保证了文本和模型之间的对应关系是可靠的。拿到MLCAD之后第一件事不是直接训练而是做“序列化”就是把CAD模型转成一串格式化的操作指令。常见工具链是用CadQuery或Build123d这类程序化建模库把b-rep几何信息反解为草图、拉伸、旋转、镜像等高层操作然后输出成类似Python脚本的指令序列。这一步是整个流程里最容易出问题的地方反解出的序列能不能被CAD软件重新执行、参数是否完整、特征是否可编辑都取决于这一环的质量。如果你没有MLCAD也可以自建数据思路是“逆向”用CAD插件批量记录建模过程把每一步操作连同参数导出成JSON同时让设计师写一句功能描述。这个方法得到的数据对特定业务场景更友好缺点是成本高、节奏慢。我的建议是前期先拿公共数据跑通流程等验证出效果再投入资源做私有数据。2.2 文本编码与CAD序列生成转化全过程拆解模型结构上text-to-cad基本沿用“编码器-解码器”框架。文本侧用预训练语言模型比如T5、BERT或者更新的LLM底座提取语义向量CAD序列侧用Transformer解码器做自回归生成。这和你熟悉的大语言模型在机制上没有本质区别只是词典被换成了“CAD操作参数”的离散集合。参数怎么处理是个细节问题。CAD操作里的尺寸、坐标通常是浮点数比如“拉伸20.5毫米”如果直接转成离散token精度会受限于词典大小。社区里目前有两种做法一种是量化到固定精度比如保留一位小数有65536个候选值把数值映射成token另一种是延续文本生成的思路把数值当作文本直接生成依靠解码器预测连续数字序列。实测来看“数值文本化”的方法更稳尤其对整数尺寸模型学得又快又准。整个生成过程可以这么理解输入“一个M6螺丝的垫圈”这样的描述编码器把它理解成“尺寸不大、环形、厚度薄”的语义解码器一步步吐出一串token先画一个外径18的圆再画一个内径6.5的圆然后拉伸2毫米。每一步的token选择都受到前文约束最后得到的指令序列就是可编辑的建模脚本。3. 完整实操从零跑通一个text-to-cad项目3.1 环境准备依赖、硬件与模型选择实际动手之前先说硬件底线。text-to-cad虽然不像训练大语言模型那样吃天价显存但也不是CPU能轻松扛住的。我的经验是推理阶段一张24GB显存的消费级显卡比如RTX 4090或A6000足够跑主流的开源模型训练阶段全量微调至少需要4张80GB的A100/H100但如果用LoRA这种参数高效微调方案一张24GB卡也能训得动小规模底座模型。环境依赖建议按下面的组合来装这是一套经过验证的搭配操作系统Ubuntu 20.04/22.04记得把驱动装好推荐535或更新的版本Python环境3.10以上不建议用系统自带Python直接用conda建虚拟环境最省心深度学习框架PyTorch 2.1以上配合CUDA 12.x语言模型底座Hugging Face Transformers库选T5-base或者更大规模的Flan-T5作为编码器CAD内核CadQuery或OpenCASCADE用于执行生成的指令序列并导出STEP文件安装完依赖后先把开源项目拉下来跑一遍自带的示例看是否可以正常生成。我见过不少同学卡在环境阶段CUDA版本不匹配、Python包冲突、CadQuery的依赖没装全这些问题排查起来其实挺费时间但一次搞通后面就顺了。3.2 训练与推理的关键参数当你准备开始训练自己的模型时下面的参数设置可以直接作为起点参考。需要先说明这些数值来自社区常见的开源实践与我的实测经验不同数据规模下可能需要微调。先看训练侧的参数。序列长度建议设为512覆盖大部分中等复杂度零件的指令长度batch size看你显存余量24GB卡上设8~16比较安全再配合梯度累积达到有效batch size 32即可。学习率不宜太大建议在5e-5到1e-4之间如果用的是LoRA学习率可以放宽到1e-4到3e-4。优化器选AdamW权重衰减按0.01设置。训练时开启混合精度能把显存占用直接砍掉40%以上。损失函数方面基础的交叉熵损失就能跑通但在后期可以加一点“几何约束”辅助损失——对序列中出现的坐标数值做约束让生成结果在几何上更合理。推理侧的参数同样重要。采样温度设到0.1~0.3可以保证输出稳定因为CAD序列不像自然语言那样容许多样性输出必须是精确的操作指令用beam search比用随机采样更合适beam width设为4到8之间比较均衡太小容易出错太大会拖慢速度。此外做推理时建议给CAD操作序列加一点“语法约束”在每一步解码时只允许模型吐出合法的下一个操作类型这个逻辑写起来不难但能显著减少无效序列——我在早期版本里曾经一晚上生成200个模型有一半因为语法错误无法导入CAD软件加上约束之后错误率降到5%以下。3.3 生成结果的后处理从指令序列到可编辑模型模型推理完成后你拿到的是一段CAD操作序列通常表现为JSON或Python风格的结构化输出。这一步还没完后续要把它输入CadQuery执行生成真正的几何体然后导出成STEP或STL格式。我的建议是导成两个格式STEP格式用于后续在专业CAD软件里继续编辑STL格式用于快速查看和3D打印。要注意的是CadQuery生成的STEP文件放到SolidWorks里打开时通常默认是“智能特征”模式——也就是能识别并保留建模历史树。这一步能否成功直接决定了“可编辑性”是否成立当你看到特征树里有草图、拉伸、切除这样的节点说明整个流程闭环了。后处理阶段我遇到过的最大的坑是单位不统一。CadQuery默认是毫米一些生成模型在推理时把坐标当作英寸处理导入CAD后发现尺寸差25.4倍。后来我在指令序列里显式加入了一个全局单位字段所有尺寸后处理时统一转换为毫米问题就消失了。另一个经验是导出STEP文件前先做一次“实体校验”看是否能检测到完整闭合、无非流形边这个校验能帮你过滤掉大部分无效生成结果。4. 常见问题与排查心得用的时候才懂得坑在哪4.1 训练不收敛先查数据再查模型训练text-to-cad时遇到loss不降或者忽高忽低的情况大概率不是模型的问题而是数据预处理出了岔子。首先检查的是“文本-序列”对是否对齐——MLCAD数据集的原始格式可能和你的预处理代码期望的格式不一致解码的时候错位一条记录整个训练就乱了。其次是操作序列的分词方式。CAD语言里的token如果用空格简单切分会把“circle(10,20)”这样的整体当一个词模型根本学不到结构。正确做法是让分词器能够识别操作名、参数分隔符和数值符号把“circle”和“(10,20)”分开让模型逐步学会“看到操作名→输出参数”的模式。我建议直接按字符级BPE处理CAD序列实测比按词切分效果好很多。最后考虑模型本身的因素。如果你用的是大规模底座模型但只在小数据集上微调loss容易在一个平台期死活下不去。这时换成更小的底座模型或者加大dropout反而能改善。我在实践中发现Flan-T5-base在十几万条数据上的表现比直接用7B级模型更稳定因为底座太大数据量不够模型根本没有充分学习的机会。4.2 显存溢出混合精度与序列切分是两条路训练时显存溢出几乎是每个人都会遇到的。最直接的解决办法有三个开混合精度bf16/fp16、减小batch size配合梯度累积、把序列长度从1024降到512。如果这三板斧都用上了还OOM那就要从模型侧下手了——比如给编码器加一层梯度检查点牺牲一点训练速度换取显存空间。推理时OOM也是常见现象尤其是当beam search的beam width设置过大同时batch里塞了几个长序列的时候。我建议推理时动态调整batch size先算一下最长序列的显存开销用它来反推合理的batch大小而不是盲目填满显存。还有一个容易忽略的问题是CUDA Memory Fragmentation也就是显存碎片化。长时间训练后虽然总显存看似足够但无法分配出一整块连续空间。遇到这种情况不要重启训练先把pytorch的cuda caching allocator释放一下或者设置PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True来减少碎片基本都能解决。4.3 模型生成结果打不开八成是序列语法问题生成结果的“不可用”几乎是text-to-cad项目里最高频的投诉具体表现为STEP文件无法在CAD软件里打开、打开后是空壳、或者模型出现严重几何错误。排查思路按顺序来从高频原因到低频原因。第一步检查生成的指令序列本身是否完整有没有漏掉关键的草图基准面定义拉伸方向是否明确布尔操作的对象是否引用正确。第二步检查参数数值的范围如果坐标值出现几千上万通常是推理解码时数值token拼接错了比如少了一位小数点或者多位数字被截断。针对这个问题我建议在解码时对数值token加上语法约束只允许合法组合同时控制数值在一个合理的范围比如坐标不超过模型包围盒的两倍。第三步才考虑几何内核问题CadQuery执行时对某些特殊拓扑结构如自相交轮廓、零厚度特征会直接报错这类错误通常需要重新设计指令模板在生成阶段避免出现这种拓扑。我的经验是在训练语料里大量增加“简单草图拉伸/切除”的样本这类基本特征组合的生成成功率最高复杂特征可以后续叠加。4.4 语义理解偏差模型到底有没有听懂你在说什么训练正常、生成也正常但出来的模型和用户设想的不一样这类问题最让人头疼。比如描述里写“带凸台的底座”生成结果却只有底座没有凸台。这个现象的根源在于训练数据的描述文本粒度不够细模型没有学会“凸台”这个词对应“拉伸一个额外特征”的这个语义关联。解决办法有几层。第一层在推理前做一个“意图归一化”环节把用户输入的自然语言先转换成一组结构化约束比如提取出主体形状底座、附加特征凸台、尺寸要求厚度、高度再把结构化约束送入text-to-cad模型。这样能把用户的模糊表达转化为模型在训练时见过的清晰表达。第二层做数据增强时多收集一些同义词和口语化描述。我见过一个效果不错的方法是用大语言模型对原始描述做改写生成比如把“bracket with two holes”改写成“a flat piece with two circular holes for mounting”这种多样性增强能显著提升模型的语义理解能力。第三层如果项目允许可以给用户提供“局部编辑”的交互方式先生成粗胚模型用户点选一个面再输入“在这个面上加一个直径5的孔”这种渐进式迭代成功率比一次性生成高得多。5. 部署环境的几个实用心得5.1 选对Prompt模板少踩一半的坑text-to-cad的输入不是随便一句话就能得到好结果。我测试过上千组提示词后总结出一个经验描述越结构化生成效果越稳定。好的提示词格式长这样“A rectangular plate, length 100mm, width 60mm, thickness 5mm, with four through holes of diameter 8mm located near the corners。”把尺寸、形状、位置约束尽量拆开说比“一块板子上有几个孔”的模糊描述可靠得多。如果你做的是面向普通用户的产品强烈建议在界面层做一个“引导式输入”的模板让用户按“主体形状-尺寸-附加特征-位置”四个字段填写描述。这样既能约束用户的输入不跑偏又能保证text-to-cad模型的输入在训练分布的覆盖范围内生成成功率会有一个质的飞跃。5.2 输出精度提升从采样到几何校验推理时算法层面的策略对最终模型质量的影响非常大。在解码阶段我推荐使用“带约束的beam search”每生成一个token就检查当前已生成的序列在语法和语义上的合法性把非法分支直接剪掉。这个剪枝策略参考了编程语言语法分析的做法——让模型在解码时自己保持一个“期望的下一个token集合”比如生成了“circle”之后期望下一个token必须是左括号再下一个必须是数值参数。在生成完成后加一步几何校验把生成序列提交到CadQuery执行执行成功后检查实体是否为流形是否有自交面是否满足用户给出的关键尺寸比如“直径20毫米”。如果不满足可以自动做一轮“回退再生成”——把错误信息作为提示词的一部分拼接回去让模型重新生成通常尝试2到3次就能得到合格结果。这个方法相当于给生成过程加了一个外部循环不需要额外训练就能把最终交付成功率从70%拉到90%以上。5.3 部署架构和延迟控制把text-to-cad部署成在线服务时要关注的不只是模型本身还有构成“文本→指令→CAD软件”链路的工程性能。服务端的请求处理链路建议拆成三个模块意图解析模块把自然语言转成结构化约束、序列生成模块运行大模型推理、几何执行模块CadQueryOpenCASCADE生成实体和导出文件。三个模块可以分别部署、独立扩缩容。延迟优化上量化方案值得投入。底座的T5模型可以量化为8位或者4位推理延迟能降一半精度损失很小。CadQuery执行几何运算相对较快一个中等复杂零件的实体化在几百毫秒内能完成主要瓶颈还是在模型推理侧。如果对延迟特别敏感可以考虑减少beam width、启用批处理队列、用vLLM这类推理框架做加速。我第一次上线的时候没做批处理高峰期GPU利用率不到10%请求排队严重改成动态batching之后单张卡在保证单请求时延不超3秒的前提下吞吐量提升了将近10倍这个优化非常划算。5.4 从单一模型走向多模态用多了你会发现纯文本描述有时候真的说不清楚几何形状比如“一个带复杂曲面的外壳”这种描述文本能表达的信息极其有限。所以这个方向的下一个演进点在于多模态输入——把文本和草图、参考图片甚至点云数据结合起来做一个多模态到CAD操作序列的生成模型。我最近在尝试的方案是“描述文本参考图像”的输入组合图像分支提取几何轮廓特征文本分支提取语义约束两个特征向量拼接后共同输入解码器。这种多模态方案尤其适合做“仿制设计”的场景——用户拍一张实物照片加上一句“按这个形状重新设计但把安装孔改成腰形”模型就能生成可编辑的CAD模型。这个方向涉及的跨模态对齐有不少工程量但潜力很大相当于把text-to-cad的适用范围从一个“创意草稿助手”扩展成了“实物逆向设计工具”。另外为了让text-to-cad模型结果更贴近实际加工需求我还在探索结合制造约束做“可制造性生成”——就是在生成阶段就避开钣金折弯半径过小、型腔深宽比过大这类工艺问题。这些约束可以用规则编码在解码剪枝阶段不用动模型结构就能有效降低后期返工率。这个思路对制造企业用户来说价值比纯粹的“能出模型”大得多。其实做这个方向最大的感触是技术本身不难理解难的是让生成结果真正进入专业流程。抛开炫酷的Demo用户要的是能编辑、能加工、能复用的CAD实体而不是一张图。围绕这个目标去优化数据、调整训练策略、完善后处理和交互每一步都有大量细节值得磨。我现在还会经常把一段描述用不同的说法反复测试观察模型哪些地方理解稳定、哪些地方会跑偏然后反推去补数据。这条路走起来不轻松但效果是一点点看得到的。