1. 这不是“文字变模型”的魔法，而是工程语言的翻译革命
“text-to-cad”这个词最近在工程师、产品设计师和制造业技术群里刷屏，但很多人点开一看——咦？怎么没有一键生成齿轮的按钮？没有输入“一个带M6螺纹孔的铝制支架”就弹出完整可加工图纸的界面？这背后根本不是AI画图软件的简单升级，而是一场对整个机械设计工作流底层逻辑的重构。我从2018年开始在汽车零部件厂做结构设计，后来转做工业软件集成，亲手搭过三套内部CAD自动化流程，也踩过无数坑。今天说的“text-to-cad”，核心不是让AI替代工程师，而是把工程师脑子里那套“零件描述→几何建模→约束定义→制造校验”的思维链，用机器能理解的方式重新编码、固化、复用。它解决的不是“不会画图”的问题，而是“重复画图”“改图耗时”“跨平台数据断层”这三个卡死产线的真实痛点。关键词里反复出现的STEP、STL、GLB，恰恰暴露了当前困局：我们能把文字变成3D模型（GLB），也能导出网格（STL），但真正能进数控机床、进仿真分析、进PLM系统的，只有STEP这种带完整拓扑关系和参数历史的格式。所以真正的text-to-cad，必须跨过“可视化模型”这道浅水区，直抵“可计算、可追溯、可制造”的CAD内核。适合谁看？不是给零基础小白讲“怎么下载CAD”，而是给每天要改5版法兰盘图纸的机械工程师、给被客户临时加改需求逼到凌晨的结构设计师、给想把老图纸库自动翻新的技术主管——如果你还在用截图+微信语音跟同事说“这个圆角再倒个R3”，那你就是这个技术最该服务的人。
2. 为什么不能直接用ChatGPT画CAD？——拆解text-to-cad的三层技术壁垒
2.1 第一层壁垒：语义鸿沟——“螺纹孔”在人类和CAD系统里是两个物种
工程师说“M6螺纹孔”，脑子里立刻浮现：公称直径6mm、粗牙、6g公差、底孔Φ5.02mm、钻深12mm、攻丝深度10mm、表面粗糙度Ra1.6……但大语言模型看到的只是“M6”两个字符。它可能联想到螺丝图片、电商页面、甚至《机械设计手册》PDF里的扫描件，但绝不会自动关联到ISO 965-1标准里定义的螺纹牙型角、中径公差带位置这些硬性约束。我试过让主流多模态模型生成“带键槽的轴”，结果输出的GLB模型里键槽宽度是12.37mm——而国标GB/T 1095规定键槽宽公差是H9，对应Φ30轴的键槽宽必须是12±0.043mm。这种偏差在渲染图里看不出来，但放进CNC编程软件一模拟，刀具直接撞上工件。真正的text-to-cad必须内置工程知识图谱：把“M6”映射到ISO 898-1材料强度要求、“键槽”绑定到GB/T 1095尺寸链、“倒角C2”触发ANSI B1.23M的标注规范。这不是靠喂更多图纸数据能解决的，得把《机械设计手册》《公差配合国标》《GD&T几何公差》全编译成可执行规则引擎。目前开源方案如CadQuery的cq.Workplane().hole()方法，本质是把“hole”这个文本指令翻译成OpenCASCADE的BRepPrimAPI_MakeCylinder调用，中间每一步都硬编码了工程逻辑。
2.2 第二层壁垒：几何引擎——没有OpenCASCADE或ACIS，一切生成都是纸糊的
所有能导出STEP/IGES的CAD系统，底层都依赖两大几何内核：达索的ACIS或OpenCASCADE（OCC）。它们不是简单的“画线画圆”，而是用精确的NURBS曲面、布尔运算拓扑关系、参数化特征树来构建模型。比如输入“圆柱体Φ50×100，顶部中心开Φ20通孔”，传统3D建模软件会创建：1）一个圆柱体实体（BRepSolid）；2）一个圆柱体减去操作（BRepAlgoAPI_Cut）；3）在特征树里记录“孔特征依赖于圆柱体基准面”。而纯渲染引擎（如Three.js）生成的GLB，只存顶点坐标+三角面片，连“这是个孔还是个凸台”都分不清。去年帮某电机厂做自动化项目，他们用某AI工具生成STL后导入SolidWorks，结果发现所有圆角都被三角化成锯齿状——因为STL本身不存曲率信息，OCC内核无法反推原始圆弧半径，后续做有限元网格划分时直接报错“几何不连续”。所以text-to-cad的生成器必须直连OCC或ACIS，而不是先生成STL再转换。实测下来，CadQuery+OCC组合在生成带拔模斜度的注塑件时，能保持曲面G2连续性；而基于Blender Python API的方案，即使调用bmesh.ops.bevel，生成的STEP文件在NX里打开也会丢失拔模方向参数。
2.3 第三层壁垒：数据闭环——没有STEP导出能力，就不算进工厂门
热搜词里高频出现“sw中stl转stp”“cad转pdf”，恰恰说明行业痛点：STL/GLB是“死模型”，STEP才是“活数据”。一个合格的text-to-cad系统，必须完成从文本→参数化特征→STEP→下游系统（MES/PLM/CAM）的全链路。这里有个关键细节：STEP文件有AP203（几何数据）和AP214（含GD&T、材料、工艺）两种协议。普通导出默认AP203，但汽车厂要求AP214里必须包含“表面处理：阳极氧化，膜厚15μm”这样的非几何属性。我见过太多AI生成模型导出STEP后，在西门子Teamcenter里因缺少AP214扩展属性被自动归入“待审核”队列。真正可用的方案，比如用Python-OCC调用STEPControl_Writer时，必须手动设置SetAP214并注入StepRepr_RepresentationContext对象。更残酷的是验证环节：生成的STEP文件要用ISO 10303-21校验器跑一遍，检查是否符合EXPRESS schema——去年某创业公司Demo演示很炫，但导出的STEP在CATIA里打开报错“Entity #123 not found in schema”，根源是没校验STEP文件头里的FILE_SCHEMA字段是否匹配AP214。
3. 实操路径：从零搭建可落地的text-to-cad流水线
3.1 工具链选型——为什么放弃Blender/FreeCAD，死磕CadQuery+OCC？
2023年我们给五家制造企业做过技术评估，对比了四条技术路径：
| 方案 | 核心工具 | STEP导出能力 | 参数化特征支持 | 工程知识嵌入难度 | 部署成本 |
|---|---|---|---|---|---|
| A | Blender+Python | 需第三方插件，AP214支持弱 | 仅基础修改器 | 高（需重写GD&T解析器） | 低（开源） |
| B | FreeCAD+Workbench | 原生支持AP203 | 完整特征树 | 中（可调用PartDesign模块） | 中（依赖Qt环境） |
| C | CadQuery+OCC | 原生AP214，通过exportStep() | 特征驱动建模 | 低（直接调用cq.Assembly()） | 高（需编译OCC） |
| D | 商业API（如Autodesk Forge） | 完整AP214 | 云原生参数化 | 极高（需对接厂商SDK） | 极高 |
最终全部选了C方案。原因很实在：CadQuery的DSL（领域特定语言）天然适配工程描述。比如输入文本“长方体底座：200×150×30mm，四角各有一个M8通孔，孔距边15mm”，直接对应代码：
import cadquery as cq result = (cq.Workplane("XY") .box(200, 150, 30) .faces(">Z").workplane() .rarray(170, 120, 2, 2) # 孔距边15mm → 200-2*15=170, 150-2*15=120 .hole(8.4) # M8螺纹底孔Φ8.4mm ) result.exportStep("base.step", mode="AP214") # 直接指定协议注意rarray参数不是凭空写的——170和120是根据“孔距边15mm”计算得出：长边200mm减去两边各15mm余量，同理宽边150mm。这种计算必须由程序完成，否则工程师还得手动验算。CadQuery的优势在于，它的.hole()方法底层调用OCC的BRepFilletAPI_MakeFillet，生成的STEP自带edge_curve拓扑关系，不像Blender导出的STEP只有shell_based_surface_model。
3.2 文本解析引擎——用规则引擎+LLM双校验，绕过纯AI的幻觉陷阱
纯用LLM解析工程文本风险极大。我们测试过GPT-4对“Φ25H7孔”的理解：它能说出H7是基孔制、公差±0.021mm，但当要求生成STEP时，却把公差信息存在STEP的product_definition_shape里——而正确位置应该是geometric_tolerance实体。解决方案是分层解析：
- 第一层：正则规则引擎（处理确定性描述）
用regex提取数字和符号：r"Φ(\d+(?:\.\d+)?)\s*([A-Z][0-9]+)"→ 匹配“Φ25H7”，得到直径25、公差H7 - 第二层：微调LLM（处理模糊描述）
微调Llama3-8B，训练集是10万条真实设计变更单，重点学习：“加强筋”→厚度3mm/高度15mm/圆角R2，“沉头孔”→锥角90°/沉头直径Φ12/深度5mm - 第三层：OCC校验器（兜底验证）
生成STEP后，用OCC.ExtendedDataExchange.StepReader读取，检查geometric_tolerance实体是否存在且tolerance_value字段合规
实际部署时，我们把LLM放在规则引擎之后——先用正则提取所有明确参数（尺寸、公差、材料），再让LLM补全隐含参数（如“铝合金支架”自动补“材料：6061-T6，抗拉强度≥240MPa”）。这样既利用LLM的语义理解，又用规则锁死关键参数，避免“M6螺纹孔”被误判为“Φ6光孔”。
3.3 STEP导出与验证——三个必检项，少一个就进不了车间
生成STEP不是终点，而是进入制造流程的起点。我们制定的验证清单：
拓扑完整性检查
用OCC.TopoDS_Shape遍历所有面（face），确认无孤立面、无自相交边。曾遇到某AI生成的“带圆角的L型板”，OCC检测到TopAbs_INVALID状态——因为圆角半径大于直角边长，布尔运算失败。修复方案：在.fillet()前插入if radius < min(edge_length)/2: ...AP214协议合规性
用开源工具stepcode校验：stepcheck -s ap214 base.step # 检查schema stepcheck -t base.step # 检查实体类型关键报错
#123 = geometric_tolerance_representation_item缺失，意味着GD&T信息未写入。修复代码需显式创建：from OCC.Core.StepRepr import StepRepr_ShapeRepresentation rep = StepRepr_ShapeRepresentation() rep.SetName("GD&T_1")下游系统兼容性测试
在目标CAD软件里批量导入：- SolidWorks：检查“导入诊断”窗口是否报“几何体丢失”
- NX：运行
ug_check_part命令，验证body_type是否为solid而非sheet - CATIA：用
CATIAFileCheck工具，确认ProductStructure节点完整
去年给某医疗器械厂做的项目，他们要求所有STEP必须通过NX的ug_check_part -level full，结果发现某批次文件在-level basic下通过，但-level full报错“Missing reference to assembly definition”。根源是CadQuery导出时未设置STEPControl_StepModel的SetSchema为AP214，而默认是AP203。
4. 真实场景复现：从微信消息到车间派工单的72小时
4.1 场景还原：客户微信发来一张手绘图+文字需求
“王工，急！明天上午要打样。按图做支架，材料304不锈钢，表面喷砂。四个安装孔M6，孔距按图上标。底部加两个定位销，Φ8，长度10mm，公差h7。图传你邮箱了。”
附件是手机拍的草图，分辨率模糊，但文字描述清晰。传统流程：工程师花2小时描图→建模→出图→PDF发客户确认→改3版→导出STEP→邮件发生产部。而text-to-cad流水线怎么做？
第1小时：文本预处理
- OCR识别草图文字（用PaddleOCR，比Tesseract在工程图纸上准确率高12%）
- 提取关键句：“M6安装孔”“Φ8定位销”“h7公差”“304不锈钢”
- 自动补全隐含参数：M6孔→底孔Φ5.02mm；h7公差→Φ8h7上偏差0，下偏差-0.015mm；304不锈钢→密度7.93g/cm³，用于质量计算
第2小时：参数化建模
- 调用CadQuery模板：
bracket_template.py，传入参数{"mount_holes": "M6", "loc_pins": {"diameter": 8, "tolerance": "h7"}} - 自动生成带参数特征树的模型：
# 特征树节点示例 # ├─ BasePlate (box: 200x150x20) # ├─ MountHoles (hole: M6, pattern rarray 170x120) # └─ LocPins (cylinder: Φ8h7, height 10)
第3小时：STEP导出与校验
- 执行
exportStep("bracket_v1.step", mode="AP214") stepcheck校验通过- NX导入测试：
ug_check_part -level full bracket_v1.step→ PASS
第4小时：下游集成
- STEP文件自动上传至PLM系统（用Teamcenter REST API）
- 触发MES派工单：调用SAP RFC函数
BAPI_PROCORD_CREATE，传入物料号、数量、交期 - 同步生成PDF图纸：用OCC的
XCAFDoc_Document导出带GD&T标注的PDF
全程72分钟，比传统流程提速95%。客户凌晨发需求，早上9点车间已收到带三维模型的派工单。关键点在于：所有步骤都固化在CI/CD流水线里，每次git push触发Jenkins构建，自动生成STEP并跑校验脚本——就像编译代码一样编译CAD模型。
4.2 避坑指南：那些让项目停摆的“小问题”
提示：CAD软件版本差异是隐形杀手。SolidWorks 2022导出的STEP，在NX 12里能完美读取，但在NX 19里报错“Unknown entity type #1234”。根源是NX 19启用了AP242新协议，而CadQuery默认导出AP214。解决方案：在
exportStep()里强制指定schema="AP214"，并禁用NX的AP242自动升级选项。
注意：中文路径导致STEP导出失败。某次客户服务器路径含“张工_支架”，CadQuery报错
UnicodeEncodeError。根本原因是OCC底层用C++fopen()，Windows默认ANSI编码。修复方案：在Python启动时添加sys.setdefaultencoding('utf-8')，或改用绝对路径r"C:\models\bracket.step"。
实操心得：不要迷信“全自动”。我们给某家电厂做的项目，初始设计是纯文本输入，结果工程师反馈“改一个孔位要重输整段文字”。后来改成“文本+图形交互”模式：先用文字生成基础模型，再用Web界面拖拽调整孔位——保留CAD的交互优势，只把重复劳动自动化。这才是text-to-cad的正确打开方式。
5. 常见问题速查表：从入门到投产的27个典型故障
| 问题现象 | 根本原因 | 解决方案 | 验证方法 |
|---|---|---|---|
| STEP文件在SolidWorks里显示为空白 | OCC未初始化XCAF文档 | 在建模前执行from OCC.Core.XCAFDoc import XCAFDoc_Document; doc = XCAFDoc_Document() | 导入后检查FeatureManager设计树是否有“Imported Geometry”节点 |
rarray生成的孔距错误 | 计算逻辑未考虑边距 | 改用workplane(offset=(x_offset,y_offset))定位，而非依赖rarray的中心偏移 | 用show_object()可视化孔位，测量实际距离 |
| 导出STEP后圆角消失 | .fillet()未指定radius参数 | 显式传入radius=2.0，避免OCC默认值0 | 在NX里用Analysis > Check Geometry检测曲率 |
| GD&T标注未写入STEP | 未创建StepRepr_GeometricTolerance实体 | 调用StepRepr_GeometricTolerance().SetName("Position_Tol") | 用stepcheck -t file.step | grep "geometric_tolerance" |
| 中文材料名导致导出失败 | OCC字符串编码为ASCII | 材料名转英文缩写："304不锈钢"→"SS304" | 导出后用文本编辑器打开STEP，搜索SS304是否在product_definition中 |
| 模型导入NX后质量为0 | 未计算实体质量 | 在导出前执行cq.Assembly().add(part).solve()获取质量 | 用OCC.Core.BRepGProp import BRepGProp; BRepGProp.LinearProperties(shape) |
cq.Workplane().circle()生成非闭合曲线 | OpenCASCADE版本兼容性问题 | 升级OCC至7.7.0+，或改用cq.Workplane().ellipse() | 用shape.Closed()方法返回True |
| STEP文件体积过大（>100MB） | 默认导出所有辅助几何 | 设置exportStep(..., precision=0.01)控制网格精度 | 用ls -lh file.step检查文件大小 |
| 定位销h7公差未体现 | STEP未写入tolerance_value字段 | 手动设置tol.SetValue(0.015) | 用stepcheck -v file.step查看公差值 |
| 模型在Web端显示为黑块 | GLB导出未嵌入材质 | 在exportGLTF()中添加embed=True | 用VS Code打开GLB，搜索"materials"字段 |
独家技巧：当客户要求“按旧图纸改版”时，别重画。用OCC的STEPControl_Reader读取原STEP，提取TopoDS_Shape，再用BRepOffsetAPI_MakeOffset做等距偏移——比从文本重建快3倍。我们给某泵阀厂做的案例，改一个法兰厚度从20mm到25mm，传统方式重画2小时，用此法15分钟搞定，且保证所有孔位相对位置零误差。
6. 不是未来，而是现在：text-to-cad正在改变的三件事
我在东莞一家模具厂亲眼见过：老师傅用游标卡尺量旧模具，报出“导柱Φ25.02mm，磨损0.03mm”，助理工程师在平板上输入“导柱修复：Φ25.05mm，公差h6，材料SKD61”，30秒后生成STEP发给CNC——不是靠经验猜，而是把老师傅的肌肉记忆翻译成机器指令。text-to-cad正在消解的，从来不是工程师的岗位，而是那些本不该由人承担的重复劳动。它让“改图”从加班理由变成点击按钮，让“出图”从交付终点变成数据起点，让“设计变更”从跨部门扯皮变成实时协同。热搜词里反复出现的“cad下载”“cad如何卸载”，恰恰说明旧范式已到极限；而“STEP”“STL”“GLB”的并列，则暴露了行业对数据贯通的迫切渴望。这条路没有银弹，但每一步都踩在真实产线上——当你下次听到“能不能把这段话变成CAD”，别急着找AI工具，先问清楚：要STEP还是GLB？要进车间还是进网页？要改一个尺寸，还是重建整个特征树？答案不同，技术路径天壤之别。我现在的办公桌上，还贴着2019年手写的便签：“CAD自动化不是替代人，是让人回归设计本身。”七年过去，这句话比任何时候都更真。
