企业官网建设流程全解析

做 CAD 这行久了，你会慢慢意识到一件反直觉的事：软件最大的瓶颈往往不是功能不够强，而是从“脑子里一个大概想法”到“屏幕上能编辑的实体模型”之间，那道转换门槛实在太高。这两年 text-to-cad 这个概念突然火起来，说白了就是想用自然语言直接生成 CAD 模型——你说一句“M6 六角头螺栓，公称长度 30 毫米”，系统还你一个能编辑、能装配、能出工程图的实体文件。这篇文章我不打算只讲概念，而是把我看过的、实际跑过的 text-to-cad 技术路线、工程落地方式和踩过的坑，一次性梳理清楚，适合正在做自动化设计、三维建模教学、或者每天被重复建模工作折磨的工程师朋友参考。

1. 从文本到模型：text-to-cad 到底在解决什么问题

1.1 传统 CAD 建模的真实痛点

我刚入行的时候，师傅教我的第一句话是“建模不是画图，是在表达设计意图”。当时觉得这句话很玄乎，干了几年才明白，传统 CAD 流程里最贵的成本不是软件授权，而是“意图转述”的过程：你想给客户做一个带法兰的轴套，得先在脑子里把形状拆解成草图、拉伸、旋转、打孔、倒角这一整套特征操作，然后手把手告诉软件每一步怎么做。这个过程的效率完全取决于操作者对软件命令的熟练度。

更现实的问题是，很多重复性建模工作根本不需要多少“设计创造”，比如标准件、法兰、支架、壳体开口。但只要你用的是传统交互式建模，每一步都得手点菜单、选基准面、输入尺寸。哪怕是一个 20 个特征的小零件，最少也要几百次鼠标操作。我见过一个做了十年非标设备的老师傅，一天八小时里有五个小时都在做这种“翻译工作”，真正花在方案思考上的时间少得可怜。

所以当有人说 text-to-cad 是“用 AI 取代设计师”时，我觉得方向完全错了。它的价值不是取代谁，而是把那道“意图转述”的墙拆掉一部分，让重复性建模从“一天做十个”变成“一小时做一百个”，把人从机械劳动里解放出来，去做真正有创造力的东西。

1.2 text-to-cad 的定义和边界

严格来说，text-to-cad 是指“以自然语言文本为输入，以可编辑的 CAD 模型为输出的生成式建模系统”。它在学术上通常归属于程序化建模（Procedural Modeling）和生成式设计交叉领域，但在工业落地时，更接近“面向自然语言的参数化模板驱动建模”。

我不止一次看到有人把 text-to-cad 和简单的文生图混为一谈，这完全是两码事。文生图生成的是像素矩阵，最后得到一张 PNG，放进 CAD 里只能当图片参考；而 text-to-cad 要求输出的是真实的边界表示（B-Rep）或者参数化特征历史，也就是 STEP、IGES 这类能被后续拆模、装配、仿真、加工直接使用的几何数据。换句话说，文生图骗得了眼睛，text-to-cad 必须骗得过机床。

这一点决定了整个技术路线的走向。你要输出的不是一个“看起来像螺栓”的三角网格，而是一个“公差正确、拓扑闭合、能出工程图”的实体。也正因为如此， text-to-cad 的实现难度比文生图高了一个数量级——它不能靠一个扩散模型糊弄过去，必须走“理解语言 → 生成指令 → 精确执行”的严肃路径。

1.3 适合谁看、能解决什么事

如果你是一个机械设计工程师，text-to-cad 最直接的价值在标准件库、非标零件快速建模、设计变更的自动同步；如果你是一个 CAD 二次开发或者自动化软件工程师，你可能更关心它背后的数据格式、模型训练、代码生成链路；如果你在职业院校或者高校教机械制图，text-to-cad 生成的大量示例模型也可以拿来做题目素材和对比教学。

我个人的判断是：现阶段 text-to-cad 最靠谱的落地场景不是“天马行空随便说两句设计一台发动机”，而是“把有限种类、参数可变、结构清晰的零件族通过自然语言召唤出来”。沿着这条主线，我们把技术链路一步步拆开。

