企业官网建设流程全解析

1. 为什么偏偏是CAD：text-to-CAD和text-to-3D的本质差异

1.1 表面像不等于能造

一年多前我第一次在机械设计交流群里看到有人贴"text-to-cad"相关截图时，第一反应是又一个text-to-3D的换皮宣传。当时群里有人输入一句 "motor mount with four through holes and a central bore"，直接蹦出来一个看着相当完整的支架模型，下面一堆人问用的什么插件。直到我自己把CLAY这类开源模型跑通，又在Zoo.dev的项目里玩了一阵子，才发现这个方向跟以前那些生成"长得像的艺术网格"的东西根本不是一回事——它想做的是把大模型接进工程建模流程，让"一句话出CAD模型"从概念变成能用的草稿工具。

很多人觉得text-to-CAD和text-to-3D差不多，顶多是"换了CAD的壳"。这是目前这个领域最大的误解。text-to-3D我们其实已经很熟了，DreamFusion、Point-E、Meshy这些工具，你要一个"看起来像龙的雕像"，它给你一个带纹理的多边形网格，放到游戏里、渲染图里没问题。但如果你要一个"DN50法兰，6个12毫米均布螺栓孔，厚度12毫米"，text-to-3D给你的是个"看起来像法兰盘"的雕塑——孔的位置是糊的，孔径是猜的，背面还是封死的，你拿尺子去量任何一个尺寸都没法用。

CAD模型的核心不是"像"，而是三样东西：精确尺寸、约束关系和制造语义。法兰盘在CAD里不是一张表面形状，而是一组参数：外径、内孔、分度圆直径、螺栓孔数、厚度，这些参数之间还有联动关系，改了外径，分度圆要不要跟着变，孔距怎么约束，这都是设计意图。text-to-CAD真正难的不是把文本变成一堆三角形，而是把文本变成"能标注、能制造、能修改"的参数化实体。这两者之间的差距，就是为什么text-to-CAD成熟得比text-to-3D晚得多。

我见过不止一个机械工程师第一次体验text-to-CAD时的反应：先用一句"一个带安装孔的外壳"生成一个模型，看起来挺唬人，然后他习惯性地想点开结构树改个壁厚——发现什么都没有，只有一个锁死的网格体。那一刻他才明白，这个领域离替代CAD还远得很。但从另一个角度看，text-to-CAD的目标本来也不是替代CAD，它想解决的问题非常具体：把"从想法到第一版草稿"的时间从几个小时压到几分钟。

1.2 到底是谁在喊"需要一个text-to-CAD"

我在跟不同背景的人聊过之后发现，这个方向的早期用户画像比我想象的清晰。

第一类是中小制造和非标自动化团队。他们接的活经常是"客户发来一个示意图，说我要一个能把电机装到铝型材上的支架"，传统流程是工程师先花半天建模，再花半天改结构。这类团队的需求不是"让AI生成艺术品"，而是"快速得到一版能讨论的结构初稿"，方便报价和沟通。

第二类是结构工程师。他们用CAD熟练但希望能更快地做方案比选：一个零件做三个版本，壁厚、开孔位置、加强筋布局各不同，给客户选。如果有个工具能基于文本描述快速生成几种变体，哪怕精度差点，也值得。

第三类是创客和3D打印玩家。他们没有系统学过CAD，但想做一个手机支架、一个树莓派外壳、一个桌下理线架。传统路径是去模型站下载别人的改一改，或者硬着头皮学Fusion 360。text-to-CAD如果靠谱，他们是最先受益的一批。

第四类是教育场景。教机械制图和参数化设计时，学生的问题往往不是理解不了概念，而是软件操作熟练度不够，导致大量时间耗在"怎么画线怎么拉伸"上。AI生成初稿让学生把注意力放在"为什么这个结构合理"上，对教学有真实价值。

有意思的是，这些需求背后有一个共同点：他们要的不是"免建模"，而是"降低建模的起手式门槛"。CAD操作从来不是目的，把脑子里的设计意图变成一个能制造、能修改的对象，才是目的。

1.3 一个反直觉的观察：标准化物件比自由造型更容易生成

我实际玩下来发现一个反直觉的现象：对三维生成模型来说，"语义越标准"的物体反而生成得越好，比如法兰、轴承座、电机支架、螺栓这类高度标准化的机械零件；而越是"自由曲面艺术造型"，文本描述几乎无能为力。

