这两年text-to-cad这个方向在CAD圈子里热度始终不减打开社交平台总能看到用一句话生成机械零件自然语言直接建模之类的标题。我陆陆续续也跟进过几轮相关项目从最初的模型玩具到现在勉强能落在真实工作流里用的原型中间踩了不少坑有些心得想系统整理一下。这篇文章不打算堆论文术语就把我实际跑通的方案、选型逻辑、参数心得和翻车记录一次说清楚给准备入坑或者正在做技术选型的朋友一个参考。text-to-cad本质上解决的是想和做之间的翻译成本。传统CAD建模需要人先把空间构思转化为具体的几何操作序列再通过软件界面一步步执行。对于做过几年设计的工程师来说这不算负担但对非专业用户、上下游协作方或者需要批量产出结构概念方案的场景这个门槛就很明显。text-to-cad想做的事情是让用户用自然语言描述功能需求直接得到一个可编辑、可仿真、可制造的CAD模型而不是一张渲染图。这对数据表示、模型架构和评估方式都提出了完全不同的要求也是它和文生图、文生视频这类方向最本质的区别。这篇文章适合三类人一是刚开始接触text-to-cad、想快速建立全局认知的开发者二是正在做技术选型、纠结走哪条技术路线的工程团队三是已经有模型产出、但卡在工程化落地环节的研究人员。我会按技术路线对比、数据细节、训练配置、问题排查这几个板块展开尽量让不同基础的读者都能找到自己需要的部分。1. 整体设计与思路拆解1.1 text-to-cad到底在解决什么问题要理解text-to-cad的难点得先搞清楚CAD模型和图片、视频这类常规生成目标之间的差异。图片本质是像素矩阵生成质量可以靠人眼主观判断错了最多就是一坨不太好看的噪声。CAD模型完全不是一回事——它由精确的几何拓扑构成是边界表示B-rep驱动的参数化实体面与面之间必须严格闭合边与边要有确定的连接关系一个面翻转、一条边缺失整个模型在工程上就没有意义无法进入网格划分、受力分析或者CAM加工流程。也就是说text-to-cad生成的不是看起来像的东西而是一份严格满足几何规范、能被下游工具直接消费的工程数据。这个目标把文本到CAD的问题从生成问题变成了结构化预测问题难度上升了好几个量级。从用户需求角度拆分text-to-cad通常要覆盖三个层次。第一层是显式属性描述比如一个直径20mm、高度50mm的圆柱体这类描述和最终几何有明确的对应关系适合作为起步数据集。第二层是功能语义描述比如一个用于连接两根水管的法兰接头模型不仅需要理解功能术语还要自己补全具体的工程尺寸和结构细节这层开始就需要常识推理能力。第三层是隐式约束描述比如结构尽可能轻但要能承受200kg的轴向压力这类需求实际上要求模型具备物理感知甚至仿真能力目前基本还没有成熟方案。我在项目初始化阶段做需求拆解时最重要的经验就是别一上来就追求三层全通。把需求限定在显式属性加上少量功能语义模型任务边界清晰数据也好构造先跑通闭环再逐步扩展比一开始就做一个万能CAD生成器稳妥得多。1.2 主流技术路线的取舍当前text-to-cad的技术路线大致可以归成三类各有各的适用场景也存在各自的硬伤。第一类是直接生成B-rep序列代表思路是把CAD模型序列化为构建操作序列然后用自回归模型逐token生成。这类方法的优点是输出天然就是合法CAD历史树可以被主流CAD内核直接回放和编辑和工程工作流无缝衔接。短板在于CAD建模序列往往很长、依赖关系复杂模型容易在中途丢失上下文长序列生成时错误会累积小模型几乎压不住这个复杂度。第二类是先生成中间表示比如点云、体素或隐式场再通过后处理步骤重新拟合出CAD曲面。这类方法的好处是可以用成熟的3D深度学习技术栈数据也好获取不需要完整的建模历史标注。但问题同样明显——从离散采样重新拟合参数化曲面这一步误差极大拟合出来的面要么精度不足要么拓扑质量和真实人工建模差距明显后处理本身就成了一整个新的难题。第三类是把任务拆成两段先用大语言模型做文本解析和设计意图理解输出结构化的参数配置或草图脚本再由传统参数化建模引擎完成实际几何生成。这类方案的逻辑是让语言模型只做它擅长的事情——理解语义和结构约束把精确的几何计算交给确定性算法。优势是路径可控、可解释、便于工程介入修正缺点是设计自由度受限语言模型能做的是参数映射而非真正的空间造型创新。我在实际项目中最终选择了第三类作为主路线核心考虑是它最容易在有限资源和有限数据下产出可用的结果同时每一步都留有调试和人工干预的接口。技术选型阶段最忌讳的就是盲目追求端到端的技术品牌感真正重要的是端到端的可用性和可控性。1.3 为什么多数团队先做2D草图再转3D很多第一次接触text-to-cad的人会有一个疑问为什么不直接生成最终的3D实体而是先让模型出2D草图再拉伸或旋转成体这个选择看起来绕了路其实是工程上的务实考量。先从数据角度说。高质量的3D CAD数据集远比2D数据难获取不仅要有闭合实体还要有合法的建模历史序列。相比之下参数化草图本质上是一个由直线、圆弧、约束关系构成的结构化几何图表示形式像代码一样可序列化为token天然适合seq2seq类型模型生成。模型生成的草图只要约束关系合法交给CAD内核拉伸成体就是一条确定性的路中间几乎不引入额外的学习误差。再从评估和调试角度说。2D草图结果可以用非常清晰的几何指标来判断对错交点和约束关系也是显式的出了错误能直接定位是文本理解错了、参数设置错了还是几何约束冲突了。如果直接输出3D B-rep出了问题排查难度会指数级上升你很难判断面上有个洞到底是语义理解环节的锅还是拓扑生成环节的锅。这种可解释性在调试阶段太重要了尤其当你手里只有几千条训练数据的时候。另外还有一个操作维度的问题——主流商业CAD系统的底层内核大多还是特征建模的历史范式一个工程师哪怕拿到了3D模型的几何表示想改一个尺寸或者改一个圆角没有参数化历史依然等于要重画。2D草图中继天然保留了先草图后特征的完整参数化链条这决定了生成结果是可编辑的工程文件而不是一次性的死几何。只要目标场景是实际工程应用2D中继路线就很难被绕过。2. 核心细节解析与实操要点2.1 文本描述拆解从口语到CAD参数的鸿沟text-to-cad里最容易被低估的环节是文本端。很多入门项目把自然语言当成一个开箱即用的输入接口随便弄个编码器就开始训练结果模型无论如何都学不好——真正的问题往往是输入侧的信号质量就不过关。自然语言描述和CAD参数之间存在着很大的语义鸿沟。一个圆形的底座中间有个方形的孔这句话人类工程师能理解模型却面临好几个不确定圆形底座是圆柱还是圆盘方形孔是通孔还是盲孔孔在圆心还是偏移默认壁厚多少这些问题在人类协作时靠上下文和常识解决但训练数据里的标注往往没有把这类隐式约束展开模型只能靠猜测效果自然无法保证。我在实际项目里采用了两个手段来缓解这个问题。第一个手段是定义结构化的文本模板在数据构造阶段把描述按主体形状-特征操作-参数值-相对位置-附加约束的语法组织起来比如一个直径40mm高30mm的圆柱体顶部中心有一个直径10mm的通孔。模板约束了描述的自由度也保证了文本到参数的映射有相对稳定的对应关系模型学起来容易得多。第二个手段是从真实用户的描述习惯里提取高频表达扩充到模板里做数据增强——比如把圆柱体写成圆棒柱子把通孔写成打穿贯穿孔用近义改写提升模型的鲁棒性。需要特别提醒的是不要指望模型能从一大段自由散文里准确解析出全部参数。即便强如大语言模型在没有外挂工具和严格schema约束的前提下输出也经常出现单位错误、术语漂移和上下文遗忘。把任务限制在从结构化描述中解析参数这个边界内效果远比放开聊稳定得多。2.2 数据集构建先处理数据再谈模型text-to-cad的数据集是整个方向真正的胜负手。没有合适的数据再先进的模型也训练不出可用的几何生成能力。但很多项目团队一开始对数据工作量的估计严重不足总以为网上能直接下载到完美可用的CAD数据集实际用起来才发现坑比想象的多得多。目前公开可用的CAD数据集规模都不大而且质量参差不齐。像DeepCAD、Fusion 360 Gallery这类数据集确实提供了CAD建模序列但数据覆盖的零件类型、特征数量和参数范围都有限和真实工业零件的多样性差距很大。更实际的问题是原始数据里夹杂着大量质量很差的样本有的是零部件的中间过渡状态有的是特征树混乱导致回放失败有的则是参数极端到明显属于噪声。直接用这种数据训练模型等于把垃圾喂给模型然后期待它输出黄金。我自己处理数据的标准流程是这样先做几何合法性过滤把无法正确重建实体的样本直接删掉再做结构复杂度分层单特征零件归一类多特征组合归另一类优先保证主体类别数量充足最后对每个样本做文本描述的重新标注。这里要特别强调一点——开源数据的自带标注很多是根据建模历史反推的流水账比如画一个草图、拉伸、再画一个草图、拉伸、倒角这种描述和用户的需求表达完全不是一回事。需要人工把描述改写为面向功能的语言比如一个矩形底板四角有四个相同的安装孔边缘倒圆角。这一步确实费时费力但它直接决定了模型学到的映射是否贴近真实使用场景。对于没有条件人工大规模标注的团队我的建议是先用聚类算法对零件的形状描述做自动归纳再用模板生成初步文本最后用人工抽检修正。这套半自动方案的质量上限低于纯人工标注但可以把生产规模从几百条推到上万条带来的训练收益通常远大于人工标注质量的边际效益。2.3 模型结构选型transformer、扩散模型还是LLM外套模型结构的选择要结合数据规模和输出模态一起考虑。早期text-to-cad项目很多沿用机器翻译的套路用seq2seq架构把自然语言映射为CAD命令序列编码器处理文本解码器逐token生成建模操作。这种结构简单直接在小规模数据集上也能跑出基本可用的结果但上下文承载能力和长序列生成能力都比较有限复杂度一上来就容易崩。后来随着扩散模型在各个生成领域的强势表现也有人尝试把CAD生成放到扩散框架里做将CAD构造序列当作离散token序列来扩散。扩散类方法在生成多样性和覆盖空间上确实更有优势尤其是处理同一个功能有多种合理结构方案这类场景时表现明显更好。但扩散模型的训练稳定性和可控生成都需要更多调参经验对算力要求也不低团队如果没有专门做生成模型优化的成员上手成本会比较可观。目前我个人觉得最有性价比的方案是把大语言模型当作控制器来用。思路是让LLM负责两件事一是从自由文本中识别设计意图、抽取结构化参数这些参数以JSON等格式输出二是生成一个参数化的草编程式脚本脚本里包含图元、约束和尺寸标注交由CAD内核执行。这个路线有几个现实好处。首先LLM的语义理解能力远超自己从零训练的编码器哪怕是个中等尺寸的开源模型都远非小模型可比。其次参数化脚本是确定性的文本程序天然具备可解析、可校验、可修正的特点出问题能够准确定位到具体环节。最后整个管线可以把几何求解这个不确定性极高的部分完全交给内核不需要学习也不知道怎么学。如果你是从零开始、团队规模又小我建议直接走LLM外套这个路线。但要注意处理器决定上限、执行器决定下限LLM输出结构化参数的格式定义必须足够严格否则模型自由发挥出来的JSON到了几何引擎那边就是一场灾难。3. 实操过程与核心环节实现3.1 环境搭建与数据预处理流程实际动手之前先把环境搭好。我建议的起步配置是Pytorch 2.x配合CUDA 11.8以上Python版本3.10左右如果走LLM外套路线还需要准备一个可本地部署的开源模型运行环境。硬件方面单卡24GB显存算是及格线训练一个中小规模的seq2seq模型勉强够用如果要微调7B以上的LLM最好是有多卡或者64GB以上显存的单机否则batch size会小到没法看。数据预处理是整个流程里最消耗时间但也是价值最大的环节。我以自建的参数化草图和拉伸体数据集为例讲一下具体流程。第一步是把原始CAD文件解析成结构化的中间表示——一个JSON结构包含顶层实体信息、草图截面图元列表、约束列表、标注尺寸、特征操作列表。这一步通常需要调用CAD内核的API或者用FreeCAD这类开源工具的脚本接口批处理完成。第二步是可视化检查每个样本的轮廓和特征树我习惯导出实体缩略图人工快筛一遍虽然费眼睛但能拦下大量解析错误。第三步是对每个样本生成多个版本的文本描述覆盖不同抽象层次比如详细参数版、功能语义版、口语简化版训练时随机采样其中一个版本喂给模型增强模型对多样化表达的适应能力。预处理阶段最容易踩的坑是图元方向不一致。比如同一个矩形草图有时用四条直线首尾相连表达有时又会混入一个封闭样条再比如孔特征的方向在不同样本里可能沿正Z轴也可能沿负Z轴。这些不一致会让模型混淆语义和几何方向表现为明明参数都对了生成出来的草图却是镜像的或者翻转的。我的经验是全部统一为逆时针方向轴线统一沿Z轴这些约定在进入训练之前必须逐条检查落实。3.2 模型训练的关键参数配置训练配置直接决定模型收敛质量和最终生成效果的上限参数选择这块我踩过的坑最深这里把最关键的几项展开聊。文本编码端的处理如果走自训小模型路线我建议直接用预训练的BERT或RoBERTa作为编码器初始化而不是随机初始化一个Transformer。没有预训练的语义知识兜底小模型在文本端的表现会非常糟糕连基本术语理解都做不好。解码端输出的是CAD操作序列的token词汇表里除了正常的token还要额外加上草图起止符、命令分隔符、参数类型标识符等专用结构token这些结构token让模型能够学会某段序列是一个完整命令的边界。训练时的超参数我给出一个实测下来比较稳的起点batch size 32学习率2e-4配合warmup和余弦退火epoch数在40到60之间。损失函数用标准的交叉熵加label smoothing数值设在0.1可以避免对特定token过拟合。如果训练过程出现loss震荡或者生成序列频繁卡在重复输出优先检查两个地方——一是学习率是不是偏高二是序列长度是否超出模型能力导致注意力混乱。CAD命令序列通常比自然语言句子长得多用相对位置编码或者RoPE这类对长序列更友好的位置编码方案会明显缓解长序列下的性能衰减问题。另外要特别注意训练和推理时的一致性。训练时用的是teacher forcing逐token喂真实标签但推理时是自回归生成一旦前一步错后续全错。为了缓解这种不匹配我建议训练时加入5%到10%的随机采样替换概率模拟推理时的误差传导能让模型的纠错能力显著提升。这个技巧在文本生成领域很常见但很多CAD方向的实现却完全忽略了它后果就是离线指标看着不错上线生成时序列一长就开始跑偏。3.3 评估指标别被表面数字骗了评估text-to-cad的模型效果是另一个容易让人自我感觉良好的环节。如果只用简单的BLEU分数或者单模态分类准确率几乎必然会得出模型效果不错的错觉但把生成结果拿到CAD软件里一打开发现根本没法用。这里的关键在于text-to-cad的产出是结构化几何评估指标必须同时覆盖语义正确性和几何合法性。我目前在项目中主要用四个指标组合起来评估。第一个是CAD命令序列的解析成功率或重建成功率也就是生成结果能被CAD内核正确回放的比例反映了最基本的结构合法性。第二个是几何距离指标比如Chamfer Distance或者IoU用来衡量生成实体和参考实体在空间形状上的接近度这类指标能反映模型是基本正确还是明显跑偏。第三个是参数误差包括尺寸绝对误差和约束关系正确率专门针对参数化模型的生成质量做精细化的度量比整体形状指标更加敏感。第四个是人工评估由工程师按照是否满足描述的功能需求是否有明显结构缺陷后期编辑工作量三个维度打分这个环节不能省。这里要特别提醒两点。第一解析成功率不等于几何正确率CAD内核能回放、能生成实体不代表实体和文本描述一致——它完全可以生成一个合法但完全不对的零件。第二Chamfer Distance这类形状指标对壁厚变化不敏感两个形状相似的薄壁件和厚壁件分数可能接近但在工程上完全是两个不同的零件。所以单一指标都不足信必须组合评估人工抽检更不能少。4. 常见问题与排查技巧实录4.1 文本和几何对不上语义映射偏移怎么查text-to-cad项目里最让人头疼的问题就是模型生成的结构看起来自洽但和文本描述明显不匹配——像圆柱底座生成了方块底座通孔生成了盲孔。这种问题的根源通常是语义和几何的对齐关系在训练数据里本身就是模糊的。排查思路可以分三步走。第一步是做注意力可视化把模型在生成草图命令时对输入文本各token的注意力权重画出来看看生成底面形状这类关键节点时注意力是否落在文本对应的关键词上。如果注意力分布完全分散说明文本编码和目标几何之间根本没有建立起可靠的对应关系。第二步是对照训练数据检查是否存在同一个描述对应多种不同标注的情况这种情况会直接教坏模型让它不知道该学哪个映射必须清理。第三步是检查文本和几何的表达粒度是否匹配——如果文本侧只描述了法兰盘但几何侧标注的却是包含了法兰盘台肩、密封槽、螺栓孔的复杂完整结构那中间缺少的建模步骤对模型来说就是无中生有的要求再怎么调参也学不出来。在排查过程中我建议建立一套简单的可视化辅助工具把输入文本、生成序列、重建实体三样东西放到同一张图里对比展示。这套三位一体视图虽然简陋但在定位问题是文本理解错误还是几何生成错误时特别高效往往一眼就能定位。4.2 训练不收敛或者震荡先查数据再查参数模型训练损失不下降或者下降一小段后开始无规律震荡是入坑text-to-cad几乎必然会遇到的情况。很多人的第一反应是调低学习率或者增加训练时长但根据我的经验问题的源头往往在数据侧而不是优化侧。最值得怀疑的首先是数据噪声。如果训练数据里混有大量的几何非法样本——比如自交特征、过约束草图、不闭合截面——模型会反复尝试拟合这些不可能学会的模式损失自然降不到理想范围。另外CAD命令序列的数据长度分布如果极度不均匀长短样本交叉出现会让模型难以稳定收敛。我的建议是先对序列长度做一次统计将过长样本去掉或者截断同时将过短样本补充到合理长度保持数据分布相对平稳。如果数据做完清理后损失仍然震荡再看参数。一个常见的坑是学习率规划和batch size不匹配大batch配大学习率在Transformer类模型上容易直接震荡到发散而小batch配过大的学习率也会出现严重的不稳定。按照3.2节给出的基线参数起步把学习率改成线性warmup加cosine decay通常能解决大部分震荡问题。最后还要检查loss的权重设置如果把几何参数的回归损失和序列生成的交叉熵损失简单地相加两者的数值尺度可能差出两个数量级直接导致梯度被量级大的那项主导这个问题在早期的实现里特别常见损失归一化做不好训练就不会有好结果。4.3 生成结果无法用于实际生产拓扑质量的隐性杀手过了训练阶段、模型也能生成看起来不错的结果之后下一个卡点往往是结果根本交付不了——生成的设计可以被打开但没法在实际的生产链路里使用。最常见的几个问题包括生成实体的面片数爆炸、曲面连续性问题、特征树结构混乱以及编辑参数时内核报错。这类问题的根源来自模型的投机取巧倾向——它在训练时发现用折线逼近圆弧更容易获得较低loss于是大量生成的小线段取代了真正的圆弧图元导致特征树简洁性差、面片数量巨大。类似的为了凑形状模型的草图里会生成大量冗余共线线段和零长度约束CAD内核虽然能解析但后续修改和制造环节会被这种脏数据拖垮。我在项目中采用的解法有两层。第一层是在训练数据侧做简化操作的数据增强让模型更多看到用标准圆弧、标准直线表达的样例减少其学习折线逼近的路径。第二层是在推理后处理阶段增加一个几何简化器自动合并共线线段、拟合近似圆弧、删除零长度几何。这一层本质上和图形学里的路径简化是同一个问题实现不复杂但效果显著可以从根本上把生成结果从能打开提升到能编辑。4.4 batch生成时的高频崩溃与稳定性优化text-to-cad如果要应用到实际工作流几乎免不了要支持批量生成。批量场景和单条场景最大的不同在于批量生成的错误概率会被放大——单条生成时一个样本出了故障你能容忍但批处理模式下如果每十条就崩一次整个工具就没办法交给别人用了。批量崩溃最常见的两个原因是数值异常和资源超限。数值异常通常表现为生成尺寸极端不合理比如宽度写成几千毫米或者圆角半径出现负值好的做法是在推理阶段就设置参数范围的硬约束利用脱敏层或模板校验将超出范围的参数直接修正到可行区间避免让异常数值进入几何引擎。资源超限则来自单卡并发过高和内存无法回收的问题——生成器在CUDA上的显存碎片化很严重连续跑几十个样本之后出现out of memory简直是家常便饭。我的经验是每批生成后显式执行显存缓存清理并把批量大小控制在合理范围内宁可牺牲少量吞吐也要保证整批任务的稳定性。此外日志系统在批量模式下也要提前设计好。建议每个生成任务记录唯一的job id以及对应的输入描述、模型版本、生成耗时、解析结果和最终实体校验结果。数据积累到一定量之后就可以对失败模式做统计分析针对性优化高频错误路径。这比反复人工猜测到底哪里出问题要高效得多。5. 一点项目体会如果让我给准备入坑text-to-cad的团队一条最核心的建议那就是先想清楚生成结果的消费方是谁。如果结果最终要进CAD软件做人工编辑那么任何不保留参数化历史的方案都走不通如果只是概念可视化那精度要求可以适当放松方案选择的余地就大得多。明确这个前提再往下做技术选型和资源分配方向才不会跑偏。另一个切身感受是这个方向的工作量分布远比想象中更偏数据和工程。模型结构固然重要但数据清洗、文本标注、后处理工具链这些脏活累活决定了项目能不能真正落地。哪怕是同一个公开数据集预处理方式不同最终模型效果可以差出一大截这远比在模型结构上做几个花活的收益更大。在实操中我还发现一个容易被忽视的小技巧推理时统一使用某一固定格式的prompt模板。很多模型在训练时见惯了某几种句式推理时换成口语化表达反而效果下滑。把用户的自由描述先经过一个改写模块转成训练分布内的标准句式能显著提升生成稳定性。这一步几乎不消耗GPU资源却常常能带来几个百分点的成功率提升性价比极高。text-to-cad远没有到成熟期多模态融合、物理常识约束、交互式修正这些方向也都还有大量值得做的空间。如果手里正好有需求场景不妨利用开源数据集和现成模型先跑一个小闭环再根据实际反馈一步步迭代。这条路走起来不算轻松但每一步的产出的确都在逼近让设计表达直接变成可用模型这个目标。 
长河君 · 2026/10/25 23:16:30 · 阅读 1.2k text-to-cad技术路线与实战：自然语言生成可编辑CAD模型
这两年text-to-cad这个方向在CAD圈子里热度始终不减打开社交平台总能看到用一句话生成机械零件自然语言直接建模之类的标题。我陆陆续续也跟进过几轮相关项目从最初的模型玩具到现在勉强能落在真实工作流里用的原型中间踩了不少坑有些心得想系统整理一下。这篇文章不打算堆论文术语就把我实际跑通的方案、选型逻辑、参数心得和翻车记录一次说清楚给准备入坑或者正在做技术选型的朋友一个参考。text-to-cad本质上解决的是想和做之间的翻译成本。传统CAD建模需要人先把空间构思转化为具体的几何操作序列再通过软件界面一步步执行。对于做过几年设计的工程师来说这不算负担但对非专业用户、上下游协作方或者需要批量产出结构概念方案的场景这个门槛就很明显。text-to-cad想做的事情是让用户用自然语言描述功能需求直接得到一个可编辑、可仿真、可制造的CAD模型而不是一张渲染图。这对数据表示、模型架构和评估方式都提出了完全不同的要求也是它和文生图、文生视频这类方向最本质的区别。这篇文章适合三类人一是刚开始接触text-to-cad、想快速建立全局认知的开发者二是正在做技术选型、纠结走哪条技术路线的工程团队三是已经有模型产出、但卡在工程化落地环节的研究人员。我会按技术路线对比、数据细节、训练配置、问题排查这几个板块展开尽量让不同基础的读者都能找到自己需要的部分。1. 整体设计与思路拆解1.1 text-to-cad到底在解决什么问题要理解text-to-cad的难点得先搞清楚CAD模型和图片、视频这类常规生成目标之间的差异。图片本质是像素矩阵生成质量可以靠人眼主观判断错了最多就是一坨不太好看的噪声。CAD模型完全不是一回事——它由精确的几何拓扑构成是边界表示B-rep驱动的参数化实体面与面之间必须严格闭合边与边要有确定的连接关系一个面翻转、一条边缺失整个模型在工程上就没有意义无法进入网格划分、受力分析或者CAM加工流程。也就是说text-to-cad生成的不是看起来像的东西而是一份严格满足几何规范、能被下游工具直接消费的工程数据。这个目标把文本到CAD的问题从生成问题变成了结构化预测问题难度上升了好几个量级。从用户需求角度拆分text-to-cad通常要覆盖三个层次。第一层是显式属性描述比如一个直径20mm、高度50mm的圆柱体这类描述和最终几何有明确的对应关系适合作为起步数据集。第二层是功能语义描述比如一个用于连接两根水管的法兰接头模型不仅需要理解功能术语还要自己补全具体的工程尺寸和结构细节这层开始就需要常识推理能力。第三层是隐式约束描述比如结构尽可能轻但要能承受200kg的轴向压力这类需求实际上要求模型具备物理感知甚至仿真能力目前基本还没有成熟方案。我在项目初始化阶段做需求拆解时最重要的经验就是别一上来就追求三层全通。把需求限定在显式属性加上少量功能语义模型任务边界清晰数据也好构造先跑通闭环再逐步扩展比一开始就做一个万能CAD生成器稳妥得多。1.2 主流技术路线的取舍当前text-to-cad的技术路线大致可以归成三类各有各的适用场景也存在各自的硬伤。第一类是直接生成B-rep序列代表思路是把CAD模型序列化为构建操作序列然后用自回归模型逐token生成。这类方法的优点是输出天然就是合法CAD历史树可以被主流CAD内核直接回放和编辑和工程工作流无缝衔接。短板在于CAD建模序列往往很长、依赖关系复杂模型容易在中途丢失上下文长序列生成时错误会累积小模型几乎压不住这个复杂度。第二类是先生成中间表示比如点云、体素或隐式场再通过后处理步骤重新拟合出CAD曲面。这类方法的好处是可以用成熟的3D深度学习技术栈数据也好获取不需要完整的建模历史标注。但问题同样明显——从离散采样重新拟合参数化曲面这一步误差极大拟合出来的面要么精度不足要么拓扑质量和真实人工建模差距明显后处理本身就成了一整个新的难题。第三类是把任务拆成两段先用大语言模型做文本解析和设计意图理解输出结构化的参数配置或草图脚本再由传统参数化建模引擎完成实际几何生成。这类方案的逻辑是让语言模型只做它擅长的事情——理解语义和结构约束把精确的几何计算交给确定性算法。优势是路径可控、可解释、便于工程介入修正缺点是设计自由度受限语言模型能做的是参数映射而非真正的空间造型创新。我在实际项目中最终选择了第三类作为主路线核心考虑是它最容易在有限资源和有限数据下产出可用的结果同时每一步都留有调试和人工干预的接口。技术选型阶段最忌讳的就是盲目追求端到端的技术品牌感真正重要的是端到端的可用性和可控性。1.3 为什么多数团队先做2D草图再转3D很多第一次接触text-to-cad的人会有一个疑问为什么不直接生成最终的3D实体而是先让模型出2D草图再拉伸或旋转成体这个选择看起来绕了路其实是工程上的务实考量。先从数据角度说。高质量的3D CAD数据集远比2D数据难获取不仅要有闭合实体还要有合法的建模历史序列。相比之下参数化草图本质上是一个由直线、圆弧、约束关系构成的结构化几何图表示形式像代码一样可序列化为token天然适合seq2seq类型模型生成。模型生成的草图只要约束关系合法交给CAD内核拉伸成体就是一条确定性的路中间几乎不引入额外的学习误差。再从评估和调试角度说。2D草图结果可以用非常清晰的几何指标来判断对错交点和约束关系也是显式的出了错误能直接定位是文本理解错了、参数设置错了还是几何约束冲突了。如果直接输出3D B-rep出了问题排查难度会指数级上升你很难判断面上有个洞到底是语义理解环节的锅还是拓扑生成环节的锅。这种可解释性在调试阶段太重要了尤其当你手里只有几千条训练数据的时候。另外还有一个操作维度的问题——主流商业CAD系统的底层内核大多还是特征建模的历史范式一个工程师哪怕拿到了3D模型的几何表示想改一个尺寸或者改一个圆角没有参数化历史依然等于要重画。2D草图中继天然保留了先草图后特征的完整参数化链条这决定了生成结果是可编辑的工程文件而不是一次性的死几何。只要目标场景是实际工程应用2D中继路线就很难被绕过。2. 核心细节解析与实操要点2.1 文本描述拆解从口语到CAD参数的鸿沟text-to-cad里最容易被低估的环节是文本端。很多入门项目把自然语言当成一个开箱即用的输入接口随便弄个编码器就开始训练结果模型无论如何都学不好——真正的问题往往是输入侧的信号质量就不过关。自然语言描述和CAD参数之间存在着很大的语义鸿沟。一个圆形的底座中间有个方形的孔这句话人类工程师能理解模型却面临好几个不确定圆形底座是圆柱还是圆盘方形孔是通孔还是盲孔孔在圆心还是偏移默认壁厚多少这些问题在人类协作时靠上下文和常识解决但训练数据里的标注往往没有把这类隐式约束展开模型只能靠猜测效果自然无法保证。我在实际项目里采用了两个手段来缓解这个问题。第一个手段是定义结构化的文本模板在数据构造阶段把描述按主体形状-特征操作-参数值-相对位置-附加约束的语法组织起来比如一个直径40mm高30mm的圆柱体顶部中心有一个直径10mm的通孔。模板约束了描述的自由度也保证了文本到参数的映射有相对稳定的对应关系模型学起来容易得多。第二个手段是从真实用户的描述习惯里提取高频表达扩充到模板里做数据增强——比如把圆柱体写成圆棒柱子把通孔写成打穿贯穿孔用近义改写提升模型的鲁棒性。需要特别提醒的是不要指望模型能从一大段自由散文里准确解析出全部参数。即便强如大语言模型在没有外挂工具和严格schema约束的前提下输出也经常出现单位错误、术语漂移和上下文遗忘。把任务限制在从结构化描述中解析参数这个边界内效果远比放开聊稳定得多。2.2 数据集构建先处理数据再谈模型text-to-cad的数据集是整个方向真正的胜负手。没有合适的数据再先进的模型也训练不出可用的几何生成能力。但很多项目团队一开始对数据工作量的估计严重不足总以为网上能直接下载到完美可用的CAD数据集实际用起来才发现坑比想象的多得多。目前公开可用的CAD数据集规模都不大而且质量参差不齐。像DeepCAD、Fusion 360 Gallery这类数据集确实提供了CAD建模序列但数据覆盖的零件类型、特征数量和参数范围都有限和真实工业零件的多样性差距很大。更实际的问题是原始数据里夹杂着大量质量很差的样本有的是零部件的中间过渡状态有的是特征树混乱导致回放失败有的则是参数极端到明显属于噪声。直接用这种数据训练模型等于把垃圾喂给模型然后期待它输出黄金。我自己处理数据的标准流程是这样先做几何合法性过滤把无法正确重建实体的样本直接删掉再做结构复杂度分层单特征零件归一类多特征组合归另一类优先保证主体类别数量充足最后对每个样本做文本描述的重新标注。这里要特别强调一点——开源数据的自带标注很多是根据建模历史反推的流水账比如画一个草图、拉伸、再画一个草图、拉伸、倒角这种描述和用户的需求表达完全不是一回事。需要人工把描述改写为面向功能的语言比如一个矩形底板四角有四个相同的安装孔边缘倒圆角。这一步确实费时费力但它直接决定了模型学到的映射是否贴近真实使用场景。对于没有条件人工大规模标注的团队我的建议是先用聚类算法对零件的形状描述做自动归纳再用模板生成初步文本最后用人工抽检修正。这套半自动方案的质量上限低于纯人工标注但可以把生产规模从几百条推到上万条带来的训练收益通常远大于人工标注质量的边际效益。2.3 模型结构选型transformer、扩散模型还是LLM外套模型结构的选择要结合数据规模和输出模态一起考虑。早期text-to-cad项目很多沿用机器翻译的套路用seq2seq架构把自然语言映射为CAD命令序列编码器处理文本解码器逐token生成建模操作。这种结构简单直接在小规模数据集上也能跑出基本可用的结果但上下文承载能力和长序列生成能力都比较有限复杂度一上来就容易崩。后来随着扩散模型在各个生成领域的强势表现也有人尝试把CAD生成放到扩散框架里做将CAD构造序列当作离散token序列来扩散。扩散类方法在生成多样性和覆盖空间上确实更有优势尤其是处理同一个功能有多种合理结构方案这类场景时表现明显更好。但扩散模型的训练稳定性和可控生成都需要更多调参经验对算力要求也不低团队如果没有专门做生成模型优化的成员上手成本会比较可观。目前我个人觉得最有性价比的方案是把大语言模型当作控制器来用。思路是让LLM负责两件事一是从自由文本中识别设计意图、抽取结构化参数这些参数以JSON等格式输出二是生成一个参数化的草编程式脚本脚本里包含图元、约束和尺寸标注交由CAD内核执行。这个路线有几个现实好处。首先LLM的语义理解能力远超自己从零训练的编码器哪怕是个中等尺寸的开源模型都远非小模型可比。其次参数化脚本是确定性的文本程序天然具备可解析、可校验、可修正的特点出问题能够准确定位到具体环节。最后整个管线可以把几何求解这个不确定性极高的部分完全交给内核不需要学习也不知道怎么学。如果你是从零开始、团队规模又小我建议直接走LLM外套这个路线。但要注意处理器决定上限、执行器决定下限LLM输出结构化参数的格式定义必须足够严格否则模型自由发挥出来的JSON到了几何引擎那边就是一场灾难。3. 实操过程与核心环节实现3.1 环境搭建与数据预处理流程实际动手之前先把环境搭好。我建议的起步配置是Pytorch 2.x配合CUDA 11.8以上Python版本3.10左右如果走LLM外套路线还需要准备一个可本地部署的开源模型运行环境。硬件方面单卡24GB显存算是及格线训练一个中小规模的seq2seq模型勉强够用如果要微调7B以上的LLM最好是有多卡或者64GB以上显存的单机否则batch size会小到没法看。数据预处理是整个流程里最消耗时间但也是价值最大的环节。我以自建的参数化草图和拉伸体数据集为例讲一下具体流程。第一步是把原始CAD文件解析成结构化的中间表示——一个JSON结构包含顶层实体信息、草图截面图元列表、约束列表、标注尺寸、特征操作列表。这一步通常需要调用CAD内核的API或者用FreeCAD这类开源工具的脚本接口批处理完成。第二步是可视化检查每个样本的轮廓和特征树我习惯导出实体缩略图人工快筛一遍虽然费眼睛但能拦下大量解析错误。第三步是对每个样本生成多个版本的文本描述覆盖不同抽象层次比如详细参数版、功能语义版、口语简化版训练时随机采样其中一个版本喂给模型增强模型对多样化表达的适应能力。预处理阶段最容易踩的坑是图元方向不一致。比如同一个矩形草图有时用四条直线首尾相连表达有时又会混入一个封闭样条再比如孔特征的方向在不同样本里可能沿正Z轴也可能沿负Z轴。这些不一致会让模型混淆语义和几何方向表现为明明参数都对了生成出来的草图却是镜像的或者翻转的。我的经验是全部统一为逆时针方向轴线统一沿Z轴这些约定在进入训练之前必须逐条检查落实。3.2 模型训练的关键参数配置训练配置直接决定模型收敛质量和最终生成效果的上限参数选择这块我踩过的坑最深这里把最关键的几项展开聊。文本编码端的处理如果走自训小模型路线我建议直接用预训练的BERT或RoBERTa作为编码器初始化而不是随机初始化一个Transformer。没有预训练的语义知识兜底小模型在文本端的表现会非常糟糕连基本术语理解都做不好。解码端输出的是CAD操作序列的token词汇表里除了正常的token还要额外加上草图起止符、命令分隔符、参数类型标识符等专用结构token这些结构token让模型能够学会某段序列是一个完整命令的边界。训练时的超参数我给出一个实测下来比较稳的起点batch size 32学习率2e-4配合warmup和余弦退火epoch数在40到60之间。损失函数用标准的交叉熵加label smoothing数值设在0.1可以避免对特定token过拟合。如果训练过程出现loss震荡或者生成序列频繁卡在重复输出优先检查两个地方——一是学习率是不是偏高二是序列长度是否超出模型能力导致注意力混乱。CAD命令序列通常比自然语言句子长得多用相对位置编码或者RoPE这类对长序列更友好的位置编码方案会明显缓解长序列下的性能衰减问题。另外要特别注意训练和推理时的一致性。训练时用的是teacher forcing逐token喂真实标签但推理时是自回归生成一旦前一步错后续全错。为了缓解这种不匹配我建议训练时加入5%到10%的随机采样替换概率模拟推理时的误差传导能让模型的纠错能力显著提升。这个技巧在文本生成领域很常见但很多CAD方向的实现却完全忽略了它后果就是离线指标看着不错上线生成时序列一长就开始跑偏。3.3 评估指标别被表面数字骗了评估text-to-cad的模型效果是另一个容易让人自我感觉良好的环节。如果只用简单的BLEU分数或者单模态分类准确率几乎必然会得出模型效果不错的错觉但把生成结果拿到CAD软件里一打开发现根本没法用。这里的关键在于text-to-cad的产出是结构化几何评估指标必须同时覆盖语义正确性和几何合法性。我目前在项目中主要用四个指标组合起来评估。第一个是CAD命令序列的解析成功率或重建成功率也就是生成结果能被CAD内核正确回放的比例反映了最基本的结构合法性。第二个是几何距离指标比如Chamfer Distance或者IoU用来衡量生成实体和参考实体在空间形状上的接近度这类指标能反映模型是基本正确还是明显跑偏。第三个是参数误差包括尺寸绝对误差和约束关系正确率专门针对参数化模型的生成质量做精细化的度量比整体形状指标更加敏感。第四个是人工评估由工程师按照是否满足描述的功能需求是否有明显结构缺陷后期编辑工作量三个维度打分这个环节不能省。这里要特别提醒两点。第一解析成功率不等于几何正确率CAD内核能回放、能生成实体不代表实体和文本描述一致——它完全可以生成一个合法但完全不对的零件。第二Chamfer Distance这类形状指标对壁厚变化不敏感两个形状相似的薄壁件和厚壁件分数可能接近但在工程上完全是两个不同的零件。所以单一指标都不足信必须组合评估人工抽检更不能少。4. 常见问题与排查技巧实录4.1 文本和几何对不上语义映射偏移怎么查text-to-cad项目里最让人头疼的问题就是模型生成的结构看起来自洽但和文本描述明显不匹配——像圆柱底座生成了方块底座通孔生成了盲孔。这种问题的根源通常是语义和几何的对齐关系在训练数据里本身就是模糊的。排查思路可以分三步走。第一步是做注意力可视化把模型在生成草图命令时对输入文本各token的注意力权重画出来看看生成底面形状这类关键节点时注意力是否落在文本对应的关键词上。如果注意力分布完全分散说明文本编码和目标几何之间根本没有建立起可靠的对应关系。第二步是对照训练数据检查是否存在同一个描述对应多种不同标注的情况这种情况会直接教坏模型让它不知道该学哪个映射必须清理。第三步是检查文本和几何的表达粒度是否匹配——如果文本侧只描述了法兰盘但几何侧标注的却是包含了法兰盘台肩、密封槽、螺栓孔的复杂完整结构那中间缺少的建模步骤对模型来说就是无中生有的要求再怎么调参也学不出来。在排查过程中我建议建立一套简单的可视化辅助工具把输入文本、生成序列、重建实体三样东西放到同一张图里对比展示。这套三位一体视图虽然简陋但在定位问题是文本理解错误还是几何生成错误时特别高效往往一眼就能定位。4.2 训练不收敛或者震荡先查数据再查参数模型训练损失不下降或者下降一小段后开始无规律震荡是入坑text-to-cad几乎必然会遇到的情况。很多人的第一反应是调低学习率或者增加训练时长但根据我的经验问题的源头往往在数据侧而不是优化侧。最值得怀疑的首先是数据噪声。如果训练数据里混有大量的几何非法样本——比如自交特征、过约束草图、不闭合截面——模型会反复尝试拟合这些不可能学会的模式损失自然降不到理想范围。另外CAD命令序列的数据长度分布如果极度不均匀长短样本交叉出现会让模型难以稳定收敛。我的建议是先对序列长度做一次统计将过长样本去掉或者截断同时将过短样本补充到合理长度保持数据分布相对平稳。如果数据做完清理后损失仍然震荡再看参数。一个常见的坑是学习率规划和batch size不匹配大batch配大学习率在Transformer类模型上容易直接震荡到发散而小batch配过大的学习率也会出现严重的不稳定。按照3.2节给出的基线参数起步把学习率改成线性warmup加cosine decay通常能解决大部分震荡问题。最后还要检查loss的权重设置如果把几何参数的回归损失和序列生成的交叉熵损失简单地相加两者的数值尺度可能差出两个数量级直接导致梯度被量级大的那项主导这个问题在早期的实现里特别常见损失归一化做不好训练就不会有好结果。4.3 生成结果无法用于实际生产拓扑质量的隐性杀手过了训练阶段、模型也能生成看起来不错的结果之后下一个卡点往往是结果根本交付不了——生成的设计可以被打开但没法在实际的生产链路里使用。最常见的几个问题包括生成实体的面片数爆炸、曲面连续性问题、特征树结构混乱以及编辑参数时内核报错。这类问题的根源来自模型的投机取巧倾向——它在训练时发现用折线逼近圆弧更容易获得较低loss于是大量生成的小线段取代了真正的圆弧图元导致特征树简洁性差、面片数量巨大。类似的为了凑形状模型的草图里会生成大量冗余共线线段和零长度约束CAD内核虽然能解析但后续修改和制造环节会被这种脏数据拖垮。我在项目中采用的解法有两层。第一层是在训练数据侧做简化操作的数据增强让模型更多看到用标准圆弧、标准直线表达的样例减少其学习折线逼近的路径。第二层是在推理后处理阶段增加一个几何简化器自动合并共线线段、拟合近似圆弧、删除零长度几何。这一层本质上和图形学里的路径简化是同一个问题实现不复杂但效果显著可以从根本上把生成结果从能打开提升到能编辑。4.4 batch生成时的高频崩溃与稳定性优化text-to-cad如果要应用到实际工作流几乎免不了要支持批量生成。批量场景和单条场景最大的不同在于批量生成的错误概率会被放大——单条生成时一个样本出了故障你能容忍但批处理模式下如果每十条就崩一次整个工具就没办法交给别人用了。批量崩溃最常见的两个原因是数值异常和资源超限。数值异常通常表现为生成尺寸极端不合理比如宽度写成几千毫米或者圆角半径出现负值好的做法是在推理阶段就设置参数范围的硬约束利用脱敏层或模板校验将超出范围的参数直接修正到可行区间避免让异常数值进入几何引擎。资源超限则来自单卡并发过高和内存无法回收的问题——生成器在CUDA上的显存碎片化很严重连续跑几十个样本之后出现out of memory简直是家常便饭。我的经验是每批生成后显式执行显存缓存清理并把批量大小控制在合理范围内宁可牺牲少量吞吐也要保证整批任务的稳定性。此外日志系统在批量模式下也要提前设计好。建议每个生成任务记录唯一的job id以及对应的输入描述、模型版本、生成耗时、解析结果和最终实体校验结果。数据积累到一定量之后就可以对失败模式做统计分析针对性优化高频错误路径。这比反复人工猜测到底哪里出问题要高效得多。5. 一点项目体会如果让我给准备入坑text-to-cad的团队一条最核心的建议那就是先想清楚生成结果的消费方是谁。如果结果最终要进CAD软件做人工编辑那么任何不保留参数化历史的方案都走不通如果只是概念可视化那精度要求可以适当放松方案选择的余地就大得多。明确这个前提再往下做技术选型和资源分配方向才不会跑偏。另一个切身感受是这个方向的工作量分布远比想象中更偏数据和工程。模型结构固然重要但数据清洗、文本标注、后处理工具链这些脏活累活决定了项目能不能真正落地。哪怕是同一个公开数据集预处理方式不同最终模型效果可以差出一大截这远比在模型结构上做几个花活的收益更大。在实操中我还发现一个容易被忽视的小技巧推理时统一使用某一固定格式的prompt模板。很多模型在训练时见惯了某几种句式推理时换成口语化表达反而效果下滑。把用户的自由描述先经过一个改写模块转成训练分布内的标准句式能显著提升生成稳定性。这一步几乎不消耗GPU资源却常常能带来几个百分点的成功率提升性价比极高。text-to-cad远没有到成熟期多模态融合、物理常识约束、交互式修正这些方向也都还有大量值得做的空间。如果手里正好有需求场景不妨利用开源数据集和现成模型先跑一个小闭环再根据实际反馈一步步迭代。这条路走起来不算轻松但每一步的产出的确都在逼近让设计表达直接变成可用模型这个目标。