十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

DeepSeek接入SolidWorks:生成式CAD建模插件架构与实战

DeepSeek接入SolidWorks:生成式CAD建模插件架构与实战 简介SolidWorks安装DeepSeek插件的项目源码包面向机械设计、三维CAD领域的SolidWorks用户、插件使用者和二次开发人员旨在解决DeepSeek智能建模和参数优化插件在安装、配置、启用等环节的常见问题并提供一个可直接阅读和修改的轻量级代码参考。压缩包内共3个文件包括HTML格式的说明文档、.inscode配置文件和.gitignore版本控制文件整体大小仅4KB却把版本兼容性检查、插件目录选择、API密钥设置、Add-in启用以及功能测试等关键链路浓缩为简洁的项目结构便于快速定位与复用。目前已有467人学习浏览适合需要在安装前核对细节、安装中排查报错或希望基于源码进行定制开发的读者。借助这份源码可以直观了解解压路径选择、管理员权限运行、配置项输入等注意事项掌握SolidWorks插件从部署到验证的完整思路同时简洁的目录结构也适合作为后续二次开发或研究插件集成机制的起点节省从零搭建与尝试的时间。 最近在折腾SolidWorks二次开发的时候一直有个想法在我脑子里转既然DeepSeek写代码、写方案这么顺手能不能直接把它塞进SolidWorks里让设计师用大白话描述一个零件模型就能自己生成这个项目就是干这件事的——一个基于SolidWorks AddIn框架的DeepSeek插件源码开放核心逻辑是把大模型的理解能力接入CAD建模流程让AI帮你画图、出工艺建议、写宏代码。这个东西适合几类人看一个是天天画重复零件的机械工程师想从标准件、钣金件里解脱出来一个是做SolidWorks二次开发的工程师想知道怎么把大模型API接进桌面工业软件还有一个就是纯粹好奇CAD和AI到底怎么结合的人。这篇博文我会把这套项目的架构设计、核心代码、部署流程和踩过的坑一次讲透照着走你能在半天内跑通自己的版本。1. 项目定位与总体设计把大模型接进CAD到底要解决什么1.1 这个插件能做什么三个典型场景我先聊一下做这个项目的初衷。机械设计里有一大堆活儿其实相当“低智力含量”画标准件、按规格改尺寸、给工程图补标注、查设计规范。这些工作不复杂但非常占用时间。拿最常见的M10外六角螺栓来说一个熟练工程师用SolidWorks从新建零件到完成建模少说也要五到八分钟如果还要做配置、加螺纹装饰线时间翻倍。这种活儿本质上是有规律可循的非常适合交给AI来处理。这个插件首批实现了三类功能。第一类是自然语言建模用户在插件面板里输入类似“生成一个M10外六角螺栓公称长度30mm螺纹长度20mm头部对边16mm”后端调用DeepSeek生成SolidWorks API代码插件自动执行模型直接出现在SolidWorks里。第二类是设计辅助用户选中一个模型AI根据模型特征给出可制造性分析、材料选择和结构改进建议结论直接展示在任务窗格里。第三类是宏代码生成用户只需要描述“给这个零件的圆角批量加上R2的倒角”AI生成对应的VBA或C#宏插件会把它编译执行方便后续复用。说实话第一版我没有把场景做得很广而是把“自然语言到三维特征”这条链路跑通。因为这条链路一旦通了后面所有场景都只是换提示词和工具函数的问题。项目的核心价值在于提供了一套可扩展的框架而不是一个包罗万象的成品。1.2 技术选型为什么是C#、AddIn和DeepSeek API技术选型这件事我踩过不少坑简单说说结论。先说语言。SolidWorks二次开发的主流域就是C#和VB.NETC太底层VBA只能做宏不适合独立插件。C#的API封装完整写UI方便生态里能用的库也多所以主程序和UI全部用C#。SolidWorks插件必须运行在.NET Framework下不能用.NET Core这一点项目初始化的时候就要注意我用的版本是.NET Framework 4.7.2。再说插件形态。SolidWorks插件有两种主流做法一是宏就是在SolidWorks里直接录制或编写VBA代码优点是启动快、适合小工具二是AddIn插件编译成DLL注册给SolidWorks加载能注册独立命令面板、任务窗格交互体验好。正式项目我肯定选AddIn因为我们要做的事情不是一次性脚本而是长期和设计师交互的工具。项目里同时保留了宏模式的示例代码方便快速验证想法。最后说模型接入方式。我第一版用的是DeepSeek API而不是本地部署。原因很实际CAD工作站一般没有好GPU本地部署大模型推理速度慢而API调用延迟低、零维护。DeepSeek的接口兼容OpenAI格式代码改动成本低以后想切别的模型也方便。当然如果企业有数据隔离要求后续可以扩展成本地Ollama端点这个在架构设计上我已经做了抽象换的话只改BaseUrl即可。1.3 源码结构与各模块职责仓库结构在设计时我刻意保持了清晰每个模块单一职责方便其他人阅读和二次开发SolidWorksDeepSeek/ ├── DeepSeekAddIn/ │ ├── DeepSeekAddIn.cs # AddIn入口实现ISwAddin接口 │ ├── DeepSeekClient.cs # DeepSeek API封装 │ ├── CodeExecutor.cs # AI生成代码的编译与执行引擎 │ ├── PromptBuilder.cs # 提示词模板管理 │ └── MainPanel.cs # WPF任务窗格界面 ├── samples/ │ ├── bolt_demo.txt # M10螺栓生成示例含输入和输出 │ └── macro_demo.swp # 宏模式示例 └── docs/ ├── 安装说明.md └── API配置.md这几个文件里最核心的是DeepSeekClient和CodeExecutor。前者负责跟大模型API通信后者负责把AI生成的C#代码编译并塞进SolidWorks进程执行。这两个模块解耦之后后续把DeepSeek换成其他模型只改Client把C#执行换成宏执行只改Executor互不影响。2. 核心细节解析AddIn框架、API调用与提示词工程2.1 SolidWorks AddIn的插件生命周期AddIn的开发绕不开ISwaddin接口它定义了两个方法ConnectToSW和DisconnectFromSW。ConnectToSW在插件被SolidWorks加载时调用入参是SldWorks主对象这个对象是整个二次开发的总入口几乎所有API调用都要从它开始。我习惯在里面做三件事注册命令管理器、创建任务窗格UI、初始化全局状态。DisconnectFromSW在插件卸载时调用一定要把UI、事件委托、缓存对象都清理干净不然SolidWorks退出时容易留下僵尸进程导致下次启动异常。我在第一版就吃过亏没写清理逻辑插件每次卸载都让SolidWorks崩溃一次。还有一个细节容易被忽略SolidWorks是64位进程所以插件程序集必须是x64或AnyCPU且关闭Prefer 32-bit。用Visual Studio新建类库项目后默认可能是AnyCPU并勾选了Prefer 32-bit不改成x64的话插件加载时会报“试图加载格式不正确的程序集”。另外程序集必须强命名也就是要勾选“签名”选项卡里的“为程序集签名”生成一个snk文件否则COM注册可能不稳定。这两个配置是新手最容易卡住的地方。2.2 DeepSeek API接入与请求参数调优DeepSeek API的接入方式不复杂它兼容OpenAI格式所以用HttpClient发个POST请求就行。我在DeepSeekClient里封装了一个方法专门负责把用户的自然语言描述转换成SolidWorks API代码。核心请求体会长这样var body new { model deepseek-chat, messages new object[] { new { role system, content PromptBuilder.SystemPrompt }, new { role user, content userPrompt } }, temperature 0.2, max_tokens 4096, stream false };这里两个参数值得展开说。temperature控制随机性生成代码类的任务我建议调到0.2甚至更低不然同样的输入每次生成的代码差异很大而且容易出现语法问题如果是设计建议类任务可以调到0.7让回答更有发散性。max_tokens要设得足够大生成一个完整的建模函数动辄两三千token如果截断了代码没法编译白白浪费一次调用。请求的时候还有一个地方容易踩坑默认的HttpClient超时时间只有100秒而DeepSeek在高峰期生成大段代码可能要几十秒所以必须显式设置Timeout为120秒以上。另外API Key不要硬编码在代码里我建议用环境变量或者项目里的secrets.json存放防止源码传到仓库后泄露密钥。2.3 提示词工程是决定成败的关键这个项目里提示词工程比API调用的权重高得多。相同一个“生成M10螺栓”的需求如果给AI的上下文不清楚它生成的代码可能是伪代码或者根本跑不起来的残缺函数。我在PromptBuilder.cs里维护了一套系统提示词核心要求有三点。第一必须输出完整可编译的C#代码格式用csharp代码块包裹不允许输出解释性文字第二必须生成固定方法签名public void Execute(SldWorks swApp)这样插件可以直接动态编译调用第三建模过程中必须判断文档状态、明确使用毫米作为单位并且在草图里保持全约束。单位这个问题我专门在提示词里写了强调。SolidWorks API底层默认米制但绝大多数设计师习惯毫米。如果AI生成的代码直接用数值创建特征出来的模型尺寸会差1000倍画一个30mm的螺栓变成画一个30米的螺栓。所以提示词里我明确要求代码开头先设置文档单位为MMGS或者所有尺寸输入按毫米处理并转为米制。另外一个很实用的小技巧是每次调用时把当前SolidWorks版本号也传给AI比如“当前环境为SolidWorks 2023 SP5使用对应版本API”。因为不同版本的API在个别方法上略有差异提前告诉AI能显著降低编译错误概率。3. 从零到一环境准备、核心代码与编译注册全流程3.1 环境准备与项目初始化先列一套我在开发环境里验证过的配置清单SolidWorks 2023 SP52020以上版本基本都能跑Visual Studio 2022 Community.NET Framework 4.7.2开发工具SolidWorks API SDK安装SolidWorks时勾选“API SDK”附加组件默认在Program Files\SOLIDWORKS Corp\SOLIDWORKS\api\redist目录下NuGet包Newtonsoft.Json、Microsoft.CSharp项目初始化步骤按这个来新建一个“类库(.NET Framework)”项目目标框架选4.7.2平台选x64。然后添加引用从api\redist目录下引入SolidWorks.Interop.sldworks.dll、SolidWorks.Interop.swpublished.dll、swconst.dll三个关键程序集。这三个DLL不是所有SolidWorks安装包都自带如果找不到去安装盘的“SOLIDWORKS CAM”或“SolidWorks Toolbox”里翻一翻也可以直接搜索。添加引用后把它们的“本地复制”属性设为False避免生成目录里出现庞大的互操作DLL。打开项目属性在“生成”选项卡勾选“为COM互操作注册”在“签名”选项卡勾选“为程序集签名”并新建snk文件。到这里一个标准AddIn插件项目的基础配置就完成了。3.2 核心执行链路从自然语言到三维特征这一步是整个项目的心脏我把它拆成五个步骤来说明。第一步用户在UI输入框输入自然语言描述比如“生成一个M10外六角螺栓公称长度30mm螺纹长度20mm头部厚度6.6mm对边16mm”。第二步DeepSeekClient把这段描述和系统提示词拼装在一起调用API获取代码。返回的内容是一段C#代码包含在csharp代码块里我用正则表达式把它提取出来var match Regex.Match(content, csharp\s*(?code.*?), RegexOptions.Singleline); if (!match.Success) { // 尝试兼容不带语言标识的纯代码块 match Regex.Match(content, \s*(?code.*?), RegexOptions.Singleline); } var code match.Groups[code].Value.Trim();第三步CodeExecutor拿到代码后先做编译检查。我用的是.NET自带的CSharpCodeProvider把生成的代码动态编译成内存程序集。如果编译出错就把错误信息反馈给DeepSeek让它重新生成最多重试三次。这个自我修复循环非常管用实测下来能在很大程度上减少人工干预。第四步编译通过后在SolidWorks进程内执行。这里注意一个关键点执行前必须关闭SolidWorks的UI刷新和输入框干扰否则过程会卡顿而且模型树会非常混乱。我常用的方式是swApp.SetUserPreferenceToggle((int)swUserPreferenceToggle_e.swInputDimValOnCreate, false); swApp.SetUserPreferenceToggle((int)swUserPreferenceToggle_e.swSketchInferWhenSnap, false); // 执行建模代码 // 执行结束后恢复设置 swApp.SetUserPreferenceToggle((int)swUserPreferenceToggle_e.swInputDimValOnCreate, true);第五步把执行日志输出到界面。AI生成了哪些特征、执行耗时多少、有没有警告都展示出来方便设计师判断结果是否可靠。3.3 编译、注册与无VS环境部署在开发机上直接F5启动调试Visual Studio会自动把SolidWorks拉起来并加载插件这是最快的验证方式。但如果要部署到没有安装Visual Studio的工程师电脑上就得手工注册DLL了。手工注册分两步。第一步用管理员身份打开命令行运行Framework64下的RegAsmC:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe DeepSeekAddIn.dll /codebaseRegAsm会把程序集的COM信息写进注册表。第二步在注册表里添加入口让SolidWorks知道这个插件需要被加载。在HKEY_CURRENT_USER\Software\SolidWorks\AddIns{你的AddIn GUID}下创建两个DWORD值LoadOnStartup设为1Command设为1。GUID在项目里的AddIn类上定义安装说明文档里会写明。这一步如果漏了SolidWorks的插件管理器里能看到但怎么都加载不起来。另外有一个实际经验开发机上F5调试过的插件在卸载时要先通过SolidWorks的“插件”对话框取消勾选再做代码清理不然DLL文件被SolidWorks进程占用删除不了。4. 常见问题、排查技巧与后续扩展4.1 高频问题速查表我整理项目时把测试中遇到的高频问题归纳成了表格发布后不少用户反馈这表比文档都实用问题现象可能原因解决方案插件在插件管理器里看不到AddIn GUID注册表缺失或RegAsm未执行重新用管理员权限RegAsm注册检查注册表项插件能显示但加载时报错平台目标不是x64或程序集没有强名称项目平台改为x64“签名”里添加snk文件点击生成按钮后无响应API Key未配置或网络不通检查环境变量DEEPSEEK_API_KEY用命令行curl测试API连通性生成的模型尺寸差1000倍单位未显式设置AI被默认米制误导在提示词里强约束代码开头设置MMGS单位生成代码编译失败AI返回内容被截断或缺少上下文调大max_tokens给AI带上SolidWorks版本号卸载插件后SolidWorks异常DisconnectFromSW没有清理UI对象在卸载方法里销毁命令组、任务窗格和事件委托这里我还想提一嘴网上常看到的“SolidWorks激活向导初始化问题72”。这个报错出现过几次但跟插件本身没什么关系一般是SolidWorks安装损坏、COM组件注册异常或者系统环境变更导致的。出现这个报错时用SolidWorks自带的Clean Uninstall Utility彻底卸载再重装通常都能解决不要试图用注册表清残留的方式硬刚费时费力还可能把系统搞坏。4.2 生成代码执行失败的深层原因编译器检查通过只能保证代码语法对不保证建模逻辑对。我把执行失败的案例复盘了一下发现典型的坑有三个。第一个是草图欠约束。AI生成的草图有时候直接按坐标画线但没有添加几何关系或尺寸约束SolidWorks对它做拉伸时可能识别不了轮廓。解决思路是在提示词里明确要求“每个草图必须用尺寸和几何关系完全约束”同时插件执行前可以为文档打开自动约束检查。第二个是特征上下文不对。有些API调用要求必须先激活一个配置或者必须先选择一个面AI生成的代码如果没有处理这一步执行时会报空引用。我在CodeExecutor里加了一个前置检查每次执行前先记录当前文档、配置、选中状态执行完再恢复相当于是给AI代码加了一层安全网。第三个是模型文档不存在。AI代码默认“当前文档”存在但实际上插件初始化时用户可能还没新建零件。我要求AI生成的代码在开头判断ModelDoc2是否为空为空则新建一个零件文档这个逻辑直接固化在提示词里。4.3 成本控制与调用治理DeepSeek API按token计费虽然价格不高但CAD建模场景有它的特殊性生成一次代码可能要消耗3000到5000个token如果用户反复调试四五次一次会话的成本就上去了。实际使用中我给插件加了三个控制手段。一是限制重试次数。AI自我修复循环最多三次超过就停止并让用户修改提示词避免死循环烧钱。二是给每次调用记录token消耗和响应时长在日志面板显示让用户对费用有感知。三是把设计建议类请求和代码生成类请求分开处理前者用简短的快速回答token消耗明显更小。另一点值得说的是DeepSeek兼容OpenAI格式意味着如果你后续接了本地Ollama或私有化部署的DeepSeek模型只要把API地址改掉就行客户端逻辑完全不用动。这个架构层面的灵活性能适配企业将来的合规需求。4.4 项目的后续扩展方向这个项目第一版的核心定位是“跑通链路”所以很多更深的功能留了扩展位。我整理了几个已经规划的迭代方向也给想参与源码贡献的人指个路。第一个方向是语音建模。设计师在SolidWorks里画图时手基本不离鼠标键盘如果接一个语音识别直接说“直径50的圆柱、高度20”插件自动建特征体验会上一个大台阶。市面上语音识别API已经非常成熟难度主要在语义解析和建模指令映射。第二个方向是批量化设计。比如公司有几千个相似零件要改尺寸AI可以遍历Excel表格生成对应的建模脚本统一执行。这个方向对企业效率提升最明显也是很多私信我的人在问的。第三个方向是把AI生成的模型直接导出到Unity3D或游戏引擎。现在不少数字孪生项目需要把机械模型做轻量化转换AI生成零件后可以直接打包成FBX或GLTF输出省去来回导出的麻烦。最后一个方向其实是工程化层面的加自动测试用例。每次修改提示词后跑一遍预设的10个测试样例对比输出成功率防止AI行为飘移。这个对维护一个AI插件来说非常关键不然每次改点东西都可能把之前能跑通的场景改崩。我在实际项目里最深的体会是AI插件开发的难处不在AI本身而在工程化。你得把API调用、提示词、代码执行、异常处理、成本控制这些环节都串起来任何一个环节没兜底用户使用时的体验就会很糟糕。这个项目把从自然语言到SolidWorks特征的完整链路跑通了后面的事情就是在这条路上继续铺砖加瓦。如果你也在做CADAI相关的尝试欢迎拿源码去魔改遇到问题可以看看仓库的Issue区里面还沉淀了不少社区踩坑记录。本文还有配套的精品资源点击获取
返回列表