★ FEATURED ARTICLE 这几年text-to-cad的热度一直没降下来隔三差五就有人拿着演示视频来问输入一句话真的能生成CAD模型吗我先给结论能但没演示里那么神。text-to-cad全称Text-to-CAD就是用户用自然语言描述一个零件的形状、尺寸和功能要求系统自动生成可编辑的CAD三维模型。它输出的是带几何参数和特征树的模型不是渲染图。这篇文章我会从技术原理、工具选型、实操流程到落地坑位完整走一遍帮你在自己的项目里快速判断这条路能不能用、怎么用。适合正在评估这项技术的机械工程师、结构设计师也适合搞3D打印和自动化建模的开发者。1. text-to-cad在解决什么以及为什么值得关注1.1 传统建模流程里的真实痛点我2012年刚入行的时候在一家非标自动化公司做机械设计。客户提需求经常是口头描述加手绘图“这里加个安装板四个角打孔孔距大概多少多少。”我拿SolidWorks建模型光是把一个安装板做出来从选基准面、画草图、标约束、拉伸、打阵列孔半小时起步如果需求方中途改一个孔距我还得回到草图里去改尺寸甚至重建特征。后来我仔细算过一笔账一个普通非标零件建模时间占整个设计周期的三成沟通返工又占三成。一个工程师每天真正花在“思考设计”上的时间远没有想象中那么多。传统CAD的痛点可以压成三句话软件门槛高需求传递损耗大模型复用率低。软件门槛好理解新手要熟悉草图、约束、特征、布尔运算没三个月上不了手。需求传递损耗更致命用户嘴里说的“这里大一点那里薄一点”到了建模软件里就变成一堆需要精确到小数点后两位的尺寸信息在翻译过程中疯狂衰减。模型复用率低则是老工程师的痛一个零件建得再好换个项目就是复制不出来哪怕只是改几个尺寸也得手动重建一遍。text-to-cad想做的就是把这个“翻译”过程自动化让自然语言直接变成建模操作跳过草图和特征树的繁琐步骤。但注意它并没有消灭设计本身该想清楚的受力、装配、工艺还是得想清楚。1.2 不是“替换设计师”而是压缩沟通链条很多人一听text-to-cad第一反应是“设计师要失业了”。我实际用下来完全不这么看。它更像个“翻译官”把口语化的设计意图转成精确的几何描述。真正有价值的不是省掉建模那半小时而是把“需求方-设计师”之间的沟通循环缩短。举一个典型的例子供应商发来一个接口法兰说“和你们之前的差不多但孔距改成80外径做到110”。传统流程里我要打开旧模型进草图改尺寸重新生成工程图再检查干涉。现在用text-to-cad直接把这句话转成提示词让模型基于我库里的法兰模板生成新版本一分钟不到。注意前提是我库里已经有一个结构化的参数化模板而不是每次从零生成。这一点后面会详细说。所以text-to-cad真正的价值是把“从一句话到第一版模型”的时间压缩。它让设计师花更多时间在方案判断、功能验证和工艺优化上而不是耗在枯燥的重复绘图里。这也是为什么过去两年它会在机械设计、3D打印、自动化建模这些领域越来越热。2. 主流技术路线与原理拆解2.1 路线一让大模型直接写程序化建模代码目前市面上能跑通的主流方案不是端到端直接生成几何而是让大模型生成程序化建模代码。这句话值得划重点。所谓程序化建模就是用代码来描述几何画一个圆、拉伸10毫米、切一个孔、阵列4个……每一步都是可执行的指令。OpenSCAD、CadQuery、FreeCAD的Python接口都属于这一类。为什么大家不约而同走了这条路原因很朴素大模型最擅长的输出格式是文本而代码恰好是文本CAD模型里的每一个特征又可以很自然地对应到代码里的一个调用。换句话说程序化建模代码就是CAD世界的“自然语言”。你告诉它“法兰盘外径100、内径50、厚度10四个螺栓均布”它把这些约束转成一段CadQuery脚本你本地一跑就得到几何模型。这条路线还有一个隐性优势代码可验证、可迭代。模型输出一段代码你可以静态审查可以跑出几何再检查错了只改其中一行就行。这个特性在工程里太重要了。2.2 路线二生成式模型输出CAD操作序列除了让大模型写代码学术界也在走一条更激进的路线直接用生成模型输出CAD操作序列而不是生成代码。这里的CAD操作序列指的是“草图-拉伸-打孔-阵列”这样的特征操作历史。2024年前后陆续出现过Text2CAD相关的研究工作把CAD建模过程表示成一系列操作标记用Transformer或扩散模型去预测整体序列。你可以把它想象成“让AI学会画流程图的每一步”而不是“让AI写代码然后自己执行”。这条路线的问题是训练数据得是大量带标注的CAD操作序列这种数据不像文本那么好拿生成结果一旦出错很难像代码那样单独修一段只能整体重跑。所以它目前更多还是在论文里离工程化还有距离。但长期看如果能直接控制特征树生成结果会比写代码更接近原生CAD这个方向值得持续关注。2.3 为什么目前“代码生成”路线明显领先我把两条路线放在一起对比过差异相当明显对比维度大模型写程序化代码生成式模型输出操作序列输入输出自然语言→可运行代码自然语言→建模操作序列可编辑性高代码可改可重跑低序列一旦错误纠偏成本高训练数据依赖依赖大模型已有代码能力无需专门训练需要大规模CAD操作标注数据工程成熟度高CadQuery/OpenSCAD生态完善低主要在学术实验阶段适合谁工程师、开发者、3D打印用户研究、前沿探索代码生成路线之所以现在领先本质是因为它“站在巨人的肩膀上”。大模型已经通过海量代码训练获得了很强的程序编写能力而程序化建模工具又已经存在了十几年两下一结合工程可用性立刻就有了。操作序列路线虽然更优雅但数据和工具链都还没成熟。3. 工具选型与一个完整实操流程3.1 当前可用的工具和选型建议市面上标榜“text-to-cad”的产品不少但真正能稳定进入工作流的其实就那几类一类是通用大模型加程序化建模库以GPT-4o、Claude这类模型配合CadQuery、OpenSCAD使用最灵活适合工程师自己折腾。另一类是专门的text-to-cad平台比如早年Zoo推出的文本生成3D模型功能输入“一个蓝色玩具车”就能生成一个可下载的STL但这类平台更偏消费级和3D打印场景离机械设计还远。还有一类是学术模型比如Text2CAD相关开源项目可以本地部署但使用门槛高效果也还在追赶中。选型我建议按照需求来如果只是快速验证想法或做3D打印用LLM加OpenSCAD就够了环境最轻STL导出快。如果做机械设计需要出工程图、需要STEP格式那LLM加CadQuery是当前最顺手的组合。如果有数据保密要求可以把开源LLM私有化部署再套一套内部CadQuery模板库效果一样能起来。3.2 环境准备与Hello World示例我目前用得最多的方案就是“大模型 CadQuery”。整套流程分成四步设计需求自己想清楚把需求写成提示词让模型输出CadQuery代码本地执行并检查几何。环境准备特别简单一个Python环境就够了。pip install cadqueryWindows上建议直接用conda装CadQuery官方在conda-forge频道有打包可以少踩很多依赖编译的坑。装完之后先跑一个最简单的立方体确认环境没问题。import cadquery as cq box cq.Workplane(XY).box(20, 20, 20) cq.exporters.export(box, box.step) print(ok)这里的XY是草图平面.box(20, 20, 20)就是生成一个长宽高都是20mm的立方体。运行后当前目录出现box.step环境就算通了。3.3 用CadQueryLLM生成一个法兰盘环境准备好之后我拿“法兰盘”这个典型零件走一遍完整流程。法兰盘在机械设计里太常见了非常适合演示text-to-cad。先写提示词我用得比较顺手的模板是这样你是精通程序化建模的机械工程师。请用CadQuery生成一个法兰盘零件要求 1. 所有尺寸定义为变量集中放在代码开头方便修改 2. 外径100mm内径50mm厚度10mm 3. 4个均布螺栓孔直径8mm螺栓孔中心圆直径80mm 4. 建模完成后用中文分步骤解释你的建模思路 5. 确保代码可直接运行不要使用不存在的CadQuery API。最后一条“不要使用不存在的API”很重要能拦住大量幻觉。我实测下来加了这一句之后生成的代码一次通过率提高了不少。以下是调用LLM的一个示例我用的是OpenAI的SDK换成你常用的API也完全一样接口大同小异。from openai import OpenAI client OpenAI() prompt 你是精通程序化建模的机械工程师。请用CadQuery生成一个法兰盘零件要求 1. 所有尺寸定义为变量集中放在代码开头方便修改 2. 外径100mm内径50mm厚度10mm 3. 4个均布螺栓孔直径8mm螺栓孔中心圆直径80mm 4. 建模完成后用中文分步骤解释你的建模思路 5. 确保代码可直接运行不要使用不存在的CadQuery API。 resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: 你只输出可直接运行的CadQuery代码代码块之外不要加任何解释。}, {role: user, content: prompt}, ], ) print(resp.choices[0].message.content)这里把system prompt设成“只输出代码”是为了把模型返回里的解释性文本滤掉方便直接存成.py文件跑。模型一般会输出类似下面的代码import cadquery as cq # 参数区 outer_diameter 100.0 # 外径 inner_diameter 50.0 # 内径 thickness 10.0 # 厚度 bolt_circle_d 80.0 # 螺栓孔中心圆直径 bolt_hole_d 8.0 # 螺栓孔直径 bolt_count 4 # 螺栓孔数量 # 建模 flange ( cq.Workplane(XY) .circle(outer_diameter / 2) .extrude(thickness) .faces(Z) .workplane() .hole(inner_diameter) ) flange ( flange.faces(Z) .workplane() .polarArray( radiusbolt_circle_d / 2, startAngle45, angle360 / bolt_count, countbolt_count, ) .hole(bolt_hole_d) ) cq.exporters.export(flange, flange.step) cq.exporters.export(flange, flange.stl)这段代码的逻辑很清晰先在XY平面画一个半径50的圆拉伸10mm得到主体然后在上表面Z指的是法向指向Z的面建一个新工作平面用.hole(50)直接切穿中心孔接着在上表面用polarArray做极坐标阵列半径为40mm起始角度45度每个孔之间间隔90度阵列4个点再在每一个点上用.hole(8)打孔。最后导出STEP和STL。第一次跑的时候我犯了个错polarArray的angle参数我理解成了“总角度”其实它是每次旋转的角度。想让4个孔均布角度就写360/490度如果写3604个孔会全部叠在同一个位置上。这个API的语义和有些软件里的“阵列总数”不一样很容易踩。3.4 提示词设计的核心技巧用了几十次之后我总结出一套提示词写法可以明显提高成功率显式声明单位。LLM对数字很敏感但对单位很迟钝。你不写“毫米”它可能默认成英寸导致模型直接大25.4倍。我所有的提示词开头都会写一句“所有尺寸单位均为毫米”。把形容词换成几何关系。不要说“好看一点”“均匀一点”要说“同轴”“中心对称”“4个孔等间距分布”。模型理解几何关系比理解审美词稳定得多。先让模型跑计划再写代码。复杂零件先让LLM输出建模步骤你确认过再让它写代码能大幅减少返工。比如“先列出建模步骤用户确认后再输出完整代码。”这种方式适合零件特征超过5个的情况。要求参数集中管理。所有尺寸放开头变量区后面改起来才是真正的参数化。如果模型默认硬编码你改一遍尺寸就等于重建一遍模型那还不如自己手动建模。给模型一个身份和约束。“你是资深机械工程师”和“确保代码可直接运行”这类句子看起来没什么技术含量但实测确实能提升输出质量。大模型非常吃角色设定。4. 工程落地中的坑与排查实录4.1 语义歧义同一个词十个工程师十个理解有一次我让模型生成“一个支架”它给了我一个L型角钢样式的东西方方正正。但我要的其实是设备背板用的U型支架带两个耳朵的那种。文本描述里只说了长宽高没说安装方向、承重面、开口方向AI当然只能猜。这事不是AI的错是需求本身没表达清楚。解决思路只有一个给关键名词绑上精确的几何定义。我自己建了一个常用零件提示词库把“支架”“法兰”“轴承座”这些词在提示词里和详细的尺寸、拓扑约束绑定。比如写“U型支架开口方向朝左底部带四个沉头孔”就比写“一个支架”强得多。如果是企业内部使用可以把这个词库做成团队共享的模板大家都按模板来生成的模型质量会稳定很多。4.2 几何与拓扑质量问题LLM生成的代码能跑不代表几何就是好的。我遇到过最常见的三个问题非流形几何比如两个面贴在一起但没有合并切片器会报错布尔运算失败CadQuery执行到最后抛异常因为相交面退化成了零厚度小尺寸退化圆角半径给到0.01mm这种实际加工和打印根本做不到。解决办法是加一个自动检查环节。CadQuery里每个Workplane对象可以用.val().isValid()做简单校验更严格的话可以调用Open CASCADE的底层检查功能。我通常在导出STEP之前在脚本里固定跑一道检查体积极小、面数异常、边界边数量异常任何一个触发都自动停。宁可让流程断掉也不要产出带暗病的模型。4.3 常见问题速查表症状可能原因排查与解决代码报错某个API不存在LLM幻觉编造了CadQuery没有的方法提示词里加“不要使用不存在的API”可以附上一小段参考代码尺寸整体大25.4倍把毫米当成了英寸处理提示词中显式写“所有尺寸单位均为毫米”孔不在应有位置polarArray的angle语义理解错误检查angle是增量角度而不是总角度导出STEP后特征树是空的导出方式不对或版本兼容性差确保用CadQuery导出的STEP来自实体对象而不是网格圆角倒角失败链选边不唯一提示词要求拆开步骤一次只对一个边链倒角模型破面无法切片非流形几何用Meshmixer做面片修复或者回到代码合并重合面这表里每一行我都真实踩过。尤其是单位混淆和API幻觉我见过的频率最高但只要提示词里提前约束就能减少一大半。5. 我现在的工作流和给你的建议5.1 适合用text-to-cad的场景用了大半年之后我现在的固定工作流是接到需求先花十分钟把约束想清楚写成结构化提示词让AI出三版候选模型挑一版进CAD软件做详细校核校核通过后同步回参数化模板库。整个过程里AI帮我省掉的主要是“从一句话到第一版模型”的时间这块过去占整体耗时比重最大。具体来说这个流程最适合四类场景概念设计阶段的多方案比选这个阶段低精度模型足够做判断非标零件快速成型尤其是一堆只有尺寸差异的亲属件标准件变种批量生成比如从同一个法兰模板派生出十余种孔径变体还有教学演示让学生直观看到文字怎么变成三维几何。不适合的也有复杂曲面造型A面设计那种它完全做不了需要严格遵循企业内部规范的交付物和对实时性要求很高的交互设计场景。5.2 个人经验与扩展方向最后分享一个很小的经验把text-to-cad当入口别当终点。我见过太多人让AI生成一个模型检查都不检查就直接丢去打印结果做出来一个装不上的件。文本生成只是把“需求翻译成几何”这一步自动化了后面该做的公差分析、干涉检查、可制造性评审一样都不能少。我个人的体会是text-to-cad目前最适合扮演的角色是一个“快筛工具”。它让你在几分钟内看到好几个方向的几何方案帮你尽早锁定设计方向。真正到了详细设计阶段我还是会回到CAD软件里做参数化建模但有了AI给的初版模型做参照效率比从空白画布开始高出一大截。如果你在评估这项技术建议别一开始就指望它端到端替代现有流程先从一个小零件、一条提示词模板、一个自动检查脚本开始把这条小链路跑通再逐步扩大范围。路上的坑我都帮你踩过一遍了剩下的可以放心往前走。
阅读完成 · 觉得有帮助？
