1. 我们真的做好准备用一句话生成三维模型了吗先不扯远景。2024年ZC建团队内部做了一个粗糙的尝试把一张法兰盘的工程描述丢给当时市面上最主流的几个文生3D模型让它们输出STEP格式的CAD模型。结果很有意思——法体外观确实接近法兰盘圆盘、螺栓孔分布、中心孔径都有模有样但一量尺寸螺栓孔间距差了0.8毫米配合面平面度完全失控模型导入SolidWorks之后特征树是空的这意味着后续根本无法做参数化修改。换句话说它生成的是看起来像法兰盘的三角网格不是能进产线的CAD模型。这个矛盾贯穿了整个text-to-cad赛道文本转自然语言描述容易文本转可编辑、可制造、带约束的CAD模型难。难点不是把文字变成模型而是把文字变成符合工程语义的模型。前者是生成问题后者是表示问题——而表示形式决定了这个工具到底是个噱头还是能真正嵌入研发流程的生产力工具。在开始拆解技术方案之前先给这篇文章定个锚点我不会罗列所有所谓一句话生成3D模型的产品让你选型而是把当前text-to-cad的主流技术路线拆开讲清楚每一条路线背后的原理、能做什么、卡在哪里、以及作为工程师你能用它做什么。后面还会给一个可以本地跑通的最小实践案例以及我从几十次失败测试里总结出的几条关键经验。这篇文章适合三类人正在评估text-to-cad工具能不能接入工作流的机械工程师和产品设计师想搞清楚大模型生成CAD底层到底怎么回事的技术负责人以及打算自己做点原型验证的开发者。如果你只是想看概念介绍那可能浪费了这些字因为问题的答案从来不在PPT里在实测结果里。2. 两条技术路线一条通向看起来像一条通向用得起来2.1 生成式路线从文本直接生成三维几何先看最直观的一条路用扩散模型或Transformer直接生成三维数据。这条路线继承了文生图的技术基因——CLIP文本编码器负责理解语义扩散模型在潜空间里逐步去噪最后解码成三维表示。目前常见的输出表示有三种体素Voxel、点云Point Cloud、神经隐式场Neural Implicit Field 常用SDF或Occupancy Field表示。这三种各有明显缺陷。体素受限于分辨率256³的体素网格看起来细腻但转换为CAD实体时边界锯齿严重圆角、倒角完全失真点云只有离散点没有拓扑关系后续做曲面重构误差很大神经隐式场是当前生成质量最高的选择它的核心思路是用一个神经网络学习几何表面的符号距离函数输出连续的距离场可以做任意分辨率的Marching Cubes提取网格但提取出来的仍是网格Mesh不是参数化实体B-Rep即Boundary Representation。这是生成式路线的天花板它生成的是数字雕塑不是工程模型。3D打印原型、游戏资产、影视道具这类场景对尺寸精度要求低视觉正确即可生成式路线完全够用。但一旦进入机械设计领域模型需要进CAM做刀路、进CAE做仿真、进BOM做物料管理网格数据根本无法支撑这些下游环节。就像你描述一个杯子AI给出的是一张杯子的高清照片而不是一张标注了直径80mm、壁厚3mm、材质304不锈钢的工程图纸——前者能看后者能用。2.2 程序化路线让大模型学会调用CAD内核另一条路线走了完全不同的逻辑不让模型直接生成几何而是让模型生成一段程序由CAD内核执行这段程序来构建模型。输入的自然语言经过LLM大语言模型的语义理解后被翻译成CadQuery、OpenSCAD、SolidPython这类程序化建模脚本再由脚本驱动内核完成建模。这条路线本质上是把问题从几何生成变成了代码生成它的核心优势是程序里承载的每个尺寸、每个约束、每个特征都是参数化的脚本执行完毕生成的是真正的B-Rep实体模型带完整特征树和参数后续修改、装配、分析全都顺理成章。举个例子。输入直径60mm、高30mm、开四个均匀分布的M6螺纹孔的圆柱底座程序化路线生成的CadQuery脚本大致逻辑是先创建圆柱体再定位四个螺纹孔位逐个添加螺纹特征。整个过程完全可追溯、可编辑。碰到尺寸不符你只需要改脚本里的一个直径参数重新执行即可不需要重头再生成一遍。这是工程世界里最熟悉的那种建模方式。但这条路也有它的难处LLM生成代码的准确率不够稳定——如果模型对CAD库API掌握不牢生成的脚本会有函数签名错误、逻辑缺失如果涉及复杂的拓扑操作比如多个特征之间的布尔运算顺序错了生成的模型就会出现应该圆角的地方尖角该打通的孔没打通这种低级错误。实测下来简单零件几何体基本特征这类小任务的成功率能到七八成但再往上的中等复杂度零件成功率会断崖式下跌。两条路线对比一下就很清楚生成式路线下限高上限低适合看过就行的视觉场景程序化路线下限低上限高一旦跑通就是端到端可用的工程模型。目前真正在CAD领域做落地的项目绝大多数押注的是第二条路。2.3 混合方案两条腿走路的现实选择现实中更多产品采用的是混合方案先用生成式模型快速给出一个视觉草案让用户确认大方向对不对确认后再切到程序化路线重新生成参数化模型或者用一个专门的模块把网格模型反向转换成B-Rep。这个流程很符合人的工作习惯——先草图后细化。但要注意网格转B-Rep逆向建模这一步目前仍然没有完美解尤其是包含自由曲面比如产品外壳时转换出来的曲面质量和原始设计意图很难保证。如果产品是规则几何体占主导机加工件、钣金件、结构件混合方案的可靠性会高很多如果是复杂曲面造型消费电子外壳、汽车内饰那还是需要正向建模软件里的曲面工具兜底。3. 从能看到能用还缺什么实测了几个代表性项目3.1 一个开源方案的完整跑通流程纯讲原理容易虚我拿一个代码仓库实际跑一遍用最直接的方式展示程序化路线的工作流。这里选的是一个开源项目核心思路是让LLM生成CadQuery脚本间接实现text-to-cad。工程上它属于源于真实需求的简化版但胜在完全透明能看清每个环节发生了什么。环境准备是这样的需要Python 3.10以上版本安装CadQuery库以及一个可用的LLM推理入口。我用的是本地部署的小模型如果你有云端的API Key也是一样的逻辑。先看一段输入。我给的指令是create a mounting bracket, 80mm wide, 60mm tall, with two 6mm holes on the horizontal face and a 30mm slot in the centerLLM经过推理后生成的CadQuery脚本大致像下面这样我做了一个简化版展示核心逻辑import cadquery as cq # 主体板80宽 x 60高 x 5厚 bracket ( cq.Workplane(XY) .box(80, 60, 5) .edges(|Z) .fillet(2) # 给棱边倒圆角 ) # 中心开一个30mm宽的槽 bracket ( bracket.faces(Z) .workplane() .slot2D(30, 10) .cutBlind(-5) ) # 水平面上开两个直径6mm的孔 bracket ( bracket.faces(Z) .workplane() .center(-20, 0) .hole(6) ) bracket ( bracket.faces(Z) .workplane() .center(20, 0) .hole(6) ) # 导出STEP格式装配、后续加工都要用这个格式 cq.exporters.export(bracket, bracket.step)执行这段脚本CadQuery内核会完成构建实体、布尔运算、倒角等操作最终输出一个带完整B-Rep拓扑的STEP文件。把它拖进FreeCAD或者SolidWorks你能看到完整的特征树板是板、槽是槽、孔是孔每个特征都能单独编辑。这就是程序化路线相对生成式路线的核心价值模型不是一坨死几何而是活的参数化特征树。3.2 实测暴露出的三个典型问题跑通了流程问题也随之而来。我用同样的方法连续测试了几十个零件描述把高频的失败样本做了分类基本可以归成三类。第一类API调用错误。模型记住了CadQuery的类名但对个别方法的参数签名理解错误比如hole()方法传入的是直径还是半径搞反了或者slot2D()的长度参数顺序错误。这个根源是模型训练数据里CadQuery代码的占比太低它对API不够熟。第二类逻辑遗漏。描述里要求四个角各有一个安装孔模型只生成了两个孔。这种问题的本质是LLM在从自然语言到代码的转换过程中丢失了约束——它在语义理解层面知道有四个孔但代码生成时遗漏了循环或数组。第三类几何拓扑错误。这一点更隐蔽生成的脚本语法完全正确CAD内核也能执行但结果是错误的几何体——比如一个应该挖穿的槽因为工作平面workplane选错变成了只切了一半的盲槽或者两个特征相交的部分布尔运算结果不符合预期。这类错误在语法层面完全看不出来必须进入三维环境里做几何检查。这些问题单个看都能修但累加起来就决定了这条路线的可用性边界。我的实测结论是简单零件2~5个特征成功率大约在60%~75%中等复杂度零件包含阵列、多工作平面、复杂布尔运算成功率会掉到30%以下。这个数字距离生产可用还有明显差距但已经足够说明程序化路线是可收敛的——因为错误模式是可以枚举、可以修复的而不像生成式路线那样存在天花板级别的表示鸿沟。3.3 为什么 选TypeScript而非纯Python再补一个选型话题。部分工程视角的实现会用到TypeScript也就是微软那套TypeChat方案。它的设计逻辑其实很有启发不依赖结构化输出约束而是给LLM一个类型定义做引导让它在自然语言和强类型类型之间做自动翻译。你可以把类型定义当成给模型的一张答题卡它必须在已有的格子里填答案这样从自然语言到接口调用的转换会受到明确约束错误的概率大幅下降。选TypeScript而不用Python做推理链路主要有几个原因类型系统带来的语法约束能力在Python里非常弱而TypeScript的interface天然就是一类约束模板另外整个前端生态和引擎生态跟JS/TS的衔接更顺滑你可以在一个网页里完成从文本输入到三维预览的全链路。当然最终生成脚本仍然会是CadQuery或OpenSCAD这类Python系工具因为CAD运行时生态目前还是Python更完整——推理用TS建模用Python这种混搭架构在实际项目里很常见。4. 当理想照进生产工程化落地里的那些脏活4.1 生成后校验是不能省的环节如果你只是做原型验证LLM生成脚本、你看一眼顺眼、导出STL去3D打印那校验环节可以省略。但一旦要进入生产环境校验必须自动化不能靠人眼。这是我踩过最深的一个坑——有次我生成的支架模型整体看起来完全正常尺寸也对结果后面的装配仿真怎么都过不去。排查下来才发现模型里有两处极小的非流形边non-manifold edge肉眼根本看不出来但下游CAE求解器一碰到非流形几何就直接崩溃。实用的校验手段分三层。第一层是语法校验脚本能不能被执行这一步靠CadQuery自身的解析器就能完成。第二层是几何校验检查生成实体的体积是否大于零、边界表示是否闭合、是否存在非流形边这个可以用开源几何内核的检测工具来做或者直接用FreeCAD的Part模块跑一遍checkGeometry()。第三层是工程约束校验关键尺寸是否落在公差范围内、孔距是否符合标准、壁厚是否满足最小加工要求——这一层是机械设计特有的没有任何通用工具你得基于业务把自己的设计规范固化成校验脚本。三层全过模型才算合格。4.2 约束注入让模型学会工程语义只给LLM一句生成一个法兰盘它生成的模型大概率不符合任何设计规范——螺栓孔数量可能是5个法兰标准里通用的是4、8、12等壁厚可能完全没考虑材料强度。要解决这个问题光靠提示词是不够的你需要把约束注入到系统里。目前实践中比较好用的方式是约束模板化。把常见零件的设计规范整理成结构化约束描述比如法兰盘螺栓孔数量必须是4的倍数两孔中心距不得小于2倍孔径最小壁厚不得小于3mm然后把这些约束拼接到输入提示词中让LLM在生成代码时时刻带着这些紧箍咒。这其实是一种工程语义的注入方式——模型本身不懂机械设计标准但你把这些标准翻译成自然语言喂给它它就能在生成过程中遵守大部分约束。更进一步的做法是约束后置校验循环修正生成完模型后自动跑一套尺寸和拓扑校验脚本发现违规就让LLM基于错误信息重新生成。这个循环设计得好能把最终成功率大幅提上去。我实测从循环修正前的60%左右提到80%以上是投入产出比最高的一项改造。4.3 人机协作把全自动改成半自动我需要说一句可能不太讨喜的话在可预见的未来text-to-cad不太可能取代设计师它最现实的定位是设计助理。全自动流程在简单标准件上有机会跑通但到了复杂产品设计阶段设计意图的传递远远超过一句自然语言能承载的信息量——重量目标、成本约束、装配顺序、制造工艺、维修便利性这些东西没法用一句话表达。更好的方式是重新设计交互流程设计师给出初步描述LLM生成设计草案设计师在CAD里对其中的关键特征做直接操作拖拽尺寸、调整截面、增删特征操作完之后系统把改动反馈给管线再继续生成下游内容。这里的关键不是让AI全包而是让AI承担从意图到草案这一大步把设计师从从零开始的建模里解放出来把精力放到真正需要经验和判断的部分。这也是我在团队内部推动的方向。5. 常见的坑和反模式别踩5.1 把能生成模型等同于能替代建模软件这句话是很多项目翻车的根源。模型生成只是前端一步真正的设计工作流涉及特征编辑、装配约束、运动仿真、工程出图等一连串环节。一个text-to-cad工具哪怕生成质量再高如果输出模型不能顺畅地被下游工具链消费它的价值就是打折的。评估一个工具不要只看它生成的模型长什么样要看它能不能导出带特征树的B-Rep、能不能在主流CAD里流畅编辑、能不能支持后续的CAM/CAE流程。5.2 对LLM的尺寸困惑掉以轻心你可能觉得奇怪LLM理解直径60mm这种明确参数能出什么错我在实测中遇到的错误包括将直径直接当半径建模、公制英制混用描述里写英寸模型里用了毫米、大量使用整数而忽略小数精度。这类问题不致命但如果不加修正批量使用时累积的错误会消耗大量校对时间。解决方式很简单在提示词模板里强制标注参数命名规范并在后置校验脚本里逐项核对关键尺寸。5.3 忽略非几何信息CAD模型不只是几何。材料、公差、表面处理、热处理状态、标准件编号这些是生产制造不可或缺的信息。但目前的text-to-cad专注于几何生成对非几何信息的表达能力几乎为零。输入制造一个45号钢、表面发黑处理、关键配合面公差H7的底座生成模型里根本不存在这些属性。如果你需要的是面向制造的完整交付物比如MBD模型现阶段还是得在CAD系统里手工补充属性信息。5.4 任务复杂度评估缺失不少团队立项的时候喜欢拿最复杂的零件做目标结果demo演示翻车之后整个方向被打上不可行的标签。我的建议是先从占企业零件总数六七成的简单件切入——轴套、垫片、支架、法兰、盖板这类规则几何体占主导的零件成功率已经足够支撑半自动批量建模的落地场景。一上来就搞涡轮叶片、腔体类零件那不是不行而是当前的模型能力和工程校验体系还撑不起来。分阶段迭代先把高重复度、低复杂度的建模任务自动化再逐步往复杂件推进这比一开始就all-in复杂场景稳健得多。6. 下一步往哪走我的一些看法和实操建议这个领域还在快速演进我没办法给你一个三年后一定这样的预言但基于目前的进展有几个方向值得关注。第一是LLM与CAD内核的接口标准化。现在每个方案都自己定义一套提示词模板和API映射逻辑互相之间完全不通。如果未来能形成一个类似CAD领域的SQL的标准化中间表示让LLM生成统一的建模指令集再翻译到不同CAD内核CadQuery、OpenSCAD、商用CAD的API整个生态的繁荣程度会完全不同。这个工作量大但价值极大。第二是模型微调方向的转移。现在大家用的都是通用LLM对CAD专业知识的覆盖严重不足。更有效的做法是基于通用模型做领域微调喂入大量自然语言描述-CAD脚本配对数据让模型对CAD API和常见设计模式的掌握变得很熟练。这比在提示词工程上死磕更根治。从数据生成的角度来说现在有很多开源零件库可以自动化生成配对数据这条路我自己已经在尝试了。第三是几何推理能力的独立。有些错误不是语言理解的问题而是几何推理的问题——这个槽该从哪个面开始切这两个特征会不会自相交倒角的顺序对不对这些需要三维空间直觉。未来的模型如果能把几何推理能力从语言模型里剥离出来变成一个独立的模块或者用神经符号方法增强text-to-cad的可靠性和复杂度边界都会有明显提升。最后给想动手试的人三点建议。先跑通一个最简单的端到端demo零件复杂度控制在三五个特征以内把管线里的每一步看仔细花时间建一个自己团队的设计规范校验库这个比调模型本身更有长期价值不要期待单次生成的完美准确率把生成-校验-修正的循环当成系统的核心设计理念而不是生成完了就完事。我自己踩了一圈坑之后最深的感受是text-to-cad在未来几年内会和当年的参数化建模普及初期很像——从看起来很神奇到难用得想砸键盘再到日常设计的一部分中间隔的不是模型参数的大幅提升而是工程化、校验体系、交互设计这些脏活被一个个填平。说得好听叫生成式设计说得务实点它就是构建在自然语言之上的批量建模自动化。如果你能接受这个定位它能帮你省下的时间会比你预想的多得多。
