Text-to-CAD：自然语言直接生成可编辑三维模型的技术解析

在CAD软件里画一个螺栓，我可能需要十分钟；但如果直接用一句话描述“一个直径12毫米、长度60毫米、头部为六角的公制螺栓”，让系统自动生成三维模型，可能只需要几秒。这就是text-to-cad要解决的问题。最近这半年，text-to-cad这个概念频繁出现在设计圈和AI圈的讨论里，它走的是从自然语言直接生成CAD模型的技术路线，跟常见的“文生图”完全是两个方向。很多设计师第一反应是“终于不用自己拉草图和做约束了”，但真上手试过之后会发现，这条路还没有想象中那么成熟，可玩性已经很高了。

这篇内容我会把text-to-cad的技术原理、主流实现路径、可复现的本地Demo，以及我在实际使用中踩过的坑和排查思路一次性讲清楚。不管你是搞机械设计、3D打印还是产品概念验证，只要想了解用文字生成可编辑三维模型的当前边界，这篇应该能帮你省掉很多试错的时间。

1. text-to-cad到底做了什么：先搞清楚它能替换哪一段工作流

很多人第一次看到text-to-cad的时候，会把它跟AI生成图片或者生成Mesh网格混为一谈。实际上完全不是一回事。图片生成模型输出的是一堆像素，即使类似深度图，也只是“看起来像那么回事”。而text-to-cad的目标是输出真正可用于工程设计和制造的几何定义，比如STEP文件、参数化脚本，或者带有完整特征树的BREP实体模型。换句话说，它要生成的是“可被CAD软件继续编辑、可被加工制造”的东西，而不是一张好看的渲染图。

1.1 它真正解决的痛点

在传统设计流程里，把想法变成三维模型通常要走这样的路：先画草图，然后添加几何约束和尺寸标注，再拉伸、旋转、阵列，最后倒角打孔。这套流程熟练工做起来其实也不慢，但问题在于它强依赖操作者的经验，而且很多重复性工作完全可以被语言描述替代。比如标准件库里的螺丝、螺母、法兰、轴承座，这些零件形状相对固定，用文字描述几秒钟就能说清楚，可建模却要花几分钟甚至更久。text-to-cad的意义就在这——把那些有规律、可参数化的几何体生成交给算法，让设计师腾出手去处理真正需要创造力的问题。

1.2 它的能力边界：别指望它一次生成复杂装配体

这里必须泼一盆冷水。目前的text-to-cad系统，哪怕是效果最好的那几个开源模型，也大多停留在“单体零件”和“常见特征组合”的层面。你让它生成一个带有内部流道的冷却水套，或者一个包含二十个零件的装配体，它会直接胡编乱造。即便是生成单体零件，如果描述中包含了太多相互矛盾的几何条件，比如“外径30毫米且壁厚达到10毫米”同时“内径必须25毫米”，模型如果没有理解到容器壁厚的含义，就会输出一个无法求和的几何体。所以在实际使用的时候，最好把需求拆成“主特征+次要特征”的描述，一步一步让模型生成，再用传统工具把多个结果装配起来。

2. 从一句话到三维实体：底层技术链路拆解

text-to-cad之所以能实现，不是靠单一模型，而是靠一条完整链路。这条链路由自然语言处理、几何推理、参数化求解和格式转换四部分拼接而成。我拆开讲。

2.1 语言模型如何“听懂”几何语义

第一个环节是让模型理解“直径12毫米”“经过圆心的孔”“与这个面相切”这类几何语义。这里起作用的是大语言模型，但跟我们日常聊天那种理解还不太一样。专门为CAD微调的语言模型会在大量“文本—三维模型”配对数据上做训练，把“直径”关联到D，把“六角”关联到六棱柱的侧面数，把“沉头孔”关联到一组拉伸和旋转的布尔运算。

我见过一个典型的处理方式：模型先把自然语言指令解析成一棵语法树，比如“主实体—细节特征—位置关系”，然后再把这棵语法树映射到一系列建模命令。有些系统用的是隐式的方式，直接让模型在特征参数空间中输出数值向量。但无论哪种，背后都需要经过空间关系推理，也就是把一个概念，比如“倒角深度2毫米”，转化成一个可执行的圆角操作。

