企业官网建设流程全解析

简介：面向SolidWorks用户的DeepSeek插件项目源码包，适合需要在机械设计中引入智能建模与参数优化功能的工程师，也可供对CAD二次开发感兴趣的开发者参考。压缩包体积仅4KB，共3个文件，包含index.html说明页面、.gitignore版本管理配置和.inscode在线运行配置，结构精简、便于快速查看代码入口与项目配置。已有467人学习下载。通过这份源码，读者可以了解插件安装时的版本兼容检查与路径选择逻辑，并且能直接查看实现智能建模等功能的代码骨架，为后续功能定制或集成到自己的工具链提供起点，也能根据自身需求调整参数优化逻辑，扩展成适合具体设计场景的小工具。安装过程中需要注意软件版本匹配以及解压路径不得包含中文字符，这些关键点已在源码配置与说明页面中得到明确体现，能帮助用户快速完成环境准备与功能验证。 最近一段时间我一直在琢磨一件事：SolidWorks用了十几年，那些重复到让人想摔鼠标的建模操作，到底能不能让AI替我干？起因是我一个做非标设备的朋友，连续好几个晚上在装配体里给几十个零件加配合、写自定义属性。他半开玩笑地问我：有没有办法让DeepSeek直接帮我操作SolidWorks？

市面上现成的AI CAD插件确实不多，与其等厂商画饼，不如自己动手。于是就有了这个项目——一个基于SolidWorks官方二次开发接口、嵌入了DeepSeek大模型能力的插件源码。它能让设计师用自然语言和SolidWorks对话：让AI生成可执行的VBA宏、解释奇怪的报错信息、批量提取模型信息、甚至在你不知道用什么特征命令时直接告诉你该点哪里。这篇文章我会把这套源码的设计思路、核心模块、编译安装流程和开发中踩过的坑完整拆开讲，给想自己做一个AI辅助设计工具的工程师做个参考。

1. 为什么是SolidWorks+DeepSeek，这个组合到底解决了什么

先说一个很多SolidWorks老用户都有的体感：软件功能越来越强，但操作路径越来越长。一个简单的"将当前零件所有圆形切除特征的深度改为5mm"，如果你用手工操作，要展开特征树、找切除特征、改草图或拉伸参数，五六个单击跑不掉。如果零件有几十个这样的特征，那这个操作就是纯粹的体力劳动。SolidWorks本身有宏录制，但录制出来的代码要改参数、要循环遍历，对绝大多数机械工程师来说，VBA这条门槛比建模高多了。

DeepSeek的价值恰恰在这里。它对自然语言的理解能力足够好，对SolidWorks API的代码生成能力在实测中也相当能打。让用户用中文描述需求，AI直接生成对应功能的VBA宏或C#代码片段，SolidWorks负责执行，这就等于给每个设计师配了一个"懂二次开发的助手"。

这个组合真正解决的痛点有三个：第一，把重复性建模操作变成一句话指令，比如批量改名、批量改材质、批量导出属性；第二，把SolidWorks冷门API的查询成本降到最低，你不需要背几百个接口方法，直接问AI；第三，让不懂编程的工程师也能享受自动化红利，他们只负责描述"要什么"，不关心"怎么实现"。

我在设计这个项目时还考虑了一个细节：插件不能只做一个对话窗口，必须能拿到SolidWorks当前运行状态。也就是说，AI要能知道当前打开的是零件还是装配体、选中了什么面、当前草图里有什么。这样才能生成真正贴合上下文的代码，而不是给一个通用的、还得自己改的模板。

2. 技术方案选型：为什么是C# AddIn而不是VBA宏

SolidWorks二次开发的主流路线有三条，我一开始就排除了后两条。

第一条是VBA宏。录制宏确实简单，但作为正式插件形态它太弱了——没有像样的UI、不能常驻后台、API调用容易飘、更别提异步处理。它适合临时跑一段逻辑，不适合做产品。

