1. 从一句标题说起AI驱动3D建模到底在做什么第一次看到“用AI驱动3D建模软件绘制3D数模及2D图纸”这个说法我脑子里冒出来的第一个念头是这不就是把自然语言变成零件吗后来真正动手把这条链路跑通之后才发现事情比想象中更有意思也比想象中更琐碎。它解决的核心问题其实很朴素——把“人对着软件点菜单”变成“人对着AI说需求AI去操作软件”。SOLIDWORKS这类参数化建模工具本质上是一个“命令参数约束”的集合体而AI大模型擅长的事情恰好是理解意图、拆解步骤、生成结构化指令。两者一结合就出现了所谓的AI驱动建模。这篇文章适合三类人看。第一类是天天泡在SOLIDWORKS里画零件、出工程图的机械工程师你可能已经厌倦了重复性的拉伸、打孔、标注想看看能不能让AI替你干一部分第二类是对AI Agent、MCP这些概念感兴趣但还没找到具体落地场景的技术爱好者第三类是想了解“AICAD”这条赛道到底走到哪一步的产品和创业者。不管你是哪一类我都会把整条链路的原理、工具选型、实操步骤、踩过的坑掰开揉碎讲清楚。需要先明确一个前提目前AI还不能凭空生成一个完全可制造、带完整工程约束的3D数模。它擅长的是“根据你的描述生成建模脚本”或者“调用软件API执行一系列操作”最终的几何质量仍然依赖你的需求描述精度和AI对CAD逻辑的理解程度。所以别指望一句话就出来一个行星齿轮箱但让它帮你画个带孔法兰、生成标准件、批量出图是完全可行的。2. 整体方案设计为什么选MCP而不是直接调API2.1 三种技术路线的取舍要把AI和SOLIDWORKS连起来市面上大致有三条路可走我逐一试过说说各自的真实体验。第一条路是直接调用SOLIDWORKS API。SOLIDWORKS提供了COM接口用Python的pywin32或者C#都能调。你写一段脚本AI生成这段脚本然后执行。这条路最直接但问题也很明显API调用是“硬编码”的每次需求变了脚本就得重写。而且SOLIDWORKS API的文档虽然全但参数极其繁琐AI很容易在某个枚举值上写错导致整个脚本报错。我试过让AI直接生成CreateCircle的调用十次里有三次参数顺序搞反。第二条路是用宏录制AI改写。你先手动操作一遍录成VBA宏然后让AI去改宏里的参数。这条路对新手最友好因为宏是“真实操作”的记录逻辑不会错。但缺点是宏的复用性差一个宏只能干一件事而且VBA的可读性对AI来说也不算友好改着改着就容易出语法错误。第三条路就是MCPModel Context Protocol。MCP是什么简单说它是一个让AI模型和外部工具“对话”的协议。你可以把它理解成一个“翻译官”AI说“我要在法兰上打四个孔”MCP负责把这句话翻译成SOLIDWORKS能听懂的一系列API调用。MCP的核心价值在于标准化——它定义了一套工具描述格式AI不需要知道SOLIDWORKS API的具体细节只需要知道“有一个叫create_hole的工具参数是位置和直径”。这样一来AI的负担大大减轻出错率也明显下降。我最终选择MCP作为主方案原因有三点。第一可扩展性。今天接SOLIDWORKS明天想接Altium Designer做PCB后天想接Unreal做场景只要各自实现MCP ServerAI端的逻辑不用大改。第二容错性。MCP Server可以在内部做参数校验和异常处理比如AI传了一个负数直径Server可以直接拒绝并返回错误信息AI收到后会自动修正。第三生态趋势。现在越来越多的工具在往MCP上靠包括一些主流的AI编程助手和设计软件跟着趋势走不会错。2.2 整体架构长什么样整条链路我画成文字版就是用户自然语言 → AI大模型理解意图、拆解任务→ MCP Client转发工具调用→ MCP Server对接SOLIDWORKS→ SOLIDWORKS API执行建模→ 返回结果。这里面有几个关键角色。AI大模型我试过几个国内外的都有核心要求是支持Function Calling或者Tool Use否则它没法输出结构化的工具调用请求。MCP Client通常是AI助手自带的比如某些支持MCP的IDE插件或者聊天客户端。MCP Server需要自己写这是整个方案里工作量最大的部分但也是最值得投入的。SOLIDWORKS这边我建议用SOLIDWORKS 2023及以上版本因为新版本的API对Python的支持更好而且稳定性明显提升。老版本比如2020在频繁调用API时容易崩溃我踩过这个坑后面会细说。3. 核心细节拆解MCP Server到底怎么写3.1 工具定义把SOLIDWORKS能力“翻译”给AI听MCP Server的核心是工具定义。你得告诉AI“我这里有这些工具每个工具叫什么名字、干什么用、需要什么参数。”这个定义通常用JSON Schema来描述。举个例子一个最简单的“创建拉伸圆柱”工具定义大概是这样{ name: create_cylinder, description: 在SOLIDWORKS中创建一个圆柱体拉伸特征, parameters: { type: object, properties: { diameter: { type: number, description: 圆柱直径单位毫米 }, height: { type: number, description: 拉伸高度单位毫米 }, plane: { type: string, description: 基准面可选Front、Top、Right, enum: [Front, Top, Right] } }, required: [diameter, height, plane] } }这个定义看起来简单但里面有几个门道。第一单位必须写死。SOLIDWORKS内部用的是米但工程师习惯用毫米如果你不写清楚AI可能会传0.05米而不是50毫米结果出来一个肉眼看不见的圆柱。第二枚举值要列全。基准面如果只写“字符串”AI可能会传“front plane”或者“前视基准面”导致匹配失败。第三描述要用人话。AI是根据描述来判断什么时候调用这个工具的描述写得越清楚它的调用准确率越高。我一开始偷懒工具描述写得很简略结果AI经常把“打孔”和“拉伸切除”搞混。后来我把每个工具的描述都写成“什么场景下用这个工具”准确率立刻上去了。3.2 参数校验别让AI的“手滑”毁掉你的模型AI不是神它经常会传一些离谱的参数。比如你让它画一个直径10毫米、高500毫米的圆柱它可能理解成直径500、高10。所以MCP Server里必须做参数校验。我的做法是设一个“合理范围”。直径小于0.1毫米或者大于1000毫米的直接拒绝高度超过500毫米的返回警告并让AI确认。这个逻辑写在Server里AI收到错误信息后会重新调整参数。实测下来加了校验之后建模失败率从30%降到了5%以下。还有一个细节单位换算。我在Server里统一把AI传来的毫米转换成米再传给SOLIDWORKS API。这样AI端永远只用毫米不用操心单位问题。3.3 异常处理SOLIDWORKS崩溃了怎么办SOLIDWORKS是个“脾气不太好”的软件尤其是在被API频繁调用的时候。我遇到过好几次AI连续调了十几个建模命令SOLIDWORKS突然卡死然后弹出一个“error 1714”或者“CEF for SOLIDWORKS”相关的错误。后来查资料才知道这是SOLIDWORKS的CEFChromium Embedded Framework组件在频繁调用时出的问题。解决办法有两个。第一加延迟。每个API调用之间强制sleep 0.5秒给SOLIDWORKS喘息的时间。第二分批执行。如果AI一次生成了20个操作不要一口气全发过去分成5个一批每批之间等2秒。这两个措施加上之后崩溃频率大幅下降。另外MCP Server里要捕获COM异常。SOLIDWORKS API抛出的异常如果不处理整个Server会挂掉。我的做法是用try-except包住每个API调用出错时返回一个结构化的错误信息给AI让AI决定是重试还是换方案。4. 实操过程从零跑通一个法兰建模4.1 环境准备与依赖安装先说环境。我用的组合是Python 3.10 SOLIDWORKS 2023 pywin32 一个支持MCP的AI客户端。Python版本不要用3.12某些COM库还没适配我用3.12的时候遇到过pywin32安装失败的问题。安装依赖很简单pip install pywin32 mcpmcp是MCP协议的Python SDK如果你用的客户端有自己的SDK按它的文档来。SOLIDWORKS这边不需要额外装什么只要确保它已经正常启动过一次并且没有弹窗拦截。注意SOLIDWORKS第一次被API调用时可能会弹出一个“是否允许程序访问”的对话框。这个对话框必须手动点掉否则API调用会一直卡住。建议在正式跑之前先手动用Python连一次SOLIDWORKS把这个弹窗处理掉。4.2 连接SOLIDWORKS并创建文档连接SOLIDWORKS的代码大概长这样import win32com.client import pythoncom pythoncom.CoInitialize() sw_app win32com.client.Dispatch(SldWorks.Application) sw_app.Visible True sw_doc sw_app.NewDocument(C:\\ProgramData\\SOLIDWORKS\\templates\\Part.prtdot, 0, 0, 0)这里有几个坑。第一模板路径。不同版本的SOLIDWORKS模板路径不一样2023版默认在C:\ProgramData\SOLIDWORKS\SOLIDWORKS 2023\templates\下面。如果你不确定可以在SOLIDWORKS里手动新建一个零件然后看它的模板路径。第二CoInitialize。多线程环境下必须调用否则会报“CoInitialize has not been called”的错误。第三Visible。设成True方便你观察建模过程调试阶段很有用正式跑的时候可以设成False速度快一些。4.3 用AI生成建模指令并执行环境通了之后就可以让AI干活了。我在AI客户端里输入“帮我画一个法兰外径100毫米内径40毫米厚度10毫米在直径80毫米的圆周上均匀分布6个直径8毫米的孔。”AI收到之后会先拆解任务第一步创建外圆拉伸第二步创建内圆拉伸切除第三步创建孔阵列。然后它会依次调用MCP Server里的工具。整个过程大概是这样调用create_cylinder参数diameter100, height10, planeFront调用create_cylinder_cut参数diameter40, height10, planeFront调用create_hole_pattern参数hole_diameter8, count6, pitch_circle_diameter80每个工具调用之间MCP Server会做参数校验、单位换算、异常捕获。如果某一步失败AI会收到错误信息并尝试修正。比如有一次AI把孔的数量传成了6.0浮点数Server校验时发现不是整数返回错误AI自动改成6重新调用。实测下来一个简单的法兰从输入文字到模型生成大概需要15到30秒。复杂一点的零件比如带拔模斜度的壳体可能需要一两分钟而且中间可能需要人工干预几次。4.4 从3D数模到2D图纸的自动出图3D模型建好之后下一步是出2D工程图。这一步的自动化程度比建模低一些因为工程图涉及视图布局、尺寸标注、公差标注AI目前还很难完全理解“这个尺寸应该标在哪里”这种工程习惯。我的做法是半自动让AI生成主视图、俯视图、侧视图和剖视图尺寸标注由AI生成初稿然后人工调整。具体来说MCP Server里加一个create_drawing工具参数包括模型路径、视图类型、图纸模板。AI调用之后SOLIDWORKS会自动生成视图但尺寸标注需要额外调用insert_dimensions工具。这里有个技巧让AI参考已有的工程图模板。如果你有一个标准的工程图模板里面已经预设好了尺寸样式、公差等级、标题栏AI生成的图纸会规范很多。我试过让AI从零开始标注结果尺寸线交叉、文字重叠惨不忍睹。后来我把公司标准模板喂给AI让它“照着这个风格标”出来的图纸至少能看了。5. 常见问题与排查技巧实录5.1 SOLIDWORKS崩溃与CEF错误这是最高频的问题。表现是API调用到一半SOLIDWORKS无响应然后弹出“error 1714”或者“the older version of CEF for SOLIDWORKS applications cannot be removed”之类的错误。根本原因是SOLIDWORKS的CEF组件在频繁调用时内存泄漏。我的解决方案是定期重启SOLIDWORKS。每执行50次API调用就主动关闭SOLIDWORKS再重新打开。虽然麻烦但比崩溃后丢失数据强。另外把SOLIDWORKS的“自动恢复”功能打开万一崩了还能找回一部分。还有一个偏方删除注册表里的CEF相关项。具体路径是HKEY_CURRENT_USER\Software\SolidWorks\CEF删掉之后SOLIDWORKS会重建。但这个操作有风险建议先备份注册表。我试过几次确实能解决一部分CEF错误但不是万能的。5.2 AI生成的参数不合理AI经常犯的错包括直径传负数、高度传0、孔的数量传小数、基准面传中文。这些都需要在MCP Server里做校验。我整理了一个校验规则表参数类型校验规则错误处理直径0.1 ~ 1000 mm超出范围返回错误提示AI调整高度0.1 ~ 500 mm超过500返回警告让AI确认孔数量正整数1 ~ 100非整数或超范围直接拒绝基准面Front/Top/Right其他值返回可选列表角度-360 ~ 360超出范围取模这张表是我踩了无数次坑之后总结出来的基本上覆盖了80%的参数错误。5.3 MCP连接失败与工具调用超时MCP Client和Server之间的连接有时候会断。表现是AI说“我正在调用工具”然后就没下文了。排查思路是先看Server的日志确认有没有收到请求再看Client的日志确认请求有没有发出去。大部分情况下是Server端的SOLIDWORKS卡住了导致请求堆积。解决办法是加超时机制。每个工具调用设置30秒超时超时后返回错误给AI让AI决定重试还是放弃。另外Server端要限制并发请求数我设的是最多同时处理3个请求多了就排队。5.4 2D图纸标注混乱AI生成的工程图标注经常出现尺寸线交叉、文字重叠、公差漏标。这个问题目前没有完美的解决方案我的做法是分两步走第一步让AI只生成视图不标注第二步人工标注关键尺寸AI辅助标注次要尺寸。这样虽然自动化程度降低了但图纸质量有保障。另外可以训练AI学习你公司的标注规范。把过去半年的工程图喂给AI让它总结标注习惯比如“孔位尺寸标在俯视图”“公差等级默认IT7”。这个训练过程需要一些时间但一旦训好后续的标注准确率会明显提升。6. 工具选型与扩展思路6.1 AI大模型怎么选不是所有大模型都适合干这个活。核心要求是支持Tool Use或者Function Calling而且对JSON Schema的理解要准确。我试过几个模型有的虽然支持Tool Use但生成的参数经常缺字段有的理解能力很强但调用工具时犹豫不决该调的时候不调。我的建议是选专门针对代码和结构化输出优化过的模型。这类模型对参数格式的敏感度更高出错率更低。另外如果模型支持“多轮工具调用”也就是一次对话里连续调用多个工具效率会高很多。我实测下来支持多轮调用的模型完成一个法兰建模的时间比不支持的要快40%左右。6.2 MCP Server的扩展方向现在MCP Server只接了SOLIDWORKS但架构是通用的。后续可以扩展的方向很多。比如接Altium Designer做PCB设计AI根据原理图自动布局接Unreal Engine做场景搭建AI根据描述生成地形和光照接Unity3D做模型导入和材质设置。这些软件都有API只要各自实现MCP ServerAI端的逻辑可以复用。还有一个有意思的方向是多AI协作。一个AI负责理解需求一个AI负责生成建模指令一个AI负责校验结果。三个AI通过MCP互相通信形成一个流水线。我试过简单的双AI协作一个画图一个检查确实能减少错误但延迟也增加了。这个方向还在探索阶段适合喜欢折腾的人。6.3 性能优化的一点经验最后说几个性能优化的点。第一缓存常用操作。比如创建基准面、设置单位这些操作每次建模都要做可以缓存起来不用重复调用API。第二批量操作。如果AI要创建10个相同的孔不要调10次API而是调一次API传一个数组。SOLIDWORKS API支持批量操作速度快很多。第三异步执行。MCP Server可以用异步IO一个请求在等SOLIDWORKS响应的时候另一个请求可以继续处理。但要注意SOLIDWORKS API本身不是线程安全的异步操作要加锁。我在实际使用中发现优化之后一个中等复杂度零件大概20个特征的建模时间从3分钟降到了1分钟左右。虽然还是比手动建模慢但考虑到AI可以24小时干活而且不用休息这个效率已经可以接受了。提示如果你打算在生产环境用这套方案建议先在小批量、低风险的零件上试跑。AI建模的可靠性还在逐步提升中关键零件还是人工把关比较稳妥。踩过几次坑之后我最大的体会是AI驱动3D建模不是要取代工程师而是把工程师从重复劳动里解放出来。那些标准件、常用结构、批量出图的活交给AI干真正需要工程判断、工艺考量、创新设计的地方还是得人来。这个边界目前还很清晰但随着时间的推移AI能干的活会越来越多。早点把这套工具链跑通早点积累经验等风来的时候你已经站在跑道上了。