1. text-to-cad到底是什么：别把它和AI生图混为一谈

最近圈子里有个话题特别热，就是text-to-cad。从字面上看，似乎是“输入一句话，直接生成CAD模型”，听起来跟AI生图、AI生成视频差不多，但实际上完全不是一回事。很多人以为它就是“三维版的Midjourney”，用户输入“一个带螺纹孔的法兰盘”，模型刷刷刷给你一个好看的渲染图——这个理解偏差非常大，也是很多人在接触这个领域后第一波踩坑的地方。

text-to-cad解决的核心问题，是从自然语言描述直接得到可用于工程设计的CAD模型，注意这个词：工程设计。这意味着生成的结果不是一张效果图，也不是一个不能编辑的三角网格，而是带有特征树、草图、约束关系的参数化实体模型。它要能够被放进SolidWorks、Fusion 360、FreeCAD这类工具里继续编辑，要能改尺寸、改孔位、改厚度，甚至重新生成工程图。这跟生成一张“看起来像那么回事”的图片，难度不在一个量级上。

这个方向适合谁来关注？如果你做机械设计、非标自动化、消费电子结构设计，经常需要从需求描述快速搭建初始模型，那text-to-cad就是奔着你的痛点来的。如果你是做AI算法、计算机图形学的工程师，这个领域同样值得跟进，因为它在数据集构建、模型架构、几何约束处理上有大量开放问题。即使你只是CAD二次开发的从业者，了解这条技术路线，也能帮你判断后续工具链会怎么演化，值不值得投入精力去研究。

我接触这个方向大概一年多，从早期的论文复现到后来跑通完整流程，中间踩了不少坑。今天这篇不打算讲太多晦涩的公式，而是想把这个领域的核心难点、技术路线、实际可复现的流程，以及我亲手踩过的问题，系统地捋一遍。看完之后你至少能回答三个问题：text-to-cad凭什么难？现在有哪些路子在走？如果我想自己跑一个最小可用的方案，该怎么办？

2. 解剖难点：为什么“文本生成CAD”这么难搞

2.1 CAD模型不是像素，是有拓扑的实体

要理解text-to-cad的难度，首先得理解CAD模型跟AI圈常见的图片、点云、网格在本质上的区别。

一张图片本质上是像素矩阵，一段语音本质上是采样点序列，这些东西的底层数据结构是规整的、稠密的，神经网络处理起来非常顺手。但一个CAD模型，底层是B-Rep（边界表示），由面、边、顶点以及它们之间的拓扑关系构成。一个面不是一堆离散点的集合，而是一个精确的数学曲面，比如NURBS曲面；一条边是两条面相交的曲线，有明确的几何方程。更要命的是，CAD模型还带参数化历史，也就是特征树，记录了“先拉伸一个矩形，再在端面上打三个孔，最后倒角”这样的完整操作序列。

这就带来一个本质性的困难：语言模型擅长处理序列，图像模型擅长处理网格，但CAD模型既不是纯粹的序列，也不是纯粹的网格，而是一种混合了拓扑结构、几何精度和操作历史的数据。你说“一个直径50的圆柱”，在CAD里它不只是一个圆柱体，它可能是一个拉伸特征加上一个旋转特征，也可能是两个半圆柱通过布尔运算得到的，还伴随着基准面、草图、约束等一堆附属信息。

换句话说，AI模型需要学会的不是“画出某样东西”，而是“复现人类设计师的操作意图和操作顺序”。这远比生成一张仿真图片要难得多。

2.2 语义理解和几何精度之间的鸿沟

第二个难点是语义和几何之间那条巨大的鸿沟。自然语言描述是模糊的、抽象的，比如“一个带安装孔的小型支架”，这句话在人类设计师脑子里会映射出一大堆隐含决策：支架是多大的？壁厚多少？安装孔直径多少？孔距多少？是否有加强筋？但在文本里，这些信息全都没有。

