text-to-cad技术全解析：从自然语言到可编辑三维CAD模型

上个月我在一个机械设计群里看到有人甩了一张动图：输入一句“做一个带四个安装孔的矩形底板”，软件自动生成了草图、拉伸、打孔的特征树，模型还能直接拖进SolidWorks继续改尺寸。群里第一反应是“这又是渲染视频吧”，第二反应是“把链接发我”。那会儿text-to-cad这个方向已经不算新词，但大多数人看到的“AI生成三维模型”，往往只是生成了一张好看的三维渲染图，并不是真正能落进CAD软件、能继续编辑的实体模型。这篇文章我想把text-to-cad这条线从头到尾拆开：它到底解决什么问题、有哪些实现路线、真正跑起来会遇到什么坑，以及如果你想自己复现一个最小流程，先从哪下手。适合刚接触AI辅助设计方向的学生，也适合正在评估“要不要接这个技术”的机械工程师和产品经理。

1. 先搞清楚text-to-cad要生成的到底是不是“模型图片”

很多人第一次听说text-to-cad，第一反应是“这不就是文生3D模型吗”。我以前也这么以为，直到自己把生成的网格模型导入SolidWorks，想倒个圆角都选不中面，才发现问题没这么简单。

文生图、文生视频、文生3D网格，本质上是生成离散的像素或者三角面片。而CAD用户要的不是一张漂亮的形状，是一个可编辑、可约束、可装配、可加工的参数化实体。这两者之间差着一整条工程链路。

1.1 对话对象不是像素，而是参数化特征树

CAD软件内部真正管理模型的，不是点云，也不是一堆三角形，而是特征树（Feature Tree）。一个长方体底座，在模型树里往往是“草图1”加“拉伸1”加“孔1”这样的节点组合，每个节点都带有可修改的参数，比如拉伸深度、孔直径、倒角半径。

text-to-cad如果只输出一个网格文件，用户在软件里看到的是一块“死模型”，既不能改尺寸，也无法正确参与装配约束，更没法直接出工程图。所以我在评估这类项目时，第一眼不看它渲染得像不像，而是看三件事：

• 输出能不能被CAD软件识别为原生特征；
• 特征树里的参数能不能二次修改；
• 修改参数之后模型会不会重建报错。

只要这三条满足不了，这个所谓的text-to-cad方案就只能当演示工具，进不了真实工作流。

1.2 为什么很多demo能看不能用：输出表达选错了

我见过不少demo，界面很唬人，文本进去，带着纹理、环境光的模型一下就出来了。但你下载下来是个.stl网格，用CAD打开一看，整个模型是一坨密集三角面，想对某个孔位做精确修改，根本无从下手。

问题不在生成算法，而在最终表达形式没选对。CAD世界的通用语言是边界表示（B-Rep），也就是用精确的曲面、边、顶点以及它们之间的拓扑关系来描述实体。一条直线、一个圆弧、一个圆柱面，在B-Rep里都有精确的数学定义，所以CAM能根据这些几何信息计算刀路，CAE能根据这些面划分网格。

神经网络不擅长直接输出B-Rep。目前能走通的做法，是把CAD建模过程本身序列化，让模型学“怎样一步步建模”，而不是学“最终长什么样”。这就引出了各个项目之间最根本的差别。

2. 三条技术路线对比：从脚本生成到端到端CAD操作序列

我研究过不少text-to-cad相关的工作，看来看去，主流思路其实能分成三条线。每条线的出发点不同，落地难度和适用范围也完全不同。

2.1 路线A：让大模型生成参数化脚本

这条路线最直觉。像OpenSCAD、FreeCAD的Python API、甚至SolidWorks的宏，本质上就是一种“用代码画模型”的方式。既然大语言模型擅长写代码，那让它直接写出一段CAD脚本不就完了？

实际效果半好半坏。对于零件库里的标准件、简单几何体组合，LLM生成的脚本确实能跑通。比如“生成一个直径40mm、高30mm的圆柱”这种需求，哪怕是7B的小模型也能写对。但一旦进入真实零件，脚本会迅速膨胀，几百个特征堆在一起，LLM很难保证括号匹配之外的几何正确性。

我踩过的坑是：模型生成的脚本能解释执行，但执行出来的几何完全不对，最常见的是坐标系方向反了、旋转角度差90度、或者两个特征之间少了个约束。脚本语法正确不等于几何正确，这是路线A最大的风险。

优点是解释性强，每一步都是代码，用户可以改参数重新生成；缺点是几何鲁棒性差，而且可维护性不好，复杂的特征树很难用自然语言一次性描述清楚。

