CATIA V5与AI智能体结合：从自然语言到自动建模的完整实践

最近在梳理 CAD 自动化和 AI 智能体结合的方向时，看到不少团队在尝试“自然语言驱动 CATIA V5 自动建模”的方案：输入一句话，让智能体去调 CATIA 的建模接口，自动完成设计、改型、加特征这些操作。这类方案听起来很吸引人，但实际能不能落地，要看几个硬指标：智能体怎么和 CATIA V5 通信、建模指令能覆盖到什么程度、改型是不是真能改参数而不是重新画一遍、批量任务跑起来稳不稳定、接口能不能接到现有工具链里。

这次我们就把这套“CATIA V5 + AI 智能体”的完整链路拆开看一遍，重点讲清楚：它是用什么思路实现全自动建模的，环境怎么配，智能体服务怎么启动，自动建模、改型、加特征分别怎么验证，以及 API 调用和批量任务怎么做。整个验证思路不限定某个特定商业产品，适合做 CAD 二次开发、工艺自动化、PLM 集成的工程技术人员参考。如果你正在纠结“AI 到底能不能帮我干活”，这篇文章可以直接收藏。

先说结论：这套方案的本质不是让大模型直接生成 CAD 文件，而是把大模型的意图理解能力、Agent 的任务拆解能力、CATIA V5 的二次开发接口三者串起来。大模型负责把自然语言指令翻译成结构化动作，Agent 负责检查参数、拆分子任务、调度执行，CATIA 侧通过宏、VBA、CAA 或 Knowledge 功能去执行具体的建模操作。所以门槛不在 AI 模型本身，而在 CATIA 自动化接口的稳定性和 Agent 对建模语法的约束能力。

1. 核心能力速览

围绕 CATIA V5 的 AI 智能体目前没有统一的官方标准，多数是“大模型 Agent + CATIA 二次开发”的组合方案。我们按可落地的最小闭环来拆解，它的核心能力如下：

从这套能力看，最大的价值不是让 AI 替代设计师做创意设计，而是把 80% 的重复性、规则性建模操作交给智能体去跑。它擅长“按规矩办事”，不擅长“凭空想象”。所以在评估这个项目时，别拿它跟资深结构设计师比创意，要比“批量改型 50 个类似零件需要多长时间”。

2. 适用场景与使用边界

2.1 适合谁用

• 机械设计工程师：经常做系列件、相似件改型，一个零件改尺寸要重复操作十几步，智能体可以按参数规则自动完成。
• CAD 二次开发工程师：做过 CATIA VBA、CAA 开发的人，最容易把现有宏命令封装成智能体可调用的工具。
• 工艺与标准化部门：需要批量创建标准件、通用特征、模板模型，AI 智能体可以按知识库自动建模。
• PLM/数据管理团队：需要把设计任务接入统一接口，让 MES、PDM、PLM 系统通过 API 触发建模任务。

2.2 能解决什么问题

• 这类方案最典型的场景是：你给它一个参数表或一句改型指令，它自动打开 CATIA V5，定位到对应零件，修改尺寸，更新模型，导出成果。
• 第二个典型场景是：批量加特征。比如 30 个零件都要加加强筋或安装孔，以前需要逐个打开、操作、保存，现在可以把任务列表丢给智能体批量执行。
• 第三个场景是：把企业设计规范固化成智能体知识库。比如“所有钣金件圆角不小于 R3”，智能体在改型时会自动检查并提示。

2.3 不适合什么场景

• 完全没参数的“哑模型”改型，CATIA 侧没有特征树支撑，智能体很难做参数级修改。
• 复杂曲面和自由造型创新设计，大模型生成的描述很难直接转成高质量的 CATIA 曲面。
• 需要多人实时协同的交互设计，智能体目前更适合离线的、任务式的、可回滚的执行方式。

2.4 安全与合规边界

• CATIA V5 属于商业 CAD 软件，部署和使用必须基于合法授权环境，不得通过任何方式绕过授权。
• 涉及企业图纸、型号数据、工艺参数时，要注意数据保密。不要把涉密模型直接送给公网大模型接口，优先使用私有化模型。
• 智能体自动修改模型后，必须保留操作日志和模型备份，避免误操作后无法恢复。
• 如果模型来自客户或第三方，需要确认是否具备修改、再设计、二次分发的授权。

3. 环境准备与前置条件

从实施角度看，这套方案至少需要三个环境：CATIA V5 工作环境、Python 智能体服务环境、大模型推理或 API 环境。

3.1 基础环境检查清单

3.2 CATIA V5 自动化准备

CATIA V5 侧主要用 VBA 宏或 CAA 来做自动化。建议先在 CATIA V5 里录制一个简单的建模宏，检查三件事：

