1. 从一句话到三维实体text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人脑子里浮现的画面大概是对着电脑说一句给我画个法兰盘屏幕上就自动蹦出一个带倒角、带螺栓孔的 STEP 模型。这个想象不算离谱但真正落地的时候它解决的问题比省几下鼠标要深刻得多。传统 CAD 工作流的本质是手工几何建模。你打开 SolidWorks、Fusion 360 或者中望 CAD画草图、拉伸、打孔、倒角每一步都靠人手点出来。这套流程成熟、精确、可控但它有一个绕不开的瓶颈几何模型的产出速度取决于人点鼠标的速度。一个中等复杂度的零件熟练工程师也要半小时到几小时如果是上百个规格的系列件那就是纯体力活。text-to-cad 想干的事情是把人描述需求和机器生成几何这两端接起来。输入是一段自然语言或者结构化文本输出是 CAD 能直接读取的几何文件——可能是 STEP、可能是 URDF、也可能是 G-code。它不是一个软件而是一类文本驱动几何生成的技术路线集合。我先把话说在前面目前没有任何一个 text-to-cad 方案能做到随便说句话就出完美工程图。大语言模型对几何的理解还停留在能生成合理参数的层面真正的几何内核比如 OpenCASCADE、Parasolid还是得靠代码去调。所以现实中的 text-to-cad主流形态是LLM 解析文本 → 生成参数化脚本 → 几何内核执行 → 导出标准格式这样一条链路。这条链路里几个关键词必须拎清楚CAD最终产物要能被 CAD 软件打开这是底线。不是生成一张图片是生成真正的边界表示BRep实体。STEPISO 10303 标准下的几何交换格式几乎是所有工业 CAD 的通用语言。text-to-cad 的输出如果能落到 STEP通用性最强。URDF统一机器人描述格式XML 结构描述机器人的连杆、关节、惯性。做机器人仿真的人对这个词又爱又恨。G-code数控机床和 3D 打印机的指令语言是几何模型走向物理制造的最后一公里。这四个词基本勾勒出了 text-to-cad 的完整价值链文本 → 参数化几何 → STEP设计交付→ URDF仿真验证→ G-code物理制造。你做的项目落在哪个环节决定了你要啃哪块硬骨头。这篇文章适合谁看如果你是机械、机器人、增材制造方向的工程师想搞清楚怎么把 LLM 接进自己的建模流程如果你是做自动化脚本的开发者想批量生成零件模型或者你只是被AI 画图这个概念吸引想看看它在工程领域到底能落地到什么程度——那接下来的内容应该对你有用。我会把整条链路拆开讲包括每一步为什么这么选、参数怎么定、哪里最容易翻车。2. 文本到几何的翻译层LLM 到底该输出什么2.1 为什么不能让 LLM 直接吐 STEP 文件这是新手最容易踩的第一个坑。很多人第一反应是STEP 是文本格式啊那我让 GPT 直接生成 STEP 不就行了理论上可行实际上灾难。STEP 文件是 ISO 10303-21 定义的纯文本格式一个中等复杂度的零件STEP 文件动辄几千上万行里面全是#123 CARTESIAN_POINT(,(0.,0.,0.));这种实体引用。LLM 生成这种内容有两个致命问题第一几何一致性无法保证。STEP 里的实体是相互引用的一个面引用一组边一条边引用两个顶点。LLM 逐 token 生成的时候它根本看不见自己前面生成的引用编号是否闭合。结果就是文件语法看着像那么回事一导入 CAD 就报拓扑错误。第二token 成本爆炸。一个带 20 个特征的零件STEP 轻松超过 5000 行。按现在的 token 价格生成一个零件几毛到几块钱批量做根本不划算。所以正确的做法是让 LLM 输出参数化脚本而不是几何文件本身。脚本可以是 CadQuery 的 Python 代码、OpenSCAD 的 DSL、或者你自己定义的 JSON 参数结构。脚本短、可读、可调试几何内核负责把它变成真正的实体。2.2 CadQuery 为什么成了 text-to-cad 的事实标准在众多参数化建模方案里CadQuery 是目前 text-to-cad 项目里出现频率最高的。原因很实在它是 Python 库LLM 对 Python 的生成质量远高于其他语言它基于 OpenCASCADE输出的是真正的 BRep 实体能导出 STEP、STL、DXF它的 API 是链式的cq.Workplane(XY).circle(10).extrude(5)这种写法语义清晰LLM 容易学也容易生成对。对比一下几种常见方案方案语言输出格式LLM 友好度适用场景CadQueryPythonSTEP/STL/DXF高通用机械零件OpenSCAD自有 DSLSTL/CSG中3D 打印、简单结构build123dPythonSTEP/STL高CadQuery 的现代替代FreeCAD 脚本Python全格式中需要完整 CAD 功能直接生成 STEP-STEP极低不推荐我实测下来CadQuery 生成的代码一次通过率能跑通不报错大概在 60% 到 70%剩下的靠报错信息让 LLM 自己修两三轮基本能收敛。这个成功率对于辅助建模来说已经够用了。2.3 提示词工程在几何生成里的特殊之处给 LLM 写几何生成的提示词和写文案完全是两码事。核心区别在于几何有硬约束文案没有。你不能只说生成一个法兰盘得把关键参数喂进去。一个能用的提示词模板大概长这样你是一个 CadQuery 专家。请根据以下规格生成 Python 代码 - 零件类型法兰盘 - 外径100mm - 内径中心通孔40mm - 厚度15mm - 螺栓孔6 个直径 8mm均匀分布在直径 80mm 的圆周上 - 所有外边缘倒角 2mm 要求 1. 使用 cq.Workplane API 2. 最后导出为 STEP 文件 3. 代码必须可直接运行不要有伪代码这里有几个经验点值得说第一单位必须显式声明。CadQuery 默认单位是毫米但 LLM 有时候会自作主张按厘米算。提示词里写死单位 mm能省掉后面一堆尺寸对不上的麻烦。第二特征顺序要暗示。先打孔还是先倒角结果完全不同。倒角后再打孔孔口是锐边打孔后倒角孔口会被倒角影响。提示词里最好按建模顺序描述特征。第三让 LLM 输出中间变量。与其让它写一长串链式调用不如要求它把关键尺寸定义成变量比如outer_d 100。这样后面改参数、调试都方便也降低了链式调用写错的概率。提示如果你要批量生成系列件把提示词做成模板参数部分用占位符替换。我见过有人用 Jinja2 模板管理几百个零件的规格配合 LLM 批量生成脚本效率比手工建模高一个数量级。3. 几何内核与格式导出STEP、URDF、G-code 各自的坑3.1 STEP 导出为什么你的模型在别人电脑上打不开STEP 是 text-to-cad 最主流的交付格式但导出这一步的坑特别多。最常见的问题是单位不一致。STEP 文件头里有一个SI_UNIT声明规定文件里的长度单位是毫米还是米。CadQuery 默认导出毫米但如果你用的几何内核配置不对导出的文件可能被 CAD 软件按米解读结果一个 100mm 的零件变成 100m。我遇到过有人导出的模型在 SolidWorks 里打开尺寸大了 1000 倍排查了半天才发现是单位声明的问题。第二个坑是精度设置。STEP 导出时可以指定线性精度和角度精度。精度设太高文件巨大设太低曲面变成多边形圆孔变成六边形。对于一般机械零件线性精度 0.01mm、角度精度 0.1 度是个比较平衡的值。# CadQuery 导出 STEP 的推荐写法 import cadquery as cq result ( cq.Workplane(XY) .circle(50) .extrude(15) .faces(Z) .workplane() .hole(40) ) # 显式指定精度和单位 cq.exporters.export( result, flange.step, opt{ write_pcurves: False, # 不写参数曲线减小文件 precision_mode: 1, # 精度模式 } )第三个坑是拓扑有效性。有时候脚本能跑通模型也能显示但导出的 STEP 在别的软件里报非流形或者自相交。这通常是布尔运算的残留问题。解决办法是在导出前做一次clean()操作或者用Shape.fix()修复拓扑。3.2 URDF从 CAD 到机器人仿真的惊险一跃URDF 这个词在热搜里出现多半是因为有人想把 CAD 模型导入 CoppeliaSim 做仿真。这个流程我走过说实话比 STEP 导出麻烦得多。URDF 不是几何格式它是运动学描述格式。它描述的是这个机器人由哪些连杆组成、连杆之间怎么连接、每个关节怎么运动、质量惯性是多少。所以从 CAD 到 URDF你要做的不是简单导出而是语义映射CAD 里的一个装配体要拆成 URDF 里的多个 link装配体里的配合关系要翻译成 URDF 的 joint每个零件的材料密度要换算成 URDF 的 inertial 参数。这里最大的坑是坐标系。CAD 软件里每个零件有自己的局部坐标系URDF 里每个 link 也有自己的坐标系而且 URDF 规定 link 的原点必须在关节轴线上。如果你直接从 CAD 导出坐标系十有八九对不上导入 CoppeliaSim 后机器人要么散架要么关节转起来像抽风。我的做法是在 CAD 里就把坐标系建好。每个零件的原点放在它和父连杆的连接点Z 轴对齐关节轴线。这样导出 STL 后在 URDF 里写 joint 的 origin 时直接填零或者填简单的平移量就行。一个典型的 URDF link 定义link nameupper_arm visual geometry mesh filenameupper_arm.stl scale0.001 0.001 0.001/ /geometry origin xyz0 0 0 rpy0 0 0/ /visual collision geometry mesh filenameupper_arm.stl scale0.001 0.001 0.001/ /geometry /collision inertial mass value1.2/ inertia ixx0.001 ixy0 ixz0 iyy0.001 iyz0 izz0.001/ /inertial /link注意那个scale0.001 0.001 0.001。STL 通常按毫米导出URDF 默认单位是米所以必须缩放。这个细节坑过无数人导入 CoppeliaSim 发现机器人是个巨人或者蚂蚁八成就是这里没设对。3.3 G-code几何模型走向物理世界的最后一关G-code 是数控加工和 3D 打印的指令语言。从 text-to-cad 的角度看G-code 不是直接生成的而是几何模型经过切片或 CAM 处理后的产物。对于 3D 打印流程是STEP/STL → 切片软件Cura、PrusaSlicer→ G-code。对于 CNC 加工流程是STEP → CAM 软件Fusion CAM、Mastercam→ G-code。text-to-cad 在这里能发挥的作用是批量生成待加工的几何模型。比如你要打印 50 个不同尺寸的支架手工建模要疯但用脚本生成 50 个 STEP再批量切片就轻松多了。G-code 本身有几个参数必须搞清楚层高3D 打印常见 0.1-0.3mm越小越精细越慢填充率15%-25% 是常规结构件的甜点区打印速度外壁慢、内部快这是基本策略回抽设置决定拉丝严重程度PETG 比 PLA 需要更激进的回抽。这些参数不在 text-to-cad 的生成范围内但你在设计几何时就要考虑。比如悬垂角度超过 45 度就需要支撑薄壁小于喷嘴直径就打印不出来。文本生成几何的时候把制造约束一起考虑进去才是真正可用的方案。4. 一条能跑通的 text-to-cad 流水线怎么搭4.1 环境准备别在第一步就卡住搭 text-to-cad 流水线环境配置是第一个拦路虎。我把踩过的坑列一下。CadQuery 安装。官方推荐用 conda 装因为它的依赖里有 OpenCASCADE 的二进制包pip 装经常出问题。conda create -n text2cad python3.11 conda activate text2cad conda install -c conda-forge cadquery如果你非要用 pip至少确保 Python 版本在 3.10 以上并且先装好OCP这个 OpenCASCADE 的 Python 绑定。LLM 接口。你需要一个能稳定调用的模型接口。本地跑的话7B 到 14B 参数的代码模型比如 DeepSeek-Coder、Qwen-Coder在 CadQuery 生成上表现尚可但复杂零件还是得用更大的模型。接口调用记得做重试和超时处理生成代码这种事一次失败很正常。验证环境。生成的代码不能直接信必须跑一遍。我建议用一个沙箱执行捕获异常和标准错误把报错信息回传给 LLM 让它自我修复。这个生成-执行-报错-修复的循环是整个流水线的核心。4.2 生成-验证-修复循环的工程实现这是整条流水线最有价值的部分。我把它拆成四步第一步文本解析。用户输入的自然语言先经过一轮结构化提取变成参数字典。这一步可以用 LLM也可以用正则加规则。比如外径 1006 个 8mm 的孔提取成{outer_d: 100, hole_count: 6, hole_d: 8}。第二步代码生成。把参数字典填进提示词模板让 LLM 生成 CadQuery 脚本。第三步沙箱执行。在隔离环境里跑脚本捕获三类问题语法错误、运行时异常、几何有效性错误。第四步反馈修复。把报错信息连同原代码一起回传 LLM要求它修复。这个循环最多跑 3 到 5 轮超过就判定失败转人工。import subprocess import tempfile import os def execute_cadquery(code: str, timeout: int 30): 在临时目录执行 CadQuery 代码返回结果和错误 with tempfile.TemporaryDirectory() as tmpdir: script_path os.path.join(tmpdir, model.py) with open(script_path, w) as f: f.write(code) try: result subprocess.run( [python, script_path], capture_outputTrue, textTrue, timeouttimeout, cwdtmpdir ) if result.returncode ! 0: return None, result.stderr # 检查是否生成了 STEP 文件 step_files [f for f in os.listdir(tmpdir) if f.endswith(.step)] if not step_files: return None, 代码执行成功但未生成 STEP 文件 return os.path.join(tmpdir, step_files[0]), None except subprocess.TimeoutExpired: return None, 执行超时可能存在死循环这个函数看着简单但有几个细节要注意超时必须设LLM 生成的代码偶尔会写出死循环工作目录要隔离避免不同任务互相污染要检查产物代码跑通不代表模型生成成功。4.3 批量生成的参数化策略单个零件生成跑通后真正的价值在批量。我做过一个项目需要生成 200 多个规格的支架尺寸按等差数列变化。手工建模不可能用 text-to-cad 流水线一晚上跑完。批量生成的关键是参数模板化。把零件的可变部分抽成参数固定部分写死在模板里。比如一个 L 型支架PARAM_TEMPLATE import cadquery as cq # 参数 length {length} width {width} height {height} thickness {thickness} hole_d {hole_d} result ( cq.Workplane(XY) .box(length, width, thickness) .faces(Z).workplane() .rect(length, width, forConstructionTrue) .vertices().hole(hole_d) .faces(Z).workplane() .rect(width, height, forConstructionTrue) .vertices().hole(hole_d) ) cq.exporters.export(result, bracket_{idx}.step) 然后循环替换参数批量执行。这里有个经验参数变化范围要合理。如果长度从 10 变到 1000中间某些尺寸可能导致几何自相交比如孔比零件还大脚本会报错。所以要么在参数层面做校验要么在生成后做几何有效性检查。5. 那些文档里不会写的翻车现场5.1 布尔运算失败最常见的几何报错布尔运算是 CAD 建模的核心操作也是 text-to-cad 最容易翻车的地方。两个实体做差集理论上很简单实际上 OpenCASCADE 经常给你甩一个BRep_API: command not done。原因通常有三类共面问题。两个实体的面完全重合时布尔运算的容差判断会出问题。解决办法是让它们稍微错开一点比如差集的时候切割体比被切体多伸出 0.01mm。微小特征。如果孔的公差和零件尺寸比例悬殊比如 1000mm 的板上打 0.1mm 的孔布尔运算可能失败。这时候要么放大特征要么调整内核容差。自相交。LLM 生成的代码有时候会造出自相交的实体这种实体做布尔运算必挂。导出前用Shape.isValid()检查一下无效的先修复。提示CadQuery 里可以用result.val().isValid()检查实体有效性。如果返回 False试试result.val().fix()能修好一部分拓扑问题。5.2 单位与坐标系跨软件协作的隐形杀手我前面提过单位问题这里再展开说因为它真的太重要了。CAD 世界里的单位混乱是历史遗留问题。SolidWorks 默认毫米Blender 默认米STL 格式本身不声明单位URDF 规定用米G-code 里又是毫米。text-to-cad 流水线横跨这么多环节单位不统一就是灾难。我的做法是全流程统一用毫米只在最后导出 URDF 的时候做一次缩放。具体来说CadQuery 建模毫米STEP 导出毫米文件头声明清楚STL 导出毫米URDF 引用 STLscale 设 0.001G-code 生成切片软件里确认单位是毫米坐标系的问题类似。CAD 里习惯把零件放在第一象限URDF 要求 link 原点在关节处。这两个约定冲突的时候要么在 CAD 里迁就 URDF要么在导出后做坐标变换。我倾向于前者因为改 CAD 比改 URDF 直观。5.3 LLM 生成的代码为什么总在同一个地方出错跑多了你会发现LLM 生成 CadQuery 代码的错误是有规律的。我统计过自己项目里的报错排前三的是API 记错。CadQuery 的 API 不算特别稳定不同版本有差异。LLM 训练数据里混着多个版本的用法经常生成过时的调用。比如Workplane.hole()在老版本里参数顺序和新版本不一样。链式调用断链。CadQuery 的链式调用要求每一步返回 Workplane 对象。LLM 有时候会插入一个返回其他类型的方法导致后面全挂。忘记选面。在 3D 实体上打孔必须先faces()选面再workplane()。LLM 经常直接workplane()结果在错误的平面上操作。针对这些我的提示词里会加一段常见错误提醒把这几条写进去一次通过率能提高不少。5.4 从 CAD 到 CoppeliaSimURDF 导入的完整排查链路热搜里urdf导入coppeliasim这个词出现频率很高说明这是很多人的痛点。我把完整排查链路写一下。第一步检查 URDF 语法。用check_urdf工具ROS 自带验证文件结构。语法错误的话CoppeliaSim 直接不认。第二步检查 mesh 路径。URDF 里的 mesh 文件名是相对路径相对于 URDF 文件所在目录。路径错了模型加载不出来但 CoppeliaSim 不一定报错只是显示空白。第三步检查 scale。前面说过STL 是毫米URDF 是米scale 必须是 0.001。忘了设的话机器人会大 1000 倍在场景里根本看不见。第四步检查惯性参数。如果 inertial 里的质量或惯量是 0 或者负数物理引擎会报错或者行为异常。质量可以从 CAD 里算惯量可以用近似公式估。第五步检查关节轴。URDF 的 joint axis 定义在 joint 坐标系下如果和实际关节轴线对不上机器人运动起来就是歪的。这五步走完90% 的 URDF 导入问题都能定位。剩下的 10% 通常是 CAD 模型本身的拓扑问题得回源头修。6. 这套方案的能力边界与我的实际体会text-to-cad 现在能做什么、不能做什么我心里有一条比较清晰的线。能稳定做的规则几何体、参数化系列件、标准结构法兰、支架、齿轮毛坯、简单装配体。这些场景下文本描述和几何之间的映射关系明确LLM 生成脚本的成功率高流水线跑起来顺畅。勉强能做的中等复杂度的零件带曲面、带复杂特征。需要多轮修复人工介入比例上升但比纯手工还是快。目前做不了的自由曲面造型、复杂装配体的运动学关系、需要工程判断的设计决策比如这个壁厚够不够。这些要么依赖几何算法的进步要么依赖更强的领域推理能力。我个人的体会是text-to-cad 的价值不在于替代工程师而在于把工程师从重复劳动里解放出来。一个熟练工程师用这套工具效率提升是实实在在的尤其是批量任务。但如果你指望它全自动出图那还早。最后分享一个我常用的技巧把常用的零件结构做成代码片段库。法兰、支架、齿轮、外壳每种结构写一个参数化的 CadQuery 函数LLM 生成的时候直接调用这些函数而不是从零写。这样既提高了生成质量又保证了代码风格统一。这个库积累得越厚你的 text-to-cad 流水线就越好用。