最近频繁被问到一个问题现在文本生成三维模型这么火为什么搞工业设计、机械结构的人还在用一个个拉伸、倒角命令慢慢画图其实大家关心的就是 text-to-cad 这个方向——不是生成一张看起来像的照片而是让AI直接生成可编辑、带参数、能进CAM/CAE流程的CAD模型。我在实际项目里试过几轮主流方案踩了不少坑也总结出一些能直接用的判断标准。这篇文章就围绕 text-to-cad 的技术路线、核心难点、实操落地和常见问题展开给想上手的人一个相对完整的参考。先说结论text-to-cad 和普通的文生图、文生3D网格完全不是一回事。它生成的不是Mesh三角网格而是B-rep边界表示实体带着特征树、草图约束和参数历史。这意味着生成的模型必须能被下游的 CAM、有限元分析、装配干涉检查直接使用修改某个尺寸后整个特征树要能跟着更新。这个要求在工程语境里极其苛刻也是当前各类方案最大的分水岭。1. 整体思路与技术路线拆解1.1 text-to-cad 到底在解决什么“真问题”如果只是要一个视觉上像样子的三维模型现有文生3D工具已经够用了比如生成一个带纹理的椅子点云或网格放进游戏或短视频里完全没问题。但CAD场景里用户要的是工程语义这个孔是通孔还是盲孔倒角半径是多少这个面是配合面还是外观面装配关系中哪个零件是基准件这些信息无法用一张渲染图表示更无法从三角网格里提取。text-to-cad 的核心挑战是把自然语言中的模糊描述翻译成确定性的几何约束和特征操作序列。比如“一个带M8螺纹孔的安装支架孔距40mm板厚3mm”这句话里既有显式参数M8、40、3也有隐式工程惯例安装支架通常带加强筋、沉头孔、倒角。好的系统不能只识别数字还要理解“安装支架”这个词汇背后隐含的拓扑布局和制造约束。另一个本质问题是表征形式的选择。CAD模型在计算机内部通常用特征树加B-rep表示而深度学习模型擅长处理规则网格或序列数据两者之间存在巨大的结构鸿沟。怎么让神经网络输出结构化的、可编辑的CAD表示是所有方案都必须回答的问题。1.2 主流路线对比序列生成、扩散生成、大模型驱动我接触到的 text-to-cad 方案大致分三类各有取舍。第一类是序列生成路线代表作包括 DeepCAD、Text2CADMIT 2024、CADCoder 等。核心思路是把CAD建模过程编码成一系列 token序列类似“草图→拉伸→倒角→切割”的操作日志然后用 Transformer 或 LSTM 预测下一个操作。Text2CAD 还额外用 GPT-4 合成文本指令再训练一个指令编码器把文本和CAD操作序列对齐。这条路线最大的优点是输出天然带特征历史可编辑性最强符合CAD软件的数据结构缺点是对复杂模型的表示能力受限因为序列长度一上去生成的错误率急剧攀升。第二类是扩散模型路线比如从文本引导生成占用场、点云或距离场再用算法拟合出B-rep面片。这类方案在自由曲面造型上更有优势能生成一些序列方法难以表达的有机形态但拟合出的面往往需要大量修复而且没有参数历史工程可用性不如序列方法。第三类是大模型直接驱动脚本生成典型做法是让 GPT-4 或开源代码模型直接生成 CadQuery、OpenSCAD 或 Python 脚本再在本地执行建模。这个路线工程落地最快提示词灵活度高但稳定性堪忧——同一个描述跑十次可能五次脚本能跑通三次尺寸明显不合理两次直接语法报错。我自己的判断是短期看序列生成文本指令微调是最接近“真CAD”的方向中期看大模型生成脚本作为辅助工具会在效率上领先因为它能利用语言模型的常识推理能力长期看两条路线可能会融合——由大模型负责规划特征顺序由专用CAD生成模块负责精确几何执行。路线代表性系统可编辑性几何精度工程可用度主要短板序列生成DeepCAD, Text2CAD高带特征树中等较高复杂模型序列过长、误差累积扩散生成文本引导B-rep拟合低需重建参数较高几何细节低无参数历史面片修复困难大模型脚本GPT CadQuery/OpenSCAD高脚本即参数依赖于脚本质量中等稳定性差需大量校验1.3 数据、数据、还是数据为什么标注数据是兵家必争之地无论走哪条路线text-to-cad 都绕不开数据问题。DeepCAD 数据集包含约 17.8 万个从 Fusion 360 导出的机械零件模型每个模型有完整的特征操作序列。ABC 数据集包含超过 100 万个CAD模型覆盖更丰富的曲面形态。Text2CAD 的工作者用 GPT-4 对 DeepCAD 中的模型批量生成自然语言描述从而建立了文本和建模序列的对应关系。但数据规模再大也存在严重的偏置问题现有公开数据集的模型结构普遍偏简单以旋转体、板类件、简单支架居多真正复杂的有上百个特征的装配级零件少之又少。这导致模型学到的“文本→建模”映射是片面的遇到真实工况中常见的钣金件、铸造件就力不从心。另一个问题是文本描述的质量——用LLM自动生成的描述往往带有模板化痕迹比如“这是一个圆形凸台上面有一个孔”真实工程师不会这样描述一个零件他们更可能说“做一个带凸台的底座孔位要和对面零件匹配”。语义分布不匹配训练出来的模型自然在真实输入上表现打折。2. 核心原理与关键设计解析2.1 为什么序列表示能保住“可编辑性”要理解序列方法为什么更受工程欢迎得先看CAD软件自身的建模逻辑。在 SolidWorks、Fusion 360 或 FreeCAD 中用户每一步操作都会生成一个特征节点草图、拉伸、倒角、抽壳、阵列……这些节点按时间顺序构成特征树每个节点保存参数修改参数时软件会重新计算几何。这个结构本质上就是一棵操作树天然可以被线性化成 token 序列。DeepCAD 把每个操作编码成固定格式比如“添加草图圆形拉伸倒角”每一个图元、约束、尺寸都映射成离散token。Text2CAD 继续沿用这种表示但把语言模型编码的自然语言向量与CAD token序列做跨模态对齐。训练时用对比学习让“文本向量”和“对应CAD序列向量”距离更近推理时给定新文本模型从CAD token库里逐步解码出完整建模命令流。这里最容易被忽视的是 token 设计对表达能力的限制。DeepCAD 早期版本不支持样条曲线不支持装配关系布尔运算也只有简单求差。遇到倒圆角半径非整数、孔位阵列等场景表达能力就捉襟见肘。即使后来加了更多操作类型token 字典依然偏小无法表达所有尺寸标注。这意味着模型生成的“支架”可能看起来差不多但实际孔距、壁厚等关键尺寸未必是精确值——对工程模型来说这可能是致命的。我在实测 Text2CAD 时发现它对“plate with two holes”这类简单描述效果不错能生成带两个通孔的板件特征树也干净。但输入“bracket with four slots and a counterbored hole”时常常只生成三个特征槽的位置也可能偏移。这说明模型确实学到了常见的建模模式但对特征数量和空间布局这类细节约束理解力依然有限。2.2 扩散模型如何生成“可以加工”的几何扩散方法在 text-to-3D 领域大放异彩后很多研究者尝试把同样的思路迁移到CAD。基本框架是用文本条件扩散模型生成三维占用场或符号距离场再通过行进立方体抽取等值面得到网格然后用面拟合算法把网格中的平面、圆柱面、球面等解析曲面识别出来组合成可用的B-rep。这套流程里的核心难点是“曲面拟合”环节。Mesh 里的平面和圆柱面容易识别但过渡圆角、样条曲面、复杂倒角面在网格上往往没有清晰边界拟合算法容易把原本是一个连续面的区域拆成多块碎面或者反过来把两个不同面误合并。拟合出的面还需要做延伸、裁剪、缝合这些操作在几何内核如OpenCASCADE层面是典型的稳定性雷区——一个面稍微有点法向偏差后面的布尔运算焊点就找不到了。所以扩散路线虽然能生成视觉上更精细的曲面模型但“可编辑性”和“参数化程度”都很差。作为概念设计阶段的灵感工具绰绰有余要输出给加工厂还差得远。目前业界更务实的做法是把扩散生成的结果当作候选几何再让工程师在CAD里手动重建特征树效率其实提升有限。2.3 大模型脚本生成最“不正经”但最容易被采用的路子我负责任地说目前真正在团队里跑出效果的反而是“LLM直接生成CadQuery脚本”这种看起来不太学术的做法。原因很简单CadQuery 本身是面向代码的CAD库每个操作都是Python函数调用生成的结果天然带参数还能导出 STEP 文件。LLM 在代码生成上的能力已经足够强只要给足上下文示例它能组合出相当复杂的建模脚本。这个关系的核心要点是“给足示例”。不是直接问“帮我画个法兰”而是给模型一个包含“导入CadQuery→创建Workplane→画草图圆→拉伸→加孔→倒角→导出STEP”的完整示例再让它模仿生成。实测效果显著提升因为代码模型擅长模式复用而不是凭空推理几何。另一个关键是包括异常处理——生成脚本在本地执行时UnitTest式的校验函数必不可少比如检查实体体积不为零、面数在合理范围、关键孔位是否存在。宁可脚本运行失败提示用户修改也不要把一个失败的半成品悄悄输出。3. 实操从文本到STEP文件的完整落地流程3.1 环境准备和工具链选择这里给出一套可以直接复现的最简流程。硬件不需要太高普通带CUDA的显卡就行CPU也能跑但推理慢一些。软件层面需要Python 3.9、PyTorch、transformers、CadQuery 2.x、OpenCASCADE 内核CadQuery自带、以及 Matplotlib 或 trimesh 用于模型可视化检查。建议用虚拟环境管理依赖避免把系统环境搞乱。我的命令习惯是先建一个干净的 venv然后按 requirements 安装。装完验证 CadQuery 是否正常最简单的方法是生成一个10x10x10的立方体并导出STEP看看能不能正常读写。这一步能过滤掉很多 OpenCASCADE 安装问题省得后面跑大模型时才发现环境有问题。python -m venv t2cad source t2cad/bin/activate pip install cadquery torch transformers trimesh matplotlibimport cadquery as cq result cq.Workplane(XY).box(10, 10, 10) cq.exporters.export(result, bohr_test.step)能跑通这段代码说明CadQuery和OCCT内核没问题。接下来就可以选择使用现成的 Text2CAD 预训练模型或者直接走大模型脚本生成路线。我的建议是两条腿走路先用公开的 Text2CAD 模型跑几轮感受一下序列生成的能力边界再立刻上手 CadQueryLLM 路线做实际项目前者是“参考标准”后者是“生产力工具”。3.2 用 Text2CAD 预训练模型生成零件特征树Text2CAD 模型发布时提供了基于 DeepCAD 数据集的预训练权重HuggingFace 上有镜像仓库可下载。加载模型后输入一段英文描述模型会输出一串CAD操作序列需要配合后处理脚本把token序列转成实际的三维模型。实操时要注意 prompt 的写法。模型对不同的表述方式非常敏感我整理出几个有效模式零件类别要前置且用最常见的工程名词“a flanged shaft” 比 “a metal rod with a circular protrusion” 效果好得多。尺寸信息尽量写成整数或常见标准值“40mm hole spacing” 优于 “about four centimeters”。不要堆叠过多约束。一个 sentence 里塞下 “four countersunk holes, two slots, a rib, and a chamfer” 时模型几乎必定丢掉某些特征。更好的做法是拆成多个阶段生成再在CAD里合并。尽量用“配合语义”而不是纯堆属性。例如 “a lid that fits on a rectangular box” 比 “a rectangular plate with a fillet” 更容易生成可用结果因为模型能从 “lid” 关联到盒子盖的典型特征布局。生成的序列需要转成 B-rep 模型。这里直接复用 DeepCAD 的预处理和后处理代码先解析 token 序列为特征操作再用 CadQuery 逐步执行。我遇到过一个高概率问题模型生成的尺寸顺序和实际草图绘制顺序不一致导致某些特征交错冲突。最简单的处理办法是生成后做一次自相交检测。OCCT 里的 BRepAlgoAPI_Section 或者 CadQuery 的 val().check() 也能帮上忙。# 伪代码解析CAD token序列并重建 import cadquery as cq def build_from_tokens(cad_tokens): w cq.Workplane(XY) for step in cad_tokens: op step.type if op setPlane: w w.workplane(offsetstep.offset) elif op circle: w w.circle(radiusstep.radius) elif op extrude: w w.extrude(step.distance) elif op hole: w w.hole(diameterstep.diameter) # ... 更多操作映射 result w.val() result.check() return result step_file export_step(build_from_tokens(pred_tokens))3.3 用 LLM CadQuery 做更可控的生成如果你觉得文本生成的特征树还是太 “黑盒”我强烈建议尝试 LLM 直接写 CadQuery 脚本的路线。这不是学术项目但实用性非常硬。做法是构造一个 few-shot 提示词模板。系统提示部分说明输出要求——必须是可运行的 CadQuery Python脚本、必须定义 export_step() 函数、不得使用未知方法、所有尺寸使用 float 类型。示例部分给出一个简单零件如带孔法兰的完整脚本输出部分是目标描述。用 GPT-4o 或 Claude 的 API 调一次就能拿到脚本在本地沙箱里执行。我测试过几个生产环境常见描述的生成效果描述成功生成并导出STEP几何合理性备注三个孔的电机安装座成功孔位需要微调脚本整体可用带加强筋的L形托架成功筋的厚度典型偏厚手动改一下尺寸即可齿轮泵端盖4个安装孔中心轴孔成功轮廓近似缺少制造标注需精修带燕尾槽的滑块第一版失败布尔操作报错加校验后重新生成修复关键的稳定性突破点在于“校验-反馈”循环。第一版脚本执行失败时不要直接放弃把报错信息拼接回提示词让LLM修正。我用这个方式把脚本一次运行成功率从大概40%提升到75%左右。修正几轮后如果不成功就果断换描述策略把复杂零件拆成几个子零件分别生成再装配合并。def verify_step_file(step_path): import trimesh mesh trimesh.load(step_path, forcemesh) # 基础校验体积是否合理、是否闭合 if mesh.is_empty: return False, empty model if mesh.volume 1e-3: return False, fvolume too small: {mesh.volume} if not mesh.is_watertight: return False, mesh not watertight if not has_expected_holes(mesh): # 根据描述里的孔数量做拓扑检查 return False, hole count mismatch return True, ok3.4 模型后处理与导出STEP/STL和可编辑格式该怎么选生成完成后最容易被忽略的是导出格式的选择。下游是3D打印直接用 STL 就可以但要注意单位——很多生成库默认毫米切片软件可能要毫米但也有软件默认厘米单位写错会让模型缩小十倍。下游是CNC加工或者结构仿真必须导出 STEP包含完整B-rep和拓扑信息不要用 STL 转格式因为那会丢失面信息和精度。CadQuery 导出 STEP 很简单而且生成的是参数化历史无关的纯几何文件SolidWorks、Fusion 360、FreeCAD 都能直接打开。但导出的STEP里没有特征树这点要心里有数。如果需要带回特征树的可编辑文件CadQuery 的脚本体本身就是最好的“参数化文档”——改代码里的一个尺寸重跑一遍脚本就是新模型。这是我认为 LLM脚本路线最大的隐藏优势模型的可编辑性不是依赖某种私有文件格式而是依赖一段可读的、可修改的代码。导出前还要做几何清理用、cadquery.val().check() 检查自相交用 BooleanOverlap 检查有没有非流形边。我见过不少生成的模型可视化看着完全正常一导出STEP送进 CAM 软件就崩原因大多是面缝合顺序错误导致的微小裂缝或重复面。OCCT 内核对此类问题的容忍度比显示引擎低得多。4. 常见问题与排查技巧实录4.1 生成的模型尺寸总是“差不多但不精确”怎么办这是 text-to-cad 目前最大的硬伤。模型学到的是统计分布不是精确的几何约束求解器。它对 “hole spacing 40mm” 的理解是“大概40mm小偏差没问题”但在工程里 40±0.1 和 40±0.05 差之毫厘谬以千里。处理办法分两层。第一层是在提示词里把关键尺寸写成“绝对约束”并让模型输出前自检。LLM 脚本路线可以直接在 prompt 里写final_geometry.boundingBox().xlen必须等于期望值然后用断言兜底。第二层是承认自动生成只能完成80%剩下的20%尤其是配合公差、表面粗糙度等制造语义必须由工程师在CAD里手动标定。这不是缺陷而是当前这个阶段的技术边界。知道边界在哪比硬磕模型更高效。4.2 布尔运算失败、面法向翻转和悬挂边CadQuery 和 OCCT 的布尔运算稳定性受很多因素影响。最常见的问题是面法向翻转——模型某个面的法向指向内部导致后续“剪切”操作裁剪掉了错误的半边。另一个高频原因是共面或近共面问题两个零件有完全重合的面或者两个面夹角极小布尔运算体量判断时出现数值误差直接报错。我的排查顺序固定是三步。第一步用val().check()看是否通过自相交检查一旦报错就溯源到具体特征通常是某个拉伸距离过短导致面重叠。第二步检查所有草图的绘制方向CadQuery 中圆的默认方向在XY平面是逆时针拉伸方向和草图法向不一致时面法向就会反。第三步给布尔操作加简化条件比如两个体只保留一个接触面时改用intersect而不是cut有时能绕过问题。稳定起见把复杂的“打孔阵列镜像”组合改成“先建半边再镜像”会大幅减少布尔运算失败率。4.3 提示词歧义怎么定量评估自然语言天生有歧义同一个描述不同人理解不同。如果你把生成结果发给五个工程师看五个人的反馈都不一样那你基本可以判断是这个描述本身有问题。我习惯在跑模型前先用一个简单的“实体数量”测试自查数一下描述里出现了几个显式特征孔、槽、凸台、肋板再想想这些特征之间是否有明确的附着关系。如果自己也数不清那模型肯定更迷糊。这里面有个反直觉的经验短的描述往往效果更差。因为太短的描述缺乏约束条件模型只能用默认参数乱猜。比如 “a cover” 就远不如 “a rectangular cover with four corner holes and a center counterbore” 来得可控。但也别走另一个极端——把描述写成完整的产品规格书里面的约束多到模型无法取舍。经验值是控制在 8 到 15 个关键要素之间既提供足够上下文又不至于摊薄注意力。4.4 复现性差同一个描述每次结果都不一样如果你用过开源 text-to-cad 工具大概率遇到过这个问题同一个prompt跑两次输出完全不同。造成这个现象的原因有两个。一是采样过程引入了随机性——解码阶段的 temperature 参数如果不设置为0每次采样的token概率分布会抖动二是模型训练中文本编码器本身的随机性即便温度设为0在某些框架里也可能因为batch size或分布式种子问题产生差异。工程上我建议设置三个固定值torch.manual_seed、random.seed 和 numpy.random.seed并将 temperature 设为0或接近0的值。即便如此如果还是发现不稳定就检查模型是否处于 eval 模式有的worker忘记model.eval()导致 dropout 还在生效。还有一个容易被忽视的点GPU 上同一模型推理卷积或Transformer计算对某些 GPU 算子可能有非确定性实现比如 cudnn.benchmark 开着的时候 conv 计算会有微小差异。把这些开关都关掉复现性会有质的提升。4.5 数据偏置为什么生成的零件总是“看起来很机械”用 DeepCAD 训练出来的模型生成结果天然偏向数据集里的常见形状——旋转体、拉伸体、简单板件。这是数据分布决定的没法靠调 prompt 突破。如果你要生成的零件形态和训练集差异过大比如薄壁复杂钣金件、有机曲面外壳模型很容易崩溃。这时候最有效的方案不是死磕单一模型而是切换到 LLM 脚本路线或者在现有模型基础上做领域微调。微调数据可以自己造用 CadQuery 批量脚本生成带标注的零件再给模型加一个轻量的 LoRA 适配器两周时间就能看到明显改善。5. 应用场景分析与落地建议5.1 哪些场景适合现在就用 text-to-cad标准件是最适合的入门场景。法兰、支架、齿轮坯、轴套、电机座这一类结构相对固定的零件工程语义清晰特征模式稳定生成成功率很高。即便直接生成的模型不完全符合要求稍微改几个尺寸也比从零开始画快得多。概念设计阶段的方案对比也值得用。设计团队常常需要在几小时内给出三五个不同结构方案的模型用于评审和仿真。传统手工建模节奏慢text-to-cad 可以快速产生多样化的候选方案虽然每个方案的细节精度有限但足够支撑前期可行性讨论。我见过一个团队用这套方法把“L形支架”一个下午迭代了十几版前期阶段效率提升非常明显。参数化族库的构建是另一个很自然的方向。企业可以把历史标准件的文本描述和对应模型整理成数据集微调出专用的 text-to-cad 模型。以后再遇到类似的选型询价输入一段描述直接生成模型能显著压缩非标设计的前期工作量。这个路线技术上已经很成熟主要成本在数据整理和标注但ROI很高。5.2 哪些场景千万别急着上重要承力结构件、配合精度要求高且需要复杂公差标注的零件、产品级的外观件这三类目前都不适合纯自动生成。不是说模型生成不了形状而是生成的模型缺少制造语义没有材料信息、没有公差标注、没有表面处理要求。这些信息在文本描述里很难完整传递即使传递了模型也未必能正确映射到B-rep的属性和标注里。有合规和认证要求的行业比如航空、医疗器械、压力容器也不能直接用自动生成的结果作为设计交付物。倒不是法律禁止而是质量追溯体系要求每个设计决策有依据、可回溯目前的深度学习模型还做不到这一点。在这些领域text-to-cad 可以做辅助但不能作为单一数据源。5.3 实用的落地路线先辅助后自动我给大多数团队的落地方案是三步走。第一步把 text-to-cad 当作“智能图库”——输入描述生成参考模型工程师在此基础上手工修改。这个阶段重点评估生成质量和覆盖度不追求直接可用。第二步针对常用标准件建立微调模型把生成成功率提升到可靠的水平比如90%以上并固化出标准化的“提示词模板校验脚本模型后处理”流水线。第三步把流水线接入PDM/PLM系统让设计人员直接在现有工作流里触发生成任务而不是开一个独立工具来回切。到这个阶段text-to-cad 才算真正嵌入了工程环境。最后说一点个人体会text-to-cad 目前争议很大有人觉得是噱头有人认为是未来。我在实际项目中见过它高效产出的瞬间也见过它不可理喻地反复报错。我的态度是不神话也不否认——把它当成一个“有脾气的实习生”生成结果必须检查、反馈、迭代不能全信。但这个方向的价值已经不容忽视尤其是当你能把生成的脚本当成参数化模板把失败案例当成微调数据时它会随着使用越来越准。未来几年如果解决了复杂模型的表示能力和制造语义标注这两个核心问题text-to-cad 很可能会变成工程师身边的标配工具就像当年的参数化建模软件一样悄悄改变工作的方式。