企业官网建设流程全解析

先把话说清楚：这两年text-to-cad这个词频繁出现在各种技术社区的讨论里，不少朋友一上来就问我“能不能推荐一个工具，输入一句话直接生成可编辑的CAD模型”。说实话，目前还没有那种科幻电影里“说一句就给完整工程图”的成品软件，但围绕这个方向的一系列模型、开源项目和实验性工作，已经能把“文字描述”转化成看得见、摸得着的三维几何了，甚至一部分能直接导出STEP、IGES这类CAD标准格式。这篇文章想做的，就是把text-to-cad这个方向背后的技术逻辑、常见实现路径、工程落地时要注意的坑，以及我自己实测下来的一些经验，完整梳理一遍。不管你是搞机械设计的工程师，还是做AI应用开发的程序员，又或者只是对3D生成感兴趣的产品经理，这篇内容应该都能给你省下不少自己摸索的时间。

1. 先搞清楚难在哪：传统CAD建模与text-to-cad的天然沟壑

1.1 为什么CAD建模这么“反人类”

如果你用过SolidWorks、Fusion 360或者FreeCAD，应该能理解我的意思：传统的参数化CAD建模，本质上是一个“精确操作”的过程。你要画草图、标注尺寸、添加约束、拉伸切除、倒角圆角，每一步都必须给出明确的数值和几何关系。软件不会猜测你脑子里想的那个“带四个圆角的金属支架”到底圆角是R2还是R5，更不会主动帮你决定壁厚是3毫米还是5毫米。这种精确性保证了工程模型的可制造性和可装配性，但代价就是学习曲线陡峭，操作效率低，入门门槛高。

而自然语言描述恰恰是模糊的、定性的。你说“一个带安装孔的L形托架”，不同工程师脑子里出现的模型可能完全不同——孔径多大多小？L形两臂的比例是多少？倒角要不要？孔在什么位置？这些信息全都没说清楚。所以text-to-cad的第一个难题，跟图像生成不一样：它不只是“生成一个看起来像的东西”，而是要生成“一个符合工程语义、可以继续编辑、理论上能拿去加工的几何体”。这两个目标之间存在巨大的鸿沟。

1.2 大模型时代为什么突然给了这个方向新机会

大概在2023年前后，text-to-cad方向的进展突然加速，原因很直接：大规模语言模型和跨模态模型（尤其是CLIP这类文本-图像对齐模型）成熟了，3D生成领域又积累了一批可用的数据集和生成框架。以前做文本到3D，常见的做法是检索——在模型库里找找有没有现成的、描述接近的模型，找到就返回，找不到就拉倒。现在不一样了，扩散模型、隐式神经场这些生成式方法，让“从零生成一个全新几何体”变成了可能，AI不再只是做匹配，而是真的在“创作”几何。

不过要特别留意，很多顶着text-to-cad名头的开源项目，实际生成的是mesh或者点云，并不是传统意义上CAD系统里的B-Rep（边界表示）模型。mesh和B-Rep的区别，简单说就是：mesh是一堆三角形面片的组合，适合渲染和3D打印，但丢给SolidWorks做参数化编辑基本不可能；B-Rep才是CAD系统的核心数据格式，包含精确的曲面方程和拓扑关系，可以被特征树记录、被参数驱动修改。理解了这两个层次，你就能看懂为什么有些demo看起来很惊艳，真正落到工程流程里却用不上了。

1.3 把text-to-cad理解成一个“跨模态翻译”任务

我习惯把整个问题拆成四层来看，这样不管是读论文还是看开源代码，心里都有数：

• 第一层：自然语言理解，把用户输入的文字描述转成结构化的意图表示，比如提取主体形状、关键特征、尺寸约束、空间关系。
• 第二层：三维几何表征，选择用什么样的数据格式来表示要生成的模型，比如体素网格、点云、隐式符号距离场、mesh、参数化特征序列等。
• 第三层：生成模型，用什么样的生成框架来产出这个三维表征，常见的有扩散模型、自回归模型、生成对抗网络、变分自编码器等。
• 第四层：CAD化后处理，把生成的三维表征转换成真正的CAD格式，并做拓扑修复、特征识别、参数化重建。