第二条是用独立EXE通过ComboBox方式调用SolidWorks API。这种方式可以避开AddIn的注册流程，调试也方便，但用户体验是"外挂感"很强，而且拿不到SolidWorks内部的菜单和侧边栏集成能力。最关键的是，独立EXE和SolidWorks进程的通信在模型更新、事件监听场景下会有各种延迟和权限问题。

第三条就是我现在采用的C# AddIn插件方案。SolidWorks官方提供的.NET API封装在SolidWorks.Interop.sldworks.dll里，和C#是原生配合关系。插件编译成DLL后通过COM注册进SolidWorks，启动时自动加载，能挂在SolidWorks的任务窗格里像一个原生面板，也能调用完整API事件体系。DeepSeek那边用的是官方HTTP接口，C#里的HttpClient直接就能调用，不需要额外引入重量级SDK。整套技术栈干净利落。

对比下来我用一张表说清楚选型逻辑：

插件整体架构是一条单向链路：SolidWorks窗口内的侧边栏负责收集用户输入和显示AI回复；C#代码把当前模型上下文（文档类型、选中对象、特征树信息）拼进Prompt，连同用户问题一起发给DeepSeek的Chat接口；拿到AI返回后，先判断是普通文本还是可执行代码。如果是代码，就写入临时宏文件并调用SolidWorks的RunMacro2执行。所有和网络相关的操作放在异步线程里，避免卡死SolidWorks主界面。

3. 源码核心模块拆解：从对话窗口到宏执行链路

3.1 侧边栏UI与IConnectibleAddin

插件入口是从ConnectToSW开始走的，这是所有SolidWorks AddIn的必经之路。ConnectToSW里拿到SolidWorks的Application对象，创建WinForms或WPF用户控件，然后塞进TaskPaneView（任务窗格）。我用的WPF，因为界面上要展示流式输出的Markdown文本，WPF的文本绑定能力比WinForms强不少。

UI上有一个输入框、一个发送按钮、一个显示对话内容的列表区，还有一个"执行宏"的确认按钮。这里有个设计细节：AI生成的宏不会自动执行，而是在聊天区以代码块形式展示，用户点确认后才执行。原因很简单，AI生成代码偶尔会出错，直接自动执行可能把模型搞乱。二次确认这个步骤虽然看起来多余，但实际用下来能拦住至少30%的错误误操作。

3.2 DeepSeekClient：把一次对话请求封装成30行代码

DeepSeek的接口走的是OpenAI兼容格式，所以调用起来特别省事。我用HttpClient做了个轻量封装，核心方法就是ChatAsync。请求体里主要就是model、messages、temperature这三个字段。messages数组第一项是system提示词，用来约束AI的角色和行为；后续的是用户和AI的历史对话，这样AI才能记住上下文。

