企业官网建设流程全解析

前阵子有个需求让我印象挺深：一个同事拿着图纸来找我，指着一个带六个孔的钣金支架说，“能不能让AI直接把这个零件生成出来，描述一下就行？我这边有个text-to-cad的工具想试试。”我当时一愣，心想这个“描述一下就能出模型”的工具确实火，但能直接把工程件做出来吗？带着这个问号，我自己花了两三天时间，把市面上主流的技术路线都试了一遍。

先说结论：text-to-cad这个方向，远没有短视频里演示的那么“神奇”，它跟近两年流行的AI画图、文本生成3D模型完全是两码事。AI画图是生成像素，文生3D大多生成的是网格“外壳”，而CAD落地的核心是实打实的实体模型——要有尺寸、有拓扑、有特征树、能出工程图、能下数控加工。这三者之间的差距，比“画得像”和“造得出”之间的差距还要大得多。

所以这篇我不打算泛泛介绍概念，而是把text-to-cad目前的主流实现路径、我自己实测三条技术路线的完整过程、以及那些真正卡住工程落地的瓶颈问题，全部摊开讲清楚。不管你是机械设计出身、想了解AI能帮到什么程度，还是做开发的、想判断哪条路线值得投入，这篇应该都能给你一个比较底层的判断框架。

1. text-to-cad到底想解决什么问题：从“看图说话”到“可编辑的实体模型”

1.1 为什么“文生3D”和“文生CAD”是不能混为一谈的两件事

我见过很多文章把text-to-cad和“文生3D”放在一起介绍，其实这两者的目标对象完全不同。

现在大家常说的文生3D，比如输入“一只戴帽子的柴犬”，生成的绝大多数是三角网格(Mesh)或神经辐射场(NeRF)。这种模型的好处是渲染出来非常好看，动画、游戏、VR场景里直接用没问题。但工程上它几乎不能用：网格模型没有“面”和“边”的拓扑语义，不能做精确的布尔运算，不能标注尺寸，更不能直接出加工刀路。哪怕网格密度再高，它本质上还是一层“皮”，不是实打实的体。

CAD模型的核心是实体建模，最常见的是边界表示(B-Rep)，也就是由面(Face)、边(Edge)、顶点(Vertex)加上明确的拓扑连接关系构成；再往上，参数化CAD还会有特征历史树(Feature Tree)，比如“拉伸一个100×80的矩形底座→在底面上打四个φ8的通孔→再做一个高40的侧板”。这棵特征树才是一份真图纸的灵魂。设计师拿到一个模型，第一件事往往是打开特征树看它是怎么长出来的，因为只有这样，后面才能改。

打个比方：文生3D相当于你请摄影师拍了一张产品照片，好看，但不能动；text-to-cad的目标是给你一张带尺寸标注和修改历史的“施工蓝图”，任何一个尺寸不对，改参数就能重新生成。

这个区别是所有后续讨论的地基。text-to-cad真正要跨过的门槛，不是“生成一个看起来像零件的形状”，而是“生成一个具备完整工程语义的实体模型”——有精确几何、有合理拓扑、有可编辑的参数化历史。

1.2 语言到CAD这条链路，真正的难点在哪

理解了上面的区别，就能看懂为什么text-to-cad这么难。

CAD模型本质上是一种高度结构化的数据，它不像图片那样是规则的像素网格，可以直接塞给卷积神经网络。B-Rep模型里，一条边连接着哪两个面、一个面由几条曲线围成、曲线是直线还是样条、样条的控制点坐标是多少——这些信息彼此强耦合，错一个拓扑连接，整个模型就废了。

更麻烦的是，自然语言天生是模糊的。你说“一块板子上开几个孔”，这“几个”到底是三还是五？“板子”是方形还是圆形？“开孔”是通孔还是盲孔？工程师之间靠一张图纸才能消除的歧义，现在全部压给模型去猜。

所以text-to-cad从一出生，就面临着双重不确定性：语言本身的不确定性，加上CAD数据结构的高复杂度。这也是我后面实测时，为什么反复强调“看起来对”和“真正能用”之间存在巨大鸿沟的真正原因。

2. 四类主流技术路线拆解：从“端到端生成实体”到“LLM写程序化建模代码”

