企业官网建设流程全解析

1. 从一段文字到三维实体：text-to-cad 到底在解决什么问题

第一次听到 "text-to-cad" 这个词，很多人会下意识觉得它是个噱头——输入一句话，电脑就吐出一个能直接加工的模型？这听起来像是把设计师十几年的手艺压缩成一次回车键。但如果你真的在机械设计、工业建模或者 3D 打印这条线上待过，就会明白它瞄准的痛点非常具体：从"想法"到"可编辑几何体"之间那段最枯燥、最重复、最容易出错的建模劳动。

传统流程是这样的：客户或工程师用文字描述需求，比如"一个 80×60×40 的底座，四角各有一个 M6 沉头孔，中心开一个直径 30 的通孔"。设计师拿到这段话，打开 CAD 软件，画草图、拉伸、打孔、倒角，一步步把文字翻译成几何。这个过程里，文字描述本身是精确的，但翻译动作是手工的，一个尺寸看错、一个约束漏加，后面全盘返工。text-to-cad 想做的，就是把这段"翻译"自动化——让文字描述直接生成参数化的 CAD 模型，输出成 STEP、GLB、STL 这些通用格式，再交给下游去做渲染、仿真或者打印。

它适合谁？我梳理了三类人。第一类是做参数化零件批量设计的工程师，比如标准件库、法兰、支架这类结构高度重复、只是尺寸不同的零件，用文字驱动生成比手动画快一个数量级。第二类是3D 打印玩家和创客，脑子里有个简单结构，不想学 SolidWorks 的完整操作，只想快速拿到一个 STL 去切片。第三类是做 AI 辅助设计工具开发的程序员，需要理解 text-to-cad 的技术链路，把它集成到自己的产品里。

关键词里出现的 STEP、GLB、STL 不是随便列的，它们代表了三种截然不同的下游用途。STEP 是精确的边界表示（B-rep）格式，保留完整的曲面和实体信息，是 CAD 软件之间交换数据的标准，能继续编辑；GLB 是 glTF 的二进制版本，主打轻量化和 Web 渲染，适合做可视化展示；STL 则是三角网格，只描述表面形状，丢了拓扑和参数信息，但几乎所有 3D 打印机和切片软件都认它。理解这三者的区别，是理解整个 text-to-cad 工作流的前提——你生成的不是一个"模型"，而是根据用途选择的一种几何表达。

这篇文章我会把 text-to-cad 从输入到输出的完整链路拆开讲：文字怎么变成结构化参数，参数怎么变成几何，几何怎么导出成不同格式，以及我在实际跑这类流程时踩过的那些坑。不管你是想自己搭一套，还是想评估现成工具能不能用，这些内容应该都能帮上忙。

2. 文字描述如何被"翻译"成可计算的几何参数

2.1 自然语言里的尺寸信息为什么难提取

很多人以为 text-to-cad 最难的是建模，其实真正的地狱在第一步：把一段人话解析成机器能用的结构化数据。人说话是带省略、带歧义、带行业黑话的。"打个 M6 的孔"——M6 是公称直径 6mm 的螺纹孔，但到底是通孔、盲孔还是螺纹底孔？沉头还是平头？这些信息在口语里经常被省略，因为说话的人默认对方懂。

我做过一个统计，在真实的零件描述文本里，大约 40% 的关键几何信息是隐含的，需要靠领域知识补全。比如"四角各一个孔"，隐含了"孔关于中心对称分布"；"底座"隐含了"有一个大平面作为安装基准"。如果解析器只做字面匹配，生成的模型十有八九不能用。

所以一个靠谱的 text-to-cad 前端，通常不是单纯的大语言模型直接输出坐标，而是大语言模型负责语义理解，规则引擎负责几何约束补全。模型先把"80×60×40 的底座，四角 M6 沉头孔，中心直径 30 通孔"解析成一个中间表示，类似下面这种结构：

{ "type": "plate", "dimensions": {"length": 80, "width": 60, "height": 40}, "features": [ {"type": "hole", "pattern": "corner", "count": 4, "diameter": 6.6, "countersink": {"diameter": 12, "angle": 90}}, {"type": "hole", "position": "center", "diameter": 30, "through": true} ] }