模型必须从模糊描述中推断出合理的设计参数，同时还要保证这些参数在几何上是自洽的——孔径不能比支架本身还大，孔间距不能超出面板范围，拉伸特征不能产生自相交几何。这涉及大量工程常识，而这些常识很难完全编码到训练数据里。

更麻烦的是CAD建模对精度的要求极高。AI生图时，像素差几个色阶没人看得出来；生成文本时，个别词语不对也能猜出大意。但CAD模型一旦尺寸偏差超过0.1毫米，放到装配体里就可能完全装不上，出工程图的时候公差标注全部作废。现在的AI模型输出天然带有概率性，要让它们稳定输出精确到小数点后好几位的几何参数，同时保证拓扑正确，这本身就是反AI模型特性的一个挑战。

2.3 训练数据从哪来：DeepCAD等数据集的贡献与局限

数据是另一个大坑。text-to-cad需要成对的“文本描述-模型文件”数据来训练，但CAD模型跟图片不一样，互联网上并没有海量现成的、带文本标注的模型文件可以爬取。

这个领域的早期突破很大程度上得益于DeepCAD数据集——从公开的CAD模型库中提取了约17万个由Onshape创建的实体模型，并将它们的特征历史解析成序列化的建模操作。这相当于把CAD模型“翻译”成了类似程序代码的序列，让Transformer模型有了可学习的目标格式。后来又有更多数据集加入，比如Text2CAD数据集，它给模型增加了文本描述。再就是Fusion 360 Gallery这类包含完整重建序列的数据集。

但现有数据集的问题也很明显：第一，类别极度偏向机械零件，像法兰、齿轮、轴套、支架这类工业标准件占了绝大多数，真正面向消费产品、建筑构件、自由曲面的数据少得可怜；第二，模型复杂度普遍偏低，绝大多数是拉伸、旋转、打孔这类二轴半特征，涉及扫掠、放样、曲面混合的很少；第三，文本描述质量参差不齐，很多描述其实就是“一个矩形板上有四个孔”这种极其直白的句子，跟真实工程师的口吻差别很大。

这些局限意味着，当前text-to-cad模型在“机械标准件”这个相对窄的领域表现尚可，一旦输入超出训练分布的描述，比如“一个仿生学造型的无人机机臂”，生成的模型就很容易翻车。

3. 主流技术路线与工具选型：现在大家都在怎么搞

3.1 程序合成路线：让大模型直接写建模代码

目前在工程上最成熟、最容易落地的一条路线，是程序合成——让大语言模型直接生成建模代码，然后用代码驱动CAD内核生成模型。典型实现方式包括让模型写OpenSCAD代码、CadQuery代码，或者Python脚本配合FreeCAD的API。

这条路线之所以最先落地，本质上是把text-to-cad转换成了“文本到代码”任务。大模型写代码的能力已经被验证得很充分了，OpenSCAD、CadQuery这类库的语法相对简单，训练数据也相对容易获取——GitHub上有大量现成的OpenSCAD脚本和CadQuery脚本可以用来自动生成文本-代码-模型三元组。

我实测下来的感受是，这条路线的下限很高。哪怕模型生成的代码有bug，多数情况下也是语法错误或者参数不对，修一修就能出模型。而且最终产物天然是参数化的，用户拿到代码就可以直接改参数，不需要额外的反向建模过程。

缺点也很明显：模型受限于代码表达能力的上限。OpenSCAD这类基于CSG（构造实体几何）的建模方式，擅长表达布尔运算、基本体组合、规则阵列，但让它表达复杂的曲面造型或倒圆角过渡就非常吃力。CadQuery虽然基于B-Rep内核，表达能力更强，但代码更复杂，大模型生成时的出错率也更高。

3.2 扩散模型路线：直接在特征序列上做生成

另一条学术氛围更浓的路线是扩散模型，代表工作包括从文本或点云条件生成CAD序列的各种模型，比较典型的思路是在“草图+拉伸”特征序列上做去噪扩散。简单说，就是把一个CAD模型的特征操作序列当作类似“语音帧”的序列数据，前向过程逐步加噪，反向过程从纯噪声中一步步还原出建模操作。