目前text-to-cad并不是只有一种实现方法。我在调研和实测中发现，这个领域至少有四条完全不同的技术路线，它们的出发点、代表工具、优劣势差异极大。搞清楚这些，比盲目追某个新模型重要得多，因为很多团队选错了路线，做了大量工作却一直原地打转。

先说总览，下面这张表是我自己的理解框架：

下面逐个展开说。

2.1 端到端B-Rep生成：看着很性感，用起来很骨感

端到端生成，就是走“文本→直接生成CAD模型文件（STEP/IGES）”这条路。这绝对是这个领域看着最神奇的一类：你不用写任何代码，输入一句“一个直径50mm高20mm的圆柱体，顶面中心有一个φ10的沉头孔”，它直接吐出一个可以打开的STEP文件。

这个方向的底层逻辑，是把CAD模型“拆碎”成模型可以学习的token序列。B-Rep里每一条边、每一个面、每一条样条曲线，都可以转换成特定格式的数字序列，然后用Transformer来预测下一个token。你训练的时候输入的是大量“CAD模型序列”，输出是学会了“什么样的几何序列是合理的”，推理的时候再把文本描述作为条件，让它生成符合条件的几何序列。

我在测试时发现，这类方法对简单几何体（立方体、圆柱、带少量孔的板子）表现尚可，但一旦特征超过十个，拓扑错误率就开始飙升。最典型的问题是：本应闭合的实体，生成结果却有一个面没有缝合上；或是一根边应该连接两个面，结果它的端点悬空了。这种模型在专业CAD软件里打开，会直接报“几何无效/实体不完整”。

为什么会这样？本质上是因为B-Rep的约束条件太严苛，自回归模型在逐token生成时，每走一步都要保证全局的拓扑闭包，这比生成一段通顺的文本要难得多。文本少写一个词，读者还能猜；B-Rep少一个拓扑关系，实体就是废的。

2.2 LLM+程序化建模代码：目前最“笨”但最靠谱的方案

相比之下，我实测中最能落地的路线，反而是“让大模型写程序化建模代码”。

程序化CAD这个思路在工程界其实不新鲜，OpenSCAD、CadQuery、build123d这些工具早就在用“代码生成模型”的方式建模。CadQuery尤其适合做机械零件，它的逻辑就是“选择一个工作平面→草图绘制→拉伸/切割→再选面→再打孔”，每一步代码都对应一个CAD特征操作。

到了text-to-cad时代，大家发现一个有趣的事：大模型不太擅长直接生成B-Rep序列，但很擅长写CadQuery代码。因为代码是文本，是LLM的“母语”；而CadQuery这类库的API文档又足够规范，模型在预训练阶段见过大量类似代码。

实际工作流是：你输入“帮我生成一个L型支架，底面100×80×10，四个角有φ6通孔”，大模型给你一段CadQuery脚本，你在本地Python环境里执行，脚本跑通，自动生成一个真正的三维实体STEP文件。

这条路最大的优势是可编辑性——代码本身就是参数化模板，改一个数字重新执行，模型就变了。它最大的问题也很明显：LLM写代码会犯错，尤其是涉及工作平面选择的代码，经常把孔挖到对面去。不过代码错误是可以调试、可以修的，比端到端生成的“黑盒”错误好处理得多。

2.3 草图+约束求解：更贴近设计师习惯的中间路线

还有一类方法，是让模型先生成2D草图轮廓和几何约束关系，再通过拉伸、旋转、扫掠这些典型建模特征来生成3D实体。这个思路比端到端生成B-Rep“更有工程味”，因为它模拟的就是设计师的真实操作：先画草图，标注约束，然后拉伸。

这类方法的代表思路是DeepCAD那一系的研究，它们把CAD建模过程看成“草图+操作序列”的组合。比如一个法兰盘可以分解为：“生成一个中心在原点、外径60的圆草图→拉伸20mm→选择顶面→生成一个外径30的圆→打穿→生成6个均布孔”。

