text-to-cad 全链路拆解：从自然语言到 STEP、URDF 与 G-code

CAD 这行当有个特别拧巴的地方：设计师脑子里的想法是三维的，但落到软件里，第一步永远是画二维草图、拉伸、倒角、装配，一套流程走下来，灵感早凉了半截。text-to-cad 想干的事，就是把这套流程压缩成一句话——你用自然语言描述想要的东西，系统直接吐出可用的 CAD 模型文件。这个方向这两年热度一直在涨，从 STEP 到 URDF 再到 G-code，整条链路都在被重新审视。下面我按自己实际折腾过的经验，把这件事拆开讲清楚。

1. 从一句话到三维实体，中间到底发生了什么

很多人第一次听到 text-to-cad，脑子里浮现的是"AI 画图"，跟文生图那种一个路子。实际完全不是一回事。文生图输出的是像素，错了就错了，看着像就行；CAD 输出的是带精确几何约束的实体，一个尺寸错了，后面装配、加工全废。所以 text-to-cad 的核心难点从来不是"生成得像不像"，而是"生成的东西在工程上能不能用"。

1.1 文本理解层：把口语翻译成几何意图

你输入"一个 80 毫米见方、高 20 毫米、四角带 R5 圆角的底座"，系统第一步要做的不是画图，而是解析。它得从这句话里抽出几个关键量：长宽 80、高 20、圆角半径 5、圆角位置在四个角。这一步现在主流做法是拿大语言模型做结构化抽取，输出一段 JSON 或者类似 DSL 的中间表示。

我实测下来，这一步最容易翻车的地方是隐含约束。比如你说"一个能放进标准 19 英寸机柜的托盘"，模型得知道 19 英寸机柜的可用宽度是 482.6 毫米，这个数字不在你的话里，得靠领域知识补。纯靠通用大模型，它大概率给你编一个差不多的数，但工程上差 0.5 毫米就可能装不进去。所以真正能用的系统，文本理解层后面一定挂着一个领域知识库或者参数表。

1.2 几何生成层：从参数到 B-rep

拿到结构化参数之后，才是真正的建模。这里有个分岔路口，决定了整个系统的能力上限。

一条路是参数化模板匹配。系统预置一堆常见几何的生成脚本，识别出你要的是"带圆角的方块"，就调用对应的 CadQuery 或 OpenSCAD 脚本，把参数填进去跑一遍。这条路稳、可控、出错率低，但覆盖面窄，遇到没预置的形状就歇菜。

另一条路是直接生成 B-rep 或网格。让模型直接输出边界表示或者三角网格。这条路理论上什么形状都能出，但生成的实体经常有自交、非流形边、面片法向不一致这些毛病，拿去切片或者做有限元直接报错。

我个人的判断是，现阶段真正能落地的方案是第一条路为主、第二条路兜底。常见件走模板，怪形状走生成再修复。别指望一步到位。

1.3 格式输出层：STEP、URDF、G-code 各管一段

生成出来的几何，最终要落到具体格式上，而不同格式服务的是完全不同的下游。

这张表是我踩过坑之后总结的。最开始我以为生成个 STEP 就万事大吉，结果要做机器人仿真的时候发现 URDF 里根本没有几何信息，只有运动学关系，得重新把 STEP 转成碰撞体再挂上去。这三个格式不是替代关系，是接力关系。

2. 为什么 STEP 是绕不过去的中间站

在所有输出格式里，STEP 的地位最特殊。它既是终点，也是很多场景的起点。搞 text-to-cad 如果不把 STEP 这一环吃透，后面全是空中楼阁。

2.1 STEP 到底存了什么

STEP 文件本质是一个文本格式的实体模型数据库。它用 EXPRESS 语言定义数据结构，里面存的是精确的几何和拓扑信息：点、线、面、壳、实体，以及它们之间的邻接关系。跟 STL 那种一堆三角面片不同，STEP 里一个圆柱面就是一个数学意义上的圆柱面，不是几百个小平面拼出来的近似。

这个特性决定了 STEP 的两个优势：一是精度无损，你把它导入任何主流 CAD 软件，尺寸都是准的；二是可编辑，导入之后还能改参数、加特征，不像网格模型那样一改就糊。

但代价也很明显：STEP 文件结构复杂，解析和生成都比网格麻烦得多。用 Python 处理 STEP，绕不开pythonocc或者cadquery这两个库，前者是 OpenCASCADE 的 Python 绑定，后者是在它上面封装的更高层 API。