原因很好理解。语言描述几何的能力是极其有限的，你说"一个优美的曲面"——什么叫优美？模型没法落地。但你说"一个带四个通孔的矩形安装板，孔距50毫米，孔径6毫米"，每个词都对应明确的几何参数，模型反而能准确映射到训练数据里的常见结构。也就是说，text-to-CAD目前最适合的恰恰是那些"长得有规矩"的工业件，而不是艺术品。这个观察基本决定了我接下来所有工具选型和流程设计的方向。

2. 技术路线拆解：CLAY让名字出圈，但它只是冰山一角

2.1 扩散模型直接生成表面：CLAY与神经场的路子

CLAY是2024年让"text-to-CAD"这个词在技术圈彻底出圈的项目，由苏黎世联邦理工Robert Katzschmann教授的团队开源。它做的事情很直接：给定一句文本描述，直接生成一个带纹理的三维模型，但不是用老式的点云或者体素生成，而是把图像扩散模型的思路搬到了三维空间。

具体来说，CLAY借用了FLUX.1的图像先验，改造出一套三维条件下的扩散模型，输出的是Signed Distance Field（SDF，符号距离场）、UV贴图、法线、材质这类三维表示。简单解释一下SDF：想象在一个三维空间里，每个点都有一个数值，表示它到最近表面的距离，正数在表面外，负数在表面内，零的位置就是表面。生成完SDF之后，再用marching cubes算法提取零等值面，就变成了可以直接渲染和导出的三角形网格。

这个路线的优势非常明显：生成结果细节丰富，能做到"看起来就是一个人手工雕刻过的模型"。社区里最惊艳的案例包括做旧的木质门板、皮沙发、油灯、金属感十足的机器人部件，表面细节甚至能看出材料的氧化痕迹。CLAY的代码和模型权重是开源的，所以它也成了很多人第一次真正把text-to-CAD跑通的起点。

但它的短板同样明显：输出是网格，不是CAD的B-rep（边界表示）实体，没有特征树，没有参数依赖，甚至没有毫米单位的概念。你在CLAY里生成一个"直径40毫米的齿轮"，它只会给你一个"看起来像齿轮"的网格，齿数不对没关系，齿轮孔径更没有。作为概念造型生成器，CLAY非常强；作为工程零件生成器，它差得还很远。

2.2 大模型翻译建模命令：从Text2CAD论文说起

CLAY让人看到"直接生成几何"的可能性，但工程界的核心诉求始终是"生成的东西得能改"。2023年微软研究院发了一篇TEXT2CAD的论文，思路和CLAY完全不同：它不让模型直接生成几何表面，而是让大语言模型把自然语言描述翻译成一条一条的CAD建模命令。

比如你说"创建一个30毫米乘60毫米的矩形草图，然后拉伸10毫米"，模型会输出类似add_rectangle(30, 60)、extrude(10)这样的命令序列，然后由CAD软件按照命令序列真正执行建模。这样做的好处是：生成的模型天然带完整特征历史，因为每一步都是明确命令；修改也很简单——改其中一条命令，模型就更新了。这正是工程师眼里的"活模型"。

这种路线的瓶颈也很直观。命令空间是封闭的，LLM只能在预定义的建模命令集里做翻译，碰到自由曲面、复杂倒角、空间曲线这些靠标准命令堆不出来的几何，就完全没辙。另外，命令序列长度一长，LLM的错误就会累积：中间一步参数错了，后面的特征全部跑偏。目前这类方法更适合快速构造简单机械零件，也是我认为离实用化更近的一条路线。

2.3 脚本化参数建模：Zoo.dev的开源实践

2025年前后，Zoo.dev做的一个text-to-CAD项目，是我个人觉得当前最接近工程实用态的一条路。它的做法可以理解成Text2CAD路线的工程化升级：你输入一句英文描述，LLM直接输出一段TypeScript脚本，脚本调用Zoo Modeling Language（ZML）来描述三维几何，最终在浏览器里渲染成模型，并且可以导出STEP、STL、GLTF这些工业常用格式。

可能有点抽象，我贴一段它生成脚本的示意（具体API以官方文档为准）：

