CATIA V5 AI智能体：从自然语言到自动化建模的工程实践

从工程实现来看，CATIA V5 的 AI 智能体能否落地，关键不在大模型本身，而在于意图解析、参数映射、CATIA 自动化接口和校验回滚能否串成一条稳定链路。所谓“AI 全自动建模、设计改型、加特征一键搞定”，本质是把工程师过去手动完成的操作拆解成可枚举的步骤，然后由大模型负责理解自然语言，由代码负责执行 CATIA 命令，最后再用模型校验结果。这个方向非常适合正在做 CAD 二次开发、智能体应用集成或制造业数字化项目的团队。

这篇文章按实测主线展开，会讲清楚 CATIA V5 AI 智能体的工作原理，并给出一套可以本机复现的最小原型：用大模型把中文建模需求解析成结构化指令，再用 Python 调用 CATIA V5 的 Automation API 完成创建零件、修改参数、添加特征三类操作。读完可以直接在本地搭建原型，并把测试数据集设计思路迁移到自己的零件库上。

1. 先看清楚：CATIA V5 的“AI 全自动建模”到底在做什么

1.1 AI 智能体不是替 CATIA 建模，而是把“意图”翻译成“操作”

大模型并不能直接生成一个可被 CATIA 编辑的三维零件文件。真正可行的路径是让大模型承担“需求理解与任务规划”的角色，把类似“创建直径 40 毫米、高 15 毫米的圆柱”这样的自然语言，转换成结构化的参数指令，然后再由本地程序调用 CATIA V5 的自动化接口完成真实建模。

在这个链路里，AI 智能体更像翻译器、调度员和检查员，真正的几何内核仍然是 CATIA 自己。理解这一点非常重要。如果一开始就期望大模型直接输出一个三维模型，路径很容易走偏。正确做法是把建模任务拆成可枚举的子动作：选择哪个平面、画什么轮廓、轮廓参数是什么、使用哪种特征、特征值是多少、是否需要更新。只要这些子动作能被结构化描述，程序就能稳定控制 CATIA 执行。

1.2 完整链路：会话、解析、映射、执行、校验五层

一个可工作的 CATIA V5 AI 智能体，通常包含五层：

• 会话层：接收用户输入，维护多轮对话上下文。用户说“把高度改成 30”时，智能体要知道“高度”指的是哪个特征。
• 解析层：大模型根据固定提示词生成 JSON 结构化指令。这是最容易被做成 demo 的部分。
• 映射层：把 JSON 中的 feature_type、参数名、单位转换成 CATIA 的 Automation 对象和 API 参数。
• 执行层：通过 COM 调用 CATIA Automation API，执行创建、修改、删除操作。
• 校验层：读取特征树、测量模型尺寸，确认操作结果符合预期。

这五层中，解析层只是第一步，映射层和执行层才是工程量主要来源。很多失败案例都是因为只在大模型提示词上反复调优，而参数映射和几何校验没有跟上，导致模型输出看似正确，CATIA 那边却执行失败。

1.3 三类典型任务：设计、改型、加特征

把 AI 建模需求归成三类，可以覆盖大多数实验场景：

• 设计：从空零件开始创建特征。输入通常是“底板 100x60x8，四角 R5 圆角”。
• 改型：在已有模型上调整参数。输入通常是“把拉伸高度改成 30mm”。
• 加特征：在已有几何上补充结构。输入通常是“在顶面中心打一个直径 6 的孔”。

这三类任务的自动化难度是递增的。设计类主要难点在草图轮廓和约束；改型类主要难点在参数路径定位；加特征类除了参数之外还依赖参考面、定位点、边线选择，对几何上下文要求更高。下面章节会按这个难度顺序逐步实现。

2. 环境准备：CATIA V5 的自动化接口是智能体的“手”

2.1 为什么选择 Automation API，而不是 CAA 或 VBA 宏

CATIA V5 提供多种二次开发通道，智能体通常选择 Automation API。

对 AI 智能体来说，Automation API 是目前最合理的平衡点。因为它通过 COM 暴露对象模型，Python 可以用 pywin32 直接调用，不需要额外开发 DLL 插件。VBA 宏的价值更多在“录制参考”：先手工操作一遍，录出 VBA 代码，再对照代码确认准确的对象名和方法签名，最后把同样逻辑翻译到 Python。

2.2 用 Python 通过 COM 连接 CATIA V5

假设本机已经正常安装 CATIA V5 并完成许可激活。下面是 Python 连接 CATIA 的常见方式：

