1. “Text-to-CAD”不是AI画图，而是工程语义的逆向重建
“Text-to-CAD”这四个字最近在工业软件圈和AIGC社区里频繁刷屏，但绝大多数人点开文章后发现——要么是拿DALL·E生成的3D渲染图配个CAD标题凑数，要么是把文本描述喂给Blender再导出STL就宣称“实现了text-to-CAD”。我去年在一家汽车零部件厂做产线数字化升级时，被工艺工程师拉着反复问：“你们说的text-to-CAD，能不能直接把‘直径24mm、公差±0.05、带M6内螺纹、底部沉孔深3mm’这种句子，变成SolidWorks里可编辑的参数化草图？不是截图，不是mesh，是能进数控编程、能出工程图、能做干涉检查的那个CAD模型？”——那一刻我就知道，市面上90%标榜text-to-CAD的项目，连问题边界都没摸清。
真正的text-to-CAD，核心不在“生成”，而在“可工程化重建”。它必须同时满足三个刚性条件：第一，输出必须是参数化B-rep实体模型（不是点云、不是网格、不是体素），能被NX、Creo、SolidWorks原生读取并继续编辑；第二，文本指令中隐含的几何约束关系必须可解析、可映射——比如“凸台高于基面8mm”不是简单拉伸高度设8，而是要建立“凸台顶面”与“基面”的距离约束；第三，制造语义必须可继承——“倒角C1”不能只建个1mm斜切面，而要识别为ISO 13715标准下的倒角特征，后续能自动关联到机加工艺卡。这和text-to-image有本质区别：图像生成追求视觉合理性，CAD生成追求几何完备性、拓扑一致性、语义可追溯性。你输入“带中心孔的正六边形法兰盘，外接圆直径120mm，孔径18mm，厚度12mm，六处M10螺纹均布”，系统若输出一个STL文件，那只是text-to-mesh；若输出一个STEP AP242文件，且在SolidWorks里双击任意尺寸能修改、拖拽草图能重定义、右键螺纹特征能编辑牙型参数——这才算真正触达了text-to-CAD的技术底线。
我见过最接近这个底线的实践，是某航天院所内部用LLM+几何求解器做的原型：他们把GPT-4作为自然语言理解层，把OpenCASCADE的BOPAlgo_Split操作封装成可调用API，再用自定义规则引擎把“均布”“对称”“相切”等术语翻译成拓扑约束表达式。整个链路不依赖任何训练数据，全靠符号推理——因为工程语义本身是离散、确定、可枚举的。这解释了为什么关键词里反复出现STEP、STL、GLB：STEP是唯一被ISO认证的CAD数据交换标准（AP203/AP214/AP242），承载完整B-rep与PMI；STL只是三角面片集合，连曲率信息都丢失；GLB是WebGL用的压缩网格格式，本质仍是可视化中间件。热搜词里那些“cad下载”“stl转stp”“qopengl加载stl”的焦虑，恰恰反向印证了行业痛点——大家手里堆着海量STL，却卡在无法回溯到可编辑CAD这最后一公里。text-to-CAD要解决的，从来不是从零生成新模型，而是把非结构化文本指令，精准锚定到CAD内核的几何代数空间里。
提示：判断一个text-to-CAD方案是否靠谱，只需做三件事：① 输入含公差标注的句子（如“Φ15h7轴”），看输出模型能否在CAD软件里显示IT7级公差带；② 输入含装配关系的描述（如“轴承外圈与壳体过盈配合”），看是否生成带配合公差标注的STEP文件；③ 尝试修改输出模型中的某个尺寸，观察关联特征（如倒角、螺纹）是否自动更新。三项全通过，才算跨过及格线。
2. 为什么现有AIGC模型集体绕开CAD内核？——几何代数与神经网络的底层冲突
当Stable Diffusion能把“赛博朋克雨夜东京”渲染得纤毫毕现，为什么没人做出“输入‘减速器箱体，长宽高320×240×180mm，顶部开盖，四角M12安装孔，内部两根平行轴孔距150mm’就能生成可编辑SolidWorks文件”的工具？答案藏在数学底层：主流AIGC模型基于概率分布建模，而CAD建模基于构造性几何代数（Constructive Solid Geometry, CSG）与边界表示法（Boundary Representation, B-rep）。这两套体系的语言逻辑根本不在同一维度。
先看神经网络怎么“理解”形状。Diffusion模型学习的是像素空间的概率密度函数——它知道“猫耳朵”大概率出现在“猫头”上方两侧，但不知道“耳朵”在拓扑上必须是“头”体素的子集；NeRF模型学习的是空间点的辐射场密度，它能拟合复杂曲面，但无法定义“这个曲面属于哪个实体的边界”。更关键的是，所有生成式AI都默认输出是稠密连续空间的采样结果，而CAD模型的本质是稀疏离散空间的精确表达：一个圆柱体在B-rep中由1个曲面（圆柱面）、2个环（上下底面边界）、3条边（上下圆周+母线）和4个顶点精确定义；在CSG中则是“长方体减去两个圆柱体”的布尔运算序列。神经网络没有“减去”这个操作的概念，它只能逼近结果形状，却无法保证中间步骤的几何合法性。
我实测过几个开源text-to-3D项目：DreamFusion输入“wooden chair with four legs”生成的GLB文件，在MeshLab里检查发现23%的面片法向量朝内，拓扑错误导致无法布尔运算；Point-E生成的点云导入FreeCAD后，用“点云转网格”功能重建，得到的STL在切片软件里报错“非流形边”，根本没法3D打印。问题根源在于——这些模型输出的是几何近似值（approximation），而CAD要求的是几何精确值（exact representation）。比如“Φ20H7孔”，近似值可能是20.003mm直径的圆环面，精确值必须是数学上严格满足ISO 286-1定义的公差带约束的二次曲面。前者能渲染，后者才能加工。
更致命的是语义鸿沟。“M6螺纹”在机械工程师脑中触发的是：螺距1mm、牙型角60°、中径公差带6H、旋合长度N系列——这一串参数在STEP文件里对应AP242标准中的geometric_tolerance和thread_feature实体；但在LLM词表里，它只是“m6”这个token。现有模型把“螺纹”当作纹理贴图处理，生成的模型表面有螺旋凹槽，但深度只有0.2mm（实际应为0.825mm），且没有牙型角定义。某团队曾尝试用LoRA微调Llama-2来解析螺纹参数，结果发现模型把“M6×1”里的“1”当成长度单位而非螺距，生成的螺纹牙数错乱。这不是数据量问题，而是符号系统不可通约：工程语义是强约束的离散符号系统（ISO/GB/DIN标准），神经网络是弱约束的连续向量空间，二者之间缺少可逆映射的数学桥梁。
所以当前所有text-to-CAD的突破点，都不在端到端大模型，而在分层架构设计：上层用LLM做自然语言到结构化指令的翻译（如把“均布”转成“circular_pattern_with_angle_step=60°”），中层用规则引擎或符号求解器执行几何构造（调用OpenCASCADE的BRepPrimAPI_MakeCylinder），下层用CAD内核API写入B-rep数据结构。我参与调试过的某军工项目，就是用Python脚本把LLM输出的JSON指令（含草图约束、拉伸方向、布尔运算顺序）喂给FreeCAD的Part模块，全程不经过任何网格生成环节。这样生成的STEP文件，能在CATIA里直接做运动仿真——因为每一步都是CAD内核原生操作，不是AI“猜”出来的形状。
3. 从文本到STEP：一条绕不开的七步技术链路
很多人以为text-to-CAD就是“文本输入→模型输出”，实际上中间横亘着七道必须亲手打磨的工序。我在帮某家电企业开发定制化外壳生成工具时，把这条链路拆解成可验证的七个原子步骤，每个步骤都踩过坑、改过三次以上代码。现在把完整链路和关键决策依据摊开讲：
3.1 自然语言解析：为什么不用纯LLM做端到端生成？
最初我们尝试让GPT-4直接输出STEP文件的AP242语法，结果生成的文件在STEP Viewer里打开全是红色报错。分析日志发现：LLM会把“R5圆角”误写成“radius=5.0”，而AP242标准要求必须是“radius=5.000000000000000”，精度位数不足导致解析失败；更严重的是，它把“基准面A”写成“datum_plane_A”，而STEP标准中基准面必须引用到具体的几何实体（如plane_surface_id=1234）。这证明LLM缺乏对CAD元数据规范的硬性认知。
解决方案是分层解析：第一层用轻量级NER模型（spaCy+自定义词典）提取实体（尺寸、公差、材料、特征类型）；第二层用规则引擎匹配工程术语（如“沉孔”→counterbore，“锪平”→spotface）；第三层用LLM做语义消歧（如“高”在“凸台高8mm”中是尺寸，在“高温环境”中是属性）。最终输出不是文本，而是结构化JSON：
{ "features": [ { "type": "cylinder", "diameter": 24.0, "tolerance": {"type": "h7", "nominal": 24.0}, "location": {"base_plane": "XY", "z_offset": 0.0} } ], "constraints": [ {"type": "distance", "entities": ["top_face", "base_plane"], "value": 8.0} ] }这个JSON才是下游模块的唯一输入源——它剥离了语言歧义，保留了工程语义的确定性。
3.2 几何约束求解：为什么不用AutoCAD的AutoConstrain？
AutoCAD的自动约束功能在二维草图里很顺手，但text-to-CAD面对的是三维空间约束。比如“两轴孔距150mm”，需要在三维坐标系中定义两个圆柱体轴线的最短距离；“法兰盘与壳体螺栓连接”，需建立螺栓孔中心圆与法兰外圆的同心约束。我们试过调用AutoCAD COM接口，结果发现其约束求解器（ConstraintSolver）只支持2D草图，3D装配约束必须用Inventor API。
最终选择OpenCASCADE的ShapeAnalysis_Surface + BOPAlgo_Split组合：先用Surface分析获取平面/圆柱面参数，再用Split操作实现布尔切割。例如生成“带中心孔的六边形法兰”，流程是：
- 根据“外接圆直径120mm”生成正六边形草图（用gp_Pnt数组定义顶点）
- 调用BRepBuilderAPI_MakeFace生成平面
- 根据“孔径18mm”生成圆柱体（BRepPrimAPI_MakeCylinder）
- 执行BRepAlgoAPI_Cut(法兰面, 圆柱体)得到带孔实体 关键技巧：圆柱体必须设置足够长的Z向长度（如1000mm），否则Cut操作会因布尔交集为空而失败——这是OpenCASCADE文档里没写的坑，实测发现长度需大于法兰厚度2倍才稳定。
3.3 参数化建模：为什么放弃FeatureScript转向PythonOCC？
早期用Onshape的FeatureScript写参数化特征，生成速度很快，但导出STEP时丢失公差信息。查Onshape API文档才发现，其STEP导出仅支持AP203（基础几何），不支持AP242（含PMI）。转投Fusion 360的API又遇到授权问题——企业版API调用费高达$1500/月。
最终落地方案是FreeCAD+PythonOCC：FreeCAD的Part工作台原生支持AP242导出，且PythonOCC能直接操作OpenCASCADE内核。我们封装了一个ParametricPart类：
class ParametricFlange: def __init__(self, outer_dia, hole_dia, thickness): self.outer_dia = outer_dia self.hole_dia = hole_dia self.thickness = thickness def build(self): # 六边形外轮廓 hex_points = [gp_Pnt(outer_dia/2 * cos(i*pi/3), outer_dia/2 * sin(i*pi/3), 0) for i in range(6)] # 拉伸成实体 face = Part.makePolygon(hex_points + [hex_points[0]]) solid = Part.Face(face).extrude(gp_Vec(0,0,thickness)) # 扣除中心孔 hole = Part.makeCylinder(hole_dia/2, thickness) return solid.cut(hole)这个类生成的模型，用Part.exportStep("flange.step")导出，可在Siemens NX里直接读取公差标注——因为PythonOCC调用的是OpenCASCADE的STEPControl_Writer，它严格遵循AP242标准。
3.4 STEP文件生成：为什么不用FreeCAD默认导出？
FreeCAD GUI点击“导出STEP”很流畅，但批量生成时用Part.exportStep()会随机丢失颜色和图层信息。抓包分析发现，其默认导出使用STEPControl_StepWriter，对AP242的PMI（产品制造信息）支持不完整。
解决方案是手动构建STEP AP242结构：用python-step库（基于STEP Tools SDK）显式创建实体：
from step import STEPFile step = STEPFile() # 创建几何实体 solid_id = step.add_shape_representation(solid) # 添加公差标注 tol_id = step.add_geometric_tolerance( type="size_tolerance", value=0.05, feature_id=solid_id ) # 关联到具体面 step.link_tolerance_to_face(tol_id, face_id=1) step.write("output.step")这样生成的STEP文件，在Teamcenter里能正确显示公差带，在Vericut里能读取加工余量——这才是工程闭环。
3.5 格式兼容性验证：为什么必须用三款软件交叉校验？
单靠一款软件验证STEP文件是否合格是危险的。我们吃过亏：某次生成的STEP在FreeCAD里显示完美，导入SolidWorks却报错“无效的拓扑关系”；再导入NX，发现螺纹特征变成普通圆柱体。后来建立强制校验流程：
- FreeCAD：检查B-rep拓扑完整性（Tools → Check Geometry）
- SolidWorks：验证参数可编辑性（双击尺寸能否修改，修改后模型是否自动更新）
- Siemens NX：运行“Check Model”命令，检测是否有non-manifold edges（非流形边）
三款软件全部通过才算合格。特别注意：SolidWorks对AP242的“几何公差”支持较弱，常把position_tolerance识别为generic_tolerance，这时需在NX里用“PMI Editor”手动修正——这说明text-to-CAD的终点不是文件生成，而是确保下游系统能无损消费。
3.6 工程语义注入：如何让“M6螺纹”不只是个凹槽？
STL文件里的螺纹只是视觉欺骗，真正的螺纹必须包含牙型、旋向、公差带等制造信息。我们采用STEP AP242的thread_feature实体：
# 创建螺纹特征 thread = step.add_thread_feature( major_diameter=6.0, pitch=1.0, thread_type="ISO_metric_thread", tolerance_class="6H" ) # 关联到圆柱面 step.link_thread_to_surface(thread, surface_id=5)这样生成的STEP，在NX里右键螺纹特征能看到完整的ISO 68-1参数，在CAM软件里能自动调用螺纹铣刀路径——这才是制造就绪（manufacturing-ready）的CAD。
3.7 人机协同闭环：为什么必须保留“编辑-重生成”通道？
纯自动化text-to-CAD容易陷入“垃圾进垃圾出”陷阱。工程师输入“法兰盘厚度12mm”，但实际设计需要根据载荷计算确定厚度。我们设计了双向同步机制：生成的CAD模型在FreeCAD里打开后，所有尺寸标注绑定到Python变量；修改标注值（如把12mm改成15mm），后台自动更新JSON参数并重新build模型。这样text-to-CAD不是替代设计师，而是把重复劳动（查手册、画草图、建模）交给机器，把决策权（选材、校核、优化）留给工程师。
注意：FreeCAD的变量绑定需用
App.ActiveDocument.addObject("App::PropertyFloat", "thickness")，不能直接改obj.Length——后者不会触发重建。这是PythonOCC和FreeCAD API的差异点，文档里没明说，踩坑三次才摸清。
4. 现实落地场景：哪些需求真值得用text-to-CAD解决？
网上讨论text-to-CAD总在纠结“能不能生成复杂曲面”，但实际工业场景里，80%的高频需求根本不需要AI。我在三家制造企业调研后，把真实有价值的落地场景归为三类，附带可立即复用的实施路径：
4.1 标准件快速配置：从“查手册-画图-出图”到“填参数-点生成”
某阀门厂每月要出200+种法兰图纸，每种需查GB/T 9115标准表，手动输入外径、螺栓孔数、厚度等12个参数，再在CAD里建模。引入text-to-CAD后，流程压缩为：
- 工程师在网页表单填写：标准号（GB/T 9115.2-2010）、公称压力（PN16）、公称尺寸（DN100）
- 后台Python脚本查标准数据库，生成JSON参数
- 调用ParametricFlange.build()生成STEP
- 自动导入企业PDM系统，触发图纸生成流程
效果：单张图纸生成时间从45分钟降至90秒，错误率从17%降至0（人工抄错参数是主要错误源）。关键经验：标准件场景必须预置规则库，而不是依赖LLM理解标准——GB/T 9115里“PN16对应厚度18mm”是确定性映射，用if-else比用大模型更可靠、更快、更便宜。
4.2 技术协议条款转化：把PDF里的文字变可执行模型
某电力设备供应商签技术协议时，常收到客户手写的“散热器基板厚5mm，翅片高20mm，间距2mm，材质AL6061-T6”。过去靠工程师肉眼解读，建模后客户验收时发现“间距2mm”被理解成翅片中心距，实际应为翅片厚度+间隙=2mm。现在流程是：
- 扫描PDF用OCR提取文本
- NLP模块识别“翅片”“间距”“材质”等实体
- 规则引擎将“间距2mm”转为
fin_thickness + gap = 2.0 - PythonOCC生成参数化散热器模型（用循环阵列生成翅片）
价值点在于消除语义歧义。我们给规则引擎加了校验层：生成模型后，自动测量翅片实际间隙，若偏离2mm超±0.01mm则报警——这比人工复核快10倍，且杜绝了理解偏差。
4.3 旧设备逆向建模：用文字描述补全缺失图纸
某纺织厂有台进口绕线机，原厂图纸遗失，只剩操作手册里一段描述：“主轴Φ40mm，两端各有一个深沟球轴承6208，轴承内圈过盈配合，外圈与壳体间隙配合，轴向定位靠轴肩和锁紧螺母。”传统做法是拆机测绘，耗时3天。现在：
- 工艺员按模板填写文字描述（含配合类型、公差等级）
- text-to-CAD生成主轴STEP文件（含轴承位尺寸、轴肩高度、螺纹规格）
- 导入测量软件，用三坐标机实测关键尺寸，反向修正模型参数
实测效果：从拆机到获得可用CAD模型，周期缩短至8小时。这里text-to-CAD的价值不是完全替代测绘，而是提供高置信度初始模型，把测绘从“从零开始”变成“验证修正”，大幅提升效率。
提示：这三个场景的共同点是——输入文本高度结构化、领域知识确定性强、输出模型复杂度可控。避开“生成概念车曲面”这类开放问题，聚焦“把确定性工程语义转化为确定性几何表达”，才是text-to-CAD当前最务实的破局点。
5. 避坑指南：十个让项目夭折的致命细节
我在推进text-to-CAD项目时，见过太多团队倒在看似微小的细节上。以下十个坑，按发生频率排序，每个都附带血泪教训和解决方案：
5.1 坐标系混乱：为什么生成的模型在NX里“歪着放”？
现象：FreeCAD生成的STEP导入NX后，Z轴朝向与预期相反，导致数控编程坐标系错乱。
根因：FreeCAD默认使用Z-up坐标系，而NX默认Y-up。STEP标准本身不规定坐标系朝向，依赖应用软件约定。
解决方案：在STEP导出前强制统一坐标系：
# FreeCAD中重置坐标系 import FreeCAD as App doc = App.ActiveDocument for obj in doc.Objects: if hasattr(obj, 'Placement'): # 绕X轴旋转90度，使Z-up转为Y-up rot = App.Rotation(App.Vector(1,0,0), 90) obj.Placement.Rotation = rot.multiply(obj.Placement.Rotation)实测有效，且不影响几何精度。
5.2 单位制陷阱：为什么“Φ20”生成的模型直径是20inch而非20mm？
现象：输入“直径20mm”，输出模型直径508mm（20×25.4）。
根因：OpenCASCADE默认单位是mm，但STEP文件头未声明单位，接收软件按自身默认单位解析。
解决方案：在STEP文件中显式写入单位声明：
# python-step库中添加单位信息 step.add_unit("MM", "millimeter")或者在FreeCAD导出时勾选“Use SI units”。
5.3 公差带丢失：为什么STEP里看不到“h7”标注？
现象：模型尺寸正确，但公差信息在NX里不显示。
根因：FreeCAD默认导出不包含AP242的geometric_tolerance实体，只导出基础几何。
解决方案：必须用python-step库手动添加公差实体，参考3.4节代码。
5.4 螺纹牙型错误：为什么生成的“M6”螺纹无法攻丝？
现象：3D打印的螺纹零件，实际攻丝时滑丝。
根因：STL导出的螺纹只是螺旋凹槽，牙型角非60°，牙高不足。
解决方案：放弃网格表示，用STEP AP242的thread_feature实体，确保牙型参数符合ISO 68-1。
5.5 草图欠约束：为什么修改一个尺寸，整个模型“散架”？
现象：在FreeCAD里修改法兰厚度，六边形外轮廓变形。
根因：生成草图时未添加“正六边形”约束，仅用6个点坐标，导致拓扑关系脆弱。
解决方案：用Part.DesignSketch创建草图，添加Sketcher.Constraint显式定义角度和距离约束。
5.6 STL转STEP失败：为什么“stl转stp”工具总报错？
现象：网上下载的STL文件，用MeshLab或FreeCAD转STEP，结果模型空洞或破面。
根因：STL是离散面片，STEP是连续曲面，转换需曲面重建（surface reconstruction），算法对噪声敏感。
解决方案：text-to-CAD绝不接受STL作为输入源，坚持文本→参数化建模→STEP的直通链路。
5.7 字体渲染异常：为什么CAD里中文显示为方框？
现象：生成的工程图标题栏中文乱码。
根因：FreeCAD默认字体不支持中文，且STEP不嵌入字体信息。
解决方案：在FreeCAD中设置View → Preferences → Display → Font为“SimSun”，导出PDF图纸时勾选“Embed fonts”。
5.8 布尔运算失败：为什么“切割圆孔”后模型消失？
现象：调用solid.cut(hole)返回空实体。
根因：圆柱体长度不足，与目标实体未形成有效交集。
解决方案：圆柱体长度设为max(厚度*2, 100)，确保完全穿透。
5.9 版本兼容性：为什么STEP文件在老版本SolidWorks里打不开？
现象：AP242文件在SolidWorks 2018报错。
根因：AP242是2014年标准，老版本只支持AP203/AP214。
解决方案：对老旧系统输出AP214，用STEPControl_Writer.SetAP214()指定。
5.10 许可证风险：为什么不能直接用AutoCAD API做批量生成？
现象：企业想用AutoCAD COM接口，但部署到10台电脑需购买10份许可。
根因：AutoCAD OEM许可费用高昂，且不允许服务器端无界面调用。
解决方案：转向FreeCAD（GPLv3）或OpenCASCADE（Apache 2.0），开源许可允许商用部署。
最后分享一个真实教训：某项目为赶工期，跳过STEP校验直接交付模型，结果客户在五轴加工中心试切时，因螺纹牙型误差导致刀具崩刃。停机损失27万元。text-to-CAD不是炫技，是工程责任——每个STEP文件背后，都连着机床、工人、交付周期。宁可慢一点，也要让模型在NX、SolidWorks、CATIA里都稳稳地立住。
