一个设计师在SolidWorks里花两个小时建好的法兰盘模型如果换成用一句话描述——“中间带六个均布螺栓孔的法兰盘外径120厚10”——在AI辅助下可能几秒就能生成初稿。这正是text-to-cad这个方向最打动我的地方它把工程建模从“动手画”变成了“开口说”让三维模型不再是鼠标和菜单堆出来的产物而是自然语言直接映射成的参数化实体。这个领域最近两年非常火从学术论文到商业软件都在往里面扎。这篇就把我研究和实测text-to-cad相关方案的经验整理出来覆盖技术路线、模型选型、数据训练、评测方法和避坑清单给想入坑的朋友一条相对完整的参考路径。1. 降维拆解text-to-cad到底在解决什么问题1.1 传统CAD建模的痛点和文本驱动的价值先聊一个最基本的场景。传统的参数化建模不管是SolidWorks、Fusion 360还是FreeCAD本质上是“几何操作序列的录制”你画草图、加约束、拉伸、切除、倒角每一步都在告诉软件“怎么做”最后得到的是“怎么做”的结果。问题是“怎么做”这三个字是有学习成本的而且对经验依赖很强。同一个零件新手可能画半小时老手五分钟搞定差别全在操作顺序和约束技巧上。text-to-cad想改变的正是这一点它把焦点从“怎么做”转移到“做什么”。用户只需要描述最终要的是什么——形状、尺寸、位置关系、孔洞特征——模型自动完成从语义到几何的映射。这带来的不只是效率提升更重要的是降低了三维建模的准入门槛。机械设计里很多非专业工程师工艺、采购、质量其实经常需要快速查看或修改三维模型但他们不会用CAD软件text-to-cad这类工具就能帮他们绕开软件操作层面的障碍。从商业价值看这个技术直接对接的是“概念设计”环节。产品开发早期方案迭代频繁设计师的精力应该放在功能定义和形态探索上而不是反复调整草图约束。如果一句话就能生成一个可编辑的参数化模型概念阶段的试错成本会大幅下降。还有一个容易被忽略的价值点它让CAD模型和文本描述之间有了双向翻译能力。反过来看一个模型可以自动生成自然语言说明这对模型库检索、PDM系统管理、跨部门沟通都有直接帮助。整个知识管理系统会因此变得更友好。1.2 现在能做什么不能做什么对任何一个新技术先搞清楚能力边界比盲目乐观重要得多。我自己实测和调研下来当前text-to-cad的“能”和“不能”分得非常清楚。能做的简单机械零件法兰、支架、轴套、外壳、齿轮的快速生成基于已有模型的文本修改指令比如“把孔距改成50”概念草图的快速可视化标准件库的文本检索和参数填充。做不好的复杂的曲面造型汽车A面、自由曲面外壳包含严格装配关系的多零件模型螺纹配合、公差标注需要行业规范约束的图纸GB/T标准标注、粗糙度符号高度抽象或含混不清的描述。换句话说当前text-to-cad更像一个“参数化特征的快速翻译器”而不是“全能建模师”。它的擅长区域是规则几何、对称结构、标准孔位这类特征清晰的零件。一旦进入自由曲面领域它的输出质量会断崖式下降这背后是训练数据分布和几何表示方法的双重限制。理解了这个边界你对后面所有技术方案的选择都会有更清晰的判断生成器选择、数据增强策略、模型训练目标全都是围绕“特征明确的机械零件”这个核心场景来做的。2. 核心技术路线拆解三种主流玩法text-to-cad这个方向看着是一个任务实际学术界和工业界分别走了三条不同的技术路线。这三条路线各有各的数学基础、数据结构、和擅长的场景我先说清楚它们的核心思路再逐个展开。2.1 路线一让大语言模型直接生成参数化脚本代码这条路线最直观也最容易被理解既然CAD软件能执行脚本SolidWorks的VBA、FreeCAD的Python、CadQuery的Python API那就让LLM学会写这类脚本然后用对应的内核去执行。这套方案的实现路径是把CAD模型表示成一段程序——通常是CadQuery或FreeCAD脚本——模型训练的目标就是最大化这个程序代码的条件概率。具体实现时有个代表性工作是Text2CAD它用GPT-4生成合成训练数据再用这些数据去微调开源模型比如LLaMA-3.1-8B、DeepSeek-Coder等让模型学会从自然语言指令生成对应的CadQuery代码。推理时拿到代码后直接交给CadQuery内核去执行生成BREP实体模型。这条路线的优势非常明显生成的模型天然是参数化的、可编辑的因为它是代码啊改个数字就能改尺寸。另一个优势是训练门槛相对低——你不需要自己设计复杂的几何生成网络直接用现成的LLM框架微调即可工程链路非常成熟。缺点是上限受限于两件事一是LLM对长程序序列的组合学习能力二是代码能否被CAD内核正确执行并生成合法的实体。实践中经常出现“代码语法对但几何自相交”这类问题后面排查章节我会细讲。此外这类方案对相交特征、圆角次序等复杂操作很容易写出逻辑上冲突的代码生成失败率高于几何直接生成方案。2.2 路线二从文本直接生成几何表示B-rep/CSG/点云第二条路线在学术圈更主流它不经过代码中间层让模型直接输出几何数据。根据几何表示方法的不同又分成几个分支。最经典的是以B-rep边界表示为目标的方式定义一系列基础特征拉伸、旋转、倒角、孔、阵列每个特征有若干参数模型输出的是一个特征参数序列然后由程序化的B-rep生成器把这些参数转成带拓扑关系的实体模型。代表性研究如DeepCAD它把CAD模型转化成类似“token序列”的表示用自回归模型逐token生成。这个路子也被Text2CAD论文沿用但在特征和参数预测上做了条件生成对抗网络cGAN的尝试。另一条子路线是CSG构造实体几何树生成。CSG把模型表示成基本体素立方体、圆柱、球的布尔运算树并、交、差模型要生成的是这棵树的拓扑和叶子节点参数。优点是结构紧凑、天然密封缺点是表达能力有限——复杂的圆角过度和拔模斜度用CSG来表达极其别扭生成出来的形状容易显得“机械感”太重。第三条子路线更激进直接生成点云或隐式场如Occupancy Field再用后处理算法重建网格。这里面最有名的是用扩散模型生成点云/隐式场的方案然而对CAD场景来说点云重建出的曲面会有不可控的误差最后得到的网格模型很难直接用于制造——你想让CNC加工一个网格模型公差直接没法保证。我对这三条子路线的评价是做研究选B-rep token序列做产品选代码生成做可视化概念设计选隐式场。选错场景再好的模型也白搭。2.3 路线三先出二维草图再拉伸成体草图-拉伸派第三条路线是这两年商业产品采用较多的一种先由文本生成满足约束的二维草图直线、圆弧、圆再由程序化规则把草图拉伸、旋转成三维实体。这个思路和人类CAD建模习惯非常像——“先画轮廓再给厚度”。代表性商业产品是Zoo的Text-to-CAD2024年发布就是用改进版的pix2pix生成带约束的二维草图从文本中提取草图形状描述再通过参数化CAD内核Onshape的API把草图拉伸成体。该方法之所以在商业上走得通是因为它绕开了直接生成三维B-rep结构这个大难题把三维几何生成拆成了两个阶段先用生成模型解决“画什么形状”的问题再用确定性的内核过程解决“怎么变立体”的问题。不确定性被控制在二维可靠性由CAD内核保证这是工程上非常高明的取舍。缺点也很明显它只能覆盖“草图拉伸/旋转/扫掠”这类prismatic特征组成的零件。如果你要生成一个包含复杂倒角、抽壳、阵列孔的特征组合这种两步式的流程就很难把多个特征的交互关系处理干净。三条路线分完你会发现没有一条是“万能钥匙”。真正的落地项目通常要混合使用主体结构用草图拉伸特征细节用程序代码叠加最终用B-rep内核做布尔运算。3. 把一个text-to-cad流水线真正跑起来说再多理论不跑代码都是空的。这一节我以“生成一个带中心通孔的法兰盘”为例把一条最小可用的text-to-cad流水线完整演示一遍从输入到实体模型输出一步步来。3.1 最小闭环从文本到可执行CadQuery代码我选择CadQuerycq-editor环境作为内核因为它是纯Python库和LLM生态结合最顺畅。先看一个最朴素的“文本→代码→实体”闭环流程我用一个不含任何模型推理的简单提示模板来演示核心链路后面再接入LLM。import cadquery as cq # 用户意图: 生成一个外径120、厚度10、中心孔直径20的法兰盘 spec { outer_diameter: 120, thickness: 10, center_hole_diameter: 20, bolt_circle_diameter: 90, bolt_hole_diameter: 9, bolt_count: 6, } # 实体建模流程 result ( cq.Workplane(XY) .circle(spec[outer_diameter] / 2.0) .extrude(spec[thickness]) .faces(Z) .workplane() .hole(spec[center_hole_diameter]) .faces(Z) .workplane() .polarArray( radiusspec[bolt_circle_diameter] / 2.0, angle0, countspec[bolt_count], rotateFalse ) .hole(spec[bolt_hole_diameter]) ) # 导出STEP文件 cq.exporters.export(result, flange.step)这段代码对应的目标很明确先建一个圆形实体拉伸到指定厚度加中心孔再在分度圆上阵列6个螺栓孔。注意所有尺寸我都用了/ 2.0因为草图的circle方法接收的是半径而不是直径这个换算关系是最容易踩的坑之一后面还会细说。在有LLM的情况下上述spec字典不是手写的而是模型从文本里解析出来的。这一步正是text-to-cad和普通CAD脚本之间的本质区别参数从哪里来决定了工具的智能化程度。3.2 让大模型学会“提取参数”的Prompt工程如果不想一开始就搞微调用现成的LLM API做参数提取是最快的验证方案。这里有个关键设计不是让模型直接生成整段CadQuery代码而让它先输出结构化的JSON参数再由确定性的代码模板去执行。这样做的原因很实际直接让LLM输出代码虽然可行但错误率在30%到50%之间摇摆尤其是遇到参数单位、坐标基准、孔位阵列索引这些细节时模型经常“自由发挥”。而如果只让它做“文本到JSON字段”的映射准确率可以稳定提升到90%以上。把不可控的代码生成降级为可控的参数映射是我在项目中最常用的一招。一个经过优化的指令模板长这样你是一个参数化建模参数提取器。根据用户描述提取以下字段只输出JSON不要输出其他内容: - outer_diameter: 外径单位毫米 - thickness: 厚度单位毫米 - center_hole_diameter: 中心孔直径 - bolt_circle_diameter: 螺栓孔分布圆直径 - bolt_hole_diameter: 螺栓孔直径 - bolt_count: 螺栓孔数量 规则: 1. 如果描述中未提及某字段省略该字段 2. 所有数字必须是浮点数 3. bolt_count必须是整数 用户描述: 一个外径120、厚度10的法兰盘中心孔直径20六个螺栓孔分布在直径90的圆上我用这个模板分别试过GPT-4o、Claude、以及开源的Qwen2.5-7B。实测下来的结论是闭源大模型基本能100%正确提取参数7B级别的开源模型在语义干净时也没问题但遇到“六个孔均布”这类隐含阵列语义时偶尔会把bolt_count漏掉或者把bolt_circle_diameter猜错。所以生产级方案里我通常会在Prompt里加一个“自校验”机制先生成JSON再让模型根据JSON反推一句话描述与原句对比不一致就重新生成。3.3 用合成数据微调一个专用小模型验证完Prompt方案下一步就是微调。这一步要解决的核心问题是生产环境不允许每次调用外部API数据安全、成本、延迟你需要一个本地可跑的专用模型。微调数据怎么造这是整个流程里最花体力的一步。我推荐的做法是这样的第一步从DeepCAD数据集里抽取一批模型。DeepCAD是一个包含约17万个机械零件模型和对应构造序列的大型数据集每个模型都有完整的特征操作链可以直接转成CadQuery代码。这一步相当于拿到了“模型→代码”的对齐数据。第二步为每个模型生成文本描述。纯靠人工写描述成本太高实际操作是先写一个基于规则的描述模板把尺寸、特征、阵列信息填进固定句式生成一批基础描述再用LLM把这些基础描述改写得更自然加入同义替换、口语化表达、省略尺寸等变化。比如“直径50的圆盘”可以改写成“一个50毫米的圆饼”可以让模型学到更丰富的语言对应。第三步做负样本增强。把尺寸数值随机扰动、孔位错排、特征顺序调换生成一批“描述与模型不匹配”的负样本。这一步非常关键能让微调后的模型学会拒绝不合理的请求而不是强行生成一个错的模型。微调本身我用的是LoRA方式基座选了Qwen2.5-7B-Instruct训练轮数2到3个epoch。实际效果对比下来微调后的7B模型在参数提取准确率上能追平未微调的GPT-4o而且在响应速度和数据不出域方面优势巨大。微调不是要把模型变成一个CAD专家而是让它真正学会“本项目的方言”——你的产品里特有的零件表述、特征名称、参数单位这些外部大模型未必懂。3.4 生成后的几何合法性校验这一步常常被初学者忽略但它恰恰是text-to-cad从“玩具”走向“工具”的关键。LLM生成的代码或参数即使语法正确生成的实体也未必合法——可能出现自相交面、非流形体、零厚度薄壁等问题。我的建议是在内核执行后加三层校验第一层CAD内核自校验。CadQuery底层是基于OpenCASCADE的执行后可以用isValid()方法检查实体合法性它内部会跑一遍BOPAlgo检查拓扑是否闭合、面是否自相交。第二层物理量粗筛。计算体积、表面积、包围盒尺寸和文本描述里的预期值做比对误差超过5%就触发重新生成。别小看这个简单的统计量它能拦截一大批“看似正常实则离谱”的输出比如孔洞丢失导致体积明显偏大。第三层特征核查。统计实体上的面数、孔数、倒角数量和预期特征做规则匹配。这层需要结合具体业务来写规则但通用做法是提取面的数量和类型分布如果法兰盘该有6个螺栓孔却只找到4个直接判失败。三层校验完成后才允许模型进入下一个环节。在流水线里这一步相当于质检工位它确保了“AI生成的东西真的能用于生产”。4. 数据与评测最容易翻车的地方我在前面反复提到DeepCAD数据集因为它确实撑起了text-to-cad这个方向。但数据这件事没有你想的那么“理所当然”评测也一样里面有不少门道我单独拿一节说。4.1 合成数据背后的代价和偏置DeepCAD这个数据集是从Onshape公共模型库里抓取真实用户创建的模型再通过程序化方法重建成带特征序列的CAD模型。听起来很美好但实际有几点很容易被忽略。第一模型类别分布极不均衡。公开模型库里最多的是机架、支架、接口板这类结构简单的零件齿轮、壳体、复杂铸件占比很小。如果你的应用场景正好是后者直接用这个数据集训练的模型会是灾难级的拉胯。我的做法是先按类别统计分布对弱势类别做上采样复制和参数扰动增强。第二真实模型库里的模型质量参差不齐。很多上传者只是随便画了个练习件特征树凌乱、尺寸随意、基准面混乱。训练数据里的这类“脏样本”会让模型学到错误的行为模式。需要先做一遍规则过滤删掉体积异常、特征异常、拓扑非法的模型。第三数据集的“语言无关性”。DeepCAD本身只包含几何特征序列没有文本描述所有text-to-cad方案的文本部分都需要额外构造。而文本质量直接决定模型的上限。那些直接用模板生成的描述句子往往句式单调、缺乏变化模型学到的语言映射很脆弱——换个说法就识别不了了。所以文本增强不是可有可无的步骤它是决定泛化能力的胜负手。4.2 评测指标怎么定才不误导自己text-to-cad怎么算“做得好”这是当前学术界都没完全想清楚的问题更别说工程落地了。最常规的指标是“生成成功率和相似度”也就是生成的模型是否有效能通过内核校验以及和参考模型的几何形状相似度比如用倒角距离或IoU。这个指标能反映基本盘但不是够的。我见过太多模型成功率高、相似度也漂亮实际却把螺栓孔的尺寸完全搞错了——相似度算出来还行因为主体形状占的体积权重大一个直径9和直径12的孔对整体IoU影响微乎其微。所以我的项目里评测体系是分层设计的第一层有效性是否能生成合法实体。第二层参数准确度预测的特征参数和真实值之间的绝对误差这个指标能暴露模型对尺寸的精细理解比整体相似度敏感得多。第三层功能完成度用户指定的特征是否全部出现这个直接用特征检测脚本统计孔数量、倒角次数、阵列数量一目了然。另外强烈建议加一个人工评测集。挑20到50个典型业务场景描述由多名工程师盲评生成结果的可用性等级完全可用、需小改、需重做、完全不可用。人工评测虽然费时间但它能发现自动化指标发现不了的软性问题比如倒角的方向对不对、螺丝过孔的间隙是否合理——这些细节工程师一眼就能看出来自动化指标则很容易被“整体相似度”蒙混过关。4.3 增量数据闭环让模型越用越准学完评测的教训最后补一个更实战的机制——增量数据闭环。任何预训练模型落地产都不可能一次性做对需要持续收集生产中的失败样本转成训练数据再定期微调更新。我搭建的闭环比较简单但有效系统里每次生成失败或工程师人工修改过的模型都会自动进入数据缓冲库。每周把缓冲库里的案例拿出来聚类如果一个错误模式反复出现比如“直径和半径混淆”“阵列起始角度偏移”就针对性地扩充这类样本加入下一轮微调数据。这个机制听起来不复杂但坚持半年之后我们的模型在特定垂直场景的成功率从72%提到了91%增量数据的作用甚至比换更大的底座模型还明显。text-to-cad这类任务跟通用对话不同它极度依赖垂直场景的数据覆盖通用能力再强还是得喂够你自己的“方言”样本。5. 实测中踩过最深的几个坑再往下写就是纯粹的执行经验了。这一节内容是我和团队在实际运行text-to-cad流水线时真金白银换回来的教训。每一条都对应具体的失败案例和解决方案。5.1 坑一直径当半径几何直接变形这个错我犯过不止一次。CadQuery里的circle()方法接收的是半径很多其他库比如SolidWorks API的草图圆接收的是直径模型往往没有区分能力直接把文本里的“直径120”填进circle(120)结果生成一个半径120、实际直径240的零件。解决办法有两个层面。第一层面在Prompt里明确注明单位换算“circle()接收半径参数值必须为直径的一半”。第二层面在代码模板层做强制换算把outer_diameter除以2后再传入永远不要让生成结果直接决定API参数的物理意义。能放在代码里做的防御不要依赖模型自觉。5.2 坑二坐标基准混乱导致孔位整体偏移还有一个高频问题螺栓孔生成在错误的平面上。CadQuery里的工作平面切换是个经典操作faces(Z)选的是Z轴正方向的面如果模型生成的代码里漏掉了切面步骤直接在原始XY平面上打孔那孔就打在底面上了整个零件报废。排查这个问题的思路是先在生成代码后做静态检查搜索代码里是否包含faces()切换操作再通过物理量粗筛计算孔洞中心的Z坐标确认孔是否穿透了正确的面。这两个检查加在一起基本能挡住80%的坐标基准错误。5.3 坑三拓扑合法但实际“破薄”OpenCASCADE的isValid()能查拓扑但查不出薄壁问题。比如一个壁厚0.01mm的壳体拓扑上完全合法但拿到实际加工和3D打印场景中这个模型等于废品。文本描述里如果没提到壁厚要求模型就会默认生成一个尽可能“省材料”的极限薄壁结构几何上成立工程上不可用。我的建议是在生成约束里加入工程下限值。壁厚不得小于0.5mm数值取决于工艺孔间距不小于孔直径的1.5倍类似这样的硬性约束在代码模板里就写死。生成器只需在这个安全区间内发挥“创造性”。5.4 坑四提示词里“默认值”的歧义最后说一个偏语言层面的坑。用户说“标准的法兰盘”不同工程师脑子里想的“标准”可能完全不一样——有人想的是GB/T 9124有人想的是ASME B16.5有人只是随口说“看起来差不多的就行”。模型没有行业背景知识时通常会按训练数据中最高频的模式生成而最高频的未必是用户想要的。解决这个歧义问题的办法是在Prompt里把“标准”强制展开成具体参数“默认按GB/T 9124 PN16平面对焊法兰参数生成若用户描述与标准冲突优先遵循用户描述”。这条规则会让模型的默认行为稳定下来而不是每次都在不同标准之间漂移。凡是能从设计规范里推导的参数不要留给模型“自由发挥”。6. 给想入坑的人的最后几条实在建议走到这里整个text-to-cad的技术全貌已经铺开了。最后再说点个人体会。如果只是好奇尝鲜直接拿Zoo的Text-to-CAD产品或者开源项目跑几个例子感受一下“一句话生成三维模型”的爽感就好这个门槛非常低。如果真的要在业务里落地我的建议始终是先从“参数提取模板代码”这个最小闭环开始不要一上来就追求端到端的纯生成。这个路线在工程上更稳而且能让你把数据结构、内核校验、失败处理这些基本功先练扎实后面再逐步引入更聪明的生成策略。关于算力投入也要泼一盆冷水微调一个7B参数的模型用单张消费级显卡如RTX 4090配合LoRA就能跑成本完全可以接受。但真正烧钱的地方在后面——数据清洗、失败样本归类、人工评测这些环节吃掉的时间和人力成本远比训练本身高得多。text-to-cad这个方向确实还处在快速变化里新模型、新数据集、新论文几乎每个月都有。但不管工具怎么迭代核心的判断框架不会有太大变化自然语言到结构参数的映射能力、参数化内核的可靠性边界、数据覆盖的完整度。抓住这三条主线无论外面出了什么新模型你都能快速评估它到底能不能用、用在哪里。我个人现在对它的判断是在标准件、通用零件和概念设计领域它已经达到了初步可用的水平离真正意义上的“全能智能CAD助手”中间还隔着自由曲面生成和装配级理解两座大山。但这不妨碍它值得你花时间研究——毕竟每一条新工具链跑通的时候最早动手的人总是占便宜的那个。