企业官网建设流程全解析

1. 一句自然语言，凭什么能变成可编辑的三维模型

如果你在工位上接过这样的需求：同事发来一段话，“帮我建个法兰盘，外径80，内径25，厚度10，中心孔周围有个2mm高的凸台，螺栓孔6个均布，分度圆直径60”，然后你打开CAD软件，从草图、拉伸、打孔一路做到下班。那你应该能立刻理解text-to-cad这个方向的价值——它想做的事情，就是让上面这种“语音转需求”的场景，直接变成“文字转模型”，而且转出来的不是一张“看起来像”的图片，不是STL网格，而是一份带参数、带特征历史、能继续改孔改尺寸的完整CAD文件。

我在本地搭过好几套不同技术栈的text-to-cad原型，从早期玩票式地让大模型直接输出STL，到后来老老实实让大模型写参数化脚本，中间踩的坑比想象中多得多。这篇文章想把这些经验整理出来，包括技术路线为什么绕不开“脚本生成”这条老路，落地时哪些环节最容易翻车，以及我是怎么把一套能跑通的链路搭起来的。适合正在做CAD自动化、做AI设计和工具集成的人参考，也适合那些想给自己的3D打印、非标设计流程提效的工程师。

先说一个经常会误导新人的点：text-to-cad不是“文字生成图片”套了一层CAD皮。图片生成追求视觉合理性，网格可以有瑕疵、可以夸张比例，但CAD模型是要拿去加工、拿去装配、拿去出工程图的，它必须精确到小数点后至少两位，必须能被选中面、改草图的尺寸，必须是一棵可回溯的特征树。哪怕你只想要一个3D打印的手柄，你也希望回去改改圆角半径，而不是重新生成一遍。所以“能生成什么”和“能不能被工程师接受”之间，隔着一整条野路。

我最后跑通的方案，本质上是一个组合拳：先用大语言模型把自然语言需求拆解成结构化参数和特征顺序，再让它生成一段CadQuery脚本，最后由OpenCASCADE内核执行这段脚本并导出STEP。整个过程跑下来，一个中等复杂度的机械零件，从文字到可用模型，稳定的话两分钟之内能完成；不稳定的时候，它会给你演示什么叫“一本正经地胡说八道”，让你深刻体会到AI建模离全自动还差着一段必须由人来兜底的路。

2. 为什么技术路线选的是“生成建模指令”，而不是直接生成网格

2.1 CAD和Mesh的底层差异：一张照片和一份可编辑工程图的区别

很多人第一次接触text-to-cad时，会下意识想到扩散模型、点云生成、神经辐射场那一套。这些技术在生成图片和3D扫描重建上确实猛，但放在CAD领域就水土不服，原因不是你模型不够大，而是输出的数据格式，从根上就不是CAD的菜。

一张STL网格，本质是一堆三角形的顶点和法线，它记录了“表面长什么样”，但没有记录“这个面为什么在这里”“这个孔是通孔还是盲孔”“倒角半径是多少”。你拿到一个STL法兰盘，想改内孔从25变成30，不好意思，你得重新雕刻网格，或者走一遍逆向建模流程，那活儿的痛苦程度堪比让设计师用像素画板画画。

CAD模型的底层是B-Rep（边界表示），更关键的是它带着特征历史树——拉伸、切除、倒角、阵列、镜像，每一步都是可回放的“操作记录”。所以text-to-cad如果只输出一个光秃秃的网格，那它解决的只是“可视化”问题，不是“建模”问题。工程上要的不是一张好看的照片，而是一份能拿回去改尺寸、更新装配关系的“原文件”。

这也是为什么我一开始就排除了“用扩散模型直接生成网格”的路线。你让扩散模型画一个法兰盘，画出来十有八九是视觉上很圆润、孔位很对称的漂亮网格，但真要导入Fusion 360再编辑一次，全部特征都变成“网格化实体”，修改自由度几乎为零。换句话说，它像一个能说会道但不会画施工图的乙方，交付物漂亮，但不顶用。

