1. 项目概述为什么我们需要一个“跨后端”的CAD中间表示如果你和我一样在工业软件、建筑设计或者产品研发领域摸爬滚打过几年一定会对CAD计算机辅助设计软件的“生态孤岛”问题深有感触。一个简单的场景你用SolidWorks精心设计了一个复杂的机械部件模型文件是.sldprt格式。现在你需要把这个模型交给下游的同事他们用的是基于开源几何内核OCCTOpen CASCADE Technology开发的定制化仿真平台。于是你导出为STEP或IGES这类中性格式。然而噩梦开始了原本漂亮的参数化特征树比如拉伸、旋转、倒角在导入后变成了一堆“哑”的、无法编辑的B-Rep边界表示面片集合。你想在仿真平台上基于原始设计意图微调一个孔的直径对不起你得回到SolidWorks修改再重新导出、导入循环往复。这种基于“文件交换”而非“数据交换”的协作模式严重制约了设计自动化和智能化的步伐。这就是“CADIR: A Cross-Backend Editable Intermediate Representation for Agentic CAD Generation”这个项目试图解决的核心痛点。它不是一个具体的软件而是一个设计理念和一套数据规范。简单来说CADIR旨在创建一个位于不同CAD系统后端之上的、统一的、可编辑的中间表示层。它把不同CAD软件如SolidWorks, CATIA, Fusion 360, 以及基于OCCT、Parasolid、ACIS等内核的自研系统中那些“各说各话”的设计逻辑特征、约束、参数翻译成一种通用的“设计语言”。这样无论是人类设计师还是“智能体”Agent都能在这种通用语言层面上进行操作和推理然后再由CADIR“翻译”回具体后端软件能理解的指令驱动其生成或修改最终的几何模型。想象一下这就像为所有CAD软件建立了一个“联合国”。每个国家CAD软件都有自己的母语原生API和数据格式但联合国代表CADIR之间用同一种工作语言中间表示交流。一个来自“SolidWorks国”的设计意图可以用这种工作语言清晰地传达给“OCCT国”的仿真程序并且这个意图在“OCCT国”依然可以被理解和修改而不是变成一堵无法穿透的“数据墙”。那么它适合谁首先是CAD工具开发者尤其是那些基于OCCT等开源内核进行二次开发需要与商业软件生态对接的团队。其次是研发自动化、智能化设计流程的工程师比如希望用程序或AI智能体批量生成、优化CAD模型的场景。最后对于有复杂多软件协同需求的先进制造企业CADIR提供了一种从根本上提升数据流转效率和设计自由度的可能性。2. CADIR的核心设计思路与架构拆解要理解CADIR我们不能只把它看作一个数据转换器。它的野心更大目标是成为可编辑的设计意图载体。这意味着它存储的不是最终的、固定的三角网格或B-Rep数据而是生成这些数据的“配方”和“约束”。2.1 从“几何交换”到“设计意图交换”的范式转移传统的CAD数据交换如STEP AP203/214, IGES主要关注几何和拓扑信息的保真度可以理解为“结果交换”。它们回答的问题是“这个零件长什么样” 而CADIR关注的是“这个零件是怎么被设计出来的”即“过程交换”。它需要记录特征序列设计是先拉伸一个基座再在上面打孔还是先旋转出一个轴再切出键槽这个顺序很重要因为后续特征的创建往往依赖于前面特征的几何元素如边、面。参数与约束拉伸的高度是多少孔的直径是多少这个孔的圆心是否与那条边线重合重合约束这个面是否与那个面平行平行约束这些参数和约束构成了模型的“智能”。设计历史与依赖关系修改一个早期特征的参数后续依赖它的特征应该如何自动更新这需要清晰地记录特征之间的父子依赖图。CADIR的中间表示本质上就是将这些信息抽象成一套与具体CAD内核无关的、形式化的数据结构。例如它可能定义一个ExtrusionFeature类包含profile_sketch截面草图、direction拉伸方向、distance拉伸距离等属性而不是直接存储拉伸后产生的成千上万个三角面片。2.2 分层架构连接抽象意图与具体实现一个典型的CADIR架构可能包含以下层次统一语义层Unified Semantic Layer这是最顶层定义了跨领域的核心设计概念。比如“草图”、“拉伸”、“旋转”、“放样”、“布尔运算”、“几何约束”、“尺寸约束”等。这一层的定义是高度抽象的不涉及任何具体数学实现。内核适配层Kernel Adapter Layer这是关键桥梁。它为每个支持的CAD后端如OCCT、Parasolid、ACIS实现一套“翻译器”。翻译器有两个方向前向翻译Forward Translation将CADIR中的抽象特征转换为该后端内核API的具体调用。例如将CADIR的ExtrusionFeature翻译为OCCT的BRepPrimAPI_MakePrism或Parasolid的PK_BODY_create_extrusion调用。反向翻译Reverse Translation / Healing更具挑战性。从现有模型如导入的STEP文件中尝试“反求”出可能的设计意图和特征树。这通常需要复杂的几何推理和模式识别是当前研究的热点。持久化与序列化层CADIR的中间表示需要能被保存、传输和版本管理。它可能采用一种基于JSON、XML或自定义二进制格式的序列化方案确保其独立于任何运行时环境。为什么选择OCCT作为重点关注的“后端”从网络热词“occt环境搭建”的流行就能看出OCCT作为一款功能强大、开源免费的几何建模内核正被越来越多的企业和开发者用于构建自主可控的CAD/CAE/CAM软件。然而OCCT的原生API是C的且相对底层直接用它来表述高级设计意图非常繁琐。CADIR可以为OCCT提供一个高级的、更易用的抽象接口同时打通OCCT生态与其他商业CAD软件的壁垒价值巨大。注意实现一个完整的CADIR是极其复杂的工程涉及计算机图形学、计算几何、软件工程等多个领域。目前这更多是一个研究方向和框架设计。实际项目中可能会先实现一个针对特定领域如钣金、注塑件的、功能子集有限的CADIR。3. CADIR中间表示的核心数据结构解析要构建一个可编辑的中间表示我们需要设计一套能够精准捕获设计意图的数据结构。这里我们深入探讨几个核心组成部分。3.1 草图Sketch的表示草图是绝大多数CAD特征的基石。在CADIR中一个草图不仅仅是二维点、线、圆的集合更是一个受约束的二维几何系统。几何实体用基本的几何元素表示如Point2d,LineSegment2d,Arc2d,Circle2d,Spline2d。每个实体都有其参数如圆心坐标、半径。约束系统这是草图的“灵魂”。约束分为两类几何约束定义实体间的相对关系。例如CoincidentConstraint点与点重合点在线上ParallelConstraint线线平行PerpendicularConstraint线线垂直TangentConstraint线与圆相切Horizontal/VerticalConstraint线水平或竖直尺寸约束定义实体的大小或相对位置的距离、角度、半径等。例如DistanceConstraint(p1, p2, 10.0)RadiusConstraint(circle1, 5.0)。关键点在于尺寸约束的参数如10.0, 5.0应该是变量名或表达式而不是固定值以便支持参数化驱动。求解状态一个完整的草图定义后其约束系统可能是“欠约束”多解、“全约束”唯一解或“过约束”矛盾。CADIR需要能表示和检查这种状态。一个“全约束”且“无冲突”的草图才是稳定、可用的。实操心得在实现草图约束求解器时一个常见的坑是数值稳定性问题。当几何元素几乎平行或距离极近时求解器的雅可比矩阵可能接近奇异导致求解失败或结果抖动。实践中需要加入公差判断和正则化处理。例如判断两条线是否平行不能直接用abs(dot(v1, v2) - 1.0) 1e-9而应该用一个稍大的公差如1e-6并做好异常处理。3.2 特征Feature的表示特征是构建模型的操作单元。CADIR需要定义一套标准的特征类型库。基于草图的特征ExtrudeFeature: 包含sketch_id草图引用、direction方向向量、distance拉伸长度可为对称或非对称、operation创建、添加、切除、相交。RevolveFeature: 包含sketch_id、axis旋转轴、angle旋转角度。SweepFeature: 包含profile_sketch_id截面、path_sketch_id路径。LoftFeature: 包含一组section_sketch_ids截面序列。直接几何操作特征FilletFeature: 包含edges要倒圆角的边列表、radius半径值或变量。ChamferFeature: 包含edges、distance倒角距离。ShellFeature: 包含faces_to_remove要移除的面、thickness壁厚。参考与变换特征PatternFeature: 包含pattern_type线性、圆形、instance_count、spacing、axis等。它引用一个或多个要阵列的“父特征”。MirrorFeature: 包含parent_feature、mirror_plane。BooleanFeature: 包含operation并集、差集、交集、body_a,body_b参与运算的实体引用。关键设计每个特征对象都必须包含一个唯一的id以及一个dependencies列表明确记录它依赖于哪些草图或先前特征。这构成了特征依赖图Feature Dependency Graph是支持参数化更新和历史回滚的基础。3.3 参数化系统与设计表参数化是CAD的灵魂。CADIR需要内置一个灵活的变量和表达式系统。变量定义变量有名称、值或表达式、单位如mm, deg。例如hole_diameter 10.0。表达式支持四则运算、三角函数、逻辑判断等。例如total_length base_length 2 * flange_thickness。尺寸约束的参数可以绑定到这些变量或表达式上。设计表可以支持类似Excel表格的配置方式通过切换不同的行配置来批量改变一组变量的值从而驱动模型生成不同的变体。这在自动化设计中非常有用。一个简化的CADIR文档结构示例JSON格式{ version: 1.0, parameters: { plate_width: 100.0, plate_height: 50.0, hole_dia: plate_width / 10 }, sketches: [ { id: sk_base, plane: XY, entities: [...], constraints: [...] }, { id: sk_hole, plane: {offset_from: sk_base, value: 10.0}, entities: [...], constraints: [ {type: distance, entity1: point_center, entity2: ref_edge, value: plate_width/2}, {type: radius, entity: circle_hole, value: hole_dia/2} ] } ], features: [ { id: feat_base, type: extrude, sketch: sk_base, distance: 10.0, operation: new_body }, { id: feat_hole, type: extrude, sketch: sk_hole, distance: 15.0, operation: cut, dependencies: [feat_base] }, { id: feat_fillet, type: fillet, edges: [feat_base.edge_top_front], radius: 2.0, dependencies: [feat_base, feat_hole] } ], active_body: feat_fillet.output }4. 面向“智能体”的CAD生成CADIR如何赋能Agentic CAD“Agentic CAD Generation”是标题中的另一个关键词它指向了CAD应用的未来由AI智能体辅助甚至主导设计过程。CADIR在这里扮演了至关重要的角色。4.1 智能体与CAD系统的交互瓶颈如果没有CADIR一个AI智能体想要生成或修改一个CAD模型它面临几个难题API复杂性直接调用SolidWorks或OCCT的底层API极其复杂需要大量的领域知识智能体难以直接学习。动作空间巨大且连续在像素画布上智能体输出的是每个像素的RGB值动作空间是连续且高维的但可以通过神经网络处理。在CAD中一个“动作”可能是在某个位置画一条线、添加一个约束、执行一个拉伸操作这些动作是离散的、结构化的且具有严格的逻辑顺序。反馈稀疏且延迟智能体执行一系列API调用后可能直到最后才能看到一个完整的模型中间步骤的“奖励”很难定义。4.2 CADIR作为智能体的“行动语言”和“观察空间”CADIR为智能体提供了一个标准化、高层级的交互接口行动Action智能体不再需要调用OCCT_BRepBuilderAPI_MakeEdge而是发出“在草图SK1上于坐标(x,y)处创建一个点”、“在点P1和P2之间添加一个距离约束值为D”、“基于草图SK1执行一个拉伸特征距离为L”这样的高级指令。这些指令直接对应CADIR中定义的操作。动作空间被大大简化和结构化。状态State智能体观察到的不是原始的三角网格或BREP数据而是CADIR的当前状态——有哪些草图、约束满足情况、特征树结构、参数值等。这是一个高度结构化、富含语义信息的观察空间更有利于基于规则的推理或机器学习模型的理解。奖励Reward可以基于CADIR的状态定义更丰富的奖励函数。例如草图是否全约束给予正奖励、特征是否重建成功、模型质量如壁厚是否均匀、是否存在自相交等。应用场景示例一个基于强化学习的拓扑优化智能体。传统拓扑优化输出一个密度场需要人工重新建模。有了CADIR智能体可以学习直接输出一系列“拉伸”、“切除”等特征操作生成一个可直接编辑、符合设计规范的CAD模型大大缩短从优化结果到可制造模型的路径。4.3 实现挑战与注意事项让智能体在CADIR层面进行操作同样面临挑战动作有效性验证智能体可能提出一个无效操作比如对一个欠约束的草图添加一个过约束的尺寸。CADIR需要有一个强大的有效性检查器能够实时拒绝无效动作并给出错误原因这可以作为智能体的负反馈。长期规划与依赖管理设计是一个强依赖的顺序过程。智能体需要理解“先有草图才能拉伸先有基体才能打孔”这样的逻辑。这要求智能体具备长序列规划和依赖关系理解的能力或者CADIR环境能提供强大的依赖关系提示。从像素/点云到CADIR的逆向转换如果智能体是从一张图片或一个点云开始设计它首先需要具备从这些数据中“解读”出可能的草图、特征和参数的能力即逆向工程到CADIR。这是计算机视觉与CAD的交叉前沿问题。实操心得在初期搭建用于AI训练的CADIR仿真环境时不建议一开始就对接真实的OCCT或商业CAD内核。因为真实内核的重建操作可能很慢且不稳定。一个高效的策略是先实现一个轻量级的、纯Python的几何推理和验证引擎。这个引擎不生成真实的B-Rep但可以验证草图约束是否可解、特征操作在逻辑上是否有效、参数是否在合理范围。用这个轻量环境进行AI算法的快速原型和训练待策略成熟后再连接到真实CAD内核进行最终模型生成和渲染。这能极大提升开发迭代效率。5. 基于OCCT后端的适配器实现详解OCCT作为广泛应用的开源内核是CADIR后端适配的重要目标。本节我们深入探讨如何实现一个连接CADIR与OCCT的适配器。5.1 前向翻译从CADIR特征到OCCT建模命令适配器的核心是一个“特征解释器”它将CADIR的抽象特征逐条翻译为OCCT的API调用序列。以ExtrudeFeature为例解析草图首先需要将CADIR中的草图包含几何实体和约束在OCCT中重建。遍历草图实体调用OCCT的gp_Pnt,GC_MakeLine,GC_MakeCircle等工具创建相应的几何对象。关键难点CADIR中的约束系统需要在OCCT中通过构造几何关系或后续的BRepBuilderAPI_Transform来满足而不是直接应用OCCT的约束求解器OCCT的约束求解主要在草图模块但功能不如专业CAD。一种实用方法是在CADIR层确保草图是全约束且已求解的适配器只使用求解后的最终几何形状点、线位置来创建OCCT的拓扑边BRepBuilderAPI_MakeEdge。创建拓扑将草图边连接成闭合的线框TopoDS_Wire然后使用BRepBuilderAPI_MakeFace创建面。执行拉伸使用BRepPrimAPI_MakePrism或更通用的BRepOffsetAPI_MakeThickSolid对于加厚拉伸来生成实体。应用布尔运算根据operation字段使用BRepAlgoAPI_Fuse并集、BRepAlgoAPI_Cut差集、BRepAlgoAPI_Common交集将新生成的实体与已有实体进行运算。历史记录与引用映射这是实现可编辑性的关键。适配器必须维护一个映射表将CADIR中每个特征、草图实体的ID与生成的OCCT拓扑形状TopoDS_Shape及其子元素面、边、顶点关联起来。当后续特征如倒角引用前面特征的某条边时适配器需要通过这个映射表找到OCCT中对应的TopoDS_Edge。代码片段示意C// 伪代码展示流程 TopoDS_Shape OCCAdapter::buildExtrude(const ExtrudeFeature feat) { // 1. 获取草图几何已由CADIR求解 const Sketch sketch getSketch(feat.sketch_id); // 2. 在OCCT中构建线框 TopoDS_Wire wire buildWireFromSolvedSketch(sketch); // 3. 创建面 TopoDS_Face face BRepBuilderAPI_MakeFace(wire); // 4. 沿方向拉伸 gp_Vec vec(feat.direction * feat.distance); TopoDS_Shape prism BRepPrimAPI_MakePrism(face, vec); // 5. 与目标体进行布尔运算 TopoDS_Shape targetBody getShape(feat.target_body_id); switch(feat.operation) { case OP_NEW: return prism; case OP_ADD: return BRepAlgoAPI_Fuse(targetBody, prism); case OP_CUT: return BRepAlgoAPI_Cut(targetBody, prism); // ... } // 6. 记录新形状与特征的映射关系 registerShapeMapping(feat.id, resultShape); return resultShape; }5.2 反向翻译与模型愈合从OCCT形状恢复CADIR意图这是更具挑战性的部分通常称为“特征识别”或“设计意图恢复”。给定一个来自STEP文件的“哑”模型一个纯粹的B-Rep如何推测出它的创建历史几何分析与模式匹配识别规则特征通过分析面的类型平面、圆柱面、圆锥面等和相邻关系可以识别出可能的拉伸、旋转特征。例如一个零件如果包含一组平行的平面和连接它们的圆柱面可能对应一个拉伸特征。识别孔、槽、倒角通过分析凹边、凸边以及面的凹凸性识别出标准的孔特征圆柱面与平面垂直相交、倒角特征等距的斜面等。草图轮廓提取对于一个疑似拉伸特征需要找到它的“起始面”和“终止面”并提取它们之间侧面圆柱面或平面的边界反推出原始的草图轮廓。约束推断在提取的草图轮廓上分析几何关系。例如两条边是否平行或垂直多个圆是否同心或等半径这些可以推断出潜在的几何约束。构建特征树识别出的特征需要排序。通常先识别基础特征最大的材料块再识别在其上的添加凸台或切除孔、槽特征。布尔运算关系也需要被识别。注意事项反向翻译很难做到100%准确和完整尤其是对于复杂或非参数化创建的模型。因此实践中常采用“交互式修复”模式系统给出一个最可能的特征树猜测允许用户进行确认、合并、拆分或手动添加特征。恢复出的CADIR模型其参数可能是一个固定值而不是变量但至少获得了可编辑的特征结构。5.3 OCCT环境搭建与依赖管理从“occt环境搭建”这个热词可以看出用好OCCT本身就有门槛。在CADIR适配器开发中需要特别注意版本管理OCCT不同版本API可能有变化。项目应明确依赖的OCCT版本如7.7.0并使用CMake等工具管理编译。第三方依赖OCCT可能依赖Tcl/Tk、FreeType等。在打包或部署适配器时需要妥善处理这些动态库。内存管理OCCT大量使用句柄Handle模式需遵循其引用计数规则避免内存泄漏。尤其注意TopoDS_Shape的拷贝是浅拷贝修改副本会影响原始形状除非显式地TopoDS_Shape::Copy()。异常处理OCCT操作特别是布尔运算可能因几何问题如微小间隙、自相交而失败。适配器代码必须包含健壮的异常捕获和错误处理逻辑并将友好的错误信息反馈给CADIR层或用户。6. 常见问题、挑战与实战排查技巧在实际开发和集成CADIR概念时会遇到一系列典型问题。以下是一些实录与应对策略。6.1 几何内核操作失败与模型修复问题描述在将CADIR特征翻译为OCCT操作时布尔运算如切割、融合经常失败报错如“布尔运算错误”、“无效的输入形状”。根因分析几何精度问题从CADIR草图生成的几何形状可能存在微小的缝隙或重叠这在数学上是无效的。例如一个本应闭合的草图线框其起点和终点在数值上相差1e-10mmOCCT会认为它未闭合。退化几何拉伸距离为0或草图包含极短的边接近0长度。拓扑不一致在进行多次布尔运算后模型的拓扑结构可能变得非常复杂包含一些“几乎为零”的面积或体积导致后续操作失败。排查与解决技巧草图预处理在将CADIR草图传递给OCCT前进行几何清理。包括合并距离极近的点确保线框严格闭合首尾点强制重合移除长度小于公差如1e-7mm的边。使用容差OCCT的布尔运算API通常允许指定容差fuzzy tolerance。适当增大容差如从默认的1e-7增加到1e-5可以容忍一些微小的几何缺陷。BRepAlgoAPI_Cut cutter; cutter.SetArguments(shape1, shape2); cutter.SetFuzzyValue(1e-5); // 设置容差 cutter.Build(); if (!cutter.IsDone()) { /* 处理错误 */ }模型修复工具OCCT提供了ShapeFix包包含一系列修复工具如ShapeFix_Wire,ShapeFix_Face。在关键步骤后对形状进行修复。Handle(ShapeFix_Shape) sfs new ShapeFix_Shape(myShape); sfs-Perform(); TopoDS_Shape fixedShape sfs-Shape();分步验证在构建复杂特征时每完成一个步骤如创建草图面、拉伸都检查生成形状的BRepCheck_Analyzer是否有效。将问题隔离在最小步骤。6.2 参数更新与模型重建的性能瓶颈问题描述当修改一个位于特征树根部的早期参数如基板长度时整个模型需要从头重建。对于复杂模型重建速度很慢交互体验差。优化策略增量更新并非所有特征都需要完全重建。分析特征依赖图只重建那些直接或间接依赖于被修改参数的特征。这需要适配器维护精细的依赖关系和中间形状缓存。并行重建对于依赖图中没有相互依赖关系的分支特征可以尝试并行重建。但需要注意OCCT本身可能不是线程安全的需要对不同分支使用独立的OCCT资源上下文。延迟计算与预览对于频繁的交互式参数拖动可以采用“延迟计算”策略。先快速更新CADIR的数据结构并提供一个简化的视觉反馈如边界框或关键轮廓线待用户释放鼠标后再触发完整的OCCT重建。简化模式在参数调整期间可以暂时用简化表示如不执行复杂的倒角、圆角来加速重建待参数确定后再应用所有细节特征。6.3 跨后端一致性挑战问题描述同一个CADIR模型在OCCT后端和另一个商业CAD后端如Parasolid生成的结果在几何上可能存在细微差异导致下游应用如CAE分析结果不一致。原因与应对内核算法差异不同几何内核的布尔运算、曲面求交、圆角生成算法实现不同可能导致1e-6毫米级别的差异。容差设置不同各内核默认的内部容差不一致。应对策略定义参考后端指定一个后端作为“黄金标准”其他后端的输出与之进行容差范围内的对比验证。标准化容差在CADIR规范中明确定义几何操作应使用的容差值并要求所有适配器遵守。面向应用的验证如果差异对最终应用如数控加工路径生成无影响则可以接受。关键是在工作流程中明确“一致性”的验收标准。6.4 版本控制与协作冲突问题描述CADIR文件作为文本或结构化数据如JSON虽然比二进制CAD文件更适合用Git管理但当多人同时修改一个复杂模型的参数或特征时合并冲突依然难以解决。实战技巧细粒度存储将模型的不同部分如不同子装配体、不同特征组存储为独立的CADIR文件或文件内的独立区块。这样冲突通常发生在文件或区块级别易于管理。参数与结构分离将模型的参数化数据变量表、设计表与特征结构定义分开存储。参数文件更小变更更频繁但冲突相对容易解决通常是数值冲突。结构文件更稳定。使用自定义合并工具对于CADIR这种领域特定语言DSL可以开发一个简单的三向合并工具。它不仅能处理文本行冲突还能理解部分语义。例如当两个分支都修改了同一个参数的值时工具可以提示用户选择其中一个值而不是展示一堆JSON冲突标记。基于操作的CRDT对于实时协作场景可以考虑使用“操作转换”或“无冲突复制数据类型”的思想。将每一次用户操作如“将参数A从10改为20”、“在特征F后插入新特征G”记录为一条不可变的指令。同步时交换和重放这些指令确保最终状态一致。但这需要极其严谨的操作定义和冲突解决规则。开发CADIR或类似系统是一个在理想完美的设计意图交换与现实几何内核的复杂性、性能约束之间不断权衡和妥协的过程。从我个人的经验来看不要试图一开始就构建一个包罗万象的通用CADIR。最好的切入点是选择一个非常具体的垂直领域例如仅支持创建参数化的齿轮、钣金折弯件或PCB安装板定义该领域最小必要特征集实现它与一两个后端的稳定对接。用这个最小可行产品解决实际业务痛点获取反馈再逐步扩展其能力和范围。这种务实、迭代的方式远比一个庞大而脆弱的概念原型更有生命力也更能让我们这些一线工程师真正感受到技术演进带来的效率提升。
