做机械设计、3D打印或者结构件的朋友，大概率都有过这种经历：脑子里明明已经把零件的形状想得很清楚了，结果打开CAD软件，先建草图、给约束、拉伸出实体、再切孔倒角，一套流程走下来少说十几分钟，要是遇到复杂配合面，折腾一两个小时也正常。text-to-cad这个方向，本质就是冲着这个痛点来的——让用户用一句自然语言描述，直接拿到一个可编辑、带特征树的三维参数化模型，而不是仅仅给一个摸不着的网格体。2024年到2025年，这个领域的论文和开源项目密集爆发，从Text2CAD、CADGPT到各家的商业探索，热度一路飙升。这篇文章我会把text-to-cad背后的几条技术路线掰开揉碎讲清楚，再给出一套本地可跑的实操流程，最后聊聊它对不同行业的实际影响。无论你是机械工程师、创客玩家，还是做AI应用开发的算法工程师，这篇文章都能帮你少走不少弯路。
1. text-to-cad在解决什么现实痛点
1.1 传统CAD建模流程的瓶颈在哪里
要理解text-to-cad的价值，得先回到传统建模流程本身。当前主流的参数化CAD建模，不管是FreeCAD、SolidWorks还是Fusion 360，本质上都是“草图+特征”两步走。你先在二维平面上画好轮廓，再通过拉伸、旋转、扫掠、放样这些特征操作把轮廓变成三维实体。
这套思路从八十年代用到现在，非常成熟，但问题也明显。首先是学习门槛高，一个新用户要熟练掌握草图约束、特征顺序、基准面概念，至少需要几周的系统学习。其次是操作和思维之间存在一层“翻译损耗”，人脑子里想的是“一个法兰盘，内孔直径30mm，外圈直径60mm，四个均布的安装孔”，但在软件里你得先建草图、画圆、约束圆心在原点、给圆加定尺寸，再拉伸出厚度，再选中上表面打孔、阵列四个孔。这个翻译过程既磨人又容易出错。
行业内其实早就有了一些折中方案，比如参数化标准件库、模板库、设计向导，但这些都属于“预制件”，遇到稍微非标的零件就得回到原始建模流程。text-to-cad想做的，是真正把“自然语言意图”到“特征树/构造序列”的翻译过程自动化，这是它跟传统模板库、宏录制本质不同的地方。
1.2 一条命令拿到参数化模型意味着什么
text-to-cad的输出不是一张静态图片，也不只是三角网格（Mesh），而是可以继续编辑的参数化模型。这一点非常关键，决定了它能不能真正进入工程链路。
我举个例子，你输入“帮我生成一个内径30mm、外径50mm、厚度8mm的环形垫圈”，一个好的text-to-cad系统应该输出类似“创建一个草图平面、画两个同心圆、拉伸8mm”的构造序列。这个序列可以被后端CAD内核执行，生成一个带完整特征树的历史模型。你在CAD软件里打开后，可以双击特征修改尺寸，垫圈会自动更新。
这就把“描述-建模-修改”的周期大幅压缩了。以前改一个尺寸，要回到草图重新约束；现在改一句话，模型自动跟着变。更进一步，如果系统能理解装配关系描述，比如“把电机安装座放在支架上表面，四个孔距为22mm”，那设计阶段的方案探索效率会提升一个量级。
聊到这里你可能会问，市面上已有的文本生成3D模型技术，比如Point-E、Shap-E、MeshXL，不也能做到“文字出模型”吗？它们的区别在于，那类技术输出的是隐式表示或网格模型，适合做可视化、动画，但工程上没法直接拿去加工，因为没有特征树、没有精确尺寸关系、也不能参数化驱动。text-to-cad回归到了CAD的底层语言——构造序列和B-Rep边界表示，输出的模型进了Fusion 360、FreeCAD依然是可编辑的实体，这是它最有价值的地方。
2. 技术原理深度拆解：模型怎么“听懂”文本再“画出”模型
2.1 参数化建模路线：让大模型学会“写建模代码”
目前最主流、也最接近落地的技术路线，是把CAD建模过程抽象成“程序合成”问题。具体做法是：把构造序列（construction sequence）描述成一种类代码的结构化语言，然后微调大语言模型（LLM），让模型学会从自然语言映射到这种结构化语言。
这里需要理解一个背景概念：CAD模型在软件里并不是一堆三角形的组合，而是一个“特征历史列表”。比如创建垫圈的过程可以拆成：新建草图→画两个圆→添加同心和尺寸约束→拉伸实体→完成。每一步操作背后都有参数。业界把这类数据整理成了带注释的向量化表示。最有代表性的公开数据集是滑铁卢大学开源的DeepCAD数据集，里面包含了约17.5万个机械CAD模型的完整构造序列。稍晚一些提出的Text2CAD数据集又给其中约1.8万个模型补充了自然语言描述，形成了“文本-构造序列”的平行语料。
有了数据，剩下的工作就变成了常规的大模型微调流程。以Text2CAD项目的做法为例，他们把构造序列编码成一种专用的标记语言（CAD语言），用Llama-3系列这样的小型LLM作为底座，用LoRA或全参数微调，让模型学习从文本token映射到CAD指令token。
这条路线最大的优势是输出天然可编辑、可直接对接现有CAD生态。因为生成的本来就是一串构造指令，后端只要用FreeCAD或CadQuery这类工具执行一遍，就能得到实体模型。
但它的难点也很突出，首先是数据获取成本高，带文本描述和完整构造序列的CAD数据非常稀缺，远远达不到互联网文本的规模。其次是构造序列的语义歧义，同一句话可能对应多种建模路径，模型可能给出一个“能跑通但结构不合理”的序列，比如该用旋转特征的地方用了拉伸，结果模型形状对但特征树很糟糕。这需要靠数据质量和后处理约束来缓解。
2.2 深度生成路线：条件扩散模型生成几何
另一条技术路线，是用条件扩散模型直接生成几何形状，本质上是把文本生成的思路搬到3D领域。典型的做法是，将三维形状编码成带符号距离场（SDF）或者占用场（Occupancy Field），然后训练一个以文本embedding为条件的扩散模型，逐步去噪生成几何体。
这条路线有一个很直观的优点：它对形状的描述能力更强，尤其适合有机形态、异形曲面这类很难用参数化特征表达的造型。比如你描述“一个具有波浪形边缘的花瓶”，参数化路线可能要想尽办法拆成放样和曲面裁剪，但深度生成路线直接从头合成几何，效果往往更自然。
问题在于，这套方法输出的几何是网格或体素，不具备特征树，也不能参数化驱动。你拿到的模型在工程软件里是“死”的，想改一个厚度，只能重做。所以这条路线目前更适合可视化、游戏资产、艺术设计的场景，离真正的机械设计和制造还有距离。也有一些团队在做“网格转B-Rep”的逆向重建，但这类转换精度损失很大，目前工程上还不太实用。
在我个人看来，这两条路线短期内的定位是互补的：参数化路线吃掉“规则零件”的大量需求，深度生成路线负责那些“说不清特征、只看重形状”的创意设计。
2.3 混合方案与关键数据集盘点
为了兼顾可编辑性和复杂曲面能力，学术界和工业界都在尝试混合方案。
一种常见的做法是“检索增强生成”：系统先根据文本描述去庞大的历史CAD模型库中检索最相近的模型，然后把检索到的模型结构作为先验输入给生成模型，让生成模型继续修改。这很像程序员写代码时先搜索相似代码再改改，而不是真从零按字符敲。Autodesk在2024年展示的Project Bernini思路就与此类似，官方演示视频里它可以根据文本描述生成可编辑的参数化模型，内部大概率用了多模态大模型与几何约束相结合的方式。
还有一条很实际的路线是把多模态大模型当“调度中枢”，让模型先生成CadQuery、OpenSCAD或者FreeCAD的宏代码，再用传统CAD内核去执行。这种方案不要求大模型直接生成复杂的二进制几何，只需它生成文本格式的代码，难度降低很多，而且工程上非常可落地。
做这类工作前，有几个关键数据集值得先研究：
| 数据集 | 规模与内容 | 适用场景 |
|---|---|---|
| DeepCAD | 约17.5万个机械CAD模型，包含完整构造序列 | 训练构造序列生成模型 |
| Text2CAD | 约1.8万个带自然语言描述的CAD模型 | 微调文本到CAD的LLM |
| Fusion 360 Gallery | Autodesk开源，包含B-Rep操作序列与设计参数 | 研究特征树结构与参数化关系 |
| CADBench | 约9000个构建与编辑任务，含多类别描述 | 评测text-to-cad模型的生成质量 |
| ABC Dataset | 约100万个B-Rep模型（边界表示为主） | 大规模几何深度学习预训练 |
我的建议是，如果只是入门尝试，优先用DeepCAD做自监督预训练，再用Text2CAD做指令微调；如果研究目标是评估模型在真实设计任务上的表现，CADBench是目前最接近“考试题”的基准。ABC数据集虽然量大，但很多模型没有自然语言标签，直接用起来反而要花大量时间做清洗和标注。
3. 从零实操：在本地跑通参数化text-to-cad
3.1 环境准备与依赖安装
纸上谈兵没意思，下面我给出一个经过实测的本地部署流程。这套方案不需要你拥有十几张显卡的服务器，一张消费级的RTX 4090就能跑，如果显存小一些，用QLoRA的4bit量化也能降一降门槛。
我个人推荐的操作系统是Ubuntu 22.04，用WSL2在Windows下跑也可以，但涉及CAD后处理和可视化时，原生Linux比WSL2省心很多。硬件方面建议最少16GB内存、24GB显存，实际上我测试时，用单张4090跑3B模型的QLoRA微调，峰值显存在14到16GB左右。
依赖安装分两大块。第一块是深度学习链路：
conda create -n text2cad python=3.10 -y conda activate text2cad pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers peft accelerate datasets bitsandbytes pip install huggingface_hub第二块是CAD后处理链路。这里我推荐用CadQuery，它是一个用Python写参数化CAD模型的库，底层封装了OpenCascade，生成的实体可以直接导出STEP格式，放进FreeCAD、Fusion 360继续编辑：
conda install -c conda-forge cadquery=2.4 pip install jupyter-cadquery如果你确定要跟进Text2CAD项目做完整复现，建议再建一个干净环境安装项目源码的依赖：
git clone https://github.com/Text-to-CAD/Text2CAD.git cd Text2CAD pip install -r requirements.txt这个仓库里包含了数据预处理、模型训练和推理的完整代码，结构不复杂，很适合读源码学原理。
3.2 数据准备与模型微调
数据准备是整个流程里最耗时、也最影响结果的一步。Text2CAD项目的官方数据来自HuggingFace上的text2cad-dataset仓库，但原始数据是JSONL格式的CAD命令序列，不是现成的“文本+代码”对，需要自己处理。
我先给你一个精简版的数据处理思路。Text2CAD数据集里每条样本的核心内容是一个二维数组格式的构造序列，包含命令类型、命令参数和草图信息。要让它变成可训练样本，需要做两件事：
第一，把构造序列转成语义化的文本描述。比如Extrude命令的参数要转成“沿Z轴拉伸10mm”这样的表述，让模型理解命令的几何含义。这一步工作量大一些，但直接关系到最后生成代码能不能读、能不能用。我测试时发现，如果跳过语义化解码直接喂原始token，模型确实能跑到很低的loss，但生成结果经常是乱码级别的不可用代码。
第二，把原始数据与CadQuery脚本对齐。这里我的做法是写一个转换器，把DeepCAD或Text2CAD的构造序列翻译成一段CadQuery Python脚本。举个例子，一条简单的“圆柱体”样本，转换后的训练目标大概是：
import cadquery as cq result = cq.Workplane("XY").circle(20).extrude(10)然后构造指令模板，在每一对“文本描述-输出代码”之前加上提示词：
你是CAD建模助手。请根据用户描述，生成一段可执行的CadQuery代码，只输出代码，不要额外解释。 用户：生成一个内径30mm、外径50mm、厚度8mm的环形垫圈。 输出：模型微调用LoRA就够了。以Llama-3.2-3B-Instruct为底座，我的建议超参如下：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| lora_r | 16 | 低秩矩阵的秩，调大能提高表达能力但也增加过拟合风险 |
| lora_alpha | 32 | LoRA缩放系数，通常设为lora_r的2倍 |
| lora_dropout | 0.05 | 防止过拟合 |
| learning_rate | 2e-4 | LoRA微调常用学习率范围 |
| batch_size | 1 | 单卡显存有限时优先设为1 |
| gradient_accumulation_steps | 16 | 模拟等效batch_size=16 |
| max_seq_len | 1536 | 太短会截断长序列，太长增加显存压力 |
| epochs | 3 | 数据量不大时，过拟合风险需关注 |
我实际跑的时候，调整目标模块为target_modules=["q_proj","v_proj","k_proj","o_proj","gate_proj","up_proj","down_proj"]，开启4bit量化和梯度检查点，训练总时长大约3到4小时可以完成，最终验证集上生成代码可执行率能到70%以上。这个可执行率是目前衡量生成质量最实用的指标，比什么BLEU都有意义。
3.3 推理生成与模型导出
微调完成后，推理过程分三步走。第一步写一个简单的推理函数，加载底座模型和LoRA适配器，接收用户文本输出代码：
import torch from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig from peft import PeftModel base_model_id = "meta-llama/Llama-3.2-3B-Instruct" adapter_path = "./text2cad-lora-adapter" quant_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_compute_dtype=torch.bfloat16, bnb_4bit_use_double_quant=True, ) model = AutoModelForCausalLM.from_pretrained( base_model_id, quantization_config=quant_config, device_map="auto" ) model = PeftModel.from_pretrained(model, adapter_path) tokenizer = AutoTokenizer.from_pretrained(base_model_id) def generate_cad_code(prompt_text): prompt = f"你是CAD建模助手。请根据用户描述，生成一段可执行的CadQuery代码，只输出代码，不要额外解释。\n用户：{prompt_text}\n输出：" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") outputs = model.generate( **inputs, max_new_tokens=1024, temperature=0.2, top_p=0.9, do_sample=True, ) return tokenizer.decode(outputs[0], skip_special_tokens=True).split("输出：")[-1]第二步，拿到代码后先做语法检查，再去CadQuery里执行。这里有一个非常重要的工程细节：永远不要直接执行模型生成的代码，必须先做静态检查，否则一段错误的代码可能导致进程崩溃，或者占用大量的临时内存。我自己的做法是先调用ast.parse做语法校验，再用超时机制包一层线程池执行，超过10秒就终止。
import ast import cadquery as cq def safe_execute_cq(code_str, timeout=10): ast.parse(code_str) # 语法检查 exec_globals = {"cq": cq} result = {} with TimeoutThread(timeout): exec(code_str, exec_globals, result) return result.get("result")第三步，把CadQuery生成的实体导出成STEP格式，再导入FreeCAD做可视化检查。这一步的目的是验证模型是真的“可以编辑”而不是一个死的网格体。
cq.exporters.export(result, "output.step")导出之后，我还习惯顺手写一个控制台检查脚本，统计每次生成的成功率、平均代码长度和尺寸偏差阈值，这样调整模型参数时才有量化依据。我强烈建议你也建立这个习惯，text-to-cad的生成结果天然是多模态的“代码+几何”，只看文本指标很容易被误导。
4. 常见问题与排查技巧实录
4.1 生成代码报错但模型loss很低
这是最典型的坑。模型在训练集上loss很低，但推理时生成的代码经常有语法错误或者语义错误。原因很简单：生成代码不同于生成普通文本，它对token级别的精确度要求极高，一个括号、一个缩进错了，整个程序就跑不起来。而交叉熵loss并不能完全反映代码执行的正确性。
我踩过几次坑之后的经验是，训练阶段就要把“代码可执行率”纳入评估指标。做法是每隔几百步做一次验证集推理，把生成的代码批量丢进CadQuery执行，统计可执行率，而不是只看loss。另一个很有效的技巧是在数据集中加入一定比例的负样本——故意给模型看一些带错误的代码，并让输出变成“代码不可执行，错误原因：...”，这样模型会学到自查能力。
如果推理阶段代码仍然报错，可以写一个重试框架，解析错误信息并反馈给模型让它自己修正。我在实践中把错误信息拼接进提示词，比如“你的代码有语法错误：expected an indented block，请重新生成”，成功率能提升大约15个百分点。
4.2 生成结果尺寸与描述不符
尺寸偏差是另一个高频问题。比如用户说“直径50mm”，模型生成代码里写成了circle(50)，但这里的50其实是半径，于是实体直径变成了100mm。这是训练数据中尺寸语义混乱导致的，有些数据集把参数记为直径，有些记为半径，有些直接按比例描述。
解决思路是结构化清洗数据。我在准备训练语料时，把所有几何尺寸都统一成“直径/半径”显式标注，并且把单位强制规定为毫米。同时，在指令模板里强调“所有尺寸单位为毫米”，并且在采样阶段用更低温度（temperature=0.1或直接greedy decoding）来减少尺寸随机性。如果你对某个零件的尺寸要求极其严格，更稳妥的方案是后处理，即让模型只生成关键轮廓，尺寸参数通过CadQuery变量从外部注入。
4.3 显存不足与训练速度过慢
本地跑text-to-cad微调最现实的问题就是显存。用7B甚至13B模型时，24GB显存基本就是极限，3B模型则宽松很多。如果还想省显存，优先做四件事：QLoRA 4bit量化、梯度检查点（gradient_checkpointing=True）、混合精度训练（bf16）、以及梯度累积。四件事同时打开，3B模型的峰值显存能压到10GB以下。
如果显存没问题但训练速度慢，最该优先优化的是max_seq_len。CAD代码序列经常很长，如果把所有样本都截断到2048，注意力计算量非常大。我实测下来，大多数样本的实际有效长度在500到800之间，把max_seq_len从2048降到1024，训练速度提升约40%，而生成效果几乎不受影响。
4.4 中文提示词表现不佳
目前公开的text-to-cad数据集基本以英文为主，所以直接输入中文描述时，模型的表现往往不尽如人意。解决这个问题的方案有两种。第一种是输入前加翻译层，先把中文翻译成标准化英文模板，再喂给模型，这也是速度最快的方案。第二种是在微调数据中加入高质量中文样本，我自己的做法是收集了大约2000条机械零件描述，人工翻译成英文后与原始数据混合训练。效果上第二种明显更好，模型能直接理解“法兰盘”“垫片”“沉头孔”这类中文术语，但成本也高出不少。
如果你暂时没有精力采集中文数据，我的建议是先走“中文描述→英文模板→生成代码”这条链路，实测也够用。
5. 应用场景与影响范围：谁能先吃到这波红利
5.1 标准件与参数化模板的高效生成
text-to-cad短期内最确定的落地场景是标准件和半标准件的自动生成。螺栓、螺母、垫圈、销轴、壳体、支架这一类零件，几何结构高度规律化，描述起来也高度模板化，非常契合当前模型的生成能力。
我试过真实场景，让模型基于企业内部的命名规则和参数表生成对应的安装支架，原来一个工程师要花大半天画的三维模型，现在十分钟内出初稿，工程师只需花少量时间做细节检查和修改。这不是“自动化取代设计”，而是把设计人员从重复性建模中解放出来，把精力放到真正的创新方案上。对零部件供应商和装备制造企业来说，这类效率提升的价值是非常直接的。
5.2 概念设计与快速原型验证
在产品设计早期阶段，设计师经常要快速验证多个外形方案。以前的做法是手动建模或者找历史模型改参数，现在可以直接口述“这个外壳左侧加一个耳朵形状的凸台，右侧开一个长条形的凹槽”，让系统生成初稿。
对3D打印玩家、创客社群来说，这个能力更实用。很多时候我做For Fun的项目，需要的只是一个能打印的支架或盒子，根本不关心模型内部的特征树是否美观。text-to-cad让我只需要把想法说清楚，就能拿到一个可以切片打印的模型，门槛一下子降到了零。
5.3 对大厂与设计生态的长期影响
从2024年以来，几大CAD厂商都有动作。Autodesk发布了Project Bernini的实验演示，PTC收购了FrencinAI的团队，云端CAD平台Zoo也推出了名为Waldo的文本生成CAD功能，这些信号足以说明行业已经认可“文本生成CAD”不是噱头，而是下一代设计工具的重要方向。
不过我不建议把这理解成“CAD软件要被取代”。参数化CAD依然是精确设计、加工制造的基石，text-to-cad改变的是设计入口——让更多人能参与建模，让熟练工程师更高效地完成日常建模任务。未来的CAD软件大概率会朝着“多模态交互”演进，你既可以用鼠标点，也可以用嘴说，模型生成之后再实时重建特征树，最终用户接触到的设计工具会比今天轻快得多。
5.4 个人开发者与初创团队的机会点
对个人开发者和AI应用团队来说，text-to-cad也有不少切入点。一是垂直领域的“窄模型”，在特定行业数据上微调出一个擅长生成某类零件的模型，比通用模型更实用，也更容易推向市场。二是“文本→CAD→设计审查”的工作流工具，把生成、检查、导出、协作整合成一个产品。三是与行业软件结合，比如做SolidWorks或Fusion 360插件，让用户在不离开CAD环境的情况下直接调用本地或云端模型服务。
这些机会的核心壁垒不在模型本身——底座模型大家都能拿到，真正的壁垒在数据和工程化能力。谁积累了更干净、更专业的行业数据，谁能把生成结果的可靠性做到99%以上，谁就能在这个赛道里站稳脚跟。
6. 踩坑之后的几点实操心得
最后聊几句我在本地把text-to-cad整套流程跑通之后最深刻的体会。
首要心得是，离数据越近的人越有优势。text-to-cad本质上还是数据驱动的序列生成问题，公开数据集只能让你跑通demo，要想做出真正可用的效果，必须花大量时间和精力清洗、增强、行业化自己的数据。我在项目后期把超过一半的精力都花在了数据上，模型结构反而调用的是很普通的LoRA微调。
第二个心得是，评估指标一定要向“能否被下游使用”靠拢。文本生成的BLEU、Rouge分数好看没有用，代码能不能执行、STEP文件能不能被下游软件打开、尺寸描述是否准确，这些才是真正决定一个text-to-cad系统有没有价值的指标。我建议任何做这块开发的人都建立一条自动评估流水线，把生成结果丢进CAD内核执行，用程序化的方式统计可执行率、特征树有效性和几何尺寸误差。
最后分享一个小技巧：如果你只是想快速体验一下text-to-cad，别一上来就训练大模型，先用现成的通用LLM配合CadQuery的少量示例做few-shot生成，效果可能会超出你的预期。等到你确认这个方向值得深入，再投入资源做数据整理和模型微调也不迟。在技术热潮面前，先用最小成本验证真实需求，永远是最稳妥的路径。
