text-to-cad这个方向是我最近一年多最看好的AI工程化落地方向之一。它做的事情其实一句话就能说清用自然语言直接驱动CAD模型的生成。比如输入“一个直径50mm、厚度8mm的带中心孔法兰盘”系统就能吐出一个可编辑、带参数约束的CAD实体而不是一张渲染图也不是一堆没有特征树的三维网格。这种能力一旦稳定影响的不只是设计环节而是整个“需求到模型”的流程重建。这篇内容我会从一个实践者的角度把text-to-cad从头到尾拆开讲一遍它到底是怎么运作的为什么近几年才出现爆发点实际跑通一个项目需要准备什么以及最容易踩的坑都在哪里。适合三类人看一类是刚接触这个方向、想快速建立全局认识的开发者一类是在公司做CAD智能化改造、需要评估技术可行性的人还有一类是已经在跑实验、但被数据质量和评估指标折磨得够呛的算法工程师。1. Text-to-CAD在解决什么以及为什么现在才爆发1.1 一个自然语言到三维模型的直接映射先理清楚text-to-cad在技术栈里的位置。它处在“语言模型”和“CAD内核”的交叉地带但又不是简单的“让大模型调用一下API接口”。核心挑战在于自然语言描述是模糊的、口语化的、丢失精确量纲的而CAD模型是绝对的、参数化的、必须可制造可修改的。这两者之间的隐含鸿沟才是这项技术真正要解决的问题。举个例子你说“一个支架”语言模型完全能理解这是承重结构但它不知道是L形、U形、还是带加强筋的异形件。你说“直径20的孔”模型需要判断这个20是指通孔直径、螺纹底孔直径、还是沉头孔的小径。传统CAD的应对方式是让人去点菜单、填参数把所有歧义消灭在设计意图明确之前text-to-cad的野心是让机器来消化歧义把语义理解直接映射到参数化操作序列上。所以我的判断是text-to-cad本质上不是“增强版的文生图”而是“反向的CAD参数提取器”。它把一个人脑里的设计意图经过语言编码再由模型解码成CAD内核能执行的一串命令。这串命令不只是画一个形状而是完整的设计流程选基准面、画草图、加约束、拉伸切除、开孔、倒角、最后生成特征树。这个特征树的存在决定了生成结果能不能被后续编辑这也是text-to-cad区别于普通三维生成模型的最关键一点。1.2 从DeepCAD到Zoo的技术演进关键任何技术方向突然变热一定是有几个关键卡点被依次打通了。text-to-cad也一样。我梳理了一下至少有三代里程碑式的进展值得说。第一代是DeepCAD它证明了“CAD指令序列可以被自回归模型生成”。DeepCAD的核心思路是把CAD操作编译成程序化的指令然后用一个类似机器翻译的encoder-decoder模型去生成。它的局限在于只能输出固定的矩形拉伸、圆孔阵列这类比较基础的CSG结构复杂倒角、放样、扫掠全都不支持而且泛化性能很有限。第二代是Zoo它做了一个我认为非常关键的工作构建了一个包含大规模真实参数化CAD模型的数据集并为每个模型配属了高层次的CAD操作序列。Zoo把问题从中等规模推到了大规模让模型有机会学习更多种类的特征和拓扑。它的数据是来自真实用户的建模会话比合成数据更能反映实际设计习惯。第三代是最近两年陆续出现的、以T5和CodeT5为骨干的Text2CAD系列以及一些把LLM和CAD指令集结合的项目。这一阶段的突破是统一了数据格式——大家不再各玩各的私有DSL而是开始向OpenSCAD、CadQuery这种公开的脚本化建模语言靠拢。为什么这一步很关键因为公开脚本语言具备“文本可解析、指令可编译、渲染可验证”三个特点这等于把text-to-cad变成了一种可控的代码生成任务而不是黑盒的形状生成任务。我现在回头看这个方向爆发的逻辑非常清晰CAD数据规模上来了语言模型能力上来了公开的脚本化建模工具也在持续迭代三者撞到一起才有了今天这个局面。阶段代表工作核心能力主要瓶颈第一阶段DeepCAD基础CSG指令序列生成能生成的模型种类少泛化差第二阶段Zoo大规模真实CAD数据与操作序列数据标注成本高语义对齐不够第三阶段Text2CAD、LLM脚本化CAD自然语言直接到参数化脚本精确尺寸控制、评估体系仍需完善2. 核心细节解析数据、模型架构与输出约束2.1 数据闭环自然语言、代码、树结构与渲染很多刚接触text-to-cad的人第一反应是找模型、调参数但真正决定上限的是数据。这个方向的训练数据不是简单的“一句话配一个模型文件”而是一个完整的闭环至少包含四层第一层是自然语言描述。这部分来源很杂有从CAD建模教程里爬的有从模型库标签里筛的也有通过合成方式生成的。质量差异极大。有些描述是“一个简单的L形支架”有些是“dimensions: 40x30x5, hole diameter 4.5, fillet radius 2”后者根本不算自然语言但对训练非常有用。第二层是CAD代码。这是模型要生成的目标。首选CadQuery和OpenSCAD的脚本因为它们把参数和特征关系暴露得很清楚。CadQuery的优势在于它和真实CAD更接近操作语义是“以某个面为基准生成拉伸体”而OpenSCAD更偏向CSG布尔运算两者在模型的输出行为和后续编辑能力上差距明显。第三层是树结构。把代码解析成抽象语法树是为了给模型一个更结构化的监督信号。你问“带加强筋的L形支架”和“没有加强筋的U形槽”虽然最终三维形状差别很大但在代码层面可能只差一两行而有了树结构模型可以更容易学到“什么特征服务于什么功能”。第四层是渲染结果。渲染不是给用户看的是给模型做跨模态对齐用的。通过多视角渲染图可以计算生成模型与描述文本之间的CLIP匹配度或者用渲染对比约束生成过程。实测下来渲染图像在数据规模足够大的时候对提升模型的空间感知能力有明显帮助尤其是判断“开孔方向”和“倒角位置”这类强几何属性时。2.2 模型选型为什么Decoder-only不是万能钥匙text-to-cad的模型选型我建议直接放弃“什么都用LLM”的思路。现在很多项目喜欢把自然语言描述和CAD代码都塞给一个大的decoder-only模型让它自己学着生成。效果确实有但问题也很明显CAD代码的语法是强约束的尺寸是绝对精度敏感的小模型的幻觉在代码场景里会被放大到完全不可用。更稳妥的方案是经典encoder-decoder架构或者把大语言模型当作“语义理解器”把具体的CAD生成交给专门的生成模型。我实测下来T5系列的性价比非常高。T5的encoder可以把自然语言描述编码成语义向量decoder可以一步步预测代码token序列。它不像GPT那样需要海量参数去积累世界知识因为CAD生成本质上不是“知识密集型”任务而是“结构密集型”任务。当然Decoder-only并非不可用。如果你的应用场景是“给一句非常详细的描述生成固定模板的零件”比如螺栓、螺母、垫圈这类标准化件大模型反而更好使因为模板知识在参数里压缩得非常密集。但一旦涉及自由形态的结构件设计Decoder-only的输出长度不收敛、尺寸漂移、特征顺序混乱这些毛病就会频繁冒出来。在实际模型选型时我更多会看两点第一模型是否接受过“代码tokenizer”的预训练而不是纯自然语言tokenizer第二模型是否有位置编码的稳定性——CAD代码动辄几百上千个token序列长度对transformer位置编码的考验比普通文本大得多。CodeT5在这方面天然占优这也是我内部实验默认选择它的原因。2.3 输出验证CSG合法性只是第一道关卡模型生成完代码不能直接当作结果交付。一个被很多人忽略的环节是输出验证。验证分几个层次最基础的是CSG合法性检查生成的几何体必须封闭、没有自交、没有零厚度的悬面。这一层至少能拦截掉百分之三四十的明显失败案例。第二层是约束一致性检查。比如用户说孔距50mm模型生成了49.8mm视觉上几乎看不出差别但装配时会出问题。所以需要把提取到的尺寸参数与描述中的期望值做比对超过容差就判定失败。这层检查在纯生成模型里很难加入但如果在代码层面做其实很直接——就是解析生成脚本里的数值参数再和文本中用正则或语义解析出的数值做匹配。第三层是物理可行性检查。对结构件来说至少要做简单的静态校核比如过大的悬臂梁、过薄的筋板、不合理的开孔位置都应该被拦截。大部分text-to-cad项目不会做到这一层但一旦你的目标是“生成的可直接用”物理校验就是绕不开的。这也是我一直强调的text-to-cad不是AI论文里的玩具它是一个“生成-验证-反馈”的工程闭环。3. 实操过程完整跑通一个Text-to-CAD示例3.1 环境与工具链准备纸上谈兵没意思我直接用一个开源项目作为示例带大家跑通一个最小闭环。这里我选的是Zoo这个项目配套的指令生成工具链加上CadQuery作为后端建模引擎再配合一个小规模微调脚本。这套组合的好处是全部开源、无商业依赖适合作为研究方向的第一块试验田。环境准备其实不复杂核心依赖就四样Python 3.10以上我用的3.10稳定且包兼容性好一个支持CUDA的PyTorch环境CadQuery用来编译生成的代码transformers库用来加载和微调CodeT5模型conda create -n text2cad python3.10 -y conda activate text2cad pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install cadquery transformers datasets有一点要提醒CadQuery和OpenCascade的版本兼容性非常折磨人。建议直接通过conda安装CadQuery而不是用pip否则经常会遇到动态库找不到或符号冲突的问题。我踩过一次大坑pip装的cadquery在编译复杂模型时直接崩掉换了conda版之后稳得一批。3.2 数据准备与提示词设计Zoo项目提供了原始CAD数据和对应的操作序列但要用于text-to-cad还需要把数据改造成“自然语言描述-CAD代码”对。Zoo自带的描述字段偏向结构化注释比如“Bracket with four holes”这种描述可以直接用但信息量不足模型很难学到丰富的语义关联。我的做法是做一个半自动的描述增强管道。先用规则生成基础描述包括类型词、主要特征、尺寸信息再用一个本地小模型把这些要素串成通顺的自然语言句子。效果还不错但要注意不要引入过多的同义改写否则模型会学到“描述越长代码越复杂”这种没有意义的关联。提示词设计方面不需要像ChatGPT那样写复杂的prompt模板但有一点很关键——把尺寸信息显式地放在前面。我习惯用这个格式Create a [part_type] with [num_features] features. Key dimensions: length..., width..., height..., hole_diameter... Feature details: [feature list]为什么尺寸要前置因为在encoder-decoder结构里序列开头的token会获得更高的注意力权重把关键数值放在前面等于给模型一个强提示让它在生成过程中更早意识到尺寸约束。实测下来这个简单的调整能让尺寸准确率提升好几个百分点。3.3 训练与推理的完整流程数据准备完成后进入模型微调阶段。我用的是CodeT5-small参数规模不大训练速度快适合先验证数据质量和管线正确性。from transformers import AutoTokenizer, AutoModelForSeq2SeqLM tokenizer AutoTokenizer.from_pretrained(Salesforce/codet5-small) model AutoModelForSeq2SeqLM.from_pretrained(Salesforce/codet5-small) inputs tokenizer( Create a bracket with four holes. length40 width25 height5 hole_diameter4, return_tensorspt, max_length128, truncationTrue ) outputs model.generate( **inputs, max_length256, num_beams4, early_stoppingTrue ) code tokenizer.decode(outputs[0], skip_special_tokensTrue) print(code)这是一个简化的推理示例。真正训练的时候需要把数据集切成train/val/test用标准的seq2seq训练方式学习率设置在5e-5到1e-4之间batch size根据显存调整。有一个细节值得注意不要使用fp16半精度训练。CAD代码生成中数值精度非常敏感半精度的浮点误差可能会让生成的尺寸参数出现系统性偏差导致一个倒角从2.0mm变成了1.98mm。虽然看起来只差0.02mm但到了装配阶段就可能是废件。训练完成后推理端不要用纯贪心解码至少要加beam searchbeam size设成4。这样会牺牲一点速度但代码的语法有效性会显著提升。如果你对推理延迟有硬性要求比如要做实时交互那可以考虑用constrained generation把输出限制在合法的token集合内。CadQuery的语法相对固定我们可以预定义一个合法的关键字集合在解码时强制屏蔽不在集合内的token。3.4 关键参数的选择逻辑实操中你会发现调参不是最费时间的最费时间的是理解每个参数为什么重要。我重点说三个第一个是max_length的设置。CAD代码往往比文本描述长得多但也不能无限制拉长。如果设置的输出长度超过实际需要模型会在生成结束后输出一堆无意义的填充token如果设置太短代码会在中间被截断整个模型直接废掉。我的经验是先对训练集里的代码长度做分位数统计选择p95值作为max_length。第二个是beam search的惩罚参数。设了length_penalty默认值是1.0但在CAD生成任务里我建议调到1.2左右。原因是CAD代码有效信息密度高多输出几个填充token的代价远不如保住一个完整特征。惩罚参数太小模型倾向于提前结束参数太大模型会拖出冗长的无效代码。1.2是一个经过多次实验的平衡值。第三个是数据清洗时的过滤阈值。训练数据里有很多无效样本比如渲染失败的、打开就报错的、体积为0的。建议用CadQuery批量编译所有代码样本能通过编译的才进训练集。不要只过滤“代码报错”的还要过滤“编译成功但体积异常”的。比如一个零件所有尺寸都正确但孔位置全挤在一个点上这种样本对模型是纯毒药。参数建议值作用常见错误max_length训练集代码长度的p95避免截断或填充过多盲目给定值导致生成失效num_beams4提升代码语法正确率beam太大导致显存爆炸length_penalty1.2控制输出简洁度默认1.0导致提前终止learning_rate5e-5微调稳定过大会导致Loss发散4. 评估指标的陷阱与常见问题排查4.1 四类评估指标的解读与误导text-to-cad项目的评估目前没有统一标准但主流的做法大致四类。第一类是Match率把生成的CAD模型和真实模型做相似度比对用IoU或者距离度量。这个指标很直观但也很容易被骗两个模型看起来很像但一个是实心件一个是带内腔的薄壁件在密度图上可能很接近实际功能却完全不同。第二类是代码正确率看生成代码能不能成功编译能编译就算成功。这个指标太粗糙了能编译不代表能制造更不代表符合需求。第三类是尺寸误差。这套指标最接近真实使用感受。用户说孔距50mm生成48mm就是失败。计算方式也比较直接从生成代码里提取所有带单位的数值与描述中出现的数字逐一匹配计算相对误差。这个指标做起来费劲但它反映的能力是最贴近生产力的。第四类是特征匹配度。把模型的特征树和用户描述的语义特征逐一比对比如“有没有开孔”“有没有倒角”“是不是拉伸特征”。这个指标更能反映模型是否真正理解了自然语言但目前实现成本高需要训练一个特征分类器或者依赖前文提到的树结构解析。这里必须泼一盆冷水如果只看Match率很多模型看起来已经很强了但拿到工业场景里一用就露馅。原因在于Match率是用几何形状相似度算的它天然偏向大尺度的形状一致性对“小但关键”的特征不敏感。一个缺失的M3螺纹孔在IoU计算里可能只占千分之几的面积但对制造来说就是废件。4.2 实操中最高频的六个问题根据我自己和身边朋友做类似项目跑出来的经验下面六个问题是出现频率最高的我把现象、原因和解决方案一起列出来。第一个问题是模型生成的代码编译失败。现象是CadQuery抛异常原因是tokenizer输出了一些无效代码片段。解决方案是推理时使用更大的beam size以及把“编译失败”的样本在训练时保留一小部分并用对比学习的方式让模型学会避开这些错误路径。第二个问题是尺寸偏小或偏大统一漂移。现象是模型生成的参数和真实值有稳定的比例偏差比如所有直径都乘以了0.98。原因往往是数据预处理时归一化方式不一致。建议在全流程保持统一的毫米单位只做固定尺度的缩放并在代码里加入尺度校验层生成后直接把所有长度数值与描述值做比率检查。第三个问题是孔特征生成不稳定。零件外形生成得很好但孔经常被漏掉或者数量不对。原因在于孔在CAD模型中是负空间特征放在代码层面看它往往是最后一个特征而decoder在长序列后半段注意力衰减严重。解决思路把训练时的样本做特征排序强制性把所有孔特征前移到代码前面如果不想改数据也可以在推理时分别预测“主体外形”和“孔特征”。第四个问题是模型对口语化描述的理解差。比如“大概五厘米”这种描述模型不知道它是50mm也没有容差范围的概念。我建议在处理语义时对模糊量词做规范化转换比如“大约”“左右”这类词直接映射为±1%的容差标记而不是让模型自行理解。第五个问题是多面构型的歧义。同一个自然语言描述可能对应无数个合法CAD模型。这个不是模型的问题是问题本身没有唯一解。解决方案是引入用户反馈闭环第一次生成后如果尺寸不符就用对话方式迭代修正把“单轮生成”变成“多轮人机协作”。实测下来两轮迭代内成功率和用户满意度都能大幅提升。第六个问题是训练数据里相似样本过多。Zoo数据集里有很多同一零件的微小变异比如孔距从40mm变41mm如果不去重模型会严重过拟合到高频的模式上泛化能力反而变差。建议在训练前做基于代码相似度的去重去除编辑距离过小的样本对。问题根因实操建议代码编译失败无效token输出beam size调大保留少量负样本尺寸统一漂移归一化不一致统一毫米单位加尺度校验层孔特征缺失注意力在长序列后端衰减特征前移或分开预测外型与孔口语描述理解差模糊量词与机构缺映射做模糊量词到容差的规范化多面构型歧义问题本身没有唯一解做多轮迭代交互训练过拟合重复样本太多按代码相似度去重5. 实操总结与个人经验text-to-cad从原理到落地中间隔着的不是一堵墙而是一连串细节问题。我做了这么多实验之后最深的体会是这个项目最难的永远不是模型结构而是数据质量、输出验证和评估体系这三者的循环建设。模型结构再先进数据里充满尺寸漂移和无效样本训练出来也只是一个漂亮的废物。我个人的习惯是每跑完一轮实验不要急着看指标涨了多少先随机抽一百个生成结果用CadQuery全部编译再手动打开看五十个。这一步虽然费时间但能最直观地暴露问题。等模型能稳定生成可编译、尺寸准确的模型之后再开始用自动指标做迭代优化。否则你在一个评估指标虚高的模型上反复调参浪费的只会是宝贵的迭代周期。另外一个经验是text-to-cad项目的成功很大程度上取决于它跟实际设计流程的整合程度。如果只是做一个“模型输出结果给人看”的Demo那永远停留在“AI生成示意图”的层面。真正有价值的方向是让生成的参数化模型直接嵌入到下游的设计链路里比如进CAE仿真、进CAM加工、进BOM表。这个方向上目前还没出现绝对的最佳实践但值得所有人投入精力去摸索。