import win32com.client def connect_catia(visible=True): try: catia = win32com.client.GetActiveObject("CATIA.Application") except Exception: catia = win32com.client.Dispatch("CATIA.Application") catia.Visible = visible return catia

GetActiveObject 会尝试连接已经打开的 CATIA 实例；Dispatch 会在找不到现成实例时启动一个新进程。实际使用时，推荐先手工打开 CATIA，再用 GetActiveObject 连接，这样调试时可以看到界面变化，便于确认模型更新状态。

import win32com.client def create_new_part(catia): documents = catia.Documents part_doc = documents.Add("Part") return part_doc

返回的 part_doc 是 PartDocument 对象，后续通过part_doc.Part拿到 Part 对象，再访问草图、特征和参数。

注意：如果 GetActiveObject 报错找不到命令，优先检查 CATIA 是否已经在运行、Python 位数和 CATIA 进程位数是否一致、pywin32 是否安装成功。不要急着换框架。

2.3 从新建零件到第一个拉伸，先跑通最小链路

建议在做 AI 智能体之前，先写一个不经过大模型的“最小建模脚本”：新建零件、创建草图、画一个圆、拉伸成圆柱。这个脚本是后面所有智能体用例的地基。

def create_cylinder(catia, radius=20.0, height=15.0): part_doc = create_new_part(catia) part = part_doc.Part # 选择 XY 平面进入草图 plane_xy = part.OriginElements.PlaneXY sketches = part.Sketches sketch = sketches.Add(plane_xy) sketch.OpenEdition() # 在草图坐标系中画圆 factory_2d = sketch.Factory2D factory_2d.CreateCircle(0.0, 0.0, radius) # 退出草图并更新 sketch.CloseEdition() part.Update() # 创建拉伸特征 shape_factory = part.ShapeFactory pad = shape_factory.AddNewPadFromRef(sketch, height) part.Update() return part, pad

代码里需要特别注意CreateCircle的坐标单位、AddNewPadFromRef的参数顺序。不同 CATIA V5 版本之间，方法名和参数签名可能存在差异。

注意：最稳妥的 API 确认方式不是查文档，而是打开 CATIA 的宏录制，手工画一遍草图再拉伸，然后打开录出的 VBA 代码对照对象名。自动化代码里的差异多半可以通过这个方式解决。

环境准备清单：

• Windows 10/11 64 位系统。
• CATIA V5 已安装并正常启动。
• Python 3.9 及以上版本。
• pywin32 库已安装。
• 大模型 API 或本地部署模型的调用凭证。
• 能手工创建一个带拉伸特征的零件。

3. 实现“听懂需求”的智能体：从自然语言到 CATIA 命令

3.1 用提示词约束大模型输出结构化指令

要让大模型稳定驱动建模，第一步是设计一个约束严格的系统提示词。目标是让模型只输出 JSON，不输出解释，不使用模糊描述。下面是一份可运行的提示词示例：

你是一个 CATIA V5 建模指令解析器。 用户会输入中文建模需求，你只输出 JSON，不要输出任何解释。 JSON 必须符合以下结构： { "mission": "create_part | modify_part | add_feature | query_parameter", "feature_type": "pad | pocket | hole | fillet | pattern | none", "profile": { "sketch_plane": "XY | YZ | ZX", "shape": "circle | rectangle | none", "center": [0, 0], "radius": 0, "width": 0, "height": 0 }, "operation": { "direction": "up | down | symmetric", "height": 0, "depth": 0, "diameter": 0, "radius": 0 }, "target_parameter": "", "new_value": "", "unit": "mm" }

固定协议的核心原因有两个。第一，结构化 JSON 可以被 Python 的 json 库直接解析，不需要写复杂的中文语义匹配逻辑；第二，枚举字段提前固定后，执行器可以对指令做严格校验，用户说“把高度改为 30”时，模型不能自由发挥成"height": "thirty"或"h": 30，只能输出协议里定义的字段。

3.2 定义建模指令协议：JSON 是更好的中间格式

建模指令协议是智能体最重要的接口。协议设计得好，后续新增特征类型只是增加枚举值；设计得不好，每加一种操作都要改解析器和执行器。

以创建类为例，一端的 JSON 可以是：

{ "mission": "create_part", "feature_type": "pad", "profile": { "sketch_plane": "XY", "shape": "circle", "center": [0, 0], "radius": 20 }, "operation": { "direction": "up", "height": 15 }, "unit": "mm" }

改型类的 JSON 则要精准指向目标参数：

{ "mission": "modify_part", "target_parameter": "PartBody.Pad.1.FirstLimit.Length", "new_value": 30, "unit": "mm" }

加特征类的 JSON 需要包含定位信息和几何属性：