这条路线的好处是，模型学到的不是“某个具体代码怎么写”，而是CAD建模本身的分布规律——哪些特征组合是常见的、哪些尺寸搭配是合理的。理论上，它比程序合成更能捕捉到设计中的隐式规律。生成的结果松耦合于具体的建模API，不会因为CadQuery或OpenSCAD的语法变化而过时。

但这条路线目前的工程成熟度比较低。首先生成结果的精度不稳定，经常出现特征与特征之间轻微穿插、间隙过大这类问题；其次，生成的特征序列往往缺乏良好的参数化表达，用户拿到的是一串已经“定死”的特征历史，想改某个关键尺寸往往牵一发动全身；最后，训练这类模型需要大规模、高质量的特征序列数据，目前公开数据集的规模仍然不够。

3.3 混合方案与商业产品：大模型内核加约束求解器

真正对用户友好的方案，往往是上述两类的混合体。商业产品如Zoo的Text2CAD、Autodesk在推进的AI辅助建模功能，大多走的不是“一步到位生成完整模型”的路线，而是把AI放在辅助位置上：用户输入描述，AI先生成一个初始模型，同时在后台运行约束求解器和几何合法性检查，不满足要求的自动修复或提示用户干预。

这类混合架构的核心设计思路是：大模型负责发散——提出建模方案、生成初始特征序列；几何内核负责收敛——校验B-Rep拓扑合法性、检查焊缝/间隙/重叠、重算约束一致性。大模型的“幻觉”问题在这里被几何求解器兜底，工程上更可靠。

值得注意的是，现在的开源社区也有不少值得关注的项目。例如较新的开源模型能够生成带特征历史的CAD模型序列，用户可以在建模软件里直接修改参数。还有不少团队在尝试利用现有大模型（如通过特定指令微调或少量示例的方式）驱动CAD工具链，效果已经接近可用的边缘。

3.4 路线对比：怎么选

我个人的判断是，短期（一两年内）工程落地主要靠程序合成路线，因为它是“站在大模型肩膀上”的稳妥方案；中期看混合方案会成为主流，因为几何可靠性是CAD不可妥协的底线；扩散模型路线还需要更长时间的数据积累和方法论沉淀。

4. 实操：搭一个能跑的最小可行Pipeline

4.1 环境准备与方案选择

说了这么多理论，接下来进入正题——自己动手跑通一个text-to-cad的最小可行流程。我推荐的方式是这样：先用OpenSCAD做后端，让大模型生成代码，再把代码渲染成STL网格，最后根据需求决定是否做参数化后处理。

选择OpenSCAD而不是CadQuery或者直接驱动FreeCAD做第一步，原因有三：第一，OpenSCAD语法极度简洁，一个圆柱就是cylinder(d=20, h=30)，一个大模型几乎不可能写错；第二，OpenSCAD支持命令行无头渲染，方便自动化批量处理；第三，它的CSG表达能力覆盖了大量机械零件场景，作为第一个demo完全够用。

需要准备的环境非常轻量：

• Python 3.10以上，用于写调度脚本和调用大模型API
• OpenSCAD命令行工具（可以无头运行）
• 一个大模型API或者本地模型接口，国内用户可以用各类国产大模型API，支持自然语言到代码的能力都已经过关
• 如果要后期做CAD后处理，可以再加一个FreeCAD命令行环境

4.2 第一步：让大模型输出结构化建模代码

打通流程的关键技巧，不是直接跟大模型说“帮我生成一个法兰盘”，而是给出结构化的提示词模板，明确要求输出OpenSCAD代码、关键参数的数值，以及必要的注释。我实践中比较稳定的提示词框架是这样一个四段式：

• 角色设定：告诉模型你是资深机械设计工程师
• 需求描述：把用户要的零件描述放进来
• 约束条件：明确单位、精度偏好、是否允许近似、代码规范
• 输出格式：强制要求给出代码块和参数说明

