★ FEATURED ARTICLE 做CAD设计的朋友这两年应该没少听说text-to-cad这个词。简单说就是给AI一句自然语言描述比如一个带四个螺栓孔的安装底板长120毫米宽80毫米厚10毫米它直接给你生成一个可编辑的参数化CAD模型输出STEP或STL文件不再需要你手动拉草图、加约束、做拉伸切除。我大概是去年开始认真折腾这个方向的。一开始也觉得是噱头毕竟CAD建模这行门槛不低草图约束、特征树、布尔运算这些逻辑不是一句两句能讲清楚的。但实际跟进了几轮开源项目和技术报告之后我承认自己判断错了text-to-cad不是玩具它正在变成工程前期方案探索、非标件快速生成、甚至教学场景里非常实用的工具。这篇文章我就把自己从原理到实操踩过的坑、验证过的流程完整梳理一遍给想入手这个方向的朋友一个参考。1. 内容整体设计与思路拆解1.1 text-to-cad 到底在解决什么问题先说痛点。传统CAD建模的路径本质上是把脑子里想的三维形状翻译成软件能执行的特征操作。这个翻译过程极度依赖经验一个老师傅画一个支架可能只要十分钟但新手光是搞明白先建基准面还是先画草图就能卡半小时。更麻烦的是很多结构件、连接件、外壳类零件功能需求是清晰的但三维形态有无数种实现方式手动建模的时间往往花在反复调整尺寸和特征顺序上。text-to-cad的定位不是取代设计师而是把想法到初步模型这一段最耗时、最不 creative 的环节自动化。它做的事情本质上是把自然语言映射成一系列CAD操作序列。这个操作序列不是渲染出来的图片而是真实的建模指令——拉伸、旋转、打孔、倒角、布尔差集等等。所以它生成的模型跟你手工建的一样特征树可展开、尺寸可改、后续能进CAM或者仿真流程。我自己的理解是这玩意儿解决的是方案探索成本问题。以前想对比三五个不同布局的外壳方案每个都得完整建模半天就没了。现在用text-to-cad一个上午能出十几版初始方案挑出靠谱的再精修效率不是一个量级。1.2 方案选型生成式AI走哪条技术路线目前text-to-cad的主流实现不是大家想象中那种扩散模型直接生成点云再变成网格而是走的大语言模型路线。这背后的逻辑其实很朴素CAD模型本质上可以被表示成有序的命令序列而大语言模型最擅长的恰恰就是生成序列。具体来说业界主流做法是把CAD建模过程拆解成边界表示和构造实体几何两条路。边界表示记录的是模型的最终几何拓扑——哪些面、哪些边、哪些顶点适合存储和交换但不适合让模型思考如何建模构造实体几何记录的是建模操作树——先画什么、再切什么、最后倒角多少这天然就是一种结构化语言。text-to-cad选的是后者这种命令序列的表达方式把建模过程变成了一串带参数的指令。为了避免读者觉得抽象我用一个类比让AI生成CAD模型相当于让AI写一篇作文。如果你只给它看最终印刷出来的文章边界表示)它很难学会写作逻辑但如果你给它看草稿纸上的修改痕迹、段落大纲、每个句子怎么搭出来的构造实体几何)它就更容易模仿这个过程。text-to-cad的路线就是后者而且指令本身是显式、可校验的这也是它能落地的关键。2. 核心细节解析与实操要点2.1 数据底座CAD命令序列怎么组织既然是让模型生成命令序列那么训练数据就是整个项目的命脉。我看过的几个开源项目比如基于合成数据做训练的Text2CAD它的数据管道大致是这样的先准备好大量带特征树的原始CAD模型然后把特征树按拓扑顺序转译成JSON格式的命令序列每个命令包含操作类型和完整的参数列表。举个例子一个简单的带孔方块它的命令序列大致长这样[ {op: Box, params: {x: 120.0, y: 80.0, z: 10.0}}, {op: Cylinder, params: {radius: 6.0, height: 10.0}}, {op: Translate, params: {x: 20.0, y: 20.0, z: 0.0}}, {op: Subtract, params: {}} ]这里每个op字段代表一个建模动作params是它的参数。模型要学的就是从一句自然语言里提取出长120、宽80、厚10、四个角落各一个直径6的孔这些信息然后排列组合出正确的操作序列。这个序列的生成质量直接决定了最终模型是不是你想要的。这里有个重要细节如果模型生成的命令只有形状而没位置那布尔运算的一堆实体可能全堆在一起模型完全报废。所以数据集里必须包含完整的变换信息——平移、旋转、镜像缺一不可。我自己清洗数据的时候就踩过这个坑后面会细说。2.2 模型的架构设计为什么是视觉语言模型而不是纯文本模型早期一些尝试只有文本输入但实际工程里很多需求是带着参考图的比如照着这个草图做一个类似的支架。这就推动了text-to-cad从纯语言模型向视觉语言模型演进。给模型加一个视觉编码器让它能同时理解文字和图片。我关注的一个代表性项目是MM-Text2CAD它在Llama-3-8B的基础之上通过监督微调和RLHF训练把通用大模型改造成一个CAD专家。这条路线最大的优点是站在巨人肩膀上——不需要从头训练一个模型而是在现有底座上做领域适配。8B的参数量也控制得比较合适个人开发者用消费级显卡还能跑一跑推理不像几百B的模型那样只能看热闹。另外我发现后训练阶段除了传统的RLHF现在越来越流行用RLVR也就是可验证奖励的强化学习。对于CAD生成来说这个可验证性特别好定义生成的命令序列是不是合法JSON能不能被CAD内核执行执行完的结果是不是封闭实体数值是否落在合理公差范围内。这些都是客观可判的不需要人类打分。所以模型可以自己试错、自己改进效果提升比单纯靠标注数据要快得多。2.3 输入输出的关键约定实操层面text-to-cad目前的输入不能太口语化。你如果说帮我做个好看点的零件模型大概率会给你生成一个奇奇怪怪的抽象雕塑。比较可靠的输入格式是结构化的功能描述我总结了一个模板零件类型底板、支架、外壳、法兰等关键外形尺寸长宽高或直径关键特征孔、槽、螺纹、加强筋特征的位置关系阵列、对称、角落定位可选的参考图多视角或三视图输出侧好的text-to-cad工具会同时给你两样东西一个可视化的预览以及一个可编辑的CAD源文件。底层的命令序列也会以JSON形式暴露出来方便你做二次开发或者自定义后处理。个人经验是输出格式里最值钱的是STEP文件。因为STEP是ISO标准的几何数据交换格式几乎所有的CAD软件——SolidWorks、FreeCAD、Fusion 360——都能直接导入。拿到STEP之后再进去补特征、改尺寸就是普通的CAD操作了完全没有学习成本。3. 实操过程与关键环节实现3.1 环境准备硬件、依赖和模型权重我建议想动手玩text-to-cad的朋友硬件门槛按下面这个表来规划场景推荐配置说明推理测试16GB以上显存的消费级显卡8B模型FP16推理大约需要16GB显存本地微调24GB以上显存建议用LoRA或Q-LoRA降低显存压力生产服务32GB以上或两块卡多并发推理、长序列生成更顺畅软件方面依赖项主要就是PyTorch、HuggingFace Transformers、以及模型仓库里自带的推理代码。有的项目还依赖CadQuery或OpenSCAD来做几何内核校验这个不是必须的但强烈建议装上——后面你会发现让AI生成的结果过一遍真正的CAD内核能筛掉大量空气模型。3.2 快速体验流程从命令行到本地服务如果你只是想在本地跑通一个text-to-cad的推理我建议按下面的步骤来克隆项目仓库用conda创建一个干净的Python 3.10环境。安装依赖核心就是transformers和torch注意版本兼容我遇到过新版transformers接口变更导致推理脚本跑不动的情况所以建议直接用项目里lock住的版本。下载模型权重。很多项目会提供GGUF量化版和原始FP16版如果显卡显存只有16GB优先用量化版。写一个最简推理脚本输入一句文本描述拿到JSON命令序列和可视化的预览图。我自己第一次跑通的瞬间还挺有成就感的输入一个直径50毫米、高30毫米的圆柱体顶部中心有一个直径8毫米的沉头孔几秒钟之后一个规规矩矩的零件就出来了。当然这是简单的但方向对了。3.3 用gradio搭一个本地交互界面命令行工具虽然能用但体验挺原始的。我更推荐用gradio搭一个简单的本地Web界面输入框写描述、上传参考图、点一下生成右侧直接显示三维预览。gradio的代码不复杂核心就是把模型推理函数包成一个接口import gradio as gr def generate_cad(text, image): # 这里调用text-to-cad模型的推理函数 cmd_sequence model.generate(text, image) step_file render_cad(cmd_sequence) # 调用CadQuery/OpenSCAD生成几何 return step_file demo gr.Interface( fngenerate_cad, inputs[gr.Textbox(label描述零件), gr.Image(typepil, label参考图(可选))], outputs[gr.Model3D(labelCAD预览), gr.Textbox(label命令序列)] ) demo.launch()注意输出用了gr.Model3D可以直接显示GLB/STL格式的三维预览体验比看命令行输出强太多。搭好这个界面之后我实测下来给身边非技术背景的同事用他们也能很快上手这就说明工具形态本身很重要。3.4 从命令序列到真实可编辑的文件这里要提醒一个关键点模型直接输出的是命令序列不是CAD文件。要把命令序列变成你可以拿去加工或二次编辑的内容还必须经过一次编译。我用的方案是CadQuery它是一个用Python写CAD模型的库直接把命令序列翻译成CadQuery代码再执行最后导出STEP。这里给一段我常用的转换逻辑示例import cadquery as cq def commands_to_model(commands): result None for cmd in commands: op cmd[op] if op Box: result cq.Workplane(XY).box( cmd[params][x], cmd[params][y], cmd[params][z] ) elif op Cylinder: result cq.Workplane(XY).circle( cmd[params][radius] ).extrude(cmd[params][height]) elif op Subtract and result is not None: result result.cut(cutter) # cutter 由前序操作传入 # 其他操作按类似方式逐条解析 return result model commands_to_model(cmd_sequence) cq.exporters.export(model, output.step)这段代码是示意实际用的时候要处理的操作类型比这多比如放样、扫描、圆角、阵列等但逻辑是一致的逐条解析、逐条执行最后导出。只要有这一步AI生成的东西才能真正进入你的设计工作流。3.5 参数调优温度、top-p和最大token长度很多朋友第一次上手text-to-cad遇到模型胡言乱语第一反应是这模型不行但很多时候其实是采样参数没调对。我整理了三个最关键的参数供参考温度控制生成随机性。CAD生成跟写诗不一样我们要的是确定性。建议温度设在0.1到0.3之间我习惯直接设0.1基本每次都能给出稳定可预期的结果。top-p采样时只从累计概率前90%的token里选。配合低温度使用能避免模型突然跳去生成一堆无意义的旋转矩阵。最大token长度CAD命令序列往往很长尤其零件特征多的时候。如果上限设太小生成中途就被截断然后给你一个只建了一半的模型。8B模型单次上下文建议至少4096复杂零件建议8192。3.6 实战案例从描述到成品的完整记录这里还原一个我前两天做的测试让AI生成一个用于固定步进电机的安装支架外形100x80x8毫米四角有直径5毫米的通孔中心有一个直径22毫米的圆形凸台高度5毫米。整个执行过程很快模型先生成JSON命令序列我检查了一下长度和操作类型一共三段底板Box、凸台Cylinder、四角四个通孔Cylinder加Subtract。随后用CadQuery执行导出STEP后直接拖进FreeCAD特征树完好尺寸可改。整个过程大概不到两分钟而这个零件如果让我手工建模从建草图到约束到阵列保守估计十五分钟。尤其值得肯定的是模型对四角有通孔这个位置描述的解析做得很好没有出现孔落在边界上这种低级错误。4. 常见问题与排查技巧实录4.1 四个高频问题的排查方案问题现象可能原因解决办法生成的模型缺胳膊少腿部分特征丢失命令序列被截断token上限不够调大max_new_tokens或者简化输入描述模型输出的JSON格式坏掉CadQuery直接报错温度太高模型生成不稳定把温度降到0.1开启强制JSON解码模型输出的是分立的多个实体没有做布尔运算训练数据里操作序列不完整在提示词里明确写合并为一个实体或后处理做布尔并集生成的模型看起来对但尺寸差得很离谱单位约定不一致在描述里强制加单位毫米并在输出侧校验数值范围4.2 独门坑位回忆录坐标系与镜像翻转最坑的一次我让模型生成一个左右对称的钣金件输入里写了mirror along X axis结果出来的模型怎么翻都不对。我检查了命令序列才发现模型生成的镜像操作矩阵里有一个符号错了导致整个实体变成了镜像加翻转。这说明一件事模型虽然学了语法但没有真正理解几何变换的物理意义它只是把训练集里的模式复述出来。解决办法是在数据标注或后处理阶段加入几何合法性校验。具体操作是生成完成后用CadQuery计算实体的体积、包围盒跟描述里的目标值做比对超出5%的误差就直接标记生成失败重新采样一次。这种做法虽然粗暴但非常有效能过滤掉大部分看起来对、量起来错的情况。4.3 模型幻觉如何处理合理但不存在的特征还有一个值得说的现象模型偶尔会发明一些你根本没要求过的特征比如在底板上加一圈莫名倒角、或者在一个简单梁结构里多塞了两个装饰性的凸台。这种现象本质上是模型在拟合训练数据的高频模式并不代表它理解你的需求。对这种问题我的策略是从提示词层面压一压明确写只生成描述中要求的特征不要添加额外修饰同时把温度设置为最低减少自由发挥的空间。如果模型还在自由发挥就回到数据层面它在训练集里见过的各种花哨零件太多了对简洁这个概念的锚定不够。可以考虑用约束更强的采样方法或者人工审核命令序列把多余操作删掉再重新执行。5. 工具生态与选型参考5.1 开源项目横向对比现在text-to-cad方向的开源项目正在快速迭代我简单对比一下几类代表性方案的优劣势方便大家选型。方案特点适合场景主要限制端到端文本生成CAD命令序列快速出初始方案、教学演示复杂曲面和自由造型支持有限图片参考文本生成仿制现有零件、基于草图建模参考图视角单一会影响效果大模型平台云端即点即用、多轮对话优化数据隐私、定制化空间小就个人开发和学习而言我建议优先选开源的、支持本地部署的端到端方案一方面数据不出门另一方面你可以直接看到命令序列的生成过程这对理解模型行为和二次开发都更有帮助。5.2 配合传统CAD的混合工作流把text-to-cad看成传统CAD的替代品是对它最大的误解。实际价值最大的用法是混合工作流先用AI生成大量结构候选方案从中筛选有希望的导出到参数化CAD里精修再走仿真或加工流程。我目前的典型流程是AI出五个方案我人工挑一个用FreeCAD打开STEP修改关键尺寸和公差然后出工程图。整个过程里AI完成的是从零到一的草稿阶段我做的是从一到十的工程化阶段。这个分工非常舒服。6. 退一步看边界与未来的想象空间6.1 当前技术的边界在哪里必须坦诚地说text-to-cad解决得好的还是以平面特征为主、带孔带槽带凸台的机械类零件。一旦涉及复杂的自由曲面——比如手机外壳那种双曲面弧度、涡轮叶片这种扭曲扫掠——目前的开源模型表现就一般了经常生成破面、自相交几何或者根本没法导出的垃圾数据。此外多实体装配体级别的生成也还早得很。模型现在能生成的往往是一个零件顶多是共轴组合的状态但那种十几个零件怎么装配在一起的逻辑涉及运动副、配合关系、冗余约束远超当前数据驱动的能力范围。指望写句话直接给你一个能在仿真环境里跑的装配体还不太现实。6.2 后续扩展的可能性往深一步想text-to-cad未来大概率会和拓扑优化、生成式设计做更深的融合——比如你只给约束条件和载荷工况AI直接生成满足力学性能的结构形态。这条路目前虽然只有雏形但方向非常清晰。对普通用户来说现在就是入场学习的最佳时机。因为技术迭代速度极快越早熟悉这类工具的工作方式和边界越能在自己的设计流程里找到合适的嵌入位置。我在实际操作中最大的体会是不要指望AI一步到位给你一个完美模型它最大的价值在此但门槛恰恰也在此——你得有一定的CAD审模能力能判断模型的合理性能修改尺寸和特征而这恰恰是传统工程师本来就该有的基本功。把它当脚手架别把它当设计师本人。
阅读完成 · 觉得有帮助？