{ "mission": "add_feature", "feature_type": "hole", "position": { "support_plane": "top_face", "center": [10, 10] }, "operation": { "diameter": 6, "depth": 8 }, "unit": "mm" }

协议设计时要避免出现“把位置放在圆孔正上方”这类模糊表达。位置、方向、参考面必须能映射到 CATIA 里的几何选择逻辑。

3.3 一个最小执行器：解析 JSON、执行建模、返回结果

执行器是连接大模型和 CATIA 的桥梁。下面给出一个最小框架：

import win32com.client class CatiaAgent: def __init__(self): self.catia = connect_catia() def execute(self, mission_json: dict): mission = mission_json.get("mission") if mission == "create_part": return self.create_part(mission_json) elif mission == "modify_part": return self.modify_part(mission_json) elif mission == "add_feature": return self.add_feature(mission_json) else: raise ValueError(f"unsupported mission: {mission}")

创建零件的方法与前面最小脚本基本一致，只是把参数从外部 JSON 取出来：

def create_part(self, action): part_doc = self.catia.Documents.Add("Part") part = part_doc.Part profile = action["profile"] plane = part.OriginElements.PlaneXY sketch = part.Sketches.Add(plane) sketch.OpenEdition() factory_2d = sketch.Factory2D if profile["shape"] == "circle": x, y = profile["center"] factory_2d.CreateCircle(x, y, profile["radius"]) elif profile["shape"] == "rectangle": # 按传入的宽高和中心点绘制矩形 half_w = profile["width"] / 2 half_h = profile["height"] / 2 cx, cy = profile["center"] factory_2d.CreateLine(cx - half_w, cy - half_h, cx + half_w, cy - half_h) factory_2d.CreateLine(cx + half_w, cy - half_h, cx + half_w, cy + half_h) factory_2d.CreateLine(cx + half_w, cy + half_h, cx - half_w, cy + half_h) factory_2d.CreateLine(cx - half_w, cy + half_h, cx - half_w, cy - half_h) sketch.CloseEdition() part.Update() height = action["operation"]["height"] pad = part.ShapeFactory.AddNewPadFromRef(sketch, height) part.Update() return {"status": "ok", "feature": pad.Name}

这里要特别注意：矩形草图只画了四条线，没有加尺寸约束和重合约束。实际建模中，这种草图可能无法稳定生成预期几何。最小 demo 可以这样跑，但生产级代码必须结合 CATIA 的约束 API 补齐约束。

3.4 改型任务的实现细节

改型是三类任务里最容易被误判为“简单”的。代码层面确实只有三步：找参数、改参数、更新模型。但难点在于如何找到准确参数名。

def list_parameters(part): parameters = part.Parameters for i in range(1, parameters.Count + 1): param = parameters.Item(i) print(param.Name, param.Value, param.Unit)

通过这个方法可以枚举当前 Part 下的全部参数，观察 CATIA 给特征参数自动生成的命名规律。修改参数的代码框架如下：

def modify_part(self, action): part_doc = self.catia.ActiveDocument part = part_doc.Part parameters = part.Parameters param_path = action["target_parameter"] try: param = parameters.Item(param_path) except Exception: return { "status": "failed", "reason": f"parameter {param_path} not found", } param.Value = float(action["new_value"]) part.Update() return { "status": "ok", "parameter": param_path, "new_value": param.Value, }

实际使用时要确认单位。CATIA V5 的界面通常显示毫米，但内部参数值可能会按文档单位存储。如果改完参数后发现模型尺寸和预期相差 1000 倍，通常是单位换算没处理。在执行器里统一维护“协议单位 -> 内部单位”的换算规则会更稳妥。

4. 实测三类任务：设计、改型、加特征

4.1 设计类任务实测：从空白零件生成圆台

设计类任务的完整流程是：用户输入需求 -> 大模型输出 JSON -> 执行器创建草图 -> 添加拉伸特征 -> 更新模型。

以“创建一个底面半径 20mm、高 15mm 的圆柱”为例，预期流程如下：

• 解析层输出 mission 为 create_part，feature_type 为 pad。
• 执行器新建 Part 文档。
• 在 XY 平面上创建圆心在原点、半径 20 的圆。
• 调用 Pad 特征，拉伸高度 15。
• Part.Update 更新模型。

跑通后可以在 CATIA 特征树中看到一个以哈希或数字命名的 Pad 特征，使用测量工具量得的圆柱直径与半径应该符合输入。这里建议使用 CATIA 自带的测量功能，不要只靠代码返回结果判断成功。

4.2 改型类任务实测：修改拉伸高度和圆角半径