import { draw, extrude } from "@zoo/geometry"; // 创建 60x40 的矩形底座 const base = draw.rectangle(60, 40); // 拉伸 12 毫米 const solid = extrude(base, 12); // 在中心开一个直径 6 毫米的孔 const hole = draw.circle(3); export const model = solid.subtract(hole);

我试用的时候，最大的感受是"它终于给了你一个能改的东西"。脚本就是参数化模型本身，你想改孔距，直接改代码里的数字再重跑；想加圆角，加一行命令。LLM负责把文本翻译成脚本，几何逻辑由建模库保证，比让LLM直接生成三角形网格可靠得多。

这套方案的短板在于LLM的幻觉问题。它经常写出不存在的API、自创参数名，或者生成几何上自相交的实体。Zoo.dev的做法是尽量在运行阶段做校验和自动修复，但失败率依然不低。对一个不懂代码的机械工程师来说，看到一段报错的TypeScript脚本就懵了。不过对我这种愿意读代码的人，它反而成了加分项——报错了看一眼代码就知道问题在哪，直接改，比在CAD里重新操作快太多。

2.4 检索加重绘：不是生成，但经常被当生成用

还有一个需要警惕的现象：市面上不少号称text-to-CAD的产品，本质是"检索加局部修改"，不是"生成"。它们的流程是：先分析用户文本，从模型库里检索最接近的已有CAD模型，然后再用算法做局部变形或特征替换。

判断方法我自己摸出一个土办法：给它一个"你几乎不可能在训练数据里见过"的组合描述，比如"一个长得像海豚的桌子"。真正的生成模型会尝试创造，哪怕结果很怪；检索型产品会直接返回一张桌子或者一只海豚，因为它只能从已有类别里挑，没办法在语义空间里合成新东西。

我说检索型不好了吗？没有。对工业应用来说，检索型的可靠性反而更高——已经存在的模型本来就是经过验证的，改一改局部尺寸就能用。很多商业工具宣称的"秒级生成CAD"，背后就是这套逻辑。只是作为用户，你需要知道自己付钱买的是真生成还是假生成，因为两者的适用场景和迭代路径差得很远。

这三种路线的核心差异，我整理成一个对比表方便大家参考：

3. 亲测主流工具：能力边界、参数取舍与翻车现场

3.1 测试一：从一句"带四个孔的电机支架"开始

我在CLAY上做的第一组测试，选的是机械设计里最常见的场景——电机安装支架。提示词很简单："a wall-mounted bracket with two mounting holes"。

生成的模型第一眼相当唬人：整体轮廓对称，边缘有自然的倒角，表面纹理甚至带一点压铸件的质感。但我把它放到Blender里检查拓扑之后，问题全出来了。两个安装孔的位置不对称，一个高一个低；背面的安装面不是平面，而是略有起伏的曲面；孔壁没有闭合，有一侧直接和外部空间打通了。对渲染来说这些细节无所谓，但对装配来说，这套模型完全不可用。

我又试了"flange with six holes"，想看看它对数量和阵列的处理能力。结果生成了五孔版本、七孔版本、六孔版本各一次，只有一次数量对，而且那一次孔的分布也没有做到严格均匀。放大看，有些"孔"根本是在表面压了个圆形凹陷，没有贯穿。扩散模型学到的"孔"是一团像孔的形状信号，不是"一个位置精确的通孔特征"。全局计数和拓扑一致性对这类模型来说，目前就是死穴。

3.2 测试二：Zoo.dev的脚本能跑通吗

Zoo.dev的text-to-cad我用的时间最长，因为它的输出能真正导入到CAD软件流程里。我输入"a table with four cylindrical legs"，第一次生成的脚本顺利编译，但打开模型发现四条腿不在一个平面上，有一条腿短了一截。我没有重新生成，而是直接看它输出的TypeScript代码，发现有一个腿的高度参数写成了"28"而不是"30"。这种错误对LLM来说很常见：数值一致性问题，它在语义上知道"四条腿等高"，但具体数值输出时会随机漂移。

第二次我加上了明确的尺寸约束："a table with four legs at the corners，each leg 30mm diameter，table top 80cm by 50cm"。这次几何对了，但它在单位换算上把毫米和厘米混用了：桌腿直径是30mm，桌面长宽却用80cm，模型里桌面大得比例失调。好在脚本是代码，我自己改很简单，但这说明LLM对单位体系的理解远没有到可靠的程度。