注意这里 M6 沉头孔我写的是直径 6.6 而不是 6。这是实操里的一个关键细节：M6 螺栓的通过孔标准直径是 6.6mm（中等级配合），不是 6mm。如果你按 6mm 生成，螺栓根本插不进去。这种"文字到实际尺寸"的映射，就是规则引擎要干的活。类似的知识还有：M3 通孔 3.4mm、M4 通孔 4.5mm、M5 通孔 5.5mm，沉头角度默认 90 度，这些都得内置成一张对照表。

2.2 中间表示层：为什么不能直接生成坐标

有人会问，既然大语言模型这么强，为什么不直接让它输出顶点坐标或者三角面片？我试过这条路，结论是：能跑通，但不可用。

直接生成坐标的问题在于，大语言模型对数值的精确控制能力很差。你让它生成一个 80mm 的边，它可能给你 79.8 或者 80.3，因为它本质上是在做概率预测，不是在算数。而且一旦模型有几十个特征，坐标之间的约束关系（比如孔必须在面上、面必须平行）很容易被破坏，生成出来的东西看着像那么回事，一测量全是错的。

中间表示层的作用，就是把"语义"和"数值"分开。大语言模型只负责把文字变成"有哪些特征、特征之间什么关系"，具体的数值计算交给确定性的几何内核。这样即使模型理解错了语义，至少数值是精确的；而语义错误可以通过规则校验和人工确认来兜底。

这个思路其实和编译器很像：源代码（自然语言）先编译成中间代码（IR），再由后端生成机器码（几何）。中间表示层就是那个 IR，它屏蔽了自然语言的模糊性，又保留了足够的语义信息供后续处理。

2.3 参数校验：那些必须拦下来的错误输入

解析完之后不能直接建模，中间必须有一道校验。我踩过最惨的一次坑，是用户输入"直径 200 的孔"打在一个"100×100 的板"上——孔比板还大，几何内核直接报错崩溃。后来我加了一套校验规则，至少拦住这几类问题：

提示：单位问题是最隐蔽的坑。用户写"2 寸管"，你按 2mm 处理，出来的东西完全不能用。我的做法是在解析阶段就强制要求带单位，没带单位的按默认 mm 处理并在结果里显式标注，让用户能一眼看到。

这套校验看起来繁琐，但它把大量错误挡在了建模之前，比生成完再让用户去 CAD 里发现要友好得多。而且校验规则本身是可以积累的，每遇到一个新的错误类型就加一条，系统会越来越稳。

3. 几何内核选型：B-rep 还是网格，这是个路线问题

3.1 两种几何表达的本质差异

到了真正生成几何这一步，你会面临一个根本性的路线选择：用 B-rep（边界表示）内核，还是用网格（mesh）生成。这两条路出来的结果，用途完全不同。

B-rep 用数学曲面（平面、圆柱面、NURBS 曲面）来精确描述实体边界，一个圆柱面就是一个方程，不是一堆三角形。它的优势是精确、可编辑、体积小。你生成一个直径 30 的孔，它就是数学意义上的正圆，放大一万倍还是正圆。STEP 格式就是典型的 B-rep。缺点是计算复杂，布尔运算（比如打孔就是减法布尔）容易失败，尤其是特征多、曲面复杂的时候。

网格路线则是把实体表面离散成一堆三角形。STL 就是纯网格。它的优势是简单、稳定、下游兼容性好，几乎所有渲染引擎和 3D 打印机都直接吃网格。缺点是精度受三角面片密度限制，一个"圆孔"其实是多边形近似，而且丢了参数信息，想改尺寸只能重新生成。

我的经验是：如果你的下游是 CAD 编辑或 CNC 加工，必须走 B-rep；如果下游是 3D 打印或 Web 展示，网格就够了，而且更省事。GLB 虽然底层也是网格，但它带了材质和层级信息，适合做可视化。

3.2 主流几何内核的实操对比

真要做 B-rep，绕不开几个成熟内核。我把用过的几个列一下，都是工业界在用的：

