我最早看text-to-cad这个概念时第一反应是“这不就是AI生成3D模型换了个说法吗”。后来真正去翻论文、跑推理、对着生成结果放大看倒角和孔位公差才意识到事情没那么简单。文本直接生成CAD模型和文本生成一张图、生成一个网格体完全是两个物种。前者要求几何精确、参数可改、特征可追溯甚至生成结果要能直接进CAM流程后者只要“看着像”就行了。这个门槛差异决定了text-to-cad注定不是又一个AI玩具而是真正值得结构工程师、产品设计师和制造工程师花时间研究的方向。这篇内容我会从原理拆到实操谈谈目前最典型的text-to-cad技术路线是怎么把自然语言“翻译”成可编辑的CAD特征的也讲讲我自己复现推理流程时踩过的坑以及哪些输入场景容易翻车。适合手里有三维建模需求但不想从草图一步步拉的工程师也适合刚接触AI辅助设计、想搞清楚这玩意到底能不能落地的朋友。1. text-to-cad是什么一个被低估的AI方向1.1 从一句话到三维模型中间发生了什么text-to-cad这个名字字面意思就是文本转计算机辅助设计模型。你输入“一个带四个安装孔的法兰底座外径80mm孔距60mm”系统直接给你输出一个可以编辑的CAD文件打开就是实体、带特征树、能改参数而不是一张渲染图或一个OBJ网格。听起来很科幻但2024年之后这个方向的进展非常快。核心突破不在某个单一算法而在三件事同时到位一是大语言模型对自然语言的理解能力够用了能把模糊描述拆成空间关系和尺寸约束二是CAD数据集的构建有了规模化方法训练数据不再依赖人工逐条标注三是把CAD模型序列化成token这件事让Transformer架构可以直接在CAD对象上做自回归生成。多说一句文本生成CAD模型的输出形态通常有两种。一种是生成完整的B-rep实体也就是带面、边、顶点的精确边界表示可以直接用于工程分析另一种是生成参数化特征历史也就是把建模过程拆成拉伸、旋转、打孔、倒角等操作序列输出结果带着特征树后续改尺寸很方便。目前主流研究更偏向第二种因为工程师拿到模型之后几乎一定会改参数特征历史比最终几何值钱得多。1.2 和通用3D生成的根本区别很多人会把text-to-cad和“文本生成3D模型”混为一谈。市面上常见的文本转3D工具大多数生成的是mesh网格几何表面由密集三角形逼近视觉效果好但模型是“死”的。你没法直接改某个孔的直径没法回到特征树里调整拉伸高度更没法做布尔运算之后保证拓扑正确。网格适合游戏资产、影视预览不适合工程交付。CAD模型讲究的是拓扑关系、尺寸约束、特征语义。一个倒角在mesh里只是某个顶点附近三角形位置的变动在CAD里却是一个特征节点删除它、改变圆角半径、影响后续特征都是结构化操作。所以text-to-cad本质上是在做结构化几何的程序合成而不是像素或图元堆叠。这也解释了为什么同样的提示词生成图片可以百花齐放生成CAD却必须收敛到确定解。你去问“设计一个支撑座”图片模型会给你十几种风格迥异的方案CAD模型必须从“能装进装配体、能承受载荷、能加工出来”这些硬约束出发最终答案在拓扑上高度相似差异集中在具体尺寸和局部特征。我自己判断这个方向潜力的一个重要标准是生成结果能不能直接进下游链条。text-to-cad最大的价值是它把AI放在了CAD设计流程的起点而不是终点。设计师输入需求系统给出版本人再基于特征树做修改和二次设计整个过程从“从零画图”变成“从草稿改图”效率提升是数量级的。2. 底层原理拆解给机器一本CAD语法书2.1 Text2CAD数据集从工程图到自然语言的翻译所有监督式生成模型都绕不开数据。text-to-cad能在这两年跑通最关键的基建是Text2CAD数据集。这个数据集最早由学术界提出核心思路是拿已有的参数化CAD模型库反向生成对应的文本描述形成“CAD序列-自然语言”成对数据。具体做法分两步。第一步从ABC数据集和Fusion 360 Gallery这类来源收集大量带特征历史的CAD模型把这些模型的操作序列统一编码成标准格式第二步用自动化管线生成语言描述。这里有个讨巧的点不是人工对着模型写“这是一个带圆角的L形支架”而是通过统计特征、尺寸、拓扑关系用模板和语言模型混合生成描述再经过一轮去重和清洗保证描述多样性。数据集规模我记得公开论文里提到的是约17万对涵盖点、线、圆弧、圆、拉伸、旋转、倒角、阵列等常见特征操作。这个规模对图像生成来说不算大但对CAD领域已经很可观因为CAD模型本身的获取门槛远高于图片。而且这个数据集的价值不只是给生成模型当燃料它还统一了“自然语言-特征序列”的接口标准后续其他团队做微调、做垂直应用都是在这个地基上盖楼。2.2 文本与CAD空间的对比对齐光有数据还不够。文本和CAD序列是两个完全不同的模态一个是离散语义符号一个是结构化几何操作序列怎么把它们拉到同一个向量空间里是模型设计最核心的环节。目前主流做法借鉴了CLIP的思路分别用文本编码器和CAD序列编码器提取嵌入向量然后通过对比学习让语义匹配的文本-CAD对在向量空间中靠近语义不匹配的对互相远离。训练完成后文本编码器输出的向量就带着几何语义CAD序列编码器输出的向量就带着语言语义两者在同一个空间里可以检索、可以匹配、可以约束生成。这个对齐模块的意义在于生成模型不再是“盲猜”文本含义而是从对齐空间里拿到一个有明确几何指向的条件向量。你输入“带六个通孔的圆形法兰”模型先把这个描述编码成向量向量里已经隐式包含了“圆形、六个孔、均布、通孔”这些几何属性然后再带着这个向量去自回归解码CAD序列。我实际看下来对齐质量直接决定了生成结果对文本的忠实度。对齐做得不好模型会抓大放小——记住了“法兰”和“圆孔”丢了“六个”和“均布”。这也是为什么早期一些demo生成的模型看起来结构正确实际一数孔位就对不上。2.3 自回归Transformer与CAD草图序列CAD序列的生成采用自回归Transformer架构这和GPT生成文本的逻辑一致每一步预测下一个tokentoken是CAD操作序列的编码单元。但CAD序列和文本序列有一个本质区别它的结构是分层的顶层是特征操作拉伸、切除、倒角底层是草图几何线段、圆弧、约束两层的依赖关系很强。所以现在的模型普遍采用两阶段生成策略。第一阶段生成草图序列相当于先在中性平面上把二维轮廓画出来第二阶段生成特征参数也就是拉伸高度、旋转角度、阵列数量这些三维操作参数。两个阶段的注意力机制会互相引用草图阶段的输出向量会作为特征阶段的条件输入。这个设计的工程意义很实际两阶段解耦之后模型可以在草图层面把拓扑关系先确定下来再决定三维形态比直接端到端生成完整序列的稳定性和可解释性强很多。调试的时候也方便生成结果不对你能判断是草图阶段错了还是特征参数错了定位问题快得多。2.4 为什么不直接用NeRF或扩散模型做CAD扩散模型在图像和通用3D生成上已经大杀四方有人会问为什么不直接把扩散模型套到CAD上。答案是扩散模型的连续噪声建模思路和CAD的离散化、程序化本质天然冲突。CAD模型不是像素点阵它的几何信息是高度结构化的一条边由两个端点定义一个孔有明确的中心、直径、深度依赖关系写在特征树里。扩散模型擅长在连续空间里逐步去噪但CAD状态空间是符号序列和参数表的混合不是均匀的连续流形。你把一个CAD模型向量化再加噪声噪声会破坏特征之间的引用关系去噪过程很难恢复出合法的拓扑结构。自回归模型虽然生成速度慢、无法并行但它天然适合序列化、结构化的生成任务能保证每一步都落在合法状态空间里。对CAD来说正确性比速度更重要生成一个拓扑错误的模型毫无工程价值。所以现阶段text-to-cad的核心生成器依然是自回归架构扩散模型在这个领域的角色更多是辅助——比如用扩散模型做文本条件几何先验的提取而不是直接生成CAD。3. 实操复盘本地跑通一个text-to-cad推理流程3.1 环境准备与模型获取前面讲的都是原理这块聊聊实操。先说明一下这里描述的是基于公开开源项目和模型权重的一种典型复现流程不同项目细节会有差异但整体思路通用。硬件上text-to-cad推理虽然不像训练那么吃资源但还是要一张支持FP16的NVIDIA显卡显存建议12GB以上。我最初在8GB显存的卡上跑过一次batch size调到1还是勉强模型加载加生成序列中间向量缓存很容易顶爆显存。后来换了16GB的卡流畅度完全不一样。显存不够的话用CPU推理也不是不行但一个中等复杂度的模型可能要等十几分钟甚至更久很消磨耐心。环境安装比较常规Python 3.10以上PyTorch 2.0以上另外需要Hugging Face的transformers库和accelerate库。模型权重从开源社区下载国内网络环境需要注意代理配置多试几个镜像源别在最基础的下载环节浪费时间。3.2 推理脚本示例与参数语义下面给一段精简过的推理脚本结构上参考了主流开源项目的写法。真正运行时要根据你使用的具体模型调整tokenizer和生成器名称但整体调用逻辑一致。import torch from transformers import AutoTokenizer, AutoModelForCausalLM model_name your-text-to-cad-checkpoint tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto ) prompt ( Generate a CAD model: a rectangular base plate with four countersunk holes at the corners, hole spacing 50 mm, plate thickness 5 mm. ) inputs tokenizer(prompt, return_tensorspt).to(model.device) gen_ids model.generate( **inputs, max_new_tokens1024, do_sampleTrue, temperature0.7, top_p0.9, eos_token_idtokenizer.eos_token_id, ) output_text tokenizer.decode(gen_ids[0], skip_special_tokensTrue) with open(result.cad, w, encodingutf-8) as f: f.write(output_text)这段代码里有几个参数值得展开说。temperature控制随机性CAD生成和文本生成不一样随机性太高容易产出拓扑错乱的模型我测试下来0.7是兼顾多样性和稳定性的一个甜点值。top_p建议固定在0.9附近低于0.8生成结果太保守容易把圆角全部吞掉接近1.0又开始出现莫名其妙的悬空特征。max_new_tokens要根据模型复杂度调整简单零件512够用复杂装配体或高密度特征序列需要拉到1500以上设太短会被截断在序列中间输出直接解析失败。3.3 后处理从序列到可编辑实体生成出的文本序列还不是CAD文件需要经过后处理流程转换。开源方案通常内置一个解析器把序列解析成特征操作树再映射到标准BREP数据。这一步最容易踩的坑是解析失败。生成序列里只要有一个token违反了语法规则——比如圆弧端点没有闭合、拉伸方向向量为零向量、阵列数量写了0——整个序列就可能中断解析。我在实测中大概有三分之一的情况下碰过解析异常处理办法是不要重新生成而是先检查失败token的位置很多时候只是单个参数异常手动修一下就能继续解析重新生成反而浪费时间且可能引入新错误。转换完成之后建议用工具做一次模型健康检查查看拓扑结构是否闭合、是否存在零面积面、特征是否存在重叠冲突。免费的检查工具可以用Python的cadquery库加载模型做布尔运算自检或者直接导入开源CAD软件看特征树。这一步千万不能省生成器偶尔会输出一个看起来正常但实际存在自相交面的模型直接拿去加工或3D打印会出大事。4. 实测效果哪些场景发挥稳定哪些场景翻车率极高4.1 稳定输出的几类零件我集中测过一批机械设计中常见的零件描述整理下来发现text-to-cad在几类场景里的表现是超出预期的。第一类是“板类零件规则孔阵”。比如带四角孔的安装板、带散热孔的盖板这类零件特征简单、拓扑规整文本描述和几何形态的对应关系明确生成成功率很高。输入“120×80mm的安装板四角M5通孔中心一个直径30mm的圆孔”模型基本一次生成就能用尺寸偏差在合理范围内。第二类是回转体零件。法兰盘、皮带轮、轴承座这类以旋转体为主体的零件因为特征序列规整拉伸旋转循环出现模型对这类模式的学习特别好。我测过带台阶和密封槽的法兰盘生成结果的特征树非常干净每个特征都能独立编辑不是糊成一坨的布尔减法结果。第三类是标准件变体。同样是螺丝垫片、限位块这类结构标准化程度高的零件只要描述里不出现非标约束生成质量都很稳定。这也符合逻辑数据集中这类零件占比高模型见过足够多样例泛化压力小。4.2 典型翻车现场与根因分析效果好的说完了重点说翻车。最常见的问题是倒角圆角特征的丢失或变形。输入里写着“四周倒角R3”生成结果可能只有两条边有倒角或者圆角半径偏离设定值。根因在于倒角特征在序列中依赖草图上边线的引用索引生成过程中一旦边线编号顺序和训练分布不一致模型就会“忘了”把倒角绑定上去。这个问题的本质是自回归模型的全局一致性问题——长序列中后期token对前期特征引用的保持不够强。第二个高频坑是对称性丢失。描述“左右对称的U形支架”生成结果左边有安装孔右边没有。这是因为对称关系在文本里是抽象语义但序列生成是逐token推进的模型没有全局规划能力去保证镜像特征成对出现。对比学习对齐阶段能把“对称”这个词映射到几何空间但映射到序列层面的一致性约束还不够强。第三个问题出在参数超范围。比如描述“六个均布孔”模型可能给出节圆直径但均布角度从一个非零值开始导致整体旋转了一个诡异角度。这类问题本质上是模型对“均布”这类隐式约束的理解不到位它知道要有六个孔但不知道起始角度也是约束的一部分。4.3 硬件开销与生成耗时实测耗时方面我的测试数据是这样的一个中等复杂度的支架类模型包含拉伸、切除、倒角、孔阵共约15个特征在16GB显存的消费级显卡上单次生成耗时约30-60秒解析后处理再占5秒左右。同样复杂度的模型在40GB的云端专业卡上生成时间能压到15秒以内。推理瓶颈主要在自回归解码的串行特性上CAD序列token数量动辄上千每一步只能前向一次没法像图像生成那样批量去噪。数据可以整理成表方便大家对照选型。这里补充一点显存大小影响的主要是batch和上下文长度如果你只跑单条生成12GB是够用的底线如果要批量生成或者跑超长序列比如装配体级24GB起步才稳妥。5. 现阶段的应用编排与绕坑心得5.1 把text-to-cad嵌入真实设计流程现在的text-to-cad还不能做到输入一句话就交付一套完整图纸。我实际跑通的工作流是把它作为早期概念设计阶段的加速器。具体做法是设计师先用自然语言描述零件的大致功能和边界条件text-to-cad生成几个候选几何方案然后导出到主流CAD软件里做特征树审查。挑一个拓扑最接近预期的方案直接在特征树里改参数而不是从零建模。这个流程把一个需要半小时的初步建模压缩到8到10分钟其中模型生成1分钟人工修改5分钟软件导入检查3分钟。这里有个心得不要把文本描述写得像招标书一样详尽反而要给模型留一点解释空间。描述越精确模型越容易出现特征冲突。比如你既写“四周倒角R3”又写“边缘棱角分明”模型会陷入矛盾最后随机选一个执行。我现在的写法是描述功能约束几个孔、多大间距、什么厚度把工艺特征倒角、圆角、拔模斜度留给模型默认。5.2 LLM解释器程序化CAD的另一种组合路线除了纯端到端生成还有一种工程上更稳的组合路线用大语言模型当解释器把自然语言翻译成程序化CAD代码再通过CadQuery或OpenSCAD这类脚本化建模工具生成模型。这条路线的好处是可控性强。LLM不需要直接生成几何序列只需要把语言描述映射成几百行Python代码代码的任何一行都可以审查、修改、重跑。几何错误的排查从“解析失败的token序列”变成了“异常的参数赋值”调试体验有质的提升。我在实践中用的方案是给LLM配一个CadQuery函数的检索工具让它先查API签名再生成代码生成的代码经过语法检查和快速预览双验证后再提交到主流程。这条路线在逻辑规则明确的零件上表现很好比如参数化法兰、齿轮、花键这类可以用数学公式描述的零件生成精度远高于端到端模型。它的短板在于LLM生成的代码偶尔会有非确定性行为——同一个描述跑两次得到的代码风格不同虽然是同一个模型但可维护性差。解决办法是在Prompt里给出一到两个固定模板作为风格锚点让LLM在模板基础上修改而非自由发挥。5.3 我踩过的几个典型坑和应对策略第一坑模型生成“看起来对了实际完全不对”。有一次生成一个带加强筋的壳体视觉上结构完整导入CAD后发现加强筋的截面没有闭合属于无效实体。从那以后我养成了强制做布尔自检的习惯每次导入后跑一次实体有效性检查几秒钟的事能拦住至少一半的隐形问题。第二坑单位系统的混乱。text-to-cad模型的训练数据可能混用英制和公制描述里写了“50mm”生成结果可能被当成50英寸处理。这个坑极其隐蔽因为模型在数值上没出错你的描述也确实生成了50这个数只是单位变了。应对方式是在输入描述里强制加上单位前缀比如“公制单位下长度50mm”把上下文单位约束显式化实测能显著减少单位乱入。第三坑版本兼容性。开源模型代码迭代很快我遇到过一次模型权重和推理代码因为transformers库的API变更导致无法加载的兼容性问题最后锁版本才解决。建议一开始就固定全套依赖版本尤其是transformers、torch、accelerate这三个核心库不要装最新版就完事在项目里维护一份requirements-lock.txt比反复排查环境问题节省太多时间。6. 局限与后续方向为什么生成CAD比生成图片难这么多6.1 精度和约束处理的天花板说到底text-to-cad的核心难度在于精度。图像生成领域的评估标准是“像不像”允许风格化、允许主观CAD生成的评估标准是“对不对”每一条边、每一个孔、每一处圆角都有确切参数。自回归模型在token层面的误差是累积的序列越长后期token偏离真实分布的概率越大这也是复杂装配体生成质量不如单体零件的原因。更麻烦的是约束求解问题。CAD模型里的尺寸约束、几何约束、装配约束是一个耦合方程组模型不仅要生成几何还要保证约束系统有解。当前模型本质上是在学习“大多数情况下的约束写法”而不是在生成后真正做约束求解。所以模型偶尔会输出一个过约束或欠约束的模型视觉效果正常但参数一变就崩。6.2 可编辑性、装配与标准件库的缺口另一个被忽视的问题是特征可编辑性。很多生成结果虽然几何正确但特征树是扁平的一次拉伸完成所有主体而不是“先轮廓后厚度再倒角”的合理顺序。这种特征树对工程师来说是灾难因为你没法独立修改某个圆角或某个孔只能全删重画。这也是“能生成”和“能用”之间的主要差距。装配层面的支持几乎还是空白。现有的text-to-cad模型都是单零件生成没有考虑零件之间的配合关系、配合面、自由度约束。实际产品设计里装配是绕不开的。我看好后续研究往“表述-装配”方向走输入“一个底座和一块盖板盖板通过四个螺钉与底座连接”模型需要同时生成多个零件并保证配合面的几何一致性这个难度比单零件生成高了一个维度。标准件库的接入也是个迫切需求。工程师的文本描述里经常出现“M6内六角螺钉”“6203轴承”这类标准件名模型并不理解这些名称对应的具体尺寸和螺纹规格。理想情况下text-to-cad系统应该内置标准件知识库描述中出现标准件名时直接调用库里的参数化模型而不是让模型重新发明轮子。6.3 我更看好的方向人机协作而非完全自动我自己对text-to-cad并不抱“完全替代设计师”的预期。这个技术最有价值的形态是让人和AI在同一个特征树里面协作——AI负责从自然语言快速生成可编辑草稿人类负责约束定义、制造可行性分析和最终决策。AI做方案发散人做收敛这种方式最符合工程设计里“探索-筛选-细化”的决策模型。实操层面我更推荐把它当成“需求翻译器”来用。设计师用自己最熟悉的语言把设计意图说出来系统把它转译成结构化模型设计师再回到熟悉的CAD环境里做精细化处理。这本质上是一个“口头需求到数字样机”的加速管道。将来如果text-to-cad能把标准件、装配约束、加工约束最小壁厚、脱模角度、刀具可达性都内建到生成条件里它就不再是一个demo工具而是真正能承担工程设计前端的生产级系统。到时设计师的日常可能变成“把上周那个支架改一下加两个加强筋壁厚减到2毫米做成铝合金的”——剩下的由系统完成。这条路还有距离但方向已经足够清晰。在我个人的实践中最值回票价的用法就是像前面说的那样把它放在创意发散到初步方案的这一段路上用一个60秒的生成结果节省半小时的从零起步这笔时间账怎么算都不亏。