1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次看到 “text-to-cad” 这个说法很多人会下意识觉得它只是个营销词——毕竟 CAD 建模这件事从入行那天起就被灌输了一个观念你得先会看图、会画草图、会约束、会拉伸才能得到一个像样的三维实体。但这两年我在几个小项目里反复折腾下来越来越确信一件事用自然语言直接生成 CAD 模型已经不是能不能做的问题而是做到什么精度、用在什么场景的问题。先把概念说清楚。text-to-cad字面意思就是“文本转 CAD”核心链路是你输入一段描述比如“一个 80mm × 60mm × 10mm 的矩形底板四角各有一个直径 6mm 的通孔孔中心距边缘 8mm”系统输出一个可用的三维模型文件常见格式包括STEP、STL、URDF甚至直接生成G-code用于加工。它解决的核心痛点是大量结构简单、重复性高的零件用传统交互式建模太慢而用脚本建模又有学习成本。自然语言正好卡在中间——比鼠标点击快比写代码门槛低。适合看这篇内容的人我大致分三类。第一类是机械、自动化方向的工程师手头经常有几十上百个标准件、安装板、支架要建想批量处理第二类是做机器人仿真和数字孪生的朋友需要快速产出URDF模型丢进仿真环境里跑第三类是做创客、DIY、小批量加工的人想把自己脑子里的一个想法快速变成能打印、能切割的文件。这三类人的共同点是不需要曲面造型那种艺术级精度但需要尺寸准确、结构规整、能直接进入下游流程。我自己的切入点是第二类和第三类之间——给一个小型机械臂项目做连杆和底座的快速迭代。传统做法是 SolidWorks 里画草图、标尺寸、拉伸、打孔一个零件改五次尺寸就要重画五遍。后来我尝试用文本描述驱动建模配合参数化脚本改一个数字就能重新生成整套模型。这个过程踩了不少坑也总结出一套相对稳定的做法下面完整拆开讲。2. 整体方案怎么搭三条技术路线与选型逻辑2.1 三条主流路线对比text-to-cad 落到实操层面目前能走通的路子大致三条我按自己的使用频率和稳定性排个序。路线核心机制输出格式上手难度适合场景大模型生成建模脚本自然语言转 Python/OpenSCAD 代码STEP/STL中结构规整的零件、批量变体大模型直接输出几何描述生成 JSON/CSV 参数表再驱动模板STEP/URDF低标准件、参数化系列端到端模型生成专用模型直接输出网格或 B-repSTL/STEP低但不可控概念验证、快速预览第一条路线是我最推荐的。大模型不直接画图而是生成一段建模脚本比如用 CadQuery 或者 OpenSCAD 的语法然后本地执行脚本得到 STEP 文件。这样做的好处是模型是“算”出来的不是“猜”出来的尺寸精确可控而且脚本可以版本管理、可以参数化。坏处是模型得能理解 CadQuery 的 API偶尔会写出跑不通的代码需要人工修。第二条路线适合标准化程度极高的场景。比如你有一批安装板区别只是长宽和孔位那就做一个模板脚本让大模型只负责把自然语言转成参数字典模板负责生成几何。这条路最稳因为几何逻辑是你自己写的大模型只做“翻译”。第三条路线目前我不太建议用在正式项目里。端到端生成的模型拓扑结构经常是乱的孔可能不是真圆面可能不共面导进 CAD 软件里想改都改不动。拿来做概念预览可以做加工不行。2.2 为什么我最终选了“脚本驱动”这条路选型的核心判断标准只有一个下游能不能用。你生成的模型最终要进 CAD 软件编辑、要进仿真环境、要出工程图、要加工那模型必须是干净的 B-rep 实体而不是一堆三角面片。STEP 格式之所以关键就是因为它承载的是精确几何而 STL 只是网格近似。脚本驱动这条路本质上是把“建模”这件事从交互操作变成了代码执行。我举个具体例子你就明白差别了。假设要建一个带四个安装孔的底板交互式建模的步骤是选基准面、画矩形、标尺寸、拉伸、选面、画圆、阵列、切除。而脚本建模是import cadquery as cq plate ( cq.Workplane(XY) .box(80, 60, 10) .faces(Z) .workplane() .rect(64, 44, forConstructionTrue) .vertices() .hole(6) ) cq.exporters.export(plate, base_plate.step)这段代码跑完STEP 文件就出来了。改尺寸只改数字改孔位只改 rect 的参数。大模型要做的就是把“80 乘 60 的板四角打 6 个的孔孔距边 8 毫米”翻译成上面这段代码。翻译对了模型就对了翻译错了你看代码也能立刻发现哪里不对。这种“可审查性”是端到端生成给不了的。2.3 工具链的完整拼图一套能跑起来的 text-to-cad 工作流我目前用的是这个组合自然语言理解层任意一个能写代码的大模型负责把描述转成 CadQuery 或 OpenSCAD 脚本几何内核层CadQuery底层是 OpenCASCADE或 OpenSCAD负责实际生成几何格式转换层CadQuery 直接导出 STEP/STLURDF 需要额外用脚本组装 link 和 joint验证层用 FreeCAD 或任意 CAD 软件打开检查或者用 trimesh 做网格检查下游对接STEP 进 CAD 出图STL 进切片软件URDF 进仿真环境这里有个细节值得说为什么不用 FreeCAD 的 Python API 而用 CadQuery因为 CadQuery 的 API 设计更接近“描述几何”而不是“操作软件”大模型生成代码的准确率明显更高。FreeCAD 的 API 里充斥着 GUI 概念比如Gui.activeDocument()大模型很容易写出一堆依赖界面状态的代码跑起来就崩。CadQuery 是纯几何描述没有界面依赖稳定得多。3. 核心细节拆解从一句话到 STEP 文件的关键环节3.1 描述文本怎么写模型才听得懂这是整个流程里最容易被低估的环节。很多人以为随便说一句“帮我画个支架”就行了结果生成的模型完全不是想要的。自然语言描述的质量直接决定生成代码的质量。我总结了一个“四要素描述法”实测下来准确率提升非常明显。第一个要素是基准形状。你得说清楚主体是什么长方体、圆柱、L 形、还是几个形状的组合。比如“一个 L 形支架”就比“一个支架”好得多。第二个要素是关键尺寸。所有尺寸必须带单位和数值不要用“大一点”“差不多”这种词。长宽高、直径、厚度、间距能给的都给。第三个要素是特征位置。孔在哪里、槽在哪里、圆角在哪个边要用相对位置描述。比如“四角各一个通孔孔中心距相邻两边各 8mm”就非常明确。第四个要素是坐标系约定。这一点很多人忽略但特别重要。你得说明模型的原点在哪里、哪个方向是 Z 轴。比如“底面中心为原点Z 轴向上”就是一个清晰的约定。没有这个约定生成的模型可能躺在坐标系里后续装配就麻烦了。我实际用的一段描述长这样创建一个矩形底板长 80mm宽 60mm厚 10mm。底面中心为原点Z 轴向上。在顶面四角各打一个直径 6mm 的通孔孔中心距相邻两边各 8mm。所有外边缘倒 2mm 圆角。这段描述丢给大模型生成的 CadQuery 代码基本一次就能跑通。对比一下如果只说“画个板子打四个孔”生成的代码大概率缺尺寸、缺坐标系、缺圆角你还得反复追问。3.2 代码生成后的三道校验大模型生成的代码我从来不直接信。跑之前先看跑之后再看导出之后还要看。三道校验缺一不可。第一道是语法校验。CadQuery 的 API 不算复杂但大模型偶尔会写出不存在的链式调用比如.faces(Z).workplane().circle(3).cutThruAll()里cutThruAll就不是标准方法。这种错误跑一下就报错改起来也快。我的习惯是先把代码丢进一个空脚本里跑一遍看报错信息定位问题。第二道是几何校验。代码跑通了不代表模型对。我遇到过生成的代码把孔打在了底面而不是顶面或者圆角加在了错误的边上。这时候需要打开模型看一眼或者用脚本检查体积、包围盒尺寸是否符合预期。比如一个 80×60×10 的板体积应该在 48000 立方毫米左右减去四个孔的体积大概 46000 多。如果算出来差很多说明几何有问题。第三道是格式校验。导出的 STEP 文件用 FreeCAD 打开后要检查是不是实体solid而不是壳体shell。有些操作会导致模型变成薄壳虽然看起来一样但没法做布尔运算也没法加工。检查方法很简单在 FreeCAD 里选中模型看属性栏里是不是显示“Solid”。3.3 URDF 和 G-code 的特殊处理STEP 和 STL 是通用格式但 URDF 和 G-code 有各自的规矩不能直接套用。URDF 的核心是 link 和 joint 的树状结构。一个机器人模型不是单个零件而是多个 link 通过 joint 连接。text-to-cad 在这里的作用是快速生成每个 link 的几何然后你需要额外定义 joint 的类型旋转、平移、固定、轴向、限位。我的做法是先用 text-to-cad 生成每个连杆的 STEP再用脚本把 STEP 转成 STL最后手写或半自动生成 URDF 的 XML。这里有个坑URDF 里的 mesh 路径必须是相对路径或者 package 路径用绝对路径在别的机器上就跑不起来。G-code 则是另一条路。它不是模型格式而是加工指令。text-to-cad 生成 G-code 的场景通常是简单的二维切割或钻孔。比如你描述“一块 100×50 的板四角打 5mm 通孔”系统可以直接输出钻孔的 G-code。但这里要注意G-code 依赖具体的机床坐标系和刀具参数不能通用。我一般只把 text-to-cad 用在生成几何和 CAM 的中间步骤最终的 G-code 还是用专业 CAM 软件出安全得多。4. 完整实操流程从零跑通一个带孔底板的生成4.1 环境准备与依赖安装先把环境搭起来。我用的组合是 Python 3.10 CadQuery 一个大模型接口。CadQuery 的安装有个坑它依赖 OpenCASCADE在 Windows 上直接用 pip 装经常失败。我的建议是用 conda 装命令如下conda create -n text2cad python3.10 conda activate text2cad conda install -c conda-forge cadquery装完之后验证一下import cadquery as cq print(cq.__version__)能打印出版本号就说明几何内核正常。如果报错说找不到 OCC 库大概率是 conda 环境没激活对或者混用了 pip 和 conda。千万不要在同一个环境里既用 pip 又用 conda 装 CadQuery依赖冲突会让你怀疑人生。4.2 描述转代码的实操记录环境好了开始跑第一个例子。我把前面那段“80×60×10 底板带四孔”的描述丢给大模型得到的代码和我手写的几乎一样。这里有个小技巧在提示词里明确要求“使用 CadQuery输出完整可执行代码不要省略 import”这样拿到的代码可以直接存成 .py 文件跑。存成gen_plate.py然后python gen_plate.py目录下就会出现base_plate.step。用 FreeCAD 打开检查尺寸包围盒应该是 80×60×10四个孔直径 6mm孔心距边 8mm。如果都对这一步就过了。4.3 参数化改造让模型可以批量变体单次生成只是起点真正的价值在于批量。我把生成的代码改造成了一个函数def make_plate(length, width, thickness, hole_dia, edge_dist): return ( cq.Workplane(XY) .box(length, width, thickness) .faces(Z) .workplane() .rect(length - 2*edge_dist, width - 2*edge_dist, forConstructionTrue) .vertices() .hole(hole_dia) ) for i, (l, w) in enumerate([(80, 60), (100, 70), (120, 80)]): plate make_plate(l, w, 10, 6, 8) cq.exporters.export(plate, fplate_{i}.step)这段代码一次生成三个不同尺寸的底板。参数化的意义在于自然语言只需要描述“变化规律”不需要逐个描述每个零件。比如你说“生成三个底板长分别是 80、100、120宽比长少 20其他参数一样”大模型就能生成类似的循环代码。4.4 导出与下游对接STEP 文件导出后下游怎么用取决于你的场景。进 CAD 出图直接导入就行。进 3D 打印需要转 STLcq.exporters.export(plate, plate.stl, tolerance0.01)tolerance控制网格精度0.01mm 对于大多数打印场景足够了。数值越小文件越大别设得太小。进仿真环境的话URDF 的组装需要额外一步。我通常用脚本把 STEP 转成 STL然后写一个 URDF 模板把 mesh 路径和 joint 参数填进去。这部分内容比较多后面单独展开。5. 常见问题与排查技巧实录5.1 代码跑不通的几种典型情况情况一API 方法不存在。大模型偶尔会编造 CadQuery 的方法名比如把hole()写成drill()。排查方法是看报错信息里的AttributeError然后去 CadQuery 文档里找正确的方法名替换。情况二链式调用顺序错误。CadQuery 的链式调用有严格的顺序要求比如必须先选面再建工作平面再画草图。顺序错了几何会跑到奇怪的位置。排查方法是把链式调用拆开一步步打印中间结果。情况三单位混淆。CadQuery 默认单位是毫米但大模型有时候会按厘米或米来理解描述。如果你说“长 0.08”它可能生成 0.08mm 的板。所有描述里必须带单位而且明确说“毫米”。5.2 模型看起来对但用不了的情况问题一模型是壳体不是实体。某些布尔运算会导致模型变成薄壳。检查方法是在 FreeCAD 里看属性如果是 Shell 而不是 Solid需要重新执行布尔运算或者用clean()方法修复。问题二面不共面。多个形状组合时如果坐标有微小偏差面可能不共面导致后续倒角或抽壳失败。解决办法是在生成代码里用整数或整齐的小数避免浮点误差累积。问题三孔不是真圆。如果导出的是 STL 且精度设得太低孔会变成多边形。STEP 格式不存在这个问题因为它是精确几何。需要精确孔的时候一律用 STEP。5.3 排查速查表现象可能原因排查动作解决办法代码报 AttributeErrorAPI 方法名错误看报错行查文档替换正确方法模型位置不对坐标系约定缺失检查包围盒在描述里明确原点尺寸差十倍单位混淆量包围盒描述里统一用毫米无法倒角面不共面或非实体检查 Solid/Shell修复布尔运算URDF 加载失败mesh 路径错误看仿真报错改用相对路径G-code 撞刀坐标系不匹配核对机床原点用 CAM 软件复核5.4 几个我踩过的坑第一个坑是过度信任大模型的几何理解。有一次我描述“在板的中心打一个沉头孔”生成的代码只打了通孔没有沉头。后来我学乖了沉头孔这种带阶梯的特征必须把两段直径和深度都写清楚。第二个坑是忽略模型的版本差异。CadQuery 2.x 和 1.x 的 API 有变化大模型训练数据里可能混着旧版本。我现在的做法是在提示词里明确说“使用 CadQuery 2.4 的 API”。第三个坑是批量生成时不加异常处理。循环生成一百个零件中间有一个报错整个脚本就停了。后来我加了 try-except把失败的记录到日志里成功的继续跑。6. 进阶玩法URDF 组装与批量变体生成6.1 从零件到机器人URDF 的组装逻辑单个零件生成只是第一步真正体现 text-to-cad 价值的是组装。以一个小型机械臂为例它由底座、大臂、小臂、末端执行器四个 link 组成link 之间通过旋转 joint 连接。我的做法是第一步用 text-to-cad 分别生成四个 link 的 STEP 文件每个 link 的描述里明确它的局部坐标系原点。比如大臂的原点设在旋转轴中心这样 joint 的位置就好定义。第二步把 STEP 转成 STL因为 URDF 的 visual 和 collision 通常用 STL。第三步写 URDF 的 XML。这里的关键是 joint 的 origin 和 axis。origin 定义子 link 相对父 link 的位姿axis 定义旋转轴。这两个参数必须和你在生成 link 时约定的坐标系一致否则装配出来是散的。第四步在仿真环境里加载 URDF检查 link 之间的相对位置对不对。如果不对回去改 joint 的 origin。6.2 批量变体的参数表驱动法当零件数量多、变体多的时候逐个描述效率太低。我现在的做法是维护一张参数表用 CSV 或 JSON 存然后写一个脚本读表生成所有模型。参数表长这样name,length,width,thickness,hole_dia,edge_dist plate_a,80,60,10,6,8 plate_b,100,70,10,6,8 plate_c,120,80,12,8,10脚本读表对每一行调用make_plate导出对应文件。大模型在这里的角色变成了“写这个脚本”而不是“逐个生成模型”。这样效率高得多而且参数表本身就是设计文档改起来一目了然。6.3 和传统 CAD 工作流的衔接text-to-cad 不是要取代 CAD 软件而是补上“快速生成”这一环。我的实际工作流是用 text-to-cad 生成基础几何和批量变体导出 STEP 进 FreeCAD 或中望 CAD 做细节调整需要出工程图的时候在 CAD 软件里标尺寸、加公差需要加工的时候导出 STL 或 DXF 进 CAM 软件这个衔接里有个细节STEP 文件在 CAD 软件里打开后特征树可能是空的因为它是直接几何而不是特征建模。想改尺寸只能重新生成不能在 CAD 里改草图。所以我的习惯是保留生成脚本改尺寸改脚本重新跑而不是在 CAD 里硬改。7. 我个人的几条实操心得先说一个最实在的描述文本的精度决定了你省下来的时间。我一开始图省事描述写得很模糊结果生成的模型改了三四轮才可用算下来比手画还慢。后来我把描述模板化每次按“基准形状 关键尺寸 特征位置 坐标系”四要素填基本一到两轮就能得到可用模型。再说一个关于工具选择的CadQuery 比 OpenSCAD 更适合 text-to-cad。OpenSCAD 是网格建模导出的 STL 精度有限而且它的脚本语言更偏“编程”而不是“描述几何”大模型生成起来错误率更高。CadQuery 基于 OpenCASCADE输出的是精确 B-repSTEP 质量好得多。最后一个关于心态的别指望一句话生成复杂装配体。目前 text-to-cad 最擅长的还是单个零件、规整结构、参数化系列。复杂曲面、自由造型、精密配合还是得靠人。把它当成一个“快速起稿”的工具而不是“全自动建模”的银弹用起来会舒服很多。如果后续要继续扩展我建议往两个方向走一是把生成脚本和版本管理结合起来每个零件的每次变体都有记录二是把参数表和仿真环境打通改一个参数就能自动重新生成模型并跑一遍仿真。这两件事我都在做等跑顺了再单独写一篇。