1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 “text-to-cad” 这个词很多人脑子里蹦出来的画面可能是对着电脑说一句“给我画个法兰盘”屏幕上就自动生成一张能直接加工的图纸。这个想象不算离谱但也不完全准确。更贴近现实的理解是——用自然语言或结构化文本描述驱动一套自动化流程最终产出 CAD 可识别的几何文件比如 STEP、URDF、G-code 这些格式。它解决的核心痛点很朴素传统 CAD 建模是“手工艺”每一个倒角、每一段拉伸都要人点鼠标而 text-to-cad 想把它变成“流水线”让描述本身成为建模的输入。我最早接触这个方向是因为手里有一批参数化零件需要反复改尺寸。每次客户改一个孔径我就得打开 SolidWorks 重新编辑草图、重建特征、再导出 STEP。几十个零件改下来一天就没了。后来我试着用脚本把“孔径、板厚、长宽”这些参数抽出来用文本描述驱动建模效率直接翻了几倍。这就是 text-to-cad 的雏形——不是取代 CAD而是把 CAD 里重复性最高的那部分工作自动化。它适合谁三类人最应该关注一是机械设计工程师手里有大量系列化零件二是机器人方向的开发者需要频繁生成 URDF 模型做仿真三是做增材制造或 CNC 加工的从业者想把设计到 G-code 的链路缩短。哪怕你只是刚学 CAD 制图入门理解这套逻辑也能帮你少走很多弯路因为你会知道哪些操作是可以被“描述”替代的。提示text-to-cad 不是“语音控制 CAD 软件”它的本质是文本到几何的编译过程中间往往要经过参数化脚本或中间格式转换。2. 核心思路拆解为什么是 STEP、URDF 和 G-code2.1 三种输出格式分别对应什么场景text-to-cad 的输出格式选择直接决定了它能用在哪个环节。我把常见的三种格式和它们的适用场景整理成表方便你对照自己的需求。输出格式核心用途典型工具链是否保留特征树STEP通用三维模型交换FreeCAD、CadQuery、SolidWorks部分保留URDF机器人仿真与运动学ROS、CoppeliaSim、PyBullet不保留只保留关节与连杆G-code数控加工与3D打印PrusaSlicer、Cura、CNC 控制器不保留只保留路径STEP 是 text-to-cad 最常用的中间格式。它像三维模型界的 PDF——几乎所有 CAD 软件都能打开而且能保留 B-rep 几何信息。你用文本生成一个 STEP 文件后可以导入中望 CAD、SolidWorks 或者 FreeCAD 继续编辑。URDF 则完全不同它是给机器人用的描述的是连杆、关节、坐标系之间的关系。如果你要把模型导入 CoppeliaSim 做仿真URDF 就是必经之路。G-code 更底层直接控制机床或打印机文本描述在这里变成了刀路或挤出路径。2.2 为什么不用直接生成 CAD 原生格式有人会问为什么不直接生成 .sldprt 或 .dwg原因有两个。第一原生格式是闭源的你很难用脚本稳定写入。第二原生格式绑定了特定软件换一个环境就打不开。STEP 是 ISO 标准URDF 是 XML 文本G-code 是纯文本这三者都可以用代码生成、用代码解析天然适合自动化流程。我试过用 Python 直接写 .dwg折腾了一周就放弃了后来换成先生成 STEP 再转换半天就跑通了。注意STEP 有 AP203、AP214、AP242 等多个版本做 text-to-cad 时建议统一用 AP214 或 AP242兼容性最好。2.3 文本描述的结构化程度决定成败“一个长 100 宽 50 厚 10 的板四个角各有一个直径 8 的孔”——这句话人看得懂但机器不一定。text-to-cad 的关键在于把自然语言转成结构化参数。我的做法是定义一套简单的 JSON schema比如{ type: plate, length: 100, width: 50, thickness: 10, holes: [ {x: 10, y: 10, diameter: 8}, {x: 90, y: 10, diameter: 8}, {x: 10, y: 40, diameter: 8}, {x: 90, y: 40, diameter: 8} ] }有了这个结构后面无论是生成 STEP 还是 URDF都只是写一个转换器的事。自然语言解析可以交给大模型做但最终一定要落到结构化参数上否则后续步骤没法稳定复现。3. 实操环境搭建从零把链路跑通3.1 工具选型与安装避坑我推荐的主力工具是CadQuery它是一个基于 Python 的参数化建模库底层用 OpenCASCADE能直接导出 STEP。安装很简单pip install cadquery但这里有个坑CadQuery 依赖的 OCP 库在部分 Windows 环境下会报 C 运行时错误类似你装 CAD 时遇到的 “c2005 cpi 错误”。解决办法是提前安装 Visual C Redistributable 合集或者直接用 Conda 安装conda install -c conda-forge cadqueryConda 会把依赖一并处理好省心很多。如果你只是想做 URDF可以装urdfpy或yourdfpy做 G-code 可视化可以用gcode-parser。另外FreeCAD 自带 Python 控制台也可以作为备选方案它的 Part 模块能直接生成 STEP。3.2 一个最小可运行示例先别急着搞复杂零件从一个带孔的板开始。下面这段代码生成一个 100x50x10 的板四角各一个直径 8 的孔导出 STEPimport cadquery as cq result ( cq.Workplane(XY) .box(100, 50, 10) .faces(Z) .workplane() .rect(80, 30, forConstructionTrue) .vertices() .hole(8) ) cq.exporters.export(result, plate.step)跑完之后你会得到一个 plate.step 文件用 FreeCAD 或中望 CAD 都能打开。这就是 text-to-cad 的最小闭环文本参数 - CadQuery 脚本 - STEP 文件。你可以把参数抽成变量从 JSON 读入就实现了“文本驱动”。3.3 环境验证与常见报错处理第一次跑通之前大概率会遇到几个问题。我整理了一个速查表报错信息原因解决办法ModuleNotFoundError: No module named cadquery没装或装错环境确认 pip 和 python 版本对应OCP 初始化失败C 运行时缺失安装 VC Redistributable导出 STEP 为空几何体没有闭合检查 box 和 hole 的顺序中文路径报错OpenCASCADE 不支持改用全英文路径实操心得CadQuery 的链式调用顺序很关键先做布尔运算再做倒角否则容易失败。我踩过好几次坑后来养成习惯——每加一个特征就导出一次看结果。4. 从文本到 URDF机器人模型生成的关键细节4.1 URDF 的结构与 text-to-cad 的映射关系URDF 本质是一个 XML 文件描述机器人由哪些 link 和 joint 组成。text-to-cad 在这里的任务是把“一个两轮差速小车轮距 200轮径 80”这样的描述转成 URDF 里的 link 几何和 joint 位置。核心映射关系是文本里的“底盘” - URDF 的 base_link文本里的“左轮” - URDF 的 left_wheel_link文本里的“轮距” - joint 的 origin xyz文本里的“轮径” - cylinder 的 radius我通常先用 CadQuery 生成各个零件的 STEP再用脚本转成 URDF 的 mesh 引用。这样几何精度有保证URDF 只负责运动学关系。4.2 导入 CoppeliaSim 的实操步骤URDF 生成后导入 CoppeliaSim 是常见需求。步骤不复杂但细节容易出错确保 URDF 里所有 mesh 路径是相对路径且文件确实存在。CoppeliaSim 的 URDF 导入插件对 inertial 标签很敏感质量不能为 0。关节类型要写对continuous 和 revolute 的区别会影响仿真行为。导入后检查 base_link 是否悬空必要时手动调整位置。我遇到过最头疼的问题是 mesh 单位不一致。CAD 里是毫米URDF 默认是米导入后模型要么巨大要么极小。解决办法是在 URDF 的 mesh 标签里加 scale 参数或者在生成 STEP 时就按米为单位建模。4.3 参数计算轮距与转弯半径的关系text-to-cad 不只是生成几何有时还要算参数。比如差速小车的转弯半径 R 和轮距 L、左右轮速度 v_l、v_r 的关系是R L/2 * (v_l v_r) / (v_r - v_l)这个公式在生成 URDF 时可以用来校验 joint 位置是否合理。如果文本描述里给了转弯半径和轮距就能反推速度比进而设置仿真参数。这种计算在纯手工建模时很容易被忽略但自动化流程里必须显式处理。提示URDF 里的 inertial 矩阵如果随便填仿真时会出现抖动或穿透。建议用 CadQuery 计算体积后乘以密度得到真实质量。5. 常见问题与排查技巧实录5.1 几何生成失败的典型原因text-to-cad 最常挂的地方不是代码而是几何本身。比如你描述“一个内孔和外圆同心的圆环”如果内孔直径大于外圆CadQuery 会直接报错。再比如倒角半径大于板厚也会失败。我的经验是在生成前加一层参数校验检查直径、厚度、倒角半径之间的约束关系。下面是一个简单的校验函数def validate_plate(length, width, thickness, hole_diameter, hole_margin): if hole_diameter min(length, width): raise ValueError(孔径不能大于板的最小边) if hole_margin hole_diameter / 2: raise ValueError(孔边距不足会导致破边) if thickness 0: raise ValueError(厚度必须为正)这层校验能挡掉八成低级错误省去反复调试的时间。5.2 格式转换中的精度丢失STEP 转 URDF 时如果中间经过 STL精度会丢失。STL 是三角网格圆弧会变成多边形。解决办法是尽量直接从 B-rep 转 URDF 的 mesh或者提高 STL 的细分精度。我在做机器人仿真时轮子用 STL 后明显不圆后来改成用 URDF 的 cylinder 原生几何问题就消失了。5.3 批量生成时的性能优化如果你要生成几百个零件逐个跑 CadQuery 会很慢。我的做法是用多进程池from multiprocessing import Pool def generate_one(params): # 生成并导出 pass with Pool(8) as p: p.map(generate_one, param_list)另外CadQuery 的 Workplane 对象不要跨进程传递每个进程独立创建。实测下来8 核并行能把批量生成时间从 20 分钟压到 3 分钟。5.4 与现有 CAD 工作流的衔接生成的 STEP 导入中望 CAD 或 SolidWorks 后有时会出现特征树丢失的情况。这是正常的因为 STEP 只保留几何不保留建模历史。如果你需要后续编辑建议同时保留生成脚本改参数重新生成而不是在 CAD 里手动改。这也是 text-to-cad 的核心价值——让修改回到文本层而不是几何层。6. 进阶方向从单零件到装配体与 G-code6.1 装配体的文本描述策略单零件跑通后下一步是装配体。文本描述装配体时关键是定义配合关系。比如“轴插入孔端面贴合”对应到代码里就是两个零件的坐标系对齐。CadQuery 可以用Assembly类做这件事assy ( cq.Assembly() .add(plate, nameplate) .add(shaft, nameshaft, loccq.Location(cq.Vector(0, 0, 10))) ) assy.save(assembly.step)装配体的难点在于约束求解目前 text-to-cad 在这方面还不如手动装配灵活。我的建议是能参数化的零件用脚本生成复杂配合关系还是手动处理不要强行全自动。6.2 生成 G-code 的基本链路从文本到 G-code中间要经过切片或刀路规划。3D 打印场景下可以用 CadQuery 生成 STL再调 PrusaSlicer 的命令行接口prusa-slicer --export-gcode --output part.gcode part.stlCNC 场景更复杂需要根据材料、刀具、进给速度生成刀路。这部分我还在摸索目前的做法是用 FreeCAD 的 Path 模块先手动配置一次刀路模板再用脚本替换参数。text-to-cad 在这里的价值是批量生成不同尺寸零件的 G-code而不是完全替代 CAM 工程师。6.3 与 Python 批量修改 CAD 的结合热词里有个“python 批量对 cad 修改”这其实是 text-to-cad 的近亲。如果你手里有一批 DWG 图纸需要改图层、改文字、改块属性可以用ezdxf库批量处理。我做过一个项目把 200 张电气 CAD 图纸的标题栏统一替换用 ezdxf 半小时搞定手动改至少要两天。思路是一样的把图纸当数据用代码操作而不是用鼠标操作。实操心得ezdxf 对中文支持需要设置编码建议统一用 UTF-8并在读取时指定 encoding 参数。7. 我在这条路上踩过的坑与最终建议text-to-cad 听起来很美好但实际落地时最大的障碍不是技术而是描述本身的模糊性。人说“一个差不多大的板”机器没法理解“差不多”。所以我的第一条建议是先定义好参数 schema再写生成逻辑。schema 是人和机器之间的合同合同越清晰返工越少。第二条建议是不要追求一步到位。我见过有人想直接从自然语言生成完整装配体结果卡在几何约束上几个月。正确的做法是从单零件开始跑通 STEP 导出再加 URDF再加 G-code。每一步都验证每一步都保留回退方案。第三条建议是保留中间产物。生成的 STEP、URDF、G-code 都要存档方便追溯。我习惯用时间戳命名比如plate_20250101_1430.step配合一个 JSON 记录参数。这样半年后回来改还能知道当时用了什么参数。最后分享一个小技巧如果你用 CadQuery 生成的模型在 CAD 软件里显示异常先检查法线方向。OpenCASCADE 有时会生成反向法线导致模型看起来“里外翻转”。解决办法是在导出前调用result.val().fix()或者用 FreeCAD 的 Part 模块做一次修复。这个坑我踩了三次才记住希望你能一次绕过。