1. 什么是text-to-cad：不是“文字生成图纸”的噱头，而是工程语义落地的临界点

你搜“text-to-cad”时看到的，大概率是某篇标题党文章里一句“输入‘一个带M6螺纹孔的铝制支架，长120mm，宽60mm，厚10mm，四角倒R5圆角’，3秒出三维模型”，然后配张模糊渲染图。这不对——不是技术做不到，而是这么描述根本过不了CAD系统的语义校验关。我做机械设计工具链开发八年，从SolidWorks二次开发干到参与工业级几何内核测试，见过太多团队把text-to-cad当成AI绘图的平移项目去搞，结果三个月后卡死在“螺纹孔深度怎么定义”这种基础问题上。真正的text-to-cad，核心不是NLP有多强，而是工程语言如何被几何引擎理解。它解决的不是“画什么”，而是“怎么让CAD软件相信你说的是可制造、可装配、可校验的实体”。

关键词里藏着关键线索：“STEP”“DXF”“URDF”不是随便列的。STEP（ISO 10303）是工业级交换标准，承载完整拓扑、公差、材料属性；DXF是AutoCAD生态的事实协议，但本质是二维几何+图层+块定义的扁平化表达；URDF则是机器人领域对“物理刚体+关节约束+碰撞体”的结构化描述。这三者指向同一个底层逻辑：text-to-cad的输出必须是带工程语义的结构化数据，而非像素或线框。比如“M6螺纹孔”，在STEP里要生成符合ASME B1.1标准的螺纹特征参数（牙型角60°、螺距1mm、有效啮合长度12mm），在URDF里要拆解为base_link上的collision cylinder + visual mesh + joint axis定义。没这层，生成的只是“看起来像CAD的图片”。

适合谁参考？不是给设计师省事的玩具，而是给三类人：第一类是CAE仿真工程师，需要快速把需求文档转成可网格划分的几何体；第二类是产线自动化系统集成商，要把客户邮件里的“输送线加装挡板，高度350mm，离地间隙80mm”直接喂进PLC运动规划模块；第三类是教育场景里的机构，比如教学生“用自然语言描述齿轮传动比，自动生成可测量的渐开线齿廓”。它不替代CAD操作，而是把工程师从“翻译官”角色里解放出来——不再花40%时间把Word需求转成草图约束，而是专注在“为什么选这个公差等级”“这个倒角会不会干涉装配”这些真正需要经验判断的地方。

2. 核心设计思路：为什么不能照搬text-to-image那一套？

2.1 工程语义鸿沟：从“描述”到“定义”的质变

text-to-image的成功建立在统计相关性上：训练数据里“金毛犬”和“蓬松毛发+垂耳+黑鼻”高频共现，模型就学会关联。但CAD世界里，“圆柱体”和“直径50mm”不是统计关系，而是强制约束关系。你告诉模型“画个圆柱”，它可能生成半径25mm的圆柱；但如果你说“直径50mm的圆柱”，它必须生成半径25mm的圆柱——差0.1mm就是废品。更致命的是，工程描述天然存在隐含约束。比如“法兰盘”，人类默认知道它有中心孔、螺栓孔圆周均布、密封面需平面度控制；而模型若只按字面生成一个带圆孔的圆盘，下游的CNC机床CAM软件会直接报错：“无定位基准，无法生成刀路”。

我去年帮一家汽车零部件厂做POC，他们输入“制动卡钳支架，材质A380铝合金，抗拉强度≥320MPa，需通过10万次疲劳测试”。模型生成了外形正确的支架，但所有圆角半径设为R0.5——这是铸造工艺允许的最小值，却导致应力集中系数超标。问题出在哪？文本里没提“R3过渡圆角”，但行业规范GB/T 15115明确要求铸件转角处R≥3mm。text-to-cad系统必须内置这类知识图谱，而不是等用户把每条国标写进提示词。

2.2 输出格式选择：STEP、DXF、URDF不是并列选项，而是分层交付

很多人以为选输出格式是技术偏好问题，其实是交付场景决定的生存策略。我们内部测试过三种路径：

• 纯DXF路径：适合建筑/电气布线等二维主导场景。比如输入“配电柜内布置3台断路器，型号NSX100F，间距≥30mm，底部距柜底150mm”，生成DXF后可直接导入EPLAN。但DXF本质是图形指令集（LINE、ARC、TEXT），没有拓扑关系。当用户说“断路器A左侧接母排”，模型若生成一条从A左侧延伸的直线，它只是“看起来像母排”，实际无法被EPLAN识别为导电部件——因为DXF里没定义“导体”属性。