实测下来，同样的需求，用结构化提示词生成的代码可编译率能从五到六成提升到八九成。这里一个值得强调的细节是，最好明确要求模型把关键尺寸集中在文件顶部的变量定义里，而不是散落在各条指令中。这样一来，后续调参、参数化批量生成都会方便很多。

下面是实际测试过的一个例子，输入是“一块120乘80、厚10的安装板，四角有直径8的沉头通孔，中心有一个直径30的凸台，凸台高度15”：

// 安装板主体 plate_length = 120; plate_width = 80; plate_thickness = 10; // 四角沉头孔 hole_diameter = 8; hole_counterbore_diameter = 13; hole_counterbore_depth = 5; corner_radius = 5; // 中心凸台 boss_diameter = 30; boss_height = 15; // 模型主体 difference() { union() { // 底板 translate([0, 0, 0]) cube([plate_length, plate_width, plate_thickness], center=true); // 中心凸台 translate([0, 0, plate_thickness/2]) cylinder(d=boss_diameter, h=boss_height); } // 四角沉头孔 for (x = [-1, 1], y = [-1, 1]) { translate([x*(plate_length/2 - corner_radius - 5), y*(plate_width/2 - corner_radius - 5), 0]) union() { // 沉头 translate([0, 0, plate_thickness/2 - hole_counterbore_depth]) cylinder(d=hole_counterbore_diameter, h=hole_counterbore_depth+1); // 通孔 translate([0, 0, -plate_thickness/2 - 1]) cylinder(d=hole_diameter, h=plate_thickness + 2); } } }

这段代码从建模逻辑上看是完整的：底板用立方体，凸台用圆柱，沉头孔用“大直径短圆柱+小直径长圆柱”的组合通过差集实现。编译后在OpenSCAD里Preview，能看到一个带凸台的安装板，四个沉头孔位置正确，尺寸也符合输入描述。

4.3 第二步：无头渲染和几何自检

代码生成之后，下一步是用OpenSCAD命令行做无头渲染，把模型输出成STL文件，同时做基础的几何检查。渲染命令很简单：

openscad -o output.stl -D '$fn=64' input.scad

这里的$fn是曲面细分精度参数。如果设得太小，圆柱面会呈多边棱柱状，影响表面质量；设得太大，STL文件体积会膨胀很多，内存消耗也跟着上去。对于快速原型验证，64是一个比较合适的值；如果是要做3D打印或者最终出图，建议用到128以上。

渲染完成后，需要做一个非常关键的自检：检查STL网格是否水密（即封闭实体）。CAD模型的网格必须封闭，后续才能做切片打印或者导入其他CAD软件做二次编辑。判断水密性最直接的方法是检查模型体积是否能够被正确计算。我自己习惯用Python的trimesh库做这个检查：

import trimesh mesh = trimesh.load('output.stl') print(f"顶点数: {len(mesh.vertices)}") print(f"面数: {len(mesh.faces)}") print(f"是否水密: {mesh.is_watertight}") print(f"体积: {mesh.volume} mm^3") print(f"包围盒: {mesh.bounds}")

如果这一步输出“是否水密: True”，说明模型几何至少是闭合的。如果False，说明模型中存在破面、裂缝或者自相交，必须回到代码层面排查。多数情况下，破面问题出在布尔运算的交界处，比如两个圆柱做差集的时候，如果尺寸刚好处于共面边界，就容易产生退化边。

4.4 第三步：从网格到可编辑参数化模型

这一步是可选的，但也是很多人的真实需求点。STL网格本质上是“死模型”——你说“这个孔是直径8的”，网格里并没有这个语义信息，你只有一个三角形的洞。想让结果真正进入参数化设计流程，必须做一步把网格转换为可编辑特征模型的处理。

目前可用的方案有两种。第一种是重建模路线，思路是让模型不仅生成代码，还输出一份结构化的参数表，然后在FreeCAD或者CadQuery里根据参数表重新构建一遍特征。以我前面的例子来说，模型输出的参数表里有板长120、板宽80、孔径8、凸台高度15等，基于这些参数在CadQuery里重新建模是非常容易的事，而且最终得到的是完全参数化的模型，想改哪个尺寸改哪个尺寸。