2. 技术拆解：LLM 是怎么“读懂”几何需求的

2.1 核心链路：自然语言 → 参数化指令 → 几何内核

真正可用的 text-to-cad 系统，内部链路基本是一致的，可以分成四层：

• 自然语言理解层：把用户输入“外径 24 内孔 6 厚度 3 的垫片”解析成结构化意图，包括零件类型、关键尺寸、特征关系。
• 参数映射层：将结构化意图映射为参数化特征树或 CAD 脚本模板，比如 CadQuery 代码、FreeCAD 的 Python API 调用、或者某个商用软件的参数表。
• 几何内核执行层：调用 OpenCASCADE、Parasolid、ACIS 这类几何内核，把特征树变成真实的边界表示模型。
• 校验输出层：检查模型是否拓扑闭合、是否存在自相交、是否满足尺寸公差，然后导出为 STEP、IGES，或者直接生成工程图视图。

这里最容易被忽略的是第四层。很多人在实验室里把前三步跑通了，以为就完事了，结果导出的 STEP 文件在别的软件里打开，要么是破面，要么是单位错乱，要么是外露边——这些都是校验层没做好的典型问题。做 text-to-cad 不是跑通一个推理脚本就算完，而是要保证输出模型的工程可用性。

2.2 底层的“燃料”：命令序列数据集

我们说 text-to-cad 是数据驱动，那么训练数据从哪来？这是一个核心问题。真实 CAD 数据不像互联网文本那样随手可得，商业模型文件大多涉及企业知识产权，基本不可能公开。目前做得比较多的是合成数据路线——通过脚本批量生成参数化零件，然后记录每一步 CAD 操作命令序列，最后自动配上文本描述。

学术界比较有代表性的 DeepCAD 数据集走的就是这个思路。它包含几十万个由 CAD 命令序列描述的机械零件，每个序列类似“开始新草图 → 画三个圆 → 拉伸 → 打孔 → 倒角”，同时对应一份抽象的 CAD 命令 JSON。在 DeepCAD 的基础上，后来有人扩展出 Text2CAD 数据集，给这些零件补充了自然语言描述，让模型可以学习“文本特征”与“操作序列”之间的对齐关系。

这类数据集有一个显著特点：零件的几何特征完全可用命令序列逆向重建，因此不需要依赖某一个特定 CAD 软件的私有格式，天然适合做跨平台训练。但缺点也很明显，就是生成出来的零件偏向“旋转对称”、“拉伸类”、“孔槽类”，对复杂的曲面造型覆盖不足。所以在实际工程中使用时，要清楚地知道模型的“能力边界”在哪里。

2.3 模型选型：为什么微调比纯提示词靠谱

现在大家习惯遇到什么都拿通用大模型来跑，一上来就把文本需求丢给 GPT、Claude 或开源 LLM，等着它直接输出一个 STEP 文件。很遗憾，目前通用大模型做不到这一点。它们可以作为 text-to-cad 链路里的“语义理解组件”，但无法替代几何内核，也不可能从零生成一个拓扑正确的实体文件。

真正靠谱的路线，是在专用 LLM 或编码器-解码器模型上做微调。输入是一句话（或加上简单草图），输出不是自然语言，而是一个 CAD 命令序列，或者是一段受约束的代码。微调数据的格式要非常严格，命令每个参数的取值范围、单位、坐标系约定都得在训练前定义清楚。只有这样，模型学到的才不是“看起来像那么回事”的幻觉，而是“每一个数字都对应真实几何操作”的映射关系。

我也试过用通用大模型配合少样本提示词，让它输出 CadQuery 代码来生成零件。在零件结构非常简单、参数都由我预定义的情况下，效果尚可；一旦遇到稍有变化的描述，它就会开始自由发挥，比如给垫片加上一个不存在的键槽，或者把一个 M6 螺纹孔写成了直径 6 的圆柱孔。这些错误在代码层面看起来只是几个数字，但落到模型上就全废了。结论很明确：工程化 text-to-cad 现阶段必须走“微调 + 约束解码 + 规则校验”的组合路线，单纯堆提示词是不够的。