这种分解方式的优点在于，每一步操作的语义都很明确，模型不需要跨越“从文本到复杂拓扑”的鸿沟，只需要学会“给定当前状态，下一步做什么操作”。缺点是：它生成的模型依然没有真正的参数化约束关系——想象一下，你拿到一个“拉伸后打孔”的模型，想改孔的直径，如果用传统CAD里的特征树，双击尺寸就能改；但这种序列生成方法，往往只是把最终几何体导出了，修改就得重新生成整个序列，特别不灵活。

2.4 检索+参数化装配：被很多人忽略但最实用的路线

最后一条路线，其实被绝大多数讨论忽略了：不生成几何，而是从已有零件库中检索最相似的型号，再让LLM推荐参数修改方案。

这个方法听着不够“AI”，但在我实际接触的企业里，落地效果反而最好。因为制造企业里80%的零件其实都是标准件、常用件：垫片、法兰、支架、轴套、钣金折弯件。它们的模型早就躺在零件库里，工程数据完整、经过实际生产验证。

你只需让模型理解自然语言描述，去库里检索最接近的零件类别，然后根据文本里的关键尺寸（如“M6螺纹孔”“板厚3mm”），输出调整后的参数。这个方案不碰任何几何生成难题，精度、可靠性、可加工性全部有保障。

代价是它的创新能力为零：库里没有的新零件，它就无能为力。但它恰恰提醒了我们：text-to-cad的首要价值可能不是无中生有，而是大幅度降低从“想法”到“已有资源匹配”的时间成本。

3. 实测记录：同一句话，三种方法的结果天差地别

理论说再多，不如实际跑一遍。我自己搭了一个测试环境，统一输入下面这句描述：

“L型安装支架，底面100×80×10，侧板高50、厚8，底面四角四个φ6通孔，侧板中心一个M8螺纹孔。”

分别用三条路线去跑：LLM+CadQuery代码生成、一个端到端生成的开源模型、以及传统的手工建模作为对照。整个测试过程挺能说明问题的。

3.1 路线A：LLM+CadQuery，代码跑了三轮才修对

先说LLM生成CadQuery代码的方案。我用的通用大模型API，提示词就是上面那段话。第一版出来的代码很快，但执行时报错——问题出在它把“底面四角四个孔”的坐标计算错了：它默认底面的坐标原点在中心，但CadQuery的矩形草图默认从原点偏移，导致四个孔里有两个跑到了板子外面。

我把报错信息直接回喂给模型，让它自己修，它第二版改对了孔的位置，但又新引入了一个错误：把M8螺纹孔和φ6通孔的概念搞混了，草图上用的是φ8的通孔而不是螺纹孔钻底孔。第三版才基本正确，最终花了几分钟。

这个过程的结论很明确：LLM写CAD代码，本质上跟写其他代码一样，会犯“抽象概念混淆”和“坐标系考虑不周”的毛病。但它最大的好处是错误可迭代——有Python报错、有渲染预览图、有生成结果，每一轮反馈它都能理解并修正。

示例代码如下，示意最终能跑通的版本：

import cadquery as cq # 底面底座 base = cq.Workplane("XY").box(100, 80, 10) # 侧板：在底面长边的后侧向上拉伸 side = cq.Workplane("XZ").center(0, -40).box(100, 8, 50) # 合并两个实体 part = base.union(side) # 底面四角通孔 for (x, y) in [(-45, -35), (45, -35), (-45, 35), (45, 35)]: part = part.faces(">Z").workplane().center(x, y).hole(6) # 侧板中心M8螺纹底孔（6.8mm） part = part.faces(">Y").workplane().center(0, 25).hole(6.8)

注意M8螺纹底孔要打φ6.8还要攻丝，这是加工知识，模型能理解但常会漏。

3.2 路线B：端到端生成模型，10秒钟出结果但没法用

接着我跑了一个基于Text2CAD数据集思路的端到端生成模型。输入同样的文本，大概十来秒它就返回了一个STEP文件。迫不及待打开一看，整体轮廓确实“像”那么回事：L型的形状能看出来，侧板上也有个孔洞。但放大检查就露馅了：

首先，尺寸是“意思意思”的——底面标注虽然不是100×80，但也接近，可这不是精确值，模型把“100”理解成了模糊的“大”；其次，四个孔的位置明显不对称，孔距跟文本描述对不上，孔径也不是φ6；更致命的是，这个模型导出后没有任何特征树，就是一团B-Rep几何。我想改其中一个孔，唯一的办法就是重新生成整个模型。