2.2 路线B：先生成三维形状再转B-Rep

第二条路线借鉴了文本生成3D的思路：先用扩散模型或Transformer生成一个三维形状表达，比如体素、点云、神经隐式场，然后再想办法把它转换成CAD能用的B-Rep模型。

这条路线对自由曲面、有机形态比较友好，做玩具外形、文创产品、概念模型挺合适。但它有一个短期无解的问题：从网格/点云/隐式场到B-Rep的重建，不是纯算法能搞定的。中间涉及曲面拟合、特征识别、拓扑清理、缝隙缝合，形状稍微复杂一点，重建出来的模型就会出现破面、错位、多余边线之类的脏数据。

真实工程里，一个网格转过来能不能做布尔运算、能不能被CAM识别，往往是碰运气。所以我把这条路线定位成“概念设计辅助”，可以快速看形态，不适合直接进下游。

2.3 路线C：直接解码CAD操作序列（目前最实用）

第三条路线是目前学术和工业界最看好的，也是我复现过效果相对稳定的：把CAD的建模历史当作一种序列，用带条件的生成模型逐token预测下一个建模操作。

以Fusion 360这类支持建模历史记录的软件为例，用户从新建草图、画矩形、标尺寸、选拉伸面、设置拉伸深度，再到打孔、倒角的整个过程，都能以JSON或命令序列的形式记录下来。这些命令序列本质上就是一种紧凑的、结构化的“建模语言”。只要把自然语言描述作为条件输入，训练一个seq2seq模型去生成这种命令序列，输出就能在软件里原样回放，特征树和参数全部保留。

Text2CAD这类项目走的就是这个路线。它的关键洞察在于，直接生成B-Rep太难，但“生成草图和拉伸等操作序列”要容易得多，因为这个序列天然就是CAD特征的来源。Zoo这类产品化的尝试，同样是把最终交付物落在可编辑的原生CAD文件上。

三条路线放在一起看是这样的：

3. 跑通最小demo：我用自然语言生成一个带孔底板的全过程

我知道光讲原理不过瘾，下面把我的实际操作流程拆一遍。这个流程不是某个论文的完整复现，而是我基于开源项目和自己踩坑后整理出来的一套最小闭环，目标是让“文本描述 - 操作序列 - 可编辑实体”这条路跑通。

3.1 数据准备：把Fusion 360操作历史变成可控token序列

第一步是解决数据从哪里来。我手头没有厂商级的高质量数据集，所以用的是公开的Text2CAD类数据集的思路：从已有的CAD模型反推建模历史，再给每个模型配上自然语言描述。

具体做法是这样：

1. 在Fusion 360里打开一批已有的参数化模型；
2. 通过API把每个模型的设计历史导出成JSON，里面包含每条草图、每个约束、每次拉伸和打孔的参数；
3. 把这些JSON按操作顺序展开成token序列，类似一个“建模指令表”；
4. 为每个模型人工或半自动生成几句自然语言描述，比如“一个100mm长、80mm宽、10mm厚的底板，四角有直径8mm的孔”。

为了让模型好学好用，我没有把全部操作都塞进去，而是先限制了操作类型：草图基本几何（矩形、圆、线段）、尺寸标注、拉伸、切除、打孔、倒角。操作类型太多会导致token空间爆炸，小算力根本练不动。

这里有个很关键的小细节：坐标全部要做归一化。不同模型尺寸差异极大，有的零件几十毫米，有的几米，如果直接用绝对坐标，模型会把数值大小当成特征去记忆，结果就是同一个形状换个尺度就生成不出来。我把草图平面的局部坐标统一缩放到-1到1，同时把真实尺寸作为另一个token输入，相当于让模型分别学习“形状”和“尺寸”。

3.2 模型推理：条件生成、beam search与语法约束

数据准备好之后，训练部分其实很标准：一个是文本编码器，一个是CAD序列解码器。文本用T5或者类似模型编码成向量，CAD序列用Transformer解码。训练时使用teacher forcing，也就是一步步把真实命令序列作为输入预测下一个操作。

推理时真正拉开差距的是解码策略。我一开始用最简单的greedy decoding，结果生成的序列经常在第五六个token之后就开始胡言乱语。后来换成beam search加top-p采样，稳定性明显提升。但beam search也有问题，它倾向于生成重复的几何操作，比如连续拉伸十次而不是直接拉伸一次到位，所以还要把“操作去重”当作一个后处理规则。

下面这段是我整理出来的推理流程示例，用伪代码写清楚关键环节：

