从工程实现来看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。开发方式语言优点缺点适用场景VBA 宏VBA录制简单、上手快跨进程调度弱、不利于工程化手工录宏、快速确认 APIAutomation APICOM可被 Python、C# 等调用对象模型复杂、版本差异存在智能体执行器、自动化脚本CAAC功能最全、性能最好编译环境重、学习成本高复杂插件、深度集成对 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(visibleTrue): try: catia win32com.client.GetActiveObject(CATIA.Application) except Exception: catia win32com.client.Dispatch(CATIA.Application) catia.Visible visible return catiaGetActiveObject 会尝试连接已经打开的 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, radius20.0, height15.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(funsupported 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: fparameter {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_partfeature_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 三类任务在链路中的差异任务类型核心输入主要依赖失败风险点设计类轮廓类型、尺寸、拉伸高度草图绘制与 Pad 特征草图不闭合、更新失败改型类参数路径、新值Part.Parameters 对象参数路径不一致、单位错误加特征类参考面、定位点、特征参数几何选择与特征定位参考面失效、定位点偏移从实验结果看设计类最容易在“轮廓约束不足”上报错改型类最容易在“参数路径找不到”上失败加特征类则最容易因为“参考几何选择错误”生成意料之外的模型。5. 智能体测试数据集要这样设计5.1 为什么测试数据集比模型本身更关键AI 建模智能体的风险不是“模型回答得不够像人”而是“模型输出看似正确但 JSON 解析失败”“参数映射到了错误特征”“CATIA 执行成功但几何结果不符合预期”。这些风险只有通过测试数据集才能系统暴露。测试数据集要做成持续迭代的资产。每一条用例至少包含四个字段用户输入文本、期望的结构化 JSON、执行预期结果、几何校验规则。5.2 分类设计测试用例测试用例建议至少覆盖创建类、改型类、加特征类和边界类四组。分类用例示例预期结果创建类创建直径 40mm、高 15mm 的圆柱特征树出现 Pad测量直径 40创建类创建 100x60x8 底板矩形草图完整拉伸高度 8改型类把第一个拉伸高度改成 30mm目标参数值变为 30模型更新改型类把不存在的参数改成 20返回参数不存在模型不变化加特征类在顶面中心打直径 6、深 10 的孔Hole 特征生成孔位置符合预期加特征类给方板四角添加 R5 圆角Fillet 特征生成半径 5边界类拉伸高度为负数执行器拦截或返回错误边界类草图画了不闭合轮廓明确提示草图错误边界类用例非常容易被忽略。比如“用户说挖一个 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 完整排查顺序遇到智能体建模失败按下面顺序排查不要跳步阶段检查内容关键日志或现象处理思路输入用户原话是否含歧义mission 字段为空补充规则或追问解析JSON 是否能解析JSONDecodeError增加提示词示例映射feature_type 是否被支持unsupported mission扩展协议枚举执行CATIA 是否抛出 COM 异常HResult 负数对比宏录制结果校验尺寸和特征是否符合预期测量值 mismatch修正约束或回滚重试这张表可以直接用作智能体调试面板的设计参考。每一层都预留日志查看日志时能迅速定位问题发生在哪一段而不是在“不知道是大模型错还是 CATIA 错”的状态里反复试。7. 从实验到生产智能体建模的边界与最佳实践7.1 学习环境与生产环境的差异原型跑通后距离生产还有很长的路。两类环境的差异需要单独规划维度学习环境/原型生产环境大模型云端 API 接受能快速验证效果数据不出域时优先本地模型模型输出人工判断即可必须做 JSON Schema 严格校验建模执行直接改活动文档失败可手工回滚使用副本模型或版本控制日志打印到控制台结构化日志 操作审计权限不限制按工程师角色控制操作范围异常处理捕获并打印自动备份 事务式恢复生产环境至少要解决“模型被改坏了怎么恢复”的问题。比较稳妥的做法是在每次执行前复制零件文件执行后做一次几何校验校验不通过就放弃当前文件回滚到执行前版本。7.2 更可靠的做法规则库优先大模型辅助从长期维护角度看不要把关键建模步骤全部交给大模型自由生成。更稳的方案是把企业常用零件和特征固化成参数化模板。由大模型识别用户需求匹配模板和参数。由代码执行模板展开和特征创建。只有模板覆盖不到的场景才允许大模型生成新的编排指令并且必须经过人工审核。这样做的好处很明显模板的参数名、约束、更新逻辑都是预先验证过的大模型只需要做“意图分类”和“参数填充”两件事出错概率大幅下降。这个思路和智能体工具调用的最佳实践完全一致让大模型负责决策让可靠代码负责执行。7.3 可复用检查清单在发布或交付一个 CATIA V5 AI 智能体前建议逐项检查CATIA 许可和自动化接口正常。Python 环境与 CAD 进程位数一致。至少跑通一个创建用例、一个改型用例、一个加特征用例。参数单位统一经过换算验证。失败时有日志和模型回滚方案。测试数据集覆盖正常、边界、非法输入。大模型输出经过 JSON Schema 校验。生产环境保留操作审计和模型版本记录。这套清单同样适用于其他 CAD 平台的自动化智能体只是对象模型和 API 名称不同。7.4 下一步扩展方向如果要在智能体方向继续深入可以按下面顺序扩展先把提示词工程学透重点掌握结构化输出、工具调用和少样本示例。再学模型部署理解大模型、小模型和智能体产品的边界除了云端 API也要了解本地模型如何替换。然后在 CATIA 侧积累宏录制经验把常用操作录制成模板库。最后把测试数据集和评测指标跑成 CI 流程每次改提示词和代码都自动回归。这个路径不需要一上来就学完整套大模型训练技术。对 CAD 自动化项目来说把规则、参数和校验做扎实比训练一个更大的模型更有实际价值。