夜雨聆风一个二次开发老兵的深夜实验
最近一直在思考和探索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化感兴趣，欢迎留言交流。
