text-to-cad解析：AI如何将自然语言变成可编辑的参数化CAD模型

做CAD设计的朋友，这两年应该没少听说"text-to-cad"这个词。简单说，就是给AI一句自然语言描述，比如"一个带四个螺栓孔的安装底板，长120毫米，宽80毫米，厚10毫米"，它直接给你生成一个可编辑的参数化CAD模型，输出STEP或STL文件，不再需要你手动拉草图、加约束、做拉伸切除。

我大概是去年开始认真折腾这个方向的。一开始也觉得是噱头，毕竟CAD建模这行门槛不低，草图约束、特征树、布尔运算这些逻辑，不是一句两句能讲清楚的。但实际跟进了几轮开源项目和技术报告之后，我承认自己判断错了：text-to-cad不是玩具，它正在变成工程前期方案探索、非标件快速生成、甚至教学场景里非常实用的工具。这篇文章我就把自己从原理到实操踩过的坑、验证过的流程，完整梳理一遍，给想入手这个方向的朋友一个参考。

1. 内容整体设计与思路拆解

1.1 text-to-cad 到底在解决什么问题

先说痛点。传统CAD建模的路径，本质上是把"脑子里想的三维形状"翻译成"软件能执行的特征操作"。这个翻译过程极度依赖经验：一个老师傅画一个支架可能只要十分钟，但新手光是搞明白"先建基准面还是先画草图"就能卡半小时。更麻烦的是，很多结构件、连接件、外壳类零件，功能需求是清晰的，但三维形态有无数种实现方式，手动建模的时间往往花在反复调整尺寸和特征顺序上。

text-to-cad的定位不是取代设计师，而是把"想法到初步模型"这一段最耗时、最不 creative 的环节自动化。它做的事情，本质上是把自然语言映射成一系列CAD操作序列。这个操作序列不是渲染出来的图片，而是真实的建模指令——拉伸、旋转、打孔、倒角、布尔差集等等。所以它生成的模型，跟你手工建的一样，特征树可展开、尺寸可改、后续能进CAM或者仿真流程。

我自己的理解是，这玩意儿解决的是"方案探索成本"问题。以前想对比三五个不同布局的外壳方案，每个都得完整建模，半天就没了。现在用text-to-cad，一个上午能出十几版初始方案，挑出靠谱的再精修，效率不是一个量级。

1.2 方案选型：生成式AI走哪条技术路线

目前text-to-cad的主流实现，不是大家想象中那种"扩散模型直接生成点云再变成网格"，而是走的大语言模型路线。这背后的逻辑其实很朴素：CAD模型本质上可以被表示成有序的命令序列，而大语言模型最擅长的恰恰就是生成序列。

具体来说，业界主流做法是把CAD建模过程拆解成边界表示和构造实体几何两条路。边界表示记录的是模型的最终几何拓扑——哪些面、哪些边、哪些顶点，适合存储和交换，但不适合让模型"思考"如何建模；构造实体几何记录的是建模操作树——先画什么、再切什么、最后倒角多少，这天然就是一种结构化语言。text-to-cad选的是后者这种命令序列的表达方式，把建模过程变成了一串带参数的指令。

为了避免读者觉得抽象，我用一个类比：让AI生成CAD模型，相当于让AI写一篇作文。如果你只给它看最终印刷出来的文章（边界表示)，它很难学会写作逻辑；但如果你给它看草稿纸上的修改痕迹、段落大纲、每个句子怎么搭出来的（构造实体几何)，它就更容易模仿这个过程。text-to-cad的路线就是后者，而且指令本身是显式、可校验的，这也是它能落地的关键。

2. 核心细节解析与实操要点

2.1 数据底座：CAD命令序列怎么组织

既然是让模型生成命令序列，那么训练数据就是整个项目的命脉。我看过的几个开源项目，比如基于合成数据做训练的Text2CAD，它的数据管道大致是这样的：先准备好大量带特征树的原始CAD模型，然后把特征树按拓扑顺序转译成JSON格式的命令序列，每个命令包含操作类型和完整的参数列表。

举个例子，一个简单的带孔方块，它的命令序列大致长这样：

