企业官网建设流程全解析

在机械设计和数字制造这个圈子里，text-to-CAD 大概是这两年最值得跟的方向。回头看我最早的建模方式，画一个法兰盘要在 CAD 软件里点十几下：草图、约束、拉伸、打孔、再倒角；步骤不复杂，但架不住每个新零件都要重复一遍。text-to-CAD 的思路就不一样——它把“从图纸到特征”这层人肉翻译交给机器，让人只负责说需求，比如“外径 60 的盘体，中间一个通孔，四角四个 M4 沉头孔”，然后直接得到可以继续编辑的模型文件。这篇文章会把它的原理、主流实现路线和一套真实可跑的工作流讲清楚，适合做三维建模工具开发的工程师、长期被参数化建模折磨的机械设计师，以及玩 3D 打印但每次建模都要查半天文档的朋友。读完之后，你至少能自己搭一个“会建模的助手”，而不是停留在看论文听概念。

1. text-to-CAD 的思路拆解：把“看图建模”变成“听写建模”

1.1 传统 CAD 建模到底卡在哪

传统 CAD 建模的整个操作路径，本质上是“人把头脑里的三维意图翻译成二维输入序列”：从草图开始，画线、加约束、拉伸、旋转、扫描，每一步都在告诉软件“我现在要做什么”。这个过程有两个痛点。

第一，操作和思维之间隔了一层。设计一个支架，脑子里想的是“这个板要多厚、哪里该受力、哪里要避让”，但手在软件里做的是另一件事：画矩形、删线、标尺寸、切特征。每一层操作都在消耗注意力，建模速度完全取决于熟练度。熟练工能把手上的动作练成肌肉记忆，但代价是大量时间耗在重复劳动上；不熟练的人则卡在“知道要什么，但不知道点哪里”的困境里。

第二，知识门槛高。参数化建模不只是会用软件，还要理解约束是否过定义、草图是否闭合、特征顺序是否合理。对机械工程师还好，对创客、3D 打印玩家、甚至非标设备采购来说，想快速拿一个可打印的零件，第一步建模就能把你劝退。市面上的建模软件界面越来越复杂，功能按钮几百个，真正常用的其实就十来个，但新用户根本分不清哪些该点、哪些不该点。

text-to-CAD 想做的是把这两道坎都挪走。核心思路是用自然语言直接描述需求，再由模型把这句话翻译成 CAD 特征序列。注意这里用的词是“翻译”，不是“渲染”——它输出的不是一张图，而是一组合法的建模步骤，这些步骤能驱动 CAD 内核一步步构造出实体模型。

1.2 两条实现路线：端到端生成 vs 程序化参数建模

把“语言”变成“模型”听起来简单，但实现方式差别很大。市面上现在基本分成两条路线，我分别说一下它们的思路和适用场景。

第一条是端到端生成。这类系统直接训练一个神经网络，输入文本，输出几何体——可能是点云、网格，或者更高级一点的 B-Rep 边界表示。它的优点是想象力强，能生成一些没有明显参数规则的自由形状，比如有机形态的壳体、雕塑类造型。目前这类工作多出现在学术论文里，离工程落地还有明显距离。

第二条是程序化参数建模。这种路线不直接生成几何，而是让语言模型输出一段建模脚本，比如 CadQuery、OpenSCAD、FreeCAD Python 脚本，然后由脚本引擎执行生成实体。好处是输出的是可读的代码和特征序列，改一个尺寸能重新生成，而且天然兼容 STEP/STL 的导出链路。

1.3 为什么我推荐先做程序化路线

个人观点，现阶段做 text-to-CAD 的实际落地，程序化参数建模是性价比最高的选择。原因不复杂：CAD 模型的核心价值不在“长得像”，而在“能制造、能修改、能追溯”。一个生成出来不可编辑的面片，在工程师眼里约等于一张效果图；而一段能重新执行的 CadQuery 脚本，才真正进入了产品迭代的闭环。

这不是说端到端生成没有意义。自由曲面、概念造型这类场景，端到端确实更有优势。但如果你要做的是非标零件、标准件、机械结构件，脚本路线的确定性和可复现性是无价的。所以下面整篇文章的实操部分，我会沿着“自然语言 → CAD 脚本 → 实体模型”这条路展开，这也是我实测下来最快能跑通的方案。至于端到端生成，后面讲原理时也会提到，但不会作为主打路径。