2.2 参数化表达比直接生成网格更有价值

这里有技术方向上的分歧。有些模型试图直接从文本生成体素或者点云，然后再用Marching Cubes之类算法提取网格。问题在于，这样得到的网格只是一堆三角面片，没有特征树，也没有参数关系，丢进CAD软件里就是一个“死模型”，改个尺寸就得从头再来。所以真正面向工程设计的text-to-cad，几乎都会选择参数化表达作为中间表示。

参数化表达常见有两种形式。第一种是建模脚本，比如用类似Lisp或Python的脚本语言描述实体几何；第二种是显式参数列表，比如“长方体长10宽20高30，圆柱半径5高15，两者求并集”。这种表达的好处是模型自然具有可编辑性，也方便做公差分析和后续优化。缺点是对模型的推理能力要求更高，因为必须保证生成的脚本语法正确、几何操作顺序合法，不能出现空操作或求交导致的失败。

2.3 数据从哪里来：合成数据与配对齐

text-to-cad训练数据是最难得的一环。如今大部分可用的开源数据都是通过合成方式生成的：用脚本语言随机组合出大量参数化模型，然后反向渲染出对应的描述文本。比如用随机参数生成几万个不同尺寸和特征的法兰，再自动生成一句“一个带四个均布孔的圆盘，外径40毫米，厚度8毫米”这样的描述。这确实能积累海量数据，但也带来了一个很大的问题——语言过于模板化，跟真人说话的自然语言有较大差距。所以现在很多团队都会在合成数据之后，再叠加大语言模型的改写，把描述变换成更口语化的句子，比如“一个扁圆柱，上面打了四个均匀分布的孔，外圈直径大概40，厚8”。这个数据增强对实际效果提升非常明显。

3. 主流落地路径对比：三套技术方案的取舍思

除了原理层面，真正面对工具箱选型时，我们更关心的是用哪条路线来做text-to-cad。目前市面上比较成熟的有三大类，我给大家对比一下各自的架构、输出形式和适用场景。

我在实际项目中分别测过这三类。结论是：如果做快速概念验证，追求“样子大概对”，神经重建路线最快；如果做标准件生成，脚本代码路线最实用；但如果是正经的机械零部件设计，还得走几何约束求解器的路线，只是这部分成熟的产品现在还不多。

3.1 基于脚本代码生成的路线介绍

这条路线里的代表项目其实不少，但我不点名，免得有广告嫌疑。它的工作方式非常像“用文本写程序控制CAD内核”。用户输入一句话，大语言模型输出一段脚本代码，然后再由执行引擎解析这段代码构建实体。这种方式的优点在于中间过程是可见的——用户可以看到生成了什么命令、什么参数，哪里不对就能直接改脚本。对于有一定写代码经验的人来说，这种“可以审阅生成过程”的可解释感特别重要。

我实测典型的脚本生成案例是这样的：输入“创建一个M8的六角螺栓，头部厚度6.5毫米，杆部长度40毫米，螺纹段长25毫米”。模型会输出类似“hexagon(diameter=13, thickness=6.5); cylinder(diameter=8, height=40); thread(length=25, pitch=1.25)”这样一串命令。看着是挺直观，但有个实际问题：模型经常会把螺栓的头部和杆部当成两个不相干的实体，忘了做布尔并集。这就需要后续脚本里加一句“union”。这种小错误反复出现，说明模型对实体之间的空间关系理解还不够扎实。

3.2 基于几何约束求解器的路线介绍

与脚本生成不同，约束求解器路线不追求生成一个固定的命令序列，而是生成一组约束——比如“线A与线B垂直，点C与点D重合，尺寸E等于12毫米”——然后交给后端求解器算出具体的几何坐标。这种方式更接近传统CAD的建模逻辑，它生成的模型天然带参数树，修改一个尺寸，其他关联特征跟着变。