2.2 用 CadQuery 把参数变成 STEP 的最小闭环

假设文本理解层已经吐出了参数，下面这段代码就是一个能跑通的最小例子：

import cadquery as cq # 参数来自上游文本解析 length = 80.0 width = 80.0 height = 20.0 fillet_radius = 5.0 result = ( cq.Workplane("XY") .box(length, width, height) .edges("|Z") .fillet(fillet_radius) ) cq.exporters.export(result, "base_plate.step")

这段代码干了四件事：在 XY 平面建工作平面、拉一个长方体、选中所有平行于 Z 轴的边、倒圆角。最后导出 STEP。

看着简单，但有几个坑我必须提醒。第一，edges("|Z")这个选择器选的是竖直边，如果你想要的是顶面四条边的圆角，得换成faces(">Z").edges()。第二，fillet的半径不能超过最短边的一半，否则几何运算会失败，报一个很难懂的Standard_Failure异常。第三，导出的 STEP 默认单位是毫米，但如果你上游传进来的是英寸，忘了换算，出来的模型会大 25.4 倍。

提示：CadQuery 的几何内核是 OpenCASCADE，所有布尔运算和倒角操作都可能因为数值精度问题失败。生产环境里一定要给每个几何操作包 try-except，失败时降级到更简单的形状，而不是直接崩掉整个流程。

2.3 STEP 的坐标系和单位陷阱

我见过太多项目在 STEP 这一环翻车，问题几乎都出在坐标系和单位上。

坐标系方面，STEP 本身支持任意坐标系，但下游软件默认的导入行为不一样。SolidWorks 导入时默认按文件里的坐标系放，FreeCAD 会问你选哪个平面，而很多 CAE 软件默认把模型原点当质心。如果你的模型不是以原点为中心建的，导入之后位置就全乱了。我的做法是生成时一律把几何中心对齐到原点，Z 轴朝上，这样绝大多数软件导入后位置都是对的。

单位方面，STEP 文件头里其实有单位声明，但很多解析器不读它，直接按毫米处理。所以最稳妥的办法是生成时就用毫米，别指望下游帮你换算。

3. URDF 这一环，做机器人仿真的都躲不开

如果你的 text-to-cad 目标是机器人或者任何有运动部件的机构，那 URDF 就是必须跨过去的一道坎。它跟 STEP 完全是两个物种：STEP 描述的是静态几何，URDF 描述的是运动学树。

3.1 URDF 的 link 和 joint 到底怎么组织

URDF 用 XML 写，核心就两个标签：link和joint。link 是刚体，joint 是连接两个刚体的关节。一个典型的机械臂 URDF 长这样：

<robot name="simple_arm"> <link name="base_link"> <visual> <geometry> <cylinder radius="0.05" length="0.1"/> </geometry> </visual> <collision> <geometry> <cylinder radius="0.05" length="0.1"/> </geometry> </collision> <inertial> <mass value="1.0"/> <inertia ixx="0.001" iyy="0.001" izz="0.001" ixy="0" ixz="0" iyz="0"/> </inertial> </link> <link name="arm_link"> <visual> <geometry> <box size="0.3 0.05 0.05"/> </geometry> </visual> </link> <joint name="shoulder" type="revolute"> <parent link="base_link"/> <child link="arm_link"/> <origin xyz="0 0 0.05" rpy="0 0 0"/> <axis xyz="0 1 0"/> <limit lower="-1.57" upper="1.57" effort="10" velocity="1"/> </joint> </robot>

这里有几个关键点，是新手最容易忽略的。

第一，visual、collision、inertial 是三套独立的东西。visual 是给人看的，可以很精细；collision 是给物理引擎算碰撞的，通常用简化形状；inertial 是算动力学用的，需要质量和惯性张量。很多人图省事三套用同一个几何，结果仿真要么慢得要死，要么物理行为完全不对。

第二，joint 的 origin 是相对父 link 的。上面例子里xyz="0 0 0.05"意思是关节位置在 base_link 坐标系下往上 0.05 米。这个数错了，整个机械臂的位姿就全错。

第三，惯性张量不能瞎填。上面那个ixx=0.001是我随手写的，实际值要根据几何形状和质量算。圆柱绕中心轴的转动惯量是0.5 * m * r^2，绕径向是(1/12) * m * (3r^2 + h^2)。填错了，仿真里的动力学响应就是错的。

