前阵子一个做机械设计的同行丢给我一句话“帮我生成一个法兰盘外径120内径60上面均匀分布四个腰型安装孔。”他说得轻巧我手工在建模软件里折腾了差不多半小时。也就在那几天我重新认真研究了Text-to-CAD这个方向——让自然语言直接变成可用的CAD模型。研究一圈之后我有一个很明确的结论这个方向听起来像玄学实际落地时考验的其实是工程化能力而工程化能力恰恰是可以复制的。这篇文章就聊聊我怎么理解Text-to-CAD、怎么搭一套能跑通的最小闭环以及中途踩过的那些坑。如果你是想尝鲜的业余玩家看完这篇文章大致能判断哪些工具适合你如果你是想把这套东西引入实际工作的工程师那后面的模板、工作流、排查思路可能更值钱。我默认你用过至少一款建模软件至少知道“尺寸驱动”“特征树”“B-rep”这几个词是啥意思但不要求你写过代码。1. 为什么Text-to-CAD比“文生图”难一个量级1.1 语义正确不等于几何正确文生图领域有个很有意思的现象一张图“看着像”就够了细节不对观众也能脑补。AI画一只猫胡须少一根没人会拿尺子去量。CAD模型完全不是这个逻辑。你说“直径120的法兰盘”生成一个119.7的视觉上根本看不出来但它装不到相配的管路上这就是废件。机械装配的间隙经常以0.1毫米甚至0.05毫米为单位这点容错空间放到生成式AI的逻辑里几乎等于不允许犯错。我印象很深的一次是让模型生成一个带腰型孔的安装板提示词里明确写了“孔间距85mm”结果输出文件的孔中心距是85.4mm。从屏幕上完全看不出来拿去打样却装不上。这让我意识到Text-to-CAD的难点根本不在于“能不能生成一个长得像的模型”而在于“生成的每一个数字是不是都可追溯、可控、可验证”。图像生成可以模糊几何生成必须确定这是两套完全不同的评价体系。1.2 自然语言天然缺少工程上下文“做一个支架”这句话在机械设计里可能有几十种理解。是电机支架还是管道支架是L型折弯件还是焊接件安装面在哪里用几个螺栓固定要不要加强筋要不要减重孔自然语言最大的问题是它默认听话的人具备大量背景知识而模型没有这个背景。更要命的是用户表达里经常出现“结实一点”“轻一点”“差不多就行”这类主观词。“结实”在材料力学里意味着壁厚、加强筋、材料选择在CAD模型里最终要落到一个具体的几何尺寸上“轻一点”又意味着挖空、减料、改变拓扑。语言模型可以把这些模糊词翻译成“增加壁厚到5mm”之类的结果但到底该增加到多少没有上下文它只能猜。所以在我的工作流里永远有一层“需求结构化”把模糊的自然语言先变成明确的参数和约束再谈建模。这一步看起来多此一举恰恰是整个流程里最能降低返工率的环节。1.3 输出必须是“可编辑的模型”而不只是一个模型现在很多AI生成模型的演示看着很酷输入一句话唰地一下出来一个复杂的曲面造型。但你去点那个模型发现它是一团三角网格没法改某个孔的直径没法调整凸台的高度也没法在原来的特征树上追加一个倒角。对普通用户这也许够了对工程师来说这就是一块“数字橡皮泥”只能看不能用。真正的CAD模型自带特征树拉伸、旋转、打孔、倒角、阵列每一步都可参数、可修改、可重放。用户说“孔径从16改成18”在特征树里改一个数字就行模型自动更新。如果AI生成的是那团“橡皮泥”想改孔径就等于重新做一遍。所以我一向认为Text-to-CAD的终极目标是“生成可编辑的参数化模型”而不是“生成一张好看的模型截图”。2. 两条主流技术路线先选对再动手2.1 端到端生成式模型从文本直接到几何体第一种路线是训练一个端到端模型输入文本输出体素、点云或隐式场然后通过等值面提取出网格。它最大的优点是“一次到位”一句话进去模型直接从数据分布里采样出一个几何形状非常符合普通人对AI的想象。我用这类模型试过不少创意造型比如“一个波浪边缘的花瓶”“一个扭转的灯罩”出图速度确实快形状也够天马行空。但问题也很明显拓扑不稳定。有时候圆孔变成多边形有时候曲面出现自交有时候壁厚忽厚忽薄。尺寸精度就更别提了它能保证轮廓“大概对”但做不到“毫米级对”。这种路线更适合概念设计、灵感预览、快速给客户看方案的阶段离“能直接拿去加工”还有距离。2.2 程序化建模路线文本先变成脚本脚本再变成模型第二种路线是我目前在工程场景里主推的让大语言模型理解需求然后生成一段参数化建模脚本由建模内核执行这段脚本最终得到带特征树的实体模型。你可以理解成身边坐了一位“听得懂人话的制图员”他拿到需求后先想清楚怎么建特征然后写下一串建模指令最后在软件里跑出来给你看。这条路线的好处非常直接。第一脚本就是参数化描述改一个变量整个模型跟着变天然满足“可编辑”需求。第二精度由建模内核保证外径120就是120不是“大约120”。第三脚本可以复用今天生成的法兰盘模板明天换个尺寸参数就能用。缺点也明显对提示词设计和规则库的要求高如果你直接丢给模型一句“给我生成一个机箱”它往往会写出一个语法正确但完全不满足装配关系的废脚本。2.3 第三条路线与我的选型建议还有人尝试“检索变型”的路线先在一个零件库里找到语义最接近的模型再通过AI修改尺寸和特征。问题在于检索结果的覆盖度非常有限“相似的”不等于“能用的”改尺寸还能应付改拓扑结构基本无能为力。三条路线各有各的坑我自己在实际项目中的选择逻辑很简单路线核心原理尺寸精度可编辑性适合场景主要成本端到端生成文本→隐式场→网格低仅概念级差网格难修改创意造型、效果图训练/调用生成模型程序化建模文本→建模脚本→实体高内核精确计算好脚本即参数工程零件、非标设计提示工程、规则库、模板维护检索变型语义检索→现有模型改造中依赖源模型中取决于源模型标准件改尺寸零件库建设如果你只是想做几个小摆件拿去3D打印端到端生成路线够用也省事如果你的目标是让CAD真正成为工作流的一部分想用它生成能装配、能修改、能出工程图的模型那最好把精力放在程序化建模这条路上。它没有端到端那么“性感”但它是目前最接近“工程可用”的方向。3. 一套能落地的五段式工作流3.1 总体架构从一句话到一份验证报告很多介绍Text-to-CAD的文章上来就聊模型多强很少聊“怎么把它装进一个可靠的流程里”。我的经验是真正占工作量的不是模型调用而是流水线设计。我目前跑通的方案是五段式需求解析、槽位校验、方案匹配、脚本生成、构建验证。每一步都有输入、输出和检查点缺了任何一个环节整体可靠性都会断崖式下跌。这五段里需求解析负责把用户的话变成结构化数据槽位校验负责查漏补缺方案匹配决定用哪套模板脚本生成把参数填进模板必要时让模型补写特征代码构建验证负责把模型编译出来、量一量、看一看。整个流程走下来用户从输入一句话到拿到一个经过初步验证的参数化模型大概在半分钟左右。3.2 需求解析与结构化输出第一件事是把用户的自然语言转成结构化数据。我自己习惯让模型输出JSON因为JSON好校验、好修改、好落库。比如“外径120、内径60、四个腰型孔的法兰盘”会被解析成下面这样{ part_type: flange_plate, parameters: { outer_diameter_mm: 120, inner_diameter_mm: 60, thickness_mm: 10, hole_count: 4, hole_type: slot, slot_length_mm: 22, slot_width_mm: 11, hole_circle_diameter_mm: 170 }, constraints: { units: mm, tolerance_class: medium, edge_break: 0.5 }, missing_fields: [], confidence: 0.9 }JSON中间层的价值在于你可以在不触碰建模内核的前提下检查参数是否合理。模型说“孔中心圆直径170”你得先判断这个值是否和“外径120”冲突——装在直径170的圆上孔就跑出外圆边界了。这种逻辑错误让用户在建模前发现比建模后再返工省钱省时间得多。3.3 槽位校验与默认值补全解析完成后流水线会检查必填项。法兰盘这种零件外径、内径、厚度是必填的孔数和孔径一般也是必填的。如果用户只说“要一个法兰盘”没给厚度我们的规则库会把厚度默认取为外径的十分之一或者查表得到一个常用板材厚度。这一步看起来简单真正的门道在于“默认值表”的积累。不同的零件类别要配不同的默认策略板类零件厚度通常和面积挂钩轴类零件直径和长度存在比例关系紧固件则要看标准件库。这些默认值不是从AI那来的是我们从过去几百份图纸里归纳出来的本质上是一种轻量级知识库。校验通过后系统会生成一份“解析确认单”展示给用户“我理解你要的是外径120、内径60、厚10、四孔均布的法兰盘请在建模前确认。”这么做的原因很朴素AI理解错需求很正常但如果在建模前让用户确认一次后面扯皮的概率会小很多。3.4 模板匹配与脚本生成拿到结构化的参数之后就该生成建模脚本了。我的方案是“模板为主生成式为辅”。规则库里为每种常用零件提前写好参数化脚本模板比如法兰盘模板、钣金支架模板、轴套模板模板接收参数数组后直接生成模型。这段脚本是我们自己维护的稳定、可控、不会突然抽风。模板覆盖不到的那些非标形状才轮到语言模型出场。比如用户要求“在外圆上生成六个均匀分布的弧形散热槽”规则库里没有对应特征就让模型写一小段局部建模代码。模型生成的代码不直接进生产环境先进静态检查、再进沙箱执行确保语法正确、变量有定义、不会操作不存在的对象。用一个大家都能看懂的伪代码来表示脚本生成结果大致长这样function main() { outerD params[outer_diameter_mm]; innerD params[inner_diameter_mm]; thick params[thickness_mm]; body cylinder(outerD / 2, thick); centerHole cylinder(innerD / 2, thick 1, center true); body difference(body, centerHole); holePoses [for (a [0, 90, 180, 270]) polarToCartesian(a, holeCircleD / 2)]; for (p holePoses) { slot roundedBox(slotLength, slotWidth, thick 1, r slotWidth / 2); slot translate(slot, p); body difference(body, slot); } }这段伪代码如果换成任何一款脚本化建模工具的DSL基本都能直接跑。它的核心思路是所有尺寸来自参数表不写死任何魔法数字。这样模型才能承担“改一个外径全模型自动更新”的职责。3.5 构建与自动验证脚本生成后流水线会调用建模内核在后台构建模型然后自动做一轮几何检查。我的检查清单包括体积是否为正数有没有非流形边外径、内径和孔中心距的实际测量值和设计值偏差在不在公差范围壁厚是不是小于材料能承受的下限。检查通过后系统会导出一份简易验证日志和一张模型预览图一起交给用户确认。用户说“没问题”模型才真正进入交付环节。这套自动验证虽然简单却帮我挡掉了大量肉眼看不出来的低级错误比如某个孔被布尔运算错误地“吞掉”了。4. 提示模板才是真正的护城河4.1 为什么通用提示词不可靠很多人觉得自己用不好Text-to-CAD是因为模型不够聪明我的体会恰恰相反问题出在提示词太“通用”。你让模型“生成一个带孔的法兰盘”它确实能生成但孔的数量、位置、大小全靠猜而这个猜测的结果往往不符合你的装配需求。语言模型对精确数值运算并不擅长让它自由发挥空间几何参数本质上是把最不该交给概率的地方交了出去。这也是为什么我把提示词模板看得比模型选型还重。提示词模板相当于给模型戴上了一个“限制思考范围”的笼子逼它先列参数、再写代码而不是自由联想。4.2 一份经过实测的六段式模板目前我在生产环境稳定使用的提示词模板是六段式角色定义、任务描述、几何拓扑声明、参数列表、输出格式、禁用行为。核心框架是这样你是参数化建模助手。你根据用户描述生成一段可执行的建模脚本。 要求 1. 所有长度单位统一为毫米不要臆造尺寸。 2. 在写代码前先用自然语言描述几何拓扑例如“主体是圆柱顶部有一个凸台凸台内有通孔”。 3. 所有参数必须来自给定参数表禁止擅自修改。 4. 输出格式为先输出JSON格式的参数确认再输出建模脚本。 5. 如果用户描述中存在冲突或缺失关键参数必须在JSON的missing_fields里指出不得自行假设。模板本身看着不起眼但它把最容易翻车的几件事全部提前管住了单位、参数来源、输出格式、缺失处理。相比自由对话式的提示词这套模板跑出来的脚本成功率高出不少。我不建议照着这个模板抄完就收工你可以根据自己的零件类型调整“几何拓扑声明”这一段把它变成你们最常画的那几类零件。4.3 数值和单位的处理技巧数值问题是Text-to-CAD里隐藏最深的地雷。同一个“50”用户可能说的是英寸、厘米或毫米。我的做法是在解析阶段就统一成毫米并在提示词里显式写“所有输入必须在JSON中标记单位并由解析器统一换算为mm”。千万不要让模型替你做单位换算它对单位的理解时好时坏正确率不足以支撑工程使用。换算逻辑由代码完成模型只负责把带单位的原始值提取出来。角度和多孔阵列也是重灾区。与其让模型自动理解“均匀分布”不如直接给它显式数组[0, 90, 180, 270]。在提示词里写“孔位角度由解析器计算后填入模型不得自行推导”。这看起来是剥夺了模型的发挥空间实际上是把几何计算的责任交还给确定性的代码正确率能提高一大截。4.4 “先拓扑后参数”的思维链用法“思维链”这个词在很多场景下已经被说滥了但在CAD生成里它是真有用。几何建模最难的是拓扑关系也就是“哪个特征在哪个特征上面、哪块实体和哪块实体求差”这些关系一旦错了参数再精确也白搭。所以我会在提示词里强制要求模型“先写几何拓扑描述再写参数最后写代码”。举个例子用户说“一个带凸台的底座凸台中心有个通孔”模型必须先输出“底座为长方体长度100、宽度60、高度10顶面中心有一个圆柱凸台直径40、高度15凸台中心有通孔直径16贯穿凸台与底座。”这段拓扑描述确认无误后再去生成代码。实践中这么做至少帮我减少了一半因为“特征顺序错误”导致的建模失败相当于人画图之前先打个草稿。5. 最容易被低估的环节几何后处理与格式兼容5.1 从网格到实体的差距我见过太多刚接触Text-to-CAD的人拿着一个输出网格大大咧咧地说“这不就能用了嘛”。但真正做机械加工的人看到网格模型通常会眉头一皱。网格由一堆三角面片拼成圆不一定是真圆曲面不一定是真曲面更关键的是网格没有“厚度”“内孔直径”这类实体语义没法直接进CAM软件编刀路。程序化建模生成的通常是B-rep实体也就是由精确的曲面边界描述的三维体这才满足制造业的基本要求。如果你拿到的是网格后面要做的工作可就多了补洞、缝合曲面、转成实体、检查自交。所以我在工作流里特别强调“导出的最终文件必须是实体模型”这个约束能帮你省掉整个后处理的噩梦。5.2 一套打磨过的清洗流程即便走程序化建模路线输出文件偶尔也会有一些小毛病比如布尔运算留下的小碎面、原点位置跑偏、单位标签丢失。我整理了一套固定清洗流程每次生成完都走一遍先验证文件头部的单位元数据确保是毫米检查模型的包围盒尺寸和参数表里的主尺寸做对比查非流形边和自由边有异常就回到脚本里修特征对所有圆角、倒角做一次视觉检查确认没有破面用自动测量工具复核关键孔径和间距最后重建一份特征树确认每一步特征都可编辑。这套流程前两步可以用脚本自动做后三步需要人工介入。别嫌麻烦工程交付拼的就是最后那一下细节。5.3 如何选择合适的导出格式格式选错了模型做得再漂亮也没用。我常用的选择逻辑是这样的使用场景推荐格式原因工程交换、CAM加工STEP保留B-rep实体语义兼容绝大多数工业软件3D打印STL或3MF三角网格即可3MF比STL更完整2D激光切割下料DXF直接导出截面轮廓方便排版协作修改特征树原生参数化文件保留完整建模历史和约束关系最容易犯的错是拿STL去应付加工厂。STL只记录表面三角形精度由网格密度决定放到数控编程软件里基本等于重新建模。STEP则记录了精确的曲面边界CAM可以直接读取加工特征这才是工业界的通用语言。5.4 交付前的验证清单每次交付前我会对着清单过一遍单位是否是毫米外径/内径/长度是否与确认单一致孔的数量和角向分布是否正确最小壁厚是否满足强度经验值装配接口的配合公差有没有标注导出格式是否符合下游需求。这些问题全部打勾之后模型才能算“完成”。这张清单我打印出来贴在工位上比任何AI工具都可靠。6. 三个真实翻车现场从现象到根因的完整排查6.1 单位错乱零件莫名放大了25.4倍有一次生成一个安装底板设计外径是100mm导出的STEP文件在CAM软件里打开后测量出来是2540mm整整放大了25.4倍。第一反应是建模内核出问题了但检查内核设置没有异常。接着看中间JSON发现解析结果里外径存的是100但单位字段写的是“inch”而不是“mm”。再往前查定位到提示词里没有强制要求模型在输出参数时保留原始单位标记模型把用户口头的“100”默认当成了“100英寸”。根因找到后修复很简单解析阶段强制JSON输出units_mm布尔字段模型输入原文里即使是“100英寸”也会在JSON里标出来再由统一换算逻辑转成2540mm并给用户弹出确认。这个坑给我的教训是AI生成任何一个数字都必须有单位来源和换算记录不能靠默认。工程上最怕的就是“两个系统默认为同一个单位”一旦默认错了后面全错。6.2 法兰孔位算错四个孔全转到了45度还有一次生成四孔法兰用户要求孔位“均匀分布”我心里默认是0、90、180、270这四个角度结果模型把孔位放到了45、135、225、315。屏幕上看也是均匀分布的视觉上完全没毛病但装配时对不上客户已有的安装孔。排查链路是这样的先打开生成的脚本发现角度参数来自一个数组数组是模型生成的生成时把“均匀分布”理解成了“从45度开始均匀分布”。这是自然语言的歧义不是几何计算的错。但我没有把“起点”这个关键信息显式传进模板系统的错。修复方式是在模板里把孔位角度改成由规则库计算一律从0度开始等分并且把角向位置作为显式参数写入需求确认单不再让模型自由理解“均匀分布”这句话。这段经历让我养成了一个习惯凡是涉及阵列、分布、对称这种几何规则一律用代码算不用语言模型推理。语言模型适合做语义理解不适合做离散几何计算。6.3 脚本偶发语法错误十次构建三次失败第三个坑最让人烦躁。程序化建模脚本有时候能跑有时候报错报错内容五花八门未定义的变量、多余的分号、调用了不存在的内置函数。现象完全随机但日志里有个共同点报错的代码都来自模型新写的“局部特征代码”而来自模板的代码从不报错。排查后发现模型在生成局部代码时会自己假设一些辅助函数存在或者把模板里的变量名改掉导致运行时找不到对象。修复方案分成三层第一层加静态检查脚本跑之前先做语法解析和变量作用域检查第二层加自动重试失败的脚本把错误信息喂回给模型让它修改一次第三层加模板兜底两次重试仍然失败就直接换成最接近的模板函数哪怕形状差点至少出来的模型是可用的、可手工调整的。三层防护上完之后整体成功率从七成不到提升到九成以上。这件事让我清楚地认识到Text-to-CAD不是一个“模型问题”而是一个“系统问题”稳定性要靠流水线设计来保证不能指望模型每次都能超常发挥。7. 要不要自己造轮子我的选型逻辑与建议7.1 什么时候值得自建一套如果你所在的环境满足这几个条件自己搭一套Text-to-CAD流水线是划算的第一重复件很多同样一个法兰盘、支架、底板每个月要画好多次第二非标定制需求来得又快又急客户今天给一句描述明天就要方案第三你们积累了大量历史图纸想把这些图纸变成可参数化调用的数字资产。这种情况下自建一套“解析模板验证”的轻量流水线一次投入换来的是以后每次出图都省下半小时到一小时复用次数越多越赚。同时你会发现最有价值的资产不是调用的模型而是你自己积累的那套参数模板和默认值知识库。7.2 什么时候别硬着头皮造反过来如果你的需求五花八门今天生成一个随身杯明天生成一个机器人玩具后天搞一套抽象艺术品那就别自建流水线了。这种场景下模板完全派不上用场规则库也没法覆盖直接用手头的端到端生成工具或者通用AI建模工具反而更快。自建方案的价值在于“稳定复现特定类型”不在“什么都能生成”。另外一个很重要的判断标准是你们有没有人能判断模型生成结果对不对。如果团队里连一个能用CAD做基础测量的工程师都没有那自建流程也守不住质量底线。AI生成的东西永远需要人工复核没有复核能力就不要盲目上量。7.3 未来半年值得关注的方向Text-to-CAD这段时间发展很快我关注的方向主要有三个。第一是多模态输入用户既能说“做一个法兰盘”又能同时发来一张手绘草图模型把文字和图像信息融合后再建模这比纯文本描述信息量大得多。第二是直接编辑特征树未来的模型不再从零生成脚本而是直接修改现有模型的特征节点比如“把第3个孔的直径从16改成18”这种操作更贴近工程师真实习惯。第三是装配体级别的生成一次生成一整个部件而不只是单个零件零件之间的配合关系也一并约束好。不过说句实话即便模型能力继续往上走我认为很长一段时间内“程序化建模兜底”都是必需的。语言模型负责把意图翻译成确定性的参数剩下的几何计算交给建模内核这条路线在精度和可编辑性上的优势太明显了。我自己做完这套东西之后最大的感受是Text-to-CAD想从演示变成生产力瓶颈不在模型本身而在工程边界。谁能把模糊的自然语言翻译成确定的参数和约束谁就能真正把它用起来。所以如果你也想入这个方向别一开始就追求生成多复杂的零件先拿一个你每天都在画的零件练手把模板、默认表、验证清单这三件事做扎实后面大概率会越用越顺。