改型类任务依赖参数路径的稳定性。实际测试时，先用宏录制创建一次目标模型，再查看特征树里自动生成的参数名。

比较常见的参数路径形态是：

PartBody.Pad.1.FirstLimit.Length PartBody.Fillet.1.Radius PartBody.Hole.1.Diameter

实测时要覆盖两个分支。第一，目标参数存在且可写，修改后模型更新成功；第二，目标参数不存在，执行器应该返回明确错误，而不是直接抛异常。更稳妥的做法是在执行器中加入“改型前备份参数值”的逻辑，一旦模型更新失败可以从内存恢复。

4.3 加特征类任务实测：打孔、圆角、阵列组合

加特征比设计类更依赖几何上下文。例如“在顶面中心打一个直径 6mm、深 8mm 的孔”，执行器必须知道顶面是哪个面、孔中心点的坐标怎么算、孔的轴向指向哪里。

加特征命令的示意代码：

def add_feature(self, action): part_doc = self.catia.ActiveDocument part = part_doc.Part shape_factory = part.ShapeFactory feature_type = action["feature_type"] if feature_type == "hole": # 先选择支撑面和孔中心点 face = self.select_support_face(part, action["position"]["support_plane"]) point = self.create_center_point(face, action["position"]["center"]) hole = shape_factory.AddNewHoleFromRef(face, point) hole.Diameter = action["operation"]["diameter"] hole.Depth = action["operation"]["depth"] part.Update() return {"status": "ok", "feature": hole.Name} if feature_type == "fillet": edge = self.select_edge(part, action["target_edge"]) fillet = shape_factory.AddNewFilletFromRef(edge, action["operation"]["radius"]) part.Update() return {"status": "ok", "feature": fillet.Name}

上面代码中的 select_support_face、create_center_point、select_edge 省略了具体实现，原因是 V5 不同版本的面选择方式存在差异。建议先录一次宏，查看 Automation 给面、边、孔的参数名称，再按宏输出补全这些辅助函数。

4.4 三类任务在链路中的差异

从实验结果看，设计类最容易在“轮廓约束不足”上报错，改型类最容易在“参数路径找不到”上失败，加特征类则最容易因为“参考几何选择错误”生成意料之外的模型。

5. 智能体测试数据集要这样设计

5.1 为什么测试数据集比模型本身更关键

AI 建模智能体的风险不是“模型回答得不够像人”，而是“模型输出看似正确，但 JSON 解析失败”“参数映射到了错误特征”“CATIA 执行成功但几何结果不符合预期”。这些风险只有通过测试数据集才能系统暴露。

测试数据集要做成持续迭代的资产。每一条用例，至少包含四个字段：用户输入文本、期望的结构化 JSON、执行预期结果、几何校验规则。

5.2 分类设计测试用例

测试用例建议至少覆盖创建类、改型类、加特征类和边界类四组。

边界类用例非常容易被忽略。比如“用户说挖一个 3mm 深的孔，但没说直径”，解析层应该补出默认值并要求确认，而不是直接执行。

5.3 评测指标：解析率、映射率、建模完成率

测试结果要用指标量化，否则无法判断提示词改动是否有效。建议至少统计四个指标：

• JSON 可解析率：大模型输出能被 json.loads 正确解析的比例。
• 参数映射准确率：JSON 中的特征类型和参数名能正确映射到 CATIA 对象的比例。
• 建模完成率：CATIA 执行完成且没有抛出异常的比例。
• 几何校验通过率：执行后模型尺寸、位置、特征数量符合预期的比例。

这几个指标的关系是层层过滤的。JSON 可解析率高只代表模型输出格式稳定，不代表建模成功；建模完成率高只代表步骤执行完，不代表几何正确。一个成熟的智能体，四个指标都应该逐步逼近 100%。

5.4 从失败样本反向优化提示词

当测试用例失败时，不要马上改代码。先记录失败类型，再决定改哪一层：

• 如果是 JSON 格式问题，增加提示词里的格式示例。
• 如果是枚举值越界，检查参数映射层是否缺少该类型。
• 如果是 CATIA 执行失败，去看宏录制到底做了什么操作。
• 如果是几何校验不通过，检查约束和参考面选择逻辑。

测试数据集要版本化。每次调整提示词后，对历史用例做回归，避免修复一个问题带来另一个回归。

6. 实测中的常见坑与排查链路

6.1 连接阶段：COM 初始化失败怎么办

现象：Python 执行 GetActiveObject 报错，提示找不到指定对象，或者直接抛出 COM 异常。