• 宏录制和回放是否正常。
• VBA 环境能否引用 CATIA 类型库。
• CATIA 是否允许外部脚本通过 COM 接口启动或连接。

如果宏功能受限，很多自动化方案就跑不通，这是第一个排查点。实际开发中，常用方式是让 Python 服务通过win32com.client去连接 CATIA 应用，然后把智能体生成的动作逐条发送给 CATIA 执行。

4. 安装部署与启动方式

由于这是一个“智能体服务 + CATIA 自动化”的组合方案，部署时可以拆成两段：先启动智能体服务，再确认 CATIA 侧能接收指令。大多数项目不会给你一个双击就能跑的全部包，需要手动组合。下面给出一套通用搭建流程，具体路径、端口、模型名称需要按实际项目替换。

4.1 创建 Python 虚拟环境并安装依赖

# 创建虚拟环境 python -m venv catia-agent-env # 激活虚拟环境 Windows catia-agent-env\Scripts\activate # 安装基础依赖 pip install fastapi uvicorn requests openai pywin32

注意：pywin32用于 Windows 下连接 CATIA COM 接口，如果智能体服务跑在别的机器上，则不能直接控制本机 CATIA，需要设计消息队列或共享目录方式。

4.2 启动智能体服务

下面是一个最小化的 FastAPI 服务示例。它不包含任何真实的建模逻辑，只用于演示“如何把 Agent 服务和 HTTP 接口串起来”。实际项目中，你需要把execute_catia_action替换成自己的 CATIA 宏调用逻辑。

from fastapi import FastAPI from pydantic import BaseModel import uvicorn import time app = FastAPI(title="CATIA AI Agent Service") class TaskRequest(BaseModel): instruction: str params: dict = {} def execute_catia_action(instruction: str, params: dict): # TODO: 调用 CATIA VBA 宏或 COM 接口，执行建模动作 # 这里仅做模拟 time.sleep(1) return {"status": "success", "instruction": instruction, "params": params} @app.post("/agent/task") def run_task(req: TaskRequest): result = execute_catia_action(req.instruction, req.params) return result if __name__ == "__main__": uvicorn.run(app, host="127.0.0.1", port=8000)

# 启动服务，实际命令需要按项目目录调整 python app.py

启动后，可以在浏览器访问http://127.0.0.1:8000/docs查看自动生成的 API 文档。这只是验证接口服务本身能跑通。

4.3 CATIA VBA 宏调用示例

智能体做自动建模时，最终还是要落到 CATIA 宏命令上。下面是一个极简的 CATIA VBA 宏模板，作用是连接当前打开的 CATIA 文档，并输出文档名称。实际项目里，你在这个框架里写“创建 Pad、打孔、做倒角”等建模代码。

Sub ConnectToCATIA() Dim oCATIA As Object Dim oDocument As Object Dim oPart As Object On Error Resume Next Set oCATIA = GetObject(, "CATIA.Application") If oCATIA Is Nothing Then Set oCATIA = CreateObject("CATIA.Application") oCATIA.Visible = True End If On Error GoTo 0 If oCATIA Is Nothing Then MsgBox "无法连接 CATIA，请确认 CATIA 已启动" Exit Sub End If Set oDocument = oCATIA.ActiveDocument If oDocument Is Nothing Then MsgBox "没有打开的文档" Exit Sub End If Set oPart = oDocument.Part MsgBox "当前文档：" & oDocument.FullName & "，Part 名称：" & oPart.Name End Sub

从工程经验来看，不要让智能体直接生成大段 VBA 代码再强行执行，那样很容易因为语法错误或参数类型不匹配而失败。更好的做法是：把 CATIA 操作封装成一个个固定函数，比如create_pad(length, width, height)、add_hole(diameter, depth)，智能体只负责选择函数和填参数，不负责凭空生成代码。这样稳定性会高很多。

5. 功能测试与效果验证

当环境都跑通之后，进入功能验证阶段。下面给出一套可以照做的测试流程，按“自动建模、改型、加特征、稳定性”四个模块来测。

5.1 自动建模测试

测试目的：验证智能体能否把自然语言指令转成 CATIA 可执行的建模动作，并成功创建基础特征。

操作步骤：

1. 在智能体对话框中输入建模指令。
2. 查看 Agent 返回的结构化参数。
3. 确认 CATIA 中是否新增特征。
4. 打开特征树查看特征名称和参数。

输入指令示例：

创建一个长100、宽50、高20的拉伸长方体

预期结果：

判定标准：特征树中新增了可编辑的 Pad 特征，双击后能修改草图尺寸和拉伸高度。如果 Agent 输出的参数格式不对、单位错误、拉伸方向反了，都算未通过。

常见失败原因：

• 大模型把“长宽高”和 CATIA 里的X Direction、Y Direction、Z Direction对应错了。
• 预期是实体 Pad，结果生成了曲面。
• CATIA 没有处于 Part Design 工作台，导致命令不可用。