[ {"op": "Box", "params": {"x": 120.0, "y": 80.0, "z": 10.0}}, {"op": "Cylinder", "params": {"radius": 6.0, "height": 10.0}}, {"op": "Translate", "params": {"x": 20.0, "y": 20.0, "z": 0.0}}, {"op": "Subtract", "params": {}} ]

这里每个op字段代表一个建模动作，params是它的参数。模型要学的，就是从一句自然语言里提取出"长120、宽80、厚10、四个角落各一个直径6的孔"这些信息，然后排列组合出正确的操作序列。这个序列的生成质量，直接决定了最终模型是不是你想要的。

这里有个重要细节：如果模型生成的命令只有形状而没位置，那布尔运算的一堆实体可能全堆在一起，模型完全报废。所以数据集里必须包含完整的变换信息——平移、旋转、镜像，缺一不可。我自己清洗数据的时候就踩过这个坑，后面会细说。

2.2 模型的架构设计：为什么是"视觉语言模型"而不是纯文本模型

早期一些尝试只有文本输入，但实际工程里，很多需求是带着参考图的，比如"照着这个草图做一个类似的支架"。这就推动了text-to-cad从纯语言模型向视觉语言模型演进。给模型加一个视觉编码器，让它能同时理解文字和图片。

我关注的一个代表性项目是MM-Text2CAD，它在Llama-3-8B的基础之上，通过监督微调和RLHF训练，把通用大模型"改造"成一个CAD专家。这条路线最大的优点是站在巨人肩膀上——不需要从头训练一个模型，而是在现有底座上做领域适配。8B的参数量也控制得比较合适，个人开发者用消费级显卡还能跑一跑推理，不像几百B的模型那样只能看热闹。

另外我发现，后训练阶段除了传统的RLHF，现在越来越流行用RLVR，也就是可验证奖励的强化学习。对于CAD生成来说，这个"可验证性"特别好定义：生成的命令序列是不是合法JSON，能不能被CAD内核执行，执行完的结果是不是封闭实体，数值是否落在合理公差范围内。这些都是客观可判的，不需要人类打分。所以模型可以自己试错、自己改进，效果提升比单纯靠标注数据要快得多。

2.3 输入输出的关键约定

实操层面，text-to-cad目前的输入不能太"口语化"。你如果说"帮我做个好看点的零件"，模型大概率会给你生成一个奇奇怪怪的抽象雕塑。比较可靠的输入格式是结构化的功能描述，我总结了一个模板：

• 零件类型（底板、支架、外壳、法兰等）
• 关键外形尺寸（长宽高或直径）
• 关键特征（孔、槽、螺纹、加强筋）
• 特征的位置关系（阵列、对称、角落定位）
• 可选的参考图（多视角或三视图）

输出侧，好的text-to-cad工具会同时给你两样东西：一个可视化的预览，以及一个可编辑的CAD源文件。底层的命令序列也会以JSON形式暴露出来，方便你做二次开发或者自定义后处理。

个人经验是，输出格式里最值钱的是STEP文件。因为STEP是ISO标准的几何数据交换格式，几乎所有的CAD软件——SolidWorks、FreeCAD、Fusion 360——都能直接导入。拿到STEP之后再进去补特征、改尺寸，就是普通的CAD操作了，完全没有学习成本。

3. 实操过程与关键环节实现

3.1 环境准备：硬件、依赖和模型权重

我建议想动手玩text-to-cad的朋友，硬件门槛按下面这个表来规划：

软件方面，依赖项主要就是PyTorch、HuggingFace Transformers、以及模型仓库里自带的推理代码。有的项目还依赖CadQuery或OpenSCAD来做几何内核校验，这个不是必须的，但强烈建议装上——后面你会发现，让AI生成的结果过一遍真正的CAD内核，能筛掉大量空气模型。

3.2 快速体验流程：从命令行到本地服务

如果你只是想在本地跑通一个text-to-cad的推理，我建议按下面的步骤来：

1. 克隆项目仓库，用conda创建一个干净的Python 3.10环境。
2. 安装依赖，核心就是transformers和torch，注意版本兼容，我遇到过新版transformers接口变更导致推理脚本跑不动的情况，所以建议直接用项目里lock住的版本。
3. 下载模型权重。很多项目会提供GGUF量化版和原始FP16版，如果显卡显存只有16GB，优先用量化版。
4. 写一个最简推理脚本，输入一句文本描述，拿到JSON命令序列和可视化的预览图。