这种方案现在最适合的应用场景是概念预览——设计师想快速看看“这个形态大致长什么样”，让脑子里的想法有个三维参照。但距离“进入CAD系统当零件用”，还差着工程精度、特征语义、可编辑性三大步。

3.3 路线C：手工建模对照，给AI的“快”祛魅

作为对照，我请一位熟练的工程师用传统CAD软件手动建同样的支架，结果他花了大概四分钟——比AI第一次代码运行还快一点，而且质量和可编辑性完全可控。

这个对照实验让我对text-to-cad的定位有了更清醒的认识：对于这种简单规则零件，AI目前并不具备效率优势；它真正的潜在价值在于那些“参数化家族零件”的批量变型，比如同一个支架要出几十种尺寸组合，让AI改代码参数去生成，比人一个一个手工改要快得多。

三条路线的实测对比汇总：

4. 真正卡住落地的四个瓶颈：精度、数据、可编辑性和工程验证

实测下来，我对text-to-cad的现状有了几个比较扎心的判断。它距离真正的工程可用，还差着四个层面的硬骨头。我之前看过很多AI产品演示，视频里模型转得飞起，觉得特别惊艳；但镜头一转，真正下产线的还是那些经过几代人验证的图纸。为什么？就是这四个瓶颈没有解决。

4.1 语言天生模糊，而制造需要毫米和公差

工程图纸是拿“数字+公差”说话的：一个孔的直径是φ8.1H7，代表基孔制公差带，孔径必须落在8.1到8.0的范围内；螺纹孔M6要不要有沉孔、沉孔直径深度多少、孔底是否有避让，全都有明确要求。而自然语言描述通常只有“φ8孔”“安装孔”这种松散表达。

这带来一个很现实的问题：就算text-to-cad生成的模型拓扑完全正确、形状完全吻合，缺失的公差信息也会让它直接卡在图纸审核环节。文本里没说倒角，模型就没有倒角；没说公差的孔，加工出来也不一定满足装配功能。目前的所有技术路线，都默认“按标称尺寸生成”，但工程需求往往是“既要标称尺寸，又要公差范围”，这一块的语言表达和信息建模还几乎是空白。

4.2 训练数据的“天花板”决定了模型的上限

AI模型的水平高度，很大程度取决于标注数据的质量和规模。目前text-to-cad领域最有影响力的公开数据集之一是Text2CAD，它从公开CAD数据集中整理出约17万到18万个模型，并为每个模型配套多条文本描述指令。

听起来数量不少，但细细深究有几个问题。第一个问题是数据来源单一——大部分模型是简单的机械零件和基本体素结构，它们来自开源CAD库和参数化建模数据集，复杂装配体、钣金件、曲面造型件严重不足。第二个问题更关键：很多文本描述是用模板和规则生成的，例如“创建带有n个圆孔的矩形板”，这种表达跟工程师日常口语“这里开一排孔，孔距别太小”根本是两回事。模型在“考试题”里学到的语言风格，和真实使用场景的语言风格存在明显gap。

数据这关不过，模型的上限就被焊死了。这也是为什么我坚持认为，目前做应用层的人，与其执着于训练自己的端到端模型，不如把精力花在构建垂直领域的语言-参数映射数据上，这可能才是回报率更高的地方。

4.3 生成模型的“可编辑性”，比几何精度更致命

前面实测部分提到，端到端生成出的模型因为没有特征树，可编辑性几乎为零。这一点在设计协作中是致命的。

CAD设计并非一锤子买卖，而是一个反复迭代的过程。设计师拿到一个模型，第一件事通常是改尺寸、改特征、调整顺序。即使AI一步到位生成了一模一样的实体，如果没有生成过程（特征树），下游任何一个人都只能把他当“死模型”用，没法改。而传统的参数化模型，只要特征树清晰，任何尺寸修改都是秒级响应。

所以在现阶段，“LLM写代码再执行生成参数化模型”这条路其实占了结构性优势：代码本身就是特征树的另一种形态。你只要把代码当模板，改数值重新运行，效果等同于在CAD里改特征参数。这也是为什么我会给团队极力推荐CadQuery、build123d这类程序化建模工具作为落地方向的核心原因。