最有意思的是一次测试："bracket with 6mm mounting holes"。它生成的脚本里写的是"6"，但没有单位概念，如果下游软件默认英尺，那就是灾难。Zoo.dev目前的做法是假设用户输入的数值就是建模时的最终数值，导出的STEP文件到了Fusion 360里默认按毫米解释，刚好对上。这里能看出，项目团队做了工程上的取舍——放弃通用单位换算，换取"用户在提示词里写什么就是什么"的确定性。

3.3 测试三：中文工具与工业演示的观察

国内团队也在这个方向上快速跟进。广汽研究院在2024年底发布了Muse AI，主打中文输入直接生成CAD模型，宣传视频里演示了"3秒生成一个汽车零件"级别的效果，面向的显然是汽车和工业设计场景。我虽然没有第一时间抢到内测资格，但从公开演示来看，它生成的概念件完成度已经接近CLAY的水平，而且中文语义理解明显更顺——我试过用中文描述同一个电机支架，效果比我在CLAY上输入的英文还要稳定一些。不过坦白说，公开演示的素材仍然停留在概念展示阶段，距离加工级还有一段肉眼可见的距离。

与此同时，传统CAD大厂也在悄悄布局。SolidWorks在3D Creator云套件里上线了Text to CAD的beta功能，思路不是独立生成模型，而是把文本变成云端特征重建命令，相当于把大模型变成了"特征助手"。AutoCAD的AI助手方向也类似，更多是理解用户命令、辅助操作，而不是直接吐几何。大厂的选择很能说明问题：它们要的不是替代CAD内核，而是让LLM成为现有建模流程的入口。

3.4 目前最稳的组合玩法

测试了这么多，我自己沉淀出的主力玩法是组合拳，不依赖单一工具走完整个流程。

第一步，用CLAY做造型探索。当你的设计目标里有复杂的自由曲面、有机形态、外观风格时，先让CLAY出几张概念图，找到感觉，它输出的是"灵感"，不是"零件"。

第二步，把概念里确定的设计意图转成文字，关键尺寸、孔位、壁厚、功能要求，写到Zoo.dev这类脚本生成工具里，让它产出带参数化脚本的初稿。

第三步，把生成的STEP文件导入Fusion 360或者FreeCAD，手动重建特征树，补上工程图中需要的公差、基准和表面粗糙度。这一步目前省不掉，但已经可以把传统"从零建模"的时间压缩掉一半以上。

这套流程的核心逻辑是：让AI负责从模糊到具体的中间转换，让人负责从具体到精确的最终裁决。

4. 落地中的硬骨头：B-rep转换、约束历史与数据闭环

4.1 网格模型为什么过不了工程师这一关

我前面反复提到网格模型和B-rep的区别，这里展开讲清楚，因为这是text-to-CAD落地时绕不开的第一道坎。

CAD软件内部真正使用的是B-rep（Boundary Representation，边界表示）模型，简单说就是一个实体由有限个精确的NURBS曲面拼接而成，每个面的边界曲线、顶点拓扑关系都是明确定义的。这种表示法能支撑后续所有工程动作：标注尺寸、生成工程图、CAM编程算刀路、有限元分析划分网格、装配体干涉检查。而扩散模型生成的三角形网格，是一堆离散的平面小三角形拼出来的近似形状，精度再高也是"看起来像"，不是"数学上精确"。

从网格转回B-rep的问题有多大？我给你一个直观的比喻：把一张照片放大到像素级别，然后让程序自动用光滑曲线把里面的物体轮廓重画出来——这就是mesh to B-rep的日常工作。网格里有密集的小三角，程序得先判断哪些三角面属于同一个曲面片，再拟合出对应的NURBS曲面，最后把相邻曲面缝合成封闭实体。遇到倒角、过渡曲面、细微的台阶面，拟合结果就很容易碎成几百块碎面，或者产生重叠、破洞。当前这类算法需要大量人工干预，通常要靠Geomagic Design X这类专业逆向软件里的资深工程师花几个小时来处理。一个AI花几秒生成的模型，要在人这里花几小时收拾，这笔账很多团队算不过。