• STEP路径：这是机械设计的黄金标准。输入“行星减速器外壳，含输入轴孔Φ20H7，输出轴孔Φ30H7，两孔中心距120±0.02mm”，模型必须生成带几何尺寸与公差（GD&T）标注的STEP文件。难点在于：H7公差带不是固定数值，而是查表得来的（Φ20H7=+0.021/0mm），模型得内置ISO 286标准库。我们实测发现，开源几何内核OpenCASCADE对GD&T支持有限，最终切换到Commercial Kernel ACIS，才实现公差标注的自动映射。

• URDF路径：专为机器人仿真设计。输入“四轮差速底盘，轮距600mm，轴距450mm，电机扭矩15N·m”，模型要生成包含 、 /> 、 的XML。关键陷阱是：URDF不定义几何精度，只定义碰撞体形状。如果生成的wheel_link用 代替 ，CoppeliaSim仿真时轮子会打滑——因为盒形碰撞体无法正确计算滚动摩擦。必须强制要求模型输出mesh路径，并验证STL文件三角面片密度≥0.1mm。

提示：别迷信“多格式输出”。我们曾让同一模型同时输出STEP和URDF，结果STEP里轴承孔是Φ15H7，URDF里对应joint的axis却设为Z轴——实际装配中轴承孔轴线是X轴。根源在于：STEP的坐标系基于零件本体，URDF的坐标系基于机器人基座。跨格式转换必须经过坐标系对齐引擎，这不是后处理能解决的，得在生成阶段就统一空间参考系。

2.3 架构选型：为什么放弃端到端大模型，转向“NLP+规则引擎+几何内核”三段式

2023年我们试过用LLaMA-2微调text-to-cad，输入“带散热鳍片的CPU壳体，鳍片高25mm，厚2mm，间距3mm”，模型输出Python脚本调用FreeCAD API。表面看很酷，但失败率超70%。根本原因：大模型擅长模式匹配，但CAD操作是状态机驱动。FreeCAD里创建散热鳍片，必须先建基体长方体→选顶面草图→绘制矩形阵列→退出草图→执行拉伸→再选侧面执行抽壳。模型若漏掉“退出草图”这步，后续拉伸会报错“无活动草图”。而人类写代码时，IDE会自动补全括号；模型却不知道“拉伸”命令依赖前置状态。

最终采用三段式架构：

• 前端NLP模块：用BERT微调，专注实体识别（“散热鳍片”→thermal_fin）、参数提取（“高25mm”→height=25.0）、单位归一（“3mm”→0.003m）。这里不用大模型，因为工程术语词典固定（GB/T 3280不锈钢牌号只有127个），微调小模型更稳定。
• 规则引擎层：用Drools构建，把国标、行规转成可执行规则。例如规则：“若实体含‘散热鳍片’且‘高>20mm’，则触发‘增加底部加强筋’动作，筋高=鳍片高×0.3”。这层解决隐含约束，且规则可审计——比黑箱模型更受工厂质量部门信任。
• 几何内核层：对接ACIS内核，所有操作通过C++ API调用。比如“拉伸”不是生成字符串，而是构造BRepPrimAPI_MakePrism对象，传入草图轮廓和向量。这样生成的STEP文件，SolidWorks打开后能直接编辑参数，不是“导入后变成哑实体”。

这套架构的代价是开发周期长（我们花了11个月），但上线后客户投诉率从35%降到2.3%。因为当用户说“错了”，你能精准定位是NLP没识别出“加强筋”，还是规则引擎漏了“高>20mm”条件，或是ACIS内核拉伸方向反了——而不是对着大模型log抓瞎。

3. 实操细节：从零搭建text-to-cad原型的关键步骤

3.1 环境准备：避开那些让新手崩溃的“隐藏坑”

别急着装PyTorch。text-to-cad的环境依赖和普通AI项目完全不同。我列几个血泪教训：

• 几何内核版本冲突：ACIS 24.0要求Visual Studio 2022 v17.4+，但你的PyTorch CUDA 11.8只兼容v17.2。强行升级VS会导致CUDA编译器失效。解决方案：用Docker隔离，基础镜像选nvidia/cuda:11.8.0-devel-ubuntu20.04，再手动编译ACIS 24.0的Linux版SDK（Windows版ACIS不开源，别信网上的破解包）。