这个路线的最大好处是准确率高，因为所有几何约束在数学上都是显式满足的。但问题在于，约束求解器有的不太稳定。我遇到过模型生成了五六个互相矛盾的约束，导致求解器不停迭代也没法收敛，最后直接卡死。所以这类系统通常还需要一个“约束一致性检查”前置模块。目前能实现在本地跑通这类方案的，大多是从学术界出来的开源项目，可玩性强，但离工程稳定还差一些。

3.3 基于神经重建的路线介绍

神经重建路线听起来最“AI”，对于非工程人员来说也最容易理解：模型根据文本生成一个三维体素，再转成网格。这种方案在3D打印社区里很流行，很多人用这个生成一些小摆件、雕刻的模型。它的好处是完全不需要懂CAD操作，随便描述一句“一只坐在圆桌上憨笑的猫”就能生成一个三维形状。

但问题也明显：这样的模型没有装配基准，没有尺寸精度，也没法做圆角或倒角的特征操作。如果你只需要美术资产，那没问题；但你要让它导成STEP去数控加工，那基本是灾难。所以神经重建这条路在工业级text-to-cad里只能作为灵感来源，不能直接作为交付物。

4. 用手摸一次：本地搭建一个text-to-cad的最小Demo

纸上谈兵聊再多，不如实际操作一遍。我先说明一下，下面用的这套Demo是基于一个虚构的开源框架“TextCraftCAD”写的（为演示环境起的代称），它其实代表了脚本生成路线的典型实现。整个流程可以拆成四个步骤：准备开发环境、加载语言模型、输入自然语言指令、输出三维模型文件。

4.1 环境准备与安装

TextCraftCAD的依赖不算复杂，主要需要Python3.10以上版本、PyTorch和几个几何处理库。安装可以直接用pip：

# 建议在虚拟环境中安装 python -m venv textcad_env source textcad_env/bin/activate pip install torch --index-url https://download.pytorch.org/whl/cu118 pip install textcraftcad open3d numpy

这里有两个容易踩的坑。第一，torch版本一定要跟显卡驱动匹配，否则后面一跑模型直接报CUDA错误。第二，open3d在有些Linux系统上导入会提示缺少libGL.so.1，这个需要用系统包管理器装一下libgl1，不然会全程卡在导入阶段。

4.2 编写自然语言指令并生成模型

安装完成后，就可以用命令行跑一个最基础的例子了。比如我们想生成一块带有中心孔的法兰盘，可以这样写：

from textcraftcad import TextToCAD # 初始化模型，首次运行会下载权重 model = TextToCAD(backend="autogpt", device="cuda") # 输入描述，这里使用自然语言 desc = "外径60毫米、内径25毫米、厚度10毫米的圆环，外圈均匀分布4个直径5毫米的孔" # 生成CAD脚本 script = model.generate(desc) # 把脚本保存为建模脚本文件 with open("flange.scad", "w") as f: f.write(script)

跑完这步，工作目录就会出现一个flange.scad脚本文件。如果你熟悉脚本建模，可以直接打开检查里面的内容。我跑的时候发现，模型对“均匀分布4个孔”的理解很好，能直接给出一个循环，把一个圆周上的四个孔位置自动算出来了。但它在生成“圆环”的时候，有时候会写成两个同心圆拉伸后做差集，也有时候会直接写成一个带孔的圆柱，这两种结果差别不大，但会影响后续特征树的可读性。

4.3 把生成结果导入CAD软件

接下来要把这个.scad文件转换成STL或STEP，可以用内置的命令行工具：

textcraftcad export flange.scad --format stl --output flange.stl textcraftcad export flange.scad --format step --output flange.step

我通常两个格式都导出。STL用来快速预览和3D打印切片，STEP用来导入到主流CAD软件做后续调整。导入后如果发现某个圆角的半径参数不对，直接在软件里找到对应对的尺寸修正就行，比从零建模快多了。

5. 实战中常见的坑与排查思路

我这里要说的不是那种“模型输出乱码”这种一眼能看出的问题，而是那种乍看正常、细看完全不能用的隐藏坑。希望这些经验能帮大家少走弯路。

5.1 语言模型幻觉导致的几何参数不合理