• OpenCASCADE（OCCT）：开源里最完整的 B-rep 内核，STEP 读写、布尔运算、倒角圆角都有。Python 绑定是 pythonocc-core，上手快。缺点是布尔运算偶尔会失败，需要调容差参数。
• CGAL：计算几何库，布尔运算和网格处理很强，但 B-rep 建模能力不如 OCCT，更适合做几何算法而不是完整建模。
• Manifold：专门做网格布尔运算的库，速度快、结果稳定，适合网格路线的 text-to-cad。
• CadQuery：基于 OCCT 的 Python 参数化建模库，语法接近自然语言，非常适合做 text-to-cad 的后端。你几乎可以把中间表示直接映射成 CadQuery 的链式调用。

我目前最推荐的组合是大语言模型解析 + CadQuery（底层 OCCT）生成 + 按需导出 STEP/STL/GLB。CadQuery 的代码写起来像这样：

import cadquery as cq result = ( cq.Workplane("XY") .box(80, 60, 40) .faces(">Z").workplane() .rect(80, 60, forConstruction=True) .vertices().cboreHole(6.6, 12, 6) # M6 沉头孔 .faces(">Z").workplane() .hole(30) # 中心通孔 ) cq.exporters.export(result, "base.step") cq.exporters.export(result, "base.stl")

这段代码的可读性极高，几乎就是文字描述的直接翻译。这也是为什么我倾向于让大语言模型输出 CadQuery 代码而不是坐标——代码本身就是一种中间表示，而且天然可执行、可调试。

3.3 布尔运算失败的常见原因和绕法

B-rep 路线最大的坑就是布尔运算失败。我遇到过的情况包括：两个面恰好共面导致内核无法判断内外、倒角半径大于相邻边长度、孔的位置正好落在面的边界上。这些在数学上都是"退化情况"，内核处理起来很脆弱。

绕法有几个。第一，给特征之间留微小间隙或过盈，比如孔的位置稍微内缩 0.01mm，避免正好落在边界。第二，调整运算顺序，先做大的减法再做小的，减少中间状态的复杂度。第三，设置合理的容差，OCCT 的 fuzzy boolean 能容忍一定误差，但容差太大会导致几何失真，一般设在 1e-5 到 1e-4 之间。第四，失败时降级到网格路线，先保证能出结果，再提示用户 B-rep 生成失败。

注意：布尔运算失败不是 bug，是 B-rep 这种表达方式的固有特性。任何用 B-rep 的系统都会遇到，区别只在于有没有做好兜底。评估一个 text-to-cad 工具时，别只看它成功案例多漂亮，要看它失败时怎么处理。

4. 导出格式的门道：STEP、GLB、STL 各自适合什么场景

4.1 STEP：精确交换的代价

STEP（ISO 10303）是 CAD 界的"普通话"，SolidWorks、Fusion 360、中望 CAD、FreeCAD 都能读写。它保留完整的 B-rep 信息，导出的文件在另一个软件里打开，还能继续编辑尺寸、加特征。

但 STEP 有个容易被忽略的问题：不同软件对 STEP 的实现有差异。同一个文件，在 A 软件里打开是实体，在 B 软件里可能变成一堆曲面片。原因是 STEP 标准很宽泛，各家的导出器对曲面缝合、容差处理不一样。我的做法是导出时尽量用 AP214 或 AP242 协议，这两个对实体的支持最完整，兼容性最好。

另外 STEP 文件体积会比 STL 大不少，因为存的是精确曲面方程而不是三角面片。一个中等复杂度的零件，STEP 可能几 MB，STL 只有几百 KB。但这是值得的，因为信息密度完全不同。

4.2 STL：3D 打印的通用语，但精度要自己控

STL 只存三角面片，结构极简，所以兼容性无敌。但它的精度完全取决于三角化的密度，这个参数叫弦高（chord tolerance）或者偏差（deviation）。弦高设得小，曲面就细腻，但文件大；设得大，文件小但圆孔变成明显的多边形。

我一般这样设：做 3D 打印预览用 0.1mm 弦高，做最终打印用 0.02mm。一个直径 30 的孔，0.1mm 弦高下大概 60 个三角面，肉眼已经看不出多边形；0.02mm 下接近 200 个面，基本和理论圆无异。

STL 还分 ASCII 和二进制两种。ASCII 可读但体积是二进制的 5 到 6 倍，实际用一律选二进制。有些老软件只认 ASCII，那是历史遗留问题，现在没必要迁就。

4.3 GLB：给 Web 和展示用的轻量格式

GLB 是 glTF 的二进制打包格式，专为实时渲染设计。它和 STL 一样是网格，但多了材质、颜色、层级、动画这些信息。如果你的 text-to-cad 结果要在网页上展示、要给客户看 3D 预览，GLB 是最合适的。

从 B-rep 转 GLB 需要先三角化，再走 glTF 导出。CadQuery 和 OCCT 都能直接导出 GLB，但要注意坐标系——glTF 默认 Y 轴向上，而 CAD 通常 Z 轴向上，导出时得做一次旋转，否则模型在网页里是躺着的。这个坑我踩过，调了半天才发现是坐标系问题。

选格式的逻辑很简单：要改就 STEP，要打就 STL，要秀就 GLB。三者不是替代关系，而是同一个模型在不同阶段的三种形态。一个成熟的 text-to-cad 流程，应该能一键导出全部三种，让用户按需取用。

5. 把整条链路跑起来：一个可复现的最小实现

5.1 环境准备里最容易翻车的地方

要自己搭一套 text-to-cad，环境配置是第一道坎。我推荐的技术栈是 Python + CadQuery + 一个大语言模型 API。CadQuery 的安装有个经典坑：它依赖 OCCT，而 OCCT 的预编译包在不同平台上的可用性不一样。

在 Linux 上，pip install cadquery基本能一把过。在 Windows 上，建议用 conda 装，conda install -c conda-forge cadquery，因为 conda 的包把 OCCT 的依赖都打包好了，pip 有时候会缺 DLL。macOS 上 pip 也能用，但 Apple Silicon 和 Intel 的包不一样，装错了会报架构不匹配。

还有一个坑是 Python 版本。CadQuery 对 Python 版本比较挑，3.9 到 3.11 最稳，3.12 有时候会有依赖冲突。我一般直接用 3.10 建虚拟环境，省心。

5.2 从文字到 CadQuery 代码的提示词设计

让大语言模型输出可执行的 CadQuery 代码，提示词是关键。我试了很多版，最后稳定下来的结构是这样的：

你是一个 CAD 建模助手。用户会用自然语言描述一个零件，你需要输出一段可执行的 CadQuery Python 代码。 规则： 1. 所有尺寸单位默认为毫米（mm）。 2. 螺纹孔按标准通过孔直径处理：M3=3.4, M4=4.5, M5=5.5, M6=6.6, M8=9。 3. 沉头孔默认 90 度，沉头直径按标准：M6=12, M8=16。 4. 代码必须以 result 变量结尾，result 是 cq.Workplane 对象。 5. 不要输出任何解释文字，只输出代码。 6. 如果描述有歧义，选择最常见的工程解释。 用户描述：{user_input}

这个提示词里，规则 2 和 3 就是前面说的"领域知识补全"，把它写进提示词比写在代码里更灵活，改起来方便。规则 6 很重要，它让模型在信息不全时有个默认行为，而不是卡住或者瞎猜。

实测下来，这套提示词对简单零件（板、轴、支架）的首次生成成功率大概在 80% 左右，剩下的 20% 主要是描述太模糊或者特征太复杂。失败的时候，把错误信息反馈给模型让它重试，通常两三次能收敛。

5.3 生成结果的自动验证与人工确认

代码生成出来不能直接信，得跑一遍验证。我的验证分三层：

第一层是语法和运行验证，直接 exec 代码，看有没有异常。这一步能拦住大部分低级错误。

第二层是几何验证，检查生成的实体是不是有效的（valid solid）、体积是不是正数、包围盒尺寸是不是和描述一致。CadQuery 的result.val().isValid()能查有效性，result.val().Volume()能查体积。

第三层是尺寸抽检，从模型里提取关键尺寸和描述比对。比如描述说"80×60×40"，就查包围盒是不是这三个数。这一步能发现模型理解偏差。

三层都过了，再输出给用户确认。用户看到 3D 预览，确认没问题，再导出最终格式。这个"生成-验证-确认"的闭环，是把 text-to-cad 从玩具变成工具的关键。

6. 实战中那些文档不会写的坑

6.1 中文描述的解析比英文难在哪

如果你的用户用中文描述，难度会上升一个台阶。中文的工程表达有几个特点：量词和单位经常省略（"打个 6 的孔"）、方位词模糊（"边上"到底是哪条边）、专业术语和口语混用（"沉孔"和"沉头孔"是一回事）。

我的处理办法是建一个同义词映射表，把常见的口语表达映射到标准术语。"打个孔"→"hole"，"挖空"→"cut"，"倒个角"→"fillet"，"圆角"→"fillet"，"倒角"→"chamfer"。这个表是慢慢积累的，每遇到一个新说法就加一条。另外中文数字和阿拉伯数字要统一处理，"六个孔"和"6 个孔"得解析成一样。

还有一个隐蔽的坑是全角和半角。用户输入"直径３０"用的是全角数字，直接解析会失败。预处理阶段统一转半角，能省很多事。

6.2 复杂模型的性能瓶颈在哪

简单零件（几个特征）生成很快，几秒钟的事。但特征一多，性能会断崖式下降。我测过一个有 50 个孔的板，布尔运算花了将近 30 秒。瓶颈在 B-rep 的布尔运算，每加一个孔就是一次减法，50 次减法累积起来很慢。

优化思路有两个。一是合并相同特征，50 个孔如果直径一样，可以用阵列（pattern）一次生成，而不是循环 50 次布尔。CadQuery 的rarray或者polarArray就是干这个的。二是延迟布尔，先把所有孔的位置算好，最后一次性做布尔，而不是边加边算。OCCT 对这种批量操作有优化。

如果实在慢，还有个降级方案：先生成网格版本给用户看预览，B-rep 版本后台慢慢算。用户看到预览确认了，B-rep 也差不多算完了。这个体验比干等 30 秒好得多。

6.3 生成结果的"看起来对"和"真的对"

这是我最想强调的一点。text-to-cad 生成的东西，视觉上正确和几何上正确是两回事。一个孔位置偏了 0.5mm，在屏幕上根本看不出来，但装配的时候就是装不上。一个面其实有 0.01mm 的缝隙，渲染时看不出来，但导出 STEP 后下游软件会报"非实体"。

所以验证不能只靠眼睛看。我的做法是：关键尺寸必须用程序提取出来和输入比对，不能靠人眼。包围盒、孔径、孔位、壁厚，这些能量化的都量化。人眼只负责看整体形状对不对，精确性交给程序。

提示：如果你在做面向生产的 text-to-cad，建议加一个"尺寸报告"功能，把生成模型的所有关键尺寸列出来，让用户逐项确认。这个功能看起来笨，但能避免大量返工。

7. 这套东西的边界在哪，以及怎么继续往下走

text-to-cad 现在的能力边界很清楚：它擅长规则明确、结构重复、参数驱动的零件，不擅长自由曲面、有机形状、需要审美判断的设计。你让它生成一个带复杂曲面的外壳，它做不好；你让它生成一百个尺寸不同的法兰，它做得又快又准。

所以定位很重要。别把它当成"替代设计师"的工具，把它当成"把设计师从重复劳动里解放出来"的工具。设计师的价值在于判断该做什么形状，text-to-cad 的价值在于把这个形状快速、精确地变成几何。

我自己在实际项目里的体会是，这套流程最舒服的用法是**"文字生成初稿 + 人工微调"**。让 text-to-cad 生成一个 80% 可用的模型，设计师在 CAD 里花几分钟调整剩下的 20%，比从零开始画快得多。纯自动化的全流程，目前还只在很窄的场景里可行。

后续可以扩展的方向，我觉得有两个值得关注。一是和参数化设计结合，生成的模型不是死的，而是带参数的，改一个尺寸整个模型跟着变。二是多模态输入，除了文字，还能接受草图、参考图，甚至语音，让输入方式更自然。这两个方向都在快速演进，值得持续跟进。

最后分享一个小技巧：如果你只是想快速验证一个想法，不需要精确的 B-rep，直接用网格路线（Manifold 或者 trimesh）生成 STL，几秒钟就能拿到结果去打印。等验证完了，再回头用 B-rep 做精确版本。先跑通，再跑准，这个顺序能帮你省下大量时间。