ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Text-to-CAD实战:用自然语言生成可编辑参数化CAD模型

Text-to-CAD实战:用自然语言生成可编辑参数化CAD模型 最近几个月我陆续在几个机械设计社群里看到有人讨论text-to-cad这个玩法就是直接打字告诉AI“我要一个M6内六角螺栓”它就能给你生成一个可以编辑、可以出工程图、可以拿去加工的CAD模型。早期这类工具生成的多是花哨的网格雕塑好看但没法进制造流程现在这帮人做出来的东西已经能直接打开参数化特征树了。我花了两周时间把主流的几个 text-to-cad 方案都试了一遍包括 Zoo 的公开测试版、两个基于 Llama 微调的本地模型以及拿 GPT-4V 配合 OpenSCAD 手搓的偏门路子。这篇文章把我踩过的坑、总结的提示词模板、以及不同工具背后的原理差异完整写出来想上手的人可以直接照着抄作业。1. 从文本到 CAD 模型这门技术到底改变了什么先说结论文本直接生成 CAD不是要把设计师干掉而是把“从想法到可编辑参数模型”这段最烦琐的路径打通。过去从一句需求到拿到一个能改尺寸的模型至少经过概念草图、三维建模、特征调整三个环节现在第一个环节被压没了。1.1 传统建模流程的痛点我最早是用 SolidWorks 做非标设备的最熟悉的路径是这样的先画草图再拉伸、旋转、打孔、倒角最后把尺寸约束表整理好。遇到改版改一个关键尺寸后面关联的圆角和孔位经常跟着崩又要花时间修草图关系。这套流程本身没问题问题在于它把“描述需求”和“构造特征”这两件事强行绑定在同一个步骤里。你脑子里的想法其实是一句话“底板长300宽200四周四个直径8的沉头孔中间开一个40x40的方槽。”但软件听不懂这句话你得手动把它翻译成草图线和特征命令。text-to-cad 想做的就是跳过手动翻译直接让模型理解这句话并输出对应的参数化建模代码。1.2 为什么是 CAD 而不是生成 Mesh 或图片早期 AI 生成三维内容主流路径是生成三角网格Mesh比如点云重建、神经辐射场NeRF之类的输出结果是一层表面好看但改不了参数也没法直接进 CNC 加工或 3D 打印切片。CAD 的底层数据结构完全不一样它记录的是“特征历史树”比如“先拉伸一个长方体再在顶面打一个直径10的孔”。这个特征树是结构化、可编辑、可参数化的。text-to-cad 真正突破的点就在这里它让模型学会了输出这种结构化描述而不是一堆三角形顶点。打个比方Mesh 生成像是给你一张照片你能看到样子但改不了里面人物的表情。CAD 生成像是给你一份 PPT 源文件每个文本框、每张图都能双击编辑。对于制造业来说源文件才有价值。1.3 适用人群谁现在就能用上谁还要等等我实测下来最受益的是这几类人机械设计工程师做标准件、连接件、简单壳体时一句话生成基础模型再进软件微调能省一半时间。创客和硬件爱好者想要一个 Raspberry Pi 外壳不用再从零学建模软件文本生成后直接导出 STL 打印。非标自动化方案设计前期做方案对比时需要快速出概念模型不需要精确公差text-to-cad 输出的参数模型正好够用。暂时不太适合的是做复杂曲面产品的工业设计师。像汽车覆盖件、鼠标曲面这类需要 A 级曲面Class A的场合现阶段的 text-to-cad 还搞不定毕竟曲面质量和连续性不是文本能描述清楚的。2. 核心原理拆解AI 凭什么能“看懂”一句话并写出建模指令想用好这个工具不能只当黑盒。我花了不少时间读相关论文和开源代码把底层逻辑捋清楚了。说白了text-to-cad 本质上是一个“文本到代码”的生成任务只不过这个代码不是普通的 Python而是 CAD 建模指令。2.1 CAD 模型的表示方法B-rep、CSG 和特征历史要让 AI 学会生成 CAD先得让 CAD 变成 AI 能理解的数据格式。目前主流的表示方法有三种边界表示B-repBoundary Representation是目前商用 CAD 内核最常用的数据结构它用“面-边-顶点”的拓扑关系描述实体。B-rep 的好处是精确适合加工但缺点是数据格式非常复杂直接让 AI 生成 B-rep 很难因为拓扑关系稍有错误就是一个不闭合的废模型。构造实体几何CSGConstructive Solid Geometry用布尔运算组合基本体比如“长方体A 减去 圆柱体B”再把两个体做并集。CSG 表达简洁树形结构清晰很适合 AI 生成。缺点是不太好表达倒角、圆角这类操作而机械零件恰恰离不开倒角。特征历史Feature History是 SolidWorks、Fusion 360 这类参数化建模软件内部记录的操作序列比如拉伸、旋转、打孔、阵列。特征历史既有布尔运算的逻辑又保留了参数还带有顺序依赖关系是最理想的 AI 输出格式。Zoo 的 Text-to-CAD 就是走的这条路生成结果是可编辑的特征历史。2.2 把建模操作翻译成“代码语言”现在主流模型的做法是把建模 SDK 的调用封装成文本格式让大语言模型去生成这段文本。最典型的例子是 Zoo 的 Text-to-CAD它内部基于 Zoo Kit一个 Zdog 的建模内核库用类似 TypeScript 的代码描述建模操作。你输入“M8 六角螺母”模型输出的是一段代码定义了一个六棱柱和一个带内螺纹的圆柱孔再通过布尔运算合成。另一个路子是使用 OpenSCAD 作为后端。OpenSCAD 本身就是程序化建模工具它的脚本语言直接支持 CSG 运算非常适合做 AI 生成的目标。我一度用 Llama-3 微调模型直接生成 OpenSCAD 脚本配合自动语法检查和预览效果也能用只是对复杂零件的理解不如专门了训练的商业模型。从模型角度看把这些建模代码作为训练语料用海量的 CAD 模型库比如 ABC Dataset、Fusion 360 Gallery去喂 Transformer 模型。模型学到的不是“螺母长什么样”而是“构建一个可接受的螺母代码应该怎么写”。这是个非常关键的思维转换。2.3 为什么纯文本输出比直接调用 API 更靠谱可能有人会问为什么不直接让 AI 输出一个最终的三维模型文件而是绕一圈输出代码核心原因是可分步验证。代码可以检查语法、逐条执行执行到哪一步出错一目了然。而直接输出三维模型文件一旦出了问题很难定位是哪个几何操作导致的。代码是天然的可解释中间表示。另外代码可以编辑。AI 生成的模型看不懂内部结构时你可以直接改代码里的参数。这一点在实际工作中太重要了——没有哪个设计师愿意用完全无法修改的“黑盒模型”。我在验证文本生成结果时通常让模型同时输出两样东西一段建模脚本和一段自然语言描述描述里注明关键尺寸和约束关系。这样做有双重好处一方面方便复查逻辑另一方面出问题时可以快速定位是尺寸错误还是几何拓扑错误。3. 主流工具横向实测Zoo、本地开源方案和偏门组合拳这个领域发展太快我建议想用的人分三条路线去评估。我把三种方案都实测了各自的优缺点列出来方便按自己需求选型。3.1 Zoo Text-to-CAD当前最接近“能直接干活”的方案Zoo 是从前谷歌 X 实验室的团队出来的主打用 AI 生成可参数化的 CAD 模型。我测的是它的公开 alpha 版本目前免费。功能上它支持文本输入、参数化调整、导出 STEP/STL 格式。实际体验输入“a flathead M3 screw, 6mm length”这类工业描述它能生成带螺纹的模型而且螺纹不是装饰性的表面纹理是可参与装配的实体螺纹。生成速度在10到30秒之间复杂模型更慢。生成结果在浏览器里直接预览带一个简单的参数面板可以拖动调整关键尺寸。比较惊艳的点是它对机械标准件的理解度比如螺丝、螺母、垫片、导轨、法兰盘这类常见件生成的模型几何关系基本正确。但要注意它用的是自己的 Zoo 内核不是 SolidWorks 内核生成结果导入 Fusion 360 或 SolidWorks 时可能会有特征丢失需要通过 STEP 格式中转。3.2 完全本地部署的 Text2CAD 开源方案如果你有数据隐私要求或者想在离线环境跑可以考虑本地部署开源方案。目前 GitHub 上有一些把 Llama-2/Llama-3 微调成“CAD 代码生成器”的项目比较典型的是 Text2CAD论文 开源代码。这类方案的原理用 Fusion 360 的 API 文档作为知识库。用海量 CAD 模型及其建模历史作为训练数据。微调 LLM使其学会输出符合 Fusion 360 API 调用的 Python 代码。实际体验生成质量远不如 Zoo尤其是复杂装配体逻辑很容易混乱生成的代码经常报错。但它胜在完全离线、可控、可定制。我可以在它的基础上加一层规则校验确保生成的代码只调用我指定的 API 子集。如果你要走这条路我的建议是不要直接让它生成最终模型而是让它生成“建模方案描述关键尺寸”再让本地脚本把方案转成模型。这样模型即使写错代码也不会影响整体流程。3.3 偏门组合拳大语言模型 OpenSCAD 参数模板第三个方案是我自己搭的适合手里有大模型 API 的开发者。思路很简单构建一个 OpenSCAD 参数化模板库大模型只负责从模板库里挑选合适模板并填写参数。比如我预定义一个“带孔底板”模板里面含length、width、thickness、hole_diameter、hole_spacing这些参数。用户输入“200 毫米长 150 毫米宽、厚 5 毫米、四角 8 毫米孔”描述模型只需要把自然语言映射到参数值再调用模板渲染。这套方案的优点是准确性极高因为模板是我自己写的几何逻辑绝对正确。缺点是覆盖范围有限只能做我预定义过的零件类型。但它适合企业内部的标准化零件库场景直接把自己的零件库模板和 LLM 对接形成“内部标准件文本生成系统”。为了直观对比我把三种方案的关键差异整理成一张表方案生成质量可编辑性离线可用覆盖面上手难度Zoo高标准件强参数化否中低Text2CAD 开源中低中是中高LLM OpenSCAD 模板高模板覆盖内强是低中4. 实操全流程从一句需求到可加工的 CAD 文件接下来这部分是最能直接用的。我以开源的 Spoon 项目为例拆解从文本提示到生成可用的 CAD 模型的完整操作流程。Spoon 是 2023 年底开源的一个 text-to-cad 项目底层也用 LLM 驱动支持直接生成 STEP 文件。流程同样适用于 Zoo 之类的工具因为核心都在提示词和验证环节。4.1 环境准备与安装Spoon 的安装我建议用 Docker一个命令拉起所有依赖省心。以下是在 Ubuntu 22.04 上的实操记录。先克隆项目代码git clone https://github.com/lingtxyz/spoon.git cd spoon然后构建 Docker 镜像docker build -t spoon .这里有几个坑要提醒。镜像比较大第一次构建可能要十分钟以上做好心理准备。如果服务器在国内构建过程中拉取基础镜像或 Python 包经常超时建议配置镜像加速器。最好提前把 Docker 的 DNS 设置好否则后面调用 API 时域名解析不了排查起来很头疼。构建完成后启动服务docker run -it --rm -p 8000:8000 spoon启动后访问http://localhost:8000能看到 Web 界面。我用下来感觉最稳定的方式是通过 REST API 调用Web 界面适合做演示和快速验证。Spoon 默认需要配置大模型 API 密钥。项目里支持 OpenAI 兼容接口所以你可以用官方 API也可以用本地部署的模型。我因为数据敏感性考虑在实验室里用了自建的模型网关按 OpenAI 格式配置改动很小。4.2 提示词工程准确描述一个 CAD 模型的技巧文本生成 CAD 的核心在提示词。我试了几十次后总结出一套可复用的模板能显著提高生成成功率。先看一个标准的提示词Create a STEP file of a slotted flat head machine screw. Specifications: - Thread size: M4 - Thread pitch: 0.7 mm - Length: 16 mm - Head diameter: 7 mm - Head height: 2.2 mm - Slot width: 1.2 mm - Slot depth: 0.8 mm这套提示词的关键点明确标准直接说 M4、0.7 pitch让模型能查到标准件参数而不是自己瞎猜。给几何参数head diameter、head height 这些尺寸帮助模型快速定位头型。指定输出格式明确说 STEP 文件避免模型输出一个可交互预览或其他格式。说明视图方向对非对称零件我通常还会补充“the slot is aligned with the Y axis”之类的话确保方位正确。对比一下失败案例错误提示词Make me a screw这种写法生成的结果基本没法用因为“screw”太泛了模型只能猜猜错概率极大。再分享一个高级技巧对复杂零件先用自然语言描述整体结构再分步骤描述特征。比如Generate a STEP file of a bearing housing. The housing is a rectangular block: - Length: 80 mm - Width: 40 mm - Height: 30 mm On the top face, create a cylindrical bore: - Diameter: 25 mm - Depth: 20 mm, through all Add 4 mounting holes at the bottom corners: - Diameter: 6.6 mm - Counterbore: 11 mm diameter, 6.5 mm deep - Hole spacing: length 60 mm, width 20 mm, symmetrical这种结构化的描述方式模型理解起来容易很多。本质上这是在用“特征历史”的思维去组织语言。4.3 生成过程与结果验证在 Spoon 的 Web 界面里输入提示词后点击生成后台会先调用大模型生成 CAD 脚本然后交给内核解析执行。正常流程下 15 秒左右就能看到结果。拿到生成结果不要急着导入软件先做三步检查第一步检查步骤树。如果是 Zoo看左侧特征树里是不是包含了预期步骤比如“拉伸-打孔-倒角”。如果只有单个布尔运算说明模型偷懒了后续改参数很难。第二步检查关键尺寸。用界面自带的测量工具抽查提示词里提到的关键尺寸比如螺纹直径、孔距。我经常发现模型生成的模型里尺寸和文本请求不一致可能是它的内部换算有问题。第三步导出 STEP 并重新导入。我用 FreeCAD 做这一步主要验证文件是否损坏、拓扑是否正确。FreeCAD 对 STEP 支持良好而且免费。实测中我发现Spoon 和 Zoo 生成的 STEP 文件导入 FreeCAD 后绝大多数情况下模型能正常显示但偶尔会出现面片缺失或缝合问题。这种情况下不要尝试在 FreeCAD 里修复了直接把提示词里的关键尺寸再明确一次重新生成。修复一个 broken 的 STEP 通常比重新生成更耗时。4.4 直接调用 API 的自动化流程如果想把 text-to-cad 集成到内部工具链Web 界面不够用我建议直接走 API。Spoon 和 Zoo 都提供 REST API大致流程是提交生成任务轮询状态结果完成后下载文件。伪代码示意import requests import time API_URL http://localhost:8000 headers {Authorization: Bearer YOUR_API_KEY} # 提交任务 response requests.post( f{API_URL}/api/generate, headersheaders, json{ prompt: M4 slotted flat head screw, length 16mm, generate STEP, format: step } ) task_id response.json()[task_id] # 轮询状态 while True: status requests.get( f{API_URL}/api/tasks/{task_id}, headersheaders ).json() if status[state] succeeded: break time.sleep(2) # 下载结果 result_url status[result][download_url] model_file requests.get(result_url).content with open(output.step, wb) as f: f.write(model_file)把这个流程包装成一个函数就能批量生成标准件库了。我建议做好任务队列因为生成任务很重并发太多会把服务打崩。5. 常见问题与故障排查实录我把两周里遇到的所有坑整理了一遍这里挑最常见的五个给排查思路。5.1 生成的模型是空壳不是实体典型表现导入 FreeCAD 后看起来有东西但剖开一看是片体不是实体。原因分析这类问题大多是底层几何内核的布尔运算失败导致的。尤其是螺母的螺纹建模需要非常精确的曲面求交模型输出的参数稍有偏差求交就失败。排查思路先看日志里有没有报布尔运算失败的记录。Spoon 的日志里会明确写Boolean operation failed。检查提示词里是否包含了会冲突的尺寸比如孔直径大于底板的宽度。不要一开始就生成带螺纹的零件先用不带螺纹的版本测试流程通了再加上。这种问题目前没有有效的程序化修复手段只能修改提示词重新生成。我在实践中会把“几何简单”放在提示词第一位比如不要求生成螺纹细节而是用简化几何表示生成成功后再在 CAD 里加真实螺纹。5.2 提示词没问题但生成的零件方向反了典型表现孔位在 X 方向实际生成在 Y 方向。原因分析大模型对空间方向的泛化能力并不强尤其是在没有明确指定坐标系的情况下它倾向于把长边放在 X 轴但这可能不符合你的预期。排查思路在提示词里显式加一句“the long dimension is along X axis”。对轴对称零件生成后再统一旋转这个可以在代码里自动完成。如果你用的工具支持二次编辑直接在参数面板里调整方向。这个问题的规律是提示词越短方向出错的概率越高。信息丰富度很重要。5.3 API 返回超时但服务没有崩溃我遇到过一次 API 调用 120 秒才返回的现象直接触发了客户端超时。原因分析复杂模型的生成时间本来就长加上服务器资源有限队列里若有多个任务排队单个任务的响应时间会指数级增长。排查思路把客户端的超时时间从 30 秒调大到 300 秒。用异步任务队列替代同步等待也就是前面伪代码里轮询的方式。检查服务器内存。我实测发现内存不足时生成速度会骤降因为这触发了 swap。强烈建议给容器分配至少 8GB 内存。5.4 生成的模型完全不符合几何逻辑典型表现输入“a bracket with two holes”生成的模型只有一个 L 型板没有孔。原因分析这常发生在模型对文本特征的理解遗漏。本质是提示词中特征描述不够突出。模型有注意力机制如果前面的铺垫描述太长核心特征词会被淹没。排查思路把核心特征放到提示词最开头比如第一句就是“Create a bracket with two through holes”。避免使用“some”“a few”这类模糊数量词直接写“two holes”。如果仍然不行把整个特征重新用一句话明确描述。我自己的经验是给模型一个结构化的提示词模板成功率能提升到 80% 以上。模糊自然语言的成功率只有三四成。5.5 生成的 STEP 文件导入 SolidWorks 后特征树是空的典型表现Zoo 生成的 STEP 在浏览器里看没问题但导入 SolidWorks 后是一个“哑体”无特征树。原因分析这是格式本身的限制。STEP 格式只保存几何和拓扑不保存建模历史。你在 Zoo 里看到的特征树导出成 STEP 后确实就丢了。排查思路如果需要特征树直接复制 Zoo 生成的建模脚本在你的 CAD 软件里重放而不是导 STEP。或者使用中间格式导入比如导入为 BREP 再转换。Fusion 360 对这类文件的兼容性比 SolidWorks 稍好一点。这是所有 text-to-cad 工具在联调阶段都容易忽略的问题。如果你要的不是最终模型而是可编辑的建模过程一定要确认工具支持导出原生参数化格式比如 Zoo 的.zoo文件或 Fusion 360 的.f3d而不是 STEP。6. 我在实际使用中的几点体会最后分享一些实操经验想到哪说到哪。第一把 text-to-cad 当作“参数化标准件自动生成器”来用别当作“万能建模器”。现阶段它对标准件、板类零件、简单壳体、连接件这类规则几何的理解已经很好一旦涉及复杂曲面、装配约束、公差标注基本帮不上忙。第二多准备几个版本的提示词模板。我在本地建了一个提示词库按零件类型分类。比如“螺栓类”“轴承座类”“钣金件类”每种分类下有几套已验证可用的模板。这样再来新需求时改参数就能用不用每次从头写。第三生成结果一定要过一遍人工检查。我用过几次直接拿生成结果去 3D 打印偶尔遇到模型上有一个微小但致命的几何错误比如孔没有完全贯穿打印出来才发现浪费时间又浪费材料。就算 text-to-cad 以后变得再强最终作为工程交付物的审核环节是省不掉的。第四注意用“工艺可行性”来描述模型而不是用“视觉外观”。一个很典型的案例你输入“一个漂亮的支架”模型可能会给你生成一个有复杂曲面的东西好看但没法加工。你换一种说法“a simple L-shaped bracket with two mounting holes, suitable for CNC machining from aluminum plate”生成的模型才真正能进入产线。text-to-cad 背后的模型其实更重视文本的精确性越接近加工语言结果越可用。这个方向的技术还在快速演进中但就目前的成熟度而言text-to-cad 已经不只是极客玩具了。它在你处理标准件、概念模型、前期方案验证时能节省大量时间值得花一个下午试一遍它会让你重新思考“建模”这件事本身。
返回列表