每一层都有各自的坑。把文本理解做差了，后面的生成再漂亮也是白搭；表征方式选错了，可能根本没法导出成可用的CAD文件；生成模型能力不够，出来的几何体漏洞百出、没法修复。所以我说text-to-cad不是一个“单一模型问题”，而是一个“系统工程问题”，这也是为什么目前成熟的商业化产品几乎为零——整条链路的难度远比表面看起来要大。

2. 核心原理拆解：从自然语言到三维几何的完整链路

2.1 语言编码这关怎么过

文本输入的第一步是编码，目前主流做法是用预训练语言模型（比如BERT、T5或者GPT系列）把文字描述转成语义向量。这步听着简单，但有个容易被忽视的细节：预训练模型是在“通用语料”上训练的，而CAD领域的描述往往有很强的行业特殊性，比如“通孔”、“沉头孔”、“腰形槽”、“加强筋”这些词在通用语料里出现频率很低，模型对它们的语义理解未必准确。

我自己在实测里就遇到过很明显的例子：输入“带沉头孔的不锈钢板”，有些开源模型生成出来的孔是直的，完全没有锥头段。后来我仔细检查了训练数据才发现，模型训练时用的文本标注里，很多“沉头孔”和“通孔”的标注是混用的，标注人员自己都分不清。所以现在稍微靠谱一点的项目，都会在语言编码前做一次领域适配，比如用CAD领域的语料做继续预训练，或者干脆手工构造一批模板描述来微调语言模型。这个细节看着不起眼，但对生成结果的准确性影响非常大。

2.2 三维表征选型：体素、点云、隐式场还是参数化序列

这是整个text-to-cad方向最核心的决策点，我把几种主流方案摊开来讲。

体素（Voxel）：就是把三维空间划分成一个个小立方体格子，每个格子标记是否被模型占据。优点是简单直观，缺点也很明显——分辨率低的时候细节全丢，分辨率高的内存爆炸。比如一个128x128x128的体素网格，光布尔数据就超过200万项，再往上加分辨率，显存直接爆掉。所以纯体素方案在text-to-cad里基本已经边缘化了，更多是作为辅助监督信号存在。

点云（Point Cloud）：用一组离散的三维点来表示表面。优点是可以直接利用点云处理网络，缺点是没有拓扑连接关系，后续重建曲面时需要额外的步骤判断哪些点属于同一张面。不过因为点云在自动驾驶、机器人领域积累了大量现成工具，不少text-to-cad项目选择先“文生点云”，再做表面重建。

隐式神经场（NeRF/SDF）：用神经网络表示一个符号距离场，模型里每个点都能查出一个“到最近表面的带符号距离”。这种方法能生成任意拓扑的模型，细节表现力强，OpenAI的Shap-E、Point-E走的都是这个路子。缺点是查询速度慢，而且直接拿到的隐含函数要转成mesh，得靠Marching Cubes这类算法，转出来的mesh质量也时好时坏。

参数化特征序列：这是目前最接近“真CAD”的方向。把CAD建模过程理解成一个操作序列，比如“先画一个矩形草图，拉伸10mm，在顶面上再画一个圆，拉伸切除5mm”。然后用自回归模型生成这个序列，最后直接导入CAD软件执行，得到的就是一个完整可编辑的特征树。代表工作有MIT那边的DeepCAD、Text2CAD这类研究。思路非常诱人，但实现难度也最大——序列数据标注成本高，模型生成的序列经常出现“执行到一半参数对不上”的尴尬情况。我在后面实操部分会专门讲这条路的坑和应对方法。

三种方案怎么选，取决于你最终要什么：只是做视觉展示和3D打印，点云+网格重建就够了；要进CAD软件做二次编辑，那参数化特征序列才是真正的终点。

2.3 生成模型这块，扩散模型和自回归模型谁更香