2.2 现在真正在跑的几条路：从“直接生成网格”到“生成脚本”

我翻了从论文到开源项目到商业工具的一大圈之后，把text-to-cad的技术路线归成下面四类，实际选型时基本绕不开这个四分法。

第一条，文本转图像再转网格。典型玩法是先从文字生成多视角图，再通过单目重建或点云拟合得到几何体。这条路胜在通用，理论上什么形状都能“编”出来，但输出基本没有参数化信息，曲面拟合也是靠猜，精度勉强够做概念示意，不够做加工。

第二条，直接训练模型输出CAD操作序列。把构建历史当成自然语言一样去训练，模型一个token一个token地吐“创建草图、拉伸30mm、打孔”。这个方向学术界很热，因为理论上最接近真实建模行为。但它的问题在于训练数据极难搞——需要大量带完整特征树的CAD源文件，而且操作序列的排列组合复杂度远高于自然语言，模型很容易在前面几步就崩掉，目前离工程可用还有距离。

第三条，让大语言模型生成CAD脚本，再交给传统内核执行。给LLM一个目标格式，比如CadQuery、OpenSCAD、FreeCAD的Python API，让它把文字需求翻译成代码，脚本跑出来的结果直接就是带特征历史的B-Rep模型。这条路线没有重新发明建模轮子，而是把LLM当成一个“翻译官”，翻译成本被大幅压缩。

第四条，文本转点云或深度图，再逆向拟合成CAD曲面。相当于多了一条信息中间层，比文本直接跳模型更容易对齐语义，但拟合出来的往往是NURBS曲面块，不是工程师习惯的拉伸、旋转、倒角特征，后续修改依然要重新“伺候”一遍曲面。

2.3 我为什么最终选了CadQuery + 大模型脚本生成

综合对比下来，上面第三条路是我能最快跑通、且交付物最满足工程要求的方案。原因很现实：LLM最擅长的事情之一就是写代码，而CadQuery的代码本身读起来就和自然语言非常接近。你看下面这段：