可能原因：CATIA 没有打开、Python 和 CATIA 进程位数不一致、pywin32 安装异常、COM 注册信息不完整。

检查方式：先手工打开 CATIA；在 Python 里执行import win32com.client确认模块可用；确认 Python 解释器位数。

处理建议：尽量使用 64 位 Python 配合 64 位 CATIA；如果 CATIA 未启动，可以使用 Dispatch 启动，但启动过程比较慢，建议作为备用路径而不是主路径。

6.2 参数阶段：单位、路径、枚举不一致

现象：参数值修改后模型尺寸变成预期值的 1000 倍；或者 Parameters.Item 报错说找不到该参数。

原因：CATIA V5 内部单位与界面显示单位不一致；特征名后面的编号会随特征创建顺序变化；不同版本对参数路径的大小写和分隔符要求不同。

检查方式：先调用 list_parameters 输出全部参数名；用宏录制比对目标操作的参数路径；用手工测量确认修改后的实际尺寸。

处理建议：在映射层统一做单位换算，不要在业务代码里到处写魔法数字。参数路径尽量避免硬编码，优先通过特征类型和位置动态查找。

6.3 草图约束不足导致更新失败

现象：模型能创建，但更新后轮廓位置偏移，或者弹窗提示草图约束不足、线框不封闭。

原因：执行器只画了几何线条，没有添加尺寸约束和几何约束。CATIA 对复杂轮廓的稳定性依赖约束，让大模型直接输出坐标点画图，通常只能支撑简单圆和矩形。

检查方式：进入草图编辑状态，查看轮廓是否封闭；查看约束符号是否完整；尝试用鼠标拖拽轮廓，看是否发生形变。

处理建议：在最小原型里，优先使用圆形、水平/垂直矩形等简单轮廓。生产环境应该把常用轮廓建成参数化模板，由智能体选择模板并填充参数，而不是逐条线让大模型编排。

6.4 完整排查顺序

遇到智能体建模失败，按下面顺序排查，不要跳步：

这张表可以直接用作智能体调试面板的设计参考。每一层都预留日志，查看日志时能迅速定位问题发生在哪一段，而不是在“不知道是大模型错还是 CATIA 错”的状态里反复试。

7. 从实验到生产：智能体建模的边界与最佳实践

7.1 学习环境与生产环境的差异

原型跑通后，距离生产还有很长的路。两类环境的差异需要单独规划：

生产环境至少要解决“模型被改坏了怎么恢复”的问题。比较稳妥的做法是：在每次执行前复制零件文件；执行后做一次几何校验；校验不通过就放弃当前文件，回滚到执行前版本。

7.2 更可靠的做法：规则库优先，大模型辅助

从长期维护角度看，不要把关键建模步骤全部交给大模型自由生成。更稳的方案是：

• 把企业常用零件和特征固化成参数化模板。
• 由大模型识别用户需求，匹配模板和参数。
• 由代码执行模板展开和特征创建。
• 只有模板覆盖不到的场景，才允许大模型生成新的编排指令，并且必须经过人工审核。

这样做的好处很明显：模板的参数名、约束、更新逻辑都是预先验证过的，大模型只需要做“意图分类”和“参数填充”两件事，出错概率大幅下降。这个思路和智能体工具调用的最佳实践完全一致：让大模型负责决策，让可靠代码负责执行。

7.3 可复用检查清单

在发布或交付一个 CATIA V5 AI 智能体前，建议逐项检查：

• CATIA 许可和自动化接口正常。
• Python 环境与 CAD 进程位数一致。
• 至少跑通一个创建用例、一个改型用例、一个加特征用例。
• 参数单位统一经过换算验证。
• 失败时有日志和模型回滚方案。
• 测试数据集覆盖正常、边界、非法输入。
• 大模型输出经过 JSON Schema 校验。
• 生产环境保留操作审计和模型版本记录。

这套清单同样适用于其他 CAD 平台的自动化智能体，只是对象模型和 API 名称不同。

7.4 下一步扩展方向

如果要在智能体方向继续深入，可以按下面顺序扩展：

• 先把提示词工程学透，重点掌握结构化输出、工具调用和少样本示例。
• 再学模型部署，理解大模型、小模型和智能体产品的边界，除了云端 API，也要了解本地模型如何替换。
• 然后在 CATIA 侧积累宏录制经验，把常用操作录制成模板库。
• 最后把测试数据集和评测指标跑成 CI 流程，每次改提示词和代码都自动回归。

这个路径不需要一上来就学完整套大模型训练技术。对 CAD 自动化项目来说，把规则、参数和校验做扎实，比训练一个更大的模型更有实际价值。