生成模型的选择跟三维表征是配套的。目前扩散模型在视觉生成领域占据了统治地位，三维生成也大量复用这一套逻辑，本质上是学习“从噪声分布逐步去噪到真实数据分布”的过程。但三维扩散模型的计算量比二维图像大得多，一张512x512的图像代表的是26万个像素点，而一个像样的三维模型往往需要数百万甚至上千万个面片，所以大部分项目要么是在潜空间做扩散（先压缩再生成），要么是降低生成目标的分辨率来换取可行性。

自回归模型在参数化特征序列方向更常见，因为CAD特征序列本身就是类似语言的离散token序列。把每个特征操作和参数值都token化，就能用训练语言模型的方式训练一个“CAD建模动作预测器”。这个思路跟“代码生成”本质上是一样的，代码有语法规则，CAD操作序列也有它的合法性约束。但代码生成错了顶多程序跑不通，CAD操作序列错了可能直接生成一个无法挽救的破面模型，所以对模型的约束要求更高，需要引入物理约束和几何约束作为额外监督。

2.4 从mesh到CAD：后处理环节容易被人忽视

很多开源项目只展示“文本进、mesh出”，然后就说自己是text-to-cad。但真正要落地到工程流程，必须把mesh转成B-Rep，并且尽可能识别出可编辑的特征参数。这个逆过程叫“逆向工程（Reverse Engineering）”或者“B-Rep重建”，难点在于：mesh只是个三角形壳，里面没有面的数学方程，没有特征树，也没有参数约束。

我见过不少团队在这个环节翻车。一个从点云重建出来的曲面可能是由几百个微小的细分面片组成的，导进SolidWorks后整个文件卡得动不了；又或者重建结果虽然长得像，但相邻面的边界没完全对齐，一检查就有缝隙，根本无法做后续的布尔运算。所以要做出真正能用的text-to-cad工具，后处理环节其实要单独花大力气开发：需要做特征识别（认出哪些三角形属于同一个平面/圆柱面/圆锥面）、拟合几何方程、重建拓扑关系、推断参数化特征树，每一步都有专门的算法文献和工具库。

3. 工程落地的现实路径：几条值得关注的技术路线

3.1 纯生成式路线：从文本直接产出参数化特征序列

这条路以DeepCAD和Text2CAD为代表，核心思路是：建立一个“CAD操作序列”数据集，每个序列包含一系列图元绘制、尺寸标注、约束添加、拉伸切除等操作。训练时，文本描述通过编码器转成向量，和操作序列一起喂给自回归模型，让模型学会“根据文字预测下一步应该做什么操作”。

实测下来效果如何？坦白说，对简单零件（轴套、垫片、简单支架这一类）效果已经很不错了，生成的模型在CAD软件里打开就是完整特征树，可以随意修改参数。但遇到复杂造型、多特征交叉、非规则自由曲面，效果就有点拉垮，偶尔还会出现操作序列语法正确但几何结果完全不是想要东西的情况。另外，这种方案极度依赖训练数据的质量，目前公开的CAD序列数据集基本都来自参数化CAD建模大赛或者逆向工程自动生成，覆盖的零件类型和行业特征有限。

3.2 两阶段路线：先“文生网格”再做“网格参数化”

这种路线是从纯生成式方案妥协来的：第一步用成熟的开源模型（比如Shap-E、Meshy这一类工具）快速从文本生成一个mesh，第二步再用网格参数化工具（比如FreeCAD里的一些逆向工程插件、或者商业软件如Geomagic Design X）把mesh转成可编辑的B-Rep模型。

这条路线最大的优势是每一阶段都有相对成熟的工具可以组合，不用从零训练模型。缺点也很明显：第一步生成的mesh质量直接决定了第二步的效果上限，而通用文字描述生成的mesh在工程语义上往往漏洞百出——破面、自交、非流形结构、比例失调都很常见。你拿着这种网格去做参数化，逆向工具经常识别出几百个毫无意义的曲面片，或者直接提示“无法识别”。