import cadquery as cq result = ( cq.Workplane("XY") .circle(40) # 外径80mm .extrude(10) # 厚度10mm .faces(">Z") .hole(25) # 中心孔内径25mm )

就算你没写过CadQuery，也能猜出这个模型是什么形状。对LLM来说，这种“用英语写建模指令”的任务天然比直接生成B-Rep数据要顺手得多。另一个原因是后端内核成熟：CadQuery基于OpenCASCADE，生成的实体就是标准的B-Rep，可以导出STEP、STL，可以和主流CAD软件互通，也可以直接拿去做有限元仿真前置。

FreeCAD的Python API我也试过，它的接口比CadQuery更接近原生OCC，能力上限更高，但语法臃肿、容易把LLM绕晕；OpenSCAD的文本语言对布尔运算友好，但圆角、倒角、复杂放样这些操作写起来就费劲。最后我的选择很明确：复杂曲面和装配级应用交给专业CAD软件，text-to-cad原型统一用CadQuery做主力输出格式，因为它的“脚本即特征历史”属性最适合让大模型发挥。

3. 从文本到CAD的完整落地链路：环境、数据与核心流程

3.1 环境准备与工具清单：别在安装这一步就卡住

整个链路不复杂，但环境依赖处理不好会浪费半天时间。我按可复现的方式把工具列一下：

• Python 3.10以上，建议用虚拟环境隔离，别直接装进系统Python
• CadQuery，负责把脚本变成B-Rep实体，它装完会自带OpenCASCADE内核
• trimesh，用于把STEP或STL加载进来做快速体积、水密性检查
• 一个大语言模型，闭源API或本地部署都可以，关键是代码能力要强，小模型写CadQuery经常漏括号
• 一个简单的文件输出模块，把生成的STEP按零件编号归档

安装命令在这里：

pip install cadquery pip install trimesh

如果你在Windows上装CadQuery，耐心等它拉预编译的OCC包就行，体积挺大但基本不会失败。Mac M系列芯片我踩过坑，需要先确保有可用的OpenCASCADE依赖，实在不行就换Docker跑，反而省心。

3.2 提示词结构比“模型聪明”更关键

很多人一上来就给大模型丢一句“生成一个法兰盘”，然后抱怨输出质量差。这其实跟CAD做图一样，你给需求方一张白纸，他怎么知道你要什么。我试了几十轮之后，固定下来一套自己的提示词模板，效果稳定很多。

我要求模型始终按照四个区块输出：

1. 需求理解：把用户文本里的尺寸、特征、约束提取出来，列成结构化清单
2. 建模思路：用自然语言描述特征的先后顺序
3. CadQuery代码：只输出一个代码块，不要夹杂解释
4. 自检说明：指出输出里哪些尺寸可能是猜测的，哪些特征存在歧义

比如你输入“做一个带6个螺栓孔的法兰盘”，模型会先给你列：外径多少、厚度多少、孔分度圆直径多少，如果没有给就明确标记为“猜测值”。这一步太重要了。CAD建模最怕的不是模型不会画，而是模型默认了某个尺寸，你却毫不知情。

3.3 核心流程与自检回路：生成脚本只是开始

我的完整处理流程是一个五段式回路，缺一不可：

• 文本解析：从自然语言里抽取实体类型、关键尺寸、特征列表、约束关系
• 脚本生成：让大模型按提示词模板输出CadQuery代码
• 内核执行：运行代码生成实体，捕获异常和警告
• 几何校验：检查实体是否有效、体积是否合理、孔的数量对不对
• 反馈迭代：如果校验不过，把错误信息回灌给模型，让它修正重试

这里最容易被忽略的是“反馈迭代”。很多人跑一次生成就放弃了，觉得模型不行。实际上，让模型看到报错信息再改，成功率会直线上升，就像代码调试，没人规定第一版必须能编译通过。我实测下来，一个中等复杂零件，平均需要1到2次修正才能达到可用状态，第一次就完美的情况大概只有四成。

下面这段代码是我用来做几何快速校验的简化版：

import cadquery as cq from pathlib import Path def build_flange(): result = ( cq.Workplane("XY") .circle(40) .extrude(10) .faces(">Z") .hole(25) ) return result model = build_flange() solid = model.val() print("体积:", solid.Volume(), "mm^3") print("是否有效:", solid.isValid()) bbox = solid.BoundingBox() print("长:", bbox.xlen, "宽:", bbox.ylen, "高:", bbox.zlen)

校验逻辑不复杂，但能筛掉大部分明显翻车的生成结果。比如模型生成的实体体积出现负值、边界盒尺寸和预期完全不符，或者实体有效性校验直接报false，这种情况基本不用看细节，直接让模型重新生成就对了。

4. 实测拆解：让模型生成一个法兰盘的完整记录

4.1 输入描述与约束拆解

为了让你直观感受这条链路跑起来是什么效果，我用一个实际例子过一遍。用户原始输入是：“外径80mm、内径25mm、厚度10mm，中心孔周围做一个2mm高的凸台，凸台外径30mm；法兰平面均布6个直径8mm的螺栓孔，螺栓孔分度圆直径60mm。”

这段描述在人类工程师眼里几乎没有歧义，但模型不一定。我先让LLM做需求拆解，它输出的结构大概是这样：

• 主体：圆柱体，外径80，厚度10
• 中心孔：直径25，贯穿
• 凸台：以中心孔为轴线，外径30，高度2
• 螺栓孔：6个，直径8，均匀分布在直径60的分度圆上，角度间隔60度
• 特征顺序：先拉伸主体，打中心孔，再凸台拉伸，再凸台打孔，最后阵列螺栓孔

如果你直接用这句话去生成，大概率会得到一堆“看着对但实际错位”的结果。关键问题是特征顺序。如果先打螺栓孔再做凸台拉伸，凸台会盖住部分螺栓孔。让模型先把特征顺序列出来再写代码，这类低级错误会明显减少。

4.2 生成脚本与执行结果

整理并修正后的CadQuery代码如下：

import cadquery as cq result = ( cq.Workplane("XY") .circle(80 / 2) .extrude(10) # 主体法兰 .faces(">Z") .workplane() .hole(25) # 中心孔 .faces(">Z") .workplane() .circle(30 / 2) .extrude(2) # 凸台 .faces(">Z") .workplane() .hole(25) # 凸台内的中心孔 .faces(">Z") .workplane() .polarArray(60 / 2, 0, 360, 6) # 分度圆直径60，均布6个 .hole(8) # 螺栓孔 )

保存成flange_gen.py之后直接执行：

python flange_gen.py

输出会生成一个STEP文件，同时打印实体体积和有效性信息。我这边跑出来的时间大约0.6秒，非常快。真正的时间都花在LLM生成和修正脚本上，CPU执行CAD内核反而是整个链路里最不愁的一环。

4.3 模型可用性验证：别只看“像不像”

生成完不是结束，我会额外跑一遍几何检查，因为靠肉眼判断孔位对不对，很容易被渲染器骗过去。

solid = result.val() print("体积:", solid.Volume()) print("是否有效:", solid.isValid()) bbox = solid.BoundingBox() print("边界盒:", bbox.xlen, bbox.ylen, bbox.zlen)

这个模型的理论体积可以手算：主体圆柱体积约40212立方毫米，减去中心孔约3927，加上凸台环体积约 2π(15² - 12.5²)，再减去6个螺栓孔的体积，最后应该落在45750立方毫米左右。如果模型输出的体积偏差超过2%，我会判定生成有问题，直接回灌给模型调整。

孔的数量和分度圆位置，我会额外用代码检查：遍历实体上的圆柱面，统计直径8的孔数量是不是6个，直径25的孔是不是2个。这种自动化检查比肉眼靠谱得多，毕竟LLM最擅长干的事之一就是“少打一个孔但不告诉你”。

4.4 第一次实测的翻车现场：角度单位与特征顺序

我也不是一开始就跑得这么顺。印象最深的一次失败，是模型把polarArray里的起始角度从0度写成了math.pi/2，又把360写成了2 * math.pi。表面看没错，6个孔还是均匀分布，但实际上整组孔相对于法兰的相位转了90度。如果这是个需要和对接法兰配对的零件，装配时就会对不上螺栓孔。

另一个高频失败是特征顺序错乱。有一次模型先做了凸台拉伸再打中心孔，结果凸台上留下一个完整的圆孔，但主体上的孔和凸台孔中间出现了台阶面。从渲染图看似乎没问题，但实际加工时这个台阶面就是干涉隐患。所以我现在把“特征顺序”单独列为提示词必填项，并且要求模型在自检说明里逐条核对，直到“主体拉伸 > 主体孔 > 凸台 > 凸台孔 > 阵列孔”这个顺序完全正确才放行。

5. 目前阶段最容易踩的坑，和我的应对习惯

5.1 语义歧义：同一个“凸台”有无数种建模方式

CAD里的术语在不同人口中经常指不同的东西。“凸台”可以是圆柱凸台、矩形凸台、带斜度的凸台，甚至可以是旋转体凸台；“倒角”可以是等距倒角、不等距倒角或者圆角。LLM不会主动追问你是哪一种，它会按训练数据里的高频统计猜一个默认答案。我遇到过一次，用户说“做一个带凸台的底座”，模型生成了圆柱凸台，但用户其实想要的是矩形凸台。

应对办法很简单，别让模型猜。我在提示词里加了一个术语表，把“凸台=圆柱拉伸体，斜度默认0，倒角默认C1”这种约定写死，模型就不会自由发挥。如果需求方自己都说不清楚，那就让模型把所有理解成多个方案并输出，人再选一个，这比让它猜一个“看起来合理”的方案稳得多。

5.2 尺寸幻觉与单位问题

这是text-to-cad最让工程师抓狂的坑。同一个数字，模型可能有时理解成毫米，有时理解成厘米，甚至有时为了“形状好看”直接把某个尺寸偷偷改了。我遇到过模型把内径25写成了“25mm”结果实际生成时用了25英寸的逻辑，虽然输出文件里数字是25，但实体尺寸差了几十倍。

我的铁律是全项目统一单位，并且在提示词第一行写明：“所有尺寸默认毫米，只能是数字，不允许换算，不允许单位换算，不允许四舍五入。”如果用户输入“1cm”，我会让模型先换算成10mm，再写进代码，最后在自检说明里明确标出“原输入为1cm，已转换为10mm”。很多尺寸错误，不是因为模型不会换算，而是它懒得确认就自行发挥了。

5.3 特征顺序和布尔运算冲突

CAD建模像做菜，先后顺序错了味道就完全不对。最常见的错误是“先倒角后打孔”。如果模型先给某个边加了倒角，再打一个孔，孔和倒角的边界相交位置会出现诡异的曲面碎片，或者整个布尔运算直接失败。反过来，先打孔再倒角通常就没事。

我在校验环节专门加了一个“特征顺序检查器”，规则很简单：拉伸必须在切除之前，打孔必须在凸台之后，倒角必须放在所有影响面确定之后。如果生成的代码不满足这个约束，就标记为失败，让模型重写。这些规则听着笨，但自动化流程里没有这些笨规则，模型就会反复用同一个错误逻辑挑战你的耐心。

5.4 评估指标怎么定：不被“看起来像”迷惑

很多人给text-to-cad系统评价，一看渲染图觉得“很厉害”，就放过去了。这是大忌。工业场景要的是数值可验证的结果，我给自己定了一套最低通过标准：

这套标准不算苛刻，但能显著筛掉“看起来能用”的模型。事实上，很多生成结果连第一关都过不了，实体有效性直接就是False。所以如果你的text-to-cad流程里没有自动校验，那你就等于在高空走钢丝，全靠肉眼当安全网。

6. 把text-to-cad放进真实工作流后，我的几个变化

跑了大半年之后，我的建模习惯确实被改变了。最明显的一点是，以前接到一个非标零件的建模需求，我第一反应是打开CAD软件开始画草图；现在我的第一反应是先在文档里把需求描述写清楚，尺寸、公差、特征顺序、默认单位，全部结构化。因为如果这段描述能让LLM生成一个靠谱模型，那这段描述本身已经足够让我自己快速建模了。说白了，text-to-cad逼着我养成了“先定义清楚，再动手执行”的习惯。

第二个变化是建模时间分布完全变了。以前画一个中等复杂度的零件，画草图加拉伸加打孔加阵列，熟练工大概15到20分钟，其中有10分钟其实是在做机械性操作。现在让LLM生成加校验，稳定情况下3分钟以内能出一个版本，但校验和修正时间增加了。我每天做的不是“更快地建模”，而是“更快地判断这次生成是不是靠谱”。

第三个变化是协作模式。以前别人找我建模，要把需求写得很详细，我再翻译成CAD操作；现在同事只需要在群里发一段自然语言，我把它整理成结构化需求扔给模型生成，省掉了中间反复沟通的成本。当然，我依然会在关键尺寸和装配关系上自己过一遍，这种事没法偷懒。

最后说一个很实际的体会：你不需要等text-to-cad成熟到“输入一句话就得到精准能加工模型”再用。现在这个阶段，它已经能在标准件、结构件、简单壳体这类建模中帮你省掉大量重复劳动。它不稳定、会犯错、需要你兜底，但就像一个能帮你打草稿的实习生，方向感大致对，细节要你检查，用好了效率提升非常明显。如果你打算试，我最想提醒的就是：务必把校验环节做扎实，否则你省下的时间，都会在后期修改模型时加倍还回去。