第二种方案是自动逆向重建，比如用FreeCAD的逆向工程工作台或第三方工具对STL做面识别、拟合，尝试自动识别平面、圆柱面，再重建B-Rep。这条路自动化程度高，但对网格质量要求非常苛刻，圆柱面的棱柱化误差经常导致拟合结果偏差过大。

我个人推荐走第一条路——让代码生成的流程本身就保留参数语义。这也是我推崇程序合成路线的核心原因：它天然保留了模型的可编辑性，不会像扩散模型那样生成一个“黑盒特征序列”然后束手无策。

4.5 批量生成与参数化变体

一旦流程跑通，你会发现text-to-cad真正的威力不在于“生成单个零件”，而在于“从同一描述批量生成一组设计方案”。比如你给大模型一句“一个60×40×5的塑料外壳底座，四角有M3螺纹柱”，同时要求它给出三个变体：一个壁厚加厚版本、一个侧面开卡扣槽版本、一个底部带定位销版本。

实现这个操作很简单——在提示词里增加变体描述，或者维护一个参数列表让模型逐次套用。我做的调度脚本大概长这样：

variants = [ {"name": "thickened", "wall_factor": 1.5}, {"name": "with_slot", "slot_depth": 2}, {"name": "with_pins", "pin_diameter": 3}, ] for v in variants: prompt = build_prompt(base_desc, v) code = llm_generate(prompt) save_scad(f"{v['name']}.scad", code) render_stl(f"{v['name']}.scad", f"{v['name']}.stl") check_geometry(f"{v['name']}.stl")

这一步在传统CAD流程里往往需要设计师手动花半天到一天，而自动化之后可能只需要几分钟。当然，前提是模型生成代码的质量足够稳定，这也引出了下一节要聊的问题——我踩过的那些坑。

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

5.1 几何不封闭、破面频发

这是遇到频率最高的问题。模型代码能编译通过，渲染也正常，但网格就是水密性检查不通过。根据我的经验，最常见的原因有三个：一是特征之间刚好共面，差集运算时产生了零厚度的退化区域，OpenSCAD内部求交计算出问题；二是圆柱细分精度不一致，两个相交的圆弧曲面在不同尺寸下生成不同数量的顶点，导致交接处出现裂缝；三是有微小到难以察觉的几何间隙，例如板厚10，孔深却只有9.8，从外表看不出来，但底部实际上没有贯穿。

排查思路是从大到小做二分。先把模型里的特征逐个注释掉，每注释一个就重新渲染检查水密性，定位到是哪个特征造成的破面。然后针对问题特征检查参数是否自洽——孔径是否接近板宽、拉伸高度是否真的超过主体厚度、布尔运算体之间是否有重叠。

另外一个经验是：遇到共面问题，给尺寸增加一个极小偏置，比如0.01毫米。这个方法看似粗暴，但在CSG建模里极其有效，一句话就能解决大量布尔运算退化问题。

5.2 约束过约束或欠约束

如果你做的是CadQuery路线，生成的特征约束经常会出问题。所谓过约束，是给草图添加了互相矛盾的尺寸标注，比如同时固定了“圆心到边20毫米”和“圆弧半径30”，而圆心位置又和另一个几何约束绑定，求解器直接报错。欠约束则是定义了位置但没定尺寸，模型理论上可以无限变形，在CAD里表现为拖动草图时图形乱跳。

大模型生成的约束代码，过约束出现的概率相当高。原因是模型在生成代码时会习惯性地“尽量多加点约束”，以免被批评漏约束。但CAD约束求解器最怕的就是矛盾约束，越多越容易冲突。

我的排查方法是把生成的约束逐一注释掉，从依赖关系最底层的几何约束开始，逐个解开看是哪个约束与其它约束冲突。实际操作中，清除“等长”或“平行”这类冗余约束的有效率最高，因为它们往往和尺寸约束重复表达同一个意图。