我自己测试过几轮，用同样的文字描述“盘类零件，直径80mm，中心通孔直径20mm，四个等距分布的M6螺纹孔”，不同网格生成工具出来的结果差异极大，有的能一眼认出特征，有的完全乱来。所以两阶段方案现阶段更适合做“概念原型验证”或者“非标快速设计”，离“生成即生产”还差着距离。

3.3 模板驱动路线：在特定领域里先把问题约束住

我自己实际做项目时，发现最靠谱的还是模板驱动方案。思路是用一个预定义参数化模板库，每个模板对应一类常见零件（法兰盘、托架、齿轮坯、轴套等），文本理解模型只负责判断“用户想要哪类零件”以及“用户提到的关键尺寸和特征参数是多少”，然后把参数填进模板生成模型。

打个比方：你让模型“生成一个带六个均布孔的圆形法兰”，文本理解模块识别出模板类别是“法兰盘”，再抽取关键参数“孔数=6”，剩下的孔直径、法兰外径、厚度这些没有提到的，都用默认值填充。这种方案看似不够“酷”，但胜在稳定可靠，生成结果永远是完整的、参数化的、可加工的模型，而且文本理解的难度大幅下降——你不需要模型理解千变万化的几何语义，只需要做分类和关键参数抽取。

模板驱动路线适合的场景是企业内部小范围的自动化设计工具，比如为某个标准件系列或客户定制件做“自然语言选型和参数化出图”。它解决不了完全自由的文本到CAD生成问题，但能以极低成本创造实际工程价值。如果你要做商业落地，我非常建议先从这种路线切入。

4. 实操案例：我实际搭建的一个最小可用text-to-cad流程

4.1 环境准备和技术选型

为了验证上面这些思路，我自己搭过一个最小可用的实验流程，用的全部是开源工具，目标很简单：输入“一个直径50mm、厚10mm、中心通孔直径10mm的圆柱法兰”，输出一个能在FreeCAD里打开并编辑的实体模型。

技术选型如下：

• 文本理解：用了一个轻量级的中文文本分类模型，微调了几百条我们自己的标注数据，专门识别法兰、轴、套、板、支架这几类常见零件，同时用正则加规则的方式提取直径、厚度、孔数、孔径等关键词参数。这块其实也可以用GPT-4级别的API直接做，但我为了成本可控和部署方便，选择了小模型+规则兜底。
• 参数化模板：在FreeCAD里建了五个模板文件，每个模板的参数都定义成了Spreadsheet（电子表格）里的单元格。法兰模板的参数就是：外径、厚度、中心孔径、螺栓孔数、螺栓孔径、螺栓分布圆直径、倒角大小。
• 执行逻辑：文本理解模块识别出的类目和参数会生成一个JSON，然后一个Python脚本用FreeCAD的Python API打开对应模板，修改Spreadsheet里的参数值，重新计算（f.recompute()），最后导出成STEP和STL。

整个流程跑起来，单次从文本到出模型大概3秒以内，模型的每个参数都能在FreeCAD里看到和修改，这让我第一次真正感受到text-to-cad在工程上落地的可能性。

4.2 核心代码思路和参数提取逻辑

参数提取这块我踩过很多坑。一开始我试图完全靠大语言模型来抽取参数，发现它的输出不稳定，同样的描述换个说法，返回的JSON字段就变了。后来改成“小模型做意图分类+正则表达式做参数抽取”的组合，稳定性大幅提升。

正则表达式的规则其实很简单，比如：外径.*?(\d{2,3})\s*(?:mm|毫米)用来匹配“外径50mm”里的数字，“螺栓孔\D{0,6}(\d)\D{0,6}孔”用来匹配孔数。但中文描述实在太灵活，什么“六个孔”、“6个均匀分布的孔”、“均布六个M6孔”都指向同一个意思，规则得写很多变体，还要考虑缺省值的情况。我的策略是：能抽到的参数就填用户值，抽不到的用模板默认值，同时把“哪些参数是用户提到的、哪些是默认值”记录在日志里，方便后续人工审核。

这部分的代码我给个简化版思路：

