AI自然语言驱动SolidWorks建模：两大方案实测对比

上个月一个做非标自动化的老朋友跟我吐槽他每天有一半时间不是在真正设计而是在重复画法兰、改尺寸、调孔位这种毫无创意的工作。他半开玩笑地问我能不能让 AI 听懂人话直接对着 SolidWorks 说一句法兰厚度改成 15孔数改成 8模型就自动更新。这句话把我拽进了一个实测项目用 Claude Code 和 DeepSeek Harness 两条路线把自然语言直接接到 SolidWorks 的建模流程里。折腾了两个周末之后我把两套方案的原理、接线链路、实测数据和翻车现场整理成这篇对比评估想给在 CAD 自动化边缘试探的工程师们一个真实参考。这篇文章适合两类人一类是天天被重复建模折磨的机械工程师另一类是想把 AI Agent 落地到工业软件里的开发者。1. 为什么用嘴画图在 SolidWorks 上特别难先说结论这不是简单地把 ChatGPT 接到 SolidWorks 上就能解决的问题。真正动手之后你会发现自然语言到三维模型之间横着的东西比大多数 AI 应用要硬核得多。1.1 SolidWorks 的自动化通道COM API 与宏录制SolidWorks 给开发者留的自动化接口是一套传统 COM API普通设计师可能一辈子都用不到但它确实是外部控制软件的唯一正经通道。这套 API 的对象模型大致分三层最外层是ISldWorks代表 SolidWorks 应用程序本身通过它可以打开或新建文档得到ModelDoc2再往下是SketchManager管草图和FeatureManager管特征。你让 AI 画图本质上就是让 AI 跨过这三层对象把自然语言翻译成一段又一段 API 调用。很多人学这套 API 是从宏录制开始的。SolidWorks 的宏录制功能会把你的每一步操作翻译成 VBA 代码这确实是理解 API 的好教材。但录出来的代码极其啰嗦因为录制器几乎记录了你鼠标点过的每一个选中状态、每一个临时辅助线一个简单的画圆拉伸操作动辄生成几百行代码。AI 拿到这种宏文件经常困在大量无意义的选择集代码里不知道该删什么、不该删什么。所以实际把 AI 接到 SolidWorks 上最稳的路线是外部进程通过 COM 方式创建或连接 SolidWorks 实例然后直接调用 API。启动实例最常规的方式是使用 ProgID 字符串SldWorks.Application从系统注册表里定位到安装的程序然后设置窗口可见、新建文档、在文档上画草图、拉伸特征。听起来不复杂但里面每一个环节都藏着能让程序直接崩掉的坑后面我会专门讲。1.2 自然语言到三维模型之间的三座大山第一座大山是语义到特征序列的拆解。人话里一句中间镂空在建模流程里其实是一整套操作选择草图平面、画内孔轮廓、退出草图、选择拉伸切除、指定深度和方向。LLM 必须把一个高度模糊的自然语言描述拆成一组有序且符合建模逻辑的 API 调用。这比写普通代码难因为 CAD 建模的特征顺序有严格约束顺序错了模型就废了。第二座大山是状态依赖。三维建模是一个典型的状态累积过程特征 A 失败特征 B 的参考平面就没了特征 C 更是无从谈起。普通代码生成错了可以局部重写但建模脚本一旦在某一步出错后续所有特征全崩。这个特性决定了一次生成代码然后完事的聊天式 AI 根本走不通必须有运行—看报错—修改—再运行的闭环。这也是我在评估两套方案时最看重的一点。第三座大山是单位制和隐性上下文。SolidWorks 的默认模板可能是英制英寸而用户和 AI 几乎总是按公制毫米思考。AI 生成的尺寸如果不显式指定单位制画出来的零件体积可能差 25.4 的三次方倍视觉上就是一个一公里大的零件。这种错误不跑一遍根本发现不了但跑一遍可能已经浪费了 10 分钟。2. Claude Code 操控 SolidWorks 的实现链路拆解我选择从 Claude Code 入手是因为它天然具备编程 Agent 的反馈闭环。在测试之前我先定义了一个统一的基准任务方便后续做公平对比生成一个法兰盘模型外径 80 毫米内径 40 毫米厚度 12 毫米端面有 6 个均布直径为 5 毫米的通孔孔心到中心的距离是 35 毫米。这个任务包含两个草图、拉伸、圆周阵列、切除等多个典型特征足够暴露问题。2.1 为什么是 Claude Code终端 Agent 的反馈闭环Claude Code 是 Claude 系列模型在终端里的一个编程 Agent 形态它做的事情不是聊天而是像一个人一样在项目目录里读文件、改文件、执行命令、看输出、根据报错继续改。这个能力用在 SolidWorks 二次开发上恰好打在要害上。SolidWorks 的 COM API 属于那种老而硬的技术参数多、文档少、版本差异大。即便模型能力再强也不可能单靠记忆一次性写出一份完美可编译的建模代码。Claude Code 的价值在于它把编译—运行—读错误—修正这个过程自动化了。我实测中最直观的感受是你只要把任务描述发出去它就会在自己的循环里折腾编译失败就翻代码运行报错就看日志直到跑通为止。它不烦也不累这正是干这活的理想形态。我在测试中走的数据链路是自然语言描述 → Claude Code 生成 C# 控制台工程 → dotnet build 编译 → 运行 exe → exe 通过 COM 连接 SolidWorks → SolidWorks 里自动建模。中间每一步的输出和报错都回到 Claude Code 的上下文里作为下一轮修正的依据。2.2 最小可用接线C# 宿主程序 COM 调用最简单的接线方式是让 Claude Code 写一个 C# 控制台程序再用Interop.SolidWorks程序集调用 COM API。核心代码骨架大概是这样的using SolidWorks.Interop.sldworks; using SolidWorks.Interop.swconst; class SolidWorksHost { [STAThread] static void Main(string[] args) { ISldWorks swApp (ISldWorks)Activator.CreateInstance( Type.GetTypeFromProgID(SldWorks.Application)); swApp.Visible true; string template C:\ProgramData\SolidWorks\SOLIDWORKS 2020\templates\Part.prtdot; ModelDoc2 doc (ModelDoc2)swApp.NewDocument(template, 0, 0, 0); SketchManager sk doc.SketchManager; sk.InsertSketch(true); // 在草图里画轮廓、加约束、退出草图 // 调用 FeatureManager 做拉伸、切除、阵列 } }这份代码是骨架示意真实生产环境还需要判空、异常处理、设置单位制等一堆细节。我特意让 Claude Code 从零开始写的时候它第一次编译就报错了项目文件里没有正确引入Interop.SolidWorks。然后它自己查了编译输出补上了引用第二次运行时报模板路径不存在因为我的 SolidWorks 版本和它猜测的路径不一致第三次终于画出来了但拉伸方向反了模型往负方向长第四次才完全正确。整个过程我没动过一行代码只在 prompt 里补了一句模板路径去注册表里查。这就是 Claude Code 的核心优势对写代码—跑代码—改代码这个循环的掌控力非常强。2.3 更轻量的技巧让 AI 改录制宏别从零写 API如果你不想被 COM 引用和编译环境折腾我强烈建议试试另一条更轻量的路让 AI 改宏而不是从零写 API。做法是先在 SolidWorks 里手动做一个和你想做的模型最接近的参考件同时打开宏录制录完之后把宏文件丢给 Claude Code告诉它把这段宏改成参数化版本直径用变量 D孔数用变量 N。这里有个很多人不知道的细节SolidWorks 宏保存格式有两种默认的.swp是 VBA 工程的二进制格式AI 根本读不了要选.swb格式或者从 VBA 编辑器里导出.bas源文件再交给 AI。我第一次就让 Claude 读.swp结果它只是对着乱码猜逻辑非常痛苦。改好的宏有几种执行方式最简单的是在 SolidWorks 的宏工具栏里手动运行也可以用命令行/m参数让 SolidWorks 启动时自动运行宏但不同版本对这个参数的支持时好时坏新版里经常失效最稳的是写一个小宿主程序通过swApp.RunMacro指定宏文件路径和过程名来调用。我实测下来第三种方式的成功率最高也方便把参数传给宏。这条路线最大的价值在于录制的宏里的 API 调用是官方真实用法AI 只需要理解、修改、组合而不是凭空想象。它猜错 API 的概率大幅降低相当于给 AI 发了一份标准答案。2.4 统一基准任务实测法兰盘生成表现我的基准任务Claude Code 跑了 4 轮才成功全程大约 8 分钟。前 3 轮的错误分别是缺引用、模板路径错误、拉伸方向反向。第 4 轮生成的模型我仔细检查过外径 80、内径 40、厚度 12、6 个均布通孔尺寸全部正确草图处于完全定义状态特征树结构也还算清晰。但我也测了它不擅长的东西。比如让它直接生成一个带复杂曲面的吹风机外壳它生成的特征树非常混乱出现了很多多余的辅助基准面和裁剪特征。又比如让它做一个简单的三件套装配体配合关系经常出现过定义或欠定义需要人工介入。我的判断是Claude Code 在中低复杂度的零件建模上已经达到可用状态但在复杂曲面和装配体配合上离真正的生产力工具还有距离。3. DeepSeek Harness 方案的核心机制与实测体验第二套方案我选的是 DeepSeek Harness。这块的定位跟 Claude Code 很不一样体验也完全不同。3.1 DeepSeek Harness 到底是什么模型外面的鞍具Harness这个英文词直译是鞍具在 AI Agent 领域它指代的是套在模型外面的一层控制框架。你可以把大模型想象成一匹马Harness 就是缰绳和鞍具负责决定模型在什么时机调用什么工具、按什么顺序执行、拿到工具输出后如何反馈到上下文。社区里常见的 DeepSeek Harness 形态是一个 Python 环境加一套工具注册机制支持执行 Python 脚本、跑 shell 命令、读写文件、调用外部 API模型在循环里自主决定下一步动作。这跟 Claude Code 的设计取向是两回事。Claude Code 是一个开箱即用的产品你安装完就能干活DeepSeek Harness 更像一盒零件框架本身给了你工具管理和上下文的机制但接什么工具、怎么定义工具的输入输出都得自己组装。它的门槛明显更高但自由度也更高。对 SolidWorks 这种场景这就意味着你需要自己动手把控制 SolidWorks这件事包装成 Harness 能用的工具。3.2 Harness 接线 SolidWorksPython comtypes 工具化我给你的思路是用 Python 加 comtypes 库来操作 COM 接口。相比 C# 需要提前引用特定版本的 Interop 程序集Python 配合 comtypes 是动态生成接口绑定代码更短版本适配也更灵活。核心代码大概是这样的import comtypes.client sw comtypes.client.CreateObject(SldWorks.Application) sw.Visible True part_template rC:\ProgramData\SolidWorks\SOLIDWORKS 2020\templates\Part.prtdot doc sw.NewDocument(part_template, 0, 0, 0) sk doc.SketchManager # 在这里画草图、加约束 # 然后通过 doc.FeatureManager 做拉伸、切除实际使用中我会把在 SolidWorks 里执行一段 Python 脚本封装成 Harness 的一个工具函数。工具的输入是脚本文件路径返回值是脚本运行日志。随后 DeepSeek 模型的任务就变成了不断修改这段 Python 脚本、调用工具执行、根据日志修下一版。这时的关键技巧是把单位制、模板路径、建模规范都写进一份环境文档让模型每次开始执行前强制读取。DeepSeek 在 SolidWorks 这种冷门 API 上的先验知识明显弱于 Claude给它一份使用手册能显著减少低级错误。这相当于给模型配了一个本地知识库实话说这一步不做DeepSeek Harness 方案的成功率会低得让人想放弃。3.3 统一基准任务实测便宜但多跑了几轮同样的法兰盘基准任务DeepSeek Harness 用了大约 7 轮才成功耗时约 15 分钟比 Claude Code 多折腾了不少。前几轮的失败主要集中在这几种圆周阵列的实例数量写成 5 而不是 6、把英寸当成毫米、重复创建已经存在的草图导致特征冲突。但它在成本上的优势非常突出。我用 DeepSeek API 跑完整轮测试费用大概只有 Claude Code 方案的几分之一。API 响应速度也很快几乎感觉不到等待。而且因为所有工具和上下文都是自己控制的我可以随时往环境文档里补充规则模型下一轮就会遵守这种可定制性是 Claude Code 给不了的。它还暴露出一个 Agent 框架的共性问题长会话跑久了之后模型会忘记前面已经建过什么特征。比如它明明已经做了一个拉伸下一轮又在同一位置画一个一模一样的草图。我的解决办法是让 Harness 每完成一步就维护一个model_state.json把当前已有的特征列表、当前草图平面、已知尺寸变量塞回上下文。这一步之后连续跑几十轮都不太会出重复建模的问题。4. 横评六个维度看懂两套方案的真实差距4.1 关键维度对比表把我实测下来的感受整理成一张表方便直接对照维度Claude CodeDeepSeek Harness上手门槛低安装后基本开箱即用高需要自己搭建工具链自然语言理解强复杂意图拆解到位中等容易遗漏隐含约束代码生成质量高API 参数记得更准中等参数位经常搞错自我纠错能力内置完整闭环需要自己写工具和反馈机制扩展定制性比较有限强可以完全按自己的流程来运行成本偏高低部署方式依赖官方服务可用 API也可考虑本地模型适合人群不想折腾的工程师有开发能力的工具党这张表的信息量在于它们不是同一个维度上的竞争者Claude Code 像是买一台配置好的工作站DeepSeek Harness 像是一堆散件加一张安装说明书。并不是所有任务都能互相替代。4.2 三个最容易被误判的地方第一不少人以为 DeepSeek Harness 只能接 DeepSeek 模型。其实 Harness 本身就是模型无关的控制层换模型在理论上完全可行只是默认针对 DeepSeek 优化。反过来Claude Code 是一个封闭产品模型和工具链被绑定死在官方体系里你想换底模或者改交互逻辑基本没戏。第二以为生成宏/生成脚本就是终点。实测下来AI 把画图的代码写出来只占整个工作量的一半另一半是让它把代码在真实的 SolidWorks 环境里跑起来并正确处理报错。谁在这个执行闭环上做得更好谁才是真正可用的方案。Claude Code 赢在这一层。第三成本不能只看单价。DeepSeek 便宜但它循环次数多在复杂任务上总成本差距没有单价差距那么大。反过来Claude Code 单轮质量高、翻车少但它的 token 单价摆在那里跑一个复杂模型迭代十几轮费用也不低。如果只是简单零件DeepSeek Harness 的绝对优势非常明显。4.3 稳定性与风险SolidWorks 进程是会死的这里必须说一个容易被低估的问题SolidWorks COM 调用不是云服务那种优雅的 REST API它是一个会直接崩溃、卡死、无响应的本地桌面软件。两套方案在测试中都遇到过 SolidWorks 进程挂掉的情况。Claude Code 里的 exe 调用如果遇到断电似的退出进程不会自己收拾DeepSeek Harness 里的 Python 脚本如果抛异常SolidWorks 实例可能还残留在后台占着数百 MB 内存。我的习惯是每跑完一个模型就强制把 SolidWorks 进程杀掉下一个任务新开实例。批量建多个模型时不要用一个 SolidWorks 实例连续跑几十个模型那种做法程序会越来越慢最后直接内存溢出。这两条原则不针对模型是针对工业软件本身的保命经验。5. 从画得出到画得对参数化建模的细节与坑5.1 让 AI 代码直接崩溃的 COM 细节如果你用 C# 方案记得Main方法上必须加[STAThread]特性。COM 对象对线程模型敏感SolidWorks 的 COM 接口很多是单线程的控制台程序默认的 MTA 线程模式会导致创建对象返回null或者程序直接崩掉。这行特性就是最简单也最容易漏的一行。模板路径也是个高频坑。不同版本 SolidWorks 的零件模板路径不一样新版本用的还是.prtdot后缀但安装方式不同路径可以五花八门。最稳的做法是从注册表里查 Install Directory而不是写死路径。我实际测下来的经验让 AI 自己写死模板路径10 次里有 4 次是错的。单位制是另一座大山。SolidWorks 新建文档时用的是模板自带的单位如果模板是默认英制AI 按公制尺寸画出一个标称 80 毫米的圆实际是 80 英寸。这个错误隐蔽而且致命因为特征树上一看尺寸好像是对的实际零件尺寸荒谬。我的规则是让 AI 在生成代码前先调用 API 把文档单位切到 MMGS 毫米克秒制并且在脚本顶部变量区用注释标明所有尺寸单位为毫米。5.2 给 AI 立规矩一份我实测有效的建模规范两套方案里我都放了一份建模规范文档。Claude Code 项目里它对应CLAUDE.md文件DeepSeek Harness 里它是环境文档让模型每轮强制读取。这份规范不要写废话直接列硬性要求所有关键尺寸放到脚本顶部变量区改这个区域就能重生成整个模型。草图必须完全定义SolidWorks 状态栏显示草图是黑色不允许出现蓝色欠定义。一个特征一个步骤不要尝试用一步操作完成多个布尔运算。特征名和草图名必须使用有意义的前缀例如SK_BoltHole、FEAT_Chamfer_1。单位统一使用公制毫米MMGS如果在英制模板下工作先切换单位再开始建模。拉伸方向在生成前要通过当前草图平面法向来判断不要盲目假定正向。保存文件用 SLDPRT 格式需要交换时额外导出 STEP。实测里加了这份规范之后两套方案的成功率都有肉眼可见的提升特别是 DeepSeek Harness 那一侧效果大得惊人。模型从自由发挥变成照章办事很多低级错误直接绕开了。5.3 自动化验证模型画完怎么判断对了AI 画完模型不代表万事大吉要判断模型对了我建议把验证也做成自动化步骤。第一是体积和质量校验。调用 SolidWorks 的质量属性 API读取体积和理论值比对。比如法兰盘的体积可以预先用公式算出来误差超过 1% 就判定为异常。第二是特征树解析检查模型里是否存在重建失败的错误特征有没有超出预期的多余特征。第三是参数回归测试修改一个变量比如把厚度从 12 改成 20重新生成模型确认能顺利重建且没有报错。如果 AI 生成的模型参数一改就崩说明它的建模方式没有真正参数化只是碰巧画出来了。在 DeepSeek Harness 里我把这三步都封装成了验证工具让模型自主执行、自主判断是否通过。这样整个链路变成了生成—执行—验证—修正的完整关卡而不是生成完就跑步收工。6. 选型建议两套方案各吃哪碗饭6.1 优先选 Claude Code 的场景如果你是一个没有编程基础的机械工程师我建议你别犹豫直接选 Claude Code。它在安装配置上省心太多装好之后你只需要在终端里描述需求它自己会处理编译、运行、报错循环。对于中低复杂度的零件建模它目前已经能比较可靠地交付跟它配合更像雇了一个会写代码的建模助理。还有一个典型场景是快速验证你想知道某个模型的某个特征能不能用某条 API 实现直接在 Claude Code 里问它马上给你实验不需要你亲手去翻那本又厚又乱的 API 文档。6.2 优先选 DeepSeek Harness 的场景如果你本身会 Python目标是在 SolidWorks 上做批量参数化建模、家族化零件扫描、自动化出图DeepSeek Harness 是更对路的工具。它的定制能力让你可以把模型验证、单位检查、命名规范全部写进自动化流水线跑几十个零件都不需要人盯着。如果公司有数据隐私要求不能把模型数据发到外网DeepSeek 这条线的优势就更明显可以接入本地化部署的模型数据不出内网环境。Claude Code 的官方产品形态基本不给这种私密部署的空间。6.3 我的混合用法与最后一点体会我目前在实际项目里用的是混合工作流第一步用宏录制加 Claude Code 攻坚出一个新的参数化模板脚本第二步把这个模板脚本交给 DeepSeek Harness 做批量参数扫描比如法兰厚度从 5 毫米到 30 毫米每隔 2 毫米生成一个模型第三步批量化过程中遇到新特征或特殊结构再回到 Claude Code 里单独攻坚。这样的组合既利用了 Claude Code 的生成质量又占了 DeepSeek 低成本批量的便宜两个方案的短板都被补上了。我自己的体会是AI 控制 SolidWorks 这件事本质上不是让 AI 替你思考而是让 AI 替你把重复劳动的脏活累活吃掉大半。真正定义产品的还是工程师的头脑——你要知道这个法兰为什么要 8 个孔而不是 6 个为什么要用沉头而不是通孔。搞清楚这一点再决定用 Claude Code 还是 DeepSeek Harness方向就不会跑偏。