# 伪代码：条件生成CAD操作序列 from transformers import T5Tokenizer, T5ForConditionalGeneration tokenizer = T5Tokenizer.from_pretrained("t5-small") model = T5ForConditionalGeneration.from_pretrained("your_text2cad_checkpoint") prompt = "a rectangular plate with four holes" inputs = tokenizer(prompt, return_tensors="pt") outputs = model.generate( inputs.input_ids, max_length=512, num_beams=8, do_sample=False, top_p=0.95, repetition_penalty=1.2, ) cad_ops = tokenizer.decode(outputs[0], skip_special_tokens=True) print(cad_ops)

注意，这只是示例，真正的模型还要外包一层语法约束解码。简单说，在每一步预测token时，把所有不符合语法的候选全屏蔽掉。例如，当前命令是“拉伸”，下一个token必须是一个数字类型的深度值或一个“反向”标志，不能是另一个“草图”。少了这层约束，模型即使训练得再好，也会偶发输出废token。

3.3 结果验证：回放模型树与量化评估

生成的CAD序列能不能用，我从来不用眼睛说了算，而是直接把它放进软件里回放一遍。

回放成功是第一步。如果中间某一句话法不过去，整个建模过程就会中断。我复现时遇到最多的情况是：前面的草图约束不全，导致拉伸后面的特征找不到参考面。这种问题光靠模型很难完全避免，需要在后处理里加入几何检查。

回放成功之后还有三档评估：

• 几何相似度：把生成模型和参考模型分别转成体素，算IoU（交并比）。0.7以上算还不错，低于0.5基本就是形态都跑偏了。
• 特征满足度：检查用户提到的要素有没有出现。说“四个孔”，生成结果就必须是四个孔，不是三个也不是五个；说“倒角”，边缘上就必须有倒角参数。
• 可编辑性：打开特征树，试着把某个孔直径从8mm改成10mm，看模型能不能自动重建。这一步是text-to-cad和普通AI生成最大的分水岭。

我自己的体会是，第三个指标最狠。很多模型生成的序列能跑通、形状也对，但参数全都写死了，改一个数字就会连锁报错。这说明模型学到的是“背台词”，不是“理解建模逻辑”，还是不具备实用价值。

4. 真正落地时卡住我的四个问题，以及我能想到的解法

demo跑通之后，我一度很兴奋，直到尝试用它生成一些稍微接近真实工况的零件，才意识到问题远没有解决。下面这几个坑，基本决定了text-to-cad能不能从“有意思”走到“能用”。

4.1 语言歧义与建模默认值之间的矛盾

自然语言描述是高度省略的，而CAD建模命令是反人性的精确。你说“一个带孔的板”，孔直径多少？孔在什么位置？通孔还是盲孔？有没有沉头？默认方向是哪个？这些信息一句话里全都没有。

模型在训练时看到的数据描述往往是“完整描述”，比如“一个边长40mm的正方形板，中间有一个直径10mm的贯穿孔”。但真实用户不会这么说话，更不会把单位、坐标系、默认平面全部说全。于是模型只能靠猜，猜错了就产生“看似合理但实际不对”的模型。

我的解法是在产品层做交互确认：先让模型给出候选方案，同时列出它假设的关键参数，比如“孔径10mm、位于中心、贯穿方向垂直顶面”，用户确认或修改后再生成最终模型。这个设计比单纯追求一次生成准确率要靠谱得多。

4.2 几何合法性：自相交、悬边、薄壁与不可加工特征

AI生成的模型，最大的问题是“看起来没毛病，一加工就露馅”。

我试过一个简单支架，生成的拉伸体在视觉上完全正常，但导入CAM软件后刀路计算直接失败。排查原因，发现两条边之间出现了一个极小的自相交区域，肉眼根本看不出来，但对制造系统来说就是致命错误。

还有一次是生成薄壁结构，壁厚只有0.08mm，按常规刀具根本没法加工。text-to-cad系统如果不了解制造约束，就只会“按文本描述造形状”，完全意识不到这个形状有没有可制造性。

所以我后来在流程里强制加入了几何校验步骤：自相交检测、最小壁厚检查、最小圆角半径检查、以及模型是否能被正确切成流水线可处理的B-Rep。几何内核能判死的，绝不让它进入下一环。

4.3 数据集中自然语言描述太“干净”，真实需求太“脏”

text-to-cad最难搞的不是模型结构，而是数据。公开数据集里的文本描述，很多是标注人员看着模型“事后编”的，倾向于完整、客观、无歧义。比如“一个底板，四个孔，孔间距60mm，四角倒圆角”。这当然方便训练，但它和真实工程师的说话方式差距很大。