我自己第一次跑通的瞬间还挺有成就感的，输入"一个直径50毫米、高30毫米的圆柱体，顶部中心有一个直径8毫米的沉头孔"，几秒钟之后，一个规规矩矩的零件就出来了。当然这是简单的，但方向对了。

3.3 用gradio搭一个本地交互界面

命令行工具虽然能用，但体验挺原始的。我更推荐用gradio搭一个简单的本地Web界面，输入框写描述、上传参考图、点一下生成，右侧直接显示三维预览。

gradio的代码不复杂，核心就是把模型推理函数包成一个接口：

import gradio as gr def generate_cad(text, image): # 这里调用text-to-cad模型的推理函数 cmd_sequence = model.generate(text, image) step_file = render_cad(cmd_sequence) # 调用CadQuery/OpenSCAD生成几何 return step_file demo = gr.Interface( fn=generate_cad, inputs=[gr.Textbox(label="描述零件"), gr.Image(type="pil", label="参考图(可选)")], outputs=[gr.Model3D(label="CAD预览"), gr.Textbox(label="命令序列")] ) demo.launch()

注意输出用了gr.Model3D，可以直接显示GLB/STL格式的三维预览，体验比看命令行输出强太多。搭好这个界面之后，我实测下来，给身边非技术背景的同事用，他们也能很快上手，这就说明工具形态本身很重要。

3.4 从命令序列到真实可编辑的文件

这里要提醒一个关键点：模型直接输出的是命令序列，不是CAD文件。要把命令序列变成你可以拿去加工或二次编辑的内容，还必须经过一次"编译"。

我用的方案是CadQuery，它是一个用Python写CAD模型的库，直接把命令序列翻译成CadQuery代码再执行，最后导出STEP。这里给一段我常用的转换逻辑示例：

import cadquery as cq def commands_to_model(commands): result = None for cmd in commands: op = cmd["op"] if op == "Box": result = cq.Workplane("XY").box( cmd["params"]["x"], cmd["params"]["y"], cmd["params"]["z"] ) elif op == "Cylinder": result = cq.Workplane("XY").circle( cmd["params"]["radius"] ).extrude(cmd["params"]["height"]) elif op == "Subtract" and result is not None: result = result.cut(cutter) # cutter 由前序操作传入 # 其他操作按类似方式逐条解析 return result model = commands_to_model(cmd_sequence) cq.exporters.export(model, "output.step")

这段代码是示意，实际用的时候要处理的操作类型比这多，比如放样、扫描、圆角、阵列等，但逻辑是一致的：逐条解析、逐条执行，最后导出。只要有这一步，AI生成的东西才能真正进入你的设计工作流。

3.5 参数调优：温度、top-p和最大token长度

很多朋友第一次上手text-to-cad，遇到模型胡言乱语，第一反应是"这模型不行"，但很多时候其实是采样参数没调对。我整理了三个最关键的参数供参考：

• 温度：控制生成随机性。CAD生成跟写诗不一样，我们要的是确定性。建议温度设在0.1到0.3之间，我习惯直接设0.1，基本每次都能给出稳定可预期的结果。
• top-p：采样时只从累计概率前90%的token里选。配合低温度使用，能避免模型突然跳去生成一堆无意义的旋转矩阵。
• 最大token长度：CAD命令序列往往很长，尤其零件特征多的时候。如果上限设太小，生成中途就被截断，然后给你一个只建了一半的模型。8B模型单次上下文建议至少4096，复杂零件建议8192。

3.6 实战案例：从描述到成品的完整记录

这里还原一个我前两天做的测试：让AI生成一个"用于固定步进电机的安装支架，外形100x80x8毫米，四角有直径5毫米的通孔，中心有一个直径22毫米的圆形凸台，高度5毫米"。

整个执行过程很快，模型先生成JSON命令序列，我检查了一下长度和操作类型，一共三段：底板Box、凸台Cylinder、四角四个通孔Cylinder加Subtract。随后用CadQuery执行，导出STEP后直接拖进FreeCAD，特征树完好，尺寸可改。整个过程大概不到两分钟，而这个零件如果让我手工建模，从建草图到约束到阵列保守估计十五分钟。尤其值得肯定的是，模型对"四角有通孔"这个位置描述的解析做得很好，没有出现孔落在边界上这种低级错误。