3. 场景盘点： text-to-cad 现在能用在什么地方

3.1 概念设计阶段的快速草模生成

产品设计前期有一个特别讨厌的阶段，叫“方案比选”。客户说想要一个带观察窗的防护罩，高度大概 400，宽度 250，内部要能容纳一个电机、要留出散热孔。这种需求，设计师第一轮通常不会直接画精细模型，而是快速拉几个方方正正的体块，把比例关系和空间占用先定下来。

过去这个环节靠拉伸和布尔运算手工搭，一个方案少说也要二十分钟。如果团队积累了参数化模板库，再用 text-to-cad 做语义触发，就能把时间压缩到两三分钟。你只要把模板库里的特征树定义好，比如“防护罩 = 主体壳体 + 观察窗 + 通风孔数组 + 安装孔”，剩下要做的就是让模型把自然语言里的“大概尺寸”映射到模板参数上。

这里我想强调一个观点：概念设计阶段的 text-to-cad 不需要追求绝对精确，反而要允许“模糊描述”和“默认值”的存在。你说“高度大概 400”，系统可以按 400 生成，同时保留一个“高度参数”在属性面板里，让设计师随时拖动修改。核心目的是把重复操作降到最低，而不是让 AI 替你做决定。

3.2 教育场景：配合 CAD 学习和自动出题

还有一个我认为价值被低估的场景，是机械制图和三维建模教学。我在带实习生和给学生讲课时发现，最耗费精力的事情之一是准备练习模型：每个学生的基础不一样，题目难度要分层，练完还要有参考答案。用 text-to-cad 批量生成带不同参数的同类零件，比如“直径 30 的带轮”“直径 50 的带轮”“带 4 个减重孔”“带 6 个减重孔”，简直是天然的教学素材库。

更重要的是，text-to-cad 可以帮助学生理解“设计意图”和“特征操作”之间的关系。学生对着系统生成的命令序列，能直观看到“厚度”这个参数是怎么一步步传导到最终的实体几何上的。这种从语义到特征的映射可视化，比对着菜单栏一遍遍演示有效得多。

当然，教学场景里也要注意一点：发给学生的模型文件最好先经过校验，确认单位一致、拓扑正确，否则学生打开一个破面模型，反而会学到错误习惯。

3.3 与现有 CAD 平台集成：不是替代，是共存

很多人担心 text-to-cad 会颠覆现有 CAD 软件，我觉得五年内都不太可能。更现实的路径是作为插件或 API 融入现有平台。比如 FreeCAD 有完整的 Python 接口，天然适合作为 text-to-cad 的执行后端；Onshape 提供 FeatureScript 和 REST API，也能把生成的参数化特征直接推送到云端文档。商用软件中的 AutoCAD 这几年的 AI 功能也在往类似方向走，但离广泛落地还有距离。

如果让我给想入坑的团队一个建议，我会说：不要把宝押在“等待某个官方 AI 功能上线”上，而是尽早把自身的零件库参数化，并定义一套标准文本模板。这样无论底层换成哪个 LLM 或者哪套生成管线，你的业务逻辑都能快速适配。工具会过时，数据和特征树的资产不会。

3.4 面向大规模零件库的自动扩展

最后聊一个看起来不起眼、但实际收益很高的场景：企业级零件库的自动扩展。很多制造企业有一个几百上千种零件的标准件库，每年还要新增不少变型。过去维护这个库需要 CAD 专员手工绘制、手工填参数表，稍有疏漏，下游装配就会出问题。

用 text-to-cad 的思路，可以把整个变型过程自动化：维护人员只需要写一条文本描述“SG-200 系列法兰，DN80，PN16，螺栓孔 4×Ø18，密封槽宽 5 深 3”，系统自动匹配到法兰模板，填入参数，生成 STEP，并同步更新到 PDM/PLM 系统。这样做出来的模型因为是同一个模板生成的，装配基准、命名规则、属性标签全部一致，后续做自动化出图、BOM 汇总都会轻松很多。

4. 实操演示：从文本生成一个可用的 STEP 文件