5.2 参数改型测试

测试目的：验证智能体能否修改已有零件的关键尺寸，实现真正的参数级改型，而不是删除重建。

操作步骤：

1. 打开一个带参数的历史模型。
2. 输入改型指令。
3. 查看参数更新情况和模型变化。
4. 检查装配关联和草图约束是否被破坏。

输入指令示例：

把 Pad.1 的长度从100改成120，保持宽度和高度不变

预期结果：

判定标准：模型更新后，下游特征不报错，无红色报错提示。如果改型后倒角失效、孔位悬空、草图约束断裂，说明智能体没有走参数路径，而是走了特征重建路径。

这里要特别注意：参数改型一定要在 CATIA 的 Part 层级用参数驱动方式实现，不要用“删除原特征再重新画”的方式，否则模型历史树会被打乱，下游关联全断。

5.3 加特征测试

测试目的：验证智能体能否在指定位置添加新特征，比如打孔、倒角、加加强筋。

操作步骤：

1. 选择一个已有面作为参考。
2. 输入加特征指令。
3. 检查生成的特征位置、方向和参数。
4. 测试连续添加多个特征时的稳定性。

输入指令示例：

在上表面中心添加一个直径8、深度15的通孔

预期结果：

判定标准：孔的位置、直径、深度、方向全部正确，且可以通过修改草图来调整位置。如果孔打在了错误的面上，说明智能体对“上表面”的语义理解有偏差，或者参考面选择逻辑有缺陷。

5.4 批量任务测试

测试目的：验证连续执行多个建模任务时的稳定性。

输入一个批量指令列表：

1. 创建一个长100、宽50、高20的拉伸长方体 2. 在长方体上表面添加一个直径8的通孔 3. 把所有竖直边做半径为2的倒角 4. 保存模型到输出目录

预期结果：智能体按顺序执行，每步都产生日志，最终输出模型文件；失败的任务能明确报错并跳过，不阻塞后续任务。

判定标准：批量执行过程中 CATIA 不崩溃、特征不堆积、每个任务都能定位到对应的特征对象。

6. 接口 API 与批量任务

智能体要融入企业工具链，必须有 HTTP API。下面给出一个通用的调用模板。接口路径、参数名和返回结构都是示例，实际项目里你要对照自己的智能体服务去调整。

6.1 单任务调用示例

curl -X POST "http://127.0.0.1:8000/agent/task" \ -H "Content-Type: application/json" \ -d '{ "instruction": "创建一个长100、宽50、高20的拉伸长方体", "params": {} }'

Python 调用示例：

import requests url = "http://127.0.0.1:8000/agent/task" payload = { "instruction": "创建一个长100、宽50、高20的拉伸长方体", "params": {} } response = requests.post(url, json=payload, timeout=120) print(response.status_code) print(response.json())

预期返回结构：

{ "status": "success", "instruction": "创建一个长100、宽50、高20的拉伸长方体", "params": { "feature_type": "pad", "length": 100, "width": 50, "height": 20 } }

如果需要在外部系统里轮询任务状态，可以设计一个/agent/task/{task_id}接口，把长时间任务放到后台队列去执行，避免 HTTP 请求超时。

6.2 批量任务目录设计

批量任务建议按目录方式管理，把输入参数、日志、输出结果分开存放。下面是一个示例结构：

{ "tasks": [ { "id": "task_001", "instruction": "创建一个长100、宽50、高20的拉伸长方体", "params": {"material": "steel"} }, { "id": "task_002", "instruction": "把 task_001 的长度改为 120", "params": {} }, { "id": "task_003", "instruction": "在 task_002 的上表面添加直径8的通孔", "params": {"hole_diameter": 8, "hole_depth": 15} } ] }

project/ ├── inputs/ # 输入模型和参数文件 ├── logs/ # 每个任务的运行日志 ├── outputs/ # 生成结果模型 ├── scripts/ # CATIA 宏和 Python 脚本 └── config.json # 智能体配置

实际使用时，所有输入文件应放在inputs目录，智能体从配置中读取输入路径，避免在提示词里拼接本地绝对路径，既能减少路径歧义，也更安全。

6.3 批量执行建议

CATIA V5 是桌面级应用，批量执行时很容易出现“多个任务同时操作一个实例”的冲突。建议的做法是：

• 任务全部走队列，串行执行。
• 每个任务执行前检查 CATIA 是否空闲。
• 任务结束后重新初始化环境，避免上一步的选中状态影响下一步。
• 失败任务记录到日志，并设置最大重试次数，比如 2 次。

7. 资源占用与性能观察

这类方案和其他 AI 生成类工具不同，它的资源消耗分三块：智能体服务、大模型推理、CATIA 本体。

7.1 显存占用观察点

