1. 从一句英文指令到三维模型text-to-cad到底在做什么先聊聊最核心的问题text-to-cad是什么。简单说就是输入一段自然语言描述比如“一个M8内六角螺栓头部直径13mm螺杆长度40mm螺纹长度30mm”系统自动生成对应的CAD三维模型文件。这个方向不是某家公司突然拍脑袋想出来的而是CAD领域这几年最实在的自动化趋势之一——把设计师从重复的参数化建模劳动里解放出来让“描述需求”直接变成“拿到模型”。这项技术适合谁三类人最值得关注一是机械工程师尤其是每天要画大量标准件、非标零件的二是产品经理和采购他们经常需要快速拿到一个可用的三维模型做方案验证但自己不会用CAD软件三是做自动化产线集成的工程师类似“皮带轮”“法兰盘”“齿轮箱壳体”这类常见部件如果能用一句话生成基础模型再进软件微调效率是肉眼可见的提升。不过要先泼一盆冷水目前的text-to-cad并不是“无所不能”。它最擅长的是参数化明确的零件、标准件、简单装配体以及可以用几何规则描述的形体。凡是涉及自由曲面造型、复杂装配约束、行业规范要求比如焊接符号、公差标注、表面粗糙度的内容自动生成结果都还达不到交付标准。理解这个边界后面用起来才不会踩坑。我之所以对这块感兴趣是因为去年在公司做过一个内部工具调研目标是把历史图纸库里的标准件参数提取出来让工程师通过一个对话框就能调取模型。当时翻了很多资料最后发现text-to-cad的技术栈并不是单一模型而是一条“语言理解→几何生成→参数化重建”的流水线。这篇文章就把我调研和实测的经验完整拆开讲从选型、原理到落地步骤能帮你省掉不少自己摸索的时间。2. 工具盘点主流的text-to-cad方案有哪些怎么选2.1 四种主流实现路线市面上叫得出名字的text-to-cad方案本质上可以分成四类。搞清楚这四类的区别你就知道为什么有的工具生成的模型是“参数化的”有的却是“一堆三角面片”。第一类是基于程序化生成器加语言映射的方案。典型代表是一些在线标准件库它们的后台维护了几百种常用零件的参数化模板比如ISO 4014六角头螺栓、GB/T 70.1内六角圆柱头螺钉、滑动轴承座等。你输入“M10×50的六角头螺栓性能等级8.8”系统先通过命名实体识别把M10、50这些参数提取出来再匹配到对应模板最后用模板API生成实体模型。这种方案胜在稳定、可编辑、完全符合标准缺点是只能覆盖模板范围内的零件超出范围就抓瞎。第二类是基于深度学习的几何生成方案也就是真正意义上的“从文本生成三维形状”。这类模型通常用大量“文本-三维模型”配对数据训练输入描述后直接输出一个网格模型或隐式符号距离场。优点是覆盖面广能生成一些不常见的异形件缺点是生成的是网格不是参数化实体导入SolidWorks、NX、Inventor这类软件后只能当参考没法直接改尺寸没法出工程图。第三类是混合方案先由深度学习生成一个粗略的几何体然后通过逆向工程技术把网格拟合成参数化特征树。这个思路是最近两年学术界和工业界都在猛攻的方向代表项目有MIT的Text2CAD、AutoDesk内部的一些实验工具。理想状态下你输入“一个带四个安装孔的矩形底座孔距100mm”系统会先输出一个网格再通过识别平面、圆柱面、孔特征重建出带参数历史的实体模型。但实测下来特征识别的准确率在复杂模型上只有六七成还做不到完全自动化。第四类是程序化AI加规则引擎典型代表是堆叠式的设计自动化平台。它们把常用设计规则比如壁厚应大于2mm、注塑拔模角度至少1°编码进规则库AI只负责解读文字和选择参数真正建模是由CAD软件的API驱动。这类方案的商业化程度最高很多PLM厂商都在往这个方向做。选型建议也直接给出来如果做标准件库选第一类如果做方案草图快速验证选第二类如果要做可编辑的工程模型现阶段还是得靠第一类加人工修复混合方案可以作为研究关注对象但别在生产环境里贸然用。2.2 五款具体工具的实测对比我实际测过几款主流工具整理了下面这个对比表。注意这里对比的是截至2024年底的公开版本情况工具迭代很快参数仅供参考。工具名称实现路线输入方式输出格式可编辑性适用场景Text2CAD (MIT开源实验)深度学习生成英文自然语言OBJ/STL网格不可直接编辑学术研究、概念参考CAD-GPT (社区项目)混合生成英文自然语言网格特征树尝试部分可编辑简单轴类、板类零件autodesk fusion 内置生成器程序化模板中文/英文原生参数化模型完全可编辑标准件、常用结构件SolidWorks 宏录制 LLM脚本规则引擎英文/中文原生参数化模型完全可编辑自定义重复建模国内某标准件库AI助手程序化模板中文STEP/原生格式完全可编辑国标/ISO标准件autodesk fusion内置的那个生成器其实更准确地说是“从文字生成配置”而非“从文字生成任意模型”。它的实现方式是把参数化特征操作拉伸、旋转、阵列和文字模板绑定对常见机械零件支持很好但对自由曲面无能为力。社区项目CAD-GPT的思路更有意思它直接调用FreeCAD的Python API让大语言模型自己写建模脚本脚本执行的结果就是模型。这种方式的本质是“AI写代码”所以对模型的最终控制力很强只要大模型生成的代码没有语法错误模型就是参数化的。实测下来最稳定的反而是看起来最“笨”的第一类工具。原因在于程序化模板是预定义的参数提取逻辑经过反复校验不会出现大模型那种“一本正经地胡说八道”的情况。所以如果你要的是稳定交付别迷信AI老老实实走模板匹配加参数提取准确率可以做到95%以上。3. 核心原理从文字到CAD模型中间发生了什么3.1 语言理解阶段——把自然语言变成结构化参数text-to-cad的第一道工序是把人的语言变成机器能处理的结构化数据。听起来简单实际坑非常多。比如“一个M8x30的内六角螺钉”这里M8是公称直径30是螺杆长度。但如果是“一个直径8、长30的螺钉”没有M前缀模型就要靠上下文判断这是公制螺纹。再比如“带法兰的轴”到底是“有轴肩的法兰轴”还是“轴端带一个法兰盘”自然语言里的省略和歧义是最大的阻力。工业界稳妥的做法是建立字典和模板联合提取。先做词法分析把句子切分成名词短语、数量短语、材料短语再用领域词典匹配比如“螺栓”“螺钉”“螺母”“垫圈”“法兰”“轴承座”这些词直接映射为零件类型最后用正则和规则抽取数字与单位填入参数槽位。这套传统NLP方案虽然不太“智能”但胜在可控出错能追查。最近也有不少工具开始用大模型做这一步但一定要约束输出为JSON格式并且做枚举校验否则“M8”可能会被解析成“M8”以外的奇怪内容。下面是一个典型的参数提取结果示例。输入“一个M8×30的内六角圆柱头螺钉材料304不锈钢需要全螺纹”系统输出{ part_type: socket_head_cap_screw, standard: GB/T 70.1, diameter: 8, length: 30, thread_type: full_thread, material: 304_stainless_steel, unit: mm }注意这里“内六角圆柱头螺钉”已经自动映射到GB/T 70.1标准这个映射关系是事先在标准件知识库里定义好的。这一步之所以关键是因为后面的参数化模板必须知道“用哪个标准、哪个系列”才能决定头径、头高、内六角对边等参数是查表还是按公式计算。3.2 几何生成阶段——从参数到三维实体的两条路线结构化参数生成后就进入几何生成阶段。这里分两条路线对应前文说的程序化模板和深度学习生成。程序化模板路线几何过程就是执行CAD内核里的建模命令。拿GB/T 70.1内六角圆柱头螺钉来说建模步骤是这样的先拉伸出头部圆柱体直径d_k按标准查表M8对应13mm高度k为8mm再拉伸出螺杆圆柱体直径d为8mm长度l为30mm然后做螺纹特征如果是全螺纹直接用螺纹扫描命令螺距P由标准表给定M8粗牙螺距1.25mm最后用六角形草图拉伸扣除头部内六角孔对边距离s为6mm深度t为4mm。每一步都有对应的API调用相当于预先写好了建模脚本只等参数填入。深度学习生成路线则完全不同。它把文本编码成一个语义向量然后用条件生成模型去预测三维形状的占用场。简单说就是用一个神经网络来判断三维空间里每个点体素是否属于实体。生成的结果通常是导出为STL网格因为网格是最通用的表示格式。但网格模型没有特征树没有参数历史导入CAD软件后只能做布尔运算或者参考不能像原生特征那样改草图尺寸。这就是为什么深度学习方案目前无法取代程序化模板的根本原因——CAD工程师要的是特征和参数不是一堆三角形。3.3 参数化重建阶段——把网格变成可编辑特征为了让深度学习生成的模型“可用”学术圈和工业界在尝试第三阶段参数化重建。核心思路是先从网格模型里识别平面、圆柱面、球面、圆角面等基本几何特征再把这些特征参数化——比如识别出一个圆柱面提取它的轴线方向、半径、高度识别出一个孔特征提取它的位置、直径、深度。然后根据特征间的拓扑关系重构一个参数化建模脚本。这个技术和逆向工程类似但难点在于自动化地识别“设计意图”。比如说一块板上有一个沉头孔网格模型里它可能被表示成几个同心圆柱面的组合。系统需要判断这几个面其实是同一个特征才能重建出“孔特征”而不是三个独立的圆柱凸台。目前的实现基于特征识别算法加机器学习分类识别简单零件无圆角、无复杂曲面的准确率还不错一到复杂件就掉链子。所以现阶段实用的做法是用深度学习做初步形状再用程序化模板的“半成品”来替换其中标准的部分最后人工修正。4. 实操落地从零搭建一个最小可用的text-to-cad系统4.1 系统架构选型与依赖准备我建议从最实用的“模板匹配加参数提取”路线开始做一个能真正跑起来的系统。这套系统只需要三样东西一个支持Python API的CAD软件我用的是FreeCAD开源免费、一个大语言模型API可选用于解析自然语言、一个标准件参数库可以用Excel或JSON维护。整体架构是接收自然语言指令→LLM解析为JSON→查模板库→生成参数化脚本→执行脚本输出模型。FreeCAD选择的原因很直接它提供完整的Python API可以在无界面模式下运行非常适合做服务化封装。你需要安装FreeCAD 0.21及以上版本并确认Python环境能导入FreeCAD模块。注意Windows和Linux下的导入路径不一致我用的是Linux的AppImage版本需要在代码里手动加入FreeCAD的lib路径。接下来准备一个零件模板目录每个模板是一个Python文件里面有一个generate(params)函数负责建模主体逻辑。4.2 模板库的编写规范模板库是整个系统的心脏。每一个模板对应一种零件类型比如内六角螺钉、六角螺母、垫圈、法兰盘。模板函数的输入是经过校验的参数dict输出是FreeCAD的Part对象。我这里给出一个极简框架让你理解结构。# templates/screw.py import FreeCAD as App import Part def generate(params): doc App.newDocument(Screw) diameter params[diameter] length params[length] head_diameter params.get(head_diameter, diameter * 1.6) head_height params.get(head_height, diameter * 0.7) # 建螺杆 shank Part.makeCylinder(diameter / 2, length, App.Vector(0, 0, 0)) # 建头部 head Part.makeCylinder(head_diameter / 2, head_height, App.Vector(0, 0, length)) # 合并 screw shank.fuse(head) # 螺纹可以省略或通过Part.ThreadBuilder实现 obj doc.addObject(Part::Feature, Screw) obj.Shape screw doc.recompute() return obj.Shape这个例子省去了螺纹和六角孔但已经足够说明问题。真实模板里最麻烦的是螺纹建模建议不要直接用FreeCAD的螺纹显示功能而是用“实际轮廓扫描”或者干脆做简化处理——用圆柱面加视觉螺纹线除非你要做3D打印否则大多数仿真场景不需要真实螺牙。这个取舍做过实际项目的人都懂。4.3 大模型接口的接入与提示词设计LLM在这套系统里负责“把话变成JSON”。这里提示词设计非常关键。经验是不要给模型太多自由一定要限定输出格式和枚举值。我用的提示词模板如下你是机械零件参数提取助手。根据用户输入输出JSON包含字段part_type取值范围screw/nut/washer/flange/bearing_housing/custom、diameter数字单位mm、length数字、material字符串。如果输入中没有对应字段用null代替。不要输出任何额外文字只输出JSON。 用户输入一个内六角螺栓直径8毫米长度30毫米 输出这样设计之后大模型基本不会跑偏。但依然要加一层防御性校验解析JSON之后检查part_type是否在枚举范围内diameter和length是否是正数超出合理阈值比如diameter大于500mm要报警。我不会把大模型的输出直接传给建模函数因为模型一旦犯错生成错误的模型比报错更麻烦。4.4 参数库与标准件查表逻辑如果没有标准件参数库模板就只能处理“任意圆柱体”这种简单形状无法处理真正的国标零件。参数库建立方法很简单从GB/T、ISO标准里找一张公称尺寸与各部位尺寸的对照表录入JSON文件。举个例子M6、M8、M10内六角螺钉头部参数保存如下{ M6: {head_diameter: 10.0, head_height: 6.0, hex_width: 5.0, hex_depth: 4.0, pitch: 1.0}, M8: {head_diameter: 13.0, head_height: 8.0, hex_width: 6.0, hex_depth: 4.0, pitch: 1.25}, M10: {head_diameter: 16.0, head_height: 10.0, hex_width: 8.0, hex_depth: 5.0, pitch: 1.5} }实际使用时先根据公称直径查这个表取出对应的头部参数再覆盖用户指定的参数比如用户指定了头部直径就按指定值算。这步查表逻辑一定要写在模板之外作为公共服务因为不只螺钉用得到螺栓、双头螺柱也共享这些基础尺寸数据。4.5 端到端的调用流程示例把以上模块串起来一个最小调用流程如下import json import sys def text_to_cad(user_text): # 步骤1: LLM解析 llm_json call_llm(user_text) # 假设已实现 params json.loads(llm_json) # 步骤2: 校验与标准件参数补全 validate_params(params) # 枚举、范围校验 fill_standard_params(params) # 查表补全 # 步骤3: 动态导入模板并建模 module importlib.import_module(ftemplates.{params[part_type]}) shape module.generate(params) # 步骤4: 保存为STEP和Stl Part.export([shape], output_step_path) mesh Mesh.meshFromShape(shape, 0.1) Mesh.export([mesh], output_stl_path) return output_step_path, output_stl_path这个系统已经可以在公司内部跑一个非常实用的场景给采购部门发一个链接填写“型号尺寸”后端自动生成STEP文件采购直接拿这个STEP文件找供应商询价。没有依赖任何商业CAD许可证成本极低。5. 实测案例三种典型输入的结果与问题5.1 案例一标准件——内六角螺钉输入“M8×30内六角螺钉304材质全螺纹”。LLM解析结果准确正确识别part_type为screwdiameter为8length为30。模板生成结果与标准GB/T 70.1完全一致头部参数通过查表得到螺纹采用简化圆柱面。实测输出STEP文件导入SolidWorks尺寸测量正确实体完整性好。这个案例的成功率接近100%是系统的看家功能。需要注意一个细节全螺纹和半螺纹的处理。全螺纹时螺杆全长都有螺牙需要把螺纹起始点设在头部底面半螺纹时螺纹长度由参数指定。这个逻辑如果漏了生成的产品会和标准不一致采购拿去询价会被供应商质疑。5.2 案例二半标准件——带法兰的轴输入“带法兰的轴法兰直径60轴径25轴长80法兰厚度10”。这个零件不是标准件LLM解析时part_type返回了customdiameter提取为25length为80同时多出两个参数flange_diameter和flange_thickness。模板库中我提供了一个“法兰轴”的通用模板支持这些参数。生成过程是用两个圆柱体布尔合并法兰与轴的连接处没有做圆角。结果导入CAD后基本可用但圆角需要手工添加。这个问题很典型自然语言描述常常隐含工艺要求倒角、圆角、退刀槽但模型不会主动识别。我的经验是在提示词里要求LLM“如果用户没有提到圆角则不要主动添加圆角”否则模型会猜测一堆不存在的圆角反而坏事。对于需要圆角的场景更稳妥的做法是模板本身提供可选圆角参数默认关闭。5.3 案例三复杂描述——壳体类零件输入“一个矩形壳体长100宽80高50壁厚3底部四个安装孔直径5孔距20”。这类零件是深度学习方案的强项但程序化模板最难搞。我的模板库没有现成壳体模板于是临时写了一个“盒子”模板先画一个实体长方体然后抽壳再通过阵列生成四个孔。结果生成成功但壁厚3mm导致壳体内腔尺寸是94×74×44而用户没有明确说的是内腔尺寸还是外腔尺寸。模型默认按外廓加抽壳处理如果用户想要的是“内腔长100”结果就错了。这个案例暴露出语言歧义是text-to-cad目前最大的坑。同样一句话机械工程师理解成外廓做CNC加工的理解成内腔做钣金的可能理解成展开尺寸。应对方法是在系统里增加交互确认环节当参数存在歧义时自动生成一个确认问题返回给用户而不是闷头生成。这个环节成本不高却能把准确率抬上一个台阶。6. 避坑指南text-to-cad落地中的主要障碍6.1 别迷信拖拖拽拽的“全自动”要设计人机协同流程我把text-to-cad落地时踩过的坑总结成几条每一条都是用时间和返工换来的。第一坑是“期望管理”。很多领导看到demo觉得文字就能生成模型以后建模工程师可以砍掉一半。实际上一套生产级的text-to-cad系统生成的模型顶多算“初稿”。后续还需要人工检查关键尺寸、添加公差符号、确认材料、调整表面粗糙度。公司内部推广时一定要把流程定义为“AI出初稿工程师做审核修正”而不是“AI替代工程师”。否则预期过高落地必然受挫。第二坑是“标准库维护”。标准件尺寸表不是一成不变的新标准发布后旧表要用新数据替换。我见过有人把ISO标准抄错一个零结果M8螺钉头部直径变成了130mm下游供应商一脸懵。所以在查表逻辑里必须写清楚数据来源和版本号并建议每季度校验一次。第三坑是“螺纹到底要不要画”。很多初学者花大量时间研究螺纹精确建模其实在生产流程里螺纹有专门的表示方法——工程图上用简化画法有限元分析里用等效螺纹或螺栓连接只有3D打印或CNC加工时才需要真实螺纹轮廓。text-to-cad系统默认输出简化螺纹是正确的不要试图追求视觉上的“精致”否则建模时间暴增还没什么实际收益。第四坑是“模型精度与单位”。FreeCAD的默认单位是毫米但如果你接入了英制文本比如“1/4 inch bolt”系统必须统一换算成公制再进入模板。做过一次忽略单位换算导致生成的螺栓实体大了25.4倍直接废掉一批测试件。单位处理一定要放在参数校验的第一位。6.2 深度学习方案还要不要关注老实说深度学习生成任意CAD模型的精度和可靠性在短期内很难达到工业交付标准。但它在两个方向有潜力一是作为“灵感生成器”输入“一个流线型外壳”得到一个可以借鉴形态的网格再让工程师在CAD里重新建模二是用于“缺失模型补全”比如历史图纸里只有二维视图可以用深度学习推测三维形状作为初始解。所以建议保持关注但别赌它立刻能上产线。7. 常见问题速查表现象可能原因排查方法解决方案生成的模型尺寸不对单位换算缺失检查输入文本是否有“inch”等英制单位在参数校验层统一乘25.4换算为mm零件类型识别错误LLM解析出错查看LLM输出JSON的part_type字段提示词限定枚举值添加模型输出的枚举校验模型正确但导入SolidWorks后显示破面STEP导出容差问题打开STEP文件检查拓扑在FreeCAD中设置shape tolerance为1e-6后再导出生成的壳体壁厚方向反了抽壳方向参数错误查看模板代码中的Shell方向明确指定偏移方向为内向或外向螺纹显示不出来没有创建真实螺纹特征查看模型树是否存在螺纹特征若使用简化圆柱则忽略此问题LLM返回非JSON内容提示词设定不严格或模型版本异常检查原始返回文本增加重试机制最多重试3次使用响应格式强制模式查表返回null零件直径不在覆盖范围检查JSON参数库是否存在该尺寸段增加默认值或提示用户输入非标尺寸生成的STEP文件体积巨大网格密度过高查看网格导出参数在网格化时设置线性偏差为0.1mm这些问题里出现频率最高的是“LLM输出非JSON”和“单位换算缺失”线上服务一定要在这两处加硬校验。比如单位换算我建议直接在参数校验函数里做def normalize_length(value, unit): if unit in (inch, in, ): return value * 25.4 elif unit in (mm, millimeter): return value else: raise ValueError(fUnsupported unit: {unit})这看似简单却能让系统少报废一半以上的模型。8. 扩展思路从“零件生成”到“装配体生成”的下一步text-to-cad目前主要在单零件层面应用但未来的价值在于装配体。想一想如果输入“一个带四个轮子的底盘每个轮子由螺栓固定”系统能自动生成底盘、轮子、螺栓的零件模型并组装成装配体还生成配合关系那工程师的重复劳动会进一步大幅减少。这依赖于装配体拓扑库和配合规则库的建设——也就是说系统不仅要懂零件特征还要懂“什么零件和什么零件通过什么方式配合”。我目前的方向是给每个装配模板定义一个接口清单比如“底座”模板有四个安装面每个安装面预留螺栓孔“轮子”模板有一个中心孔“螺栓”模板有标准型号。然后通过匹配接口名自动生成配合关系。这个思路还在探索中但至少比单纯生成零件更接近实际工程需求。另外还有一个非常实用的扩展结合二维图纸识别。很多工厂还有大量旧图纸只有PDF或者打印件没有三维模型。与其直接做text-to-cad不如先做“PDF图纸→参数提取→三维模型生成”这等于把识别的输入从自然语言换成了图纸后台的逻辑可以完全复用现有的模板库。这个方向我尝试过准确率比纯文本高不少因为图纸上的尺寸标注是结构化明确的。最后再分享一个小心得做这类项目与其追求“最先进”不如追求“最实用”。先把标准件的text-to-cad做好让采购、工艺部门真正用起来再逐步扩展非标件和装配体。我在实际跑这个系统的过程中最大的感受是技术本身不难难的是让人接受“自动生成的东西需要审核”这个流程。只要你把这个流程设计顺了工具的价值很快就能体现出来。