1. 从一段文字到三维模型text-to-cad 到底在解决什么问题第一次听到 “text-to-cad” 这个词很多人脑子里浮现的画面大概是对着电脑敲一句“给我画一个长宽高 100×60×30 的带孔法兰盘”然后 CAD 软件里就自动蹦出一个可以旋转查看的三维实体。这个理解方向没错但只对了一半。text-to-cad 真正要解决的不是“偷懒不画图”而是把自然语言描述和参数化几何模型之间那道长期存在的鸿沟给填上。传统 CAD 工作流是这样的你脑子里有一个零件的形状先把它翻译成尺寸、约束、特征顺序再用手在软件里一步步拉伸、切除、倒角、打孔。这个过程中真正花时间的往往不是“画”而是“想清楚怎么画”——也就是把设计意图转译成建模操作序列。text-to-cad 想做的就是让机器替你完成这层转译你负责说清楚“要什么”它负责生成“怎么建”。从热搜词能看出来围绕 CAD 的讨论集中在几个方向安装与卸载cad安装、cad如何彻底卸载不影响二次安装、格式转换cad转pdf、cad图纸合并、二次开发python批量对cad修改、cad插件、以及跨工具协同urdf导入coppeliasim、cad导入layout步骤详解。这些热词背后其实指向同一个痛点CAD 数据在不同环节之间的流转成本太高。text-to-cad 如果只停留在“生成一个模型”价值有限它真正的想象空间在于生成的结果能直接对接下游——导出 STEP 用于加工、导出 URDF 用于机器人仿真、导出 G-code 用于数控加工。所以这篇文章适合谁看如果你是机械设计工程师想了解怎么用自然语言快速出草图方案如果你是机器人方向的学生或从业者需要频繁在 CAD 和仿真环境之间倒腾模型如果你是做二次开发的程序员想找一个能批量生成参数化模型的入口——那这篇内容应该能给你一些可以直接上手的东西。我会从整体设计思路讲起然后拆到核心细节、实操流程、常见坑尽量把“为什么这么做”说透而不是只丢一堆命令。2. 整体设计思路为什么 text-to-cad 不是“语音控制 CAD”2.1 核心矛盾自然语言的模糊性 vs 几何的精确性自然语言天生是模糊的。“一个差不多这么大的板子”在人看来可以理解但 CAD 内核需要的是精确的数值和拓扑关系。text-to-cad 的第一个设计决策就是在哪一层做“翻译”。目前主流思路有三条路线。第一条是端到端生成用大模型直接输出几何表示比如点云、网格或者隐式场。这条路听起来最酷但问题也很明显——生成结果不可参数化改一个尺寸就得重新生成而且精度很难保证到丝级。第二条是代码生成让模型输出建模脚本比如 CadQuery、OpenSCAD 或者 FreeCAD 的 Python 脚本。这条路的好处是结果完全参数化、可复现、可版本管理缺点是模型得懂建模 API。第三条是特征序列生成输出一串类似“拉伸 50mm、打孔直径 10mm、阵列 4 个”的结构化指令再由后端解释执行。从实际落地角度看代码生成路线是目前最稳的。原因很简单CAD 的本质是参数化特征历史而代码天然就是参数化的。你让模型写一段 CadQuery 脚本它生成的每一个尺寸都是变量改起来方便导出 STEP 也顺理成章。后面讲的实操也主要围绕这条路线展开。2.2 为什么选 CadQuery 而不是直接操作商业 CAD有人会问为什么不直接让模型去操作 SolidWorks 或者中望 CAD 的 API理论上可以但实际很别扭。商业 CAD 的 API 通常绑定特定版本、需要授权、跨平台差而且调试成本高。CadQuery 是基于 OpenCASCADE 的 Python 建模库开源、跨平台、API 干净生成的模型可以直接导出 STEP、STL、DXF 等格式。对于 text-to-cad 这种需要快速迭代的场景CadQuery 的“代码即模型”特性几乎是量身定做的。更重要的是CadQuery 的脚本本身就是一份可读的设计文档。你拿到一段生成的代码能一眼看出哪里是长度、哪里是孔径、哪里做了倒角。这种透明度在工程场景里比“黑盒生成一个网格”有价值得多。2.3 整体架构从文本到可加工文件的链路一个完整的 text-to-cad 流程大致分四层。第一层是意图解析把用户输入的自然语言拆成结构化字段比如零件类型、关键尺寸、特征列表、材料或工艺约束。第二层是代码生成根据结构化字段调用大模型生成 CadQuery 脚本。第三层是执行与校验在沙箱里跑脚本检查是否报错、几何是否有效、尺寸是否落在合理范围。第四层是导出与对接根据下游需求导出 STEP、URDF 或 G-code。这四层里最容易出问题的是第二层和第三层之间的衔接。模型生成的代码经常“看起来对但跑不通”比如引用了不存在的 API、单位搞混、布尔运算顺序导致空集。所以校验环节不能省而且校验规则要尽量具体。3. 核心细节解析把“一句话”拆成可执行的建模指令3.1 意图解析先定义好“槽位”再让模型填直接让大模型“根据这句话生成 CAD 代码”结果往往不稳定。更可靠的做法是先定义一套槽位slot让模型做信息抽取再基于槽位生成代码。以“一个 100×60×10 的底板四角各有一个直径 6 的通孔孔中心距边 10mm”为例抽取结果大概是零件类型板类零件外形尺寸长 100、宽 60、厚 10特征列表四角通孔直径 6边距 10单位毫米这套槽位不需要很复杂但必须覆盖常见零件的基本要素。槽位定义得越清晰后续代码生成的确定性就越高。实际做的时候我会把槽位分成“必填”和“可选”两类外形尺寸和主要特征是必填倒角、圆角、材料这些是可选。如果用户没说就用默认值或者留空让后端补。3.2 代码生成给模型一个“模板 约束”的框架让模型从零写 CadQuery 脚本容易出现 API 幻觉。更稳的方式是给它一个模板骨架让它只填关键部分。比如下面这个底板模板import cadquery as cq # 参数区 length 100.0 width 60.0 thickness 10.0 hole_dia 6.0 edge_offset 10.0 # 建模 result ( cq.Workplane(XY) .box(length, width, thickness) .faces(Z) .workplane() .rect(length - 2 * edge_offset, width - 2 * edge_offset, forConstructionTrue) .vertices() .hole(hole_dia) ) # 导出 cq.exporters.export(result, plate.step)模型要做的就是把参数区的数值替换成用户给的必要时调整特征顺序。这种“模板 参数填充”的方式比完全自由生成稳定得多。模板可以按零件类型分类板类、轴类、法兰类、支架类每类一个骨架。3.3 单位与坐标系最容易被忽略但最致命CAD 里单位搞错后果是灾难性的。一个“直径 10”的孔如果被当成米那就是 10 米模型直接废掉。所以在意图解析阶段就要强制统一单位默认毫米如果用户说了“厘米”或“英寸”在进入代码生成前就换算好。坐标系也一样默认 Z 轴向上、XY 平面为基准面这样导出的 STEP 在大多数下游工具里都能正确定位。提示如果你的下游是机器人仿真坐标系约定可能不同。URDF 里常用 Z 轴向上但有些仿真环境默认 Y 轴向上。导出前最好确认一下目标环境的约定避免模型“躺平”。3.4 几何有效性校验跑通不等于做对脚本能跑通不代表模型可用。常见的几何问题包括孔打在了实体外面、布尔运算产生零厚度壁、倒角半径大于相邻边长度。这些在 CadQuery 里可能不报错但导出的 STEP 在别的软件里会出问题。所以校验环节至少要检查三件事实体数量是否为 1、体积是否大于 0、包围盒尺寸是否和输入一致。如果条件允许还可以检查最小壁厚防止出现无法加工的薄壁。4. 实操过程从零搭一个可用的 text-to-cad 流水线4.1 环境准备Python CadQuery 大模型接口先装基础环境。CadQuery 推荐用 conda 装因为它的依赖链比较长pip 有时候会卡在 OpenCASCADE 的编译上。conda create -n text2cad python3.11 conda activate text2cad conda install -c conda-forge cadquery装完之后验证一下import cadquery as cq box cq.Workplane(XY).box(10, 10, 10) cq.exporters.export(box, test.step) print(ok)能导出 STEP 就说明环境没问题。接下来接大模型接口这部分看你手头有什么资源本地模型或者云端 API 都行。关键是要能稳定输出结构化文本最好支持 JSON 模式。4.2 意图解析的实现用 JSON Schema 约束输出给模型一个明确的 JSON Schema让它按格式输出。比如{ part_type: plate, dimensions: { length: 100, width: 60, thickness: 10 }, features: [ { type: hole, diameter: 6, position: four_corners, edge_offset: 10 } ], unit: mm }Schema 里把单位、尺寸、特征都定义清楚模型输出的稳定性会高很多。如果模型返回的 JSON 缺字段后端可以补默认值或者直接报错让用户补充。4.3 代码生成与执行沙箱里跑别在生产环境跑生成的代码一定要在隔离环境里执行。原因有两个一是模型可能生成死循环或者资源消耗大的操作二是安全考虑避免执行恶意代码。简单做法是用 subprocess 起一个独立进程设置超时和内存限制。import subprocess import tempfile import os code generated_code # 模型生成的 CadQuery 脚本 with tempfile.NamedTemporaryFile(modew, suffix.py, deleteFalse) as f: f.write(code) script_path f.name try: result subprocess.run( [python, script_path], capture_outputTrue, textTrue, timeout30 ) if result.returncode ! 0: print(执行失败:, result.stderr) else: print(执行成功) finally: os.unlink(script_path)超时设 30 秒对大多数零件够用了。如果经常超时可能是模型生成了过于复杂的阵列或者布尔运算需要回头优化提示词。4.4 导出 STEP对接下游加工与仿真STEP 是中性格式大多数 CAD 和 CAM 软件都能读。CadQuery 导出很简单cq.exporters.export(result, output.step)如果下游是机器人仿真需要 URDF那就得额外做一步转换。URDF 本质是描述连杆和关节的 XML不是几何格式。常见做法是把 STEP 转成 STL 或 DAE再在 URDF 里引用网格文件。这一步可以用 FreeCAD 或者 trimesh 来做。import trimesh mesh trimesh.load(output.step) mesh.export(output.stl)然后在 URDF 里写link namebase_link visual geometry mesh filenameoutput.stl/ /geometry /visual /link4.5 导出 G-code从模型到加工路径G-code 是数控加工用的text-to-cad 直接生成 G-code 不太现实因为加工路径依赖刀具、材料、机床参数。更合理的做法是生成 STEP 后导入 CAM 软件比如 FreeCAD 的 Path 工作台生成刀路。如果只是做 2.5D 的简单零件也可以用 CadQuery 导出 DXF再在 CAM 里处理。cq.exporters.export(result, output.dxf)DXF 适合板类零件的轮廓加工孔和外形都能表达。复杂曲面还是得走 STEP CAM 的路线。5. 常见问题与排查技巧实录5.1 模型生成的代码跑不通怎么快速定位最常见的原因是 API 用错。CadQuery 的 API 在不同版本之间有变化模型可能混用了新旧写法。排查步骤先看报错行确认是哪个方法不存在然后查 CadQuery 官方文档对应版本的签名最后把那段代码单独拎出来在 REPL 里跑。如果模型频繁出错可以在提示词里附上 CadQuery 的 API 速查表减少幻觉。5.2 导出的 STEP 在别的软件里打开是空心的这通常是布尔运算的问题。CadQuery 里如果先打孔再倒角有时候会生成非流形实体。解决办法是调整特征顺序先做外形和倒角最后打孔。另外导出前可以用result.val().isValid()检查实体有效性。5.3 URDF 导入仿真环境后模型位置不对坐标系约定不一致导致的。CAD 里默认 Z 向上有些仿真环境默认 Y 向上。解决办法是在导出 STL 前旋转模型或者在 URDF 的origin里加旋转。具体加多少取决于目标环境的约定一般是绕 X 轴转 -90 度或 90 度。5.4 批量生成时内存越跑越高如果在同一个进程里反复生成模型CadQuery 的中间对象可能没被及时回收。解决办法是每次生成都起独立子进程跑完就退出。虽然启动开销大一点但稳定性好很多。5.5 常见问题速查表问题现象可能原因排查方法解决思路脚本报 AttributeErrorAPI 版本不匹配查文档确认方法名固定 CadQuery 版本提示词附 API 表STEP 打开为空布尔运算产生空集检查实体数量和体积调整特征顺序先外形后孔模型尺寸不对单位混淆检查输入单位统一换算成毫米再生成URDF 位置偏移坐标系约定不同对比 CAD 和仿真环境轴向导出前旋转或 URDF 加 origin批量生成内存上涨对象未回收监控进程内存每次生成用独立子进程注意如果你在做批量生成建议把每次生成的输入、输出代码、导出文件都存一份日志。出问题的时候能快速回溯是哪一步偏了比重新跑一遍省时间。6. 工具选型与扩展思路text-to-cad 还能怎么玩6.1 本地模型 vs 云端接口怎么选本地模型的好处是数据不出内网适合有保密要求的场景缺点是硬件成本高推理速度慢。云端接口速度快、模型能力强但要注意数据合规。实际做的时候可以混合意图解析用云端代码生成用本地微调过的小模型。这样既保证了解析质量又控制了敏感数据的外流。6.2 从单零件到装配体下一步的扩展方向单零件生成跑通之后自然会想生成装配体。装配体的难点在于配合关系和运动约束。一个可行的思路是先生成各个零件再用规则或者模型来推断装配关系。比如“轴插入孔”这种配合可以在意图解析阶段就识别出来生成对应的 URDF joint。这块目前还没有特别成熟的方案但方向是明确的。6.3 和现有 CAD 工作流的结合点text-to-cad 不一定要取代现有流程也可以作为前置环节。比如用自然语言快速生成方案草图导出 STEP 后导入中望 CAD 或 SolidWorks 做细化。这样既享受了自然语言的效率又保留了商业 CAD 的精细编辑能力。对于做非标设计的团队这种组合能省不少前期建模时间。6.4 参数化模板库的积累模板库是 text-to-cad 的护城河。每处理一类新零件就把模板沉淀下来。时间长了常见零件类型都能覆盖生成成功率会显著提升。模板库的维护要注意版本管理每次 CadQuery 升级都要回归测试一遍。7. 我个人在实际操作中的几点体会踩过几次坑之后我最大的感受是text-to-cad 的瓶颈不在模型能力而在输入的结构化程度。你给模型的描述越接近结构化字段输出就越稳。与其花时间调提示词让模型“理解”模糊描述不如在前端做一个简单的表单让用户填尺寸和特征。自然语言是入口但不必是唯一入口。另一个体会是校验比生成更重要。生成一段代码只要几秒但一段有问题的代码流到下游排查成本可能是几小时。所以我在每个环节都加了检查点JSON 解析后检查字段完整性代码执行后检查实体有效性导出后检查文件大小和包围盒。这些检查看起来繁琐但省下的时间远超投入。最后别指望一次生成就完美。实际用下来第一版能跑通的比例大概七成剩下三成需要微调。把微调过程也自动化——比如让模型根据报错信息自我修正——能进一步提升效率。这个方向我还在试目前看小步快跑比一步到位靠谱。