• 如果大模型通过云 API 调用，本地几乎不消耗显存，CPU 和内存占用也很低。
• 如果使用本地大模型做意图识别，显存占用取决于模型规模和量化精度。7B 到 14B 模型在 8GB 到 24GB 显存范围内都有对应部署方案，但具体占用要用nvidia-smi实测。
• 大模型推理的显存占用和 CATIA 自身的图形显存占用要分开看，CATIA V5 本身是传统 CAD 工具，显存占用不算高，重点是 GPU 驱动要稳定。

7.2 性能观察方法

Windows 下可以用任务管理器观察三个指标：Python 进程的 CPU 和内存、CATIA 进程的内存、GPU 显存和编码器占用。也可以用命令行方式快速查看：

# 查看 Python 和 CATIA 进程内存占用 tasklist | findstr "python" tasklist | findstr "CATIA"

7.3 影响性能的主要因素

• 模型或者特征树越复杂，改型时需要更新的关联特征越多，耗时越长。
• 批量任务如果设计成单 CATIA 实例串行执行，性能瓶颈在 CATIA 的刷新和重建速度。
• 大模型推理本身有延迟，如果再加上多轮对话、上下文打印、JSON 解析，一道指令可能多花几秒到十几秒不等。更稳妥的做法是：先让大模型输出结构化 JSON，再做语法校验，校验通过后直接执行，不搞多轮来回。

8. 常见问题与排查方法

排查问题有一个通用顺序：先看服务日志，再看 CATIA 宏的报错代码，最后看大模型返回的原始内容。多数情况下，问题不在 AI 理解，而在接口调用和参数校验。

9. 最佳实践与使用建议

9.1 第一次测试从小用例开始

不要一上来就做整机改型，先用“创建方块 → 打孔 → 倒角 → 改尺寸”这套最小流程验证整条链路。只有最小闭环走通，才有必要继续叠加复杂案例。

9.2 把 CATIA 操作固化成函数库

这是最重要的工程建议。不要让大模型直接写 VBA 代码，而是让它在固定函数池里做选择。比如：

def create_pad(length: float = 100, width: float = 50, height: float = 20): # 调用 CATIA VBA 宏创建拉伸特征 pass def add_hole(diameter: float = 8, depth: float = 15): # 调用 CATIA VBA 宏创建孔特征 pass def modify_parameter(feature_name: str, param_name: str, new_value: float): # 调用 CATIA VBA 宏修改参数 pass

大模型只做“意图理解 + 参数抽取”，具体建模动作由人工封装的函数执行。这样即使大模型输出有小幅偏差，函数层也能兜住。

9.3 设计输入输出规范

输入侧统一为“指令 + 参数表”或“指令 + CSV 参数文件”，输出侧统一为带时间戳的模型文件和日志。批量任务必须做到：每个任务一个日志文件，失败任务有错误码。生产环境里还要有任务重跑机制，避免 CATIA 崩溃后手工清理进程。

9.4 模型文件分目录管理

按inputs、outputs、logs、scripts、backups目录管理，不要把所有文件堆在一个目录。CATIA 自动修改模型前，先复制备份到backups，这样改型失败也能快速恢复。

9.5 接口服务限制访问范围

智能体服务如果挂在局域网，务必通过 IP 白名单或访问令牌限制调用来源。接口提交的任务如果涉及批量修改模型，应增加确认机制：先预览改动点，再执行修改。

9.6 合规提醒

涉及企业真实图纸、客户模型、军用或特种装备数据时，谨慎评估数据出域风险。建议私有化部署大模型，并使用 CATIA V5 的审计日志功能记录每次修改操作。对外发布或商用前，必须由工程师复核生成结果。

10. 总结与下一步

CATIA V5 与 AI 智能体的组合，最值得尝试的点不是让 AI 替代你的设计能力，而是把明确的、重复的、有规则的设计操作自动化。整个方案里最先应该验证的功能是“参数改型”，因为大部分设计工作都消耗在改尺寸、换规格、调整特征上。只要这条链路稳定，批量加特征、模板建模、标准件库自动生成都可以顺理成章地接进来。

最容易踩的坑有三个：一是大模型输出的参数格式不稳定，二是 CATIA 宏执行环境没配好，三是批量任务缺少日志和重试机制。这三个问题几乎决定了项目能不能从 demo 走向实用。

先把最小用例跑起来，再逐步增加特征类型和知识库。后续如果要把这套方案继续扩展，可以往三个方向走：把企业设计规范做成智能体知识库，让它在改型前自动做规则检查；把任务接入 PLM/PDM 系统，让设计变更由系统触发；再把智能体插件化，方便更多工程师在 CATIA 界面里直接使用，而不需要单独打开一套 Web 服务。建议收藏备用，先从自己的高频改型任务开始测一轮。