一个二次开发老兵的深夜实验

最近一直在思考和探索AI+CAYIA二次开发编程，整理电脑上的项目文件夹时，有些吃惊。

在过去六年里，我写了超过300个CATIA二次开发的方法——从尺寸链自动计算到机身等直段参数化布局，从复材成本分析到图样要素提取。D盘上躺着60多个CAA C++项目和十几个WinForms工具。

每一个工具都是这样的：一个需求 → 一个对话框 → 一个按钮 → 一个exe → 用户手动点。

功能越多，界面越臃肿。而且CATIA的二次开发人才越来越难招。

最近我突然想明白了一件事：我一直在「写工具」，而不是「搭接口」。AI Agent 驱动设计，我们应该准备什么？

如果我的200个方法不是藏在WinForm后面等人点，而是暴露成API，让AI来调用呢？

于是我做了一个实验——用自然语言驱动CATIA。

从「写工具脚本」到「搭建能力接口」

传统的CATIA二次开发模式是：

需求 → 写一个新Form → 加几个输入框 → 用户手动点击 → 操作CATIA

这个模式有一个结构性缺陷：代码和UI绑定，人和代码一对一。

你想要调用「创建长桁」的功能？得先打开那个特定的工具界面，填参数，点按钮。另一个系统想调用？不行，得写REST API包装、处理COM引用、加认证——没人愿意干。

而AI时代的思路完全不同：

需求 → 自然语言描述 → AI理解意图 → 自动调用API → CATIA执行

这个思路下，你的CATIA API封装不再是某个工具的组成部分，而是一个可以被任何AI Agent调用的「能力接口」。

听起来很玄？其实实现起来只用了三个组件。这次我选用的是C#+COM组件的技术路线。

架构拆解：就三个文件

第一层：CATIA COM 桥接层

CATIA提供了COM接口，C#可以通过它操作CATIA的几乎所有功能。关键是用早期绑定——引用预生成的Interop DLL，走vtable调用：

// 连接到已运行的CATIAApplication catia = (Application)Marshal.GetActiveObject(”CATIA.Application”);catia.Visible = true;catia.DisplayFileAlerts = false;// 获取Part，创建几何工厂Part part = ((PartDocument)catia.ActiveDocument).Part;HybridShapeFactory factory = (HybridShapeFactory)part.GetCustomerFactory(”HybridShapeFactory”);// 创建点，添加到几何图形集HybridShapePointCoord pt = factory.AddNewPointCoord(100, 200, 300);pt.set_Name(”用户定义点”);hybridBody.AppendHybridShape(pt);part.Update();

这段代码你看着可能不陌生——每个CATIA二次开发人员都写过类似的。

第二层：Tool Definition（工具定义）

关键思路是把每个CATIA操作包装成一个**「AI可理解的工具」**，用JSON Schema描述它的入参：

{ ”name”: ”create_point”, ”description”: ”在指定的几何图形集中创建一个坐标点”, ”input_schema”: { ”type”: ”object”, ”properties”: { ”hybrid_body”: { ”type”: ”string”, ”description”: ”目标几何图形集名称” }, ”x”: { ”type”: ”number”, ”description”: ”X坐标 (mm)” }, ”y”: { ”type”: ”number”, ”description”: ”Y坐标 (mm)” }, ”z”: { ”type”: ”number”, ”description”: ”Z坐标 (mm)” } }, ”required”: [”hybrid_body”, ”x”, ”y”, ”z”] }}

大模型收到这个Schema后，就能理解：「哦，有一个叫create_point的函数，它需要一个几何图形集名称和三个坐标值」。

第三层：AI API 客户端

把用户输入发给大模型，大模型返回结构化的函数调用：

用户说: ”在几何图形集.1中创建一个点(100,200,300)”大模型返回:{ ”function”: ”create_point”, ”arguments”: { ”hybrid_body”: ”几何图形集.1”, ”x”: 100, ”y”: 200, ”z”: 300 }}程序执行: ✅ 点已创建: 用户定义点 (100, 200, 300)

整个过程：中文 → 大模型理解 → 结构化函数调用 → CATIA执行 → 返回结果。

实际效果

目前的Demo支持这些操作：

而且架构是三级递进的，无论你用什么方式都能跑：

DeepSeek API (云端，效果好)  ↓ 没Key时自动降级Ollama 本地模型 (免费，离线) ↓ 没模型时自动降级内置正则匹配 (基础句式兜底)

为什么这件事有意思

1. 复用已有的代码资产

电脑上的300+CATIA操作方法，本质上已经是「能力接口」的雏形。只是它们之前被锁在了WinForm后面。给每个方法补一个JSON Schema描述，AI就能调用它们——一次封装，所有生态复用。

2. 对话式操作替代UI

想象一下这个场景：

用户：在机身等直段上，每隔300mm创建一个偏移平面AI：create_plane → create_plane → create_plane → ...（自动循环）用户：在每个平面上画一个截面圆AI：create_circle → create_circle → create_circle → ...

没有复杂的面板，没有几十个参数输入框。自然语言就是最好的交互界面。

3. MCP协议是下一步

现在的架构是「控制台程序等用户输入」。更进一步的形态是包装成MCP Server，挂到WorkBuddy的连接器里。到时候任何一个AI Agent都能调用你的CATIA能力——设计、仿真、制造、管理，打通了整个链路。

踩过的坑

坑一：CATIA B20 不支持晚期绑定

一开始我用dynamic（晚期绑定/IDispatch）调用COM，心想「这样不用引用Interop DLL，更干净」。结果CATIA V5-6R2020一设置Visible = true就进程崩溃，try-catch都抓不住——SEH异常，进程级硬崩。

解决方案：改用早期绑定，引用Interop DLL走vtable调用。稳定。

坑二：不同CATIA版本的API命名不同

R30版本的HybridShapeFactory叫AddNewCircleCtrRad而不是AddNewCircle，GetLength()是属性Length而不是方法。每个版本都得对一遍API词典。

坑三：64位CATIA vs 32位exe

默认AnyCPU编译出来的exe是32位的，CATIA是64位的，COM跨位数直接E_FAIL。必须PlatformTarget=x64。

适合谁看

如果你是CATIA二次开发工程师，或者你在做其他工业软件的API封装，这篇文章的核心思路是通用的：

你的代码不是没人会用，而是缺一个AI翻译官。

如何你是企业老板，想给你的产品开发提效，尝试AI+CAD方面的更多可能性，欢迎联系我，一起共创~

*项目地址：后续项目架构和接口文件会开源共享

题外话：巧的是，今天刷到两家公司同样在AI+CATIA和CATIA+AI方面的探索，有了同行的探路，相信这个方向在不远的将来就开出更多的花来了~

当然，面对AI技术快速迭代的同时，我们也应该清醒地认识到，AI+工业场景依然有你有我~

如果你对CATIA二次开发、工业软件AI化感兴趣，欢迎留言交流。