2. 从表示到模型：text-to-CAD 背后的核心技术细节

2.1 几何表示：为什么 B-Rep 比网格更接近“制造”

要理解 text-to-CAD，必须先理解 CAD 自己怎么表示几何。市面上的 CAD 文件，内部主要用两类表示。

网格模型由三角面片拼接而成，适合渲染和 3D 打印切片，但缺乏面与面的拓扑关系，无法精确表示圆柱面、球面这些二次曲面。STL 文件就是典型的网格，拿到转换工具里往往会有精度损失。实体的边缘会被拆成无数小三角，圆孔变成多边形孔，这对注塑模具和精密加工来说不可接受。

B-Rep 则不同。它用顶点、边、面、环和它们之间的拓扑关系来描述一个实体，曲面可以是精确的解析曲面。SolidWorks、Fusion 360、FreeCAD 等主流 CAD 内核的核心都是 B-Rep 数据结构，这也是 STEP 文件能跨软件交换的根本原因。一个在某个软件里建出来的圆柱面，导到另一个软件里仍然是精确圆柱面，而不是近似的多面体。

对 text-to-CAD 来说，直接生成 B-Rep 很难，因为模型不仅要预测几何位置，还要保证所有边、面严格闭合、拓扑一致。这就是为什么多数研究型工作选择生成“命令序列”而不是直接生成面：CAD 软件本身也是通过特征命令一步步构造出 B-Rep 的。命令序列天然能保证实体合法，只要命令参数没写错，生成的实体就是一个可用的实体。

2.2 训练数据从哪来：十万级“模型-文本”对的背后

深度学习的规律就是这样，模型能力大概率取决于数据。text-to-CAD 的训练数据不是天上掉下来的，公开数据集主要靠三种渠道构建。

第一种是逆向标注。从已有的参数化 CAD 模型库出发，把模型的特征树翻译成自然语言，比如“一个长方体，长 40，宽 20，通孔直径 8 位于中心位置”，然后按模板生成描述文本。这种方式能快速得到大量配对数据，但描述往往偏模板化，缺乏真实人类表达的变化。

第二种是合成指令。用规则模板或者另一组语言模型生成多样化的自然语言表达方式，覆盖同一个模型的不同说法，比如“中间开一个 8 毫米的孔”和“在中心打一个直径为 8 的通孔”其实是同一个意思，但文本形态完全不同。提高多样性，是为了让模型在推理时能扛住用户千奇百怪的说法。

第三种是人工精修。在自动生成的基础上做筛选、纠错，补充那些模板表达不了的自由描述。人工精修的成本高，但质量也最高，往往是数据集中最宝贵的部分。

目前公开的 text-to-CAD 数据集，规模普遍在十万级“模型-描述”对以上。相比通用自然语言语料，这个规模仍然算小，所以模型在这种任务上更容易过拟合模板，这也是实操中常见“换个说法就翻车”的根源。

2.3 模型架构：从自回归生成到扩散模型

现有模型架构主要沿着两个方向发展。

自回归方向最直观：把建模脚本当成一段“程序语言”，按 token 顺序预测下一个命令。这种思路和代码生成一脉相承，许多实现直接基于 Transformer 解码器，配合语法约束做采样。优点是可以直接借用代码大模型的预训练知识，缺点是生成较长脚本时容易累积误差，后面命令对不上前面的状态。

扩散模型是另一个方向。扩散在图像生成领域已经是主流，现在有人尝试把它引入 CAD，但 CAD 的难点在于输出必须是离散、结构化的特征树，而不是连续像素。目前能看到的效果更多集中在简单零件上，离复杂装配体和自由曲面还有距离。几何生成这类结构化输出，本质上比像素生成更难建模。

我实测下来，对于普通机械零件，自回归式的 LLM 配合脚本输出，效果远比端到端网络稳定。原因很简单：通用代码大模型已经见过大量参数化建模代码，它有足够的世界知识去理解“法兰盘”“沉头孔”这些概念，只是需要我们去规范它的输出格式。

2.4 命令序列：可编辑性的源头

命令序列这个表示还有一个常被忽略的优点：可追溯和可参数化。一段 CadQuery 脚本里，“外径 60”对应清晰的一行代码，后续要改成 80，改一个数字就可以重新生成。这在制造业里太重要了。

