1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词我的反应和大多数人一样用文字直接生成 CAD 模型这事靠谱吗毕竟在传统工作流里一个零件从需求到能加工的图纸中间要经过草图绘制、尺寸标注、特征建模、装配约束、格式导出这一长串环节每一步都依赖工程师的手动操作和经验判断。而 text-to-cad 想做的事情是把这段流程压缩成一句自然语言描述让程序自动输出可用的三维几何文件。这个方向之所以最近被反复讨论核心原因在于 CAD 建模里有大量重复性、模式化的工作。比如标准件库里的螺栓、法兰、型材截面比如参数化程度很高的钣金件、盘扣脚手架节点再比如批量生成的机械结构。这些模型的几何逻辑其实很清晰只是过去必须靠人一条条画线、一个个拉伸。text-to-cad 的价值就在于把这些有规律可循的建模任务交给程序人只负责描述意图和校验结果。它适合谁来关注我梳理了一下大致是三类人。第一类是机械、建筑、电气领域的工程师手头有大量参数化建模需求想用脚本或 AI 提效第二类是做机器人仿真和数字孪生的开发者需要频繁生成 URDF、STEP 这类格式的模型文件第三类是做 CAM 加工和 3D 打印的技术人员希望从文字描述直接拿到可切片、可出 G-code 的几何体。如果你属于这三类中的任何一类下面这些内容应该对你有实际参考价值。需要先说明一点text-to-cad 目前不是一个开箱即用的成熟软件它更像是一类技术方案的统称。市面上有基于大语言模型直接生成 CAD 脚本的路线也有基于参数模板加自然语言解析的路线还有把文字转成中间几何描述再转成标准格式的路线。我下面会把这几种路线的原理、实操和坑都拆开讲你可以根据自己的场景选一条最合适的。2. 技术路线拆解文字是怎么变成几何体的2.1 三条主流路线的核心差异要把一个直径 20 毫米、长 50 毫米的圆柱这句话变成 STEP 文件中间至少有两种截然不同的思路。我把目前能落地的方案归成三类用一张表先看清楚差异。路线核心机制输出格式适合场景上手难度代码生成路线大模型生成 CadQuery/OpenSCAD 脚本STEP、STL参数化零件、批量建模中模板填充路线自然语言解析后填入预定义参数模板STEP、URDF标准件、固定结构低中间表示路线文字转 JSON/DSL 几何描述再转 CADSTEP、G-code复杂装配、仿真高代码生成路线的逻辑最直接让大语言模型理解你的文字描述然后输出一段 CadQuery 或 OpenSCAD 的建模代码再由 CAD 内核执行这段代码生成实体。这条路线的优势是灵活几乎任何能用代码描述的几何体都能生成劣势是模型生成的代码不一定一次跑通需要人工校验和调试。模板填充路线走的是另一条路。它不指望模型理解任意几何而是预先准备好一批参数化模板比如圆柱法兰齿轮型材然后用自然语言解析出关键参数填进去。这条路线的稳定性最高因为几何逻辑是人工写死的模型只负责抽取参数。缺点是覆盖面有限遇到模板里没有的形状就无能为力。中间表示路线是最工程化的一种。它把自然语言先转成一种结构化的几何描述语言比如用 JSON 描述特征树再写一个转换器把 JSON 映射到具体的 CAD 操作。这条路线的可控性最强也最适合接入 URDF 这类需要关节、连杆、坐标系信息的场景但开发成本最高。2.2 为什么 STEP 和 URDF 是两个关键出口在 text-to-cad 的输出端STEP 和 URDF 出现的频率最高这不是偶然。STEP 是 CAD 领域通用的三维交换格式几乎所有主流 CAD 软件都能读写它保留的是精确的边界表示几何适合后续加工、装配、出图。而 URDF 是机器人描述格式它描述的不只是几何还有连杆之间的关节关系、运动学约束、惯性参数是仿真和运动规划的基础。这两个格式代表了 text-to-cad 的两类典型需求一类是我要一个能加工的零件另一类是我要一个能动的机器人模型。前者关心尺寸精度和特征完整性后者关心拓扑结构和坐标系定义。理解了这一点你在设计自己的 text-to-cad 流程时就知道该往哪个方向优化。至于 G-code它其实是更下游的产物。G-code 是数控加工和 3D 打印的指令语言它描述的是刀具路径而不是几何体。text-to-cad 一般不会直接生成 G-code而是先生成 STL 或 STEP再交给切片软件或 CAM 软件生成 G-code。所以如果你的目标是加工text-to-cad 的终点应该是 STL 或 STEPG-code 是后一步的事。2.3 大模型在这里扮演什么角色很多人以为 text-to-cad 就是让 GPT 画图其实大模型在其中的角色比想象中要窄。它主要负责的是自然语言到结构化信息的转换也就是把一个带四个 M8 孔的方形法兰盘边长 100厚 10这句话解析成边长、厚度、孔径、孔位这些参数。真正生成几何体的还是 CadQuery、OpenCASCADE 这类几何内核。这个分工很重要因为它决定了系统的可靠性边界。大模型擅长的是理解模糊描述、补全缺失参数、生成代码框架它不擅长的是精确的几何计算和拓扑校验。所以一个稳健的 text-to-cad 系统应该是大模型负责翻译几何内核负责执行中间加一层参数校验和几何验证。我见过一些直接把大模型输出当最终结果的方案跑十个模型能错三四个问题就出在缺少这层校验。3. 实操环境搭建从零把工具链跑起来3.1 Python 环境与 CadQuery 安装代码生成路线最常用的几何库是 CadQuery它基于 OpenCASCADE 内核用 Python 写建模逻辑输出 STEP 和 STL 都很方便。安装步骤如下。# 建议用 conda 建独立环境避免和系统 Python 冲突 conda create -n text2cad python3.10 conda activate text2cad # 安装 CadQuery官方推荐用 conda 装依赖处理更干净 conda install -c conda-forge cadquery # 验证安装 python -c import cadquery as cq; print(cq.__version__)这里有个坑要提前说CadQuery 的 pip 安装经常在 OpenCASCADE 依赖上出问题尤其是 Windows 环境。我试过三次 pip 装两次卡在 OCP 编译上。所以强烈建议走 conda-forge 渠道省心很多。如果你只能用 pip记得先装好对应版本的 OCP 包。3.2 大模型接口的接入方式要让大模型生成 CadQuery 代码你需要一个能调用模型的接口。这里不涉及任何特定厂商只说通用做法准备一个函数输入是用户的自然语言描述输出是模型生成的 Python 代码字符串。关键是要在提示词里把 CadQuery 的 API 约束清楚否则模型很容易写出不存在的函数。import cadquery as cq def build_from_description(desc: str): # 这里 desc 是模型生成的 CadQuery 代码 # 实际使用时需要先做安全校验禁止执行危险操作 local_vars {cq: cq} exec(desc, {}, local_vars) return local_vars.get(result) # 一个典型的模型输出示例 sample_code result ( cq.Workplane(XY) .circle(10) .extrude(50) ) model build_from_description(sample_code) cq.exporters.export(model, cylinder.step)注意直接 exec 模型生成的代码有安全风险生产环境一定要做沙箱隔离和代码审查禁止文件系统写操作和网络调用。3.3 URDF 导出链路的准备如果你的目标是机器人仿真还需要把几何体组装成 URDF。URDF 本质是一个 XML 文件描述连杆和关节。常见做法是先用 CadQuery 生成每个连杆的 STL再手写或程序生成 URDF 的 XML 结构。# 生成连杆几何 link_geom cq.Workplane(XY).box(100, 20, 20) cq.exporters.export(link_geom, link1.stl) # URDF 中引用这个 STL urdf_template robot namesimple_arm link namelink1 visual geometry mesh filenamelink1.stl/ /geometry /visual /link /robot with open(robot.urdf, w) as f: f.write(urdf_template)这套流程跑通之后你就可以把 URDF 导入到 CoppeliaSim 这类仿真环境里做运动学验证。导入时最常见的报错是 mesh 路径找不到和坐标系不匹配后面排查章节会细说。4. 核心环节实现把一句话变成可用的模型4.1 自然语言解析与参数抽取整个流程里最容易出问题的就是这一步。用户说一个厚 10 毫米的圆盘直径 80模型要能准确抽出厚度 10、直径 80 两个参数还要知道圆盘对应的是圆柱体。我实测下来纯靠大模型自由发挥参数抽取的准确率大概在七成左右剩下的三成要么漏参数要么单位搞错。提升准确率的办法是给模型一个结构化的输出格式约束。不要让模型直接写代码而是先让它输出 JSON再由程序把 JSON 映射成建模代码。这样中间多了一层校验参数错了能及时发现。# 期望模型输出的结构化描述 { shape: cylinder, params: { diameter: 80, height: 10, unit: mm }, features: [] }有了这个 JSON你就可以写一个映射函数把 shape 和 params 翻译成 CadQuery 调用。这样做的好处是即使模型偶尔抽错参数你也能在 JSON 层面拦截而不是等到几何生成失败才发现。4.2 几何生成与特征叠加简单形状好办复杂零件就涉及特征叠加。比如一个 100x100x10 的方板四角各有一个直径 8 的通孔孔中心距边缘 15 毫米这需要先建方板再在四个角做孔特征。result ( cq.Workplane(XY) .box(100, 100, 10) .faces(Z) .workplane() .rect(70, 70, forConstructionTrue) .vertices() .hole(8) )这段代码的逻辑是先建方板选中顶面在顶面画一个 70x70 的构造矩形取四个顶点作为孔位然后打直径 8 的孔。孔中心距边缘的距离是 (100-70)/2 15 毫米正好符合要求。这种构造几何定位的技巧在 CadQuery 里非常常用比直接算坐标要直观得多。4.3 参数校验与几何验证模型生成之后不能直接就用必须做校验。校验分两层参数层和几何层。参数层检查数值是否合理比如直径不能为负、孔不能比板还大几何层检查生成的实体是否有效比如有没有自相交、体积是否为零。# 参数校验 def validate_params(params): if params[diameter] 0: raise ValueError(直径必须为正数) if params[height] 0: raise ValueError(厚度必须为正数) # 几何校验 def validate_solid(model): solid model.val() if solid.Volume() 0: raise ValueError(生成的实体体积为零几何无效) return True几何校验这一步很多人会跳过结果导出的 STEP 在某些 CAD 软件里打不开。我踩过这个坑一个自相交的实体在 CadQuery 里能生成导出后在中望 CAD 里直接报错。所以体积校验和有效性检查一定要做。4.4 格式导出与批量处理单个模型跑通之后批量处理就是加一层循环。这里的关键是错误隔离不能让一个模型失败导致整批中断。import os descriptions [ 直径 20 长 50 的圆柱, 100x100x10 带四孔方板, 外径 60 内径 30 厚 10 的圆环 ] for i, desc in enumerate(descriptions): try: code generate_code(desc) model build_from_description(code) validate_solid(model) cq.exporters.export(model, foutput/part_{i}.step) print(fpart_{i} 生成成功) except Exception as e: print(fpart_{i} 失败: {e}) continue批量处理时建议把每个模型的描述、生成的代码、校验结果都记到日志里方便回溯。我一般会存一份 JSON 日志记录每个零件的参数和状态出问题时能快速定位是解析错了还是几何错了。5. 常见问题与排查技巧实录5.1 模型生成的代码跑不通怎么办这是最高频的问题。模型生成的 CadQuery 代码经常出现几种典型错误调用了不存在的 API、参数类型不对、链式调用顺序错误。排查思路是先看报错行再对照 CadQuery 官方文档确认 API 是否存在。报错类型典型原因解决方向AttributeError调用了不存在的函数核对 CadQuery API 版本TypeError参数类型错误检查是否传了字符串而非数字ValueError几何操作无效检查尺寸是否合理Standard_Failure内核级错误检查是否自相交或退化几何我的经验是在提示词里明确给出 CadQuery 的版本和常用 API 列表能显著降低这类错误。另外让模型生成代码时加上注释说明每一步在做什么出问题时更容易定位。5.2 URDF 导入仿真环境报错把 URDF 导入 CoppeliaSim 时最常见的三个报错是mesh 文件找不到、关节类型不支持、惯性矩阵无效。mesh 路径问题一般是相对路径和绝对路径没搞对建议在 URDF 里用相对路径并把 STL 和 URDF 放在同一目录下。关节类型方面CoppeliaSim 对 continuous 和 revolute 支持较好prismatic 也没问题但 floating 关节有时会出问题。惯性矩阵无效通常是因为质量或转动惯量设成了零仿真器会直接拒绝加载。提示URDF 里的单位是米而 CAD 建模常用毫米导出 STL 时记得做单位换算否则模型会大一千倍或小一千倍。5.3 批量生成时的性能问题当你要生成几百个模型时性能会成为瓶颈。CadQuery 每次建模都要初始化内核频繁调用开销很大。优化办法是把建模逻辑放在一个进程里复用而不是每个模型起一个新进程。另外导出 STEP 比导出 STL 慢很多如果只是做可视化预览可以先导 STL最终确认后再导 STEP。5.4 参数抽取的边界情况有些描述天然模糊比如一个差不多 50 毫米的方块差不多这种词模型没法处理。还有标准 M8 螺栓这种依赖标准库的描述需要你预先准备好标准件参数表。我的做法是维护一个常用标准件的参数字典遇到标准件名称直接查表不走模型解析这样既快又准。6. 影响范围与延伸思考text-to-cad 这套思路的影响面其实比表面看起来要广。在机械设计领域它能把标准件和常用结构的建模时间从几分钟压缩到几秒在机器人领域它能加速仿真模型的搭建让算法验证不再卡在模型准备上在建筑和电气领域参数化的盘扣节点、桥架、管线支架都可以用类似思路批量生成。但也要清醒地看到它的边界。text-to-cad 擅长的是参数化、模式化的几何对于自由曲面、复杂装配、需要工程判断的设计它目前还替代不了人。它的定位应该是建模助手而不是建模替代者。你把重复劳动交给它把创造性判断留给自己这才是合理的用法。从技术演进的角度看这条路线的下一个突破点可能在几何推理能力上。现在的模型能理解圆柱和方板但对这个零件要能承受 500 牛的拉力这类功能性描述还无能为力。等哪天模型能把功能需求翻译成几何约束text-to-cad 才算真正成熟。在那之前把参数化模板和自然语言解析结合好已经能解决相当一部分实际问题了。我在实际项目里用得最多的组合是标准件走模板查表非标件走代码生成两者用同一套参数校验和几何验证兜底。这套组合跑下来建模效率大概能提升三到五倍出错率也比纯手工低。如果你刚开始尝试建议先从模板路线入手把流程跑通再逐步引入代码生成这样踩的坑会少很多。