1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 “text-to-cad” 这个词很多人会下意识觉得它离自己很远像是实验室里的概念演示。但如果你真正在机械设计、机器人建模或者增材制造这条线上摸爬滚打过就会明白它戳中的是一个极其现实的痛点从“脑子里有个形状”到“手里有个能用的模型文件”中间隔着一条又长又陡的学习曲线。传统流程是什么样你得先打开 CAD 软件熟悉草图约束、拉伸旋转、布尔运算这一整套操作逻辑然后一个特征一个特征地把脑子里的东西“翻译”成软件能理解的几何语言。一个简单的法兰盘熟手可能十分钟搞定但如果你只是想让程序自动生成一百个不同参数的支架或者想让一个大语言模型直接输出一个可用的机械零件手动建模就完全不现实了。text-to-cad 要做的就是把“自然语言描述”和“CAD 几何文件”之间的那道墙拆掉。你输入一句“一个外径 80mm、内径 40mm、厚度 10mm 的圆环中心开四个直径 6mm 的安装孔”它输出一个标准的 STEP 文件或者 URDF 模型可以直接丢进仿真环境或者切片软件里用。这件事的价值不在于“炫技”而在于它把建模的门槛从“会操作软件”降到了“能说清楚需求”。我最初接触这个方向是因为手头有一批机器人连杆需要做参数化变体。每个连杆的孔位、长度、厚度都随工况微调手动改模型改到怀疑人生。后来尝试用脚本驱动 CAD再后来干脆研究起怎么让文本直接映射到几何体。踩了不少坑也攒了一些真正能跑通的方案。这篇文章就把我对 text-to-cad 的理解、实操路径和避坑经验完整拆开讲一遍适合三类人看想入门参数化建模的工程师、做机器人仿真需要批量生成 URDF 的开发者以及单纯好奇“一句话生成 CAD 模型”到底靠不靠谱的技术爱好者。2. 核心思路拆解文本怎么变成几何体2.1 三种主流技术路线对比text-to-cad 不是一个单一技术而是一类方案的统称。根据我实际折腾过的经验目前能跑通的路子大致分三条每条路的适用场景和坑点完全不同。第一条路是代码驱动型代表工具是 OpenSCAD 和 CadQuery。核心逻辑是你用自然语言描述需求大语言模型或者规则引擎把它翻译成一段建模脚本脚本执行后导出 STEP 或 STL。这条路的最大优势是确定性极强——同样的脚本永远生成同样的几何体参数改一个数字模型精确变化不会出现“差不多但不对”的情况。缺点是复杂曲面表达能力有限做规则几何体很爽做有机形态就吃力。第二条路是直接生成型比如一些基于深度学习的模型直接输出网格或点云。这条路听起来最“AI”但实际用下来问题最多生成的几何体经常有自交、非流形边、法线翻转等毛病导进仿真环境直接报错。而且不可控你没法说“把孔位往左移 2mm”只能重新生成碰运气。我个人的判断是这条路目前适合做概念草图不适合做工程交付。第三条路是混合型用 LLM 做“意图理解层”把自然语言拆解成结构化参数再交给参数化建模引擎执行。比如你说“一个带加强筋的 L 型支架”LLM 先解析出“L 型”“加强筋”“支架”这几个语义单元映射到预定义的参数化模板上填入尺寸参数后生成模型。这条路兼顾了灵活性和可控性是目前工业场景下最务实的选择。路线代表工具优势劣势适用场景代码驱动型OpenSCAD、CadQuery确定性高、参数精确、可版本控制曲面能力弱、需要学脚本语法规则零件、参数化变体、批量生成直接生成型各类深度学习模型形态自由度高几何质量差、不可控、难编辑概念探索、艺术造型混合型LLM 参数化模板兼顾灵活与可控模板覆盖范围有限工业零件、机器人模型2.2 为什么 STEP 和 URDF 是两条不同的终点线很多人把 text-to-cad 的输出笼统称为“CAD 文件”但实际用起来STEP 和 URDF 的差别大到像两种语言。STEP 是几何交换格式它描述的是一个静态的实体形状。你生成一个 STEP 文件它就是一个零件有体积、有表面、有精确的边界表示。加工、3D 打印、装配检查用的都是这类格式。text-to-cad 生成 STEP 的难点在于自然语言里的“圆角”“倒角”“拔模”这些工艺特征需要精确映射到 B-rep 几何操作上差一个参数就是废件。URDF 是机器人描述格式它描述的是一个运动学树。里面不仅有几何形状还有关节类型、旋转轴、父子连杆关系、惯性矩阵、碰撞体简化模型。text-to-cad 生成 URDF 的难点不在几何本身而在于语义理解你说“一个两自由度的机械臂”系统得知道第一个关节是旋转还是平移旋转轴是 Z 轴还是 Y 轴连杆长度和关节原点怎么对应。这些信息自然语言里往往没说全需要系统根据常识补全或者反过来向用户追问。我踩过的一个典型坑早期用脚本生成 URDF 时只关注了几何体的形状忽略了惯性矩阵的自动计算。结果模型导进 CoppeliaSim 后机械臂一动就抖得像筛糠因为默认惯性张量给了一个不合理的值。后来才明白URDF 里的inertial标签不是可选项质量、质心、惯性矩阵必须和几何体匹配否则动力学仿真完全不可信。2.3 参数化模板text-to-cad 真正的“发动机”不管走哪条路text-to-cad 能不能落地关键看有没有一套靠谱的参数化模板库。自然语言是模糊的几何是精确的模板就是中间的翻译器。举个例子用户说“一个 M8 的螺栓”。这句话里隐含了大量默认参数螺纹规格 M8、螺距 1.25mm、头部类型默认六角、头部高度约 5.3mm、螺杆长度没说但通常默认 30mm 左右。如果系统没有预置“螺栓”这个模板LLM 就得从零开始推理所有尺寸出错概率极高。但如果有模板系统只需要提取“M8”这个关键参数其余全部走默认值生成结果就稳定得多。我在实际项目中维护了一套约 40 个基础模板覆盖法兰、支架、连杆、齿轮、轴承座、螺栓、螺母这些常用件。每个模板定义了三样东西必填参数不填就报错、可选参数有默认值、几何生成函数用 CadQuery 或 OpenSCAD 写。这套模板库建好之后text-to-cad 的可用性直接上了一个台阶因为大部分常见需求都能落到某个模板上LLM 只需要做参数抽取不需要做几何推理。实操心得模板库不要一开始就追求大而全。先把你手头最常做的 5 到 10 种零件做成模板跑通“文本→参数→模型”的完整链路再逐步扩展。我见过太多项目死在“想一口气支持所有零件类型”上最后每个模板都半成品。3. 核心细节解析与实操要点3.1 自然语言到参数的映射规则设计text-to-cad 最核心的一步是把“人话”翻译成“参数表”。这一步做不好后面几何生成再精确也没用。我总结了几条映射规则实测下来能覆盖大部分场景。第一条规则尺寸单位显式化。自然语言里说“直径 80”到底是 80mm 还是 80cm工程场景下默认毫米但必须在解析层强制补全单位。我的做法是如果用户没写单位一律按毫米处理同时在返回结果里标注“已默认单位为 mm”让用户有机会纠正。第二条规则特征词到几何操作的映射。“开孔”对应布尔减运算“凸台”对应布尔加运算“倒角”对应边缘过渡“阵列”对应线性或环形复制。这些映射关系需要预先定义好不能让 LLM 自由发挥。比如“四个孔均匀分布”这句话系统要能解析出“孔数量4分布方式环形阵列阵列角度360/490 度”。第三条规则模糊描述走默认值。用户说“一个厚一点的板”这个“厚一点”没法精确解析。我的处理方式是查模板默认值如果模板里“板”的默认厚度是 5mm那就用 5mm同时在输出里提示“厚度未指定已使用默认值 5mm”。这样既保证了生成成功又给了用户修正的入口。下面是一个实际的参数解析示例用 Python 字典表示解析结果{ template: flange, params: { outer_diameter: 80.0, inner_diameter: 40.0, thickness: 10.0, hole_count: 4, hole_diameter: 6.0, hole_pcd: 60.0, unit: mm }, defaults_used: [hole_pcd], warnings: [孔分布圆直径未指定已按外径减 10mm 默认计算] }这个结构里defaults_used和warnings字段特别重要。它们让整个生成过程可追溯用户知道哪些参数是猜的哪些是明确的。没有这两个字段text-to-cad 就是个黑盒出了问题没法排查。3.2 几何生成引擎的选型与配置参数解析完了接下来是几何生成。我主要用两个引擎CadQuery和OpenSCAD。两者各有优劣选哪个取决于你的具体需求。CadQuery 基于 OpenCASCADE 内核生成的几何体是精确的 B-rep 表示可以直接导出 STEP。它的 Python API 写起来很顺手比如生成一个法兰盘import cadquery as cq result ( cq.Workplane(XY) .circle(40) # 外径 80mm半径 40mm .circle(20) # 内径 40mm半径 20mm .extrude(10) # 厚度 10mm .faces(Z) # 选择顶面 .workplane() .polarArray(30, 0, 360, 4) # 分布圆半径 30mm4 个孔 .hole(6) # 孔径 6mm ) cq.exporters.export(result, flange.step)这段代码跑完直接得到一个标准 STEP 文件。CadQuery 的优势是精度高、导出格式规范适合做工程交付。缺点是安装配置稍微麻烦依赖 OpenCASCADE 的库Windows 上偶尔会有 DLL 加载问题。OpenSCAD 走的是另一条路它用脚本描述几何体的构造过程渲染时生成网格。语法更简单但输出的是 STL 网格不是精确 B-rep。做 3D 打印够用做精密装配就差点意思。不过 OpenSCAD 有一个巨大优势纯文本脚本版本控制极其方便。每次生成的脚本可以存进 Git随时回溯和 diff。我的建议是需要 STEP 输出就用 CadQuery需要快速原型和版本管理就用 OpenSCAD。两者可以共存根据输出格式需求切换。3.3 URDF 生成的特殊处理关节与惯性生成 URDF 比生成 STEP 多了一层复杂度运动学结构。一个 URDF 文件里link定义连杆的几何和惯性joint定义关节的类型和变换关系。text-to-cad 要生成 URDF必须从自然语言里提取出这两类信息。我处理过一个典型需求“一个两连杆机械臂第一段长 200mm第二段长 150mm两个关节都是旋转关节”。这句话里几何信息200mm、150mm是明确的但关节信息是模糊的旋转轴是哪个方向关节原点在连杆的什么位置这些没说。我的处理策略是用默认约定补全并显式输出假设。默认约定包括旋转轴沿 Z 轴、关节原点在连杆起点、连杆质心在几何中心、惯性矩阵按长方体近似计算。这些假设会写在 URDF 的注释里用户导入 CoppeliaSim 后如果发现不对可以手动调整。惯性矩阵的计算是个容易忽略的坑。对于一个长 200mm、宽 50mm、高 30mm、质量 1kg 的连杆惯性张量按长方体公式计算Ixx m/12 × (h² d²) 1/12 × (0.03² 0.05²) ≈ 1.42e-4 kg·m²Iyy m/12 × (w² h²) 1/12 × (0.05² 0.03²) ≈ 1.42e-4 kg·m²Izz m/12 × (w² d²) 1/12 × (0.05² 0.2²) ≈ 3.54e-4 kg·m²这些数值必须填进 URDF 的inertial标签否则仿真时动力学行为完全不对。我早期偷懒用单位矩阵代替结果机械臂在 CoppeliaSim 里动起来像在太空里飘完全没有重力感。注意URDF 里的单位是米、千克、秒不是毫米。从自然语言解析出来的尺寸如果是毫米必须除以 1000 再填入 URDF。这个单位转换我至少犯过三次错每次都是模型导入后尺寸差了一千倍。4. 实操过程与核心环节实现4.1 环境搭建从零到跑通第一条链路先把环境搭起来。我以 CadQuery 路线为例走一遍完整流程。操作系统用 Ubuntu 22.04 或者 Windows 11 都行Python 版本建议 3.10 以上。第一步创建虚拟环境并安装依赖python -m venv text2cad-env source text2cad-env/bin/activate # Windows 用 text2cad-env\Scripts\activate pip install cadquery2.4.0 pip install openai # 如果用 LLM 做参数解析 pip install trimesh # 用于网格处理和格式转换CadQuery 的安装在不同平台上差异较大。Ubuntu 上通常很顺Windows 上如果遇到OCP相关的编译错误建议直接装预编译的 wheel 包不要从源码编译。我试过在 Windows 上源码编译 OpenCASCADE折腾了三个小时最后放弃直接用 pip 的二进制包五分钟搞定。第二步验证 CadQuery 能正常工作import cadquery as cq box cq.Workplane(XY).box(10, 10, 10) cq.exporters.export(box, test_box.step) print(导出成功)跑通这一步说明几何引擎没问题。如果报错大概率是 OpenCASCADE 的库路径没配好检查一下CASROOT环境变量。第三步接入参数解析层。我用 OpenAI 的 API 做自然语言到 JSON 的转换prompt 设计是关键。下面是我实际用的 system prompt 模板你是一个 CAD 参数解析器。用户会用自然语言描述一个机械零件。 你需要输出一个 JSON 对象包含 template 字段和 params 字段。 可用的 template 有flange, bracket, link, gear, bearing_seat。 如果用户描述无法匹配任何模板template 设为 unknown。 所有尺寸默认单位为毫米。如果用户未指定某个参数使用模板默认值 并在 defaults_used 数组中记录该参数名。这个 prompt 的关键点是限定模板范围。如果不限定LLM 会自由发挥生成一堆不存在的模板名。限定之后解析成功率从不到 50% 提升到 85% 以上。4.2 完整链路演示从一句话到 STEP 文件现在把整条链路串起来。用户输入“生成一个外径 100mm、内径 50mm、厚度 12mm 的法兰均匀分布 6 个直径 8mm 的孔孔分布圆直径 75mm。”第一步参数解析。LLM 返回{ template: flange, params: { outer_diameter: 100.0, inner_diameter: 50.0, thickness: 12.0, hole_count: 6, hole_diameter: 8.0, hole_pcd: 75.0 }, defaults_used: [], warnings: [] }所有参数都明确给出了没有使用默认值。这是最理想的情况。第二步模板匹配与几何生成。系统查到flange模板对应的生成函数传入参数执行def generate_flange(params): outer_r params[outer_diameter] / 2 inner_r params[inner_diameter] / 2 thickness params[thickness] hole_count params[hole_count] hole_d params[hole_diameter] pcd_r params[hole_pcd] / 2 result ( cq.Workplane(XY) .circle(outer_r) .circle(inner_r) .extrude(thickness) .faces(Z) .workplane() .polarArray(pcd_r, 0, 360, hole_count) .hole(hole_d) ) return result第三步导出与验证。生成结果导出为 STEP同时用trimesh做一次几何有效性检查result generate_flange(params) cq.exporters.export(result, flange_output.step) # 验证 import trimesh mesh trimesh.load(flange_output.step) print(f体积: {mesh.volume:.2f} mm³) print(f是否水密: {mesh.is_watertight})is_watertight返回True说明几何体是封闭的没有破面。这个检查很重要因为有些布尔运算会产生微小破面肉眼看不出来但导入仿真环境就会报错。整个链路跑下来从输入文本到拿到 STEP 文件耗时大约 3 到 5 秒其中 LLM 解析占 2 到 3 秒几何生成和导出占 1 到 2 秒。批量生成 100 个变体的话可以把 LLM 解析结果缓存下来只跑几何生成速度能压到每个 0.5 秒以内。4.3 批量生成与参数扫描的实操技巧text-to-cad 真正体现价值的地方是批量生成。手动建模做一个零件脚本化之后可以做一千个。我做过一个项目需要生成 200 个不同长度的机器人连杆用于强化学习训练。核心思路是把参数写成 CSV循环读取批量生成。CSV 长这样link_id,length,width,height,mass L001,200,50,30,1.0 L002,180,50,30,0.9 L003,220,50,30,1.1 ...然后写一个批处理脚本import csv import cadquery as cq def generate_link(length, width, height): return ( cq.Workplane(XY) .box(length, width, height) .faces(X) .workplane() .hole(8) # 两端各开一个安装孔 .faces(X) .workplane() .hole(8) ) with open(links.csv) as f: reader csv.DictReader(f) for row in reader: link generate_link( float(row[length]), float(row[width]), float(row[height]) ) cq.exporters.export(link, foutput/{row[link_id]}.step) print(f已生成 {row[link_id]})这个脚本跑 200 个连杆大概两分钟。如果手动建模一个连杆至少五分钟200 个就是十几个小时。效率差距是数量级的。实操心得批量生成时一定要加异常捕获和日志。我遇到过某个参数组合导致布尔运算失败的情况如果没有 try-except整个批处理会中断前面的成果全白费。加上异常处理后失败的记录单独输出到日志成功的继续跑最后统一排查失败原因。5. 常见问题与排查技巧实录5.1 几何生成失败的典型原因与修复text-to-cad 最让人抓狂的就是“参数都对但生成失败”。我整理了实际遇到过的几类问题做成速查表问题现象可能原因排查方法修复方案布尔运算后几何体消失减运算的工具体完全包含在目标体内检查孔径是否大于外径调整参数确保工具体与目标体有交集但不完全包含导出 STEP 报错几何体存在非流形边用is_watertight检查简化几何避免零厚度特征圆角操作失败圆角半径大于相邻边长度检查圆角半径与壁厚关系圆角半径不超过最小壁厚的 1/3阵列后孔位错乱阵列角度和数量不匹配检查polarArray参数确保角度范围是 360 度数量为整数URDF 导入后模型散架关节父子关系错误检查parent和child标签确保每个 link 只被一个 joint 作为 child 引用其中“圆角半径大于相邻边长度”这个问题我遇到最多。用户说“边缘倒个圆角”LLM 解析出fillet_radius5mm但零件壁厚只有 8mm倒角直接穿透了。修复方案是在模板里加一个约束检查fillet_radius min_wall_thickness / 3不满足就自动降低半径并给出警告。5.2 URDF 导入 CoppeliaSim 的常见坑URDF 生成出来只是第一步导入 CoppeliaSim 能不能用是另一回事。我踩过的坑包括坑一单位不匹配。URDF 用米CAD 用毫米。如果生成 URDF 时忘了除以 1000导入后模型要么大得像座山要么小得看不见。排查方法很简单在 CoppeliaSim 里量一下模型尺寸和预期对比。坑二惯性矩阵缺失或错误。前面提过inertial标签不能省。如果实在懒得算至少给一个合理的近似值不要用单位矩阵。CoppeliaSim 对惯性矩阵很敏感给错了模型动起来完全不对。坑三碰撞体过于复杂。URDF 里的collision标签如果直接复用视觉几何体对于复杂零件会导致碰撞检测极慢。我的做法是视觉用精细模型碰撞用简化包围盒或圆柱体。比如一个复杂支架视觉模型有几百个面碰撞体就用一个长方体代替。坑四关节限位没设。旋转关节如果不设limit在 CoppeliaSim 里会无限旋转。对于机械臂来说这会导致仿真结果完全不可用。生成 URDF 时默认给旋转关节设 ±180 度限位平移关节设 0 到 1 米限位。5.3 性能优化让批量生成快起来当生成数量上到几百上千时性能就成了问题。我做过一些优化效果比较明显优化一缓存 LLM 解析结果。如果同一批任务的自然语言描述结构相似只是参数不同可以把解析结果缓存下来避免重复调用 LLM。我用 Redis 做缓存key 是描述文本的哈希value 是解析后的 JSON。命中率大概 70%整体耗时降低一半以上。优化二并行生成。CadQuery 的几何生成是 CPU 密集型的可以用多进程并行。Python 的multiprocessing模块就能搞定from multiprocessing import Pool def generate_one(params): result generate_flange(params) cq.exporters.export(result, foutput/{params[id]}.step) return params[id] with Pool(8) as p: results p.map(generate_one, all_params)8 核并行200 个零件的生成时间从两分钟压到 20 秒左右。优化三降低导出精度。STEP 导出时可以设置精度参数精度越低文件越小、速度越快。对于仿真用的模型精度不需要太高设置tolerance0.01mm就够了。对于加工用的模型才需要tolerance0.001mm。注意并行生成时每个进程要独立初始化 CadQuery 环境。我遇到过在子进程里直接调用 CadQuery 报错的情况原因是 OpenCASCADE 的全局状态没有正确初始化。解决方案是在每个子进程的入口函数里重新 import 一次 CadQuery。6. 工具链选型与扩展方向6.1 我实际用过的工具组合经过几轮迭代我目前稳定使用的工具链是这样的参数解析OpenAI APIGPT-4 级别模型配合自定义 prompt 和 JSON schema 约束几何生成CadQuery 为主OpenSCAD 为辅需要快速原型时用格式转换CadQuery 自带 STEP 导出STL 用 trimesh 处理URDF 生成自己写的 Python 脚本基于模板填充批量调度Python multiprocessing Redis 缓存验证trimesh 做几何有效性检查CoppeliaSim 做运动学验证这套组合不是唯一解但实测下来稳定性和效率都还不错。如果你不想依赖外部 API可以用本地的开源模型做参数解析比如 Llama 系列但解析准确率会下降一些需要更多的后处理规则来兜底。6.2 从 text-to-cad 到 text-to-gcode 的延伸text-to-cad 生成 STEP 或 URDF 之后下一步往往是加工或打印。这就涉及到 G-code 生成。G-code 是数控机床和 3D 打印机的指令语言描述的是刀具路径不是几何形状。从 CAD 到 G-code中间需要经过切片或 CAM 处理。3D 打印用切片软件如 Cura、PrusaSlicer数控加工用 CAM 软件如 FreeCAD 的 Path 工作台。text-to-cad 本身不直接生成 G-code但它生成的模型可以无缝接入这些流程。我做过一个实验用 text-to-cad 生成一个支架的 STEP 文件导入 PrusaSlicer 切片导出 G-code直接打印。整个流程从文本到可打印文件大概十分钟。如果手动建模光画图就得半小时。这个效率提升在快速迭代场景下非常明显。6.3 当前方案的局限与改进方向说实话text-to-cad 目前还远没到“万能”的程度。我总结几个主要局限局限一复杂曲面表达困难。自然语言描述自由曲面几乎不可能比如“一个流线型的汽车后视镜外壳”这种需求目前只能靠手动建模或专业曲面软件。局限二装配体生成不成熟。单个零件生成已经比较靠谱但“一个由 20 个零件组成的减速箱”这种需求目前还处理不了。零件之间的配合关系、装配约束自然语言很难说清楚。局限三工艺特征理解有限。“拔模角”“圆角过渡”“退刀槽”这些工艺特征LLM 能识别出关键词但映射到精确几何操作时经常出错。需要更专业的领域微调。改进方向我觉得有两个一是模板库的持续积累把更多常见零件类型做成参数化模板二是多轮交互系统发现参数不全时主动追问而不是强行用默认值生成。后者对用户体验提升很大但实现复杂度也高不少。7. 一些实操中的个人体会这个方向我折腾了大概一年半从最初的“一句话生成一个方块”到现在的“批量生成参数化零件并导入仿真”中间踩的坑比走的路还多。最大的体会是text-to-cad 的核心难点不在 AI而在几何。LLM 负责理解意图但最终能不能生成可用的模型取决于参数化模板的设计质量和几何引擎的稳定性。另一个体会是不要追求全自动。完全让 AI 从零生成复杂零件目前还不现实。更务实的做法是“AI 做参数填充人做模板设计”。模板由工程师根据经验预先定义好AI 只负责从自然语言里抽取参数。这样既降低了 AI 的负担又保证了生成结果的可靠性。最后分享一个小技巧如果你刚开始做 text-to-cad先从一个零件类型入手把整条链路跑通再逐步扩展。我见过太多项目一上来就想支持几十种零件结果每个都做不精。先把法兰做透再做支架再做连杆一步步来反而更快。