企业官网建设流程全解析

简介：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.NET，C++太底层，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 SP5（2020以上版本基本都能跑）
• 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下的RegAsm：

"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe" DeepSeekAddIn.dll /codebase

RegAsm会把程序集的COM信息写进注册表。第二步，在注册表里添加入口，让SolidWorks知道这个插件需要被加载。在HKEY_CURRENT_USER\Software\SolidWorks\AddIns{你的AddIn GUID}下，创建两个DWORD值：LoadOnStartup设为1，Command设为1。

GUID在项目里的AddIn类上定义，安装说明文档里会写明。这一步如果漏了，SolidWorks的插件管理器里能看到但怎么都加载不起来。另外有一个实际经验：开发机上F5调试过的插件，在卸载时要先通过SolidWorks的“插件”对话框取消勾选，再做代码清理，不然DLL文件被SolidWorks进程占用，删除不了。

4. 常见问题、排查技巧与后续扩展

4.1 高频问题速查表

我整理项目时把测试中遇到的高频问题归纳成了表格，发布后不少用户反馈这表比文档都实用：

这里我还想提一嘴网上常看到的“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特征的完整链路跑通了，后面的事情就是在这条路上继续铺砖加瓦。如果你也在做CAD+AI相关的尝试，欢迎拿源码去魔改，遇到问题可以看看仓库的Issue区，里面还沉淀了不少社区踩坑记录。

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