1. 从一段文字到三维模型text-to-cad 到底在解决什么问题第一次听到 “text-to-cad” 这个词我脑子里蹦出来的画面是对着电脑敲一句“给我画一个长宽高 100×60×30 毫米、四角带 M4 沉头孔的法兰底座”然后软件自己把三维模型建好顺手导出 STEP 和 STL。这个画面在几年前还属于科幻范畴但现在已经有一批工具和方案在往这个方向走了。所谓 text-to-cad直译就是“文本转 CAD”核心逻辑是把自然语言描述或者结构化文本自动转换成计算机辅助设计CAD能识别的几何模型最终输出 STEP、GLB、STL 这类通用格式。这件事的价值在哪儿我举个实际场景。做非标自动化设备的朋友应该深有体会客户发来一段文字需求比如“一个 200×150 的铝型材安装板中间开 80 的圆孔四角各一个 6.5 的通孔”从读懂需求到在 CAD 里画完、标注、导出熟手也要十几二十分钟。如果一天来二十个这种小件光建模就能吃掉大半天。text-to-cad 想干的事就是把这十几分钟压缩到几秒钟让工程师把精力放在真正需要判断力的结构设计和装配关系上而不是重复性的拉伸打孔。它适合谁我梳理了三类人。第一类是机械、钣金、建筑领域的工程师日常有大量标准化、参数化的零件要建text-to-cad 能当效率放大器用。第二类是做 3D 打印、手办、文创的玩家脑子里有个形状但不会用 CAD 软件用文字描述生成 STL 直接打印门槛一下子降下来了。第三类是搞 AI 应用开发的程序员想在自己的产品里集成“文字生成模型”的能力需要搞清楚 STEP、GLB、STL 这些格式怎么选、怎么转、怎么落地。需要先泼一盆冷水目前的 text-to-cad 远没到“说人话就能出工程图”的程度。它擅长的是参数明确、结构规整的零件比如法兰、支架、齿轮毛坯、安装板遇到复杂曲面、自由造型、装配体还是得靠人。但即便只覆盖这一部分场景对效率的提升也是实打实的。下面我按自己踩过的坑和跑通的流程把这件事拆开讲透。2. 核心思路拆解文本怎么变成几何体2.1 三种主流技术路线各自适合什么场景text-to-cad 不是单一技术而是一类方案的统称。我把它归成三条路线每条路线的成熟度和适用面差别很大。第一条是参数化脚本生成。思路最朴素把自然语言解析成一组参数然后调用 CAD 软件的脚本接口比如 FreeCAD 的 Python API、OpenSCAD 的脚本语言去建模。比如你说“直径 50、高 30 的圆柱”系统提取出diameter50, height30然后执行cylinder(d50, h30)。这条路线的优点是结果精确可控导出的 STEP 是真正的 B-rep 实体能直接进 CAM 加工。缺点是能表达的形体有限基本局限在拉伸、旋转、打孔、倒角这些规则操作。第二条是代码生成路线。让大语言模型直接写 CAD 脚本代码比如生成一段 OpenSCAD 或 CadQuery 的 Python 代码运行后得到模型。这条路灵活度高因为代码能表达复杂逻辑比如阵列、循环、条件判断。我实测下来让模型写 CadQuery 代码建一个带加强筋的支架成功率比直接生成几何体高不少。但风险也明显代码可能报错、可能几何自交、可能尺寸单位搞错需要一套校验机制兜底。第三条是神经几何生成。用深度学习模型直接输出网格或隐式场代表工作是各种 text-to-3D 模型。这条路能生成有机曲面、艺术造型视觉效果好但输出的往往是三角网格mesh精度和可编辑性差很难转成工程用的 STEP。做概念展示、游戏资产、3D 打印摆件可以做机械零件不行。我的建议是工程用途优先走前两条创意造型才考虑第三条。下面重点讲前两条怎么落地。2.2 为什么 STEP、GLB、STL 要分清楚热词里 STEP、GLB、STL 反复出现这三个格式的区别必须搞明白否则做出来的东西没法用。格式本质精度可编辑性典型用途STEPB-rep 实体边界表示精确数学曲面高可参数化编辑机械加工、工程交付STL三角网格近似有弦高误差低只能整体缩放3D 打印、快速预览GLB三角网格 材质近似低偏渲染网页展示、AR/VR关键点在于STEP 是“真”模型STL 和 GLB 是“壳”。一个圆柱在 STEP 里是一个数学上精确的圆柱面在 STL 里是几十上百个三角形拼出来的近似。所以如果你要拿去 CNC 加工必须给 STEP如果只是 3D 打印看个形状STL 够用如果要在网页里转着看GLB 最合适因为它自带材质和光照信息加载快。text-to-cad 工具的输出格式选择直接决定了它能用在哪个环节。我见过不少人用 text-to-3D 生成的 STL 去报价加工结果被工厂打回来因为网格模型没法直接生成刀路。这个坑一定要提前避开。2.3 文本解析这一环才是真正的难点很多人以为 text-to-cad 的难点在建模其实难在把一句话准确翻译成参数。自然语言太灵活了“打个孔”“开个洞”“钻个眼”是一个意思“四角各一个”和“四个角分别布置”也是同一个需求。更麻烦的是隐含信息比如“M4 沉头孔”懂行的人知道这意味着通孔直径约 4.5 毫米、沉头直径约 8 毫米、沉头角度 90 度但模型不一定知道。所以一个靠谱的 text-to-cad 流程文本解析层通常要做三件事实体识别识别出“板”“孔”“槽”这些几何特征、参数抽取把数字和单位绑定到对应特征、约束补全根据行业常识补上默认值。第三件事最考验功力也是区分“玩具”和“工具”的分水岭。我的做法是维护一个特征-参数映射表把常见特征的默认参数固化下来模型解析不出来的部分就用默认值兜底同时给用户一个确认和修改的界面。3. 实操落地从一句话到可用的 STEP 文件3.1 环境准备与工具选型要跑通一条 text-to-cad 流水线我推荐的技术栈是这样的Python 做胶水层CadQuery 做几何内核大语言模型做文本解析FreeCAD 做格式转换和校验。为什么选 CadQuery 而不是 OpenSCAD因为 CadQuery 基于 OCCT 内核输出的是真正的 B-rep 实体能直接导出 STEP而 OpenSCAD 本质是网格建模导 STEP 要经过转换精度会损失。安装这块CadQuery 用 conda 装最省心conda create -n text2cad python3.10 conda activate text2cad conda install -c conda-forge cadquery pip install openaiFreeCAD 建议装 0.21 以上版本命令行模式可以用来做批量格式转换。如果你只是想在本地快速验证也可以直接用 CadQuery 自带的导出功能不一定非要 FreeCAD。注意CadQuery 对 Python 版本比较挑3.10 和 3.11 最稳3.12 有些依赖还没跟上。我踩过一次坑用 3.12 装了半天 OCCT 编译不过换回 3.10 五分钟搞定。3.2 文本解析层的实现细节文本解析我分成两步走。第一步用大语言模型把自然语言转成结构化 JSON第二步用规则引擎把 JSON 映射成 CadQuery 代码。为什么不直接让模型写代码因为直接写代码出错率高而且错误信息对用户不友好。中间加一层 JSON既能校验参数又方便做可视化确认。给模型的提示词我打磨了好几版核心是限定输出格式 提供特征词典。比如prompt 你是一个 CAD 参数解析器。把用户描述转成 JSON只输出 JSON不要解释。 支持的几何特征box(长方体), cylinder(圆柱), hole(孔), slot(槽), fillet(圆角)。 每个特征包含 type 和 params 字段。单位统一用毫米。 示例输入一个 100x60x10 的板四角各一个直径 5 的通孔 示例输出 { base: {type: box, params: {length: 100, width: 60, height: 10}}, features: [ {type: hole, params: {diameter: 5, positions: [[5,5],[95,5],[5,55],[95,55]]}} ] } 用户输入{user_input} 这里有个细节孔的位置我让模型直接算好坐标而不是说“四角”。因为“四角”到坐标的转换涉及边距边距取多少是个工程习惯问题一般取孔径的 1.5 到 2 倍。我在提示词里明确要求模型按“孔中心距边缘 孔径 × 1.5”来算这样出来的结果符合大多数加工习惯。3.3 从 JSON 到 CadQuery 代码的映射拿到 JSON 后映射逻辑其实很直白就是一层翻译。我写了一个build_model函数核心结构如下import cadquery as cq def build_model(spec): base spec[base] if base[type] box: p base[params] model cq.Workplane(XY).box(p[length], p[width], p[height]) elif base[type] cylinder: p base[params] model cq.Workplane(XY).circle(p[diameter]/2).extrude(p[height]) for feat in spec.get(features, []): if feat[type] hole: d feat[params][diameter] for pos in feat[params][positions]: model model.faces(Z).workplane().pushPoints([pos]).hole(d) elif feat[type] fillet: r feat[params][radius] model model.edges(|Z).fillet(r) return model这段代码里有个容易翻车的地方faces(Z)选的是 Z 方向最高的面如果模型被旋转过或者有多个面选面逻辑就会出错。我的经验是在打孔前先把工作平面显式固定不要依赖自动选面。另外hole()默认是通孔如果要盲孔得用cboreHole或手动cutBlind。3.4 导出与格式转换的完整命令模型建好后导出 STEP 就一行cq.exporters.export(model, output.step)导出 STL 需要指定精度这个参数很关键cq.exporters.export(model, output.stl, tolerance0.01, angularTolerance0.1)tolerance是弦高误差单位毫米0.01 意味着曲面被离散成三角形时误差不超过 0.01 毫米。这个值越小STL 越精细文件也越大。做 3D 打印一般 0.05 到 0.1 够用做精细装配验证建议 0.01。angularTolerance控制角度误差默认 0.1 弧度一般不用改。如果要 GLBCadQuery 本身不支持得走 FreeCAD 或者 trimesh 中转。我的做法是先导 STL再用 trimesh 转 GLBimport trimesh mesh trimesh.load(output.stl) mesh.export(output.glb)提示STL 转 GLB 是无损的因为两者都是网格。但 STEP 转 STL 是有损的转之前想清楚精度要求。我一般会同时保留 STEP 和 STL 两个版本STEP 存档STL 用于预览和打印。4. 常见问题与排查技巧实录4.1 模型生成失败或几何异常怎么查text-to-cad 最让人抓狂的就是模型看起来生成了但一打开发现是空文件或者实体自交、面缺失。我整理了一张排查表按出现频率排序现象可能原因排查方法解决手段导出文件为空模型未闭合或布尔运算失败用model.val().isValid()检查检查打孔位置是否在实体外孔打歪或没打穿工作平面选错打印model.faces().size()显式指定工作平面STEP 打开报错单位不一致检查是否混用 mm 和 inch统一在建模前设单位STL 文件巨大精度设太高看文件大小调大 tolerance圆角失败圆角半径大于相邻边减小半径试分步倒角我遇到最多的是布尔运算失败。CadQuery 底层是 OCCTOCCT 对布尔运算的容差很敏感。如果两个实体只是刚好相切运算就可能失败。解决办法是让相交部分有明确的重叠比如打孔时孔的深度比板厚多 1 毫米确保切穿。4.2 文本描述歧义导致的返工自然语言的歧义是另一个大坑。用户说“一个 100 的板”这个 100 是长、宽还是对角线说“中间开孔”中间是几何中心还是视觉中心我的处理原则是能问就问不能问就按最常见惯例来并在输出时标注假设。具体做法是在解析结果里加一个assumptions字段把系统做的默认假设列出来比如“假设 100 为长度宽度默认取长度的 0.6 倍”“假设孔位于几何中心”。用户看到这些假设如果不对可以直接改 JSON比重新描述一遍快得多。这个设计我用了半年返工率明显下降。4.3 格式转换中的精度损失STEP 转 STL 的精度损失是物理上不可避免的但可以控制。核心参数就是弦高误差。我做过一组对比测试一个直径 50 的圆柱tolerance 设 0.1 时STL 的直径实测 49.92 毫米误差 0.08设 0.01 时实测 49.99误差 0.01。所以如果 STL 要用于配合验证tolerance 至少 0.01。另一个容易被忽略的是法线方向。有些转换工具导出的 STL 法线朝内3D 打印机切片时会识别成反面。检查方法是看文件大小和用网格查看器看颜色如果整体显示为暗色多半是法线反了。trimesh 里可以用mesh.fix_normals()修复。4.4 批量处理的性能优化单件生成几秒钟能接受但如果要批量处理几百个零件性能就成了问题。我的优化经验有三条。第一复用 CadQuery 的 Workplane 对象不要每次重新 importimport 一次的开销比建模还大。第二并行用多进程而不是多线程因为 OCCT 的运算释放 GIL 不彻底多线程反而慢。第三把文本解析和几何生成分离解析可以批量调 API几何生成在本地跑避免网络往返拖慢整体速度。实测下来单进程生成一个中等复杂度零件约 1.5 秒用 8 进程并行处理 100 个零件总耗时从 150 秒降到 25 秒左右提速约 6 倍。5. 这套方案还能怎么扩展跑通基础流程后我陆续加了几个扩展实用性提升不少。一个是参数化模板库把法兰、支架、齿轮这些高频零件做成模板用户只需要填几个关键尺寸不用每次从零描述。另一个是版本对比每次生成的 STEP 存一份用哈希值比对方便追溯设计变更。还有一个是与 3D 打印切片软件联动生成 STL 后自动调切片命令直接出 G-code省去手动导入的步骤。这些扩展的共同思路是把 text-to-cad 当成流水线的一环而不是孤立的工具。它上游接需求描述下游接加工或打印中间还能接仿真和报价。想清楚它在整个链条里的位置才知道该往哪个方向优化。我个人在实际操作中的体会是text-to-cad 目前最靠谱的用法是处理“有明确参数、结构规整”的零件把它当成一个不知疲倦的建模助手而不是替代工程师的万能工具。遇到复杂装配和自由曲面老老实实打开 CAD 软件手动建效率反而更高。把工具用在它擅长的地方这才是提效的关键。