工程师拿到一个模型，第一件事往往不是看它外形对不对，而是看特征树——拉伸在哪步、打孔在哪步、倒角参数是多少。能编辑，意味着零件可以复用、可以出工程图、可以对接后续 CAM 编程。我在多个项目里都体会过“不可编辑几何”的局限：预览阶段看不出问题，一进装配就发现干涉没法调，只能推倒重来。

这也就是为什么我强调，做 text-to-CAD 不要跳过“脚本”这一层。直接生成网格也许演示效果好，但到车间就会被毙掉。反过来说，一旦脚本这条路跑顺，后面接参数化设计、批量改型、自动出图都非常自然。

3. 从零搭一套可用的 text-to-CAD 工作流：CadQuery + LLM 实测组合

3.1 工具选型：CadQuery、OpenSCAD、FreeCAD 脚本怎么选

程序化建模的脚本有很多种，不是随便选一个都能做好 text-to-CAD。我按自己的实测体验排个序，把三个常用工具说清楚。

OpenSCAD 的语法偏向 CSG，用 union、difference、translate 组合基本体。上手简单，但描述方式离“建模思维”比较远。你很难用自然语言流畅地对应到它的函数嵌套，让大模型翻译时也容易绕晕。适合纯几何爱好者，不太适合做文本到特征的映射。

FreeCAD Python 脚本功能最强，但 API 太庞杂，同一个操作有好几种写法，LLM 生成时很容易选择困难，导致生成代码错误率高。而且 FreeCAD 的依赖环境偏重，脚本运行速度和稳定性也不算理想。

CadQuery 反而是最平衡的选择。它用 Workplane 的概念模拟“在哪个平面上画草图、拉伸多高、在哪个面上打孔”，代码嵌套深度小，读起来几乎和自然语言一一对应。它是基于 Python OCC 内核构建的，导出的 STEP 文件精度和兼容性都过关，且支持常见的布尔运算、圆角、阵列、扫掠等操作。

所以我的建议是，pip install cadquery 就能开始，没有任何 CAD 软件依赖，非常适合做 text-to-CAD 的验证环境。命令行里跑通脚本，再可视化看一眼，整个闭环很干净。

3.2 让大模型“好好听话”：提示词里的六个关键约束

把 LLM 用作建模引擎，最大的坑是它“自由发挥”过头。要让输出稳定可控，提示词不能只写一句“帮我建模”，必须把边界条件写死。下面这个模板我已经实际跑过，可以直接抄走：

你是一名 CadQuery 建模专家。请根据用户的自然语言描述，生成完整可运行的 CadQuery 脚本。 约束： 1. 只输出 Python 代码，不要任何解释文字。 2. 统一从 cq.Workplane("XY") 开始。 3. 所有尺寸单位是毫米。 4. circle() 传的是半径参数，hole() 传的是直径参数，不要混用。 5. 每个新特征必须显式指定基准面或面选择（例如 faces(">Z")）。 6. 不要添加用户描述中不存在的倒角、圆角、螺纹或装饰特征。 7. 参数不足时，输出一行注释 # MISSING_PARAM 并给出默认值，而不是停止。 8. 最终变量命名为 result。 用户描述：{用户输入}

六个约束分别对应六个实际问题。约束 1 保证输出干净，省掉解析成本；约束 2 统一坐标系习惯，避免每个模型一个方向；约束 3 消除单位歧义，这是制造业的红线；约束 4 专门防半径/直径这个高频错误；约束 5 避免特征挂错平面；约束 6 杜绝“过设计”。

3.3 完整实测案例：从一句话到 STEP 文件

拿最典型的法兰盘来跑一遍。用户输入是：

“一个圆形法兰盘，外径 60 毫米，厚度 8 毫米，中心有一个直径 25 毫米的通孔，四周均匀分布 6 个直径 5.5 毫米的安装孔，孔心所在圆直径为 48 毫米。”

按照上面的提示词约束，大模型输出的 CadQuery 代码大致如下：