4.1 环境准备与工具选择

理论说了那么多，还是动手最踏实。我先假设一个最简单、也最有代表性的场景：用户输入“外径 24、内孔 6、厚度 3 的平垫圈”，系统输出一个可用的 STEP 文件。这里我选择 CadQuery + OpenCASCADE 作为底层实现，原因是 CadQuery 的 Python API 足够简洁，而且最终导出 STEP 文件时走的是 OpenCASCADE 内核，工程可用性好。

环境准备只有一个核心依赖：

pip install cadquery

如果你要额外做模型健康检查，可以安装 OCP（OpenCASCADE 的 Python 绑定），CadQuery 装好后一般会自带。我用的是 Python 3.10 以上的版本，实测下来 CadQuery 2.x 在 Windows 和 Linux 上都没有太大问题。

4.2 用 CadQuery 生成垫片的完整流程

把“平垫圈”这个零件翻译成特征操作，其实就两步：先画一个外圆草图，拉伸成圆柱体，再在中心打一个圆孔。用 CadQuery 写出来非常直观：

import cadquery as cq # 零件参数，实际使用中这些值由文本解析层提供 outer_diameter = 24.0 inner_diameter = 6.0 thickness = 3.0 result = ( cq.Workplane("XY") .circle(outer_diameter / 2.0) # 画外圆 .extrude(thickness) # 拉伸成圆柱 .faces(">Z") # 选中上表面 .workplane() .hole(inner_diameter) # 打中心孔 ) # 导出 STEP 文件 result.exportStep("washer.step")

这段代码的执行过程是这样的：在 XY 基准面上创建草图，画一个半径 12 的圆，向 Z 方向拉伸 3 毫米形成圆柱体；然后选中法向指向 +Z 的那个端面，建立新的工作平面，在上面打一个直径 6 的通孔。CadQuery 的.hole()方法会创建真正的贯通特征，不是简单的圆台切除，所以导出的 STEP 里包含的是“带孔圆柱体”的实体拓扑，而不是两个独立实体的布尔差集残留。

4.3 关键参数怎么确定：从自然语言到精确数值

你可能会问，用户说“外径 24、内孔 6、厚度 3”，系统是怎么知道这些数字对应哪个参数的呢？这才是 text-to-cad 的真正难点。工程上我会采用一个“模板化抽取”策略，而不是真的让模型自由发挥。

首先定义一个 JSON Schema，把零件参数和描述规则写清楚：

{ "part_type": "washer", "parameters": { "outer_diameter": {"type": "number", "unit": "mm", "default": 24.0, "alias": ["外径", "外圆", "OD"]}, "inner_diameter": {"type": "number", "unit": "mm", "default": 6.0, "alias": ["内孔", "内径", "ID"]}, "thickness": {"type": "number", "unit": "mm", "default": 3.0, "alias": ["厚度", "高", "T"]} }, "constraints": [ "inner_diameter < outer_diameter", "thickness > 0" ] }

然后让 LLM 做一件事：把用户输入的文本格式化为符合这个 Schema 的 JSON。比如用户输入“帮我做个外径 24，内孔 6，厚 3 的垫圈”，LLM 应该输出：

{ "part_type": "washer", "parameters": { "outer_diameter": 24.0, "inner_diameter": 6.0, "thickness": 3.0 } }

这里的微妙之处在于：LLM 只需要负责“语义理解”和“参数抽取”，不需要负责“几何生成”。几何生成完全交给 CadQuery 和 OpenCASCADE。这条路线的最大好处是，模型输出的自由度被死死限制在 Schema 里，不会出现“临时起意”的多余特征。

更重要的是要处理约束校验：在把参数传给 CadQuery 之前，程序先检查inner_diameter < outer_diameter是否成立，如果不成立就返回提示，而不是继续执行生成。我见过有人在文本里写“内孔 30 外径 20”，结果几何内核抛出一个异常，程序直接崩溃。这种问题靠规则校验能拦截一大部分。

4.4 输出检查：几何合法性、拓扑闭合、工程语义