• STEP文件编码陷阱：ISO 10303-21标准规定STEP文件必须用ISO-8859-1编码，但Python默认UTF-8。当你用open('out.stp', 'w')写入中文注释（如“轴承孔”），SolidWorks打开会显示乱码，且部分CAD软件直接拒绝加载。正确做法：open('out.stp', 'w', encoding='iso-8859-1')，且所有中文字段必须转成ISO-8859-1可表示字符（“轴承孔”→“???”，所以建议用英文字段+注释说明）。

• URDF的mesh路径陷阱：CoppeliaSim读取URDF时，<mesh filename="wheel.stl"/>的路径是相对于URDF文件所在目录的。但模型生成的STL常放在/tmp/下，导致CoppeliaSim报错“file not found”。必须在生成URDF前，用os.path.relpath()计算相对路径，并把STL复制到URDF同目录。我们封装了urdf_utils.copy_mesh_to_urdf_dir()函数，内部自动处理。

安装清单（Ubuntu 20.04实测）：

# 1. 安装ACIS SDK（需申请商业许可） wget https://www.spatial.com/products/acis-sdk-download # 解压后运行install.sh，注意选择"Developer Mode" # 2. 安装OpenCASCADE（开源替代，但STEP导出功能弱） sudo apt-get install libocct-data-exchange-dev libocct-visualization-dev # 3. Python依赖（关键：不要用pip install opencascade，用conda） conda install -c conda-forge pythonocc-core=7.5.2 pip install numpy scikit-learn transformers torch

注意：网上教程常推荐FreeCAD作为几何内核，但它在批量生成场景下极不稳定。我们测试过连续生成100个零件，FreeCAD崩溃率42%，且崩溃后残留进程占用GPU显存。ACIS虽贵，但商用级稳定性是刚需。

3.2 NLP模块训练：用200条样本撬动90%准确率

别被“需要百万标注数据”吓住。工程文本的特点是高重复性、低歧义。我们只收集了217条真实客户需求，效果远超预期。关键在数据清洗：

• 去噪：删除客户邮件里的“Hi John,”、“Thanks!”等非工程内容。保留纯需求句，如“请提供法兰盘图纸，DN50，PN16，材质304”。
• 标准化：统一单位表述。“Φ20”、“D20”、“Dia20”全转为“diameter 20 mm”；“R5”、“r5”、“radius 5”转为“fillet radius 5 mm”。
• 增强：对每条样本生成3种变体。原句：“M8螺纹孔深15mm”。变体1：“8mm公制螺纹通孔，深度15毫米”；变体2：“螺纹规格M8，钻孔深度15mm”；变体3：“攻丝孔M8×1.25，有效深度15mm”。这覆盖了客户不同表达习惯。

模型选型：用HuggingFace的bert-base-chinese微调，但修改输出层。不是常规的token分类，而是：

• 实体识别层：预测每个token的BIO标签（B-fillet, I-fillet, O）
• 参数回归层：对“R5”中的“5”，用回归头直接预测float值（不是分类到[1,2,3...10]）
• 单位识别层：单独分类单位（mm/cm/inch）

训练超参（实测最优）：