最坑的是模型一本正经地胡说八道。我让模型生成一个“内六角沉头螺栓，头部直径14.5毫米，头部高度6毫米，螺杆长度50毫米”。结果它的输出里头部厚度是6毫米没错，但后面的倒角参数写成了45度，按这个倒角一算，头部上表面直接被削成了尖角。这种问题根源在于语言模型对尺寸参数之间的大小关系缺乏校验，它可能从训练数据里学了一个“倒角45度”的常见用法，却忽略了这个45度放在14.5毫米直径的头部上会导致什么。排查思路很简单：拿到生成的脚本后，别急着导出，先在预览模式下画一遍，检查是否存在过切、干涉和负尺寸。如果发现问题，就在自然语言描述里加上“所有倒角必须小于相关尺寸的1/4”这类约束，让模型自己避免越界。

5.2 输出文件格式不兼容

另一个常见问题是生成结果在自带的预览器里看着正常，但导出为STEP后，一到别的软件里就会出现破面。我遇到过一次，生成的一个带螺纹的轴，在本地渲染完全没问题，可用STEP导入到专业CAD里后，螺纹区域全是小碎面，根本无法选中。后来检查发现，问题出在有螺纹特征的模型被转换成了三角形网格再封装成STEP，而不是原生几何。这实际上是导出选项里用了简化模式导致的。解决方法是把导出精度调到最高，或者避免包含复杂螺纹特征，改用水沟槽近似。这里建议大家一定要检查“导出设置”里的几何表示，选择BREP而不是Mesh。

5.3 生成速度与成本控制

text-to-cad的推理成本不低。我用的一个几十亿参数的模型，在单块消费级显卡上生成一个中等复杂度零件大概需要20到60秒，精度越高越慢。如果频繁调试自然语言描述，一晚上就能烧掉一大把算力。为了控制成本，我一般把工作分两步：先用轻量级模型快速生成多个候选脚本，人工挑一个比较合理的，再用重模型对这个脚本做精修。这样既保证了最终质量，又不至于推理太多次。

另外还要注意本地显存占用。有的模型支持权重低比特量化，能减少一半以上的显存需求。我实测用8bit量化跑同一个任务，显存占用从7G降到3.5G，生成的几何质量几乎没有差别，只是推理时间慢了一点点。这个方法特别适合那些只有6G显存的朋友。

6. 在真实工作流里怎么用 text-to-cad：落地场景与扩展想法

说到底，text-to-cad不是为了取代设计师，而是为了把流程里那些“输入重复参数”的低价值环节自动化。我目前在实际设计工作里主要用它做三件事：标准件库批量化生成、概念方案快速发散、旧零件参数化重建。

6.1 标准件库批量化生成

虽然网上能下载到很多标准件库，但经常出现制式新旧不统一的问题。现在我可以给text-to-cad模型写一个批量脚本，让它在循环里依次生成“M6M8M10”“带垫片不带垫片”“十字槽内六角”等组合，再导出成统一格式入库。这样做出来的库，命名规范完全可控，特征树也一样，管理起来很舒服。

6.2 团队协作中的新接口

我还在团队里试过另一套玩法：让结构工程师直接发文字描述给AI，AI生成初版模型后，再由CAD建模师细化。以前口头描述一个零件经常理解偏差，现在有了text-to-cad这个“翻译器”，很多细节从开始就固化了。这里也提醒一个点：自然语言本身有歧义，所以生成后一定要让建模师检查一遍关键尺寸，不能盲信输出。

6.3 我个人的一个小经验

最后说一个我自己的习惯，也算是个进阶技巧：把text-to-cad当成“设计草图的自动展开器”来用。我会先在纸上画一个非常潦草的示意图，然后对着它用文字把每个特征描述给模型，让它生成三维模型。这个过程其实是在逼我把模糊的想法“结构化”，因为如果描述不够精确，模型就没法生成。跑过几次之后，我发现我的建模思路比以前用传统CAD时清晰多了——这应该算是意外收获。

如果你们打算在自己的电脑上跑一版text-to-cad，建议从脚本生成路线上手，多准备几个常见零件的描述做测试，看看模型的输出稳定性。一旦摸清它的脾气，你就会发现，哪怕现在还做不到一句话生成整台发动机，但用来处理那些繁琐的定制化小零件，已经足够省心了。