3.2 从 STEP 到 URDF 的转换链路

text-to-cad 生成 URDF 的典型链路是这样的：文本先解析出运动学结构（几个 link、几个 joint、怎么连），然后每个 link 的几何单独生成 STEP 或者直接用基本体，最后组装成 URDF。

这里有个现实问题：URDF 里的几何标签只支持基本体（box、cylinder、sphere）和 mesh 文件。也就是说，你没法直接把 STEP 塞进 URDF。要么把 STEP 转成 STL 或 DAE 再引用，要么用基本体近似。

我的经验是，碰撞体用基本体，视觉体用 mesh。碰撞检测用基本体又快又稳，视觉上想要好看就挂个精细的 mesh。两者在 URDF 里分开写，互不干扰。

3.3 导入仿真环境时最常见的三个报错

把 URDF 导入 CoppeliaSim 或者类似仿真环境时，报错基本集中在三个地方。

一是mesh 路径找不到。URDF 里的filename支持相对路径和package://协议，但不同仿真器对相对路径的解析基准不一样。最保险的做法是用绝对路径，或者把 mesh 和 URDF 放同一个目录用相对路径。

二是惯性矩阵非正定。物理引擎要求惯性张量是正定的，如果你填的数不满足三角不等式（比如 ixx + iyy < izz），仿真器会直接拒绝加载。这个错误信息通常很隐晦，得自己检查数值。

三是关节类型不匹配。URDF 支持 revolute、prismatic、continuous、fixed、floating、planar 六种关节类型，但不同仿真器支持程度不一样。比如有些仿真器不支持 floating，你写了它也不报错，就是不动。

4. G-code 是最后一公里，也是最容易被低估的一环

模型建好了，仿真跑通了，最后要变成实物，就得落到 G-code。这一步是把几何变成机床能执行的指令，中间的转换逻辑跟前面完全不是一回事。

4.1 G-code 不是通用格式，是机床方言

很多人以为 G-code 是个标准，生成一份到处能用。实际上 G-code 更像方言，不同机床、不同控制系统、不同后处理器的输出都不一样。同样一个圆弧，FANUC 系统和西门子系统可能用不同的 G 指令。

所以 text-to-cad 生成 G-code 这件事，本质上不是"生成"，而是"切片加后处理"。真正干活的是切片软件（3D 打印）或者 CAM 软件（CNC），text-to-cad 负责的是把几何喂给它们，然后调用它们的命令行接口。

以 3D 打印为例，从 STEP 到 G-code 的链路是：STEP 转 STL，STL 导入切片软件，切片软件按层高、填充率、支撑策略生成 G-code。每一步都有参数要调。

4.2 切片参数里最影响成品的几个

我拿实际打印的经验说几个关键参数。

层高决定表面质量和打印时间。0.2 毫米是通用值，想要精细就 0.1，想要快就 0.3。但层高不是越小越好，太小的层高会让喷嘴反复加热同一区域，反而容易糊。

填充率决定强度和材料用量。15% 是展示件常用值，功能件一般 30% 到 50%，受力件可以到 80% 甚至 100%。填充图案也有讲究，网格状强度均匀，蜂窝状省材料，直线状最快。

支撑策略是最容易翻车的地方。悬垂角度超过 45 度一般就要加支撑，但支撑加多了拆起来费劲，加少了又塌。我的做法是先用自动支撑生成，然后手动删掉明显不需要的，再在关键悬垂处补几根。

4.3 从 CAD 到 G-code 的自动化脚本长什么样

如果要把这条链路自动化，大致是这样：

import subprocess import os # 假设上一步已经生成了 model.step step_file = "model.step" stl_file = "model.stl" gcode_file = "model.gcode" # 第一步：STEP 转 STL，用 FreeCAD 命令行 subprocess.run([ "freecadcmd", "-c", f"import Part; " f"shape = Part.Shape(); " f"shape.read('{step_file}'); " f"shape.exportStl('{stl_file}')" ], check=True) # 第二步：调用切片软件命令行 # 以 PrusaSlicer 为例 subprocess.run([ "prusa-slicer", "--export-gcode", "--layer-height", "0.2", "--fill-density", "30%", "--support-material", "-o", gcode_file, stl_file ], check=True)

这段脚本的关键在于，每一步都要检查返回值。check=True会在命令失败时抛异常，避免错误被静默吞掉。实际生产里还要加日志、加超时、加重试。

