资讯详情

资讯详情

一文读懂text-to-CAD:从自然语言到可编辑三维模型的技术路径与实操指南

1. text-to-CAD 是什么以及它为什么值得关注text-to-CAD字面意思就是“用文字描述直接生成CAD模型”。不管你是机械工程师、产品设计师还是刚开始学建模的学生只要你曾经对着空白的草图界面发呆或是为一个简单零件反复调整拉伸、倒角、阵列这些参数就一定理解这个工具的价值把脑子里那个“大概长什么样”的模糊想法直接变成可编辑的三维模型。这个方向之所以在近两年爆发核心原因是多模态大模型和参数化建模技术终于走到了一个交汇点。以前我们聊AI辅助设计更多是自动出图、拓扑优化这类偏仿真和分析的工作现在不一样了语言模型可以直接输出OpenSCAD脚本、CadQuery代码、STEP文件生成指令甚至是FreeCAD的宏命令。也就是说AI不再只是“帮你算”而是真的“帮你建”。适合关注这个方向的人我认为主要有三类。第一类是经常需要快速验证结构方案的工程师脑子里有想法但不想花半小时建一个临时模型第二类是做非标自动化或工装治具设计的朋友很多零件其实就是“一个板子上面开几个孔、折几道弯”这种模式化结构用自然语言描述绰绰有余第三类是教育领域的老师和学生text-to-CAD 能极大降低学习CAD的门槛让学生先学会用工程语言描述需求再反过来理解建模逻辑。我自己测试了大半年这个方向包括各类开源模型、商业API、本地部署方案还尝试在工作流里加入自动校验环节。这篇文章不是一篇综述而是把我实际跑通过、踩过坑的经验整理出来尤其会讲清楚几条技术路径的差异、提示词该怎么写、生成的模型如何检查修正以及哪些常见问题会被很多人忽略。2. 技术路线拆解四种实现路径与选型逻辑2.1 文生代码最务实、最可落地的路线所谓文生代码路线简单说就是让大语言模型输出一段CAD相关的脚本然后用对应的解析器或CAD内核去执行这段脚本生成几何实体。目前在工业级和创客圈子里最主流的几个目标语言是OpenSCAD、CadQuery、build123d以及FreeCAD的Python API。为什么选它们而不是直接生成一个二进制的STEP文件因为脚本本身就是参数化描述用户拿到脚本之后随时可以改尺寸、改数量、改位置关系这才是CAD的核心价值。你让模型输出一个死板的网格文件那只是“一次性造型”对工程迭代没有意义。以OpenSCAD为例它的语法接近函数式编程非常适合让语言模型生成。你描述“一个长100宽60高10的板子中心位置挖一个直径30的圆孔”模型大概率会输出类似这样的代码difference() { cube([100, 60, 10], center true); cylinder(r 15, h 12, center true); }这段代码的逻辑其实很直白先创建一个立方体再用一个圆柱体做差集运算得到孔洞。OpenSCAD的模型树就是一段可读的文本这让大模型非常容易学习和推理。CadQuery则是基于Python的另一个思路它更接近传统CAD的“特征建模”逻辑。比如同样的零件CadQuery写法是这样的import cadquery as cq result ( cq.Workplane(XY) .box(100, 60, 10) .faces(Z) .workplane() .hole(30) )这个代码在语义上更贴合工程师的思维创建一个长方体选中顶面打一个直径30的孔。我用下来感觉CadQuery生成的模型边界质量更好圆孔、倒角这类特征的几何精度更高更适合要拿去加工或仿真的场景OpenSCAD胜在简单直接、渲染快、生态成熟。从选型角度我建议遵循一个原则如果你的核心需求是“快速看形状、做概念示意”OpenSCAD足够如果生成的模型后续要进CAM、有限元分析或者和别的外部零件装配优先考虑CadQuery。因为CadQuery最终基于OCCT内核导出的STEP文件在工程软件里兼容性更好。2.2 文生参数把特征模板和语言模型结合第二种路线不是让模型直接写代码而是让模型输出“参数表”。你事先在CAD软件里定义好一个参数化模板模板里有若干关键尺寸和特征开关模型只负责根据自然语言描述把这些参数填上。举个例子我做过一个法兰盘的模板变量包括法兰外径、内孔直径、螺栓孔数量、螺栓孔分布圆直径、法兰厚度。当用户输入“设计一个DN50的法兰4个螺栓孔”模型就输出一套结构化参数程序再把这些参数写进模板生成最终模型。这种路线的优势非常明显可控性极强。模型不需要理解复杂的建模操作只需要做好语义到数值的映射。哪怕模型生成的参数有偏差也不至于出现几何拓扑错误。缺点是泛化能力受限换一个新类型的零件就得多写一套模板。实际项目中文生参数路线往往是和文生代码路线搭配使用的。对于结构高度标准化的零件族用模板对于非标结构让模型直接写代码。判断标准其实很简单这个零件有没有规律可循如果“结构是稳定的只是尺寸变化”模板化如果“每次结构都不同”代码生成。2.3 文生几何关注度最高的前沿方向文生几何是最像“AI生成图片”的路线也就是让扩散模型或生成对抗网络直接生成三维几何数据比如点云、体素场、隐式曲面或者三角网格。许多相关论文展示的结果确实令人惊艳输入一句话模型直接产出精细的网格模型。但你一旦把这类模型生成的几何数据往CAD软件里放问题就来了网格模型在CAD里只是一个“实体”没有特征树没有参数不能改孔的位置不能改圆角半径最多只能转换成一个无法编辑的B-rep实体。这在快速原型和游戏资产制作里够用但在工程制造领域基本是鸡肋。我可以负责任地说如果目标是“让AI在工程场景里辅助设计”那文生几何不是当前的最优解。倒不是说它没有意义而是生成精度和可编辑性这两道坎短时间内跨不过去。至少在我测试的模型中还没有哪个能在“倒角到底是C2还是C3、孔距公差要求”这种细节上给出准确反馈。2.4 混合路线代码生成 视觉校验 参数反馈我在实际项目中走得比较多的是混合路线。第一步用大模型生成CAD脚本第二步自动执行脚本渲染出预览图第三步把预览图喂回给多模态模型让模型自己检查尺寸是否合理、比例是否协调、特征位置是否对必要时自动修改提示词或脚本再重新生成。这个闭环里面最关键的是第二步到第三步的衔接。你需要在本地搭建一个自动渲染服务OpenSCAD和CadQuery都支持命令行离线渲染。比如OpenSCAD可以这样openscad -o preview.png model.scad --camera0,0,0,45,0,30,200--camera参数向量里依次是视野中心和相机角度这一行命令的作用就是无头模式下渲染一张固定视角的PNG图。CadQuery可以直接导出SVG或者通过cq-editor的离线模式导出PNG。有了图片你就可以调用视觉语言模型接口自动审视生成的几何是否符合预期然后把修改意见再编译成新的提示词。这套流程我用下来的感受是虽然每次生成和校验的时间成本比“直接出代码”高但整体的成功率提升非常多。单独让模型写代码可能生成10次有6次能跑通但只有3次尺寸合理加上视觉校验闭环之后10次里有7次都是直接可用的结果。这个差距在项目里的价值非常大。3. 完整实操从自然语言到可用CAD模型的完整流程3.1 环境准备和模型选型如果你只是随便试玩直接使用主流的商业对话模型就能跑通OpenSCAD生成。但要做成一条可靠的生产线我强烈建议自建服务。原因很简单你需要批量调用、需要固定版本保证输出风格稳定还需要在脚本出问题时自己定位。本地部署方面我的推荐是先用7B级别的小模型跑通完整链路比如Qwen2.5系列或Llama 3.1 8B的量化版本然后在真实效果不满意时再切换到更大参数规模的模型。为什么先从小的开始因为这个任务对模型的“代码能力”和“空间想象能力”要求其实没有那么高OpenSCAD这种简单的脚本语法7B模型经过简单的微调就能胜任。与此同时小模型的推理速度更快迭代调试的成本也更低。在调用模型之前最好先在系统提示词里明确几个约束。第一要求模型只输出纯代码不要解释、不要额外注释这样方便程序自动解析第二告诉模型OpenSCAD的坐标约定和常用函数名第三禁止使用某些容易出错的语法比如polyhedron的顶点顺序如果错误会导致形面撕裂。这些约定能极大降低后续的解析难度。3.2 提示词设计如何把想法翻译成模型能理解的语言提示词是text-to-CAD成败的第一道分水岭。很多人觉得“我都说了要一个架子为什么模型生成的尺寸不对”问题几乎都出在描述方式上。我总结了一个“四要素”提示词模板物体类型明确告诉模型要生成什么例如“L型支架”。整体尺寸给出长宽高或关键尺寸例如“总高100毫米宽度80毫米厚度10毫米”。特征明细逐一罗列孔、槽、倒角、阵列等特征并给出位置关系例如“在竖直面板中心开一个直径25的圆孔”。约束条件特殊要求例如“所有外露锐边倒C1角”“底部四个角开安装孔直径6.5”。一个实际例子我经常用来测试模型的一个提示词是这样的生成一个L型支架水平面板尺寸为80x60毫米厚度8毫米。 竖直面板高度为120毫米厚度8毫米。 两个面板交接处内侧加一个加强筋加强筋为三角形厚度6毫米高15毫米。 水平面板上均匀分布四个直径6.5毫米的安装孔孔中心距边缘10毫米。 竖直面板顶部中心开一个直径20毫米的通孔。 所有锐边倒C1角。你可能会注意到这里有大量的具体数值。这是关键中的关键。语言模型不像人一样有“差不多”的直觉你说“大一点的孔”它可能理解为直径30毫米也可能理解为直径8毫米完全取决于训练数据里的统计偏好。唯一可靠的做法是把所有尺寸数值化。另一个技巧是“先整体后局部”。让模型先生成主体轮廓再通过后续提示词或人工检查添加细节。一次提示词里塞太多要求模型容易顾此失彼。如果生成结果不尽如人意不要重写整段提示词而是针对差异部分做增量修正例如“把两个安装孔改为4个沿长边均布”。3.3 从描述到脚本一次典型的生成过程拿上面这个L型支架来演示一次从文字到脚本的完整过程。我先用OpenSCAD做第一版生成。把上面那段提示词发给模型经过一次对话之后得到的脚本框架是$fn 32; // 水平面板 translate([0, 0, 0]) cube([80, 60, 8]); // 竖直面板 translate([0, 0, 8]) rotate([0, 90, 0]) cube([120, 8, 8]); // 加强筋 linear_extrude(height 6) polygon([[0, 0], [15, 0], [0, 15]]); // 安装孔后续差集 ...这里第二轮细节生成出现了几个问题第一个是加强筋没有摆放到交界处第二个是竖直面板的方向不对。这非常典型——模型理解了整体结构但在局部定位上会出偏差。我的处理方法是直接手动修正坐标而不是重新生成。在脚本里把加强筋移动到正确位置加上旋转和偏移。OpenSCAD的好处是代码改起来很直接甚至可以写一个Post-Processor自动识别常见错误模式。修正完成之后执行渲染命令生成预览图确认四要素都满足然后导出STL或STEP文件。整个流程大约5分钟其中大部分时间花在渲染预览和检查上。3.4 自动校验尺寸不对等于白干对生成结果做自动校验是text-to-CAD工作流里最应该重视但大多数人忽略的环节。没有校验你根本不知道模型生成的孔距到底是20毫米还是30毫米也不知道壁厚是否均匀。校验方案按照精细程度分为三级。第一级是脚本静态检查用正则表达式和语法分析器抓取所有数字参数和预期范围比对。第二级是几何分析用CadQuery或trimesh读取生成的模型测量关键尺寸。第三级是渲染图视觉校验用多模态模型“看”图判断比例是否协调。三级校验逐层递进可以拦截绝大多数问题。以CadQuery为例一个简单的尺寸检查脚本是这样的import cadquery as cq # 读取生成的结果 result cq.importers.importStep(output.step) # 检查模型整体包围盒 bbox result.val().BoundingBox() x_len bbox.xlen y_len bbox.ylen z_len bbox.zlen print(f尺寸检查: X{x_len}, Y{y_len}, Z{z_len}) # 如果尺寸超出预期范围报警 if not (70 x_len 90): print(警告: X方向尺寸超出预期范围)实际项目里我会把这些校验规则整理成一张配置表每个零件对应一组阈值校验结果自动写入日志再决定是否进入人工审核环节。3.5 输出格式选择STL、STEP还是原生脚本到最终交付阶段输出格式的选择取决于你的下游需求。只做3D打印验证STL就够了需要进一步编辑修改必须保留脚本或STEP需要进装配体做干涉检查、出工程图STEP是稳妥选择需要在FreeCAD或者SolidWorks里继续操作CadQuery脚本可直接转换OpenSCAD脚本则要导入后再重建特征树。我在这一步踩过一个坑STL导出之后发现网格质量太差圆孔变成多边形表面有明显的棱线。解决办法是在OpenSCAD里提高$fn精度变量或者在CadQuery的导出API里设置线框偏转角度。对于需要展示和装配的模型$fn64通常能达到视觉和性能的平衡点。另外一点对于有经验要求的交付场景比如CNC加工不要直接拿STL切片编程最佳实践是导出STEP文件然后配合CAM软件重新拾取加工特征。这能极大减少加工中的意外也让工艺人员在模型上做针对性的修改。4. 常见问题与排查技巧实录4.1 模型生成出来了但结构不对怎么办结构不对是最常见的挫败点。模型理解了大概形状但开口方向、孔的位置、加强筋的连接关系都有问题。我的经验是先区分“语义错误”和“几何错误”。语义错误是模型没听懂你在说什么比如把“水平面板上开孔”理解成“竖直面板上开孔”几何错误是模型理解对了但计算出的坐标偏移错了。前者靠改进提示词解决后者靠脚本局部修正解决。改进提示词的时候有一个非常实用的技巧增加“位置锚点”。在描述每个特征时都明确指出相对于哪个参考面、哪个边的位置。不要只说“在面板中心”要说“在水平面板的上表面中心以底面为基准向上偏移8毫米”。这种锚点描述法对模型定位的帮助是极大的我实测下来能把位置类问题的发生率减少一半以上。如果提示词已经写得很精确结构还是不对那就要怀疑是不是模型版本本身的问题。不同的模型在OpenSCAD的“空间坐标系变换命令”上的掌握程度差异很大。建议准备一组标准测试集包括拉伸、旋转、差集、阵列、镜像五种基本操作每次更换模型之前先跑一遍测试集心里有底再上线。4.2 生成速度慢和批量处理的优化方案本地部署小模型跑单条指令通常需要几秒到十几秒这在交互场景下勉强可接受但批量生成几十个零件的时候就很难受。我的优化思路有三个方向。第一结合并行推理框架加载模型比如用amll或者带有continuous batching的推理服务让多个请求同时进入吞吐量能提升3到5倍。第二提示词里少用长文本因为输入token和输出token都会影响推理延迟把提示词模板压缩到精简格式。第三引入缓存机制同一组参数重复生成时直接复用历史结果不做重复推理。我也尝试过把全家桶部署在有GPU的服务器上用API形式对外提供生成服务配一个队列系统管理任务效果很理想。对个人用户来说没必要一步到位搞大规模集群一台24G显存的机器足够支撑小团队的日常使用。4.3 孔洞与装配关系频繁出错的深层原因最后说一个我在实际测试中观察到的深层问题语言模型对“孔”和“配合关系”的理解普遍偏弱因为它本质上没有物理世界的直觉。举个例子你让模型在管道法兰上生成6个螺栓孔分布圆直径100毫米。模型常常会输出均匀分布但缺少基准角定位的结果也就是说它知道“均匀分布”但不知道“第一个孔应该在哪个角度”。在真实装配中基准角决定了法兰的对中一旦错位整个装配就废了。解决这个问题我的方案是引入“特征模板约束”——把常见的标准特征定义成结构化模板建模时优先调用。比如螺栓孔分布我预先定义了这样一个段模板for (i [0 : 360 / n : 360 - 360 / n]) { rotate([0, 0, i]) translate([pcd / 2, 0, 0]) cylinder(r hole_r, h plate_h 1, center true); }提示词里只需要告诉模型“使用标准螺栓孔模板数量6分布圆直径100毫米”模型输出时直接引用这个模板名细节由程序拼接完成。这个“模板优先”的思路让我在涉及孔洞、螺柱、倒角等标准特征时出现的几何错误数量大幅下降。5. 我对这个方向的一些体会和扩展想法整套text-to-CAD工作流跑下来的最大感受是不能把大模型当作“全能的建模师”而应该把它当作一个“理解能力很强的实习生”。它需要你给清晰的任务描述需要通过代码这种媒介来交互做完任务之后需要检查错了需要纠正。这个类比帮助我调整了很多预期也不再追求“一次完美生成”而是把重心放在“快速迭代、高效修正”上。对于想上手实践的朋友我建议从OpenSCAD开始因为它的语法最简单、生态最成熟遇到问题容易搜到答案。先跑通“生成-渲染-检查”的闭环再逐步引入CadQuery和更复杂的模板体系。不要一上来就追求本地大模型先用API接口验证业务价值再考虑成本和部署。这个方向后续还有几个我很看好的扩展点。一个是“设计意图理解”——从工程图纸、手绘草图甚至口头描述中自动提取参数生成CAD模型另一个是“装配体生成”从自然语言描述整个机构的运动关系自动生成多个零件的装配模型还有“设计规范嵌入”把企业的标准件库、制造工艺约束写进提示词或检索增强数据库里让生成结果天然符合规范。这些扩展点目前都还在快速演进中如果你也在这个方向探索我建议多动手实测少追热点词汇真实项目和真实需求是最好的试金石。
觉得有用,分享给同行:

为您的企业打造数字门面

稳重轻奢商务风格,端正雅致视觉,长效耐看不易过时。

立即咨询 →