模型生成出来之后，千万别急着交付。在正式工程流程里，我每次都会跑一遍几何健康检查。CadQuery 导出的 STEP 文件可以通过 OpenCASCADE 的BRepCheck_Analyzer来做实体合法性验证，下面是一段可运行的检查逻辑：

from OCP.BRepCheck import BRepCheck_Analyzer from OCP.STEPControl import STEPControl_Reader # 读取 STEP 文件 reader = STEPControl_Reader() reader.ReadFile("washer.step") reader.TransferRoots() shape = reader.OneShape() # 执行拓扑健康检查 analyzer = BRepCheck_Analyzer(shape) print("is valid:", analyzer.IsValid())

这段代码会检查模型是否存在无效几何、退化边、错误朝向等问题。如果IsValid()返回 False，说明模型不能直接用于后续装配和加工。实际工作中我还遇到过一种更隐蔽的问题：在某个 CAD 软件里生成和导出的模型，放到另一个软件里显示正常，但做布尔运算时报“非流形实体”错误。因此我建议，凡是给下游用的 STEP 文件，最好在“导出方”和“接收方”两个环境里各测一遍布尔运算，尤其是拆分和合并操作，这比只看视觉结果可靠得多。

另外，尺寸公差也值得在输出时写明。text-to-cad 生成的 STEP 文件本身可以携带几何尺寸，但公差信息通常不在这类生成流程里。如果你需要把模型直接给加工部门，建议在 CAM 或工艺系统里单独配置公差，而不是依赖生成流程自动附加，否则容易出现“模型看似精确、公差其实全缺”的尴尬局面。

5. 常见问题与排查实录

5.1 自然语言歧义怎么消解

text-to-cad 最让人头疼的问题不是模型不会生成，而是用户描述本身模棱两可。例如“做一个大一点的支架”，“大一点”到底是长宽高同时放大 20%，还是指总体积增大？遇到这类模糊描述，不要硬猜，更不要让 LLM 擅自决定。我的做法是在解析层设定“置信度阈值”：如果某个参数在文本中没有明确数字，就返回追问，同时给出推荐默认值，让用户一键确认。

另一个常见歧义是“厚度”和“高度”在不同零件语境下的含义不同。垫片的厚度是 Z 向高度，法兰的厚度却可能是安装边的宽度。因此每个零件模板里都必须把参数语义写清楚，否则同一个“厚度”词在不同模板里会映射到不同方向，最终生成的模型和用户预期南辕北辙。

我的实用建议是：在系统设计阶段就让文本解析器和零件模板解耦，解析器只负责抽取数字和特征关键词，模板负责把关键词映射为具体的几何方向。这样即使新增一个零件类型，也不需要改动解析逻辑。

5.2 几何精度不够，数值误差从哪来

有段时间我连续被加工部门反馈“螺纹孔位置偏了 0.1 毫米”，一开始以为是模型生成的问题，后来排查发现是文本描述里的尺寸单位错了。用户口语里说“孔距 40 个丝”，但系统把它理解成 40 毫米，实际加工要求是 0.4 毫米。这种单位混淆在 text-to-cad 流程里极其常见，尤其是中文里“丝”“道”“缪”这类工程口语，一个词在不同老师傅嘴里意思完全不同。

我的对策是在参数抽取层强制带单位映射表，并且对非常规单位给出提示：“你输入的孔距单位为丝，换算后为 0.4 毫米，是否确认？” 宁可多问一次，也不要让 0.1 毫米的误差流到机床上。

还有一类误差来自浮点存储。OpenCASCADE 默认容差是 1e-6 毫米，如果生成过程中某个尺寸是由多个约束迭代计算出来的，浮点误差可能累积到 1e-4。对绝大多数机械件来说，这个量级可以接受，但如果你在做光学结构或者精密配合件，建议在生成后做一次尺寸重新标注，而不是直接信任内核里的浮点值。

5.3 输出模型不可用：自相交、开放壳、非流形实体

这是 text-to-cad 落地时最容易炸的一类问题。代码里看起来每个特征都没错，但组合在一起，模型却出现了自相交面、开放壳或非流形边。常见诱因有三个：