4.4 “看着对”不等于“能加工”：工程验证这道关绕不过去

我见过的最扎眼的一句话是：“AI生成快了，人工审核慢了。”端到端模型10秒生成一个STEP文件，看起来效率惊人。但把这个文件投入后续流程之前，你还得做一系列检查：几何是否符合预期、是否有自相交面、导出格式是否兼容下游软件、有没有水密性问题影响网格划分、加工工艺上孔和螺纹是否合理、表面粗糙度/余量/热处理标记放哪……这些工程验证的成本，目前并不比重新建模一次低。

所以我认为，在比较各条技术路线时，永远要把“生成之后的验证和修正成本”算进总成本。不算验证成本的快，是没有意义的快。

5. 那现在到底能怎么用：基于现状的三类落地建议

聊完卡点，也还是要回到“能做点什么”。这半年来我自己在实践里摸索出几个还算靠谱的使用姿势，分别适合不同人。

5.1 如果你是工程师：把AI当“会写代码的实习生”，而不是设计师

经过这段时间的使用，给我最大的感受就是：AI在CAD里速写一些基础分析不太行，但作为正交方向的好助手是合格的。立个任务给它是“把这张图纸的零件用参数化方式建出来”，然后你来做工程师该做的判断。

推荐的落地姿势是：用通用大模型生成CadQuery或build123d代码，在本地跑通后，把代码保存成模板文件，命名好，纳入你的参数化零件库。下次遇到同类型零件变型，直接改代码里的尺寸参数，几分钟出一个新版模型。

我自己现在就是这么做非标件的。遇到一个法兰支架的变型需求，直接在模板代码里改外径、孔数、分布圆直径，重新渲染，然后导出STEP格式丢给下游。整个过程里，AI的角色不是“生成零件”，而是“帮我写好了改参数用的建模脚本”。改完以后要不要调整钻孔位置、要不要考虑加工变形，才是设计师真正该花时间的地方。

5.2 如果你是开发者：优先做“语言到API调用”而不是“语言到几何”

如果你是想做一款工具产品的开发者，我给的建议是：别一头扎进训练自己的几何生成模型里（成本和风险极高），而是去做“自然语言到程序化建模API的调用层”。

什么意思？就是用一套日常用语，识别出用户真正要的参数（长宽高、孔径、孔数、倒角、材质、螺纹规格），再把这些参数注入到CadQuery/build123d的模板代码里。识别参数这件事，大模型做得比几何生成好得多，可靠得多。

再进一步，可以接企业零件库：语言输入先解析参数，去库里检索最接近的标准件，再通过LLM对比差异，输出“要么直接调用标准件，要么提供参数修改建议”。这套逻辑我用下来，比从零生成一个零件要稳不止一个数量级。

5.3 分清text-to-cad的适用边界：概念设计、标准件变型、教学示例

最后，给所有想尝试的人一个清晰的边界感：

• 适合：概念设计早期的形态探索（端到端生成出形状参考）；标准件/常用件的参数化变型（LLM+代码模板）；教学场景里的建模示例生成；企业内部零件库的检索增强。
• 不适合：需要严格公差控制的关键零部件；复杂曲面/自由造型（如汽车A面）；需要多实体装配关系的复杂机构；对可编辑性要求极高的核心件设计。

在这个边界内使用，text-to-cad能实打实帮到你；超出边界硬上，只会增加返工成本。

最后分享一个我自己的小经验：无论用哪条技术路线，生成的模型我都会做一次统一的“入库前检查”——先转成STEP格式，在专业CAD里打开，用检查实体功能验证水密性；再看特征树/代码里有没有明显不合理特征（比如悬空面、贯穿了不该贯穿的壁）；最后核对一遍所有关键尺寸是否符合图纸要求，检查完再归档到常用件库。这套流程下来，踩坑的概率能降一大半。

text-to-cad这个方向，最有价值的地方其实不是“代替设计师”，而是把设计师从重复的参数调整里解放出来。顺着这个思路用，你会发现它远比演示视频里那个“一句话生成零件”的噱头更实用。