更糟的是，CLAY这类生成模型输出的网格往往拓扑非常复杂——面片数十几万，三角形大小不均，还有封闭内腔、悬空面这些"看起来正常但工程上非法"的结构。这就让自动转换雪上加霜。

4.2 特征树缺失：能改才是CAD

CAD的另一个灵魂是特征树。你在SolidWorks或者Fusion 360里建的每个零件，本质上是一连串记录的建模步骤：基准面、草图、拉伸、切除、倒角、孔阵列。每一步都能回退、修改、抑制，修改一个草图，后面所有相关特征自动更新。这才是工程师口中的"活模型"。

现在多数text-to-CAD工具生成的STEP文件，即使几何形状是对的，也没有特征树。它是一个"死模型"：你导入软件之后，所有的面都凝固成最终状态，没有草图，没有拉伸记录，没有约束。想改一个孔径，对不起，你得把整个模型当成一个实体重新切割。对一个CAD熟练工来说，这种模型的价值比网格模型高不了太多。

所以在所有路线里，参数化脚本路线（比如Zoo.dev）为什么更打动人，就是因为它把"模型=程序"这个现代CAD底层逻辑接了回来。几何形状由代码产生，特征历史的载体从"树节点"变成"代码行"，修改几何就是修改参数重跑脚本。虽然脚本式的"历史"不如图形特征树那么好用，但它至少把可编辑性还给了用户。我认为，text-to-CAD要真正进入工程流程，特征历史不是可选项，是必选项。

4.3 文本描述的空间分辨率

还有一个经常被忽略的瓶颈：人类语言描述几何的能力天生不够精确。你说"厚一点"，是厚0.5毫米还是5毫米？你说"圆角过渡"，半径多少？当前LLM在处理这类模糊描述时，采取的策略是"填一个训练分布里的高频默认值"。这个值大概率不是你想要的。

这种模糊性带来一个实际后果：用户在和text-to-CAD工具对话时，必须自己承担"把意图翻译成数字"的责任。我在给自己写的提示词模板里，坚持的原则是把所有关键几何拆成"数字加单位"的结构，杜绝"bigger""thicker""some holes"这类词。这也是为什么我在实操中发现，一个会把需求翻译成工程参数的用户，和一个不会的用户，用同一个工具得到的结果差距是数量级的。

4.4 数据瓶颈是真正的胜负手

最后说一个决定这个领域未来走向的问题：训练数据。text-to-3D之所以能快速发展，是因为互联网上海量的图-文对提供了训练语料，模型可以从"图片配文字描述"中学到"一只狗"长什么样。但text-to-CAD需要的训练数据是"文本描述配CAD建模过程/参数化模型"，这类数据在公开互联网上极其稀少。

常在学术圈被提起的数据集包括：ABC（Autodesk Research发布的百万级CAD模型）、Fusion 360 Gallery（包含大量带特征历史的机械零件）、PartNet（带部件层级标注的CAD模型集）。但这些数据的共同问题是：几何信息有，文本描述几乎没有。工程上有一种做法是用LLM反过来给CAD模型生成描述文本，然后拿"模型—文本"对再去训练生成模型，相当于数据自举。这能缓解一部分问题，但生成的描述大多停留在"这是一个支架""这是一个齿轮"的粗粒度，远达不到"六个均布通孔孔径6毫米"这种工程描述的信息密度。

谁手里有制造企业的真实建模日志——工程师在CAD里的一步步操作、伴随的标注、产出的图纸——谁就能训练出比通用模型强一个档次的垂直text-to-CAD模型。这也是为什么现在这个阶段的真正竞争不在算法层，而在数据获取层。算法论文会越来越公开，数据护城河会越来越值钱。

5. 给工程师和创客的可用建议：现在就上手，但别重投入

5.1 一个实用的Prompt模板

如果你现在就想把text-to-CAD用起来，我最想给你的建议不是推荐哪个工具，而是把提示词写好的方法。一个合格的工程提示词，要包含五个信息块：应用场景、零件类型、功能要求、关键尺寸、制造工艺。

我常用的是一个填空式模板：

为[应用场景]设计一个[零件类型]， 功能要求是[连接/支撑/限位/防护中的一种或几种]， 关键接口尺寸为[长、宽、高、轴径、孔径、孔距]， 材料为[铝合金/钢/工程塑料]， 制造工艺为[数控加工/3D打印/钣金折弯]， 优先考虑[轻量化/便于装配/减少加工步骤]。