• 布尔运算顺序问题：先打孔后倒角，和先倒角后打孔，在很多情况下结果不同。有的顺序会产生残片，虽然视觉上看不出来，但 BRepCheck 会报错。
• 尺寸过小而导致的几何退化：比如把圆角半径设成比倒角半径还大，系统生成一个不合理的零厚度特征。
• 多实体误合并：拉伸之后没有把操作对象限定在当前体上，导致两个不相关的实体被隐式合并。

排查这类问题，最有效的方法不是人眼盯着模型看，而是跑一遍自动检查脚本，把失效的拓扑类型精确打印出来。我在第四章给的BRepCheck_Analyzer代码就是第一道防线。接下来还要检查每个面的面积和边长，出现接近零值的元素时，直接判定为可疑特征并定位到对应命令序列。

遇到这种情况，我一般会在生成管线里加一条“回退策略”：如果校验失败，自动把参数微调一个微小量（比如直径偏移 0.01 毫米），重新生成，避开病态几何。虽然是笨办法，但在批量生成零件时有奇效，能显著减少手动干预。

5.4 模型幻觉和数据覆盖不足的问题

如果你尝试过使用大模型生成 CAD 代码，肯定会遇到幻觉问题。比如模型告诉你它生成了一个“带梯形螺纹的丝杆”，但代码一执行，只是画了一个光滑圆柱，根本没有螺纹牙型。另一个典型例子是它生成一个 M6 螺纹孔，却写成直径 6 的光孔，完全误解了螺纹孔径代表的功能语义。

从根上讲，这是因为通用预训练语料里“CAD 代码”和“文本描述”的对应关系太少，模型只能靠生成语法相似的内容来凑数。我的做法是把“词汇表”和“功能库”做严格映射：允许模型调用的特征指令只有固定的几十种，每种特征指令的每个参数都必须来自模板允许的范围。凡是超出范围的，一律视为非法输出，直接拒绝并提示重试。

数据覆盖不足的问题同样值得警惕。即便用 DeepCAD 这类数据集微调，模型也只会对它见过的特征组合比较擅长。你让它生成一个“带波纹管接头的异径管”，很可能因为训练集里几乎没有波纹管特征而输出一个奇怪的变形体。解决这个问题没有捷径，只能持续扩充该领域的合成数据，并且在系统层面把“识别不了”作为正常输出反馈给用户，而不是让模型硬编一个错误答案。

5.5 常见问题速查表

排查表只能帮你快速定位方向，真正的工程效率来自把这些检查写成自动化脚本，在生成链路里做实时门禁。凡是不能通过检查的模型，一律不进交付流程，从源头杜绝问题。

6. 写在最后：我在实操中的几点体会

说实话，text-to-cad 到现在还没有到“随便说一句话就能生成完美模型”的阶段，任何吹嘘这个方向的宣传你都得多留个心眼。但我自己把这条路从论文跑到工程原型之后，最大的感受是：它的核心价值不在“AI 创造设计”，而在“消解重复劳动”。你把有限种类的零件族模板化，把特征参数表达清楚，再让 LLM 充当一个高级的语义翻译器，这件事的产出效率提升是指数级的。

我个人实际开发时最依赖的一条经验是：一定要把“模型自由发挥”的空间压到最小。宁可让系统在拿不准参数时多问一句，也不要让它顺着模糊语义猜一个答案。一个诚实说“我不确定”的系统，在工业场景里远比一个自信满满的幻觉机器可靠。

最后再分享一个小技巧：做 text-to-cad 项目时，不要一开始就花大量时间去训练一个大模型，先把你最常用的 20 个零件做成模板和文本解析器，用通用 LLM 做参数抽取跑通全流程。等这个闭环稳定运行了，再把真正频繁出错的部分交给微调模型处理。这条路看起来慢，但实际上每一步都能交付成果，比一口气搞一个“万能生成模型”稳妥得多。后续你还可以把它跟拓扑优化、点云逆向、工艺知识库串起来，那时候 text-to-cad 就不再是一个噱头，而是一根真正连接语言和制造的管道。