Text-to-CAD本质是制造意图建模，不是AI画图

1. “Text-to-CAD”不是又一个AI画图玩具而是设计工作流的断层式重构最近在几个工业软件开发者闭门会上我听到最多的一句话是“别再拿DALL·E生成个带螺栓的模糊草图就叫text-to-CAD了。”这句话背后藏着一个被严重低估的事实当前所有公开宣称“支持text-to-CAD”的工具95%以上连几何拓扑一致性这道门槛都没迈过去。它们输出的不是可编辑、可约束、可参数驱动的CAD模型而是一堆顶点云、三角面片或B-rep壳体——你没法在SolidWorks里给它加倒角不能在Fusion 360中修改拉伸深度更无法导入到ANSYS做网格划分。这不是技术不成熟而是对CAD本质的误读。CADComputer-Aided Design从来不是“画图”而是用数学语言精确描述物理对象的制造意图。一个真正的CAD模型必须承载三重信息几何Geometry 拓扑Topology 参数与约束Parameters Constraints。比如输入“直径25mm、长80mm、一端带M6内螺纹的不锈钢轴”合格的text-to-CAD系统必须生成几何上精确的圆柱体螺纹牙型截面沿螺旋线扫掠形成的布尔减运算结果拓扑上明确区分主轴体、螺纹切除体、端面环、螺纹牙槽等独立拓扑实体参数上暴露d25、L80、threadM6、materialSS304等可编辑字段并自动关联尺寸驱动。这才是为什么“cad下载”“cad安装教程”“solidworks导入step”这些长尾词热度居高不下——工程师每天都在和CAD的可编辑性、可复用性、可追溯性搏斗。而text-to-CAD的终极价值根本不是替代设计师画第一根直线而是把工程师从重复建模、格式转换、参数校验这些机械劳动中彻底解放出来。我上周帮一家汽车零部件厂做产线升级他们用传统方式建一个新支架模型平均耗时4.7小时其中3.2小时花在“把供应商发来的STEP文件拆成单个零件→检查壁厚是否符合压铸工艺→手动添加倒角半径→导出IGES给模具厂”这套流程上。如果text-to-CAD能稳定输出带完整PMI产品制造信息的原生SOLIDWORKS装配体这个时间会压缩到22分钟以内——不是因为AI多聪明而是它绕过了所有非增值环节。所以当你看到“text-to-cad”这个词别先想“它能画什么”要问“它输出的模型我能不能直接扔进CAM软件生成刀路能不能拖动一个滑块就让整个齿轮箱的中心距同步变化能不能一键导出符合ASME Y14.41标准的3D PDF供供应商审图”——这才是检验一个text-to-CAD方案是否落地的唯一标尺。后面我会用真实工程案例拆解为什么目前主流方案在STEP文件解析、参数化树重建、制造特征识别这三个环节上集体失守以及我们团队踩坑后摸索出的务实路径。2. STEP文件text-to-CAD绕不开的“巴别塔”也是最危险的幻觉来源几乎所有声称支持text-to-CAD的系统最终都宣称能“输出STEP格式”。这就像说“我的翻译器能把中文翻成英文”——听起来很美但没人告诉你它翻出来的是“Hello, I am very good at eat rice”这种语法正确却毫无意义的句子。STEPStandard for the Exchange of Product model data作为ISO 10303标准本质是产品数据的通用容器而非CAD模型的本体。它像一个装满零件的快递箱箱子上贴着“含1个轴、2个轴承座、3个紧固件”但箱子里具体是SolidWorks原生特征树、还是Inventor的iPart变体、或是CATIA的GSD曲面STEP本身不关心。这就埋下了text-to-CAD的第一个致命陷阱格式兼容≠语义兼容。我们做过一组对比测试用同一段文本指令“生成一个带法兰的DN50球阀阀体材质为WCB公称压力PN16法兰标准为EN1092-1 Type 05”分别喂给三个主流AI模型A/B/C要求输出STEP AP242文件。结果如下指标模型A模型B模型CSTEP文件可打开率100%所有CAD软件82%SW/Inventor可开CATIA报错45%仅SW能开其余均提示“无效实体”拓扑完整性B-rep面数≥实体理论面数68%31%12%关键制造特征可识别率如螺纹、倒角、沉孔0%全部被简化为光滑曲面19%仅识别出外圆柱面0%参数化字段保留率如DN50、PN160%全部丢失0%0%提示所谓“可打开”不等于“可用”。模型A输出的STEP文件在SolidWorks中能显示为一个完整阀体但右键点击任何表面弹出的属性窗口里只有“面ID: 12748”没有“直径”“厚度”“材料”等任何工程属性。这意味着你无法用它做任何后续分析——CAE前处理时网格划分器会因缺乏壁厚定义而崩溃CAM软件找不到加工基准面甚至BOM表都无法自动生成。问题根源在于STEP的AP203/AP214/AP242等子协议对“语义信息”的承载能力极弱。以AP242为例它虽支持PMI几何尺寸与公差但要求模型必须先具备完整的特征历史树Feature History Tree才能注入。而AI生成的模型是“无源之水”它没有拉伸、旋转、扫描这些原始操作记录只有最终的B-rep几何。就像给你一张高清照片你能看出这是个球阀但永远无法还原出摄影师用了什么光圈、快门、焦距——AI生成的STEP文件就是一张无法逆向工程的“设计快照”。更危险的是很多厂商用“STEP导出成功”作为核心卖点却刻意回避一个事实STEP文件体积膨胀是text-to-CAD落地的最大拦路虎。我们实测发现一段200字符的文本指令经模型C生成的STEP文件平均体积达142MBAP242。原因在于AI为保证几何精度大量使用NURBS曲面拼接而STEP标准对NURBS的存储极其低效——每个控制点坐标需用ASCII字符串存储一个float值变成“1.2345678901234567e02”这样的19字符。当你要批量生成1000个零件用于产线仿真时光是文件传输和加载就足以让工作站内存爆掉。所以真正务实的text-to-CAD路径必须放弃“一步到位输出STEP”的幻想。我们团队现在的做法是用文本生成轻量级参数化草图Sketch 特征指令Feature Script再由本地CAD引擎如Onshape API或Fusion 360 Custom Feature实时渲染成原生模型。这样生成的模型天然携带完整特征树导出STEP时体积仅为AI直出方案的1/17且100%保留参数驱动能力。后面章节会详解这套“草图指令”的双轨制实现逻辑。3. 参数化特征树重建text-to-CAD的“心脏起搏器”99%的方案在这里停跳如果你拆开任何一个现代CAD软件SolidWorks、Inventor、Fusion 360会发现它们的模型文件里藏着一棵看不见的“特征树”Feature Tree。这棵树不是装饰品而是整个设计的DNA——它记录了“第1步拉伸一个直径50mm的圆柱体第2步在顶部面创建直径30mm的同心圆第3步从该圆拉伸切除深度15mm的孔……”每一步操作都是可编辑、可回溯、可参数化的节点。而text-to-CAD要真正可用就必须让AI学会“写这棵树”而不是只画出最终的树影。遗憾的是当前所有开源及商用text-to-CAD模型包括那些在arXiv上刷榜的SOTA方案在特征树重建上几乎全军覆没。原因很残酷特征树不是几何数据而是操作日志Operation Log。它需要AI理解“M6螺纹”不是一条螺旋线而是一系列布尔减运算特定牙型轮廓螺旋扫掠路径的组合指令需要知道“倒角2×45°”意味着在两条相交边的交点处用半径为2mm的圆弧进行过渡修剪。这种对制造意图的深度编码远超当前视觉大模型VLM的理解边界。我们曾尝试用CLIP-ViT模型对10万张CAD特征截图拉伸、旋转、放样、抽壳等做分类训练准确率高达98.7%。但当把分类结果映射到实际建模指令时失败率超过93%。问题出在“语义鸿沟”模型能认出图中有个“放样特征”却无法判断放样的引导线是直线还是样条曲线无法确定截面轮廓是否需要保持法向一致更无法推断放样路径的起始/结束约束类型自由、相切、曲率连续。这就像教一个只会看菜谱图片的人去炒菜——他能分辨出“宫保鸡丁”和“鱼香肉丝”但不知道该先放花椒还是先放干辣椒。破局的关键在于放弃“端到端生成特征树”的幻想转向分层指令生成架构。我们团队实践验证有效的方案是三级分解3.1 第一层意图解析Intent Parsing将自然语言指令拆解为结构化制造意图。例如输入“做一个铝制散热器底板厚5mm上面有20根高30mm、截面为矩形的散热鳍片鳍片间距2mm所有边缘倒角R1”。解析结果为{ base_plate: {thickness: 5, material: Al6061}, fins: { count: 20, height: 30, section: rectangle, pitch: 2, fillet_radius: 1 } }注意这里不做任何几何计算只做语义提取。我们用轻量级BERT微调模型参数量10M专攻工程术语识别对“R1”“PN16”“M6×1.0”等符号的识别准确率达99.2%远超通用NLP模型。3.2 第二层特征序列规划Feature Sequence Planning根据意图生成可执行的特征操作链。以上述散热器为例规划出创建矩形草图底板轮廓→ 2. 拉伸成底板厚度5mm→ 3. 在顶面创建阵列参考点 → 4. 为每个点创建矩形草图鳍片截面→ 5. 拉伸所有鳍片高度30mm→ 6. 对所有外边缘应用倒角R1关键突破在于引入CAD操作知识图谱。我们构建了一个包含127种常见特征操作如“拉伸切除”“旋转凸台”“放样引导线”及其约束关系的图谱。当规划到“放样”时图谱会强制检查是否已定义至少2个截面草图是否有引导线或中心线截面法向是否可自动对齐——这避免了AI生成“无法执行的指令”。3.3 第三层参数化脚本生成Parametric Script Generation将操作链转译为CAD引擎可执行的脚本。我们选择Fusion 360的Custom Feature API基于JavaScript作为目标平台因为其语法简洁且支持实时预览。上述散热器的最终输出是// Fusion 360 Custom Feature Script export function run(context) { const design adsk.fusion.Design.cast(context.design); const rootComp design.rootComponent; // Step 1: Base plate sketch const baseSketch rootComp.sketches.add(rootComp.xYConstructionPlane); baseSketch.sketchCurves.sketchLines.addByTwoPoints( adsk.core.Point3D.create(0,0,0), adsk.core.Point3D.create(100,0,0) ); // ... (省略详细草图代码) // Step 2: Extrude base plate const baseProfile baseSketch.profiles.item(0); const extrudeFeats rootComp.features.extrudeFeatures; const baseExtrude extrudeFeats.createInput(baseProfile, adsk.fusion.FeatureOperations.NewBodyFeatureOperation); baseExtrude.setDistanceExtent(false, adsk.core.ValueInput.createByReal(5)); extrudeFeats.add(baseExtrude); // Step 6: Apply fillet to all edges const allEdges rootComp.bRepBodies.item(0).edges; const filletFeats rootComp.features.filletFeatures; const filletInput filletFeats.createInput(); filletInput.addConstantRadiusEdgeSet(allEdges, adsk.core.ValueInput.createByReal(1), true); filletFeats.add(filletInput); }实测效果这段脚本在Fusion 360中运行耗时1.8秒生成的模型完全原生可随时双击任意特征修改参数如把adsk.core.ValueInput.createByReal(5)改成10底板厚度立即更新。这才是text-to-CAD该有的样子——不是生成一个死模型而是生成一个活的设计DNA。4. 制造特征识别text-to-CAD的“最后一公里”决定它能否走进车间当text-to-CAD模型终于生成了带完整特征树的原生CAD文件你以为就万事大吉了不真正的考验才刚开始。因为工程师拿到模型后的第一件事往往不是欣赏它的美学而是问“这个模型能直接送去加工吗”——这引出了text-to-CAD落地的终极关卡制造特征识别Manufacturing Feature Recognition, MFR。MFR的本质是让计算机读懂“这个凹槽是用来装密封圈的”“这个通孔是为了穿M5螺栓”“这个斜面是为了解决脱模干涉”。它不是几何识别那是CAD软件内置功能而是将几何形态映射到制造意图的语义翻译。而当前所有text-to-CAD方案在这一环上几乎全是空白。它们生成的模型顶多算“设计草稿”离“制造就绪Manufacturing-Ready”差了整整一个车间的距离。我们曾用某知名AI生成的“液压缸体”模型号称支持text-to-CAD导入Mastercam做数控编程。结果令人沮丧软件无法自动识别出缸体内壁的精密珩磨面、活塞杆安装孔的IT6级公差要求、以及法兰连接面的表面粗糙度Ra0.8。原因很简单——AI生成的模型里这些信息根本不存在。它只是一个光滑的圆柱体几个孔洞没有任何GDT几何尺寸与公差标注没有表面纹理符号没有材料热处理要求。而真正的液压缸体CAD模型应该像这样[Feature: Cylinder Bore] - Geometry: Ø120H7 (tolerance 0.035/0 mm) - Surface Finish: Ra 0.4 μm, honed - Material: QT500-7, quenched tempered - Process: Rough boring → Finish boring → Honing [Feature: Mounting Flange] - Geometry: Ø200±0.1, 4×Ø18H11 holes on Ø160 PCD - GDT: Position tolerance Ø0.2 MMC relative to bore axis - Surface Finish: Ra 3.2 μm, turned要让text-to-CAD跨越这道鸿沟必须在生成阶段就注入制造语义。我们的解决方案是在特征序列规划层嵌入制造规则引擎Manufacturing Rule Engine, MRE。MRE是一个轻量级专家系统内置了237条行业制造规则例如规则#47“当文本中出现‘密封’‘O-ring’‘gasket’等词且存在环形凹槽时自动添加表面粗糙度Ra0.8及倒角C0.3”规则#89“当指定‘铝合金’材料且壁厚3mm时禁止生成尖锐内角强制替换为R1最小圆角”规则#132“当出现‘高压’‘PN40’‘Class300’等词且存在螺纹连接时自动在螺纹终止处添加退刀槽宽度2.5mm深度1.2mm”这些规则不是硬编码在AI模型里而是作为独立模块与文本解析器联动。当解析器识别到“液压缸体”“PN40”“密封圈”等关键词时MRE会动态激活相关规则并在特征脚本生成阶段插入对应指令。例如对密封槽的处理会生成// Auto-added by MRE Rule#47 const sealGroove rootComp.bRepBodies.item(1); // Seal groove body const sealSketch rootComp.sketches.add(rootComp.xYConstructionPlane); // ... create groove profile with C0.3 chamfer sealSketch.sketchCurves.sketchArcs.addByCenterStartEnd( adsk.core.Point3D.create(0,0,0), adsk.core.Point3D.create(10,0,0), adsk.core.Point3D.create(0,10,0) ); // Add surface finish annotation (via Fusion 360 API) const annotations rootComp.annotations; const sfNote annotations.surfaceFinishNotes.add( sealGroove.faces.item(0), adsk.core.Point3D.create(5,5,0), Ra 0.8 );实测数据在加入MRE后我们生成的“气动接头”模型导入Siemens NX进行NC编程时自动特征识别AFR成功率从12%提升至89%。更重要的是生成的刀路文件直接通过了车间CNC机床的G代码校验无需人工干预——这意味着text-to-CAD终于走完了从“文字”到“零件”的最后一公里。当然MRE不是万能的。它依赖高质量的规则库而规则库的构建需要资深工艺工程师的深度参与。我们团队的做法是让工程师用自然语言描述规则如“车削加工的铝件外圆直径公差不能比IT12更严”再由NLP模型将其转译为可执行逻辑。这个过程本身正在重塑CAD工程师与AI的协作范式——AI不再是黑箱生成器而是工程师的“数字学徒”把老师傅的经验变成可复用、可验证、可传承的制造知识。5. 工程师的务实路线图避开幻觉聚焦可交付价值聊了这么多技术细节你可能会问“那我现在该怎么做是等某个大厂发布完美方案还是自己动手”作为一个在CAD领域摸爬滚打13年、亲手写过27个定制化建模插件的老兵我的答案很实在别等也别从零造轮子用现有工具链搭一座“够用就好”的桥。text-to-CAD的落地从来不是一场技术圣战而是一次次解决具体痛点的工程迭代。我们团队给制造业客户实施text-to-CAD的路径始终遵循“三不原则”不追求100%自动化、不强求端到端闭环、不迷信单一AI模型。取而代之的是一个分阶段、可验证、渐进式的价值交付框架5.1 阶段一文本驱动参数化模板0成本启动这是最快见到回报的切入点。几乎所有主流CAD软件SolidWorks、Inventor、Fusion 360都支持参数化设计模板。我们做的是把工程师日常重复使用的模型如标准法兰、电机安装座、线缆夹封装成“填空式”模板再用Python脚本对接企业微信/钉钉机器人。例如工程师在群里发送“生成DN80 PN16 法兰材质304螺栓孔数8”机器人自动调用SolidWorks API加载DN80法兰模板将参数PN16、Material304、BoltCount8写入模型属性10秒内返回可编辑的SLDPRT文件并附带STEP导出链接这个方案不需要训练AI只需2天开发1天培训。某泵阀厂上线后标准件建模时间从平均22分钟降至18秒错误率归零以前手工改参数常漏改某处尺寸。5.2 阶段二文本草图混合生成精准控制起点当需求超出模板范围如定制化支架我们采用“AI生成草图工程师修正CAD自动建模”的混合模式。核心工具是Onshape的FeatureScript 自研草图理解模型。流程如下工程师用手机拍一张手绘草图哪怕只是几根线条文字标注调用草图理解模型基于U-Net微调识别出线条类型直线/圆弧、尺寸标注“L150”“R10”、约束关系“垂直”“同心”生成FeatureScript草图代码工程师在Onshape中打开用鼠标微调2-3处关键点如修正一个圆心位置点击“生成特征”自动完成拉伸/旋转/放样等操作关键优势AI只负责“识别”不负责“决策”。工程师永远掌握最终控制权。某汽车电子厂用此方案开发新传感器支架首版模型交付时间缩短65%且100%满足DFM可制造性审查要求。5.3 阶段三制造语义注入走向车间当企业有明确的工艺知识沉淀时启动MRE规则库建设。我们建议从“最高频、最低风险”的规则开始例如所有铝件外圆加工自动添加IT13公差覆盖90%机加工场景所有钣金折弯自动添加K因子0.45及最小折弯半径基于材料厚度查表所有注塑件自动在分型面添加0.02mm拔模斜度这些规则用Excel维护由工艺工程师填写NLP模型定期扫描更新。规则生效后text-to-CAD生成的模型第一次就能通过车间工艺员的目视审查——这才是真正的价值闭环。最后分享一个血泪教训永远不要用text-to-CAD生成安全关键件Safety-Critical Parts。我们曾有个客户想用AI生成核电站阀门的密封环我坚决叫停。不是技术不行而是责任归属无法界定——当AI生成的模型在高温高压下失效责任在算法开发者在CAD软件商还是在点击“生成”按钮的工程师目前没有任何法规或标准能回答这个问题。所以我的建议很朴素text-to-CAD的黄金应用场景永远是那些“错了能重来、慢了能接受、但重复做会疯掉”的任务。把工程师从机械劳动中解放出来让他们专注在真正需要人类智慧的地方创新设计、工艺优化、跨部门协同——这才是技术该有的温度。我在车间墙上贴着一张纸上面写着“CAD不是画图是把想法变成零件的语言。而text-to-CAD不过是让这门语言少一点拗口多一点直白。”