举一个实际的对比。我用两个提示词在同一个工具里生成"电机支架"，第一个是"做一个电机支架"，结果生成的模型是一个四四方方的盒子，上面有个莫名其妙的桃花心木纹理——模型把"支架"理解成了展示台。第二个我按模板写：

为NEMA17步进电机设计一个L型安装支架，功能要求是将电机固定在铝型材框架上， 关键尺寸为电机面板64mm见方，安装孔距31mm，孔径4.2mm，支架壁厚5mm， 材料为6061铝合金，制造工艺为数控铣削，优先考虑轻量化和减少加工步骤。

这一次生成的模型基本能用：L型结构正确，四个安装孔的位置和孔径都对了，底面有预留的型材槽口。当然精度依然达不到直接加工的水准，但作为初稿，它帮我省掉了画草图、拉伸、打孔、倒角这一整套起手步骤。这就是模板的价值。

5.2 拿到结果之后的检查清单

AI生成的模型不管多唬人，我建议你拿到手之后都按下面这份清单过一遍，尤其是准备把模型交给别人或者拿去加工之前：

• 单位一致性：模型里标注的毫米/英寸是不是你想要的，导出的STEP在软件里被解释成什么单位。
• 孔是否贯通：名义上是通孔的特征，是不是真的从一端穿透到另一端。
• 壁厚是否合理：生成件经常出现0.5毫米以下的薄壁，注塑和铸造都做不了。
• 拔模角度：涉及模具成型的零件，侧壁有没有给拔模角。
• 对称性：标称对称的零件，左右两侧的孔位、倒角是否真的对称。
• 干涉与间隙：装配体里，两个零件的接触面有没有留装配间隙。
• 可制造性：内部有没有数控刀具够不到的角落，有没有加工时无法装夹的结构。

这套检查清单我整理成了给自己用的一个简短版本，贴在待办事项工具里，生成完模型就过一遍，每次都能抓到至少一个明显问题。把检查环节前置，比在加工厂那边翻车再补救省事一百倍。

5.3 对工具边界保持清醒：它是草稿纸，不是终稿交付

我在整个体验过程中最大的感受是：当前text-to-CAD工具的定位应该是"草稿加速器"，而不是"设计替代者"。它做的事情本质上是从训练数据的分布里"抽样"一个看起来合理的答案，而不是基于几何规则做精确求解。这意味着，你让它生成一个没见过的结构组合，它有想象力但没有判断力；你让它保证公差和配合精度，它根本不知道配合是什么。

但这不代表它不值得用。对工程师来说，它的价值体现在几个具体场景：和客户沟通时快速输出概念示意、给供应商征询报价时提供初版模型、方案评审时生成多版变体对比。对创客来说，它的价值更直接：减少从想法到可打印模型的步骤。对设计师来说，它让"形状探索"从几个小时浓缩成几十次生成迭代。

还有一个容易被忽视的好处。我把text-to-CAD用了一个多月之后，发现自己写技术需求文档的能力明显变强了。因为你要让AI输出好结果，就必须把设计意图拆成功能、尺寸、工艺、材料这些颗粒度足够细的要素。这个过程本身就是一次完整的设计需求梳理。

最后说点个人体会

我自己现在的工作流里，text-to-CAD已经成了固定的第一站，但它的角色很明确：它是我用来"把自己的需求说清楚"的镜子，也是我输出概念草稿的加速器。如果你打算尝试，我给一个最实际的建议：在提示词里尽量写清楚制造工艺——"该零件将用数控铣削加工，侧壁需要拔模角"——这十几个词对结果的影响，比换一个更强的模型还要大。模型对工艺的敏感度远比很多人以为的高，一句工艺说明就能让生成结果从"雕塑"变成"零件"。

真正让我对这个方向保持乐观的，不是哪一家模型效果惊艳，而是参数化脚本这条路线终于被人认真做出来了。代码即模型，脚本即历史，这是过去几年所有3D生成技术里最接近工程本质的一次尝试。后续如果数据闭环跑通，LLM的几何能力再往前进一步，text-to-CAD从"草稿纸"变成"正式图纸的起点"，并不是遥不可及的事。