做AI辅助设计这段时间我一直在盯text-to-cad这个方向。简单说它就是让你直接用自然语言描述一个零件比如“一个带四个通孔的矩形法兰盘”系统自动帮你生成对应的CAD模型文件而不是靠你手动去SolidWorks或者Fusion 360里一步步拉草图、做拉伸切除。这个方向最近热起来是因为大语言模型把“人话”转成“程序化指令”的能力已经成熟到可以落地了再叠加上参数化建模本身的结构化特点整套链路就跑得通了。这篇文章我想把这几个月从读论文到跑通开源项目的经验整理出来给准备入坑这个方向的工程师、设计师和AI应用开发者一份能直接用的实操参考。1. text-to-cad到底解决了什么问题1.1 传统CAD建模为什么难住了一大批人我见过太多人被CAD软件劝退的场景。三维建模工具的学习曲线非常陡界面里密密麻麻的约束、基准面、草图关系每一个都是坑。即使是机械专业的学生能把SolidWorks用得溜的也屈指可数。更有意思的是真正到了企业里大量零部件的建模工作其实高度重复——法兰、支架、轴承座、导流板结构大同小异无非是改几个关键尺寸和孔位。这种“换个尺寸再画一遍”的工作让人画到怀疑人生。text-to-cad要解决的正是这个问题。它的核心思路不是让AI替代你成为一个建模大师而是把“怎么说清楚一个零件”变成你的核心能力把“怎么在软件里把这堆特征垒出来”交给模型去完成。你只需要告诉它零件的功能、形状、主要尺寸、孔位要求剩下的事情由模型自动生成参数化建模指令。这个转变的价值在于它把人的精力从“操作细节”解放到“设计意图”这才是CAD建模真正有价值的部分。1.2 技术路线的分岔路口程序生成派与图像生成派现在commonsense里有两条主流技术路线我一开始也在这两条路之间犹豫了很久。一条是图像派直接用一个文本到图像的扩散模型生成零件的三视图或体素表示然后再想办法转换成CAD模型。这条路直观但有个绕不过去的硬伤生成的体素或网格是离散的三角形面片转成参数化CAD模型非常困难最终得到的往往是“看着像”但没法编辑、没法出工程图的壳子。另一条是程序生成派让模型直接输出CAD建模脚本比如OpenSCAD代码或者AutoCAD命令序列。这是Text2CAD这类项目采用的路线也明显更符合工程实际需求。原因很简单CAD模型在工业界的本质不是一堆三角面片而是一棵由特征操作组成的参数化历史树。你回头要改尺寸、要出BOM、要做CAE分析都需要这棵特征树。程序生成派天然保证了输出能被下游工具链继续处理。1.3 为什么参数化建模被选中说到这儿你可能要问了为什么非要是参数化建模直接生成STEP或IGES文件不行吗这里有个工程现实问题STEP文件描述的是边界表示它保存了最终几何但丢了建模过程。如果我想把法兰盘的厚度从10毫米改成8毫米在STEP层面操作就是在跟一堆曲面死磕而在参数化历史里改一个数字就完了。Text2CAD这类项目选择了把问题定义成序列生成任务给定一段自然语言描述输出一条由CAD命令组成的执行序列。这些命令按顺序执行后对应的参数化模型就建出来了。这意味着AI生成的不是一个死的几何体而是一个活的、可修改的设计过程。这背后的模型架构和训练数据组织方式就成了整个项目最核心的技术秘密。2. 核心细节解析与实操要点2.1 Prompt工程如何让模型听懂人话我在跑Text2CAD的时候最大的感受是模型的能力边界很大程度上不取决于模型本身而取决于你怎么描述这个零件。官方文档和论文里给了一条很关键的经验——描述必须包含三个层次的信息几何形状什么形状的主体、特征操作孔、槽、倒角、螺纹、关键尺寸直径、长度、厚度。缺一层生成结果就会往不可控的方向跑。举个例子你如果只说“帮我建一个支架”模型大概率会蒙。但如果你说“一个L形的支架竖直板高40毫米、水平板长60毫米、厚度5毫米水平板上有两个直径6毫米的沉头孔”输出质量和前者完全不在一个量级。我测试下来描述越具体的生成成功率能翻一倍以上。所以如果你把这个技术用到自己的项目里第一步不是调模型而是先把你的“产品需求文档”翻译成这种结构化描述模板。2.2 DeepCAD数据集与SDF格式的底层逻辑整个text-to-cad的基石是DeepCAD这个数据集。它是目前公开可用的最大规模参数化CAD数据集里面包含了十几万个三维CAD模型每个模型都被转换成了参数化建模指令序列。Text2CAD团队在这个基础上做了二次加工他们用大语言模型为每条指令序列生成对应的自然语言描述然后经过一轮一轮的筛选和人工矫正得到一个约十七万对的“自然语言—CAD命令”平行语料库。这个语料库既用来训练生成模型也用来做评测基准。有个细节值得留意DeepCAD原始数据格式是把CAD模型离散成指令序列每个指令由操作码和参数组成类似于“新建草图→画圆→拉伸→再画圆→拉伸切除”这种流水账。模型训练的任务就是从这种流水账里学会几何直觉这其实挺反直觉的——它没有显式的坐标网格没有三维卷积纯靠序列模型在token之间建立空间关系的隐式表达。好在CAD指令本身高度规律化序列模型在这个任务上的表现比在开放语言任务上稳定得多。2.3 网络架构从Transformer到扩散模型从模型架构来看text-to-cad生成部分的主流方案是Transformer解码器。输入是自然语言文本的embedding序列输出是CAD命令token序列。这个框架跟GPT做代码生成本质上是一回事所以社区里有很多实现直接复用LLaMA或GPT-2的backbone再在CAD语料上做微调。我自己试下来从零训练一个百万参数级别的小模型效果并不理想但用开源预训练模型做LoRA微调效果会好很多这也是目前性价比最高的做法。除了纯自回归生成现在也有团队在尝试把扩散模型用到CAD序列生成上。这个方向的动机是自回归生成的误差会一路累积到序列后半段经常出现特征错乱而扩散模型在整体结构一致性上可能有优势。不过这个方向还比较新公开可复现的成果不多如果你不是做研究暂时可以观望。2.4 精度与对齐CAD世界里一个小数点就是天壤之别做text-to-cad和做普通文本生成有一个非常大的区别精度极度敏感。在聊天模型里token预测错了可以糊弄过去但在CAD生成里一个命令里的坐标小数点错一位孔的位置就偏了十万八千里整个零件就废了。所以实操中你需要特别关注两件事第一模型的数值tokenize方式。很多模型会把数字拆成若干token处理但CAD参数是连续浮点数离散化方式直接决定精度上限。如果直接用BPE切数字五位数以上的尺寸很容易被切碎导致误差巨大。比较靠谱的做法是在数据预处理阶段对尺寸做clamping限制到一个合理范围比如1毫米到500毫米之间然后保留三位小数。第二生成后的校验环节必不可少。你不能生成完就直接交付至少要做一键的几何合法性校验比如检查是否有自相交、是否有退化面、特征是否完全落在工件轮廓内。这个校验步骤在工程交付场景里是底线谁跳过谁下午就得去车间挨骂。3. 实操过程与核心环节实现3.1 环境搭建与依赖选择先把环境跑起来这是所有后续工作的前提。我推荐直接在Linux服务器上用CUDA环境跑这套流程Windows虽然也能跑但在编译一些C扩展的时候坑比较多。环境依赖主要分三块深度学习框架、CAD命令解析与执行库、可视化与验证工具。conda create -n text2cad python3.9 conda activate text2cad pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install transformers dataset accelerate peft pip install cadquery2.4.0 pip install jupyter matplotlib trimesh这里的cadquery是整个链路里的关键角色。它负责把你生成的命令序列真正执行成三维模型。假如没有cadquery你生成一堆指令token之后根本没地方验证它对不对。另外建议装一个open-cascade的python绑定CadQuery底层就是基于它做的后面做STEP导出和布尔运算都会用到。3.2 跑通推理加载权重与生成测试模型推理是整个流程里最让人兴奋也最容易幻灭的部分。我第一次跑通满心期待输入一段描述结果输出了一串乱码——括号没闭合、操作码不存在、参数超出范围。后来才明白从文本到CAD命令这层模型远没到可以完全放飞的状态推理阶段必须有后处理兜底。建议的推理流程是先用微调后的模型生成一个长度为512token的原始序列然后立刻做语法解析。如果解析失败不要急着重新生成先从序列尾部做截断重试——CAD命令序列往往前面是对的越往后错得越离谱尾部截断到最后一个合法命令往往还有救。我维护的推理脚本核心逻辑大概是这样from transformers import AutoTokenizer, AutoModelForCausalLM import cadquery as cq tokenizer AutoTokenizer.from_pretrained(your_model_path) model AutoModelForCausalLM.from_pretrained(your_model_path).cuda() desc 一个L形支架竖直板高40毫米水平板长60毫米厚度5毫米水平板上有两个直径6毫米的沉头孔 inputs tokenizer(desc, return_tensorspt).to(cuda) for max_len in [512, 384, 256]: outputs model.generate(**inputs, max_new_tokensmax_len, temperature0.7) cad_code tokenizer.decode(outputs[0], skip_special_tokensTrue) try: result cq. Workplane()._compile(cad_code) break except Exception: continue注意这里的temperature设置。我在大量测试后发现0.7到0.8之间是比较合适的太低容易输出模板化但错误的重复序列太高容易胡言乱语。另外生成过程最好打开top-p采样p设0.9左右能有效避免解码阶段陷入循环。这个逻辑跟文本生成的体验完全不一样——在text-to-cad里你宁可让它极端保守也别让它自由发挥。3.3 模型训练与微调数据准备是重头戏如果你要针对自有零件库做微调训练阶段的数据准备才是真正的重头戏。文本描述不是你想怎么写就怎么写需要统一成固定模板。我整理了一下自己的数据预处理流程大致是第一步从设计文档、历史订单、BOM表里提取零件描述统一单位全部转成毫米第二步把描述拆成“主体形状特征列表尺寸表”三段式结构每一段都有固定起始标记第三步把CAD命令序列按操作类型分组每个操作前加上显式的特征类型标记比如[HOLE] [SLOT] [CHAMFER]。数据量上我的体感是至少准备一万条以上质量过关的平行语料低于这个量模型学不到稳定的映射关系。如果数据集规模不够做几轮数据增强——比如同义改写、尺寸等比例缩放、特征顺序随机打乱——比硬调模型参数有用得多。微调阶段我建议用LoRA而不是全参数微调。一个很现实的原因是CAD命令序列非常长全参数微调需要极高的显存而LoRA只训练一小部分注入的低秩矩阵显存需求直接下降一个数量级效果在大多数场景下也够用python finetune.py \ --base_model meta-llama/Llama-2-7b-hf \ --data_path ./data/text2cad_train.json \ --output_dir ./ckpt/text2cad_lora \ --batch_size 8 \ --num_epochs 3 \ --learning_rate 2e-4 \ --lora_r 8 \ --lora_alpha 16 \ --lora_dropout 0.05跑起来之后建议每500步保存一次checkpoint并且每次都跑一遍验证集上的“CAD编译成功率”。这个指标比loss更直观因为loss只能告诉你token预测对了多少而这个成功率直接告诉你最终模型的可用性。我自己在这个阶段踩过一个坑训练轮数过多会导致过拟合模型开始机械复读训练集里的常见特征对没见过的新尺寸描述只会生成离大谱的近似模型。后来我把epoch数控制在3以下问题就消失了。3.4 后处理与可视化导出模型输出经过CadQuery执行成功之后还没到大功告成的时候。工业交付最常见的需求是导出STEP文件这是所有主流CAD软件都能打开的格式。CadQuery的exportStep方法直接搞定但有个地方要注意如果你后续要把模型拿去仿真或3D打印还需要做一个几何清理——合并重合面、去除零厚度特征、修复法向不一致。这一步用CadQuery的clean()方法能解决大部分问题但复杂的模型可能需要手动介入。可视化我一般用trimesh加载生成结果直接在Jupyter里查看。还有一个更直观的验证工具是直接把STEP文件丢进FreeCAD里打开看特征树是否完整——特征树里每个步骤都和你的原始描述对得上才算真正合格。千万别只看渲染图渲染图好看不代表尺寸对尺寸对不代表特征操作顺序合理。工业上特征树顺序错了后续改图就是灾难。4. 常见问题与排查技巧实录4.1 生成结果惨不忍睹先查这几个地方我整理了这段时间里遇到频率最高的几类问题做成一个排查表你对照着看能省不少时间现象直接原因排查方向输出全是重复命令无限拉伸温度过高导致模式坍缩降低temperature到0.7启用top-p命令合法但模型是个片体拉伸高度参数溢出或被离散化检查数据预处理时尺寸clamping范围孔位总是偏移1-2毫米数字tokenize切分错误换成按位编码数字或检查tokenizer词表编译成功率很高但模型千篇一律训练数据重复度过高数据增强增加特征组合多样性长描述时后半段开始乱码自回归误差累积生成时对超长描述做分段或截断这里面我想特别提一下第二个问题。片体在CAD里是最隐蔽的故障——渲染的时候什么都看不出来一旦拿去切片或者做有限元分析就原形毕露。你会发现模型几乎所有面都正常但有一个面没封闭特征树里那个拉伸操作的高度参数是负值或者零。这个在自回归生成模型里非常容易被触发因为模型对负数和小数的表征能力天然弱于正数整数。所以我的建议是数据预处理阶段做绝对值的归一化把所有坐标和尺寸统一限制在0到1之间并在解码端做后置反归一化这样能让数值预测的难度大幅下降。4.2 训练不收敛的排查思路如果你是从零开始训练text-to-cad模型而不是用预训练模型微调那可能会遭遇训练不收敛的问题。loss曲线像心跳一样上下跳动或者干脆一路横盘。我排查这种情况的顺序是先检查数据tokenization看看训练数据里是否有太多超长序列被截断导致模型永远看不到完整特征再检查学习率CAD序列生成任务的loss曲面比语言模型更陡峭学习率稍微大一点就会导致震荡我一般从1e-4起步配合warmup和cosine schedule最后检查模型是否真的接触到了数值预测任务如果数据集的尺寸字段有大量重复值模型会学会偷懒直接复制最常见的数字。这里有个我试过很有效的技巧把CAD编译成功率作为早停指标在每个epoch结束时对验证集做一次完整的编译成功率不再增长就果断停止训练哪怕loss曲线还在缓慢下降。因为在这个任务里loss下降而编译成功率不动往往意味着模型在优化token层面的表现但并没有学会真正的几何关系继续训练只是浪费时间。4.3 从结果到产品把实验模型变成可用工作流到了这个阶段你需要把模型封装成一套可复用的自动化流水线。我的建议是三步走第一步写一个统一入口的API输入自然语言描述输出STEP文件第二步在这条链路里加一个“人工审核”节点生成结果先出预览图设计人员确认后再进PDM系统第三步把每次生成的设计图、修改意见和最终确认结果回收到数据集里定期重新微调。这条飞轮一转起来你会发现模型越用越顺手因为你的数据集在持续覆盖自己业务里的边角案例。我也被人问过多次这个东西会不会让设计师失业我在实操中的体会是短期内恰恰相反。text-to-cad真正淘汰的不是设计师而是那些重复性极高的“画图工”岗位。设计师把更多时间花在描述需求和审查结果上反而是被这个工具放大了生产力。成熟的工程师不会拒绝一个能让自己少加班的工具。最后再分享一个小技巧调试text-to-cad模型的时候不要只盯着“生成成功”这一个指标。我在自己的项目里会同时记录“第一次生成就通过编译”和“经过截断修复后编译成功”两个数据前者反映模型原始理解力后者反映模型容错能力。两者分开评估你才能准确判断当前模型的瓶颈到底在语义理解上还是在数值生成上。这个思路同样适合你做模型版本迭代时的效果对比。 
长河君 · 2026/10/26 16:02:50 · 阅读 1.2k Text-to-CAD实战：从自然语言到参数化建模的完整技术解析
做AI辅助设计这段时间我一直在盯text-to-cad这个方向。简单说它就是让你直接用自然语言描述一个零件比如“一个带四个通孔的矩形法兰盘”系统自动帮你生成对应的CAD模型文件而不是靠你手动去SolidWorks或者Fusion 360里一步步拉草图、做拉伸切除。这个方向最近热起来是因为大语言模型把“人话”转成“程序化指令”的能力已经成熟到可以落地了再叠加上参数化建模本身的结构化特点整套链路就跑得通了。这篇文章我想把这几个月从读论文到跑通开源项目的经验整理出来给准备入坑这个方向的工程师、设计师和AI应用开发者一份能直接用的实操参考。1. text-to-cad到底解决了什么问题1.1 传统CAD建模为什么难住了一大批人我见过太多人被CAD软件劝退的场景。三维建模工具的学习曲线非常陡界面里密密麻麻的约束、基准面、草图关系每一个都是坑。即使是机械专业的学生能把SolidWorks用得溜的也屈指可数。更有意思的是真正到了企业里大量零部件的建模工作其实高度重复——法兰、支架、轴承座、导流板结构大同小异无非是改几个关键尺寸和孔位。这种“换个尺寸再画一遍”的工作让人画到怀疑人生。text-to-cad要解决的正是这个问题。它的核心思路不是让AI替代你成为一个建模大师而是把“怎么说清楚一个零件”变成你的核心能力把“怎么在软件里把这堆特征垒出来”交给模型去完成。你只需要告诉它零件的功能、形状、主要尺寸、孔位要求剩下的事情由模型自动生成参数化建模指令。这个转变的价值在于它把人的精力从“操作细节”解放到“设计意图”这才是CAD建模真正有价值的部分。1.2 技术路线的分岔路口程序生成派与图像生成派现在commonsense里有两条主流技术路线我一开始也在这两条路之间犹豫了很久。一条是图像派直接用一个文本到图像的扩散模型生成零件的三视图或体素表示然后再想办法转换成CAD模型。这条路直观但有个绕不过去的硬伤生成的体素或网格是离散的三角形面片转成参数化CAD模型非常困难最终得到的往往是“看着像”但没法编辑、没法出工程图的壳子。另一条是程序生成派让模型直接输出CAD建模脚本比如OpenSCAD代码或者AutoCAD命令序列。这是Text2CAD这类项目采用的路线也明显更符合工程实际需求。原因很简单CAD模型在工业界的本质不是一堆三角面片而是一棵由特征操作组成的参数化历史树。你回头要改尺寸、要出BOM、要做CAE分析都需要这棵特征树。程序生成派天然保证了输出能被下游工具链继续处理。1.3 为什么参数化建模被选中说到这儿你可能要问了为什么非要是参数化建模直接生成STEP或IGES文件不行吗这里有个工程现实问题STEP文件描述的是边界表示它保存了最终几何但丢了建模过程。如果我想把法兰盘的厚度从10毫米改成8毫米在STEP层面操作就是在跟一堆曲面死磕而在参数化历史里改一个数字就完了。Text2CAD这类项目选择了把问题定义成序列生成任务给定一段自然语言描述输出一条由CAD命令组成的执行序列。这些命令按顺序执行后对应的参数化模型就建出来了。这意味着AI生成的不是一个死的几何体而是一个活的、可修改的设计过程。这背后的模型架构和训练数据组织方式就成了整个项目最核心的技术秘密。2. 核心细节解析与实操要点2.1 Prompt工程如何让模型听懂人话我在跑Text2CAD的时候最大的感受是模型的能力边界很大程度上不取决于模型本身而取决于你怎么描述这个零件。官方文档和论文里给了一条很关键的经验——描述必须包含三个层次的信息几何形状什么形状的主体、特征操作孔、槽、倒角、螺纹、关键尺寸直径、长度、厚度。缺一层生成结果就会往不可控的方向跑。举个例子你如果只说“帮我建一个支架”模型大概率会蒙。但如果你说“一个L形的支架竖直板高40毫米、水平板长60毫米、厚度5毫米水平板上有两个直径6毫米的沉头孔”输出质量和前者完全不在一个量级。我测试下来描述越具体的生成成功率能翻一倍以上。所以如果你把这个技术用到自己的项目里第一步不是调模型而是先把你的“产品需求文档”翻译成这种结构化描述模板。2.2 DeepCAD数据集与SDF格式的底层逻辑整个text-to-cad的基石是DeepCAD这个数据集。它是目前公开可用的最大规模参数化CAD数据集里面包含了十几万个三维CAD模型每个模型都被转换成了参数化建模指令序列。Text2CAD团队在这个基础上做了二次加工他们用大语言模型为每条指令序列生成对应的自然语言描述然后经过一轮一轮的筛选和人工矫正得到一个约十七万对的“自然语言—CAD命令”平行语料库。这个语料库既用来训练生成模型也用来做评测基准。有个细节值得留意DeepCAD原始数据格式是把CAD模型离散成指令序列每个指令由操作码和参数组成类似于“新建草图→画圆→拉伸→再画圆→拉伸切除”这种流水账。模型训练的任务就是从这种流水账里学会几何直觉这其实挺反直觉的——它没有显式的坐标网格没有三维卷积纯靠序列模型在token之间建立空间关系的隐式表达。好在CAD指令本身高度规律化序列模型在这个任务上的表现比在开放语言任务上稳定得多。2.3 网络架构从Transformer到扩散模型从模型架构来看text-to-cad生成部分的主流方案是Transformer解码器。输入是自然语言文本的embedding序列输出是CAD命令token序列。这个框架跟GPT做代码生成本质上是一回事所以社区里有很多实现直接复用LLaMA或GPT-2的backbone再在CAD语料上做微调。我自己试下来从零训练一个百万参数级别的小模型效果并不理想但用开源预训练模型做LoRA微调效果会好很多这也是目前性价比最高的做法。除了纯自回归生成现在也有团队在尝试把扩散模型用到CAD序列生成上。这个方向的动机是自回归生成的误差会一路累积到序列后半段经常出现特征错乱而扩散模型在整体结构一致性上可能有优势。不过这个方向还比较新公开可复现的成果不多如果你不是做研究暂时可以观望。2.4 精度与对齐CAD世界里一个小数点就是天壤之别做text-to-cad和做普通文本生成有一个非常大的区别精度极度敏感。在聊天模型里token预测错了可以糊弄过去但在CAD生成里一个命令里的坐标小数点错一位孔的位置就偏了十万八千里整个零件就废了。所以实操中你需要特别关注两件事第一模型的数值tokenize方式。很多模型会把数字拆成若干token处理但CAD参数是连续浮点数离散化方式直接决定精度上限。如果直接用BPE切数字五位数以上的尺寸很容易被切碎导致误差巨大。比较靠谱的做法是在数据预处理阶段对尺寸做clamping限制到一个合理范围比如1毫米到500毫米之间然后保留三位小数。第二生成后的校验环节必不可少。你不能生成完就直接交付至少要做一键的几何合法性校验比如检查是否有自相交、是否有退化面、特征是否完全落在工件轮廓内。这个校验步骤在工程交付场景里是底线谁跳过谁下午就得去车间挨骂。3. 实操过程与核心环节实现3.1 环境搭建与依赖选择先把环境跑起来这是所有后续工作的前提。我推荐直接在Linux服务器上用CUDA环境跑这套流程Windows虽然也能跑但在编译一些C扩展的时候坑比较多。环境依赖主要分三块深度学习框架、CAD命令解析与执行库、可视化与验证工具。conda create -n text2cad python3.9 conda activate text2cad pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install transformers dataset accelerate peft pip install cadquery2.4.0 pip install jupyter matplotlib trimesh这里的cadquery是整个链路里的关键角色。它负责把你生成的命令序列真正执行成三维模型。假如没有cadquery你生成一堆指令token之后根本没地方验证它对不对。另外建议装一个open-cascade的python绑定CadQuery底层就是基于它做的后面做STEP导出和布尔运算都会用到。3.2 跑通推理加载权重与生成测试模型推理是整个流程里最让人兴奋也最容易幻灭的部分。我第一次跑通满心期待输入一段描述结果输出了一串乱码——括号没闭合、操作码不存在、参数超出范围。后来才明白从文本到CAD命令这层模型远没到可以完全放飞的状态推理阶段必须有后处理兜底。建议的推理流程是先用微调后的模型生成一个长度为512token的原始序列然后立刻做语法解析。如果解析失败不要急着重新生成先从序列尾部做截断重试——CAD命令序列往往前面是对的越往后错得越离谱尾部截断到最后一个合法命令往往还有救。我维护的推理脚本核心逻辑大概是这样from transformers import AutoTokenizer, AutoModelForCausalLM import cadquery as cq tokenizer AutoTokenizer.from_pretrained(your_model_path) model AutoModelForCausalLM.from_pretrained(your_model_path).cuda() desc 一个L形支架竖直板高40毫米水平板长60毫米厚度5毫米水平板上有两个直径6毫米的沉头孔 inputs tokenizer(desc, return_tensorspt).to(cuda) for max_len in [512, 384, 256]: outputs model.generate(**inputs, max_new_tokensmax_len, temperature0.7) cad_code tokenizer.decode(outputs[0], skip_special_tokensTrue) try: result cq. Workplane()._compile(cad_code) break except Exception: continue注意这里的temperature设置。我在大量测试后发现0.7到0.8之间是比较合适的太低容易输出模板化但错误的重复序列太高容易胡言乱语。另外生成过程最好打开top-p采样p设0.9左右能有效避免解码阶段陷入循环。这个逻辑跟文本生成的体验完全不一样——在text-to-cad里你宁可让它极端保守也别让它自由发挥。3.3 模型训练与微调数据准备是重头戏如果你要针对自有零件库做微调训练阶段的数据准备才是真正的重头戏。文本描述不是你想怎么写就怎么写需要统一成固定模板。我整理了一下自己的数据预处理流程大致是第一步从设计文档、历史订单、BOM表里提取零件描述统一单位全部转成毫米第二步把描述拆成“主体形状特征列表尺寸表”三段式结构每一段都有固定起始标记第三步把CAD命令序列按操作类型分组每个操作前加上显式的特征类型标记比如[HOLE] [SLOT] [CHAMFER]。数据量上我的体感是至少准备一万条以上质量过关的平行语料低于这个量模型学不到稳定的映射关系。如果数据集规模不够做几轮数据增强——比如同义改写、尺寸等比例缩放、特征顺序随机打乱——比硬调模型参数有用得多。微调阶段我建议用LoRA而不是全参数微调。一个很现实的原因是CAD命令序列非常长全参数微调需要极高的显存而LoRA只训练一小部分注入的低秩矩阵显存需求直接下降一个数量级效果在大多数场景下也够用python finetune.py \ --base_model meta-llama/Llama-2-7b-hf \ --data_path ./data/text2cad_train.json \ --output_dir ./ckpt/text2cad_lora \ --batch_size 8 \ --num_epochs 3 \ --learning_rate 2e-4 \ --lora_r 8 \ --lora_alpha 16 \ --lora_dropout 0.05跑起来之后建议每500步保存一次checkpoint并且每次都跑一遍验证集上的“CAD编译成功率”。这个指标比loss更直观因为loss只能告诉你token预测对了多少而这个成功率直接告诉你最终模型的可用性。我自己在这个阶段踩过一个坑训练轮数过多会导致过拟合模型开始机械复读训练集里的常见特征对没见过的新尺寸描述只会生成离大谱的近似模型。后来我把epoch数控制在3以下问题就消失了。3.4 后处理与可视化导出模型输出经过CadQuery执行成功之后还没到大功告成的时候。工业交付最常见的需求是导出STEP文件这是所有主流CAD软件都能打开的格式。CadQuery的exportStep方法直接搞定但有个地方要注意如果你后续要把模型拿去仿真或3D打印还需要做一个几何清理——合并重合面、去除零厚度特征、修复法向不一致。这一步用CadQuery的clean()方法能解决大部分问题但复杂的模型可能需要手动介入。可视化我一般用trimesh加载生成结果直接在Jupyter里查看。还有一个更直观的验证工具是直接把STEP文件丢进FreeCAD里打开看特征树是否完整——特征树里每个步骤都和你的原始描述对得上才算真正合格。千万别只看渲染图渲染图好看不代表尺寸对尺寸对不代表特征操作顺序合理。工业上特征树顺序错了后续改图就是灾难。4. 常见问题与排查技巧实录4.1 生成结果惨不忍睹先查这几个地方我整理了这段时间里遇到频率最高的几类问题做成一个排查表你对照着看能省不少时间现象直接原因排查方向输出全是重复命令无限拉伸温度过高导致模式坍缩降低temperature到0.7启用top-p命令合法但模型是个片体拉伸高度参数溢出或被离散化检查数据预处理时尺寸clamping范围孔位总是偏移1-2毫米数字tokenize切分错误换成按位编码数字或检查tokenizer词表编译成功率很高但模型千篇一律训练数据重复度过高数据增强增加特征组合多样性长描述时后半段开始乱码自回归误差累积生成时对超长描述做分段或截断这里面我想特别提一下第二个问题。片体在CAD里是最隐蔽的故障——渲染的时候什么都看不出来一旦拿去切片或者做有限元分析就原形毕露。你会发现模型几乎所有面都正常但有一个面没封闭特征树里那个拉伸操作的高度参数是负值或者零。这个在自回归生成模型里非常容易被触发因为模型对负数和小数的表征能力天然弱于正数整数。所以我的建议是数据预处理阶段做绝对值的归一化把所有坐标和尺寸统一限制在0到1之间并在解码端做后置反归一化这样能让数值预测的难度大幅下降。4.2 训练不收敛的排查思路如果你是从零开始训练text-to-cad模型而不是用预训练模型微调那可能会遭遇训练不收敛的问题。loss曲线像心跳一样上下跳动或者干脆一路横盘。我排查这种情况的顺序是先检查数据tokenization看看训练数据里是否有太多超长序列被截断导致模型永远看不到完整特征再检查学习率CAD序列生成任务的loss曲面比语言模型更陡峭学习率稍微大一点就会导致震荡我一般从1e-4起步配合warmup和cosine schedule最后检查模型是否真的接触到了数值预测任务如果数据集的尺寸字段有大量重复值模型会学会偷懒直接复制最常见的数字。这里有个我试过很有效的技巧把CAD编译成功率作为早停指标在每个epoch结束时对验证集做一次完整的编译成功率不再增长就果断停止训练哪怕loss曲线还在缓慢下降。因为在这个任务里loss下降而编译成功率不动往往意味着模型在优化token层面的表现但并没有学会真正的几何关系继续训练只是浪费时间。4.3 从结果到产品把实验模型变成可用工作流到了这个阶段你需要把模型封装成一套可复用的自动化流水线。我的建议是三步走第一步写一个统一入口的API输入自然语言描述输出STEP文件第二步在这条链路里加一个“人工审核”节点生成结果先出预览图设计人员确认后再进PDM系统第三步把每次生成的设计图、修改意见和最终确认结果回收到数据集里定期重新微调。这条飞轮一转起来你会发现模型越用越顺手因为你的数据集在持续覆盖自己业务里的边角案例。我也被人问过多次这个东西会不会让设计师失业我在实操中的体会是短期内恰恰相反。text-to-cad真正淘汰的不是设计师而是那些重复性极高的“画图工”岗位。设计师把更多时间花在描述需求和审查结果上反而是被这个工具放大了生产力。成熟的工程师不会拒绝一个能让自己少加班的工具。最后再分享一个小技巧调试text-to-cad模型的时候不要只盯着“生成成功”这一个指标。我在自己的项目里会同时记录“第一次生成就通过编译”和“经过截断修复后编译成功”两个数据前者反映模型原始理解力后者反映模型容错能力。两者分开评估你才能准确判断当前模型的瓶颈到底在语义理解上还是在数值生成上。这个思路同样适合你做模型版本迭代时的效果对比。