注意：切片软件的版本差异很大，命令行参数经常变。写自动化脚本时一定要锁定版本，别用latest。我吃过一次亏，切片软件升级后参数名从--fill-density改成了--fill-density-percent，整条流水线半夜挂了。

5. 把整条链路串起来时，我踩过的那些坑

前面分开讲了每一环，但真正难的是把它们串起来。串联过程中暴露的问题，往往比单环节的问题更隐蔽。

5.1 单位不一致导致的连锁错误

这是最经典也最致命的坑。文本解析层如果没统一单位，后面全乱。我遇到过一次，上游传进来的是英寸，CadQuery 按毫米建了模，导出的 STEP 尺寸大了 25.4 倍，切片软件按这个尺寸算，打印时间预估 40 小时，实际根本打不出来。

解决办法是在整条链路的最前端做一次单位归一化，所有内部计算一律用毫米，只在最终输出时按需转换。别在每个环节各自处理单位，那样迟早出错。

5.2 几何精度在格式转换中的损失

STEP 转 STL 是有精度损失的，因为 STL 用三角面片近似曲面。如果转的时候弦高公差设得太大，圆柱就变成了多边形柱，装配的时候会卡。我的经验是，弦高公差设成 0.01 毫米，角度公差设成 0.5 度，这个精度对绝大多数应用够了，文件也不会太大。

但要注意，精度设太高会让 STL 文件爆炸。一个直径 100 毫米的圆柱，公差 0.01 毫米的话，圆周上大概要 300 多个面片。如果模型里有几十个这样的特征，STL 轻松上百兆，切片软件直接卡死。

5.3 自动化流程中的错误处理

整条链路涉及多个外部工具，任何一个挂了都会让流程中断。我的做法是每个环节都做幂等设计：如果中间产物已经存在且比输入新，就跳过这一步。这样流程中断后重跑，不会从头再来。

另外，每个环节的输出都要做基本校验。STEP 生成后检查文件大小是否合理，STL 生成后检查面片数是否在预期范围，G-code 生成后检查是否有明显的空层。这些校验能挡住大部分低级错误。

5.4 一个完整的端到端例子

假设用户输入"一个直径 50 毫米、高 30 毫米、中心有直径 10 毫米通孔的圆柱"。

文本解析层输出：{"type": "cylinder", "outer_diameter": 50, "height": 30, "hole_diameter": 10, "hole_type": "through"}。

几何生成层用 CadQuery：

import cadquery as cq outer_d = 50.0 height = 30.0 hole_d = 10.0 result = ( cq.Workplane("XY") .circle(outer_d / 2) .extrude(height) .faces(">Z") .workplane() .hole(hole_d) ) cq.exporters.export(result, "cylinder.step")

然后按需转 STL、切片、出 G-code。整条链路跑通一次大概几秒钟，比手动建模快得多。

但这里有个细节：hole()方法默认是打通孔，如果你要的是盲孔，得用cboreHole或者手动布尔减。这个区别在文本解析层就要识别出来，不能等到几何生成才发现。

6. 这套东西现在能用到什么程度

说了这么多技术细节，最后聊聊实际能力边界。text-to-cad 现在不是万能的，但也不是玩具。

能稳定搞定的：标准件、简单结构件、参数化零件。比如法兰、支架、外壳、齿轮毛坯。这些形状有明确的参数描述，模板匹配能覆盖。

勉强能搞定的：中等复杂度的装配体、带简单曲面的零件。需要模型有一定的几何推理能力，出错率明显上升，得人工检查。

还搞不定的：自由曲面、复杂有机形状、需要大量工程判断的结构。这些要么靠生成模型硬扛（质量不稳定），要么根本没法用语言描述清楚。

我的建议是，把 text-to-cad 当成一个快速原型工具，而不是最终生产工具。它能帮你把想法快速变成可看的模型，省掉从零建模的时间，但出来的东西一定要人工过一遍。尤其是要拿去加工或者做仿真的，尺寸、约束、材料属性都得自己核对。

另外，这套流程对输入描述的规范性要求很高。你说得越具体，出来的东西越靠谱。"一个支架"和"一个 100x60x8 毫米、四角 M4 沉头孔、中心减重槽的铝合金支架"，生成质量完全不是一个级别。所以用好这个工具的前提，是你自己得清楚想要什么。