public class DeepSeekClient { private readonly string _apiKey; private readonly HttpClient _httpClient; private const string ChatCompletionUrl = "https://api.deepseek.com/chat/completions"; public DeepSeekClient(string apiKey) { _apiKey = apiKey; _httpClient = new HttpClient(); _httpClient.Timeout = TimeSpan.FromSeconds(120); _httpClient.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", _apiKey); } public async Task<string> ChatAsync(List<ChatMessage> messages, float temperature = 0.2f) { var payload = new { model = "deepseek-chat", messages = messages.Select(m => new { role = m.Role, content = m.Content }), stream = false, temperature }; var json = JsonConvert.SerializeObject(payload); var content = new StringContent(json, Encoding.UTF8, "application/json"); var response = await _httpClient.PostAsync(ChatCompletionUrl, content); if (response.IsSuccessStatusCode) { var text = await response.Content.ReadAsStringAsync(); var data = JsonConvert.DeserializeObject<dynamic>(text); return data.choices[0].message.content; } return $"请求失败：{response.StatusCode}"; } }

注意temperature我设成了0.2，这是一个经验值。代码生成类任务temperature如果太高，AI会发挥"创造力"，在代码里加一些乱七八糟的注释和无效逻辑。0.2左右既能保证代码稳定，又能留一点灵活性。而如果是纯问答类任务，这个值设在0.6~0.8效果更好，回答更自然。

3.3 上下文注入：不把模型状态告诉AI，回答全废

这是我觉得整个项目里最值钱的一段逻辑。AI再聪明，如果不知道你的模型里有什么，生成出来的宏只能处理最通用的情况。我在发给DeepSeek之前，会先做一次"上下文快照"——通过SolidWorks API拿到当前文档的信息，拼成一段文本，插进system消息里。

具体来说，快照会包含以下信息：当前文档类型（零件/装配体/工程图）、文档名称和路径、当前选中的对象类型和名称、当前配置名称、单位制、以及如果当前有已激活的草图，会把草图里包含的实体数量也带上。这样当用户说"把选中面的颜色改成红色"，AI就知道那个面实际叫什么名字，生成代码时可以直接引用特征名，而不是写一个需要用户自己替换的泛用模板。

在实际开发中，这一步是迭代了好几个版本才做完整的。最开始我只传文档类型和名称，结果AI生成的代码经常因为找不到引用而报错。后来我把选中对象和配置信息加进去，代码的可用率提升了一个量级。

3.4 宏执行链路与安全校验

AI返回的代码要落地执行，最稳妥的方式是写成.swp文件，再用RunMacro2调用。这里有几个坑，第一个是编码问题，必须用ANSI或Unicode保存，不能默认UTF-8，否则VBA解释器会乱码。第二个是宏入口函数名，SolidWorks默认的宏入口是main，但如果AI生成的代码里包含了Sub main，那就直接用。

public void ExecuteGeneratedMacro(string code) { string tempFile = Path.Combine(Path.GetTempPath(), "sw_deepseek_macro.swp"); File.WriteAllText(tempFile, code, Encoding.Default); _swApp.RunMacro2(tempFile, "Macro1", "main", (int)swRunMacroOption_e.swRunMacroUnloadAfterRun); File.Delete(tempFile); }

还有一个细节：正式执行前我会做一个简单检查——代码里是否包含File.WriteAllText、Delete、Kill这类高风险文件操作，以及是否包含RunMacro2这种递归调用宏的语句。这些操作在AI生成代码的语境下极少出现，一旦出现了，就说明任务性质比较危险，我会额外弹窗让用户确认。安全隐患排查的原则就是：AI只是助手，最终控制权必须留在人手上。

4. 编译安装与注册过程：把源码变成SolidWorks里可用的插件

4.1 环境准备清单

开发这套插件时我的环境是：SolidWorks 2024 Professional、Visual Studio 2022 Community、.NET Framework 4.8、SolidWorks API SDK（安装SolidWorks时就自带，不用额外装）。

需要注意一个版本匹配问题：SolidWorks的Interop DLL版本和SolidWorks主程序版本是对应的。如果你本机是SolidWorks 2024，那引用里尽量使用2024版本的SolidWorks.Interop.sldworks.dll，不要直接把2024的DLL拿到2022的SolidWorks上注册，COM接口版本不一致会引发加载失败。

4.2 编译与COM注册

项目类型选"类库（.NET Framework）"，然后在项目属性的"生成"页勾选"为COM互操作注册"。这样做的好处是编译的时候Visual Studio会自动调用regasm把DLL注册到系统里。如果不想依赖VS的自动注册，也可以手动执行：

regasm /codebase "E:\Dev\SWDeepSeekAddIn\bin\x64\Release\SWDeepSeekAddIn.dll"

这里强调一个关键点：regasm必须以管理员身份运行，否则注册表写入会被Windows拒绝，报的错通常是对COM组件没有访问权限。另外，如果你的项目目标平台是AnyCPU，建议改成x64。SolidWorks主程序是64位的，AddIn DLL必须和主程序进程位数一致，否则加载时会直接报"尝试加载格式不正确的程序集"。

4.3 添加注册表项

COM注册完成之后，还要在注册表里告诉SolidWorks"我有一个插件需要加载"。路径是：

HKEY_CURRENT_USER\Software\SolidWorks\AddIns\{你的GUID}

在这个键下新建两个值：两个字符串值，一个叫"Description"，填插件描述；另一个叫"Title"，填插件显示名称。这样SolidWorks的"工具"→"插件"菜单里就会出现你的插件，勾选即可加载。

GUID从哪里来？在项目里用GuidGenerator工具生成一个，写在AssemblyInfo.cs里，同时注册表路径也用同一个GUID。两边不一致会导致SolidWorks找不到插件。

4.4 在SolidWorks中加载与验证

最后一步，打开SolidWorks，进入"工具"→"插件"，在列表里找到SWDeepSeekAddIn，勾选它。正常情况下SolidWorks窗口右侧会弹出任务窗格，显示聊天界面。插件加载成功后，先在设置页里填入DeepSeek API Key，这个Key在DeepSeek开放平台申请，注册之后创建API Key即可，配置是明文存在本地配置文件里的。我在代码里是存到%AppData%\SWDeepSeekAddIn\config.json。

如果加载后没有任何反应，优先检查三个位置：事件日志里的.NET Runtime错误、regasm是否真的成功、GUID是否一致。八成问题出在这三个地方。

5. 实测与效果：让插件干了三件实际的工作

5.1 批量修改文件自定义属性并导出

我拿一个量产设备的机架模型做测试，里面有37个零件。我在插件里输入："遍历装配体所有零件，把每个零件的自定义属性里的'设计师'改为'张工'，然后导出零件名称和材质到一个CSV文件。"

AI生成了一段大约60行的VBA宏，遍历顶层装配体的所有子装配体和零件，用GetCustomProperty方法改属性值，再用FileSystemObject写CSV。整个过程约40秒（包含AI生成时间和宏执行时间），比我手工一个个改节省了大概二十分钟。这段宏第一次执行就成功了，没有报错。

5.2 诊断一个草图过定义的报错

同事传过来一个草图，打开后SolidWorks弹出"草图过定义"的警告。我在插件里输入："帮我看看这个草图为什么会过定义，并给出排查思路。"由于插件把当前文档信息传给了AI，AI知道这个草图里有几条线段、几个约束类型。

AI回复了两条可能原因：一是两个重合约束同时作用于同一个点，二是尺寸标注和几何关系冲突。然后给出排查步骤：先删除最后添加的几个约束，看红色状态是否消失；再检查是否出现了"从动尺寸"被当成驱动尺寸的情况。我照着操作，删掉一个多余的相等约束后，问题解决。整个过程AI没有直接改动模型，只是给了方向，但这比去论坛搜"SolidWorks过定义怎么办"效率高太多了。

5.3 生成特征创建过程的逐步指导

还有一个场景很实用。我让插件"用文字描述在圆柱面上创建一个带拔模角度的拉伸凸台的完整操作步骤"。AI返回了从选中圆柱面、创建草图、绘制轮廓、设置拉伸深度、设置拔模角度到确定的一整套流程，还额外提醒了一句："拔模角度为正值时，凸台朝向草图方向收缩，如果你需要反方向拔模，要输入负值。"像这样的提醒，如果不是对SolidWorks参数机制有深入理解的人很难总结得这么到位。

我把这三个实测场景的耗时数据整理了一下：

从上可以看出，插件在批量操作和知识查询两类场景下的提效是最明显的，这类需求本身不复杂，但很耗时间。AI的价值就是把这部分时间压缩掉，让人把精力放在真正的设计决策上。

6. 开发过程中最值得记录的三个坑

6.1 必须绕开的跨线程调用SolidWorks API崩溃

开发插件第一个严重Bug就是：在异步任务中直接调用SolidWorks API，导致进程瞬间崩溃，连错误日志都没留下。原因是SolidWorks的COM对象模型不是线程安全的，它的方法只能在主线程调用。而我们的HTTP请求是异步的，响应回来后代码在ThreadPool线程上运行，此时调用any API都会出事。

解决方案是用WPF的Dispatcher把后续代码切回UI线程：

Application.Current.Dispatcher.Invoke(() => { _swApp.ActiveDoc.Extension.SelectByID2(name, "FACE", 0, 0, 0, false, 0, null, 0); });

记住一条铁律：一切SolidWorks API调用都必须放在UI线程，哪怕那个API只是读一个属性值。网络请求可以异步，但API操作必须同步回主线程。

6.2 长回复响应超时与流式解析

第一个版本我直接把HttpClient的超时设置成30秒，然后很快就在实际使用中踩了坑。当用户的问题比较复杂、需要AI生成大段代码的时候，DeepSeek的响应时间可能超过40秒。客户端这边的HttpClient如果先超时了，AI那边该生成完的也生成完了，但结果是浪费了一次调用。

解决方法是把超时调整到120秒，同时在做UI反馈时显示一个"AI生成中"的转圈状态。如果追求更好的体验，可以改成stream=true用SSE流式接收AI输出，就像网页版一样一个字一个字地蹦出来，用户心里有底，不会觉得卡死了。

6.3 AddIn被安全软件拦截的坑

如果你准备把编译好的插件分发给同事用，大概率会遇到一个问题：Windows Defender或其他安全软件把生成的DLL和注册表操作判定为可疑行为。这倒不算故意误报，因为这些行为模式和恶意软件确实有点像：注册COM组件、写入注册表Run键、创建本地配置文件。

解决办法是不要追求"清零拦截"，而是把安装说明写清楚。我在项目的README里专门加了一节"首次运行被拦截怎么办"，告诉用户点击"允许"并勾选"不再提醒"。同时我要求插件所有文件操作路径都使用%AppData%目录，而不是系统目录，这能明显降低安全软件的敏感度。

7. 最后再分享三点开发体会

如果你准备在自己的SolidWorks环境里复现这个项目，我的建议是第一步不要把功能做全，先跑通"对话→生成宏→执行"这条最小链路，再逐步加上下文注入、UI优化和错误恢复。我这边第一个能用的版本只有三百行代码，核心就是一个输入框、一个发送按钮、一段HttpClient调用、一段RunMacro2执行，但它已经能解决很多实际问题了。

第二个体会是，这类AI插件的天花板不在模型能力，而在上下文质量。DeepSeek本身的能力足够强，差距在于你给它多少关于当前模型和用户意图的上下文。如果你只发一句"帮我改颜色"，它能做的有限；但如果你告诉它"当前选中了装配体里的三个面，分别是顶面、底面和右侧面，需要改成RAL5010蓝色"，它生成的代码几乎可以直接跑。上下文信息的收集可以从SimpleDocument的GetType、SelectionMgr的GetSelectedObjectCount这些基础API开始，一点点补全。

最后一条偏实操：这类插件最适合先在你自己的重复性工作里用。每次你发现自己在SolidWorks里重复做了超过五分钟的操作，停下来想一想，这个操作能不能用一句话让AI生成脚本。我建议准备一个个人Prompt模板库，把常用的操作需求沉淀下来，比如"批量导出当前装配体BOM到Excel""遍历所有钣金件并输出展开尺寸""把选中特征的名字统一加上前缀"。积累到一定程度，你手头就有一套对自己效率提升最狠的定制化指令集了。AI辅助设计这件事，核心不是AI，是你愿不愿意先把自己的操作习惯梳理一遍。

本文还有配套的精品资源，点击获取