1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 “text-to-cad” 这个词很多人脑子里浮现的画面大概是对着电脑说一句“给我画个法兰盘”屏幕上就自动蹦出一个带倒角和螺栓孔的 STEP 模型。这个想象不算离谱但也不完全准确。我做了几年参数化建模和自动化脚本实际接触下来text-to-cad 的本质不是“语音控制 CAD”而是把自然语言描述转译成可编辑、可制造、可仿真的几何数据。它要打通的是从“人话”到“机器能读的几何语言”之间那条最费劲的沟。这条沟有多宽你让一个刚学 CAD 的人画一个“外径 80、内径 40、厚 10 的圆环”他得先想用哪个命令、选哪个基准面、拉伸还是旋转、要不要打孔。而 text-to-cad 想做的是让这段描述直接变成一段脚本或者一个模型文件。它解决的核心问题有三个降低重复建模的时间成本、让非专业用户也能产出几何数据、把文本描述变成可版本管理的工程资产。适合谁来参考如果你经常需要批量生成标准件、做参数化设计、或者想把设计意图用文字沉淀下来那这套思路对你就有用。我最早接触类似需求是在做一批非标支架的时候。客户给了一张 Excel里面几十行尺寸描述每行对应一个支架。手动建模要两天写脚本生成只要半小时。那时候我就意识到text-to-cad 不是一个炫技的概念而是一个实打实的效率工具。它背后的关键词——CAD、STEP、URDF、G-code——其实代表了四个不同的输出方向通用交换格式、机器人仿真格式、加工制造格式。理解这四个词基本就理解了 text-to-cad 的整个应用版图。提示text-to-cad 不是要取代 CAD 工程师而是把工程师从重复劳动里解放出来去做真正需要判断力的设计决策。2. 核心思路拆解文本怎么变成几何2.1 三种主流技术路线对比把文本变成 CAD 模型目前能走通的路子大致分三类我按落地难度和适用场景排了个序。路线核心原理优点缺点适合场景规则解析 脚本生成用正则或语法树解析文本映射到 CAD 脚本命令可控性强、结果精确、易调试只能处理结构化描述标准件批量生成大模型 代码生成让语言模型输出建模脚本灵活、能处理模糊描述结果不稳定、需要校验快速原型、概念设计大模型 几何内核模型直接输出几何参数或网格端到端、门槛低精度差、难编辑可视化展示、初步示意我个人的经验是规则解析加脚本生成是目前最稳的方案。原因很简单工程领域对精度的要求是刚性的一个孔位偏 0.5 毫米装配就废了。大模型生成的代码看起来很聪明但它经常在尺寸链上犯低级错误比如把半径当直径、把内径外径搞反。所以我的做法通常是用大模型做“翻译”把自然语言转成结构化的中间表示再用确定性脚本去生成几何。这样既保留了灵活性又保证了精度。2.2 为什么选脚本而不是直接操作 CAD 界面有人会问为什么不直接写个插件去点 CAD 的按钮我试过结论是界面操作适合人不适合程序。CAD 软件的 UI 是为鼠标和键盘设计的程序去模拟点击速度慢、容易出错、还依赖窗口焦点。而脚本接口是专门给程序用的稳定、快、可批量。以 FreeCAD 为例它的 Python API 可以直接创建几何体、布尔运算、导出文件全程不需要打开界面。这种“无头模式”才是自动化的正确姿势。另一个关键考量是可复现性。界面操作的过程很难记录你今天点了一遍明天可能就忘了顺序。而脚本本身就是文档改一个参数就能重新生成还能用 Git 管理版本。我现在的习惯是任何一个需要重复三次以上的建模任务我都会写成脚本。text-to-cad 只是把这个习惯往前推了一步连脚本都不用写用文字描述就行。2.3 输出格式的选择逻辑text-to-cad 生成什么格式取决于你要拿它干什么。STEP 是通用交换格式几乎所有 CAD 软件都能读适合做设计交付。URDF 是机器人描述格式带关节和连杆信息适合做仿真。G-code 是加工指令直接驱动机床适合做制造。STL 是网格格式适合 3D 打印和渲染。我一般会同时导出 STEP 和 STL。STEP 用来存档和后续编辑STL 用来快速预览和打印。如果涉及机器人仿真再额外导出 URDF。这里有个坑STEP 和 STL 的精度差异很大。STL 是三角面片逼近曲面会有棱角感而 STEP 是精确的边界表示。所以如果你要加工千万别拿 STL 去出工程图尺寸对不上。3. 实操环境搭建从零开始跑通第一条链路3.1 工具选型与安装避坑我推荐的工具组合是Python FreeCAD CadQuery。FreeCAD 是开源 CAD有完整的 Python APICadQuery 是建立在 OpenCASCADE 之上的建模库语法更简洁适合做参数化生成。安装这块我踩过的坑比想象的多。FreeCAD 的安装Windows 上直接下安装包就行但要注意版本。0.20 和 0.21 的 API 有些差异建议用 0.21 以上。安装过程中如果遇到 C 运行库报错比如提示缺少 2005 或 2015 的 redistributable去微软官网下对应的运行库装上就行。这不是 CAD 的问题是系统缺组件。另外安装路径不要有中文和空格否则 Python 导入模块时可能找不到路径。CadQuery 的安装更简单一条命令pip install cadquery但如果你用的是 Anaconda建议新建一个虚拟环境因为 CadQuery 依赖的 OCP 库和某些科学计算库有版本冲突。我试过在 base 环境里直接装结果 numpy 被降级其他项目跑不了。所以conda create -n text2cad python3.10 conda activate text2cad pip install cadqueryPython 版本选 3.10 是因为 3.11 和 3.12 在某些依赖上还没有预编译包装起来会编译源码很慢。3.10 是目前的甜点版本。3.2 第一个 text-to-cad 脚本从描述到 STEP假设我们要生成一个简单的法兰盘描述是“外径 100内径 50厚度 10中心圆孔直径 30四个螺栓孔直径 8分布在直径 80 的圆上。”用 CadQuery 写出来是这样的import cadquery as cq # 参数定义 outer_dia 100 inner_dia 50 thickness 10 center_hole_dia 30 bolt_hole_dia 8 bolt_circle_dia 80 bolt_count 4 # 创建基础圆环 result ( cq.Workplane(XY) .circle(outer_dia / 2) .circle(inner_dia / 2) .extrude(thickness) ) # 打中心孔 result result.faces(Z).workplane().hole(center_hole_dia) # 打螺栓孔 import math for i in range(bolt_count): angle 2 * math.pi * i / bolt_count x (bolt_circle_dia / 2) * math.cos(angle) y (bolt_circle_dia / 2) * math.sin(angle) result result.faces(Z).workplane().center(x, y).hole(bolt_hole_dia) # 导出 cq.exporters.export(result, flange.step) cq.exporters.export(result, flange.stl)这段代码跑完你会得到两个文件。STEP 可以用任何 CAD 软件打开STL 可以拖进切片软件。整个过程不需要打开任何图形界面纯命令行完成。3.3 文本解析层的实现上面那段代码还是手写的。text-to-cad 的关键一步是把“外径 100内径 50”这样的文字自动变成变量。我用的方法是用正则表达式提取“关键词 数字”的组合。比如import re text 外径 100内径 50厚度 10中心圆孔直径 30四个螺栓孔直径 8分布在直径 80 的圆上 patterns { outer_dia: r外径\s*(\d\.?\d*), inner_dia: r内径\s*(\d\.?\d*), thickness: r厚度\s*(\d\.?\d*), center_hole_dia: r中心圆孔直径\s*(\d\.?\d*), bolt_hole_dia: r螺栓孔直径\s*(\d\.?\d*), bolt_circle_dia: r直径\s*(\d\.?\d*)\s*的圆, bolt_count: r([一二三四五六七八九十\d])个螺栓孔 } params {} for key, pattern in patterns.items(): match re.search(pattern, text) if match: params[key] float(match.group(1)) print(params)中文数字“四”需要额外转换可以写个映射表。这个方案看起来笨但准确率比大模型高得多。我实测过对于结构化的描述正则的准确率接近 100%而大模型大概在 70% 左右剩下的 30% 需要人工校验反而更费时间。注意正则解析的前提是描述格式相对固定。如果用户输入天马行空还是得靠大模型做兜底但一定要加校验层。4. 进阶应用URDF 与 G-code 的生成逻辑4.1 从 CAD 到 URDF机器人仿真的桥梁URDF 是机器人领域描述连杆和关节的格式。如果你想让一个机械臂在仿真环境里动起来就需要 URDF。text-to-cad 在这里的价值是用文字描述机械臂的连杆尺寸和关节位置自动生成 URDF 文件。我做过一个三自由度机械臂的案例。描述是“底座直径 100高 50大臂长 200宽 40厚 30小臂长 150宽 30厚 20末端执行器长 50。” 生成 URDF 的核心是定义 link 和 joint。每个 link 对应一个几何体每个 joint 定义旋转轴和父子关系。这里有个容易忽略的点URDF 的坐标系原点和 CAD 的建模原点往往不一致。CAD 里你可能习惯把底座放在原点但 URDF 要求每个 link 的坐标系在关节处。所以生成 URDF 时需要做一次坐标变换。我的做法是在 CAD 里就把每个零件的坐标系建在关节位置这样导出时直接对应省去换算。URDF 导入 CoppeliaSim 的时候常见问题是惯性矩阵缺失。URDF 里如果不定义 inertial 标签仿真引擎会默认一个很小的质量导致机械臂抖动或者飞出去。所以生成 URDF 时一定要根据几何体积和材料密度算出质量和惯性张量。这个计算不难但很容易忘。4.2 G-code 生成从模型到加工指令G-code 是数控机床能读的指令。text-to-cad 生成 G-code 的路径通常是文本描述 → CAD 模型 → CAM 刀路 → G-code。中间多了 CAM 这一步因为刀路规划涉及刀具选择、进给速度、切削深度等工艺参数不是纯几何问题。我一般用 FreeCAD 的 Path 工作台做这件事。它的 Python API 可以创建铣削刀路然后导出 G-code。关键参数包括刀具直径、主轴转速、进给率、每层切深。这些参数如果让大模型猜基本不靠谱。我的做法是建一个工艺参数库根据材料铝、钢、塑料和刀具类型自动匹配。# 伪代码示意 material aluminum tool_dia 6.0 params process_db[material][tool_dia] # params 包含 spindle_speed, feed_rate, step_down生成的 G-code 一定要在仿真里跑一遍再上机床。我见过有人直接拿生成的代码去切结果撞刀了。仿真能发现大部分干涉问题但切削力、排屑这些物理因素仿真也模拟不了只能靠经验。4.3 批量生成与参数化变体text-to-cad 真正体现效率的地方是批量生成。比如你有 50 个不同尺寸的法兰盘描述存在 Excel 里。你可以写个循环读一行生成一个模型自动命名保存。我做过一个项目200 多个零件从读表到出 STEP 文件总共跑了 3 分钟。手动建模的话至少两天。批量生成的关键是命名规范和错误处理。文件名要包含关键参数方便后续检索。错误处理要记录哪一行失败了、失败原因是什么而不是整个脚本崩掉。我通常用 try-except 包住每个零件的生成逻辑失败的记录到日志里最后统一处理。5. 常见问题与排查技巧实录5.1 模型生成失败的典型原因问题现象可能原因排查方法解决方案脚本报错找不到模块Python 环境不对检查 sys.path 和 pip list用虚拟环境确认 CadQuery 已安装生成的模型是空壳布尔运算顺序错误在 FreeCAD 里手动复现先做差集再做并集注意对象顺序STEP 文件打不开导出时几何无效用 FreeCAD 的检查工具修复几何或降低精度重新导出尺寸偏差大单位混淆检查输入单位统一用毫米避免英寸混入螺栓孔位置不对角度计算错误打印坐标值确认角度用弧度还是角度5.2 精度与性能的平衡CadQuery 生成复杂模型时如果倒角、圆角很多速度会明显变慢。我试过一个带 50 个圆角的零件生成时间从 2 秒涨到 40 秒。优化方法是减少不必要的圆角或者在导出前再统一加圆角。另外布尔运算的次数也要控制能合并的合并能一次成型的不要分多次。还有一个坑是网格精度。导出 STL 时可以设置公差公差越小文件越大。我一般用 0.01 毫米的公差兼顾精度和文件大小。如果只是预览0.1 毫米就够了。5.3 与现有 CAD 工作流的衔接text-to-cad 生成的模型最终还是要回到 CAD 里做细化。我的做法是脚本生成基础几何导出 STEP然后在 CAD 里做倒角、打标、出工程图。这样分工明确脚本做重复的部分人做需要判断的部分。如果你用的是中望 CAD 或者 AutoCAD它们也支持脚本和插件。AutoCAD 的 AutoLISP 和 .NET API 都能做类似的事。但跨平台性不如 Python FreeCAD 组合。我选 FreeCAD 还有一个原因是它免费开源不用担心授权问题团队里每个人都能装。提示生成的 STEP 文件在导入其他 CAD 时可能会丢失特征树变成一个死实体。这是正常现象STEP 是交换格式不保留建模历史。如果需要保留特征得用原生格式。6. 我在这条路上踩过的几个坑第一个坑是过度依赖大模型。刚开始我试过让 GPT 直接生成 CadQuery 代码结果十次有三次跑不通还有两次尺寸错了。后来改成“大模型解析文本 规则生成代码”稳定性才上来。大模型适合做模糊匹配和意图理解不适合做精确计算。第二个坑是忽略单位。有一次客户给的描述是英寸我默认按毫米处理结果模型大了 25 倍。从那以后我在解析层加了一个单位识别看到 inch、英寸、 就自动换算。第三个坑是文件管理混乱。批量生成几百个文件如果没有命名规范根本找不到谁是谁。我现在的命名格式是零件类型_关键尺寸_版本.step比如flange_OD100_ID50_v2.step。配合 Git 做版本管理改了什么一目了然。第四个坑是忘了做几何校验。生成的模型有时候会有自相交或者零厚度的问题肉眼看不出来但导入仿真或加工时会报错。我后来加了一步自动校验用 FreeCAD 的isValid()方法检查不通过的就标记出来人工处理。这套流程跑顺之后我现在接到批量建模的需求第一反应不再是打开 CAD而是先想想能不能用文字描述清楚。能描述清楚就能自动生成。text-to-cad 对我来说已经从一个新鲜概念变成了日常工具。它不完美但在合适的场景下确实能省下大量时间。如果你也在做重复性高的建模工作不妨从一个小零件开始试试跑通一条链路之后后面的扩展就顺理成章了。