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”，系统需验证20+20 ≤ 120且20+20 ≤ 80是否成立。但真实场景更复杂：“孔中心圆直径155，孔数8，相邻孔中心夹角45度”——这涉及三角函数计算。我们没有自己造轮子，而是集成开源稀疏矩阵求解器SuiteSparse，将所有尺寸约束转化为线性/非线性方程组：
# 示例：八孔均布约束 # 设孔中心圆半径R=155/2=77.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配置文件管理，产线工程师可随时调整。现在，系统生成的模型自带完整GD&T注释，工艺员打开就能直接编制工序卡。
4.3 坎三：版本兼容性黑洞——SolidWorks 2022生成的模型，2024打不开？
这是最反直觉的坑。我们曾为客户生成一批模型，客户用SolidWorks 2024打开时，所有参数化特征树全变成“冻结特征”（Frozen Features），无法编辑。查日志发现：2024版API在创建FeatureExtrusion3时，默认启用了“增强性能模式”，该模式会禁用部分历史记录功能。而我们的模板库是用2022版录制的宏生成的，特征间存在隐式依赖。
终极解法是：所有特征创建必须显式指定UseAutoCalculation=False，并在特征树末尾插入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的终极价值，不是炫技，而是让“把想法变成实物”这件事，少一点等待，多一点笃定。