import cadquery as cq result = ( cq.Workplane("XY") .circle(30) # 外径 60，circle 使用半径 .extrude(8) # 厚度 8mm .faces(">Z") # 选择顶面 .workplane() .hole(25) # 中心通孔，hole 使用直径 ) result = ( result.faces(">Z") .workplane() .polarArray(24, 0, 360, 6) .hole(5.5) )

这里有几个关键点要解释清楚。circle(30) 而不是 circle(60)，因为 CadQuery 的 circle 接收半径；hole(25) 而不是 hole(12.5)，因为 hole 接收直径。这两个就是最经典的语义陷阱，大模型在没有明确约束时几乎一定会搞混。

polarArray(24, 0, 360, 6) 的参数语义是：第一个参数是分布圆的半径 24mm，第二个是起始角度 0 度，第三个是结束角度 360 度，第四个是要生成的孔数量 6。这一句等同于数学上的“在半径 24 的圆周上均匀取 6 个点”，比手写三角函数可靠得多，也不容易出现角度累积误差。

执行这段代码后，再用一行导出：

cq.exporters.export(result, "flange.step")

就能在当前目录拿到一个 flange.step 文件，可以直接丢进 FreeCAD、Fusion 360 或者其他支持 STEP 的查看器里检查。到这里，一句自然语言已经完成了到工程文件的闭环。整个过程不到十秒。

3.4 自动校验闭环：别让生成代码直接跑进产线

代码能跑和代码“正确地建出了想要的模型”是两回事。我在实操里会加一个三层校验，成本很低，但能拦掉大部分问题。

第一层是语法检查。用 Python 的 ast 模块解析生成的代码，语法都过不了直接打回重试。这一步能拦掉漏括号、错误缩进这些低级问题。大模型偶尔会在代码块里夹带解释性文字，ast.parse 也会直接报错。

import ast def check_syntax(code: str): try: ast.parse(code) return True, "语法 OK" except SyntaxError as e: return False, f"语法错误: {e}"

第二层是执行检查。在一个受限的命名空间里执行脚本，然后对 result 做合法性检查，比如实体是否非空、是否包含有效体积、faces 数量是否合理。CadQuery 的 solid 对象提供了 check() 方法，可以返回几何错误列表，比肉眼靠谱得多。

import math try: ns = {"cq": cq, "math": math} exec(code, ns) solid = ns["result"].val() errors = solid.check() if errors: print("几何检查发现错误:", errors) else: print("几何检查通过") except Exception as e: print("执行失败:", e)

第三层是人工或者可视化复审。把生成的 STEP 丢到查看器里，或者导出渲染缩略图，对照自然语言描述快速核对。自动检查能保证“是个合法实体”，但“是不是用户要的那个实体”，最终还是要人看一眼。这一步千万别省，实测中 LLM 偶尔会生成一个完全合法但和你描述南辕北辙的零件，比如把梯形板做成了矩形板，因为描述里没说清楚，而模型脑补了一个。

4. 实测踩坑记录：text-to-CAD 最常见的 5 类翻车现场

4.1 半径和直径的“宿命之战”

这是我在实际测试中遇到最多的问题。CadQuery 的 circle() 接收半径，hole() 却接收直径，而用户的自然语言习惯几乎都是说直径。“外径 60 的圆”对应 circle(30)，“直径 25 的孔”对应 hole(25)。

有一次我测试模型生成的代码，把中心孔写成了 hole(12.5)，理由是“25 除以 2”——这明显是被 circle 的语义带偏了。类似的错误还发生在沉头孔、键槽这些带两个尺寸的特征上。对策只有一个：在提示词里把这条规则明确写进去，并且在校验脚本里对关键尺寸做一次 boundBox 抽查，发现孔的实际尺寸和描述对不上就重新生成。

4.2 特征挂错了面：拉伸方向与面选择的歧义

生成代码第二大类问题出在平面选择上。比如要把通孔打在顶面，正确写法是先 faces(">Z") 再 workplane()，但 LLM 有时候会省略这一步，直接把 hole 挂到最初的工作平面上，结果孔打在了底面或者侧面，甚至跟预想完全不一样。

拉伸方向也比较隐蔽。extrude(8) 是沿着当前平面法向挤出，如果工作平面选成了 "<Z" 或者 "XZ"，整个零件方向就会乱。我建议在提示词里固定基准面为 "XY"，并且让所有跨越实体表面的特征都显式带 faces(">Z")，这样至少方向是可控的。

4.3 过设计：模型自己加的倒角和螺纹

通用 LLM 有一个非常固执的习惯：觉得“好看”就要加细节。一段描述里明明只说了“一个矩形板，四个孔”，生成结果却多出 2mm 的圆角和一个螺纹孔。

这种自动追加的特征在工程上是致命的：倒角会影响装配干涉，螺纹会影响后续攻丝工序。我在提示词的约束 6 里专门写了“不要添加不存在的特征”，实测能明显降低这种情况，但不会完全消失。最好的兜底是人工复审时扫一眼特征树，看到多余的特征直接删掉。另一个技巧是让模型先写特征列表再生成代码，相当于给它一个“施工计划”，计划里没出现的东西就不会被加进代码。

4.4 尺寸约束的“自由发挥”：把毫米当英寸是灾难

另一类高发问题是单位理解。描述里写“板厚 10”，模型生成 extrude(10)，这没问题；但如果用户说“1 英寸厚的板”，LLM 可能直接写 extrude(1)，也可能写成 25.4 之后又在别处用 1。最危险的是混用：上面用毫米，下面又用英寸的近似值。

我目前的处理方式是在提示词里强制“所有尺寸单位是毫米”，同时要求模型在参数不足时输出默认值而不是自行猜测。单位问题一旦流到制造端，就是批量报废级别的灾难，这条不能妥协。

4.5 布尔运算失败与非流形几何

CadQuery 里有不少操作依赖布尔运算，比如 cut、union、intersect。当两个实体刚好共面、相切或者存在微小间隙时，布尔运算会报错或生成非流形几何。这类问题属于几何引擎的常见坑，不完全是模型生成的锅。

遇到这类问题，最有效的排查手段是用 solid.check() 拿到具体的拓扑错误列表，或者尝试把切割体偏移一个极小值（比如 0.001mm）再执行布尔。如果是阵列产生的孔位重叠，也容易触发类似问题，可以先把孔心距检查一遍再执行。用 polarArray 做阵列时尤其要注意，分布圆半径太小导致孔之间打架，就会触发这种问题。

下面整理成一个速查表，方便直接对照：

5. 怎样评估一个 text-to-CAD 结果才算合格：质量指标与下一步扩展

5.1 别只看“长得像”：几何正确与可制造性才是硬指标

判断一个 text-to-CAD 结果好不好，我建议按两层来。第一层是几何正确性：尺寸是否符合描述、特征数量是否对、有没有非流形实体。这一层现在依靠自动校验加人工复核基本能兜住。

第二层是可制造性，这一层才是真门槛。一个模型几何完全正确，但最小壁厚只有 0.3mm，注塑直接废；一个法兰盘的安装孔离边缘太近，压铆时会开裂。当前绝大多数 text-to-CAD 系统都不考虑这些，因为训练数据里根本没有制造约束。

我给做这个方向的朋友一个很实际的建议：在生成流程后面挂一个规则检查器，对最小壁厚、孔径、孔边距这些常见制造规则做硬性校验，不满足就回炉重试。这比让模型自己“领悟”制造工艺要可靠得多。规则检查器写起来不复杂，本质是一组 if 判断加数值比较，但能挡住大量流到线下的废品。

5.2 从单个零件到参数化族和装配体

现在多数 text-to-CAD 演示都停留在单个零件的层面，但这个方向真正的价值在参数化族和装配体。比如“一个 M6 的内六角螺栓”只是一个信息，而“一个符合 GB/T 5783 的 M6 全螺纹螺栓”才是有生产意义的描述。参数化族一旦建立起来，标准件库就有了雏形。

进一步，一旦模型能生成带参数关系的脚本族，改一个主参数，相关尺寸自动联动，那 text-to-CAD 就不再是建模辅助工具，而是整个非标自动化设计的前端入口。再往前一步，装配体层面的描述会涉及配合约束，像“轴套孔与轴颈间隙 0.05”，这对模型的空间推理能力要求更高，但也是更值得投入的方向。

5.3 我个人实操里的三点体会

最后分享几个我自己跑下来的体会，不展开太多，但都是真金白银换的。

第一，别指望一个模型解决所有问题。当前最稳的组合是“强约束提示词 + CadQuery + 自动校验”，本质上是用工程手段兜住模型的随机性。等端到端生成真正成熟之前，这条路线够用且能落地。

第二，提示词迭代比换模型重要。我试过不同规模的模型，发现把提示词的约束写清楚，小模型的可用性提升比直接换大模型带来的提升还明显。花时间打磨提示词模板，性价比极高。

第三，数据闭环比模型结构更值钱。如果是在企业内部做，把每一次用户提问、生成结果、人工修正都记录下来，形成自己的 text-to-CAD 数据集，这个资产的价值会随时间增长，比反复调参更持久。我自己现在的做法就是每个翻车案例都归档，攒得多了，模型会越来越懂你们那一行的黑话。