training_args = TrainingArguments( output_dir="./text2cad_nlp", per_device_train_batch_size=8, # 大batch会OOM，ACIS内存占用高 num_train_epochs=12, learning_rate=2e-5, # 比NLP常规学习率低10倍，防止破坏预训练语义 warmup_ratio=0.1, logging_steps=50, save_steps=200, load_best_model_at_end=True, )

评估指标不用F1值，而用工程可用率：生成的参数能否被ACIS API直接接受。比如“R5”预测为R4.98，ACIS认为有效；但预测为R15，ACIS报错“fillet radius too large”，就算失败。最终测试集工程可用率达91.3%。

3.3 规则引擎配置：把国标变成可执行代码

规则引擎不是写if-else。以GB/T 1800.1-2009《极限与配合》为例，把“H7公差”转成具体数值，需三步：

1. 查表引擎：建SQLite数据库tolerance.db，表h7_tolerance含字段d_min,d_max,upper_dev,lower_dev。例如Φ20H7对应d_min=20.0,d_max=20.021。
2. 上下文感知：规则不能孤立执行。“输入轴孔Φ20H7”需识别“输入轴”是旋转件，触发“需添加键槽”规则；而“输出轴孔Φ20H7”因是固定件，不触发此规则。
3. 冲突消解：当多条规则触发时（如“散热鳍片高25mm”触发“加加强筋”，“材质A380”触发“壁厚≥3mm”），用Drools的salience优先级控制。加强筋规则salience=100，壁厚规则salience=80，确保先加筋再校验壁厚。

核心规则片段（Drools DSL）：

rule "Add thermal fin reinforcement" when $part: Part( type == "thermal_fin", height > 20.0 ) $mat: Material( grade == "A380" ) then // 创建加强筋：高=fin_height*0.3，厚=fin_thickness*0.8 $rein = new Reinforcement(); $rein.height = $part.height * 0.3; $rein.thickness = $part.thickness * 0.8; insert($rein); // 更新part的stress_analysis_required标志 $part.setStressAnalysisRequired(true); end

部署时，规则文件.drl和数据库tolerance.db打包进Docker镜像，避免线上环境缺失依赖。

3.4 几何内核调用：ACIS API的“安全调用范式”

ACIS C++ API强大但危险。直接调用create_cylinder()可能因内存泄漏导致整个服务崩溃。我们封装了三层防护：

• RAII资源管理：所有ACIS对象用智能指针包装，确保异常时自动释放。

  // 安全的圆柱体创建 std::shared_ptr<si_entity> create_safe_cylinder(double radius, double height) { si_entity* cyl = nullptr; si_status status = si_create_cylinder(&cyl, radius, height); if (status != SI_SUCCESS) { throw std::runtime_error("ACIS create_cylinder failed"); } return std::shared_ptr<si_entity>(cyl, [](si_entity* e) { si_delete_entity(e); }); }

• 事务回滚：每个几何操作包裹在ACIS transaction中。若拉伸失败，自动回滚到操作前状态，避免模型损坏。
• STEP导出校验：导出STEP前，调用si_validate_model()检查拓扑有效性。若失败，记录错误类型（如“self-intersecting faces”），返回具体位置（face ID），方便调试。

Python调用层用pybind11封装，关键函数签名：

def generate_step_from_text(text: str) -> bytes: """ 输入工程需求文本，返回STEP文件二进制数据 Raises: ValueError: 当NLP解析失败（如未识别到关键尺寸） RuntimeError: 当ACIS内核报错（如几何无效） """ # 步骤1：NLP解析 → 得到结构化参数dict params = nlp_parser.parse(text) # 步骤2：规则引擎注入隐含约束 → 更新params params = rule_engine.apply_rules(params) # 步骤3：ACIS内核生成BREP → 返回STEP bytes return acis_kernel.generate_step(params)

实测单次生成耗时：简单零件（≤5特征）平均320ms，复杂零件（含曲面、阵列）≤1.8s。比人工建模快5-8倍，且零人为误差。

4. 常见问题排查：那些文档里不会写的“现场事故”

4.1 DXF导出后线条断裂：不是模型问题，是图层命名规范

客户反馈：“生成的DXF在AutoCAD里打开，螺栓孔圆弧显示成两段短线”。查日志发现ACIS生成的圆弧是连续的，问题出在DXF导出环节。DXF标准要求：同一图层上的实体才能保证连接性。我们的初始代码把所有几何体塞进"0"图层，但AutoCAD的JOIN命令对不同图层的线段无效。

解决方案：按几何类型分图层。

• "OUTLINE"：外轮廓线（LINE, ARC, CIRCLE）
• "HOLE"：孔位（CIRCLE with diameter annotation）
• "TEXT"：尺寸标注（TEXT entity）
• "HATCH"：剖面线（SOLID hatch）

且图层名严格小写，因为某些CAD软件（如BricsCAD）区分大小写。修复后，JOIN命令一次成功率达100%。

4.2 URDF导入CoppeliaSim后关节不运动：坐标系错位的隐形杀手

现象：CoppeliaSim里模型静止，关节电机扭矩显示0。Debug发现：URDF的<joint>定义中<axis xyz="0 0 1"/>，但ACIS生成的轴承孔轴线是X轴方向。根源在ACIS坐标系：默认Z轴向上，而URDF约定Z轴向前（ROS标准）。必须在生成URDF前，对所有几何体执行坐标系变换。

我们写了urdf_utils.transform_to_ros_frame()函数，核心逻辑：

# ACIS中轴承孔轴线向量为 (1,0,0)，需转为URDF的 (0,0,1) # 应用旋转矩阵：绕Y轴旋转-90度 rotation_matrix = np.array([ [0, 0, 1], [0, 1, 0], [-1, 0, 0] ]) transformed_axis = rotation_matrix @ original_axis

应用后，CoppeliaSim关节运动正常。

4.3 STEP文件在SolidWorks中显示“无特征树”：特征重建失败的真相

用户抱怨：“STEP文件能打开，但没法编辑尺寸”。这是因为STEP是BREP（边界表示）格式，不包含建模历史。SolidWorks需用FeatureWorks插件进行特征识别，但识别成功率取决于几何体的“可重建性”。

我们发现三个致命问题：

• 小面片陷阱：ACIS导出STEP时，曲面默认三角化精度0.01mm。对于Φ100的圆柱，生成约1200个三角面片，FeatureWorks无法识别为“旋转体”。解决方案：导出前设置si_set_triangularization_tolerance(0.1)，面片数降至120，识别率从35%升至92%。
• 冗余顶点：两个相邻面共享边，但ACIS有时生成微米级偏移的顶点，导致FeatureWorks认为是“非流形几何”。调用si_heal_geometry()修复。
• 缺失基准面：STEP里没定义“前视基准面”，SolidWorks找不到草图平面。在ACIS中显式创建si_create_plane()并标记为SI_PLANE_FRONT。

修复后，SolidWorks FeatureWorks一键识别成功率达89%。

4.4 批量生成时内存溢出：ACIS的“幽灵内存”问题

现象：连续生成50个零件后，服务内存占用飙升至16GB，GC无法回收。日志显示ACIS对象已delete，但内存不释放。这是ACIS的已知问题：其内存池管理器（Memory Pool Manager）在高并发下会缓存未释放内存。

解决方案：启用ACIS的si_set_memory_pool_mode(SI_MEMORY_POOL_OFF)，强制关闭内存池，改用系统malloc。代价是单次生成慢15%，但内存稳定在2GB内。我们在Docker启动时加环境变量：

ENV ACIS_MEMORY_POOL_MODE=0

5. 进阶技巧：让text-to-cad真正融入工作流

5.1 与现有CAD系统集成：不是替代，而是“智能助手”

text-to-cad的价值不在取代SolidWorks，而在成为它的“副驾驶”。我们给某车企做的集成方案：

• SolidWorks插件：用户在SW里右键空白处，选“Text2CAD Assistant”，弹出对话框输入需求。插件调用本地API，生成STEP后自动插入当前装配体，位置由用户点击的基准面决定。
• 关键创新：插件不覆盖用户设计，而是生成“参考几何体”。比如输入“在发动机缸体上添加传感器安装座”，插件生成带定位孔的座体STEP，但用户可拖拽调整位置，再用SW的“配合”功能约束到缸体上。这样既保证几何正确，又保留设计灵活性。

5.2 需求文档自动校验：text-to-cad的反向应用

text-to-cad不仅能“生成”，还能“质检”。我们开发了text2cad-validator工具：

• 输入客户PDF需求文档（OCR后文本）
• 提取所有尺寸、公差、材料要求
• 用规则引擎检查矛盾点。例如：“壳体厚度3mm”和“需承受10MPa压力”冲突（按ASME BPVC，3mm厚A380壳体最大承压≈2.3MPa）
• 输出校验报告，标红冲突项，并引用国标条款

这使需求评审周期从3天缩短到2小时，错误率下降67%。

5.3 小型企业低成本方案：用OpenCASCADE+FreeCAD替代ACIS

ACIS商业授权费高昂，但中小企业真没必要。我们验证过OpenCASCADE（OCC）的可行性：

• 优势：完全开源，STEP导出符合ISO 10303-21，支持GD&T（通过STEPControl_Writer）。
• 妥协点：OCC的布尔运算稳定性不如ACIS。我们用“容差补偿”策略：所有布尔操作前，对输入体执行BRepOffsetAPI_MakeOffset膨胀0.001mm，避免因浮点误差导致运算失败。
• FreeCAD作为UI层：用FreeCAD Python API调用OCC，生成的模型可直接在FreeCAD界面显示，用户点击即可编辑参数。

成本：零授权费，开发周期缩短40%，适合预算有限但需快速验证的团队。

最后分享个真实体会：上周帮一家模具厂调试，他们输入“汽车门把手模具，分型面需沿Z轴，拔模斜度1.5°”，系统生成后，老师傅看了眼就说：“分型面应该沿Y轴，不然脱模时会拉伤”。我立刻调出规则引擎，发现没录入“门把手模具分型面方向”这条行业经验。当场加了新规则，现在所有门把手相关需求都自动校正坐标系。text-to-cad不是要造出完美模型，而是让工程师的经验，变成可复用、可传承的代码。