text-to-cad：自然语言驱动CAD建模的路线与实测-北京尧图网络

第一次在电脑前把一句“给我一个带中心孔的圆盘外径80毫米厚10毫米外圈倒角2毫米”变成真正的STEP文件时我愣了一下。这不是玩笑也不是那种只能看不能用的“文字转3D模型”玩具而是text-to-cad——让自然语言直接驱动CAD建模——真正进入了我的工作流。这个方向最近在社区里热得发烫但大多数讨论都停留在“演示很震撼”的层面真正能讲清楚它背后有几条技术路线、哪些能落地、哪些是画大饼的内容反而很少。这篇文章我打算用自己的实测经历把text-to-cad从原理到踩坑完整拆一遍给想入坑的工程师、设计师以及对AI辅助设计感兴趣的朋友一个尽量真实的参考。1. 先搞清楚text-to-cad到底解决什么问题1.1 从“画图”到“说图”的转变传统CAD建模是个什么流程拿着需求打开软件选草图平面画轮廓加约束拉伸减材料倒角再回到草图……一套动作下来一个简单的零件也许十分钟复杂的零件几小时甚至几天。这里面最耗时间的不是“想清楚”而是把脑子里的想法一步步翻译成软件能理解的几何操作。text-to-cad想干的就是把这一层翻译直接干掉。你用自然语言描述需求模型负责把它拆解成建模意图再由CAD内核执行输出真正的CAD数据。注意我这里说的是CAD数据不是美术模型。具体发生的事情可以从三个层面来看在交互层建模师不再需要点选按钮而是描述需求在逻辑层模型将文本中的实体圆柱、孔、倒角和对应操作拉伸、切割、阵列映射为参数化特征序列在数据层输出的是STEP/IGES这类带精确几何信息的文件可以直接进入下游装配、工程图和CAM加工。这个转变的本质是建模意图的传达方式变了。以前是人对着软件说“我要这样建”现在是人对模型说“我要这个件”模型去对着软件说。解放的是操作时间压缩的是从“语言描述”到“3D几何”的转换成本。1.2 和传统3D生成的根本区别能编辑 vs 只能看很多人一听到text-to-cad第一反应是“这不就是AI生成3D模型吗”。还真不是。市面上常见的文本生成3D模型工具比如喂一句话生成一个发光的房子、一只卡通猫输出的是网格模型——OBJ、GLB这种。网格模型的好处是造型自由、渲染好看但坏处也很致命它是一个“死”的三角面片集合你没法编辑参数没法改厚度没法进CAM加工连倒角都得回到软件里重新修。text-to-cad要看的是另一套东西参数化特征和边界表示B-rep。CAD软件里面的每个圆柱、孔、倒角背后都是一串特征历史和约束关系。text-to-cad要生成的就是这种“活的”模型——拉伸多长、孔直径多少、倒角半径多少全部是可以改的数字。判断一个AI辅助CAD系统是不是“真CAD”还是“假3D”就一条标准生成的结果能不能进入建模历史树里继续被编辑。能进历史树、能改参数、能导STEP的才是真text-to-cad只能导出一个不能编辑的STL网格的再惊艳也停留在“预览”层面。1.3 谁最需要它我在实际工作中的观察我这一年多在机械设计和工装夹具场景里实际试下来text-to-cad的需求其实非常集中主要在这么几类人身上。第一类是非标自动化工程师。每天跟气缸座、垫块、传感器支架、联轴器打交道零件形态高度重复只是尺寸变来变去。对他们来说text-to-cad要是能省掉“每次重新画一遍相似建模”的时间效率直接翻倍。第二类是结构仿真和热仿真工程师。他们常常需要快速搭建带有特定形状、孔位、散热齿的概念几何并不关心内部的装配逻辑。语言生成参数化几何对他们是刚需。第三类是做采购、售前、报价的人。很多时候只需要一个“看起来差不多、尺寸能对上”的初版模型去做沟通不需要精确到公差。这种粗稿需求用text-to-cad生成比开完整CAD软件快得多。我没提工业设计师和自由曲面造型师——不是不需要而是在当前技术栈下自由曲面这条路离可靠还有距离后面会细说。2. 拆开来看业界常见的三条技术路线2.1 路线一大模型直接写CAD脚本LLM 程序化建模库这是我目前用得最多、也最容易落地的一条路线。思路很简单用一个或多个大语言模型理解自然语言把描述翻译成一段定义好的CAD脚本代码比如CadQuery或OpenSCAD然后由系统的建模引擎执行这段代码生成精确的CAD模型。直观的流程是用户输入“一个直径30mm、高45mm的圆柱顶部带一个半径5mm的圆角。”大模型判断这是“圆柱-拉伸-倒角”的组合生成CadQuery代码CadQuery内核执行代码在内存中构建出B-rep导出成STEP进入正常CAD流程。这条路线最吸引人的地方是它复用了现有的工程级CAD内核。CadQuery底层是OpenCascade这可是造飞机、造机床都用过的几何内核能保证几何精度。大模型只负责“翻译”需求不负责“计算”几何因此只要代码正确产出的模型就是精确的、可编辑的。2.2 路线二端到端几何生成扩散模型/序列生成这是学术界和论文里最热闹的一条线也是被很多公司拿来演示“未来感”的技术。它不通过代码中转而是训练深度学习模型直接生成CAD原生的几何表示常见两种形态把CAD建模过程看作“特征操作序列”模型学习输出“草图轮廓 → 拉伸 → 打孔 → 布尔”这样的序列标记然后驱动内核重建用扩散模型生成点云或体素再用NURBS/B-rep拟合后处理成CAD格式。这条路线理论上上限最高——它可以生成极其复杂的自由形态几何不再受限于“脚本能描述到的规则形状”。但它的痛点也很明显训练数据极难获取工业级带历史树的CAD模型不是互联网上有多少就有多少的企业模型都加密且带版权生成结果拓扑不稳定容易出来自相交曲面、非流形几何放到CAD里就是纯废品可编辑性弱生成的是“结果”不是“过程”修改一个尺寸往往得从头生成。按我看到的公开工作比如一些Text2CAD方向的研究论文目前大多数成果还停留在“能生成简单拉伸件的视觉几何”阶段离工程使用有距离。但它指明了方向值得关注。2.3 路线三检索拼装自然语言驱动组件复用还有一条容易被忽略但落地性极强的路子——检索拼装。它不需要模型去“凭空创造”几何而是让大模型理解用户的语言描述从企业已有的标准件库、历史模型库中检索出最匹配的零件进行装配或变体驱动。这和RAG检索增强生成的思路一模一样把模型库里的每个零件做向量化检索用户的描述作为query匹配到合适的模型后再用参数化驱动它修改尺寸。一个很常见的落地场景是企业有一整套法兰库从DN15到DN200各种规格都有text-to-cad的调用方式就是让大模型从描述“我要一个DN100的带颈平焊法兰螺栓孔按GB标准”中抽出关键参数去模型库里调出对应模板驱动尺寸生成新实例。这条路线常常被“自由生成”的光环掩盖但它恰恰是现阶段投入产出比最高的方向——因为它根本不需要模型“硬造”几何只需要一个靠谱的参数化模板库加一个能做意图解析的模型。2.4 三条路线怎么选我的对照表为了不让选择显得玄学我把自己在项目里判断路线的维度整理成一个表对比维度LLM直接写脚本端到端几何生成检索拼装几何可编辑性高特征是活的中低改参数等于重做高驱动模板自由曲面能力低只适合规则实体高理论上限低只能选已有形态对训练数据需求低靠LLM通用知识高需要CAD历史数据中需要模型库落地难度低当天能跑通高论文为主中前期建库与现有CAD流程兼容性高输出STEP中后处理麻烦高本身就是库当前最推荐场景规则零件/参数化粗稿概念造型探索标准件/历史件复用我的判断是短期内想产出实际价值的走一和三长期想突破自由形态的关注二。三条路线未来大概率会融合成一个混合架构而不是相互取代。3. 最小验证亲手搭一个text-to-cad跑通流程3.1 环境准备CadQuery与LLM的组合说再多不如自己动手跑一个。我用的最小组合是CadQuery 一个通用代码能力够用的大模型。选CadQuery不是因为它完美而是因为它有三个其它库短期比不了的优势首先是Python原生大模型对Python的掌握程度远超对CAD软件宏语言的掌握其次是它有明确的建模历史适合做“翻译”和“修改”最后是它底层是OpenCascade导出的STEP能直接进主流CAD和CAM。步骤很简单安装CadQuery环境推荐用conda创建干净环境避免依赖冲突装上cq-editor进行可视化调试不一定必需但强烈推荐选一个大模型我用下来通用大模型GPT-4/Claude类和代码专精的本地模型如Qwen2.5-Coder在“简单零件翻译”这个任务上差距不大本地模型的好处是可以离线、数据不出内网工厂环境里这点特别重要。CadQuery安装好后验证一下能不能在Python里正常导入并且能导出STEP。这一步非常关键因为后面所有LLM生成的代码都依赖这个环境环境不对会浪费大量调试时间。3.2 提示词工程的几个关键约束text-to-cad里的提示词和写文案的提示词完全是两码事。它本质上是在给大模型定义一个“翻译规则”规则不清晰输出就会乱。我最常踩到的坑是“让模型自由发挥”。所以我现在的提示词模板固定包含四类约束角色设定明确告诉模型它是“CadQuery专家”并且只输出Python代码不输出解释单位与坐标约定明确所有尺寸单位是毫米草图平面默认在XY平面挤出默认沿Z轴正方向避免模型自己发挥特征语义要求模型先识别并列出目标的特征清单比如“外圆柱、中心孔、顶部倒角”再为每个特征写对应操作出错处理在每段代码后注释清楚该代码基于的CadQuery API习惯或者反过来要求代码必须有可导入的依赖。一个我反复验证有效的提示词例子你是一名CadQuery专家。请根据下面的自然语言需求生成一段可运行的CadQuery Python代码。规则 1. 所有长度单位默认为mm 2. 草图默认在XY平面默认沿Z方向挤出 3. 零件需求会描述多个特征请先用一行注释列出特征清单再逐一实现 4. 只输出Python代码不要包含任何解释段落。需求一个外径80mm、内径20mm、厚度10mm的中心孔圆盘外圆顶部边缘倒角2mm。这个提示词跑出来的结果稳定性比“帮我画个圆盘”这种模糊指令高一个数量级。3.3 一个能跑通的示例从中文描述到STEP文件下面是我验证过的一段CadQuery代码对应上面需求。如果你在自己环境里跑应该能直接导出STEPimport cadquery as cq result ( cq.Workplane(XY) .circle(40) # 外圆半径40mm外径80 .extrude(10) # 厚度10mm沿Z .faces(Z) .workplane() .hole(20) # 中心孔直径20mm .edges(|Z) .fillet(2) # 外圆竖直边倒角2mm ) cq.exporters.export(result, flange_demo.step)这段代码的执行逻辑是在XY平面画一个半径40的圆拉伸10mm得到圆盘选择顶面并在其上创建新工作平面使用hole函数在顶面钻一个直径20的通孔CadQuery的hole传的是直径参数最后选中所有与Z轴平行的边做2mm的倒角。导入到FreeCAD里打开STEP可以测量确认外径80、内孔20、厚度10、倒角2完全符合输入要求。3.4 模型生成结果怎么验证验证是text-to-cad流程里绝不能省的一步。我见过很多人第一步跑了模型生成看到“看起来对”的几何就以为成功了结果拿去加工发现孔位置偏了0.5mm。我的验证分三层语法层代码能否无报错执行报错信息直接回传给大模型让它修复这个闭环很关键几何层用CadQuery或者解析STEP文件检查关键尺寸是否落在需求公差范围内。比如孔直径是否真的是20mm、外径是否80mm特征层检查建模历史树是否保留了应有的特征。比如孔是“打出来的”还是“用布尔减出来的”倒角是否真的以特征形式存在——这决定了下游修改的灵活度。做到第三层才算真正完成了一个text-to-cad的闭环验证。目前很多公开demo只做前两层这也是为什么它们能“展示”但不能“生产”的原因。4. 实测里躲不开的坑从“代码能跑”到“模型能用”4.1 最典型的翻车代码看起来对实际上错跑通上面的demo你可能会产生“这玩意儿已经很好用了”的错觉。等你把需求从“圆盘”换成“带四个均布孔的法兰盘”大模型生成代码的执行结果往往会给你当头一棒。我遇到的最典型的翻车是模型生成的代码语法完全正确、运行完全无报错但结果明显不对——比如它把圆环外径算成内径的一半把四个均布孔生成成了中心一个孔把倒角做在了内孔边缘而不是外圆。这种错误的狡猾之处在于它不报错所以如果你只看日志不看几何根本发现不了。根因是大模型对CAD几何语义的“常识”目前还是偏弱的它知道“螺栓孔”是孔但对“均布4个孔在分度圆上”如何转换成CadQuery的极坐标阵列经常给出看似合理实则错位的代码。所以我的经验是不要相信模型的“自检”。必须在流程里加入一个独立的几何校验步骤无论模型说自己多确定都要让程序去测量关键尺寸。4.2 草图平面和挤出方向最容易埋雷的地方CadQuery的建模顺序是“选平面 → 画草图 → 挤出/切割”。这一套里有两个地方模型经常搞混。第一个是草图平面选择。CadQuery默认是“XY”但在多层建模时模型容易在各种workplane中间绕晕。比如它想在侧壁上打孔本应选择“X”或“Y”面结果写成了“Z”生成的孔就横着穿到了另一侧。第二个是挤出方向。CadQuery的extrude默认向草图平面的法线方向但如果你在非默认平面上操作方向判断就容易出错。模型生成“反着挤”的代码实际模型整个偏移特别隐蔽。我的规避办法是在提示词里强制规定“所有新的工作平面都用faces().workplane()方式显式声明”并且“所有挤出必须写明方向参数挤出高度值只允许正值”。这样可以从源头上压缩模型犯错的概率。4.3 单位与图纸习惯一个低级但致命的坑CAD行业内最大的“单位暗坑”之一就是模型生成单位和实际生产单位不一致。CadQuery默认是毫米这个没问题但当你把导出的STEP文件放到不同CAD、不同国家的工厂里图纸上标的单位可能是英寸。很多大模型训练数据里混着英制单位代码它在生成参数时可能把“25.4”和“1”混用。我真实遇到过让模型生成一个“1英寸厚的支架”它按英寸理解了但CadQuery按毫米执行结果模型只有1mm厚导出的STEP没法用。所以提示词里应该把单位这一项固定死。并且如果你需要英制最好的办法是全部按毫米输入在最后落图阶段用工具统一换算不要依赖大模型自己做单位转换——它做转换的误差率目前没有代码里的硬编码可靠。4.4 为什么你需要一张自己的评测集如果你打算把text-to-cad用在正经项目上我强烈建议你花半天时间建一个“最小评测集”。做法不复杂整理20~30条你真实工作中会用到的零件描述从简单到复杂排列每条描述写清需要的最终尺寸关键尺寸单独标注跑一遍你的text-to-cad流程记录四个指标代码通过率、几何正确率、特征保留率、生成耗时每次换模型、换提示词、换系统组件都把这份评测集重跑一遍。这个评测集的价值非常大。因为大模型迭代速度快今天好用的模型换一版可能就不行了你没有评测集就没法客观比较“升级”到底是不是“升级”。我自己的评测集现在积累了60多条每次外部模型升级后跑一遍基本30分钟就能判断要不要切换省去了大量脑补的时间。5. 工具链怎么选库、模型、生产边界5.1 脚本化建模库横向对比CadQuery / OpenSCAD / build123d既然LLM写脚本是主路线那么“把语言翻译成哪套脚本”就直接决定了系统的上限。我用了三个主流库结论如下CadQueryPython原生建模历史清晰底层OpenCascade适合直接进入工程流程。缺点是API对新手不算直观很多操作需要理解“workplane”和“selectors”而大模型并不总理解。OpenSCAD语法极简很多大模型对它掌握得非常好因为它本质上就是CSG布尔运算的多面体操作规则简单。“圆柱挖孔差集”这种基础操作生成成功率很高。缺点是可编程能力弱复杂装配和参数化约束处理吃力。build123dCadQuery的“继任者”API更贴近人的直觉比如直接用Box、Cylinder对象支持位置、旋转表达更自然自由度更高。文档相对新大模型训练语料少生成失败率目前偏高但趋势看好。用一句话总结我的选型思路想要最稳CadQuery想要最快出效果OpenSCAD想要极致灵活build123d。5.2 大模型怎么选通用大模型 vs 本地代码模型 vs 专用微调模型选择直接决定翻译质量。我实测的经验有三个阶段。第一个阶段直接用通用大模型比如GPT-4、Claude这类。优点是对自然语言的理解极强、也能写出像样的CadQuery代码缺点是API成本高、数据要出网很多工厂不能接受。第二个阶段换成本地代码模型比如Qwen2.5-Coder这类32B以下能在单卡上跑的。优点是数据不出内网、一次买断式部署、隐私无忧缺点是代码能力在某些复杂场景下明显弱于通用大模型需要靠提示词和上下文做补偿。第三个阶段如果团队有预算和算力可以做专用微调——用企业自己的CAD脚本数据微调一个专用模型。实测下来只要你手里有几百条“自然语言到CAD脚本”的高质量数据再配合一个代码基座模型效果通常出奇地好。但数据清洗成本的量级可能超过你的预期不适合小团队。我的稳妥建议是先通用大模型跑通流程确认业务价值后上本地模型数据积累到一定量再考虑微调。顺序反了很容易白花钱。5.3 生产环境里什么时候能信它、什么时候不能这是文章里我特别想展开的一段。text-to-cad在目前的工程环境里边界非常清晰能信的场景是标准化程度高的参数化零件。法兰、轴承座、支架、垫块、齿轮坯、管接头这些零件的形态在库里有模板、在行业里有标准、在模型训练里有大量语料生成结果基本可靠。不能信的场景是自由曲面和复杂装配。比如一个带复杂流道的泵体、一个要满足大量GDT公差的机加工件、一个涉及到多个零件相互配合咬合的装配体——这些靠文本生成目前即便偶有惊艳案例也无法通过评审。我的实操建议是用“三七原则”分配精力七成精力放在把标准件模板脚本化、把企业知识库结构化三成精力去试自由几何。这样既能看到眼前效率提升又不会因为整天跟“高级别的失败”较劲而丧失信心。6. 接下来值得尝试的方向我的判断和实验6.1 和参数化模板库结合的“填参模式”我目前最看好的落地玩法是“text-to-cad 企业参数化模板”。把企业常用的零件做成CadQuery/FreeCAD脚本模板每个模板有明确的参数接口如直径、高度、孔数、壁厚然后让大模型只做两件事理解用户描述、抽取参数并判断该调用哪个模板。这两个任务都是大模型的强项——抽取参数比凭空造几何可靠得多。这套架构的成功率实测可以到90%以上因为生成的核心逻辑不是模型写的而是工程师预先验证过的。我现在做的一个内部工具就是这种模式用户说“我要一个DN50的带颈法兰按HG/T 20592标准”系统解析出来是“HG/T 20592 DN50”“带颈法兰”模板然后自动填参并导出可编辑的STEP。整个链路非常稳因为模板是工程师写的大模型只做语义路由。6.2 多模态方向语言图像点云的混合输入文本最大的短板是“说不清楚复杂形状”。纯语言描述一个叶轮你得先说几十句还容易歧义。所以我认为很快会进化成混合输入用户上传一张参考图或一个扫描点云再加上一句“照着这个形状把材料改成不锈钢壁厚加到5mm”系统完成多模态理解并输出CAD。这条路的难度在于把图像/点云的几何信息与CAD特征历史对齐——但正是这种“图像找相似、文本定参数”的分工很可能比纯文本生成更早达到工程可用。我已经在关注一些用视觉编码器辅助语义检索的项目把它接到现有模板库上效果已经在内部demo里体现出来了。6.3 我对text-to-cad走向工程化的三个判断最后说三个我比较有把握的判断给关注这个方向的人做个参考。第一纯端到端生成在可预见的两年内很难进生产。数据的稀缺和拓扑的不可控是硬伤但它在概念设计阶段的价值会越来越大。第二LLM 程序化建模企业参数化模板的混合架构会是未来三到五年最主流的工程落地形态。它吃掉的不是“设计”而是“重复劳动”——这恰好是制造业里最贵的东西。第三嵌入主流CAD的原生助手会逐步成为标配。等你习惯了在SolidWorks或Fusion里用自然语言驱动参数化建模再回到纯手工草图的建模方式会感觉像在回到没有“自动保存”的年代。把text-to-cad从“演示”变成“工作流”我最大的体会就是一句话别指望模型替你创造让它帮你压缩重复。我在实际项目里最受益的是把法兰、支架、垫块这些“长年重复却又没人愿意优化”的建模流程脚本化后接到大模型上做语义路由。这比追求“AI凭空设计一台机器”靠谱得多也冷启动最快。如果你要入坑我的建议是从一个最简单的零件模板开始跑通文本到STEP的闭环再加上评测集一步步磨。等哪天你的基础零件库能通过自然语言驱动了你再回头去看这个方向的论文和新闻会发现理解完全不一样。

text-to-cad：自然语言驱动CAD建模的路线与实测

相关推荐

T3 Stack 全栈开发实战：端到端类型安全与项目搭建避坑指南

解决Windows下npm脚本执行策略错误的6种方法

从复制粘贴到模板生成：t3code命令行代码生成器设计与实践

更多资讯

企业AI项目失败的七大常见原因：从需求定义到运维的全链路复盘

YOLOv8数据集制作全流程：X-AnyLabeling标注与格式转换实战

Linux运维必备：MBR引导损坏修复实战与避坑指南

Claude Code：VS Code智能编程助手安装与配置指南

同城外卖系统开发：架构设计与性能优化实战

STM32实现SBUS协议解析与编码：遥控信号处理全攻略

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？