4. 常见问题与排查技巧实录

4.1 四个高频问题的排查方案

4.2 独门坑位回忆录：坐标系与镜像翻转

最坑的一次，我让模型生成一个左右对称的钣金件，输入里写了"mirror along X axis"，结果出来的模型怎么翻都不对。我检查了命令序列才发现，模型生成的镜像操作矩阵里有一个符号错了，导致整个实体变成了镜像加翻转。这说明一件事：模型虽然学了语法，但没有真正"理解"几何变换的物理意义，它只是把训练集里的模式复述出来。

解决办法是在数据标注或后处理阶段加入几何合法性校验。具体操作是：生成完成后，用CadQuery计算实体的体积、包围盒，跟描述里的目标值做比对，超出5%的误差就直接标记生成失败，重新采样一次。这种做法虽然粗暴，但非常有效，能过滤掉大部分"看起来对、量起来错"的情况。

4.3 模型幻觉：如何处理"合理但不存在"的特征

还有一个值得说的现象：模型偶尔会"发明"一些你根本没要求过的特征，比如在底板上加一圈莫名倒角、或者在一个简单梁结构里多塞了两个装饰性的凸台。这种现象本质上是模型在拟合训练数据的高频模式，并不代表它理解你的需求。

对这种问题，我的策略是从提示词层面压一压，明确写"只生成描述中要求的特征，不要添加额外修饰"，同时把温度设置为最低，减少自由发挥的空间。如果模型还在自由发挥，就回到数据层面：它在训练集里见过的各种花哨零件太多了，对"简洁"这个概念的锚定不够。可以考虑用约束更强的采样方法，或者人工审核命令序列，把多余操作删掉再重新执行。

5. 工具生态与选型参考

5.1 开源项目横向对比

现在text-to-cad方向的开源项目正在快速迭代，我简单对比一下几类代表性方案的优劣势，方便大家选型。

就个人开发和学习而言，我建议优先选开源的、支持本地部署的端到端方案，一方面数据不出门，另一方面你可以直接看到命令序列的生成过程，这对理解模型行为和二次开发都更有帮助。

5.2 配合传统CAD的混合工作流

把text-to-cad看成传统CAD的替代品，是对它最大的误解。实际价值最大的用法，是混合工作流：先用AI生成大量结构候选方案，从中筛选有希望的，导出到参数化CAD里精修，再走仿真或加工流程。

我目前的典型流程是：AI出五个方案，我人工挑一个，用FreeCAD打开STEP，修改关键尺寸和公差，然后出工程图。整个过程里，AI完成的是"从零到一"的草稿阶段，我做的是"从一到十"的工程化阶段。这个分工非常舒服。

6. 退一步看：边界与未来的想象空间

6.1 当前技术的边界在哪里

必须坦诚地说，text-to-cad解决得好的还是以平面特征为主、带孔带槽带凸台的机械类零件。一旦涉及复杂的自由曲面——比如手机外壳那种双曲面弧度、涡轮叶片这种扭曲扫掠——目前的开源模型表现就一般了，经常生成破面、自相交几何或者根本没法导出的垃圾数据。

此外，多实体装配体级别的生成也还早得很。模型现在能生成的往往是一个零件，顶多是共轴组合的状态，但那种"十几个零件怎么装配在一起"的逻辑，涉及运动副、配合关系、冗余约束，远超当前数据驱动的能力范围。指望写句话直接给你一个能在仿真环境里跑的装配体，还不太现实。

6.2 后续扩展的可能性

往深一步想，text-to-cad未来大概率会和拓扑优化、生成式设计做更深的融合——比如你只给约束条件和载荷工况，AI直接生成满足力学性能的结构形态。这条路目前虽然只有雏形，但方向非常清晰。

对普通用户来说，现在就是入场学习的最佳时机。因为技术迭代速度极快，越早熟悉这类工具的工作方式和边界，越能在自己的设计流程里找到合适的嵌入位置。

我在实际操作中最大的体会是：不要指望AI一步到位给你一个完美模型，它最大的价值在此，但门槛恰恰也在此——你得有一定的CAD审模能力，能判断模型的合理性，能修改尺寸和特征，而这恰恰是传统工程师本来就该有的基本功。把它当脚手架，别把它当设计师本人。