CAD 这行当有个特别拧巴的地方设计师脑子里的三维结构要变成机器能读的几何文件中间隔着一整套繁琐的手工建模流程。画个法兰、支架、齿轮箱熟练工也得在草图、约束、拉伸、倒角之间来回折腾几十分钟。而大语言模型现在能写代码、能画流程图、能生成 SQL唯独碰到给我生成一个 STEP 文件这种需求就抓瞎——它输出的永远是文字不是几何。text-to-cad要解决的就是这个断层。它的核心思路很直接把自然语言描述翻译成 CAD 脚本代码再由脚本驱动几何内核生成真正的三维模型文件最终导出 STEP、URDF、G-code 这些下游能直接消费的格式。适合谁看如果你是从业多年的机械设计师想搞清楚 AI 到底能不能替你干重复建模的活如果你是搞机器人仿真的工程师天天被 URDF 手写折磨或者你是做增材制造的想让 G-code 生成流程自动化——这篇内容都值得你花时间读完。下面我按实际落地的顺序把这条链路从头到尾拆一遍。1. 从一句话到三维实体text-to-cad 到底在翻译什么1.1 自然语言和几何内核之间隔着的三层鸿沟很多人第一次听到文字生成 CAD脑子里想的是我说个杯子它就给我个杯子。实际远没这么简单。自然语言描述的是意图而 CAD 文件描述的是精确几何中间至少隔着三层翻译。第一层是语义到参数的映射。一个直径 50mm、厚 10mm 的法兰盘中心开 20mm 通孔边缘均布 6 个 8mm 螺栓孔——这句话里直径、厚度、孔径、孔数、分布方式都是明确参数但均布这个词机器需要理解成沿圆周等角度分布边缘需要理解成距离外圆某个合理距离。这些隐含知识模型必须从训练数据里学到。第二层是参数到建模操作的映射。有了参数还得决定用什么建模原语法兰盘主体是拉伸一个圆环还是旋转一个截面螺栓孔是用布尔减运算挖出来还是用阵列特征生成不同的操作路径生成的几何拓扑结构不一样下游能不能顺利做有限元分析、能不能被 URDF 正确引用差别很大。第三层是建模操作到脚本代码的映射。这一步才是 text-to-cad 真正落地的关键。它不直接操作几何内核而是生成一段可执行的脚本——通常是 CadQuery 或 OpenSCAD 这类基于代码的 CAD 库的 Python 脚本。脚本执行后几何内核OpenCASCADE 或 CGAL才真正计算出 B-rep 实体最后导出成 STEP 或 STL。提示理解这三层鸿沟很重要因为它决定了你评估一个 text-to-cad 方案时该看什么——不是看它生成的模型像不像而是看它生成的脚本能不能改、参数能不能调、导出的 STEP 拓扑是不是干净的。1.2 为什么选脚本代码作为中间表示而不是直接生成几何这里有个设计决策值得展开说。理论上大模型可以直接输出顶点坐标和面片索引拼出一个网格模型。但实际工程里没人这么干原因有三个。可编辑性。脚本是参数化的你把diameter 50改成diameter 60重新执行就得到新模型所有特征自动更新。而一堆顶点坐标改起来就是灾难牵一发动全身。可验证性。脚本是文本可以静态检查语法、可以单元测试、可以做版本控制。你甚至可以让模型自己检查生成的脚本有没有引用未定义的变量。网格数据没法这么玩。与现有工具链的兼容性。CadQuery 生成的实体是真正的 B-rep能导出 STEP能被 FreeCAD、SolidWorks 等主流软件打开继续编辑。而网格模型导出 STEP 后往往是一堆碎面下游根本没法用。所以 text-to-cad 的技术路线基本定型为LLM 生成参数化脚本 → 脚本执行 → 几何内核计算 → 导出标准格式。这条链路里LLM 只负责最前面那段翻译后面的活交给成熟的几何工具各司其职。1.3 一个最小可跑通的例子长什么样光说原理太虚直接看代码。假设你输入生成一个 40mm 见方、高 20mm、中心有 10mm 通孔的方块一个合格的 text-to-cad 系统应该输出类似这样的 CadQuery 脚本import cadquery as cq # 参数定义 length 40.0 width 40.0 height 20.0 hole_dia 10.0 # 建模 result ( cq.Workplane(XY) .box(length, width, height) .faces(Z) .workplane() .hole(hole_dia) ) # 导出 cq.exporters.export(result, block_with_hole.step)这段脚本里参数和建模逻辑是分离的改尺寸只动上面四行。faces(Z)选中顶面.workplane()在顶面建立工作平面.hole()挖通孔——这套链式 API 是 CadQuery 的典型写法。模型要理解中心有通孔对应的是在顶面工作平面上打一个贯穿的孔而不是在侧面或者底面。跑通这个例子你就理解了整条链路。剩下的复杂度都在于怎么让模型稳定地生成正确的脚本以及怎么处理更复杂的几何关系。2. 拆解 text-to-cad 的技术栈LLM、几何内核与格式转换2.1 大模型在这里扮演的角色和它的能力边界LLM 在 text-to-cad 里干的是翻译官的活但它不是万能的。实测下来它的能力边界大致是这样的。擅长的识别常见机械零件的描述模式法兰、支架、轴、齿轮毛坯把尺寸参数正确映射到变量选择合适的建模原语拉伸、旋转、扫掠生成语法正确的 CadQuery 或 OpenSCAD 代码。对于训练数据里出现过的零件类型一次生成成功率相当高。不擅长的处理复杂的空间约束关系这个孔必须和那个槽对齐理解行业特定的公差标注生成需要多步布尔运算的复杂装配体。还有一类高频错误是单位混淆——模型有时候会把毫米当成米或者把直径当成半径。完全靠不住的涉及具体工程标准的细节比如螺纹规格、键槽尺寸、倒角标准。这些必须靠外部知识库或者人工校验补上。所以实际部署时通常会在 LLM 后面加一层校验和修正检查生成的脚本能不能跑通、参数范围是否合理、导出的实体是不是有效的闭合体。跑不通就让模型重试或者回退到模板。2.2 CadQuery 与 OpenSCAD两条主流脚本路线的取舍目前 text-to-cad 领域脚本层基本是 CadQuery 和 OpenSCAD 二选一。两者差别很大选错了后面全是坑。对比维度CadQueryOpenSCAD底层内核OpenCASCADEB-repCGALCSG导出 STEP原生支持拓扑干净不支持只能导 STL参数化能力强支持选择器链式操作中靠变量和模块学习曲线较陡API 丰富平缓语法简单适合场景机械零件、需要下游编辑快速原型、3D 打印LLM 生成难度较高API 组合多较低语法规整如果你的下游是机器人仿真需要 URDF、是数控加工需要 STEP、是要在 SolidWorks 里继续改那必须选 CadQuery因为只有它能导出拓扑干净的 STEP。如果只是 3D 打印个摆件OpenSCAD 足够而且 LLM 生成 OpenSCAD 的准确率明显更高因为它的语法更接近传统编程语言。我个人的经验是做工程用途选 CadQuery做创意用途选 OpenSCAD。别想着一个方案通吃两者的几何表示根本不同混用会出大问题。2.3 STEP、URDF、G-code三种输出格式各自服务谁text-to-cad 生成模型只是第一步真正体现价值的是它能导出什么格式。这三种格式对应三条完全不同的下游链路。STEP是 CAD 领域的通用交换格式存的是精确 B-rep 几何。它的价值在于跨软件兼容——CadQuery 生成的 STEP 能被 SolidWorks、UG、Creo、FreeCAD 打开继续做装配、出工程图、做有限元前处理。如果你要把 AI 生成的模型接入现有设计流程STEP 是唯一选择。URDF是机器人描述格式存的是连杆的几何、质量、惯性、关节关系。它本身不存几何而是引用 STL 或 STEP 文件。text-to-cad 在这里的价值是批量生成机器人连杆——你描述一个六轴机械臂的各段尺寸它生成对应的几何文件加 URDF 描述直接导入 CoppeliaSim 或 Gazebo 就能仿真。手写 URDF 是出了名的痛苦这一步自动化省的时间最多。G-code是数控加工和 3D 打印的指令格式存的是刀具路径。从几何到 G-code 需要切片或 CAM 处理text-to-cad 通常不直接生成 G-code而是生成几何后调用切片软件如 Cura 的引擎或 CAM 库如 FreeCAD 的 Path 模块来生成。它的价值在于打通从描述到加工的最后一公里。注意URDF 导入 CoppeliaSim 时几何文件的路径和单位经常出问题。建议生成 URDF 时统一用米做单位几何文件用 STL 而非 STEP因为 CoppeliaSim 对 STL 的支持更稳定。3. 动手搭一条最小链路从描述到 STEP 文件3.1 环境准备里最容易翻车的依赖问题要跑通 text-to-cad环境配置是第一个坎。CadQuery 依赖 OpenCASCADE这个库在 Windows 上的安装历史包袱很重很多人卡在 C 运行库报错上。推荐用 conda 而不是 pip 装 CadQuery因为 conda 会把 OpenCASCADE 的二进制依赖一起处理好conda create -n text2cad python3.10 conda activate text2cad conda install -c conda-forge cadquery如果你非要用 pip那得先确保系统装了对应版本的 Visual C 运行库。网上那些安装 CAD 出现 C2005 错误的帖子本质都是运行库版本不匹配跟 CAD 软件本身没关系。装 CadQuery 遇到类似报错思路一样先补运行库再装库。LLM 那端如果你用本地模型需要装 transformers 和对应的推理框架如果用 API装个 requests 或 openai 的 SDK 就行。本地跑的话7B 级别的代码模型如 CodeLlama、DeepSeek-Coder在 CadQuery 生成上勉强能用但复杂零件还是得靠更大的模型。3.2 提示词工程怎么描述才能让模型生成对的脚本这一步是 text-to-cad 实操里最影响成功率的环节。同样一个零件描述方式不同生成质量天差地别。我总结了几条实用规则。规则一先给整体形状再给局部特征。别说一个带孔的方块孔在中心方块 40mm要说一个 40mm 见方的方块中心有一个通孔。模型对整体→局部的描述顺序处理得更好。规则二尺寸必须带单位且统一。全程用毫米别一会儿毫米一会儿厘米。模型对单位的推理能力很弱混用必出错。规则三明确建模基准。说清楚零件以哪个面为底面、以哪个轴为中心。比如以 XY 平面为底面沿 Z 轴拉伸比竖着放精确得多。规则四复杂特征拆成多句。一个零件如果有五个特征就写五句话每句一个特征。模型对长句里嵌套多个几何关系的解析能力有限。一个实际可用的提示词模板长这样用 CadQuery 生成以下零件 - 整体直径 80mm、高 30mm 的圆柱 - 特征1中心沿轴向开直径 30mm 的通孔 - 特征2顶面均布 8 个直径 6mm 的孔分布圆直径 60mm - 单位毫米 - 导出为 STEP 文件3.3 脚本执行与几何校验怎么判断生成的模型是对的模型生成了脚本跑通了导出了 STEP不代表模型就是对的。我见过太多次脚本没报错但几何完全不对的情况——比如孔打穿了整个零件、特征位置偏移、实体不闭合。校验分三层。第一层是语法和运行校验脚本能不能跑通这个最简单try-except 就能捕获。第二层是几何有效性校验用 CadQuery 的isValid()方法检查实体是不是有效的闭合体solid result.val() if not solid.isValid(): print(几何无效需要重新生成)第三层是尺寸校验把生成实体的包围盒尺寸和预期对比bb result.val().BoundingBox() print(fX: {bb.xlen}, Y: {bb.ylen}, Z: {bb.zlen})如果包围盒尺寸和描述对不上说明模型理解错了。这三层校验串起来就能自动筛掉大部分错误结果只把靠谱的交给人工确认。3.4 导出 STEP 之后怎么验证文件真的能用STEP 文件导出后别急着往下游送先做两个验证。一是用 FreeCAD 打开看看。FreeCAD 是免费开源的对 STEP 的兼容性好能直接看到几何形状、检查有没有破面。如果 FreeCAD 打开是空的或者报错说明 STEP 文件本身有问题。二是检查文件大小和实体数量。一个正常的简单零件 STEP 文件通常几十 KB 到几 MB。如果只有几 KB可能是空文件如果几十 MB可能是生成了大量碎面。用文本编辑器打开 STEP 文件它是 ASCII 格式搜索MANIFOLD_SOLID_BREP关键字正常应该只有一个或几个如果出现几百个说明几何拓扑很碎下游用起来会出问题。4. 踩过的坑text-to-cad 实操中的典型故障与排查4.1 模型生成的脚本看起来对但几何是错的这是最高频的坑也是最难排查的。脚本语法没问题跑起来也不报错但生成的几何和预期完全不是一回事。我遇到过一个典型案例描述一个 L 形支架两臂各长 50mm宽 20mm厚 5mm模型生成的脚本用两个长方体做布尔并运算但两个长方体的位置没对齐结果是一个错位的十字形而不是 L 形。脚本里每个box()调用都是对的错的是translate()的坐标。排查这类问题不能只看脚本必须看几何。我的做法是生成脚本后先导出 STL用网格查看器如 MeshLab快速看一眼形状。STL 加载快能立刻发现形状错误。确认形状对了再导 STEP 做精细校验。根因通常是模型对空间坐标系的理解不稳定。它知道要并两个体但对并的位置关系推理不可靠。解决办法是在提示词里显式给出坐标比如第一个长方体中心在原点第二个长方体中心在 (25, 10, 0)把空间关系变成明确的数字。4.2 单位、坐标系和布尔运算的连锁错误单位错误往往不是孤立的它会引发一连串连锁反应。模型把毫米当米生成的零件尺寸差 1000 倍然后布尔运算时因为尺寸差异过大几何内核可能直接算失败或者算出一个退化的结果。坐标系错误更隐蔽。CadQuery 默认工作平面是 XYZ 轴向上。但有些模型会假设 Y 轴向上这是很多图形学库的习惯。如果提示词里没说清楚模型可能按 Y 轴向上生成结果零件躺在 XY 平面上下游装配时方向全错。布尔运算的错误通常出在共面上。两个体如果有一个面完全重合布尔并运算可能产生退化边导出的 STEP 在别的软件里打开会报错。规避方法是在设计时让特征之间有微小的重叠或间隙别让面完全贴合。提示在提示词里固定写一句使用 CadQuery 默认坐标系Z 轴向上单位为毫米能规避掉一大半坐标系和单位问题。这句话我每次都加几乎成了肌肉记忆。4.3 复杂装配体生成失败时的降级策略让模型一次生成一个包含十几个零件的装配体成功率很低。这时候需要降级策略拆成单个零件分别生成再用代码组装。具体做法是先让模型生成每个零件的脚本逐个验证通过后再写一个装配脚本用 CadQuery 的Assembly类把零件按位置关系组装起来。这样每一步都可控出错也好定位。from cadquery import Assembly, Location assy Assembly() assy.add(part1, namebase, locLocation((0, 0, 0))) assy.add(part2, namearm, locLocation((0, 0, 30))) assy.save(assembly.step)如果连单个零件都生成不好那就再降一级用模板。把常见零件法兰、支架、轴套做成参数化模板模型只负责填参数不负责生成建模逻辑。这样牺牲了灵活性但换来了稳定性。实际生产环境里模板参数填充的方案反而比纯生成更常用因为可控。4.4 从 STEP 到 URDF 转换时的常见断链STEP 转 URDF 是机器人仿真里的高频需求但这条链路坑特别多。URDF 需要的是每个连杆的几何、质量、惯性矩阵、关节类型和位置而 STEP 只提供几何。质量和惯性得另外算通常用 CAD 软件的质量属性功能或者用 Python 的 trimesh 库从网格估算。几何格式上URDF 引用的是 STL 或 DAE不是 STEP。所以流程是 STEP → STL → URDF。转换时要注意单位URDF 标准用米而 CAD 通常用毫米转换时要除以 1000。忘了这一步导入 CoppeliaSim 后机器人会大 1000 倍整个场景都废了。还有一个坑是坐标系原点。URDF 里每个连杆的几何是相对于连杆坐标系定义的而 STEP 里的零件是相对于全局坐标系。转换时需要重新计算每个连杆的局部原点通常取关节位置或者质心。这一步手工做很繁琐建议写脚本自动处理。5. 把 text-to-cad 接进真实工作流的几种姿势5.1 批量生成标准件参数表驱动的自动化text-to-cad 最实用的场景不是生成复杂零件而是批量生成标准件。比如你要做一系列不同规格的法兰与其一个个描述不如做一张参数表让脚本循环生成。import csv import cadquery as cq with open(flange_specs.csv) as f: for row in csv.DictReader(f): result ( cq.Workplane(XY) .circle(float(row[outer_dia]) / 2) .extrude(float(row[thickness])) .faces(Z).workplane() .hole(float(row[bore_dia])) ) cq.exporters.export(result, fflange_{row[id]}.step)这种模式下LLM 只用来生成一次模板脚本后面全靠参数驱动。效率极高而且结果完全可控。我见过有团队用这种方式把几百个标准件的建模时间从几天压缩到几分钟。5.2 与现有 CAD 软件的协作生成后继续手工精修别指望 text-to-cad 一步到位生成能直接投产的零件。它的定位应该是生成初稿然后设计师在 CAD 软件里精修。实际流程是text-to-cad 生成 STEP → 导入 SolidWorks/FreeCAD → 设计师加倒角、圆角、公差、螺纹特征 → 出工程图。这样设计师省掉了从零建模的时间只需要做精修效率提升明显。这里有个技巧生成时把特征做粗一点别让模型去处理倒角、圆角这些细节。这些特征在 CAD 软件里手工加更快更准而且模型生成这些细节的失败率很高。让 AI 干它擅长的主体形状、孔位布局让设计师干他擅长的工艺细节。5.3 面向增材制造从描述直接到可打印文件3D 打印场景下text-to-cad 的链路可以更短描述 → CadQuery 脚本 → STL → 切片软件 → G-code。中间不需要 STEP因为 3D 打印只认网格。这个场景下OpenSCAD 反而更合适因为它的 CSG 表示天然适合生成网格而且 LLM 生成 OpenSCAD 的准确率更高。一个典型的提示词是生成一个壁厚 2mm、内部中空的立方体容器边长 50mm顶部开口OpenSCAD 几行就搞定。要注意的是壁厚和悬垂角。模型生成的几何可能包含不适合打印的薄壁或大悬垂切片时会出问题。建议生成后先在切片软件里预览检查有没有需要加支撑的地方。这一步目前还得人工判断AI 还替代不了。5.4 机器人仿真链路URDF 自动生成的落地要点机器人仿真是我认为 text-to-cad 价值最高的场景。手写 URDF 又臭又长一个六轴机械臂的 URDF 动辄几百行还容易写错。用 text-to-cad 生成效率提升是数量级的。落地要点有三个。第一连杆几何用简单形状。别生成复杂的曲面连杆用长方体、圆柱体近似就行仿真里看不出来但生成成功率高得多。第二关节位置要精确。关节的 origin 决定了运动学这个必须准建议在提示词里显式给出每个关节的坐标。第三惯性参数用估算。质量按体积乘密度估惯性矩阵用简化公式算仿真精度要求不高的话够用。生成完 URDF 后导入 CoppeliaSim 或 Gazebo 测试。如果机器人动起来姿态不对八成是关节坐标系或者旋转轴方向错了回去检查 URDF 里的axis和origin标签。6. 几个提高成功率的实战心得6.1 提示词里必须显式声明的几件事踩了足够多的坑之后我总结出一份必写清单每次生成前都检查一遍单位毫米还是米坐标系Z 轴向上还是 Y 轴向上建模基准以哪个面为底面输出格式STEP 还是 STL是否需要参数化变量定义还是硬编码这五条写清楚成功率能提升一大截。尤其是单位和坐标系不写的话模型就随机选结果不可预测。6.2 生成结果的自动化校验脚本手工校验太慢建议写个校验脚本把生成、执行、校验串起来def generate_and_validate(prompt, expected_bbox): script call_llm(prompt) try: exec(script) except Exception as e: return False, f执行失败: {e} solid result.val() if not solid.isValid(): return False, 几何无效 bb solid.BoundingBox() actual (bb.xlen, bb.ylen, bb.zlen) if not all(abs(a - e) 1.0 for a, e in zip(actual, expected_bbox)): return False, f尺寸不符: 期望{expected_bbox}, 实际{actual} return True, 通过这个脚本能自动筛掉大部分错误结果只把通过的交给人工。实际用下来能省掉七八成的人工检查时间。6.3 什么时候该放弃 AI 生成回到手工建模不是所有零件都适合 text-to-cad。遇到这几种情况我建议直接手工建模别跟 AI 较劲零件有复杂的自由曲面如叶轮、流道需要精确的工程标准特征如螺纹、花键、齿轮齿形装配关系复杂涉及大量配合约束对公差和表面粗糙度有严格要求这些场景下AI 生成的模型要么形状不对要么精度不够改起来比自己建还慢。text-to-cad 的甜区是规则几何、参数明确、精度要求不高的零件认清这个边界才能把它的价值最大化。6.4 把生成脚本纳入版本管理的习惯最后说个工程习惯把 LLM 生成的脚本存进 Git。每次生成的脚本、对应的提示词、校验结果都记录下来。这样做有三个好处一是出问题能回溯知道哪个版本的脚本有问题二是好的提示词能复用慢慢积累成自己的提示词库三是团队协作时别人能看到你是怎么描述零件的减少沟通成本。我现在的做法是每个零件一个文件夹里面放prompt.txt、model.py、output.step和validation.log。时间长了这就是一个可复用的零件生成知识库比任何文档都实用。这套东西我用了大半年最大的体会是text-to-cad 不是要取代设计师而是把设计师从重复劳动里解放出来。它擅长的是把明确的需求快速变成几何初稿不擅长的是处理模糊需求和工艺细节。把这两件事分清楚用起来就顺手了。