5.3 生成的模型“能看不能用”

另一个非常打击信心的问题是：模型看起来完全符合描述，渲染图很漂亮，但实际使用中却完全不能用。典型例子是3D打印的时候发现内孔实际偏小，或者装配的时候发现两个零件配合公差完全不对。根子在于大模型“视觉化”生成参数，而不是“工程化”生成参数——它倾向于给出那种看起来顺眼、比例协调的数字，却忽略了制造工艺要求，比如孔径标准系列、公差带选择、最小壁厚要求。

对策是在提示词阶段就把工艺约束写进去。常见做法是在提示词里加入“孔直径遵循优先数系”“最小壁厚不小于1.5毫米”“所有锐边倒角0.2”这类硬性规则。大模型对这些规则遵循得越好，后处理阶段返工就越少。

5.4 语义幻觉导致的设计错误

最隐蔽也最危险的问题是“语义幻觉”——模型理解了你说的词，但误解了你的意图。比如你说“带法兰的管接头”，模型可能给你生成一个圆柱管加上一个大圆盘，看起来确实有“法兰”有“管”，但法兰盘上没有螺栓孔，与标准法兰规格也毫无关联，实际根本无法跟标准管路连接。

这类错误在视觉上非常有欺骗性，非专业人士往往会觉得“模型没问题啊”。但从事过实际机械设计的人一眼就能看出，这是典型的“外行建模”——形状对了，功能细节全面缺失。

应对这个问题的办法是引入领域知识库。我给提示词框架里加了一个“标准参考”字段，对于有可能涉及标准件的情况，要求模型先枚举适用的标准号和关键参数，再开始建模。例如要求模型“参考GB/T 9112对法兰的尺寸定义”或者“参考M3螺钉的过孔直径规范”，生成质量会有显著提升。

5.5 典型问题速查表

5.6 我的几条避坑心得

最后分享几条属于“不撞南墙不会知道”的经验。

第一，永远不要相信大模型第一次生成的结果。不管代码多完整、渲染多好看，全部默认有隐藏缺陷，必须做水密性、尺寸、装配干涉三层检查。把检查做成自动化脚本，别靠肉眼。

第二，提示词里的一切都值得固化。一个好的提示词模板是长期调试出来的，我最终沉淀了一个近十屏长的模板，把角色、步骤、格式、标准、语法规范全部固化，生成稳定性比早期随手写的模板高出太多。

第三，不要让模型“自由发挥”太多自由度。对于复杂零件，把建模任务拆成多步，先让模型生成主体，再逐步添加细部特征，每一步都检查，比让它一步到位靠谱得多。这也符合人类设计的习惯——我也没见过哪个工程师是第一步就直接出完整模型的。

6. 写在最后的一点个人体会

text-to-cad这个方向我跟踪了一年多，从最初“看起来很酷但完全不知道能干什么”，到后来逐步用它在实际项目里做前期方案探索，感受最深的一点是：这类AI工具的价值不在于替代设计师，而在于把设计师从大量重复性的、低创造力的“翻译工作”里解放出来——把需求描述翻译成初始模型、把基型修改成不同尺寸的变体，这些活AI干得又快又稳。

我自己现在的使用习惯是，接到一个新的项目需求时，先用text-to-cad工具快速生成十来个方案变体，挑出两三个方向合理的，再导入CAD软件里精修。以前做这一步要花几天，现在一上午就能过完一轮。当然，精修阶段还是要靠人来完成，AI生成的模型在复杂细节、工艺合理性上还需要大量打磨，这是目前所有text-to-cad方案共同的短板。

如果你也想尝试这个方向，我的建议是不要一开始就追求训练自己的模型或者复现前沿论文，那样投入产出比太低。先把我上面这个OpenSCAD加LLM的最小流程跑通，亲手体验一遍“从一句话到可编辑模型”，建立直觉之后再决定往哪个方向深入。这条路技术上并不神秘，剩下的就是不断地迭代和积累。