1. “Text-to-CAD”不是又一个AI画图玩具而是工程设计工作流的断点重连“Text-to-CAD”这四个字最近在技术社区和工业软件圈里频繁弹出但多数人第一反应是这不就是“用文字生成3D模型”的新噱头类似MidJourney画图那样输入“一个带螺纹孔的铝制支架”就吐出一个STL文件——如果你也这么想那恰恰说明你还没真正看清它背后正在发生的底层位移。我接触这个方向最早是在某高校机械实验室协助搭建一个跨专业教学平台时。当时导师提出一个朴素需求“大一学生刚学《工程制图》能不能让他们跳过AutoCAD前8小时的界面熟悉期直接用自然语言描述‘底板长120mm、宽80mm、四角各有一个M4通孔中心凸起10mm高圆柱’就生成可编辑的参数化草图”我们试了三类方案第一类是调用现成多模态大模型API结果生成的几何体全是“看起来像”的近似体素块无法导出为SolidWorks可识别的BREP拓扑结构第二类是用传统NLP规则引擎解析语句但遇到“倒角半径为厚度的1/3”这类相对约束就彻底失效第三类才是后来真正跑通的路径——把文本理解、几何语义建模、参数化约束求解、CAD内核API调用这四层严格解耦再用轻量级微调模型做中间桥接。整个过程耗时三个月但最终交付的模块让零基础学生在15分钟内完成从文字到可修改特征树的闭环。这背后的关键认知跃迁在于Text-to-CAD的本质不是“生成”而是“可逆映射”。它要求输入的每一段文字必须能被无损还原为CAD系统内部的精确几何实体Point/Edge/Face、拓扑关系Adjacency/Incidence、参数约束Dimensional/Geometric和特征操作Extrude/Revolve/Loft。这不是图像生成那种“感知相似性”任务而是数学层面的“结构等价性”验证。所以你看不到OpenAI或Anthropic主推这个方向——因为它的技术栈横跨自然语言处理、计算几何、约束求解器如Cassowary或自研稀疏矩阵求解器、以及商业CAD内核如ACIS、Parasolid的深度集成属于典型的“三不管地带”AI公司嫌太重CAD厂商嫌太新高校研究嫌太工程。目前行业里真正落地的案例基本都锚定在三个刚性场景一是教育端降低入门门槛二是制造业中游的快速原型沟通比如采购工程师给供应商发微信“请按附件图纸做调整原φ12孔改为沉头孔沉头直径18mm深度3mm”三是AEC领域中非结构构件的标准化生成如幕墙龙骨连接件库的自动扩充。它们共同的特点是输入文本高度结构化、输出模型无需复杂曲面、对参数可编辑性有强依赖。换句话说“Text-to-CAD”当前的价值不在于替代设计师而在于把那些原本需要手动点击27次才能完成的重复性建模动作压缩成一次语义表达。提示别被“text-to-anything”的泛化宣传带偏。真正值得投入的Text-to-CAD项目一定具备明确的领域语料边界如只处理机械零件描述、确定的输出格式要求如必须生成SOLIDWORKS FeatureScript或Fusion 360 API可执行脚本、以及可验证的几何精度标准如所有线性尺寸公差≤±0.02mm。脱离这三点谈“通用Text-to-CAD”99%是Demo级玩具。2. 为什么现有大模型直接“喂”CAD数据行不通——从语义鸿沟到几何不可微性的硬伤去年底某团队在arXiv发布了一篇名为《CAD-GPT: Scaling Text-to-CAD with 10M Part Descriptions》的论文宣称用1000万条“文本-STEP文件”配对数据微调LLaMA-3实现了端到端生成。我们第一时间复现了其开源代码结果发现在测试集上模型能正确生成“长方体”“圆柱体”等基础体素的STEP文件但一旦涉及“抽壳厚度0.8mm”“沿螺旋线扫掠矩形截面”这类操作生成的BREP拓扑就出现大量非法边环Invalid Loop、未闭合面Non-manifold Face和参数冲突Over-constrained Sketch。更致命的是这些错误无法通过简单后处理修复——因为错误根植于模型对几何语义的理解偏差。问题出在哪我们做了三组对照实验结论很清晰第一语义粒度错配。人类描述CAD特征时天然采用“操作链”逻辑“先画矩形草图→添加两个同心圆→拉伸成实体→对顶部面倒角”。但大模型训练时看到的却是整个STEP文件的二进制流或其ASCII编码它被迫学习“倒角”对应的是edge_loop节点下嵌套的faced_surface和geometric_tolerance字段组合。这种从原子操作到文件结构的跨层映射远超当前Transformer架构的归纳能力。就像教一个没摸过琴的人听交响乐录音然后让他凭记忆复原每个小提琴手的指法——信息损失是结构性的。第二几何不可微性。CAD内核的核心是布尔运算Union/Difference/Intersect和参数化建模Feature-based Modeling。这些操作在数学上是离散事件驱动的当拉伸深度从9.9mm变为10.0mm时模型拓扑可能完全不变但当它跨过某个临界值如导致自相交整个BREP结构会突变。这种“阶梯式响应”无法用梯度下降优化。我们尝试用强化学习让模型预测拉伸深度奖励函数设为“生成模型与目标模型的Hausdorff距离”结果发现策略网络在临界点附近震荡剧烈收敛失败率超83%。根本原因在于距离函数本身在几何突变点不可导梯度信号在此处消失。第三约束系统的隐式耦合。真实CAD建模中一个尺寸标注往往牵扯多个约束。例如“中心孔距边缘15mm”这个描述实际在后台触发了① 创建参考基准面② 在该面上定义点约束③ 将点与边缘线建立水平/垂直距离约束④ 生成圆特征并绑定其中心。这四步在用户看来是一气呵成的但在内核里是四个独立事务。大模型若试图一次性生成所有约束ID和参数就必须掌握整个CAD系统的事务调度协议——而这恰恰是商业内核最严密的黑盒部分。我们最终放弃端到端路线转而构建分层解析框架。核心思路是把文本拆解为“意图→操作→参数→验证”四级流水线。例如输入“做一个底座长200宽150高30四角各有一个M6螺纹孔孔中心距边缘20mm”系统首先识别出主意图是“创建基体添加孔特征”然后调用专用NLU模块提取操作序列Extrude→Create Hole→Thread再由几何解析器将“M6螺纹孔”映射为标准螺纹表中的直径5.8mm、螺距1.0mm、有效深度12mm等参数最后交由约束求解器验证“孔中心距边缘20mm”是否与基体尺寸冲突。每一层都可独立调试、替换、验证这才是工程落地的正道。注意市面上所谓“支持Text-to-CAD的AI插件”90%只是前端加了个聊天框后端调用的是预设模板库匹配。比如输入“法兰盘”就从数据库里调出12个常见法兰模型供选择。这本质上是高级搜索不是真正的语义生成。判断真伪很简单让它生成“外径185mm、内径120mm、厚度22mm、8个均布φ10通孔、孔中心圆直径155mm”的定制法兰——如果不能实时生成可编辑的参数化模型那就还在Demo阶段。3. 真实可用的Text-to-CAD系统长什么样——基于SolidWorks API的轻量级实现路径既然端到端大模型走不通那务实的做法是什么我们团队在半年内交付了一个生产环境可用的Text-to-CAD模块部署在某制造企业的PLM系统中日均处理约320次设计意图转换。它的技术栈非常克制前端用Gradio做简易交互界面后端核心是Python SolidWorks API 自研几何语义解析器总代码量不到2800行。下面我把关键模块的实现逻辑和踩过的坑毫无保留地拆解出来。3.1 文本解析层不用BERT用有限状态机FSM更稳很多人第一反应是上大语言模型做NER命名实体识别但我们发现在机械设计领域描述文本的结构高度稳定。95%的有效指令遵循“主体尺寸修饰关系”模式例如“底板主体长120宽80高15尺寸带四个修饰M5沉头孔主体中心距边缘20关系”。因此我们放弃了复杂的深度学习模型改用手工编写的有限状态机FSM。FSM的状态流转图非常简洁INIT→ 遇到名词如“底板”“支架”进入ENTITY状态ENTITY→ 遇到量词“个”“处”“组”或尺寸单位“mm”“inch”进入DIMENSION状态DIMENSION→ 遇到关系词“距”“离”“中心”“对称”进入RELATION状态RELATION→ 遇到参照物“边缘”“中心线”“基准面”回到ENTITY或终止。关键技巧在于我们为每个状态预置了领域词典并支持模糊匹配。比如“沉头孔”会被识别为HOLE_TYPE实体其子类型“平头沉头”“锥形沉头”通过后缀词典匹配。实测下来FSM在测试集上的实体识别准确率达98.7%比微调后的RoBERTa-base高1.2个百分点且推理速度提升47倍单次解析8ms。更重要的是FSM的错误模式完全可解释——比如当输入“斜切45度”时FSM会卡在DIMENSION状态并报错“未识别角度修饰词”而大模型可能胡乱生成一个无效的Chamfer特征。3.2 几何映射层用参数化模板库代替自由生成我们构建了一个包含217个高频机械特征的参数化模板库每个模板都是SolidWorks FeatureManager Design Tree中可复用的特征树片段。例如“M6螺纹孔”模板内部已预置草图中心点直径5.8mm圆拉伸切除深度12mm方向朝向基准面螺纹特征ISO Metric Thread规格M6x1.0公差等级6H当FSM解析出“M6螺纹孔”时系统不是从零开始建模而是加载该模板再用解析出的参数如“孔中心距边缘20mm”动态修改模板中的几何约束。这里有个关键细节SolidWorks API的SketchPoint对象不支持直接设置“到边缘的距离”必须通过创建参考线添加尺寸约束来实现。我们的做法是先获取边缘线的SketchLine对象再调用CreateReferenceGeometry生成平行参考线最后用CreateDimension添加尺寸。整套操作封装成set_distance_to_edge(point, edge, distance)函数对外隐藏所有底层API调用细节。3.3 约束求解层用稀疏矩阵求解器处理参数冲突最棘手的是参数冲突检测。比如输入“底板长120宽80四角孔中心距边缘20”系统需验证2020 ≤ 120且2020 ≤ 80是否成立。但真实场景更复杂“孔中心圆直径155孔数8相邻孔中心夹角45度”——这涉及三角函数计算。我们没有自己造轮子而是集成开源稀疏矩阵求解器SuiteSparse将所有尺寸约束转化为线性/非线性方程组# 示例八孔均布约束 # 设孔中心圆半径R155/277.5第i个孔坐标(x_i,y_i) # x_i R * cos(θ_i), y_i R * sin(θ_i) # θ_i θ_0 (i-1)*45° # 约束所有(x_i,y_i)必须位于底板边界内即|x_i|≤60, |y_i|≤40求解器会返回可行解集或冲突报告。实践中我们发现85%的冲突源于单位混淆如输入混用mm和inch或逻辑矛盾如“沉头直径18mm”但“孔直径20mm”这些都在FSM层就做了强校验。实操心得SolidWorks API的FeatureManager对象在批量创建特征时极易崩溃尤其当特征间存在父子引用。我们的解决方案是所有特征创建必须在swModel.Extension.SelectByID2()选中基准面后用swModel.FeatureManager.FeatureExtrusion3()等原子方法逐个提交并在每次调用后检查swModel.GetErrors()。曾有一次因未检查错误码导致生成的模型在保存时静默失败排查了两天才发现是拉伸方向向量为零向量。4. 从“能用”到“好用”工程化落地必须跨越的五道坎很多团队做到第三步就宣布成功但我们在企业现场部署时才发现技术可行性只是起点工程可用性才是生死线。以下是我们在某汽车零部件厂落地时被反复暴击后总结出的五道硬坎每一道都决定了Text-to-CAD是沦为演示道具还是真正嵌入设计流程。4.1 坎一术语歧义的领域适配——同一句话在不同车间意思完全不同输入“做一个连接板”在机加工车间它默认是“铣削加工的矩形钢板”在钣金车间它默认是“折弯成型的带孔薄板”在铸造车间它默认是“带拔模斜度的砂型铸件”。我们最初的系统只认“连接板”这个名词结果生成的模型在铸造车间根本没法用——没加3°拔模角没留1.5mm加工余量。解决方案是引入“上下文开关”。系统启动时用户必须选择当前场景机加/钣金/铸造/3D打印每个场景对应独立的术语映射表。例如“连接板”在铸造场景下自动关联预设规则添加拔模斜度3°可配置所有直角改为R2圆角防裂纹厚度方向预留1.5mm加工余量生成砂芯定位孔直径φ8深10mm这套机制上线后铸造部门的模型一次通过率从31%提升至89%。关键启示Text-to-CAD的“智能”不在于理解多深而在于知道该向哪个领域低头。4.2 坎二尺寸链的隐式继承——人类不说但CAD必须懂工程师说“孔中心距边缘20mm”他心里默认的是“距最近的加工边缘”但CAD系统不知道哪条边是“加工边缘”。更隐蔽的是尺寸链继承比如“底板厚15mm安装面需铣平公差IT7”这隐含了“铣平面到厚度15±0.018mm”。如果系统只生成15mm厚的实体没添加公差注释和加工符号下游工艺部门会直接拒收。我们开发了“隐式规则引擎”它基于ISO 2768一般公差和GB/T 1800公差等级标准为每个尺寸自动附加默认公差。例如未标注公差的线性尺寸如“长120”→ 按GB/T 1800-IT14级±0.52mm未标注公差的角度尺寸如“45度”→ 按GB/T 1800-IT12级±15所有孔径尺寸 → 自动关联ISO 286标准中的公差带如M6默认6H这些规则以JSON配置文件管理产线工程师可随时调整。现在系统生成的模型自带完整GDT注释工艺员打开就能直接编制工序卡。4.3 坎三版本兼容性黑洞——SolidWorks 2022生成的模型2024打不开这是最反直觉的坑。我们曾为客户生成一批模型客户用SolidWorks 2024打开时所有参数化特征树全变成“冻结特征”Frozen Features无法编辑。查日志发现2024版API在创建FeatureExtrusion3时默认启用了“增强性能模式”该模式会禁用部分历史记录功能。而我们的模板库是用2022版录制的宏生成的特征间存在隐式依赖。终极解法是所有特征创建必须显式指定UseAutoCalculationFalse并在特征树末尾插入swModel.EditRebuild3()强制刷新。更狠的是我们给每个生成的模型添加水印属性swModel.CustomInfo2(, Text2CAD_Version, v2.3.1-SW2022)这样当模型在低版本打开失败时系统能精准提示“请使用SolidWorks 2022或更高版本”。4.4 坎四安全沙箱缺失——一句恶意输入就能删光服务器文件早期测试版有个致命漏洞用户输入“删除所有模型”系统FSM误判为ENTITY进而触发了swModel.CloseDoc()调用。更可怕的是当输入包含路径遍历字符如../../../etc/passwd时API竟真的尝试访问系统文件——虽然SolidWorks内核会拦截但日志里全是权限拒绝错误。我们立即加入三层防护输入净化层用正则过滤所有..、/、\\、*、?等危险字符API调用白名单只允许FeatureExtrusion3、CreateSketch、CreateDimension等23个安全API其余全部拦截沙箱进程隔离每个文本解析请求都在独立Docker容器中运行容器内存限制512MB超时强制kill。现在即使输入“生成10000个球体”系统也只会安静地返回“超出单次生成上限50个”而不是让服务器卡死。4.5 坎五人机协同断点——生成失败时不能只说“错了”得告诉人怎么改最失败的设计是让系统在解析失败时返回“语义解析错误”。用户看到这个只会关掉窗口。我们重构了错误反馈机制确保每次失败都给出可操作建议。例如输入“斜切45度” → 错误“未识别斜切角度修饰词。建议改为‘45度倒角’或‘45度斜角’”输入“底板长120宽80孔中心距边缘20孔数12” → 错误“12孔均布时最小孔中心圆直径需≥20×2÷sin(15°)≈77.3mm。当前底板宽度80mm不足请增大底板宽度或减少孔数”这套机制基于预计算的几何约束库所有错误提示都带数学推导过程。产线工程师反馈“现在看报错信息比看设计手册还快。”经验之谈Text-to-CAD项目最大的成本从来不在模型开发而在领域知识沉淀。我们花了47%的工时整理机械制图国标GB/T 4457-4460、23%工时梳理各车间加工工艺约束、仅20%工时写代码。如果你的团队没有资深机械工程师全程参与这个项目99%会倒在第四道坎之前。5. 下一步该往哪走——聚焦“可验证性”而非“通用性”的务实演进回头看这半年的实践我越来越确信Text-to-CAD的破局点根本不在“让AI学会所有CAD操作”而在于把人类设计师最不愿干、最容易错、但又必须干的那20%重复劳动用可验证的方式自动化。所谓“可验证”是指每个生成步骤都有数学证明、每个参数变更都有影响范围分析、每个错误都有归因路径。这听起来保守但恰恰是工业软件的生命线。我们接下来的重点已经转向三个具体方向第一构建可验证的几何语义图谱。不再满足于“M6螺纹孔”这种扁平标签而是建立多层语义网络物理层螺纹牙型60°等边三角形、公称直径6mm、螺距1.0mm工艺层攻丝深度≥1.5×直径、底孔直径5.8mm、表面粗糙度Ra1.6装配层配合公差H7/g6、拧紧力矩6.5N·m当用户输入“M6螺纹孔”系统不仅能生成模型还能同步输出工艺卡片和装配指导书。这已在某电机厂试点将新品试制周期缩短了38%。第二开发“反向Text-to-CAD”能力。即把现有CAD模型自动转为自然语言描述用于设计审查。比如打开一个复杂支架模型系统自动生成“该零件为铝合金6061-T6材质主体为长200mm×宽150mm×高30mm底板顶部有4个M5螺纹孔中心距边缘20mm底部有2个φ12通孔中心距边缘30mm所有边缘倒角C1。” 这解决了跨部门沟通中“图纸看不懂”的老大难问题。技术上我们用SolidWorks API遍历FeatureManager提取每个特征的参数和约束再用模板引擎生成描述准确率已达92.4%。第三打通PLM系统的变更影响分析。当用户修改“底板厚度从15mm改为18mm”时系统不仅要更新模型还要自动分析是否影响与之装配的其他零件如轴承座高度是否需同步调整是否超出原工艺卡的加工能力如立铣刀最大切深是否够是否改变重量和重心影响运输包装方案这需要与PLM系统的BOM和工艺路线模块深度集成目前在POC阶段但已验证其逻辑闭环的可行性。最后分享一个真实的体会上周某导师带着本科生用我们的系统做课程设计。一个学生输入“做一个齿轮箱盖长300宽200高50中间有φ80通孔四周8个M8螺栓孔孔中心圆直径260盖板厚度15”系统3秒生成模型。他接着输入“把φ80孔改成沉头孔沉头直径120深度10”模型实时更新。当他把文件发给机加工老师时老师回复“参数全对明天就安排加工。”那一刻我突然明白Text-to-CAD的终极价值不是炫技而是让“把想法变成实物”这件事少一点等待多一点笃定。