最近这几年AI生成领域最火的方向一个是text-to-image一个是text-to-video但真正让我这种天天和三维模型打交道的人兴奋起来的其实是text-to-cad。今年这个方向密集出了不少成果从学术界到工业界都在往里面砸资源。我也花了不少时间把主流方案扒了一遍并且用实际需求去测了它们的效果所以这篇文章想把text-to-cad到底是怎么运作的、目前主流模型各自什么水平、以及实际落地时有哪些坑一次性讲清楚。无论你是做机械设计的、做3D打印的还是做游戏建模的这篇文章应该能帮你省下不少自己摸索的时间。先说个总体的判断text-to-cad的难度比text-to-image高一个量级因为自然语言本身是模糊的而CAD模型要求的是精确的几何拓扑关系。生成一张“看起来像那么回事”的图和生成一个“能进CAM加工、能出工程图”的实体模型是完全不同的两件事。当前各家模型在这件事上的完成度也远远没有达到大部分人想象中“输入一句话就能出生产级模型”的程度。1. 为什么text-to-cad突然成了焦点从“画图”到“编程”的范式转换如果只是看标题很多人会以为text-to-cad就是把文字描述变成三维模型和AI绘画本质上是一回事。但真正深入研究之后你会发现这个方向最核心的转变是把“建模”这个行为从一种类似绘画的几何操作变成了一种类似写代码的生成过程。传统的CAD建模本质上是在描述一个设计意图你要画一个圆然后拉伸然后挖孔然后倒角。每一步都是明确的操作模型是这些操作的累积结果。而text-to-cad要做的事情恰恰是把自然语言里的设计意图直接翻译成这一串操作序列。换句话说模型生成的不是三角网格而是应该生成一段“建模脚本”或者说程序化指令让CAD软件能按步骤把实体重建出来。这个范式转换的意义非常大因为它决定了text-to-cad和应用层的兼容性。如果你生成的是网格文件那它在工程软件里的价值极其有限——不能出工程图、不能做装配、不能进有限元分析。但如果你生成的是建模历史那就意味着生成的模型继承了参数化能力用户可以回到草图、回到特征树去修改尺寸、调整形状。这是完全不同的工作流价值。也正因为如此目前主流的text-to-cad模型普遍采用了“代码生成”的思路非常默契地把问题定义成了“根据文本描述生成一段能重建出正确几何体的程序”。这个程序可以是OpenSCAD代码可以是Python脚本也可以是CAD内核原生的命令流。1.1 设计意图的层次拆解想把“一个带圆角的长方体底座中间有个通孔”这句话转化成可执行的建模代码模型必须完成三层理解。第一层是语义识别搞明白物品是什么、有哪些特征第二层是参数提取把“长方体”“圆角”“通孔”这些描述背后的关键尺寸、位置关系挖出来第三层是操作排序就是用什么样的建模顺序去构建最合理。举个例子如果你让模型生成一个“法兰盘”它不能只是生成一个看起来像法兰盘的网格它必须知道法兰盘的典型结构参数一个圆柱主体、中间一个通孔、圆周上均匀分布几个螺丝孔。这些参数可能没有在文本里明说但模型需要靠它的先验知识去补齐。这就是text-to-cad区别于普通生成模型的最大挑战——它需要“常识”级别的工程知识而不只是视觉上的“像”。我在实际测试中发现很多模型在这三个层次上的能力是严重不均衡的。它们在语义识别上做得不错能听懂“带孔的方块”是什么意思但在参数提取上经常出问题比如生成的孔在边缘位置或者尺寸明显不符合工程常识在操作排序上更是参差不齐有的会把孔放在拉伸之前做结果拉伸把孔覆盖掉最终模型是个实心的。1.2 为什么“可编辑”比“好看”更重要关于text-to-cad有一个很反直觉的点在大部分场景下我们不关心模型看起来多精致而关心它能不能改。如果你只是想找一个能在渲染图里当背景的模型那用AI生成网格模型就够了甚至现在许多游戏建模工具就能做到。但在真正的工程设计流程里一个模型被创建出来的时刻恰恰是它开始被修改的时刻。设计本质上是一个反复迭代的过程没有工程师会指望输入一句“设计一个支架”就拿到最终版本。真正的需求是拿到初版之后我能说“把壁厚从3毫米改成4毫米”“把圆角半径加大”“把四个螺丝孔改成六个”然后模型要同步更新。目前大部分开源text-to-cad模型在这件事上都不完全达标。它们能生成看似合理的程序代码但代码的逻辑结构往往很脆弱如果你改一个关键参数后面一系列操作可能就崩了。这一点我会在后面的实测部分展开说这里先给出一个结论不要指望开箱即用地拿到可编辑模型大概率你需要做一些代码层面的补补改改。2. 主流text-to-cad模型的技术路线拆解现在市面上能看到的text-to-cad相关工作大致可以分成三条技术路线每条路线有自己的一套逻辑也有各自的优缺点。把这个底层的路线搞清楚了你才能真正看懂这些模型在干什么、上限在哪、瓶颈在哪。2.1 路线一基于大语言模型的文本直接生成代码这类方法的代表是Text2CAD还有后来的不少变体。它们的核心思路非常简单粗暴用大量“文本描述对应CAD代码”的数据对去微调现有的代码大模型让模型学会把自然语言翻译成生成脚本。具体来说研究者会构造一个大规模数据集里面每条样本包含一段文本描述以及一段用某种程序化语言写成的建模代码。这个代码可以是OpenSCAD的脚本也可以是更接近真实CAD操作的构造命令流。然后拿这些数据去微调一个本来就会写代码的LLM比如CodeLlama或者StarCoder之类的。训练完成之后输入一段文本模型就会输出一段代码把代码交给对应的CAD解释器执行就能得到三维模型。这条路线的优势非常明显工程复杂度低因为LLM的技术栈已经很成熟泛化能力相对好因为LLM本身就积累了大量程序知识而且天然支持编辑因为生成结果就是一段可读的代码。缺点也很明显。首先生成的代码大概率只在语法上正确粗糙得没有任何工程美感因为模型是在“模仿”代码的样子而不理解制造工艺很多模型生成的几何体其实是一堆基本体的布尔运算勉强堆出来的特征数量完全不成比例。其次模型的成功率受限于数据集的规模和多样性如果你要它生成一个超出训练分布的特殊零件它就会给你胡编一个。我在实测里就遇到过让模型生成一个“齿轮泵壳体”的情况它直接给我生成一个像某种艺术装置的东西看起来结构复杂实则完全没有泵壳应有的油路结构。要想把这条路跑通数据是关键中的关键。还是以Text2CAD为例它用的数据集是经过严格筛选的涵盖了从简单几何体到中等复杂机械零件的几万个样本。这个规模对语言模型来说其实很小所以模型的泛化能力更多是靠LLM本身底子撑着而不是靠微调数据集。2.2 路线二从图像到文本的间接生成第二条路线也是目前不少工业级产品在用的思路先让模型根据文本生成多视角图像然后再从图像重建CAD模型。代表工作是CAD-Creator等。这条路线为什么会存在原因很简单这两年text-to-image技术太成熟了特别是扩散模型生成高质量图像的能力已经非常稳定。研究者就想了一个取巧的办法先让扩散模型根据文本描述画出这个物体的多视角图再从这些图像里提取几何特征最后用传统的3D重建算法给构建成模型。这样可以把自然语言理解的重任交给图像模型而CAD模型生成变成图像到几何的转换。这个思路在实践中确实能生成比较“好看”的模型因为图像模型对人类审美的把握往往好过代码模型。但问题也不少。第一从多视角图像重建出来的几何通常是一个三角网格丢失了参数化信息后续编辑能力很差。第二重建精度受限于图像的分辨率和视角数量很多细小的特征会被抹掉比如螺纹、小圆角、小孔阵列。第三图像到CAD模型这一步目前学术界也没有完美解决工业界多半是靠人机交互半自动完成。不过对于“先要一个外观概念模型看看感觉”的场景这条路是最合适的生成的东西有视觉冲击力拿去做方案展示很方便。我们做设计时经常需要给客户看概念效果图这个路线出来的东西就很能打。2.3 路线三端到端的CAD原生生成模型第三类是少数派目前还处于比较早期的研究阶段但它们的技术潜力被普遍看好。这条路线试图训练一个模型直接从文本生成结构化的B-Rep边界表示模型一步到位不经过代码、不经过网格。B-Rep是CAD内核里真正存储几何的方式它由一系列的面、边、顶点以及它们的拓扑关系构成。如果能直接生成B-Rep那意味着生成结果天生就是为CAD系统准备的精度极高且天然支持后续的特征编辑。难点在于B-Rep的数据结构和文本语言的序列结构差异太大B-Rep是高度拓扑化的结构没有天然的“从左到右”的顺序一些细节特征的表示极其复杂模型很难直接输出。当前的研究多是把B-Rep转成某种序列化表示然后再生成。但这个转换过程本身就有信息损失所以端到端模型目前的成功率普遍不高很多只能处理棱柱体之类极其简单的形状。我个人对这条路线的判断是三五年内它会是text-to-cad的主攻方向因为只有它真正解决了“CAD原生”的问题。但现在来看直接拿来用还为时过早。2.4 三维数据表示网格、B-Rep与程序化脚本的取舍把三条路线放在一起对比之后你会发现一个绕不开的核心问题到底用什么数据格式作为模型的输出。这也决定了你的使用场景是渲染展示还是工程应用。输出格式代表性模型优点缺点适合场景程序化脚本OpenSCAD/PythonText2CAD系列可编辑、占用小、参数化成功率受限于数据集、工程结构粗糙设计早期探索、参数化零件三角网格Mesh图像转化类模型视觉效果好、生成稳定不可编辑、精度低概念展示、渲染、3D打印原型B-Rep原生学术前沿模型精度最高、完全工程可用成功率低、技术不成熟远期目标我自己在做实际项目的时候会同时保留脚本和网格两种输出。脚本用来做结构推敲网格用来做效果图这样各取所长。如果你只依赖其中一种后面一定会发现很多事做不了。3. 复现与部署时最容易被忽视的工程细节如果你只关注论文里的效果图你大概率会高估这些模型的成熟度。真正把它们跑起来、接入到自己的设计流程里需要处理下面这些工程细节。我在复现开源项目的时候几乎每个环节都踩过坑分享出来希望对你有用。3.1 大语言模型改造的适配问题目前最热门的几个开源项目本质都是拿开源LLM的底座去微调。但直接用原始LLM是不行的因为原始LLM的tokenizer是按自然语言统计的对建模代码里的特殊符号、缩进、嵌套结构统计得不够好。我实际操作下来的经验是最好在通用的代码数据集上先做一轮领域预训练然后再做监督微调效果会好不少。另外有个细节就是上下文长度的控制。建模代码通常不会太长但描述文本可能包含很多约束信息比如尺寸、位置、数量、公差等。如果上下文塞得太满模型容易在后面的代码生成里丢失前置信息。我测下来比较稳妥的做法是把描述文本和已有的代码分隔符做得很清晰让模型能明确知道哪些是输入、哪些是它要生成的。3.2 模型与CAD内核的数据交换这是最容易翻车的一个环节。模型生成脚本之后脚本必须调用某个CAD内核来执行建模。但不同内核的API差异巨大有的用开源内核如OpenCASCADE有的用商业内核如Parasolid。脚本是为哪个内核写的就只能跑在哪个内核上。举个例子如果你用Text2CAD生成输出那大概率是基于OpenCASCADE的Python脚本但如果你习惯用SolidWorks这中间就差了一个文件格式转换的步骤。好在现在STEP格式已经基本统一了你可以在内核里把脚本跑完再导出STEP文件再导进自己的CAD软件里。这个链路虽然多了一步但确实可行。我在实际操作中是用FreeCAD的Python控制台配合脚本来执行的效率不高但胜在免费可控。如果你有条件上商业内核速度会快很多但成本也上去了就看项目预算是否允许。3.3 后期处理模型修复与特征整理的必要性说实话我在测试中几乎没遇到过一次性生成的模型能直接用的情况。哪怕模型生成成功后续也总会有一些小问题破面、非流形边、过薄的壁、悬空特征等等。这时候就需要在CAD软件里做模型的修复和特征整理这个步骤跟3D扫描模型后期的处理很像需要一定的几何功底。我的建议是不要期望AI生成模型是完美的而是把它当成一个初稿一个在概念设计阶段能快速给你方向感的草稿后续必须要有人类工程师介入做细节打磨。团队里需要有一个熟悉CAD软件的人来处理这些模型。4. 实测体验用真实需求考验主流模型纸面上的分析说再多都不如实际跑一遍来得直观。为了写这篇文章我把几个代表性的开源模型都跑了一遍设计了一个统一的测试基准测试结果相当有意思。4.1 测试基准的设计思路我选了五个典型问题从简单到复杂覆盖了不同的设计场景生成一个20mm边长的立方体中心有一个直径10mm的通孔 —— 最简单测试基础特征能力生成一个带法兰的圆柱管法兰上均匀分布四个安装孔 —— 中等难度测试阵列和复合特征生成一个齿轮泵后盖壳体有进油口、出油口和一圈安装孔 —— 高难度测试领域知识生成一个带有加强筋的L型支架底座上有四个沉头孔 —— 中等偏上测试非对称特征生成一个蜗轮蜗杆减速器箱体的一半 —— 极高难度测试复杂装配结构理解这五个问题我没有给任何额外的参数提示完全依赖模型自己的先验知识看看它在“自由发挥”条件下能到什么水平。4.2 各模型的表现对比与典型失误实际测试结果有些出人意料。第一个测试是最简单的立方体带孔基本所有模型都能完成没有太多分歧。但从第二个测试开始差距就出来了。我重点说几个典型的失败模式。第一个是生成圆角特征时有些模型会生成非常夸张的圆角半径看起来像是一团黏土捏出来的东西完全没有机械零件的干脆。第二个是阵列特征的处理让生成四个分布均匀的螺丝孔结果四个孔的位置偏移看起来随意得像随手打的。第三个是布尔运算的综合运用有些模型生成的壳体内部是完全实心的或者几个腔体之间莫名其妙连通这种在制造上直接就是报废件。我把五个测试的结果汇总成了下面这个表格评分的维度列出来供大家参考测试题语义符合度特征完整性参数准确性工程合理性综合印象立方体带孔高高中中中规中矩能用法兰圆柱管中中低低孔距失准需要大改齿轮泵壳体低低低低结构错乱仅有概念价值L型支架加强筋中中中低能识别主要特征尺寸不对减速器箱体低极低低极低看起来像实则完全不成立这个结果让我更坚定了一个判断text-to-cad目前能稳定处理的是“基础特征组合型”的零件比如板、轴、孔、槽、圆角、倒角这些基本特征的组合。一旦涉及到需要真正的领域知识来补全结构关系时模型就撑不住了只能给你一个看起来像那么回事、实则经不起推敲的东西。4.3 成功用例拆解什么样的文本描述最容易生成好模型在测试中也有成功案例而且规律非常清晰。那些输出质量高的样本描述文本都有一个共同特点结构化的、显式给出的几何和拓扑信息。举个例子同样是生成一个支架低质量描述“给我设计一个支架”高质量描述“生成一个L型支架主体是一个40mm乘以40mm乘以5mm的竖直板水平底座是一个40mm乘以60mm乘以5mm的平板两者焊接连接。竖直板顶部有一个直径8mm的通孔水平底座上有两个直径6mm的沉头孔间距30mm位置居中”后者生成的成功率和质量明显高于前者这不难理解因为模型没有能力去推断你想要的尺寸它只能从训练数据里抽一个它见过的最接近的先验值。所以如果你想利用text-to-cad提高效率我的第一条建议就是在描述里把几何参数和相对位置关系写得尽量清晰不要指望模型替你动脑子。5. 把text-to-cad融入真实设计流程哪些环节能即插即用很多人在评估一个新技术时容易走极端要么觉得它能完全替代现有流程要么觉得它一无是处。text-to-cad的真实定位应该是一个设计前期的加速器和灵感生成器而不是一个能替代资深工程师的自动设计系统。5.1 痛点一概念生成环节的最大赢家在我个人的工作流里text-to-cad目前最有价值的使用场景是概念生成阶段。每次开始一个新项目第一步要做的都是在纸上画一堆草图然后讨论、筛选、抛弃、重来。这个过程极其耗时。现在我可以直接在软件里输入几个不同类型的描述让模型快速生成十几个粗略的候选模型然后我在其中挑两三个被低估的思路去做深化。举个例子在设计一个仪器外壳的时候我输入“带散热鳍片的铝合金外壳”“带圆形观察窗的外壳”“有多排接口槽位的壳体”这样几个方向模型能给我完全不同的结构走向很多方案是我自己按惯性思维想不到的。之所以这么说是因为AI不像人类设计师那样有路径依赖它不会因为你昨天看了一个苹果风格的设计今天就顺手把圆角给加大。这种去惯性化的生成能力是text-to-cad目前最值钱的价值。5.2 痛点二某种程度上它能充当草图还有一个被忽视的使用场景是把它当成一个“可执行的便签”。我们在设计沟通中经常遇到这样的情况你告诉加工师傅“我要一个这样的底座但稍微改一下结构”对方嘴上说明白了实际做出来还是按他自己的理解走因为你给不出精确的图纸。这时候你让text-to-cad生成一个粗略的模型哪怕尺寸不对、结构不完善但至少它能直观地传达你的设计意图。它能很大程度降低设计沟通里的误解成本特别是对非机械专业出身的人来说非常友好。我自己就用这个办法和供应商确认了很多次加工方案比口头描述、甚至手画草图高效得多。5.3 痛点三参数化零件库的快速构建还有一类更进阶的用法是用text-to-cad搭建参数化零件库。很多标准件比如法兰、轴承座、卡箍它们的基本结构是固定的变的只是关键尺寸。如果你让模型生成一个参数化的脚本模板之后每次需要不同尺寸的标准件只需要改几个变量就能生成新的模型。这件事原本需要人工写脚本现在可以交给模型来写然后你只做审核和调整就行。不过要注意模型生成的脚本有时会有冗余的历史操作同一个孔可能会被重复创建两次或者创建后被一个多余的布尔运算又合并掉。这个问题在脚本较长时尤其常见需要人工做简化。我的经验是生成的脚本可以作为初稿但务必要跑一遍“参数灵敏度分析”改几个尺寸看看有没有东西崩掉。5.4 实际部署时的硬件与运行环境建议最后给一些部署层面的经验。目前主流的text-to-cad模型推理阶段对硬件的要求不算离谱一块消费级的显卡就能跑得动原因是很多模型其实是在已有LLM基础上做微调推理成本并没有比普通代码生成高多少。但如果你想自己微调一个领域专用模型那显存和内存的压力就会大不少建议直接上A100/H100级别。如果你只是想在项目里先试试水其实不用自己部署。现在不少开源项目提供了在线demo和API直接在浏览器里试就行。切忌一上来就大规模采购硬件先用已有资源把模型效果摸清楚再决定要不要投入更深的研发。6. 下一步值得关注的四个方向text-to-cad还在快速演进中现在入局虽然不算早但远没有到定局的时候。如果你对这个方向感兴趣我建议盯住下面这几个关键趋势。第一个是多模态输入。目前text-to-cad基本只吃文本但现实中设计师更习惯“草图文字注释”的表达方式。已经有不少研究尝试把一张手绘草图和一个简短描述结合起来作为输入让模型能参照草图的轮廓、同时配合文本理解设计意图。这个组合如果能成熟价值会非常大因为它非常贴合工程师原有的思考习惯。第二个是B-Rep语义的深度接入。前面说的端到端生成B-Rep目前还停留在“能生成”的阶段下一步要做的是让模型理解每个面、每条边的工程意义比如哪个面是配合面、哪条边是密封边。这相当于给模型赋予了“工艺意识”真正完成这个跨越生成的模型才具备生产价值。第三个是领域微调。目前的开源模型大多是通用方向对特定行业的知识掌握不足。如果你想在医疗器械领域或者航空结构件领域用text-to-cad几乎必然需要自己收集领域数据做微调。这个需求会催生一批做数据服务的公司也给懂行的人创造了不少机会。第四个是真实设计数据的采集与标注。优质数据太稀缺了真正的设计数据并不会开源。那些掌握着大量高质量建模历史数据的公司在未来两三年会拥有巨大的壁垒优势。如果你所在的公司有CAD使用数据资产现在开始有意识地做规范化和清洗未来可能比模型本身还要值钱。7. 实操总结与常见陷阱清单最后放一张我踩过坑之后整理出来的速查表给准备尝试text-to-cad的朋友一些关键提醒。常见问题具体表现建议应对描述太模糊生成结果永远是千篇一律的基础几何体把参数、位置、数量写清楚当成写需求说明书一样生成代码语法对但逻辑错布尔运算顺序错误导致模型和预期严重不符检查脚本里特征创建的先后顺序手工调整顺序阵列特征位置飘螺丝孔、加强筋的位置偏离设计意图不要直接用了改参数后重跑或者干脆手动阵列破面与非流形体导入CAD软件后无法正常布尔计算或加厚用网格修复工具做一次流形化处理再进CAD文件格式不兼容生成的STEP导入后材质、颜色、特征树信息丢失明确预期只能要几何别指望特征树完整迁移过度依赖AI结论拿到生成模型直接发加工任何AI生成的模型必须经过人工审查才能进入下游流程用一句话总结我的实操体会text-to-cad目前适合当“外部大脑”而不是“主力手”它能在你思路打结的时候快速给出方向参考能在你懒得画草图的时候快速摆出一个可用示意模型但它还无法替代你坐在CAD软件前从零构建一个精确的、可制造的、符合工艺规范的最终产品。如果你正打算在自己的项目里尝试text-to-cad我给的建议很简单先找三五个你手头真实遇到过的设计需求把描述精心写成型逐个去现有的开源模型上跑一遍看看结果和你的预期差多远。这个测试做完你基本就知道哪些环节可以借力、哪些环节还得靠人了。五年前还在纠结先学SolidWorks还是先学Creo的那批人现在应该认真考虑把“AI协作建模”也加入自己的技能树了。
MATLAB仿真：直接与间接转发实现)