def parse_params(text): params = { "outer_diameter": 60, # 默认值 "thickness": 10, "center_hole_diameter": 20, "bolt_count": 4, "bolt_diameter": 6, "bolt_circle_diameter": 50, "chamfer": 1.5 } if "外径" in text: m = re.search(r"外径\D{0,6}(\d+)\s*(?:mm|毫米)?", text) if m: params["outer_diameter"] = int(m.group(1)) if "厚" in text: m = re.search(r"厚\D{0,4}(\d+)\s*(?:mm|毫米)?", text) if m: params["thickness"] = int(m.group(1)) # 其余参数按同样逻辑处理 return params

用这种思路扩展，十来行代码就能覆盖大部分描述方式。要注意的是正则规则写的顺序要先长后短、先具体后通用，避免“外径50mm”被“孔50mm”的规则先匹配掉。这些细节不值钱，但真能决定工具好不好用。

4.3 FreeCAD脚本化调用的几个关键细节

FreeCAD的Python API跟很多CAD软件相比，文档算是不太友好的，这里把容易踩的坑提前说一下。

首先是打开模板并修改Spreadsheet参数的代码：

import FreeCAD as App import FreeCADGui as Gui doc = App.openDocument("flange_template.FCStd") sheet = doc.getObject("Parameters") sheet.set("outer_diameter", str(params["outer_diameter"])) sheet.set("thickness", str(params["thickness"])) doc.recompute() doc.saveAs("output.FCStd")

注意set函数里传的是字符串，不是数字，我第一次用的时候传整数，结果Spreadsheet单元格显示正常但参数驱动没有生效，排查了很久才发现是类型问题。

另一个关键是recompute()之后一定要检查模型有没有报错。参数改得太极限（比如外径改成10毫米但螺栓分布圆直径还是50毫米）会导致几何生成失败，FreeCAD不会主动告诉你，只是模型变成红色或者部件树里出现警告符号。所以我在脚本里加了校验逻辑，检查模型的Shape.Volume是否大于0，以及有没有null shape之类的异常。

导出STEP文件的代码：

import Import Import.export([doc.getObject("Body")], "output.step")

这个接口的名字就叫Import，第一次不熟悉的人很容易找不到。导出的STEP文件可以被所有主流CAD软件直接打开，而且保留特征树和参数信息，这才是真正的“CAD模型”，不是一堆三角形面片。

4.4 测试效果和局限

实测跑下来，对法兰、轴套、垫片这几类简单零件，文本描述跟真实生成结果的匹配度大概有八成以上，剩下两成主要差在用户描述了模板不支持的参数（比如“双排螺栓孔”）。对超出模板范围的零件，系统会直接提示“暂不支持该类型”，不会硬生成一个垃圾结果凑数。

这套流程的局限也很明显：模板覆盖的零件类别有限，规则引擎能理解的描述方式也有限，整体泛化能力跟论文里那种“任意文本生成任意模型”差了十万八千里。但作为工程验证，至少证明了text-to-cad在特定场景下可以做到“能用、可控、可解释”。

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

5.1 描述模糊导致的生成偏差

这个问题在自由生成路线里极其常见。你输入“一个有趣的支架”或者“一个现代风格的桌面金属零件”，模型根本不知道你在说什么。目前所有靠谱的方案，都要求文本描述在功能语义上尽量明确，比如“一个带四个安装孔的直角支架，一边长100mm，另一边长80mm，厚5mm”。

所以我的建议是：在面向用户的输入界面里，一定要做结构化引导，比如提供“零件类型下拉框+参数填空+自由描述框”的组合，而不是给一个朴素的文本输入框让AI自由发挥。越是给用户无限自由，生成结果越失控，这跟很多做文生图产品的公司踩过的坑是一样的。

5.2 几何错误和拓扑问题排查

生成网格模型时常见的几何错误有：自交面（面片互相穿透）、非流形边（一条边连接了三个或更多的面）、孤立顶点、法线翻转。这些错误会导致导出STL后切片软件崩溃，或者导入CAD后无法执行后续操作。

排查方法我推荐两板斧：一是用Meshlab的“Cleaning and Repairing”菜单做自动修复，它能处理大部分简单问题；二是写一个简单的检测脚本，遍历所有三角形检查单条边关联的面数是否不等于2，如果是，就标记为非流形。修复非流形边没有万能算法，很多时候得人工介入，所以我的经验是“尽量在生成阶段避免，而不是在后期修复”。

5.3 文本描述里的尺寸尺度不一致

这是个很隐蔽但很要命的坑。用户描述“直径5厘米的套筒”，模型生成出来的可能是个5毫米的小东西，因为训练数据里很多标注根本没写明单位，模型默认以为数值对应的就是基准单位。更麻烦的是，有些模型内部用归一化坐标，跟物理尺寸之间根本没有确定的映射，导出的STL模型实际大小完全看随机性。

解决方案是：在生成模型和应用层之间增加一个“尺寸校准层”。比如输入里如果检测到“毫米”、“cm”、“英寸”这类单位词，先统一换算成毫米，再决定缩放倍数。如果输入没有单位词，就用默认合理尺度（比如中等零件100mm左右）做基准，同时把实际尺寸写进输出的元数据，避免下游环节拿到的模型尺寸完全对不上。

5.4 显存和算力不够时的工程化降级方案

三维生成模型对显存的要求普遍不低，一个能用扩散模型生成小尺寸体素或mes h的实验环境，至少需要8GB以上显存，复杂的模型24GB也未必够用。对个人开发者来说，成本确实有点高。

我的实操建议是三步降级：第一，尽量用潜空间扩散模型而不是原始空间扩散模型，能省不少显存；第二，把生成分辨率分成两阶段，先低分辨率快速出一个轮廓，再在局部区域做高分辨率细化；第三，如果条件实在有限，直接用现成的API服务做第一阶段的“文生网格”，本地只跑参数化重建，这样对硬件要求最低。

6. 后续可以扩展的方向和个人一点真实体会

6.1 从零件级走向组件级

目前text-to-cad的研究基本都在“单个零件”这个尺度上，但工业设计里更常见的是“装配体”——一个产品由多个零件组成，零件之间还有配合关系（螺丝拧进螺纹孔、轴穿过轴承位等）。把文本生成扩展到装配体的难度不只是生成多个零件，还要在语义层面理解零件之间的约束关系，比如“这个孔是为了跟那个轴配合的”，这需要额外的关系建模和约束求解能力。我觉得未来如果哪个团队在这个方向上做出突破，那才真正的改变设计流程。

6.2 和逆向工程、自动化仿真做结合

另一个值得关注的方向是把text-to-cad跟仿真分析打通。以前设计一个零件要先建模再仿真，流程很长。如果文本能直接生成可仿真的模型，就能快速迭代多个方案——“这个支架太重了，减重20%”“这个圆角加大一点，看看应力集中是否改善”，把设计意图用自然语言直接表达，让工具自动完成修改和仿真验证。虽然离产品化还有距离，但这个闭环一旦跑通，对中小企业的设计能力会是巨大的杠杆。

6.3 我在实际使用中的几点体会

零零散散写了这么多，最后分享几条真正有价值的经验。第一，别迷信端到端模型，分阶段拆解、每个环节用最合适的工具，整体效果远好于一个“全能大模型”，这跟做菜一个道理，好的食材分开处理再组合，比一股脑全下锅强。第二，文本描述的质量决定结果的上限，投入精力做一套好的输入模板，比花大把时间调模型参数更划算。第三，任何生成结果都必须走一遍“CAD软件打开–检查特征树–重新计算尺寸”这样的验证流程，肉眼看着像没有用，工程上必须能打开、能编辑、能出图、能对接加工，缺任何一环，前面的工作都等于白做。

text-to-cad这条路还很长，但现在恰恰是入局的好时机，工具链在快速成熟，数据也在不断积累，谁先找到适合自己的场景把它落地，谁就能在这波生成式设计浪潮里站住脚。