真实工程师会说“电机安装板，孔位按那个型号的电机法兰打就行”，会拿另一个零件当参照，会用功能、装配关系、工艺习惯来代称尺寸。这类“脏描述”信息密度很低，隐含语义极多，模型根本无从下手。

针对这一点，我觉得不能只靠CAD数据标注，还要引入功能语义层：先把“电机安装板”这类词汇映射到具体参数规则库，再用规则补充默认尺寸和约束逻辑。也就是说，模型只负责把相对规范的需求转成CAD序列，而把“行业知识”放在外部知识库里，两者协同，才可能贴近现实场景。

4.4 从几何到工程数据：材料、公差、BOM和PDM没人管

真正工厂里用的三维模型，不只是几何。它还需要材料牌号、公差标注、表面处理、热处理要求、标准件编码、版本号，以及贯穿整个生命周期的BOM信息。现在的text-to-cad基本都绕开了这些工程属性，只输出一个“干净的几何体”。

这带来的结果是：即便几何生成得很完美，这个模型也没法直接进PDM系统，因为没有物料编码，没有生命周期状态，没有关联的工艺卡片。下游的采购、制造、质检全都没法自动衔接。

我做产品评估时，现在会专门问一句：“生成的模型能带多少非几何属性？”如果一个项目只能输出裸几何，那它最多就是个建模加速器，离“AI替代工程师”还非常远。解决方案上，我倾向把text-to-cad定位成“几何生成前端”，后续属性由规则引擎和PLM系统补齐，而不是指望一个模型把所有事都干了。

5. 我对这条路的判断：text-to-cad更适合做“CAD副驾”而不是“CAD终结者”

聊完技术，聊聊定位。每次出现这类工具，总有人担心“设计师要失业了”。我实际用下来的感受正好相反，text-to-cad更像一个极其聪明的实习生，你不能放手让它独立干活，但它能极大减少你从0到1的重复劳动。

5.1 适合做的场景与不该碰的场景

什么场景适合用text-to-cad？我的判断是：概念建模、方案对比、标准件变体、教学演示、早期结构选型。这些场景的共同特点是：低风险、允许改、看重速度和多样性。你让AI生成十个底板变体，自己挑一个再精修，效率远高于从空白草图开始画。

什么场景绝对不该现在用？精密模具、复杂装配体、有严格公差要求的配合面、涉及安全认证的承力结构。这些场景中，一个尺寸的偏差可能造成整个制造批次报废，AI现阶段没有能力为这类高约束问题负责。

我个人的底线是：AI生成的东西，永远要经过人工审图，并且在特征树里留下可追溯的修改记录。这不仅是技术问题，也是责任问题。

5.2 从个人项目到产品化，选型建议

如果你想自己玩，我的建议是先选轻量路线：用LLM生成OpenSCAD脚本就行，一台普通笔记本都能跑，出问题也容易排查。等你理解了“脚本到几何”的坑，再往操作序列方向升级。

如果你想做产品化，直接上路线C，但不要从零训练模型。选一个能导出建模历史的CAD内核，用现成的语言模型基座微调，把重点放在三块：数据集质量、语法约束解码、几何校验闭环。这三块任何一个缺腿，产品都会死在demo阶段。

5.3 再往前一步：文本、语音、手势和现有模型的多模态输入

text-to-cad只是交互入口的一种。我自己设想中的下一代辅助设计工具，输入应该是一个混合通道：你指着一块现有零件说“把这个孔改成直径12mm，位置挪到右边”，系统能结合视觉、语音和文本理解意图，再回到特征树执行局部修改。

这个方向比“从零生成一个完整模型”要落地得快，因为它的操作域更小、约束更清晰、可验证性更强。text-to-cad积累的自然语言到操作序列能力，恰恰是这条路的地基。

最后再分享一点个人体会。我实际用了几个月之后，最深的感受是：text-to-cad真正压缩的不是建模时间，而是“从想法到第一个可修改版本”的决策时间。以前你对着空白草图画五分钟才能开始评估一个方案，现在一句话就能拿到三个候选。它不会让设计师失业，但它会淘汰那些只会在软件里点图标、不理解建模逻辑的操作型岗位。如果你想靠这个方向吃饭，我建议别只追最新模型，先把“自然语言描述 - 操作序列 - 几何校验 - 参数回改”这个闭环彻底吃透，这才是所有上层应用绕不开的核心能力。