在CAD领域摸爬滚打这些年我一直在等一个东西能不能直接输入一句“给我一个带四个安装孔的L形支架壁厚3毫米”就能拿到一个可编辑、可加工的三维模型。text-to-cad这个方向就是冲着这个目标去的。它解决的问题很直接——把自然语言描述翻译成计算机辅助设计CAD模型不让设计意图卡在“人会画图但不会建模”或者“建模太慢”这个环节上。对于机械设计、工业设计、3D打印爱好者、AI应用开发者来说这都是值得关注的方向。这篇文章我会从技术路线、方案选型、数据集、模型训练到落地排查把我知道的、踩过的坑一次性说清楚。1. 内容整体设计与思路拆解1.1 text-to-cad要跨过的三道坎先说清楚text-to-cad到底难在哪里。第一道坎是模态鸿沟文本是离散的符号序列CAD模型是连续的参数化几何体两者之间没有天然的映射关系。第二道坎是精度要求做渲染图可以“大概像”但CAD模型要用于加工尺寸误差动辄得控制在0.1毫米以内生成结果必须精确、可度量。第三道坎是可编辑性工业场景不是要一张图片而是要一个能改参数、能出工程图的零件模型。想明白这三道坎就能理解为什么这个方向一直没被简单的“视觉生成模型”端到端解决。图像生成模型可以生成看起来很真的图片但生成不出带精确尺寸、拓扑关系明确的CAD实体。所以真正靠谱的text-to-cad方案几乎都走的是“中间表示”路线——把文本先转成某种结构化的CAD描述再执行成模型。这里涉及一个关键的设计决策中间表示选什么。目前主流的几条路线要么选程序代码OpenSCAD、CadQuery脚本要么选CAD命令序列B-rep操作序列要么选体素/点云再反推几何。没有绝对优劣只有适配场景的取舍。1.2 为什么说“代码即模型”是最稳的切入点我个人的观点很明确刚开始做text-to-cad从程序化建模代码入手是最稳的。原因有三点。第一大语言模型LLM对代码生成这件事已经有很强的能力。GPT系列这类模型在大量开源代码上训练过对OpenSCAD、Python这类语言的语法、常见库调用非常熟悉。让LLM写一段能运行的CadQuery代码比让它直接输出一个精确的网格模型要靠谱得多。第二代码是天然可解释、可编辑的中间产物。生成的脚本可以直接打开修改改一个参数就能得到一个新尺寸的零件。相比“黑盒”的隐式生成工程人员能看懂、能干预这就有了实际落地的价值。第三调试成本低。代码执行失败、语法错误可以用编译器和调试器定位问题。如果是扩散模型直接生成的几何体出了问题你根本不知道它哪个维度算错了、为什么少了一个孔。所以下面讨论的技术路线我会把“LLM生成程序代码再渲染为CAD模型”作为主线同时分析其他几条路线的适用场景。这个选型逻辑也是我在实际项目中反复验证过的能选可解释、可调试的方案就别选不可控的端到端生成。2. 核心细节解析与实操要点2.1 文本输入怎么处理才能让模型“听懂”别以为把用户的话原样丢给模型就行。我在实际项目里发现文本的质量直接影响生成结果的准确率而且是几何级的影响。这里有几个处理要点。第一需要做术语归一化。用户说“螺孔”“螺纹孔”“螺丝洞”在模型眼里可能是三回事。做推理的时候需要在前端做一层标准化处理把口语化的描述映射到CAD建模术语上比如“打几个眼”统一成“钻孔”“板子上加几条筋”统一成“加强肋”。这一步不用太复杂维护一个同义词映射词典就能解决大部分问题。第二必须提取尺寸约束。用户描述里的尺寸信息是“带M6螺纹孔的安装底座”“两个孔间距40毫米”这类信息是最关键也是模型最常丢失的部分。我的做法是用规则加LLM结合的方式先把数字、单位、公差要求抽出来作为结构化的约束条件拼接进提示词。这一步做完生成的准确率能提升一大截。第三要给模型一个“回答框架”。不能指望模型自己发挥需要设计一个统一的提示词模板让模型按固定格式输出实体类型、创建方式、参数列表、特征操作拉伸、旋转、布尔运算。这样既有利于模型稳定输出也方便后续代码执行模块解析结果。2.2 中间表示的选型OpenSCAD、CadQuery还是自定义DSL这是text-to-cad项目里最核心的决策点。我三种都试过各自的坑都踩过这里展开说说。OpenSCAD的优点是语法极其简洁和它自身的CSG构造实体几何模型天然匹配用cube、cylinder、difference这几个原语就能拼出很多零件。LLM写OpenSCAD代码的成功率相对高。缺点是它的参数化能力偏弱做复杂曲面、倒角、圆角很费劲生成的模型偏“硬朗”。CadQuery是基于Python的库表达能力比OpenSCAD强很多支持真正的参数化建模、草图拉伸、扫掠等高级操作。LLM生成的CadQuery代码可以直接用Python执行方便集成到现有工程流程里。缺点是API层级较深模型经常记不住某些方法的具体用法生成的代码报错率偏高。自定义DSL领域特定语言的思路是针对特定产品类型比如法兰、底座、支架定义一套精简的建模指令比如ADD_HOLE(x, y, r)、CHAMFER(edge, size)。优点是可控性最强、错误率最低缺点是适用范围窄换个品类就得重新设计DSL。我给的建议是做通用方案选OpenSCAD做垂直深耕选自定义DSLCadQuery适合团队有Python工程基础、且对模型质量要求较高的场景。没有完美的方案只有当前阶段最合适的方案。2.3 从文本到几何的链路设计谁负责生成、谁负责校验text-to-cad和普通文本生成有一个本质区别下游有一个“执行器”。生成的代码必须能跑通跑不通就是废品。所以整个链路不能是“一次性生成完就结束”必须是一个“生成-校验-修复”的闭环。我实际采用的链路是这么拆分的。前端有一个意图解析模块负责理解用户的自然语言描述提取实体类型、特征参数、约束条件。中间是生成模块基于LLM生成中间代码。后端是关键——有一个自动校验模块用OpenSCAD或CadQuery的解析器去检查代码的语法合法性然后执行代码生成模型再检查模型是否符合约束比如体积不为零、尺寸在合理范围内、孔位数量正确。一旦校验不通过就进入自动修复循环把报错信息原样返回给LLM让它看错误再去改代码。我实测下来这个循环跑三四轮之后可编译率能从60%拉到90%以上。这是我建议所有做text-to-cad项目的人都必须加的环节别想着模型一次就能写对。2.4 量化评估体系不能光“看效果”要可度量做工程不能只看生成结果的截图“像不像”。text-to-cad项目的验收必须有一套客观的、可量化的评估体系。我给自己的项目定了五个指标。第一个是最基础的代码可编译率——生成的代码有多少能顺利通过语法检查并生成有效几何体。第二个是几何相似度把生成的模型和真实目标模型分别在空间里体素化计算IoU交并比IoU越高说明几何形态越接近。第三个是尺寸误差核心特征尺寸孔直径、壁厚、中心距与设计值的偏差用Chamfer距离或者直接对比参数值来衡量。第四个是特征完整性检查比如要求生成“4个安装孔”就数最终模型里有没有4个孔、孔径对不对。第五个是端到端响应时间——单次从文本到模型的总耗时。这里特别提醒不要只看IoU。我之前遇到过一个模型IoU分数很高但仔细看它的孔位偏移了5毫米整个零件装不上机器这种模型就是废品。所以特征完整性检查这一步绝不能省。3. 从零到一完整跑通text-to-cad项目3.1 环境准备与依赖工具选型如果你想自己跑通一个text-to-cad的最小闭环我按我的经验给你列一份依赖清单。这个清单我反复用过稳定可靠。Python 3.9推荐用conda建独立环境不要污染系统Python。PyTorch 2.0以上CUDA版本根据你的显卡选择目前11.8系比较稳。OpenSCAD用于把生成的代码渲染成三维模型支持批量导出STL/STEP。CadQuery 2.x版本提供Python API和本地渲染能力适合做参数化零件的生成与验证。大语言模型的推理框架本地部署可选ollama或vLLM调用API则要关注上下文长度限制。创建环境的实操命令我就不写死配置了但有一个经验值得分享不要用最新的依赖版本如果OpenSCAD用的是2021版CadQuery用2.1.0LLM推理框架用经过验证的稳定版一切求稳。做AI项目时依赖版本的大版本升级经常带来很多莫名其妙的问题不值得浪费时间。3.2 让模型“看图说话”双编码器结构的核心逻辑很多text-to-cad项目会加一个双编码器的结构——文本编码器和模型编码器这是近期业界常用的思路。文本编码器负责把自然语言描述编码成语义向量。一般直接用预训练的语言模型做编码器比如BERT系列或者LLM内部的文本编码层。这个编码器可以冻结参数也可以微调具体取决于你的数据量。模型编码器负责把CAD模型通常用体素化后的一系列点云、体素标志编码成几何特征向量。这一路不需要很复杂近年来的Transformer或者点云编码器都能胜任。双编码器训练时有一点非常关键两个编码器输出的向量必须在同一语义空间里对齐。训练阶段要做对比学习让“正确的文本-模型对”的向量距离近让“错误的文本-模型对”的距离远。对齐做得好不好直接决定最终的生成质量。训练好后推理时就能根据文本向量去匹配最相近的模型潜变量送入生成器解码出几何。3.3 用扩散模型还是自回归模型做解码我踩过的坑解码器选型是text-to-cad项目另一个能卡住人的地方。两条路线都有明显的优缺点。自回归模型autoregressive是逐token预测式生成训练比较稳定控制性好适合生成结构化的CAD命令序列。比如DeepCAD这类工作就是把CAD建模操作序列化成一个token列表然后按序列逐token生成。这种方案的优点是序列天然有序前后特征一致性较好。缺点是序列一旦很长超过1024个token模型容易丢失早期的上下文信息导致后续特征崩塌。扩散模型diffusion则在体素或者点云生成上表现更佳。近年来的CADFusion就是不错的尝试所以才成了热词。扩散模型的原理是训练时给模型添加噪声让它学会从噪声里恢复出模型的特征推理时输入随机噪声让它一步步去噪还原出模型。它胜在生成整体几何的连贯性好但难在精确参数的把控上——你很难让它准确生成一个“直径正好12.5毫米的孔”它更擅长生成“看起来像孔”的东西。我实际的经验是如果你的目标是让生成的几何尽量精确可控走自回归路线如果你对着重造型、外观、曲面流畅度的场景更感兴趣考虑扩散模型。两条路线都不轻松都得花时间调参、调数据。3.4 数据集的获取与预处理模型成败的分水岭text-to-cad项目里最常见的失败原因不是模型结构不好而是数据没处理好。我见过太多人在这一步草草了事最后整个模型质量都上不去。公开数据集方面常用的有DeepCAD包含17万多个带有文本描述的CAD模型这些模型来自Fusion360 Communities覆盖了大量设计特征。ABC Dataset则是大型CAD模型数据集但文本描述比较弱需要做一些配对生成。Text2CAD论文里专门构造了一个包含文本描述、OpenSCAD脚本和对应模型的配对数据集是目前做这条路线最顺手的起点。拿到数据后不能直接开工预处理有三大要点。一是去重用几何哈希或者简化版IoU筛选出重复模型不然数据冗余会严重拖慢训练。二是过滤不完整描述很多公开数据的文本描述只有“part1”“part2”这种无意义标注这类数据要果断删掉。三是单位与坐标系归一化我在项目中发现同一数据集里模型有的单位是毫米有的是英寸坐标系也不统一跑训练前必须全部统一否则模型学到的几何关系全是乱的。3.5 训练与推理过程中的关键参数调优模型训练这里给出我实测下来比较稳的参数起点你可以按自己的显卡显存来调整。对于序列化的自回归方案我推荐的初始参数是嵌入维度256Transformer层数6层注意力头数8最大序列长度512batch size 32。如果显存不足优先调小batch size而不是调短序列长度。训练时用学习率预热warmup策略初始学习率1e-4预热2000步后衰减。对于双编码器对比对齐温度为0.07是常见起点batch size建议至少64否则对比学习的负样本太少向量空间拉不开。我自己实测batch size从32提到64后检索准确率提升了将近8个百分点。模型评估时分两个阶段看先是训练loss降下来而且不过拟合然后看五个核心指标前面提到的可编译率、IoU、尺寸误差、特征完整性、响应时间。响应时间这里提醒一下如果用本地LLM推理单次要控制在10秒以内如果超过就要考虑裁剪提示词或升级硬件了。3.6 后处理从生成结果到可交付的CAD模型生成出来的模型哪怕几何对了也还不能直接交付。后处理这一步我见过很多人都忽略了结果前面的努力全白费。头一步是格式转换。模型生成后可能是STL网格格式但工程上需要的可能是STEP文件——STEP格式才是工业软件通用的数据交换格式支持精确几何。转换工具可以用FreeCAD的脚本接口或者直接用CadQuery的导出能力。转换过程中重点检查有没有破面、缝隙、过度简化。第二步是参数化还原。模型直接生成的是一串固定尺寸的几何体但真正好用的CAD模型是带参数驱动表的——改一个变量、全体更新。我在项目里会手动给关键特征加上参数比如把“孔径”“壁厚”“安装孔间距”提取成参数这样后续被修改时才具备实战价值。第三步是添加标准属性材料、密度、加工工艺说明。这一段时间不长但一定要做因为它是后续物料清单导入的信源工程环境里缺了这些属性模型再漂亮也没法进入生产流程。4. 常见问题与排查技巧实录4.1 LLM输出非法代码怎么修最快这是text-to-cad落地时最高频的问题没有之一。LLM生成的代码经常出现未定义变量、函数名拼错、括号不匹配这类低级错误。我试过很多修复方式最有效的组合是三点。第一在提示词里预置脚手架代码——把公共的建模环境单位设置、常用函数、公差变量以代码模板的形式写进提示词让模型只生成核心特征部分。脚手架固定之后语法错误率能显著下降。第二生成代码后不直接执行先过一遍OpenSCAD的官方解析器做语法预检报错信息立刻返回给模型进行修复。第三修复超过三轮仍然失败就不死磕直接换一个不同的提示词表述重试让模型换个思路。这里有个细节值得注意修复循环里反馈给模型的信息要尽量具体不要只返回“代码有误”要把具体的错误行号、错误类型、预期的token类型都拼进去。LLM对具体的报错信息的修复能力远高于笼统报错。4.2 3D模型几何错乱先查坐标系与归一化一次典型的翻车现场生成的模型孔位和外形都对但整体跑到世界坐标系角落去了或者模型大小比例完全失真。这个问题通常不是模型能力不够而是前后处理阶段的坐标和尺度没有对齐。排查思路分三步第一步确认训练数据里所有模型是否做了统一的归一化处理比如全部缩放到边长1的包围盒内。第二步确认推理时输入文本里的尺寸信息的单位是否和数据集的单位一致——如果数据集是英寸文本描述用的是毫米那生成的结果必然差25.4倍。第三步检查后处理导出时是否做了反归一化——如果生成的是归一化坐标下的模型导出STEP文件时必须映射回原始尺寸这一步没做模型就永远是缩小的。4.3 生成结果千篇一律大概率是数据多样性不够还有一个典型问题无论输入什么文本生成的模型外形都差不多。这个问题的根子通常在数据集而不是模型结构。我的排查建议是统计一下训练集里文本-模型对的多样性。很多公开数据集存在“长尾分布”——少数几个类型的模型占了80%以上的数据量其他类型都是零星几条。模型在这种情况下自然只会“记住”高频类型。解决办法有三类。丢掉部分高频数据让数据分布相对均匀一些这是最直接的。或者对文本描述做数据增强比如替换同义词、改变描述句法让同一个模型对应不同风格的语言表达这样文本编码器会更鲁棒。再或者用重采样的方式对低频类型做重复采样或简单变换旋转、镜像相当于让模型多“见”几遍边缘样例。4.4 常见问题速查表现象可能原因首选排查手段生成代码无法编译提示词缺乏脚手架预置公共代码模板捕获报错并循环修复模型坐标偏移归一化与反归一化缺失检查训练前和导出后的坐标系映射尺寸比例失真单位不一致统一所有环节使用毫米或英寸生成结果单一数据集长尾分布数据增强或重采样5. 从项目走向产品场景化落地建议5.1 当前哪些应用场景最适合text-to-cad虽然方向还在快速演进但已经有几个场景可以实实在在落地不是只停留在论文里。第一个是概念设计阶段的前期草图生成。设计师在接需求、出方案阶段往往需要快速看到基于语言描述的雏形。text-to-cad可以把这个过程从几小时压缩到几分钟让设计师能更快地对多个方向做出取舍。第二个场景是非专业人员的“语义化定制零件”。比如3D打印爱好者想做一个特定尺寸的手机支架却不会用CAD软件。用自然语言描述需求直接得到可打印的模型文件这会大大降低创造门槛。第三个是参数化家族零件的快速派生。比如一个法兰只需要换孔数和尺寸就成为另一个零件型号这类工作由text-to-cad来做效率极高。教育领域同样值得关注——帮助学生通过自然语言描述反过来理解CAD模型的构成逻辑比直接让他们从零学软件操作更能保持兴趣。5.2 工程化落地时的三条实战建议第一坚持“人机协同”而不是“全自动替代”。我目前在这个方向的实际项目里最稳定的用法是让text-to-cad快速生成初稿再由工程师做精修——像“AI生成初稿人工精修”的模式。全自动对接生产环节现阶段风险还太高。第二加上规则审核。生成结果经过尺寸合理性检查、干涉检查、可制造性检查之后再出模型文件。这些检查可以用开源库实现成本不高但能砍掉90%以上的低级错误。第三关注可追溯性。把文本输入、中间代码版本、生成参数、修改记录全部保存下来这样才能对生成结果的准确性做复盘。工程场景里出问题要能追根溯源这是合规性的基本要求。5.3 一连串后续可扩展的方向text-to-cad这个方向后面的演进空间还很大。一个值得关注的扩展是文本驱动模型装配体——不只生成单个零件而是由自然语言描述“一个底座加四个轮子加一个把手”由AI生成整个装配结构及各零件的配合关系。另一个方向是逆向从CAD模型反向生成对应的自然语言描述用于图纸归档、设计文档自动化。还有跟参数优化结合——用户说“这个支架要能承受500N的力”模型不仅要生成几何还要迭代式地验证强度并自动加厚或加筋这一块要跟有限元分析打通想象空间更大。写在最后text-to-cad这个方向做下来给我最大的感受是它不是在替代设计师而是在压缩从想法到实体的时间。技术层面还有很多不完美但已经足够让一批人先跑起来。我个人实际操作中体会到的最核心的一件事是不要把它当做一个一步到位的生成器而是把它当做一个“草图加速器”——快速给出可行方案人工介入收尾。这种用法下它的实际价值比想象中大很多。另外分享一个小技巧生成质量不好时先别急着调模型、调参数试着改一下提示词——把“一个安装底座”改成“一个铝合金安装底座底面有4个直径10毫米的安装孔孔距50毫米四周带R5倒角”你会发现生成质量提升的幅度比调任何超参数都明显。这在工程上算是“入口质量决定出口质量”的经典验证。