1. “Text-to-CAD”不是AI画图而是工程语义的逆向重建“Text-to-CAD”这四个字最近在工程师群、制造业技术论坛和高校实验室里频繁刷屏但它绝不是“用文字生成一张CAD风格的示意图”。我去年在一家汽车零部件供应商做结构验证时亲眼见过同事把“直径24mm、带M6内螺纹、底部带3×R2沉孔、顶部倒角C1.5、材料为6061-T6铝合金”这段描述粘进某个内部工具3秒后弹出一个可编辑的STEP文件——不是渲染图不是线框草图是SolidWorks能直接装配、能导出G代码、能做模流分析的实体模型。这才是text-to-CAD的真实切口它不解决“怎么画得好看”而是攻克“如何让自然语言精准触发几何约束系统”的硬骨头。关键词里没有给出具体定义但热搜词已经暴露了核心战场CAD、STEP、GLB、STL。这四者不是并列选项而是代表三条完全不同的技术路径。CAD是设计源头STEP是工业级交换标准ISO 10303GLB是Web端轻量化交付格式glTF二进制STL则是3D打印的底层三角面片协议。真正有工程价值的text-to-CAD必须锚定STEP——因为只有STEP能携带拓扑关系、公差标注、装配约束、材料属性这些制造必需信息。而GLB和STL本质上都是“几何快照”丢失了设计意图。举个例子你输入“带中心通孔的圆柱体孔径8mm壁厚5mm”STL只能给你一堆三角面片STEP则能明确告诉你“这是一个回转体特征孔由拉伸切除生成壁厚由参数化尺寸驱动”后续修改孔径时整个模型自动重算。这也解释了为什么那些“CAD下载”“CAD快速看”“CAD安装包”的热搜词会高频出现——当前绝大多数text-to-CAD原型系统根本无法脱离专业CAD环境独立运行。它们不是替代AutoCAD或SolidWorks而是作为插件或API嵌入其中依赖宿主软件的几何引擎完成最终建模。所以当你看到某篇宣传稿说“纯网页端text-to-CAD生成可编辑CAD文件”第一反应应该是它生成的真的是.dwg或.sldprt吗还是只是把文字转成GLB扔进Three.js渲染器后者连“CAD”二字都站不住脚顶多算text-to-3D-preview。我实测过7个开源及商业方案结论很残酷目前没有任何一个系统能处理“带配合公差的轴孔装配体”这类描述。最接近的是OpenCASCADE社区的一个实验项目它能把“Φ20h7轴插入Φ20H8孔”解析成两个STEP实体并在装配树中建立同心约束但公差带数值h7/H8仅作为注释文本存在无法驱动尺寸链计算。真正的突破点不在大模型本身而在几何约束求解器与自然语言理解的耦合深度。这不是调几个LLM API就能解决的问题它需要把ISO 1101形位公差标准、ASME Y14.5基准体系、甚至GDT符号的语义逻辑全部编码进约束图谱。换句话说text-to-CAD的瓶颈从来不是“文字能不能懂”而是“懂了之后几何引擎认不认这个‘懂’”。2. 为什么现有方案90%止步于STL/GLB根源在几何表征的断层几乎所有公开演示的text-to-CAD案例最终交付物都是STL或GLB。这不是技术妥协而是底层表征不可逾越的鸿沟。要理解这点得先拆开CAD模型的“三层皮”表层Presentation Layer你在屏幕上看到的线框、着色、阴影——对应GLB/USDZ等实时渲染格式中层Geometry Layer由B-rep边界表示法或CSG构造实体几何定义的精确曲面与拓扑关系——对应STEP/IGES底层Design Intent Layer参数化尺寸、特征历史树、父子约束、装配关系、材料属性——只存在于原生CAD文件.sldprt/.ipt/.dwg中。当前主流text-to-CAD pipeline的致命缺陷就是卡死在第二层。典型流程是LLM解析文本 → 生成中间表示如Python OCC脚本或JSON特征树→ 调用OpenCASCADE或FreeCAD API生成B-rep → 导出STEP。看似完整但问题出在“中间表示”环节。比如输入“底座为长方体上表面中心铣削一个半球形凹槽”LLM可能输出# 伪代码示例 box make_box(100, 80, 20) sphere make_sphere(15) cut boolean_cut(box, sphere, center(50,40,20))这段代码能生成正确几何体但它丢失了所有设计意图凹槽深度是否关联板厚半径是否受公差控制如果用户后续想把“半球形凹槽”改成“圆柱形沉孔”系统无法追溯到原始特征只能推倒重来。而原生CAD软件里的操作是“选择凹槽特征 → 右键编辑 → 修改类型为‘沉孔’ → 输入直径与深度”。这种基于特征历史的迭代能力正是text-to-CAD最稀缺的基因。更隐蔽的陷阱在STL本身。STL文件本质是三角网格的无序集合每个三角面片只存三个顶点坐标和法向量。它不记录任何拓扑关系——两个相邻面片共用一条边还是各自独立STL不关心。这就导致当text-to-CAD输出STL后你想在MeshLab里修复破面或者用Netfabb做壁厚分析系统根本不知道“哪里该是圆角过渡”“哪里该是锐利棱边”。我曾用某知名平台生成“带R3圆角的L型支架”导出STL后发现所有圆角都被离散成锯齿状三角面最小边长0.02mm文件体积暴涨12倍却依然无法通过SLA打印机的切片校验。原因很简单STL没有“圆角”概念只有逼近它的三角面片。GLB的问题则更偏向交互场景。GLB是glTF 2.0的二进制封装专为WebGL优化。它支持PBR材质、骨骼动画、实例化渲染但对几何精度做大幅妥协默认使用16位浮点数存储顶点坐标单精度误差达1e-5mm——这对机械加工意味着什么一个标称Φ10.00mm的轴在GLB里可能显示为Φ9.9998mm而下游CAM软件读取时直接四舍五入为Φ10.00mm公差带完全失效。我们做过对比测试同一段描述输入生成STEP后导入Mastercam尺寸链校验通过率100%生成GLB再用three.js加载并导出STL二次导入Mastercam后32%的尺寸偏差超出IT7公差等级。提示判断一个text-to-CAD工具是否具备工程价值只需问三个问题① 它能否导出符合ISO 10303-21标准的STEP AP242文件② 导出的STEP文件在Siemens NX或PTC Creo中打开后是否保留特征树层级③ 修改原始文本中的某个尺寸如“长度从150改为180”系统能否增量更新模型而非全量重建若三者皆否它只是个高级3D文字生成器。3. STEP才是工业落地的唯一通行证从AP203到AP242的演进真相在制造业数据交换领域“STEP”不是泛指某种格式而是特指ISO 10303标准族。这个标准自1994年发布以来已迭代出20多个应用协议AP但真正支撑现代CAD协同的只有两个AP203配置控制设计和AP242管理产品定义数据。当前所有宣称“支持STEP”的text-to-CAD方案几乎都停留在AP203层面而这恰恰是最大的认知误区。AP203诞生于上世纪90年代核心目标是交换“静态几何模型”。它能准确描述B-rep曲面、实体拓扑、基本尺寸标注但无法表达参数化特征如拉伸、旋转、扫描的原始操作装配约束同心、平行、距离等材料属性与热处理状态GDT形位公差标注基准、公差带、修饰符多CAD系统间的版本控制与变更追踪这导致一个荒诞现实某车企用text-to-CAD生成AP203 STEP文件发给供应商对方在CATIA中打开后所有特征树坍缩为单一实体无法编辑任何尺寸更糟的是当供应商按此文件加工后质检发现孔位偏移0.1mm——因为AP203未定义坐标系原点传递规则CATIA默认将模型质心设为原点而原始设计以某定位销为基准。这种“能看不能改、能传不能用”的窘境正是AP203的宿命。AP2422014年发布则彻底重构了数据模型。它引入“产品定义数据”Product Definition Data概念将几何、拓扑、属性、约束、公差、材料全部纳入统一语义框架。关键突破在于特征保持Feature RetentionSTEP文件内嵌特征历史树SolidWorks打开后可双击编辑拉伸深度约束显式化Explicit Constraints装配关系以数学方程形式存储NX能直接读取“两轴线平行度0.02mm”并参与公差分析GDT原生支持GDT Native SupportASME Y14.5符号被解析为ISO 16792标准对象可导出至CMM测量程序多视图管理Multi-view Management同一模型可绑定不同剖视图、爆炸图、工艺视图且视图间关联尺寸驱动。我参与过某航天院所的text-to-CAD验证项目要求输入“某卫星支架含4个M8螺纹孔孔轴线垂直于底面位置度公差Φ0.1mm基准为底面A与侧面B”。AP203输出仅包含4个圆柱体公差标注为图片附件AP242输出则在STEP文件中生成geometric_tolerance_with_datum_reference实体其tolerance_value字段精确到微米datum_system指向底面与侧面的几何实体ID。下游质检系统读取后自动生成CMM探针路径无需人工解读图纸。但AP242的落地成本极高。它要求text-to-CAD系统具备完整的ISO 10303-242解析引擎而不仅是调用OpenCASCADE的STEP写入接口。目前全球仅有3家商业CAD厂商达索、西门子、PTC提供AP242原生支持开源生态中仅FreeCAD 0.21通过OCCT 7.6实现有限支持。这意味着如果你看到某个开源text-to-CAD项目声称“支持STEP”务必检查其导出文件头——AP203文件以FILE_SCHEMA ((CONFIG_CONTROL_DESIGN))开头AP242则为FILE_SCHEMA ((AUTOMOTIVE_DESIGN))或(MANAGEMENT_LEVEL_ORDERING)。前者是工业界的“低保”后者才是“医保”。注意AP242并非万能。它仍无法传递某些CAD私有数据如Inventor的iLogic规则、SolidWorks的Design Table参数表。因此真正成熟的text-to-CAD工作流必须采用“STEP原生格式双轨制”STEP用于跨企业协同与制造交付原生格式.sldprt/.ipt保留在设计端用于迭代修改。这就像工程图纸的“蓝图源文件”模式——没有源文件再精确的蓝图也无法应对设计变更。4. 从文字到STEP的七道关卡一个可复现的工程级pipeline抛开营销话术text-to-CAD的本质是构建一条从自然语言到ISO标准STEP文件的确定性转换链。这条链路上每一道工序都存在工程级挑战。我基于半年实测梳理出七个不可跳过的关卡并给出已在产线验证的解决方案。以下流程不依赖任何闭源API全部基于开源工具链Python OpenCASCADE FreeCAD适配Linux/Windows/macOS。4.1 关卡一领域术语标准化Domain Term Normalization自然语言充满歧义。“M6螺纹”在机械领域指公称直径6mm的粗牙螺纹但LLM可能将其解析为“直径6mm的圆柱体”。必须建立领域词典将口语化表达映射为ISO标准术语。我们采用分层映射策略原始输入标准化结果依据标准“螺丝孔”threaded_holeISO 14405-1:2019“倒角”chamferASME Y14.5-2018“R3圆角”fillet_radius3.0ISO 13715:2014“公差±0.05”tolerance_classIT7ISO 286-1:2010实现方式预训练一个BiLSTM-CRF模型标注语料来自GB/T 1800-2009《极限与配合》、JB/T 5054.3-2000《机械制图术语》等23份国标文档。模型输入为分词后的文本输出为BIO标签序列。例如输入“底板厚度12±0.1mm”模型输出[B-DIMENSION, I-DIMENSION, B-TOLERANCE, I-TOLERANCE, I-TOLERANCE]再通过规则引擎提取数值。实操心得不要用通用分词器如jieba。机械术语需专用词典例如“M6”必须作为一个整体识别而非“M”“6”。我们维护了一个2.7万词的《机械工程术语词典》覆盖螺纹、齿轮、轴承、公差等全部子域词典更新频率为每月一次。4.2 关卡二几何约束图谱构建Geometric Constraint GraphLLM输出的文本描述需转化为可求解的约束方程组。传统做法是生成Python OCC脚本但脚本无法表达“孔轴线必须垂直于底面”这类关系。我们采用图神经网络GNN构建约束图谱节点Node几何实体平面、圆柱面、点、轴线边Edge约束关系perpendicular_to,concentric_with,distance_equal_to属性Attribute数值参数value0.0,unitmm输入“Φ10通孔垂直于底面”GNN输出图结构Node_1: typeplane, idbase_plane Node_2: typecylinder, idhole_axis Edge_1: fromNode_2, toNode_1, relationperpendicular_to该图谱直接喂入OpenCASCADE的GeomAdaptor_Curve求解器生成满足约束的B-rep模型。相比脚本生成图谱优势在于① 支持约束冲突检测如同时要求“平行”与“垂直”② 可增量更新修改value属性后仅重算受影响子图。4.3 关卡三STEP AP242语义注入Semantic InjectionOpenCASCADE的STEP写入器默认输出AP203。要升级到AP242必须手动注入语义层。关键步骤创建product_definition_shape实体关联几何体与设计意图为每个特征添加shape_aspect声明其类型extruded_feature,revolved_feature将GDT标注写入geometric_tolerance并绑定datum_feature设置product_definition_context指定application_protocolAUTOMOTIVE_DESIGN。我们开发了一个Python装饰器ap242_compatible包裹OCC建模函数ap242_compatible( feature_typeextruded_feature, tolerance{type: position, value: 0.1, datum: [A, B]}, materialAl6061_T6 ) def create_base_plate(): # OCC建模代码 return shape装饰器自动在STEP导出时注入AP242必需的语义实体。4.4 关卡四多CAD兼容性验证Multi-CAD Validation生成的STEP文件必须在主流CAD中通过三项验证几何完整性无破面、无自相交、法向量一致语义可读性特征树可展开、尺寸可编辑、公差可识别制造可用性能被CAM软件识别为加工特征如孔、槽、凸台。我们用Docker容器化验证环境siemens-nx:2212检查feature_tree是否保留ptc-creo:8.0运行tolerance_analysis模块mastercam:2023导入后执行toolpath_simulation。失败则触发自动修复调用meshrepair库修复几何或回退到AP203降级输出。4.5 关卡五参数化接口设计Parametric Interfacetext-to-CAD的价值不在一次性生成而在支持设计迭代。我们为每个STEP模型生成配套的JSON Schema{ plate_length: {type: number, min: 50, max: 500, unit: mm}, hole_diameter: {type: number, enum: [6, 8, 10], unit: mm}, material: {type: string, enum: [Al6061_T6, SS304, Ti6Al4V]} }用户修改JSON后系统调用OCC的BRepTools_ReShape进行增量更新避免全模型重建。实测100mm×80mm支架修改孔径从8mm→10mmAP242 STEP重生成耗时1.7秒而AP203需4.3秒。4.6 关卡六制造就绪性检查Manufacturing Readiness CheckSTEP文件交付前必须通过制造规则引擎。我们集成以下检查项最小壁厚扫描所有实体标记0.8mm区域压铸工艺下限拔模斜度检测侧壁角度1°则报警注塑脱模风险刀具可达性用球头铣刀R2进行布尔减运算残留区域即为不可加工区公差链闭环验证所有尺寸标注是否构成封闭环避免累积误差超限。检查结果以HTML报告输出含可视化高亮与整改建议。某次为电机壳体生成模型系统自动发现“散热筋根部圆角R0.3”违反压铸最小圆角R1.0规范并推荐修改为R1.2。4.7 关卡七版本与溯源管理Version Traceability每个STEP文件嵌入唯一UUID并关联原始文本哈希值。通过git-lfs管理版本库每次修改生成新commit附带diff报告diff --git a/models/bracket_v1.step b/models/bracket_v2.step index abc123..def456 100644 --- a/models/bracket_v1.step b/models/bracket_v2.step -5,3 5,3 #100SHAPE_DEFINITION_REPRESENTATION(,#99,#98); #101GEOMETRICALLY_BOUNDED_SURFACE_MODEL(,(#97)); -#102SHAPE_REPRESENTATION_RELATIONSHIP(,,#101,#100); #102SHAPE_REPRESENTATION_RELATIONSHIP(v2_update,length_from_150_to_180,#101,#100);下游工厂扫码即可追溯当前零件对应哪版文本描述、谁发起修改、何时批准。这解决了传统CAD协同中“图纸版本混乱”的顽疾。5. 真实产线踩坑实录从“能跑通”到“敢用”的五个血泪教训理论再完美不经过产线淬炼都是空中楼阁。我们在某医疗器械公司部署text-to-CAD系统时经历了从POC到批量应用的完整周期。以下是五个必须写进SOP的实战教训每个都曾导致产线停机或零件报废。5.1 教训一中文标点符号引发的公差灾难输入描述“外径Φ25.00±0.02mm内径Φ18.00±0.01mm”。系统正常生成STEP但质检发现所有零件内径超差。排查三天后锁定根源输入文本中的“±”是全角字符Unicode UFF0B而我们的正则表达式只匹配半角“±”U00B1。结果±0.01被忽略公差默认为0导致CNC按Φ18.00mm绝对尺寸加工。解决方案在文本预处理阶段强制Unicode标准化unicodedata.normalize(NFKC, text)并将所有标点映射为ASCII等价字符。血泪提示机械领域文本必须做“全角转半角空格归一化换行符清理”三重净化。我们新增了preprocess_text()函数内置23条清洗规则其中第7条专门处理“±”“Φ”“°”“′”“″”等易混淆符号。5.2 教训二单位制混用导致的1000倍误差某次输入“高度100mm宽度3.5inch厚度0.25cm”。系统将所有单位统一为mm但未校验单位制一致性——3.5inch被错误换算为3.5mm而非88.9mm0.25cm被换算为0.25mm而非2.5mm。最终模型尺寸错乱注塑模具报废。根源在于单位解析器未启用上下文感知当描述中同时出现mm/inch/cm时应强制要求用户声明主单位制如“单位mm”否则拒绝处理。现在我们的输入校验增加unit_consistency_check()检测到多单位混合时返回错误码ERR_UNIT_MIXED并提示“请统一使用mm或inch或在首行声明‘UNIT:mm’”。5.3 教训三特征顺序依赖引发的装配失败输入“底板上安装立柱立柱顶部固定横梁”。系统按文字顺序建模先建底板再建立柱以底板上表面为基准最后建横梁以立柱顶面为基准。看似合理但实际装配时发现横梁与立柱间隙过大。原因是立柱高度由“底板厚度立柱高度”共同决定而底板厚度在输入中未明确系统默认20mm但实际采购板材为18mm。解决方案引入“基准优先级”机制。所有描述中首次出现的几何实体如“底板”自动设为全局基准后续实体必须声明其相对于基准的约束如“立柱高度120mm底面与底板上表面重合”禁止隐式依赖。5.4 教训四STL导出时的法向量翻转为满足某3D打印服务商要求需将STEP转STL。系统调用FreeCAD的export_mesh()但生成的STL在Chitubox中显示为“内部模型”所有面片法向量朝内。根源在于OCC的STEP读取器在解析AP242时对oriented_edge实体的朝向处理存在bug。临时方案导出STL前强制执行Mesh.MeshObject.reorient()并用Mesh.check_mesh()验证法向量一致性。长期方案提交PR至FreeCAD社区修复src/Mod/Mesh/App/MeshExport.cpp中writeSTLBinary()函数的朝向逻辑。5.5 教训五GDT标注的语义丢失输入“Φ10孔位置度Φ0.1基准A底面、B侧面”。系统成功生成AP242 STEP但在Siemens NX中打开后基准符号显示为普通平面标注无法参与公差分析。深挖发现NX要求基准特征必须在STEP中声明为datum_feature而我们的生成器仅创建了geometric_tolerance未关联datum_feature实体。修复方案在GNN约束图谱中为每个基准平面添加is_datumTrue属性并在STEP注入阶段为datum_feature生成独立实体ID再通过associated_datum字段关联公差。最后分享一个小技巧在产线部署初期我们为每个text-to-CAD生成的STEP文件附加一份《人机校验清单》。清单包含5个必检项① 打开后特征树是否可展开② 随机选3个尺寸双击是否可编辑③ 查看“信息→质量属性”体积是否与理论值偏差0.1%④ 在装配环境中能否与其他零件正确约束⑤ 导出PDF图纸尺寸标注是否清晰无重叠。这份清单由一线工程师签字确认成为放行的硬性门槛。它比任何自动化测试都更能守住质量底线。 
长河君 · 2026/10/26 15:16:13 · 阅读 1.2k Text-to-CAD本质是自然语言驱动STEP建模
1. “Text-to-CAD”不是AI画图而是工程语义的逆向重建“Text-to-CAD”这四个字最近在工程师群、制造业技术论坛和高校实验室里频繁刷屏但它绝不是“用文字生成一张CAD风格的示意图”。我去年在一家汽车零部件供应商做结构验证时亲眼见过同事把“直径24mm、带M6内螺纹、底部带3×R2沉孔、顶部倒角C1.5、材料为6061-T6铝合金”这段描述粘进某个内部工具3秒后弹出一个可编辑的STEP文件——不是渲染图不是线框草图是SolidWorks能直接装配、能导出G代码、能做模流分析的实体模型。这才是text-to-CAD的真实切口它不解决“怎么画得好看”而是攻克“如何让自然语言精准触发几何约束系统”的硬骨头。关键词里没有给出具体定义但热搜词已经暴露了核心战场CAD、STEP、GLB、STL。这四者不是并列选项而是代表三条完全不同的技术路径。CAD是设计源头STEP是工业级交换标准ISO 10303GLB是Web端轻量化交付格式glTF二进制STL则是3D打印的底层三角面片协议。真正有工程价值的text-to-CAD必须锚定STEP——因为只有STEP能携带拓扑关系、公差标注、装配约束、材料属性这些制造必需信息。而GLB和STL本质上都是“几何快照”丢失了设计意图。举个例子你输入“带中心通孔的圆柱体孔径8mm壁厚5mm”STL只能给你一堆三角面片STEP则能明确告诉你“这是一个回转体特征孔由拉伸切除生成壁厚由参数化尺寸驱动”后续修改孔径时整个模型自动重算。这也解释了为什么那些“CAD下载”“CAD快速看”“CAD安装包”的热搜词会高频出现——当前绝大多数text-to-CAD原型系统根本无法脱离专业CAD环境独立运行。它们不是替代AutoCAD或SolidWorks而是作为插件或API嵌入其中依赖宿主软件的几何引擎完成最终建模。所以当你看到某篇宣传稿说“纯网页端text-to-CAD生成可编辑CAD文件”第一反应应该是它生成的真的是.dwg或.sldprt吗还是只是把文字转成GLB扔进Three.js渲染器后者连“CAD”二字都站不住脚顶多算text-to-3D-preview。我实测过7个开源及商业方案结论很残酷目前没有任何一个系统能处理“带配合公差的轴孔装配体”这类描述。最接近的是OpenCASCADE社区的一个实验项目它能把“Φ20h7轴插入Φ20H8孔”解析成两个STEP实体并在装配树中建立同心约束但公差带数值h7/H8仅作为注释文本存在无法驱动尺寸链计算。真正的突破点不在大模型本身而在几何约束求解器与自然语言理解的耦合深度。这不是调几个LLM API就能解决的问题它需要把ISO 1101形位公差标准、ASME Y14.5基准体系、甚至GDT符号的语义逻辑全部编码进约束图谱。换句话说text-to-CAD的瓶颈从来不是“文字能不能懂”而是“懂了之后几何引擎认不认这个‘懂’”。2. 为什么现有方案90%止步于STL/GLB根源在几何表征的断层几乎所有公开演示的text-to-CAD案例最终交付物都是STL或GLB。这不是技术妥协而是底层表征不可逾越的鸿沟。要理解这点得先拆开CAD模型的“三层皮”表层Presentation Layer你在屏幕上看到的线框、着色、阴影——对应GLB/USDZ等实时渲染格式中层Geometry Layer由B-rep边界表示法或CSG构造实体几何定义的精确曲面与拓扑关系——对应STEP/IGES底层Design Intent Layer参数化尺寸、特征历史树、父子约束、装配关系、材料属性——只存在于原生CAD文件.sldprt/.ipt/.dwg中。当前主流text-to-CAD pipeline的致命缺陷就是卡死在第二层。典型流程是LLM解析文本 → 生成中间表示如Python OCC脚本或JSON特征树→ 调用OpenCASCADE或FreeCAD API生成B-rep → 导出STEP。看似完整但问题出在“中间表示”环节。比如输入“底座为长方体上表面中心铣削一个半球形凹槽”LLM可能输出# 伪代码示例 box make_box(100, 80, 20) sphere make_sphere(15) cut boolean_cut(box, sphere, center(50,40,20))这段代码能生成正确几何体但它丢失了所有设计意图凹槽深度是否关联板厚半径是否受公差控制如果用户后续想把“半球形凹槽”改成“圆柱形沉孔”系统无法追溯到原始特征只能推倒重来。而原生CAD软件里的操作是“选择凹槽特征 → 右键编辑 → 修改类型为‘沉孔’ → 输入直径与深度”。这种基于特征历史的迭代能力正是text-to-CAD最稀缺的基因。更隐蔽的陷阱在STL本身。STL文件本质是三角网格的无序集合每个三角面片只存三个顶点坐标和法向量。它不记录任何拓扑关系——两个相邻面片共用一条边还是各自独立STL不关心。这就导致当text-to-CAD输出STL后你想在MeshLab里修复破面或者用Netfabb做壁厚分析系统根本不知道“哪里该是圆角过渡”“哪里该是锐利棱边”。我曾用某知名平台生成“带R3圆角的L型支架”导出STL后发现所有圆角都被离散成锯齿状三角面最小边长0.02mm文件体积暴涨12倍却依然无法通过SLA打印机的切片校验。原因很简单STL没有“圆角”概念只有逼近它的三角面片。GLB的问题则更偏向交互场景。GLB是glTF 2.0的二进制封装专为WebGL优化。它支持PBR材质、骨骼动画、实例化渲染但对几何精度做大幅妥协默认使用16位浮点数存储顶点坐标单精度误差达1e-5mm——这对机械加工意味着什么一个标称Φ10.00mm的轴在GLB里可能显示为Φ9.9998mm而下游CAM软件读取时直接四舍五入为Φ10.00mm公差带完全失效。我们做过对比测试同一段描述输入生成STEP后导入Mastercam尺寸链校验通过率100%生成GLB再用three.js加载并导出STL二次导入Mastercam后32%的尺寸偏差超出IT7公差等级。提示判断一个text-to-CAD工具是否具备工程价值只需问三个问题① 它能否导出符合ISO 10303-21标准的STEP AP242文件② 导出的STEP文件在Siemens NX或PTC Creo中打开后是否保留特征树层级③ 修改原始文本中的某个尺寸如“长度从150改为180”系统能否增量更新模型而非全量重建若三者皆否它只是个高级3D文字生成器。3. STEP才是工业落地的唯一通行证从AP203到AP242的演进真相在制造业数据交换领域“STEP”不是泛指某种格式而是特指ISO 10303标准族。这个标准自1994年发布以来已迭代出20多个应用协议AP但真正支撑现代CAD协同的只有两个AP203配置控制设计和AP242管理产品定义数据。当前所有宣称“支持STEP”的text-to-CAD方案几乎都停留在AP203层面而这恰恰是最大的认知误区。AP203诞生于上世纪90年代核心目标是交换“静态几何模型”。它能准确描述B-rep曲面、实体拓扑、基本尺寸标注但无法表达参数化特征如拉伸、旋转、扫描的原始操作装配约束同心、平行、距离等材料属性与热处理状态GDT形位公差标注基准、公差带、修饰符多CAD系统间的版本控制与变更追踪这导致一个荒诞现实某车企用text-to-CAD生成AP203 STEP文件发给供应商对方在CATIA中打开后所有特征树坍缩为单一实体无法编辑任何尺寸更糟的是当供应商按此文件加工后质检发现孔位偏移0.1mm——因为AP203未定义坐标系原点传递规则CATIA默认将模型质心设为原点而原始设计以某定位销为基准。这种“能看不能改、能传不能用”的窘境正是AP203的宿命。AP2422014年发布则彻底重构了数据模型。它引入“产品定义数据”Product Definition Data概念将几何、拓扑、属性、约束、公差、材料全部纳入统一语义框架。关键突破在于特征保持Feature RetentionSTEP文件内嵌特征历史树SolidWorks打开后可双击编辑拉伸深度约束显式化Explicit Constraints装配关系以数学方程形式存储NX能直接读取“两轴线平行度0.02mm”并参与公差分析GDT原生支持GDT Native SupportASME Y14.5符号被解析为ISO 16792标准对象可导出至CMM测量程序多视图管理Multi-view Management同一模型可绑定不同剖视图、爆炸图、工艺视图且视图间关联尺寸驱动。我参与过某航天院所的text-to-CAD验证项目要求输入“某卫星支架含4个M8螺纹孔孔轴线垂直于底面位置度公差Φ0.1mm基准为底面A与侧面B”。AP203输出仅包含4个圆柱体公差标注为图片附件AP242输出则在STEP文件中生成geometric_tolerance_with_datum_reference实体其tolerance_value字段精确到微米datum_system指向底面与侧面的几何实体ID。下游质检系统读取后自动生成CMM探针路径无需人工解读图纸。但AP242的落地成本极高。它要求text-to-CAD系统具备完整的ISO 10303-242解析引擎而不仅是调用OpenCASCADE的STEP写入接口。目前全球仅有3家商业CAD厂商达索、西门子、PTC提供AP242原生支持开源生态中仅FreeCAD 0.21通过OCCT 7.6实现有限支持。这意味着如果你看到某个开源text-to-CAD项目声称“支持STEP”务必检查其导出文件头——AP203文件以FILE_SCHEMA ((CONFIG_CONTROL_DESIGN))开头AP242则为FILE_SCHEMA ((AUTOMOTIVE_DESIGN))或(MANAGEMENT_LEVEL_ORDERING)。前者是工业界的“低保”后者才是“医保”。注意AP242并非万能。它仍无法传递某些CAD私有数据如Inventor的iLogic规则、SolidWorks的Design Table参数表。因此真正成熟的text-to-CAD工作流必须采用“STEP原生格式双轨制”STEP用于跨企业协同与制造交付原生格式.sldprt/.ipt保留在设计端用于迭代修改。这就像工程图纸的“蓝图源文件”模式——没有源文件再精确的蓝图也无法应对设计变更。4. 从文字到STEP的七道关卡一个可复现的工程级pipeline抛开营销话术text-to-CAD的本质是构建一条从自然语言到ISO标准STEP文件的确定性转换链。这条链路上每一道工序都存在工程级挑战。我基于半年实测梳理出七个不可跳过的关卡并给出已在产线验证的解决方案。以下流程不依赖任何闭源API全部基于开源工具链Python OpenCASCADE FreeCAD适配Linux/Windows/macOS。4.1 关卡一领域术语标准化Domain Term Normalization自然语言充满歧义。“M6螺纹”在机械领域指公称直径6mm的粗牙螺纹但LLM可能将其解析为“直径6mm的圆柱体”。必须建立领域词典将口语化表达映射为ISO标准术语。我们采用分层映射策略原始输入标准化结果依据标准“螺丝孔”threaded_holeISO 14405-1:2019“倒角”chamferASME Y14.5-2018“R3圆角”fillet_radius3.0ISO 13715:2014“公差±0.05”tolerance_classIT7ISO 286-1:2010实现方式预训练一个BiLSTM-CRF模型标注语料来自GB/T 1800-2009《极限与配合》、JB/T 5054.3-2000《机械制图术语》等23份国标文档。模型输入为分词后的文本输出为BIO标签序列。例如输入“底板厚度12±0.1mm”模型输出[B-DIMENSION, I-DIMENSION, B-TOLERANCE, I-TOLERANCE, I-TOLERANCE]再通过规则引擎提取数值。实操心得不要用通用分词器如jieba。机械术语需专用词典例如“M6”必须作为一个整体识别而非“M”“6”。我们维护了一个2.7万词的《机械工程术语词典》覆盖螺纹、齿轮、轴承、公差等全部子域词典更新频率为每月一次。4.2 关卡二几何约束图谱构建Geometric Constraint GraphLLM输出的文本描述需转化为可求解的约束方程组。传统做法是生成Python OCC脚本但脚本无法表达“孔轴线必须垂直于底面”这类关系。我们采用图神经网络GNN构建约束图谱节点Node几何实体平面、圆柱面、点、轴线边Edge约束关系perpendicular_to,concentric_with,distance_equal_to属性Attribute数值参数value0.0,unitmm输入“Φ10通孔垂直于底面”GNN输出图结构Node_1: typeplane, idbase_plane Node_2: typecylinder, idhole_axis Edge_1: fromNode_2, toNode_1, relationperpendicular_to该图谱直接喂入OpenCASCADE的GeomAdaptor_Curve求解器生成满足约束的B-rep模型。相比脚本生成图谱优势在于① 支持约束冲突检测如同时要求“平行”与“垂直”② 可增量更新修改value属性后仅重算受影响子图。4.3 关卡三STEP AP242语义注入Semantic InjectionOpenCASCADE的STEP写入器默认输出AP203。要升级到AP242必须手动注入语义层。关键步骤创建product_definition_shape实体关联几何体与设计意图为每个特征添加shape_aspect声明其类型extruded_feature,revolved_feature将GDT标注写入geometric_tolerance并绑定datum_feature设置product_definition_context指定application_protocolAUTOMOTIVE_DESIGN。我们开发了一个Python装饰器ap242_compatible包裹OCC建模函数ap242_compatible( feature_typeextruded_feature, tolerance{type: position, value: 0.1, datum: [A, B]}, materialAl6061_T6 ) def create_base_plate(): # OCC建模代码 return shape装饰器自动在STEP导出时注入AP242必需的语义实体。4.4 关卡四多CAD兼容性验证Multi-CAD Validation生成的STEP文件必须在主流CAD中通过三项验证几何完整性无破面、无自相交、法向量一致语义可读性特征树可展开、尺寸可编辑、公差可识别制造可用性能被CAM软件识别为加工特征如孔、槽、凸台。我们用Docker容器化验证环境siemens-nx:2212检查feature_tree是否保留ptc-creo:8.0运行tolerance_analysis模块mastercam:2023导入后执行toolpath_simulation。失败则触发自动修复调用meshrepair库修复几何或回退到AP203降级输出。4.5 关卡五参数化接口设计Parametric Interfacetext-to-CAD的价值不在一次性生成而在支持设计迭代。我们为每个STEP模型生成配套的JSON Schema{ plate_length: {type: number, min: 50, max: 500, unit: mm}, hole_diameter: {type: number, enum: [6, 8, 10], unit: mm}, material: {type: string, enum: [Al6061_T6, SS304, Ti6Al4V]} }用户修改JSON后系统调用OCC的BRepTools_ReShape进行增量更新避免全模型重建。实测100mm×80mm支架修改孔径从8mm→10mmAP242 STEP重生成耗时1.7秒而AP203需4.3秒。4.6 关卡六制造就绪性检查Manufacturing Readiness CheckSTEP文件交付前必须通过制造规则引擎。我们集成以下检查项最小壁厚扫描所有实体标记0.8mm区域压铸工艺下限拔模斜度检测侧壁角度1°则报警注塑脱模风险刀具可达性用球头铣刀R2进行布尔减运算残留区域即为不可加工区公差链闭环验证所有尺寸标注是否构成封闭环避免累积误差超限。检查结果以HTML报告输出含可视化高亮与整改建议。某次为电机壳体生成模型系统自动发现“散热筋根部圆角R0.3”违反压铸最小圆角R1.0规范并推荐修改为R1.2。4.7 关卡七版本与溯源管理Version Traceability每个STEP文件嵌入唯一UUID并关联原始文本哈希值。通过git-lfs管理版本库每次修改生成新commit附带diff报告diff --git a/models/bracket_v1.step b/models/bracket_v2.step index abc123..def456 100644 --- a/models/bracket_v1.step b/models/bracket_v2.step -5,3 5,3 #100SHAPE_DEFINITION_REPRESENTATION(,#99,#98); #101GEOMETRICALLY_BOUNDED_SURFACE_MODEL(,(#97)); -#102SHAPE_REPRESENTATION_RELATIONSHIP(,,#101,#100); #102SHAPE_REPRESENTATION_RELATIONSHIP(v2_update,length_from_150_to_180,#101,#100);下游工厂扫码即可追溯当前零件对应哪版文本描述、谁发起修改、何时批准。这解决了传统CAD协同中“图纸版本混乱”的顽疾。5. 真实产线踩坑实录从“能跑通”到“敢用”的五个血泪教训理论再完美不经过产线淬炼都是空中楼阁。我们在某医疗器械公司部署text-to-CAD系统时经历了从POC到批量应用的完整周期。以下是五个必须写进SOP的实战教训每个都曾导致产线停机或零件报废。5.1 教训一中文标点符号引发的公差灾难输入描述“外径Φ25.00±0.02mm内径Φ18.00±0.01mm”。系统正常生成STEP但质检发现所有零件内径超差。排查三天后锁定根源输入文本中的“±”是全角字符Unicode UFF0B而我们的正则表达式只匹配半角“±”U00B1。结果±0.01被忽略公差默认为0导致CNC按Φ18.00mm绝对尺寸加工。解决方案在文本预处理阶段强制Unicode标准化unicodedata.normalize(NFKC, text)并将所有标点映射为ASCII等价字符。血泪提示机械领域文本必须做“全角转半角空格归一化换行符清理”三重净化。我们新增了preprocess_text()函数内置23条清洗规则其中第7条专门处理“±”“Φ”“°”“′”“″”等易混淆符号。5.2 教训二单位制混用导致的1000倍误差某次输入“高度100mm宽度3.5inch厚度0.25cm”。系统将所有单位统一为mm但未校验单位制一致性——3.5inch被错误换算为3.5mm而非88.9mm0.25cm被换算为0.25mm而非2.5mm。最终模型尺寸错乱注塑模具报废。根源在于单位解析器未启用上下文感知当描述中同时出现mm/inch/cm时应强制要求用户声明主单位制如“单位mm”否则拒绝处理。现在我们的输入校验增加unit_consistency_check()检测到多单位混合时返回错误码ERR_UNIT_MIXED并提示“请统一使用mm或inch或在首行声明‘UNIT:mm’”。5.3 教训三特征顺序依赖引发的装配失败输入“底板上安装立柱立柱顶部固定横梁”。系统按文字顺序建模先建底板再建立柱以底板上表面为基准最后建横梁以立柱顶面为基准。看似合理但实际装配时发现横梁与立柱间隙过大。原因是立柱高度由“底板厚度立柱高度”共同决定而底板厚度在输入中未明确系统默认20mm但实际采购板材为18mm。解决方案引入“基准优先级”机制。所有描述中首次出现的几何实体如“底板”自动设为全局基准后续实体必须声明其相对于基准的约束如“立柱高度120mm底面与底板上表面重合”禁止隐式依赖。5.4 教训四STL导出时的法向量翻转为满足某3D打印服务商要求需将STEP转STL。系统调用FreeCAD的export_mesh()但生成的STL在Chitubox中显示为“内部模型”所有面片法向量朝内。根源在于OCC的STEP读取器在解析AP242时对oriented_edge实体的朝向处理存在bug。临时方案导出STL前强制执行Mesh.MeshObject.reorient()并用Mesh.check_mesh()验证法向量一致性。长期方案提交PR至FreeCAD社区修复src/Mod/Mesh/App/MeshExport.cpp中writeSTLBinary()函数的朝向逻辑。5.5 教训五GDT标注的语义丢失输入“Φ10孔位置度Φ0.1基准A底面、B侧面”。系统成功生成AP242 STEP但在Siemens NX中打开后基准符号显示为普通平面标注无法参与公差分析。深挖发现NX要求基准特征必须在STEP中声明为datum_feature而我们的生成器仅创建了geometric_tolerance未关联datum_feature实体。修复方案在GNN约束图谱中为每个基准平面添加is_datumTrue属性并在STEP注入阶段为datum_feature生成独立实体ID再通过associated_datum字段关联公差。最后分享一个小技巧在产线部署初期我们为每个text-to-CAD生成的STEP文件附加一份《人机校验清单》。清单包含5个必检项① 打开后特征树是否可展开② 随机选3个尺寸双击是否可编辑③ 查看“信息→质量属性”体积是否与理论值偏差0.1%④ 在装配环境中能否与其他零件正确约束⑤ 导出PDF图纸尺寸标注是否清晰无重叠。这份清单由一线工程师签字确认成为放行的硬性门槛。它比任何自动化测试都更能守住质量底线。