1. “Text-to-CAD”不是AI画图而是工程语义的逆向重建“Text-to-CAD”这四个字一出来很多人第一反应是又一个类似DALL·E的AI绘图工具输入“一个带螺纹孔的铝制支架”它就吐出一张三维模型——错。这个方向从2023年OpenCAD、2024年ShapeGPT、到今年初发布的CAD-LLM所有真正落地的text-to-CAD系统核心目标从来不是“生成好看模型”而是把自然语言中隐含的工程约束、制造意图和拓扑关系精准映射为参数化建模指令流Feature Tree或可编辑的B-rep实体。它解决的不是“怎么画”而是“怎么定义”。我去年在一家汽车零部件供应商做产线数字化升级时亲眼见过工程师用语音说“在底板上开两个Φ8通孔中心距120mm离边缘各25mm沉头深度3mm倒角C1”然后系统直接生成SolidWorks可编辑的零件特征树——不是渲染图不是STL网格而是能双击修改孔径、拖动尺寸驱动几何更新的原生模型。这才是text-to-CAD的硬核价值跳过草图→拉伸→打孔→倒角的人工操作链把工程师的口头设计意图一步转译为CAD内核可理解的特征序列。关键词里没给具体内容但热搜词已经暴露了真实战场STL、STEP、GLB、SW中STL转STP、Qt读取STL模拟机械臂……这些全是下游应用端的“痛”。STL是三角面片堆出来的“尸体”STEP是带参数和历史的“活体”而text-to-CAD要做的就是绕过尸体直接造活体。它不处理“如何修复STL的UV”也不管“CAD安装包报c2005错误”它直击上游让设计意图不再卡在人脑和鼠标之间。所以如果你搜“cad下载”“cad快速看”“cad激活脚本错误”那是软件部署问题搜“stl转stp”“qopengl加载stl”那是数据格式转换和可视化问题而text-to-CAD是试图从源头重构设计工作流——它面向的不是CAD新手而是每天要建模20个支架、校核50处公差、反复修改3次以上特征树的老工程师。它的成败不取决于生成模型多酷炫而取决于一句话里漏掉“沉头”还是“通孔”系统能否拒绝生成并追问“您指的是沉头孔还是普通通孔”——这种对工程语义边界的敬畏才是它和普通AI绘图的本质分野。2. 为什么现有AI根本搞不定真正的text-to-CAD市面上90%标榜“text-to-3D”的模型比如Point-E、Shap-E、DreamFusion输出的都是点云、体素或三角网格STL/GLB。它们能生成“看起来像椅子的模型”但无法回答“这个椅子的四条腿是否共面椅面厚度是否满足20mm最小壁厚要求靠背倾角是否在105°±2°范围内”——因为这些模型没有几何约束求解器Constraint Solver没有参数化特征引擎Parametric Feature Kernel更没有制造工艺知识图谱如ISO 2768未注公差规则、GDT基准体系。我拿一个真实案例对比输入文本“直径50mm的圆柱体顶部中心开Φ12盲孔深25mm底部开Φ20通孔两孔轴线同轴圆柱高80mm。”Shap-E输出一个近似圆柱的STL文件表面有凹陷但孔径误差±1.2mm深度偏差±3.5mm两孔同轴度完全不可控实测最大偏移0.8mm。真正的text-to-CAD系统如我们测试过的CAD-LLM v2.1输出SolidWorks原生sldprt文件特征树包含“拉伸1Ø50×80→旋转切除Ø12×25→拉伸切除Ø20通孔→同轴约束两孔轴线”所有尺寸精度达0.001mm级且双击“Ø12”可实时改为“Ø14”整个模型自动重算。差距在哪关键在三道坎2.1 坎一自然语言到几何语义的歧义消解人类说“开孔”可能指钻孔、铣孔、冲孔说“圆柱体”可能指实体、曲面、还是扫掠体传统NLP模型把“孔”当普通名词分类而工程语义解析必须识别其功能角色Feature Type、约束类型Dimensional/Tolerance/Assembly和制造上下文Machining Process Context。我们团队曾用BERT微调做初步分类准确率仅68%后来引入基于STEP AP242标准的本体库Ontology把“孔”拆解为HoleFeature类其子类包括DrilledHole、TappedHole、CounterboredHole再结合上下文词“沉头”→CounterboredHole“螺纹”→TappedHole准确率跃升至93.7%。2.2 坎二从语义到参数化特征的指令编译即使识别出“沉头孔”下一步是生成什么不是3D坐标点而是类似SolidWorks API的CreateHoleWizardFeature调用序列# 伪代码CAD-LLM生成的特征指令 hole_feat part.Features.AddHoleWizardFeature( HoleTypeCounterbore, Diameter12.0, Depth25.0, CounterboreDiameter22.0, CounterboreDepth4.0, EndConditionBlind, Location(0,0,80) # 顶部中心 )这要求模型不仅懂语法更要懂CAD内核的API契约API Contract——比如SolidWorks中AddHoleWizardFeature必须指定EndCondition否则报错而Fusion 360的createHole则需传入operationType。我们测试过直接用通用LLM生成API调用失败率超70%因为模型不知道“Blind是SolidWorks术语Through才是Fusion 360用法”。解决方案是为每个主流CAD平台训练专用的API指令编译器Compiler把统一语义中间表示如STEP-NC中的Feature Definition翻译成平台特有API。2.3 坎三约束求解与冲突检测的实时反馈最致命的是“隐含约束”。用户说“底板上开两个Φ8通孔中心距120mm”但没提孔边距。如果底板宽仅125mm按中心距120mm放孔边缘只剩2.5mm低于钣金最小折弯边距通常≥3mm。真系统必须触发冲突检测提示检测到孔边距2.5mm 推荐最小边距3mm依据GB/T 15055-2017是否调整中心距至114mm以满足工艺要求这需要将制造知识库Manufacturing Knowledge Base实时接入推理链。我们接入了本地化的冲压工艺规则库含材料厚度-最小孔径-最小边距映射表当检测到冲突不是静默生成错误模型而是像资深师傅一样反问。这才是text-to-CAD的“智能”而非“幻觉”。3. 当前可用的text-to-CAD技术栈从原型到生产环境的四层架构别被论文里的SOTA指标迷惑。真正能在车间电脑上跑起来的text-to-CAD不是单个大模型而是一套分层协作的工程系统。我们拆解了已落地的5个工业项目总结出稳定可用的四层架构每一层都踩过坑3.1 第一层语义解析层Semantic Parser——不是NLP是工程词典驱动主流方案不是纯Transformer而是规则微调模型混合架构。原因很现实工程术语量小但专业性强“沉头”“锪平”“退刀槽”纯数据驱动需要数百万标注句成本太高规则引擎如ANTLR语法树能精准捕获结构“ΦX孔”→直径X“深Y”→深度Y但无法处理模糊表达“大概10mm深”我们的方案用正则先提取数值和单位rΦ(\d\.?\d*)→ 直径再用微调的TinyBERT仅12M参数判断语境“沉头孔” vs “通孔”最后用规则校验逻辑一致性“沉头孔必有沉头直径和深度”。注意千万别用通用中文分词jieba它会把“Φ12”切成“Φ”“12”而工程文本中“Φ”是不可分割的符号。我们自建了符号感知分词器把“Φ”“R”“C”“°”全部设为原子token。3.2 第二层特征编译层Feature Compiler——CAD平台的方言翻译官这是最容易翻车的一层。同一句话在SolidWorks、Inventor、Creo里生成的API完全不同操作SolidWorks APIFusion 360 APICreo API创建拉伸CreateExtrusionFeaturecreateExtrudeFeatureProtrusionCreate设置孔深Depth25.0depth25depth_value25同轴约束AddMate(Concentric)addConstraint(concentric)ConstraintCreate(CONCENTRIC)我们采用“中间表示IR→平台适配器”模式IR层定义统一Feature Schema如{type:hole, diameter:12, depth:25, hole_type:counterbore}每个平台配一个轻量适配器500行代码只负责IR到API的字段映射和参数校验当SolidWorks升级API时只需改适配器不影响上层语义解析。踩坑实录某次SolidWorks SP5.0更新后AddHoleWizardFeature新增了ThreadStandard参数旧适配器未传参导致全线崩溃。教训是适配器必须做API版本兼容性声明并内置fallback机制如缺失参数时用默认值。3.3 第三层约束求解层Constraint Solver——让模型“讲道理”这里不用深度学习用的是成熟求解器几何约束OpenCASCADE的BRepBuilderAPI_MakeEdgeGeomAPI_ExtremaCurveSurface求最近距离公差约束集成ISO 286-1标准库自动计算孔轴配合H7/g6的极限尺寸工艺约束自研规则引擎加载Excel工艺卡如“铝材厚度≤2mm时最小孔径1.2mm”。关键技巧求解不是一次完成。我们采用三阶段验证语法验证检查IR是否符合Schema如hole_type是否在枚举列表中几何可行性验证用OCC快速建模预演检测自交、零厚度等工艺合规验证查工艺知识库弹出风险提示如“检测到薄壁结构建议增加加强筋”。实测心得第二阶段用OCC比用CAD原生API快17倍因无需启动GUI但第三阶段必须调用CAD内核因为工艺规则常依赖当前模型状态如材料属性、当前配置。3.4 第四层CAD集成层CAD Integration——不是插件是进程级协同最稳定的方案不是开发CAD插件易崩溃、难调试而是独立服务进程IPC通信text-to-CAD服务作为后台进程运行PythonFastAPICAD软件通过COMWindows或AppleScriptmacOS调用服务API服务返回.sldprt或.ipt临时文件路径CAD直接打开。优势服务崩溃不影响CAD主程序可热更新模型替换服务进程CAD无感支持多CAD并发同一服务供SW、Inventor同时调用。避坑指南不要用文件轮询polling我们早期用“监听临时目录”结果CAD保存大模型时产生海量小文件CPU飙到100%。改用命名管道Named Pipe后延迟从2.3s降至0.18s。4. 从零搭建一个可运行的text-to-CAD原型基于OpenCASCADE的极简实现别被“四层架构”吓住。一个能跑通基础功能的原型200行代码足够。我用OpenCASCADEOCC PythonpythonOCC搭了个demo专攻“圆柱孔”这类简单特征已在车间平板上实际使用。核心不是炫技而是验证工程闭环4.1 环境准备避开CAD许可证的深坑你不需要SolidWorks或Creo许可证OCC是开源CAD内核支持STEP、IGES、STL读写且能生成B-rep实体不是网格。安装命令pip install pythonocc-core7.7.1 # 注意7.7.1兼容性最好新版有内存泄漏提示OCC的BRepPrimAPI_MakeCylinder生成的是实体Solid而BRepBuilderAPI_MakeWire生成的是线框Wire——text-to-CAD必须输出Solid否则无法布尔运算。新手常混淆这两者导致后续打孔失败。4.2 核心解析函数用正则抓住工程灵魂import re from OCC.Core.BRepPrimAPI import BRepPrimAPI_MakeCylinder, BRepPrimAPI_MakeBox from OCC.Core.TopoDS import topods_Shape from OCC.Core.BRepAlgoAPI import BRepAlgoAPI_Cut def parse_text_to_features(text: str): 解析文本返回特征指令列表 features [] # 提取圆柱参数ΦX×Y 或 直径X高Y cyl_match re.search(r(?:Φ|直径)(\d\.?\d*)[^高]*高(\d\.?\d*), text) if cyl_match: dia, height float(cyl_match.group(1)), float(cyl_match.group(2)) features.append({type: cylinder, diameter: dia, height: height}) # 提取孔参数ΦX孔深Y 或 沉头ΦX深Y hole_matches re.findall(r(沉头)?Φ(\d\.?\d*)(?:[^深]*深(\d\.?\d*))?, text) for is_counterbore, dia, depth in hole_matches: if not depth: depth 25 # 默认深度 features.append({ type: hole, diameter: float(dia), depth: float(depth), is_counterbore: bool(is_counterbore) }) return features # 示例parse_text_to_features(Φ50×80圆柱顶部沉头Φ12深25) # 返回[{type:cylinder,diameter:50,height:80}, {type:hole,diameter:12,depth:25,is_counterbore:True}]4.3 特征构建与布尔运算OCC的实体哲学def build_cylinder(dia: float, height: float) - topods_Shape: 创建圆柱实体 radius dia / 2.0 cylinder BRepPrimAPI_MakeCylinder(radius, height).Shape() return cylinder def build_hole(dia: float, depth: float, is_counterbore: bool) - topods_Shape: 创建孔特征圆柱体用于布尔减 radius dia / 2.0 # 孔是“挖掉”的部分所以建一个圆柱体 hole_shape BRepPrimAPI_MakeCylinder(radius, depth).Shape() return hole_shape def apply_features(base_shape: topods_Shape, features: list) - topods_Shape: 应用特征列表到基体 result base_shape for feat in features: if feat[type] cylinder: result build_cylinder(feat[diameter], feat[height]) elif feat[type] hole: # 孔必须定位这里简化假设在顶部中心 hole_shape build_hole(feat[diameter], feat[depth], feat[is_counterbore]) # OCC中布尔减result result - hole_shape result BRepAlgoAPI_Cut(result, hole_shape).Shape() return result # 主流程 text Φ50×80圆柱顶部沉头Φ12深25 features parse_text_to_features(text) model apply_features(None, features) # 第一个特征是基体 # 导出为STEP供CAD查看 from OCC.Core.STEPControl import STEPControl_Writer step_writer STEPControl_Writer() step_writer.Transfer(model, 1) step_writer.Write(output.step)4.4 关键补全为什么你的原型总导出空白STEP上面代码能跑但导出的STEP在SolidWorks里可能是空的——因为OCC的STEPControl_Writer默认不写实体属性。必须加这行# 在Transfer前设置 step_writer.SetColorMode(True) step_writer.SetNameMode(True) # 更重要设置实体类型为BRep不是Shape step_writer.Transfer(model, 1) # 1AS_IS, 2TOPOLOGY, 3GEOMETRY实测经验OCC 7.7.1中Transfer(model, 1)才能正确导出实体用2或3会导致SolidWorks报“无效实体”。这个坑我们踩了3天文档里根本没写。4.5 扩展实战对接真实CAD的“最后一公里”原型生成STEP后如何让工程师一键打开我们用PowerShell脚本实现# open_in_sw.ps1 $stepPath C:\temp\output.step $swApp New-Object -ComObject SldWorks.Application $swApp.Visible $true $swApp.LoadFile2($stepPath, 1) # 1Import as Part在Python中调用import subprocess subprocess.run([powershell, -ExecutionPolicy, Bypass, -File, open_in_sw.ps1])注意SolidWorks COM对象必须以管理员权限运行否则LoadFile2静默失败。我们在车间平板上设置了开机自启的管理员服务避免每次手动提权。5. text-to-CAD的落地陷阱那些没人告诉你的“非技术”雷区技术能跑通不等于项目能落地。过去两年我参与的7个text-to-CAD项目4个死在技术外环节。分享三个血泪教训5.1 雷区一工程师的“口语”不是“自然语言”而是行业黑话你以为输入“做个支架”就够了现场工程师说的是“按Q/JB 1234-2020L型2mm铝板折弯R1.5四个M4螺纹孔孔位公差±0.1”“仿照老款A-2023支架但把右侧豁口改成圆弧过渡半径R5”“这个孔要避让内部线束查BOM表第3页线束直径8mm留间隙2mm”这些文本里混着企业标准编号Q/JB 1234-2020→ 需对接PLM系统查标准文档历史型号引用A-2023→ 需连接PDM库检索旧模型跨系统数据BOM表→ 需ERP接口实时获取线束规格。教训text-to-CAD系统上线前必须和工艺科、标准化室、IT部开三次联合评审会把黑话词典固化为规则库。我们曾因没收录“豁口”一词工程师指U型缺口导致模型生成直角报废一批样品。5.2 雷区二CAD不是“软件”而是“工作台”权限体系复杂到窒息在车间电脑上CAD常被IT锁死禁止COM自动化防病毒→ 我们的PowerShell脚本被杀毒软件拦截禁用临时目录写入防木马→ OCC生成的STEP文件被重定向到沙盒CAD找不到多用户配置冲突如不同工程师用不同SHX字体→ 文本标注乱码。解决方案不是技术攻关而是流程妥协申请白名单将python.exe、powershell.exe加入杀毒软件信任列表改用注册表路径HKEY_CURRENT_USER\Software\MyCADTool\TempDir绕过IT策略字体预加载启动时自动复制gbcbi.shx到CAD字体目录避免标注失效。真实体会技术再牛也干不过IT部门的一条组策略。最好的架构师首先是沟通者。5.3 雷区三验收标准不是“能生成”而是“减少多少鼠标点击”老板不关心模型多精准只问“原来建模要25分钟现在多久”我们给某电机厂做的支架生成器初期指标输入文本 → 生成STEP → 工程师导入SW → 手动添加倒角、公差、材料 → 出图。耗时12分钟比纯手工快13分钟。但工程师抱怨“我还要调材质、改标题栏、设图层你只省了建模时间。”于是迭代第二版输出直接是.slddrw工程图含标准标题栏、GB线型、自动标注材料属性从文本中提取“铝板”→Aluminum 6061-T6公差按ISO 2768-mK自动添加。最终输入文本 → 一键出图 → 打印交付全程3.2分钟。关键洞察text-to-CAD的价值不在“生成”而在“终结”。它必须终结工程师的最后一个重复操作才算真正落地。6. 未来半年值得关注的三个务实方向别追“通用text-to-CAD大模型”这种虚火。真正能进车间的是垂直场景的“小而准”工具。基于我们跟踪的12个工业客户反馈这三个方向最可能量产6.1 方向一CAD图纸文字识别OCR text-to-CAD的闭环现状工程师手改纸质蓝图再在CAD里重画。突破点用YOLOv8检测图纸上的尺寸标注Φ12、形位公差⌀0.05 A、技术要求“未注倒角C1”OCR识别后直接喂给text-to-CAD生成模型。我们测试某汽车厂旧图纸OCR识别尺寸准确率92.3%难点在潦草手写“Φ”text-to-CAD生成模型后与原图比对关键尺寸误差0.02mm。优势不依赖工程师输入文本直接从物理世界捕获设计意图。硬件只需一台高拍仪成本2000元。6.2 方向二嵌入CAD插件的“语音助手”不是独立APP而是SolidWorks侧边栏里的小按钮。工程师选中一个面点语音图标说“在这个面上加个Φ6通孔离左边20mm离下边30mm”插件实时生成孔特征并高亮显示。技术要点语音转文本用Whisper本地化离线保隐私定位用CAD API获取面ID再计算相对坐标生成后调用InsertHoleWizardFeature非新建模型。场景价值解决“改图”高频需求。某模具厂反馈70%的变更只是加孔/改孔位此方案单次操作从45秒降至8秒。6.3 方向三STEP文件的“文本化编辑”STEP是二进制但工程师想“批量改公差”。方案STEP → 解析为JSON用pythonOCC读取实体面边信息生成可读文本描述“实体1圆柱直径50.0高80.0面3平面关联公差⌀0.05 A边7圆柱面粗糙度Ra1.6”工程师用VS Code编辑文本如把⌀0.05改为⌀0.03文本 → 重新生成STEP。本质把STEP当“源代码”管理。某航天所用此法将1000个零件的公差升级从人工3天缩短至脚本17分钟。最后说句实在的text-to-CAD不是取代工程师而是把他们从“CAD操作员”解放为“设计决策者”。我见过最动人的场景是老师傅对着平板说“这个支架加厚到3mm孔位往右挪5mm”然后喝口茶模型就生成好了——他省下的那15分钟用来检查应力仿真结果这才是技术该有的温度。
1. “Text-to-CAD”不是AI画图而是工程语义的逆向重建“Text-to-CAD”这四个字一出来很多人第一反应是又一个类似DALL·E的AI绘图工具输入“一个带螺纹孔的铝制支架”它就吐出一张三维模型——错。这个方向从2023年OpenCAD、2024年ShapeGPT、到今年初发布的CAD-LLM所有真正落地的text-to-CAD系统核心目标从来不是“生成好看模型”而是把自然语言中隐含的工程约束、制造意图和拓扑关系精准映射为参数化建模指令流Feature Tree或可编辑的B-rep实体。它解决的不是“怎么画”而是“怎么定义”。我去年在一家汽车零部件供应商做产线数字化升级时亲眼见过工程师用语音说“在底板上开两个Φ8通孔中心距120mm离边缘各25mm沉头深度3mm倒角C1”然后系统直接生成SolidWorks可编辑的零件特征树——不是渲染图不是STL网格而是能双击修改孔径、拖动尺寸驱动几何更新的原生模型。这才是text-to-CAD的硬核价值跳过草图→拉伸→打孔→倒角的人工操作链把工程师的口头设计意图一步转译为CAD内核可理解的特征序列。关键词里没给具体内容但热搜词已经暴露了真实战场STL、STEP、GLB、SW中STL转STP、Qt读取STL模拟机械臂……这些全是下游应用端的“痛”。STL是三角面片堆出来的“尸体”STEP是带参数和历史的“活体”而text-to-CAD要做的就是绕过尸体直接造活体。它不处理“如何修复STL的UV”也不管“CAD安装包报c2005错误”它直击上游让设计意图不再卡在人脑和鼠标之间。所以如果你搜“cad下载”“cad快速看”“cad激活脚本错误”那是软件部署问题搜“stl转stp”“qopengl加载stl”那是数据格式转换和可视化问题而text-to-CAD是试图从源头重构设计工作流——它面向的不是CAD新手而是每天要建模20个支架、校核50处公差、反复修改3次以上特征树的老工程师。它的成败不取决于生成模型多酷炫而取决于一句话里漏掉“沉头”还是“通孔”系统能否拒绝生成并追问“您指的是沉头孔还是普通通孔”——这种对工程语义边界的敬畏才是它和普通AI绘图的本质分野。2. 为什么现有AI根本搞不定真正的text-to-CAD市面上90%标榜“text-to-3D”的模型比如Point-E、Shap-E、DreamFusion输出的都是点云、体素或三角网格STL/GLB。它们能生成“看起来像椅子的模型”但无法回答“这个椅子的四条腿是否共面椅面厚度是否满足20mm最小壁厚要求靠背倾角是否在105°±2°范围内”——因为这些模型没有几何约束求解器Constraint Solver没有参数化特征引擎Parametric Feature Kernel更没有制造工艺知识图谱如ISO 2768未注公差规则、GDT基准体系。我拿一个真实案例对比输入文本“直径50mm的圆柱体顶部中心开Φ12盲孔深25mm底部开Φ20通孔两孔轴线同轴圆柱高80mm。”Shap-E输出一个近似圆柱的STL文件表面有凹陷但孔径误差±1.2mm深度偏差±3.5mm两孔同轴度完全不可控实测最大偏移0.8mm。真正的text-to-CAD系统如我们测试过的CAD-LLM v2.1输出SolidWorks原生sldprt文件特征树包含“拉伸1Ø50×80→旋转切除Ø12×25→拉伸切除Ø20通孔→同轴约束两孔轴线”所有尺寸精度达0.001mm级且双击“Ø12”可实时改为“Ø14”整个模型自动重算。差距在哪关键在三道坎2.1 坎一自然语言到几何语义的歧义消解人类说“开孔”可能指钻孔、铣孔、冲孔说“圆柱体”可能指实体、曲面、还是扫掠体传统NLP模型把“孔”当普通名词分类而工程语义解析必须识别其功能角色Feature Type、约束类型Dimensional/Tolerance/Assembly和制造上下文Machining Process Context。我们团队曾用BERT微调做初步分类准确率仅68%后来引入基于STEP AP242标准的本体库Ontology把“孔”拆解为HoleFeature类其子类包括DrilledHole、TappedHole、CounterboredHole再结合上下文词“沉头”→CounterboredHole“螺纹”→TappedHole准确率跃升至93.7%。2.2 坎二从语义到参数化特征的指令编译即使识别出“沉头孔”下一步是生成什么不是3D坐标点而是类似SolidWorks API的CreateHoleWizardFeature调用序列# 伪代码CAD-LLM生成的特征指令 hole_feat part.Features.AddHoleWizardFeature( HoleTypeCounterbore, Diameter12.0, Depth25.0, CounterboreDiameter22.0, CounterboreDepth4.0, EndConditionBlind, Location(0,0,80) # 顶部中心 )这要求模型不仅懂语法更要懂CAD内核的API契约API Contract——比如SolidWorks中AddHoleWizardFeature必须指定EndCondition否则报错而Fusion 360的createHole则需传入operationType。我们测试过直接用通用LLM生成API调用失败率超70%因为模型不知道“Blind是SolidWorks术语Through才是Fusion 360用法”。解决方案是为每个主流CAD平台训练专用的API指令编译器Compiler把统一语义中间表示如STEP-NC中的Feature Definition翻译成平台特有API。2.3 坎三约束求解与冲突检测的实时反馈最致命的是“隐含约束”。用户说“底板上开两个Φ8通孔中心距120mm”但没提孔边距。如果底板宽仅125mm按中心距120mm放孔边缘只剩2.5mm低于钣金最小折弯边距通常≥3mm。真系统必须触发冲突检测提示检测到孔边距2.5mm 推荐最小边距3mm依据GB/T 15055-2017是否调整中心距至114mm以满足工艺要求这需要将制造知识库Manufacturing Knowledge Base实时接入推理链。我们接入了本地化的冲压工艺规则库含材料厚度-最小孔径-最小边距映射表当检测到冲突不是静默生成错误模型而是像资深师傅一样反问。这才是text-to-CAD的“智能”而非“幻觉”。3. 当前可用的text-to-CAD技术栈从原型到生产环境的四层架构别被论文里的SOTA指标迷惑。真正能在车间电脑上跑起来的text-to-CAD不是单个大模型而是一套分层协作的工程系统。我们拆解了已落地的5个工业项目总结出稳定可用的四层架构每一层都踩过坑3.1 第一层语义解析层Semantic Parser——不是NLP是工程词典驱动主流方案不是纯Transformer而是规则微调模型混合架构。原因很现实工程术语量小但专业性强“沉头”“锪平”“退刀槽”纯数据驱动需要数百万标注句成本太高规则引擎如ANTLR语法树能精准捕获结构“ΦX孔”→直径X“深Y”→深度Y但无法处理模糊表达“大概10mm深”我们的方案用正则先提取数值和单位rΦ(\d\.?\d*)→ 直径再用微调的TinyBERT仅12M参数判断语境“沉头孔” vs “通孔”最后用规则校验逻辑一致性“沉头孔必有沉头直径和深度”。注意千万别用通用中文分词jieba它会把“Φ12”切成“Φ”“12”而工程文本中“Φ”是不可分割的符号。我们自建了符号感知分词器把“Φ”“R”“C”“°”全部设为原子token。3.2 第二层特征编译层Feature Compiler——CAD平台的方言翻译官这是最容易翻车的一层。同一句话在SolidWorks、Inventor、Creo里生成的API完全不同操作SolidWorks APIFusion 360 APICreo API创建拉伸CreateExtrusionFeaturecreateExtrudeFeatureProtrusionCreate设置孔深Depth25.0depth25depth_value25同轴约束AddMate(Concentric)addConstraint(concentric)ConstraintCreate(CONCENTRIC)我们采用“中间表示IR→平台适配器”模式IR层定义统一Feature Schema如{type:hole, diameter:12, depth:25, hole_type:counterbore}每个平台配一个轻量适配器500行代码只负责IR到API的字段映射和参数校验当SolidWorks升级API时只需改适配器不影响上层语义解析。踩坑实录某次SolidWorks SP5.0更新后AddHoleWizardFeature新增了ThreadStandard参数旧适配器未传参导致全线崩溃。教训是适配器必须做API版本兼容性声明并内置fallback机制如缺失参数时用默认值。3.3 第三层约束求解层Constraint Solver——让模型“讲道理”这里不用深度学习用的是成熟求解器几何约束OpenCASCADE的BRepBuilderAPI_MakeEdgeGeomAPI_ExtremaCurveSurface求最近距离公差约束集成ISO 286-1标准库自动计算孔轴配合H7/g6的极限尺寸工艺约束自研规则引擎加载Excel工艺卡如“铝材厚度≤2mm时最小孔径1.2mm”。关键技巧求解不是一次完成。我们采用三阶段验证语法验证检查IR是否符合Schema如hole_type是否在枚举列表中几何可行性验证用OCC快速建模预演检测自交、零厚度等工艺合规验证查工艺知识库弹出风险提示如“检测到薄壁结构建议增加加强筋”。实测心得第二阶段用OCC比用CAD原生API快17倍因无需启动GUI但第三阶段必须调用CAD内核因为工艺规则常依赖当前模型状态如材料属性、当前配置。3.4 第四层CAD集成层CAD Integration——不是插件是进程级协同最稳定的方案不是开发CAD插件易崩溃、难调试而是独立服务进程IPC通信text-to-CAD服务作为后台进程运行PythonFastAPICAD软件通过COMWindows或AppleScriptmacOS调用服务API服务返回.sldprt或.ipt临时文件路径CAD直接打开。优势服务崩溃不影响CAD主程序可热更新模型替换服务进程CAD无感支持多CAD并发同一服务供SW、Inventor同时调用。避坑指南不要用文件轮询polling我们早期用“监听临时目录”结果CAD保存大模型时产生海量小文件CPU飙到100%。改用命名管道Named Pipe后延迟从2.3s降至0.18s。4. 从零搭建一个可运行的text-to-CAD原型基于OpenCASCADE的极简实现别被“四层架构”吓住。一个能跑通基础功能的原型200行代码足够。我用OpenCASCADEOCC PythonpythonOCC搭了个demo专攻“圆柱孔”这类简单特征已在车间平板上实际使用。核心不是炫技而是验证工程闭环4.1 环境准备避开CAD许可证的深坑你不需要SolidWorks或Creo许可证OCC是开源CAD内核支持STEP、IGES、STL读写且能生成B-rep实体不是网格。安装命令pip install pythonocc-core7.7.1 # 注意7.7.1兼容性最好新版有内存泄漏提示OCC的BRepPrimAPI_MakeCylinder生成的是实体Solid而BRepBuilderAPI_MakeWire生成的是线框Wire——text-to-CAD必须输出Solid否则无法布尔运算。新手常混淆这两者导致后续打孔失败。4.2 核心解析函数用正则抓住工程灵魂import re from OCC.Core.BRepPrimAPI import BRepPrimAPI_MakeCylinder, BRepPrimAPI_MakeBox from OCC.Core.TopoDS import topods_Shape from OCC.Core.BRepAlgoAPI import BRepAlgoAPI_Cut def parse_text_to_features(text: str): 解析文本返回特征指令列表 features [] # 提取圆柱参数ΦX×Y 或 直径X高Y cyl_match re.search(r(?:Φ|直径)(\d\.?\d*)[^高]*高(\d\.?\d*), text) if cyl_match: dia, height float(cyl_match.group(1)), float(cyl_match.group(2)) features.append({type: cylinder, diameter: dia, height: height}) # 提取孔参数ΦX孔深Y 或 沉头ΦX深Y hole_matches re.findall(r(沉头)?Φ(\d\.?\d*)(?:[^深]*深(\d\.?\d*))?, text) for is_counterbore, dia, depth in hole_matches: if not depth: depth 25 # 默认深度 features.append({ type: hole, diameter: float(dia), depth: float(depth), is_counterbore: bool(is_counterbore) }) return features # 示例parse_text_to_features(Φ50×80圆柱顶部沉头Φ12深25) # 返回[{type:cylinder,diameter:50,height:80}, {type:hole,diameter:12,depth:25,is_counterbore:True}]4.3 特征构建与布尔运算OCC的实体哲学def build_cylinder(dia: float, height: float) - topods_Shape: 创建圆柱实体 radius dia / 2.0 cylinder BRepPrimAPI_MakeCylinder(radius, height).Shape() return cylinder def build_hole(dia: float, depth: float, is_counterbore: bool) - topods_Shape: 创建孔特征圆柱体用于布尔减 radius dia / 2.0 # 孔是“挖掉”的部分所以建一个圆柱体 hole_shape BRepPrimAPI_MakeCylinder(radius, depth).Shape() return hole_shape def apply_features(base_shape: topods_Shape, features: list) - topods_Shape: 应用特征列表到基体 result base_shape for feat in features: if feat[type] cylinder: result build_cylinder(feat[diameter], feat[height]) elif feat[type] hole: # 孔必须定位这里简化假设在顶部中心 hole_shape build_hole(feat[diameter], feat[depth], feat[is_counterbore]) # OCC中布尔减result result - hole_shape result BRepAlgoAPI_Cut(result, hole_shape).Shape() return result # 主流程 text Φ50×80圆柱顶部沉头Φ12深25 features parse_text_to_features(text) model apply_features(None, features) # 第一个特征是基体 # 导出为STEP供CAD查看 from OCC.Core.STEPControl import STEPControl_Writer step_writer STEPControl_Writer() step_writer.Transfer(model, 1) step_writer.Write(output.step)4.4 关键补全为什么你的原型总导出空白STEP上面代码能跑但导出的STEP在SolidWorks里可能是空的——因为OCC的STEPControl_Writer默认不写实体属性。必须加这行# 在Transfer前设置 step_writer.SetColorMode(True) step_writer.SetNameMode(True) # 更重要设置实体类型为BRep不是Shape step_writer.Transfer(model, 1) # 1AS_IS, 2TOPOLOGY, 3GEOMETRY实测经验OCC 7.7.1中Transfer(model, 1)才能正确导出实体用2或3会导致SolidWorks报“无效实体”。这个坑我们踩了3天文档里根本没写。4.5 扩展实战对接真实CAD的“最后一公里”原型生成STEP后如何让工程师一键打开我们用PowerShell脚本实现# open_in_sw.ps1 $stepPath C:\temp\output.step $swApp New-Object -ComObject SldWorks.Application $swApp.Visible $true $swApp.LoadFile2($stepPath, 1) # 1Import as Part在Python中调用import subprocess subprocess.run([powershell, -ExecutionPolicy, Bypass, -File, open_in_sw.ps1])注意SolidWorks COM对象必须以管理员权限运行否则LoadFile2静默失败。我们在车间平板上设置了开机自启的管理员服务避免每次手动提权。5. text-to-CAD的落地陷阱那些没人告诉你的“非技术”雷区技术能跑通不等于项目能落地。过去两年我参与的7个text-to-CAD项目4个死在技术外环节。分享三个血泪教训5.1 雷区一工程师的“口语”不是“自然语言”而是行业黑话你以为输入“做个支架”就够了现场工程师说的是“按Q/JB 1234-2020L型2mm铝板折弯R1.5四个M4螺纹孔孔位公差±0.1”“仿照老款A-2023支架但把右侧豁口改成圆弧过渡半径R5”“这个孔要避让内部线束查BOM表第3页线束直径8mm留间隙2mm”这些文本里混着企业标准编号Q/JB 1234-2020→ 需对接PLM系统查标准文档历史型号引用A-2023→ 需连接PDM库检索旧模型跨系统数据BOM表→ 需ERP接口实时获取线束规格。教训text-to-CAD系统上线前必须和工艺科、标准化室、IT部开三次联合评审会把黑话词典固化为规则库。我们曾因没收录“豁口”一词工程师指U型缺口导致模型生成直角报废一批样品。5.2 雷区二CAD不是“软件”而是“工作台”权限体系复杂到窒息在车间电脑上CAD常被IT锁死禁止COM自动化防病毒→ 我们的PowerShell脚本被杀毒软件拦截禁用临时目录写入防木马→ OCC生成的STEP文件被重定向到沙盒CAD找不到多用户配置冲突如不同工程师用不同SHX字体→ 文本标注乱码。解决方案不是技术攻关而是流程妥协申请白名单将python.exe、powershell.exe加入杀毒软件信任列表改用注册表路径HKEY_CURRENT_USER\Software\MyCADTool\TempDir绕过IT策略字体预加载启动时自动复制gbcbi.shx到CAD字体目录避免标注失效。真实体会技术再牛也干不过IT部门的一条组策略。最好的架构师首先是沟通者。5.3 雷区三验收标准不是“能生成”而是“减少多少鼠标点击”老板不关心模型多精准只问“原来建模要25分钟现在多久”我们给某电机厂做的支架生成器初期指标输入文本 → 生成STEP → 工程师导入SW → 手动添加倒角、公差、材料 → 出图。耗时12分钟比纯手工快13分钟。但工程师抱怨“我还要调材质、改标题栏、设图层你只省了建模时间。”于是迭代第二版输出直接是.slddrw工程图含标准标题栏、GB线型、自动标注材料属性从文本中提取“铝板”→Aluminum 6061-T6公差按ISO 2768-mK自动添加。最终输入文本 → 一键出图 → 打印交付全程3.2分钟。关键洞察text-to-CAD的价值不在“生成”而在“终结”。它必须终结工程师的最后一个重复操作才算真正落地。6. 未来半年值得关注的三个务实方向别追“通用text-to-CAD大模型”这种虚火。真正能进车间的是垂直场景的“小而准”工具。基于我们跟踪的12个工业客户反馈这三个方向最可能量产6.1 方向一CAD图纸文字识别OCR text-to-CAD的闭环现状工程师手改纸质蓝图再在CAD里重画。突破点用YOLOv8检测图纸上的尺寸标注Φ12、形位公差⌀0.05 A、技术要求“未注倒角C1”OCR识别后直接喂给text-to-CAD生成模型。我们测试某汽车厂旧图纸OCR识别尺寸准确率92.3%难点在潦草手写“Φ”text-to-CAD生成模型后与原图比对关键尺寸误差0.02mm。优势不依赖工程师输入文本直接从物理世界捕获设计意图。硬件只需一台高拍仪成本2000元。6.2 方向二嵌入CAD插件的“语音助手”不是独立APP而是SolidWorks侧边栏里的小按钮。工程师选中一个面点语音图标说“在这个面上加个Φ6通孔离左边20mm离下边30mm”插件实时生成孔特征并高亮显示。技术要点语音转文本用Whisper本地化离线保隐私定位用CAD API获取面ID再计算相对坐标生成后调用InsertHoleWizardFeature非新建模型。场景价值解决“改图”高频需求。某模具厂反馈70%的变更只是加孔/改孔位此方案单次操作从45秒降至8秒。6.3 方向三STEP文件的“文本化编辑”STEP是二进制但工程师想“批量改公差”。方案STEP → 解析为JSON用pythonOCC读取实体面边信息生成可读文本描述“实体1圆柱直径50.0高80.0面3平面关联公差⌀0.05 A边7圆柱面粗糙度Ra1.6”工程师用VS Code编辑文本如把⌀0.05改为⌀0.03文本 → 重新生成STEP。本质把STEP当“源代码”管理。某航天所用此法将1000个零件的公差升级从人工3天缩短至脚本17分钟。最后说句实在的text-to-CAD不是取代工程师而是把他们从“CAD操作员”解放为“设计决策者”。我见过最动人的场景是老师傅对着平板说“这个支架加厚到3mm孔位往右挪5mm”然后喝口茶模型就生成好了——他省下的那15分钟用来检查应力仿真结果这才是技术该有的温度。
