Codex 接入 SolidWorks 教程：MCP、COM 接口、Computer Use 三条路径对比
Codex 连接 SolidWorks 的三种技术路径完整拆解：MCP 协议、COM 自动化接口、Computer Use。含正版要求、token 成本估算、Plus 是否够用等常见问题，帮你选对路径少踩坑。
我写后端代码写了将近十年，最近一年多一直在折腾 AI 工程化的东西——怎么把大模型接进实际的工作流，而不只是停留在聊天框里。所以当我看到有人把 Codex 接进 SolidWorks 自动建模，第一反应不是"AI 要替代工程师了"，而是：它到底是怎么连进去的？
这个问题比"效果好不好"更值得先搞清楚。因为连接方式决定了能力边界，也决定了你踩坑的位置。
先说清楚：Codex 凭什么能操控 SolidWorks
很多人看到演示截图，以为 Codex 是某种专门为 SolidWorks 训练的 AI。实际上不是。Codex 本质上是一个具备工具调用能力的 AI Agent，它能操控 SolidWorks，靠的是外部接口，而不是内置的 CAD 知识。
这个区别很重要。它意味着：
- Codex 的建模能力上限，取决于你给它的接口质量
- 接口越标准、反馈越清晰，Codex 表现越好
- 接口越模糊、错误信息越含糊，Codex 就越容易在那里转圈
目前把 Codex 接进 SolidWorks 主要有三条路径，原理完全不同，适用场景也不一样。
路径一：MCP 协议（推荐，但有门槛）
MCP（Model Context Protocol） 是 Anthropic 在 2024 年 11 月提出的开放标准，定义了 AI 应用和外部工具之间的通信方式。可以把它理解成 AI 世界的 REST API 规范——不是某家公司的私有协议，而是一套大家都能实现的接口标准。
Codex 支持作为 MCP 客户端接入各种 MCP Server。GitHub 上已经有人开发了 mcp-server-solidworks，把 SolidWorks API 包装成 MCP 兼容的工具集，让 Codex 可以通过标准化的 tool call 来调用建模操作。
这条路径的工作原理大致是：
Codex（MCP Client）
↓ tool call（JSON）
MCP Server（本地运行）
↓ 调用
SolidWorks API（COM 接口）
↓ 返回结果
MCP Server → Codex
Codex 发出一个结构化的工具调用请求，比如"创建一个直径 50mm、高 80mm 的圆柱体"，MCP Server 把这个请求翻译成 SolidWorks API 调用，执行完再把结果（成功/失败/当前模型状态）返回给 Codex。
优点：
- 接口标准化，Codex 能拿到清晰的执行结果和错误信息
- 可以精确控制暴露哪些操作，不会让 AI 乱点界面
- 理论上可以在无界面（headless）模式下运行
坑点：
- 需要自己部署和维护 MCP Server，有一定开发成本
- 现有的开源 MCP Server 质量参差不齐，工具覆盖不全
- SolidWorks 的 COM 接口本身就有很多历史包袱，封装进 MCP 后错误处理更复杂
- 必须是正版 SolidWorks（COM 接口需要授权）
适合谁： 有一定编程基础、愿意花时间调试、需要稳定可重复执行的场景。比如批量生成标准件、参数化建模流水线。
路径二：COM 接口直接调用（最底层，最灵活）
SolidWorks 本身就有一套完整的 自动化 API，基于 Windows COM（Component Object Model）技术，支持 VBA、VB.NET、C# 等语言调用。这套接口存在了二十多年，文档齐全，功能覆盖几乎所有建模操作。
Codex 接管 SolidWorks 的另一种方式，是让 Codex 直接生成调用这套 COM 接口的代码，然后在本地执行。流程大概是：
用户描述需求（自然语言）
↓
Codex 生成 VBA/Python 脚本
↓
本地执行脚本 → 调用 SolidWorks COM API
↓
SolidWorks 执行建模操作
这条路径不需要额外的 MCP Server，Codex 扮演的是"代码生成器"的角色，而不是实时 Agent。
优点：
- 不需要额外基础设施，有 SolidWorks 就能跑
- COM 接口功能最全，几乎没有操作盲区
- 生成的脚本可以保存复用，不用每次都烧 token
坑点：
- Codex 生成的代码不一定能一次跑通，COM 接口的错误信息对 AI 不友好
- 复杂模型需要拆成多步，每步都要人工确认再继续
- 没有实时反馈，Codex 不知道当前模型状态，容易在错误上叠加错误
- 有人测试过，一个鼠标零件大概需要 2000 行 VBA 代码，而 Codex 单次输出有长度限制，分段执行时上下文容易断
这条路径更像是"AI 辅助编写宏"，而不是"AI 自主建模"。对于有一定 SolidWorks 宏开发经验的人来说，效率提升很明显；对于完全不懂 API 的人，调试成本可能超出预期。
路径三：Computer Use 直接操控屏幕（最直观，最不稳定）
OpenAI 在 2026 年初为 Codex 加入了 Computer Use 功能，让 Codex 可以像人一样看屏幕、移动鼠标、点击按钮、输入文字。Mac 版先上，Windows 版在 2026 年 3 月跟进。
这条路径不需要任何 API 接口。Codex 直接"看着"SolidWorks 的界面操作，就像一个远程控制的人类用户。
优点：
- 零接入成本，不需要写任何代码或配置
- 理论上能操控任何有界面的软件，不限于 SolidWorks
- 对于没有 API 的老旧软件，这是唯一可行的路径
坑点：
- 稳定性差，界面稍有变化（弹窗、分辨率、主题）就可能失败
- 速度慢，每一步操作都需要截图→分析→决策→执行，延迟高
- 无法精确控制，Codex 可能点错地方，而且很难检测到
- token 消耗极高，因为每一帧截图都要处理
- 不适合需要精确尺寸输入的场景，手动输入数字容易出错
实际测试中，有人用这条路径建一个减速器模型花了将近 100 分钟，而且最终结果还需要大量人工修正。这不是 Codex 的问题，而是 Computer Use 这种交互方式本身的局限——它是最后的兜底方案，不是主力方案。
三条路径怎么选
| MCP 协议 | COM 直接调用 | Computer Use | |
|---|---|---|---|
| 接入难度 | 中（需部署 Server） | 低-中（需懂 API） | 低（开箱即用） |
| 执行稳定性 | 高 | 中 | 低 |
| 精度控制 | 高 | 高 | 低 |
| Token 消耗 | 低 | 低 | 极高 |
| 适合场景 | 批量/流水线 | 单次复杂建模 | 无 API 的软件 |
| 需要正版软件 | 是 | 是 | 是 |
如果你是程序员，想把 AI 建模接进实际工作流，MCP 路径是值得投入的。前期搭建成本高，但一旦跑通，后续可以持续复用，而且接口标准化意味着以后换模型（从 Codex 换成别的 Agent）成本很低。
如果你只是想试试效果，COM 直接调用是最快的起点。让 Codex 帮你生成一段 VBA 宏，在 SolidWorks 里跑一下，看看能到什么程度。不需要任何额外配置。
Computer Use 适合探索，不适合生产。
一个容易被忽略的前提
不管走哪条路径，有一个问题在实际使用中会反复出现：Codex 不理解物理世界。
这不是在贬低 AI，而是一个工程事实。Codex 生成的建模步骤，在语法上可能完全正确，但在物理上可能毫无意义——比如两个零件的配合公差不对、螺纹方向反了、装配约束缺失。
这和 AI 写代码不一样。代码跑起来会报错，错误信息直接告诉你哪里出了问题。SolidWorks 建出来的模型"看起来没问题"，但只有懂机械的人才能判断它能不能用。
所以目前这套工作流的合理定位是：AI 负责执行，工程师负责判断。AI 帮你把重复性的建模操作自动化——比如批量生成标准件、根据参数表生成变体——工程师负责审查结果、处理异常、做最终决策。
有个做复合材料仿真的朋友跟我说，他最希望 AI 能做的，不是帮他"设计"，而是帮他自动完成铺层参数赋值、表面识别、材料方向划分这类重复操作——每次手动做要花几个小时，但逻辑完全固定。这个需求用 MCP 路径完全可以实现，而且效果会比"让 AI 自由建模"稳定得多。
实际上手前的几个检查项
如果你打算动手试，建议先确认这几件事：
- SolidWorks 版本和授权：COM 接口和 MCP Server 通常需要正版授权，盗版可能在 API 调用时报错
- Codex 订阅等级：Computer Use 功能需要 Plus 及以上，MCP 集成在 Pro 下体验更稳定，token 消耗不容小觑
- 从简单模型开始：单个零件、几何形状规则、尺寸标注完整——这是 AI 建模成功率最高的场景，复杂装配体先别碰
- 准备好工程图：给 Codex 的输入越结构化越好，完整的二维工程图（含尺寸、公差、装配关系）比自然语言描述效果好得多
- 建立验证流程：AI 生成的模型必须有人审查，不要直接拿去出图或加工
这件事现在还处于"能跑通但不稳定"的阶段。但方向是对的，接口在完善，模型在迭代。
值得花时间搭一套自己的工作流，而不是等它"成熟了再说"——等它成熟的时候，先动手的人已经把流程跑顺了。
常见问题
Codex 需要正版 SolidWorks 吗？
MCP 路径和 COM 路径都需要。SolidWorks 的自动化 API 是通过 COM 注册表暴露的，盗版软件通常不注册这些接口，调用时会直接报错。Computer Use 路径理论上不依赖 API，但盗版软件的弹窗和功能限制会严重干扰 AI 操作。结论：想正经用，正版是前提。
Codex Plus 够用吗？还是必须升 Pro？
取决于你的使用频率。Plus 每 5 小时刷新一次额度，如果你只是偶尔建几个简单零件，Plus 够用。但如果你在调试 MCP Server 或者跑复杂装配体，一个任务可能就把 5 小时额度烧完——这种情况下 Pro 的体验会好很多。Computer Use 路径因为每步都要处理截图，token 消耗是 MCP 路径的 5-10 倍，用 Plus 基本不够。
一个模型大概消耗多少 token / 花多少钱？
差异很大。一个简单的旋转体零件（法兰盘、轴套），MCP 路径大概消耗 5-15k token；一个中等复杂度的零件（带孔阵列、倒角、螺纹）可能到 50-100k token。按 GPT-5 Codex 的定价估算，单个简单零件成本在几毛到一两块人民币，复杂装配体可能到几十块。相比之下，Computer Use 路径同样的模型可能花费 10 倍以上。
DeepSeek 能替代 Codex 接 SolidWorks 吗？
目前不太行。DeepSeek 的图像理解能力较弱，无法有效解析工程图纸，这在需要"看图建模"的场景中是硬伤。纯文字描述驱动的简单建模可以尝试，但效果和 GPT-5 Codex 有明显差距。如果你主要用 COM 路径（让 AI 生成 VBA 代码），DeepSeek 的代码生成能力可以一试，但要做好多轮调试的准备。