企业官网建设流程全解析

1. 从一句英文指令到三维模型：text-to-cad到底在做什么

先聊聊最核心的问题：text-to-cad是什么。简单说，就是输入一段自然语言描述，比如“一个M8内六角螺栓，头部直径13mm，螺杆长度40mm，螺纹长度30mm”，系统自动生成对应的CAD三维模型文件。这个方向不是某家公司突然拍脑袋想出来的，而是CAD领域这几年最实在的自动化趋势之一——把设计师从重复的参数化建模劳动里解放出来，让“描述需求”直接变成“拿到模型”。

这项技术适合谁？三类人最值得关注：一是机械工程师，尤其是每天要画大量标准件、非标零件的；二是产品经理和采购，他们经常需要快速拿到一个可用的三维模型做方案验证，但自己不会用CAD软件；三是做自动化产线集成的工程师，类似“皮带轮”“法兰盘”“齿轮箱壳体”这类常见部件，如果能用一句话生成基础模型，再进软件微调，效率是肉眼可见的提升。

不过要先泼一盆冷水：目前的text-to-cad并不是“无所不能”。它最擅长的是参数化明确的零件、标准件、简单装配体，以及可以用几何规则描述的形体。凡是涉及自由曲面造型、复杂装配约束、行业规范要求（比如焊接符号、公差标注、表面粗糙度）的内容，自动生成结果都还达不到交付标准。理解这个边界，后面用起来才不会踩坑。

我之所以对这块感兴趣，是因为去年在公司做过一个内部工具调研，目标是把历史图纸库里的标准件参数提取出来，让工程师通过一个对话框就能调取模型。当时翻了很多资料，最后发现text-to-cad的技术栈并不是单一模型，而是一条“语言理解→几何生成→参数化重建”的流水线。这篇文章就把我调研和实测的经验完整拆开讲，从选型、原理到落地步骤，能帮你省掉不少自己摸索的时间。

2. 工具盘点：主流的text-to-cad方案有哪些，怎么选

2.1 四种主流实现路线

市面上叫得出名字的text-to-cad方案，本质上可以分成四类。搞清楚这四类的区别，你就知道为什么有的工具生成的模型是“参数化的”，有的却是“一堆三角面片”。

第一类是基于程序化生成器加语言映射的方案。典型代表是一些在线标准件库，它们的后台维护了几百种常用零件的参数化模板，比如ISO 4014六角头螺栓、GB/T 70.1内六角圆柱头螺钉、滑动轴承座等。你输入“M10×50的六角头螺栓，性能等级8.8”，系统先通过命名实体识别把M10、50这些参数提取出来，再匹配到对应模板，最后用模板API生成实体模型。这种方案胜在稳定、可编辑、完全符合标准，缺点是只能覆盖模板范围内的零件，超出范围就抓瞎。

第二类是基于深度学习的几何生成方案，也就是真正意义上的“从文本生成三维形状”。这类模型通常用大量“文本-三维模型”配对数据训练，输入描述后直接输出一个网格模型或隐式符号距离场。优点是覆盖面广，能生成一些不常见的异形件；缺点是生成的是网格，不是参数化实体，导入SolidWorks、NX、Inventor这类软件后只能当参考，没法直接改尺寸，没法出工程图。

第三类是混合方案，先由深度学习生成一个粗略的几何体，然后通过逆向工程技术把网格拟合成参数化特征树。这个思路是最近两年学术界和工业界都在猛攻的方向，代表项目有MIT的Text2CAD、AutoDesk内部的一些实验工具。理想状态下，你输入“一个带四个安装孔的矩形底座，孔距100mm”，系统会先输出一个网格，再通过识别平面、圆柱面、孔特征，重建出带参数历史的实体模型。但实测下来，特征识别的准确率在复杂模型上只有六七成，还做不到完全自动化。

第四类是程序化AI加规则引擎，典型代表是堆叠式的设计自动化平台。它们把常用设计规则（比如壁厚应大于2mm、注塑拔模角度至少1°）编码进规则库，AI只负责解读文字和选择参数，真正建模是由CAD软件的API驱动。这类方案的商业化程度最高，很多PLM厂商都在往这个方向做。

选型建议也直接给出来：如果做标准件库，选第一类；如果做方案草图快速验证，选第二类；如果要做可编辑的工程模型，现阶段还是得靠第一类加人工修复，混合方案可以作为研究关注对象，但别在生产环境里贸然用。

2.2 五款具体工具的实测对比

我实际测过几款主流工具，整理了下面这个对比表。注意，这里对比的是截至2024年底的公开版本情况，工具迭代很快，参数仅供参考。

autodesk fusion内置的那个生成器，其实更准确地说是“从文字生成配置”而非“从文字生成任意模型”。它的实现方式是把参数化特征操作（拉伸、旋转、阵列）和文字模板绑定，对常见机械零件支持很好，但对自由曲面无能为力。社区项目CAD-GPT的思路更有意思，它直接调用FreeCAD的Python API，让大语言模型自己写建模脚本，脚本执行的结果就是模型。这种方式的本质是“AI写代码”，所以对模型的最终控制力很强，只要大模型生成的代码没有语法错误，模型就是参数化的。

实测下来，最稳定的反而是看起来最“笨”的第一类工具。原因在于，程序化模板是预定义的，参数提取逻辑经过反复校验，不会出现大模型那种“一本正经地胡说八道”的情况。所以如果你要的是稳定交付，别迷信AI，老老实实走模板匹配加参数提取，准确率可以做到95%以上。

3. 核心原理：从文字到CAD模型，中间发生了什么

3.1 语言理解阶段——把自然语言变成结构化参数

text-to-cad的第一道工序，是把人的语言变成机器能处理的结构化数据。听起来简单，实际坑非常多。比如“一个M8x30的内六角螺钉”，这里M8是公称直径，30是螺杆长度。但如果是“一个直径8、长30的螺钉”，没有M前缀，模型就要靠上下文判断这是公制螺纹。再比如“带法兰的轴”，到底是“有轴肩的法兰轴”还是“轴端带一个法兰盘”？自然语言里的省略和歧义是最大的阻力。

工业界稳妥的做法是建立字典和模板联合提取。先做词法分析，把句子切分成名词短语、数量短语、材料短语；再用领域词典匹配，比如“螺栓”“螺钉”“螺母”“垫圈”“法兰”“轴承座”这些词直接映射为零件类型；最后用正则和规则抽取数字与单位，填入参数槽位。这套传统NLP方案虽然不太“智能”，但胜在可控，出错能追查。最近也有不少工具开始用大模型做这一步，但一定要约束输出为JSON格式，并且做枚举校验，否则“M8”可能会被解析成“M8”以外的奇怪内容。

下面是一个典型的参数提取结果示例。输入“一个M8×30的内六角圆柱头螺钉，材料304不锈钢，需要全螺纹”，系统输出：

{ "part_type": "socket_head_cap_screw", "standard": "GB/T 70.1", "diameter": 8, "length": 30, "thread_type": "full_thread", "material": "304_stainless_steel", "unit": "mm" }

注意这里“内六角圆柱头螺钉”已经自动映射到GB/T 70.1标准，这个映射关系是事先在标准件知识库里定义好的。这一步之所以关键，是因为后面的参数化模板必须知道“用哪个标准、哪个系列”，才能决定头径、头高、内六角对边等参数是查表还是按公式计算。

3.2 几何生成阶段——从参数到三维实体的两条路线

结构化参数生成后，就进入几何生成阶段。这里分两条路线，对应前文说的程序化模板和深度学习生成。

程序化模板路线，几何过程就是执行CAD内核里的建模命令。拿GB/T 70.1内六角圆柱头螺钉来说，建模步骤是这样的：先拉伸出头部圆柱体，直径d_k按标准查表（M8对应13mm），高度k为8mm；再拉伸出螺杆圆柱体，直径d为8mm，长度l为30mm；然后做螺纹特征，如果是全螺纹，直接用螺纹扫描命令，螺距P由标准表给定（M8粗牙螺距1.25mm）；最后用六角形草图拉伸扣除头部内六角孔，对边距离s为6mm，深度t为4mm。每一步都有对应的API调用，相当于预先写好了建模脚本，只等参数填入。

深度学习生成路线则完全不同。它把文本编码成一个语义向量，然后用条件生成模型去预测三维形状的占用场。简单说，就是用一个神经网络来判断三维空间里每个点（体素）是否属于实体。生成的结果通常是导出为STL网格，因为网格是最通用的表示格式。但网格模型没有特征树，没有参数历史，导入CAD软件后只能做布尔运算或者参考，不能像原生特征那样改草图尺寸。这就是为什么深度学习方案目前无法取代程序化模板的根本原因——CAD工程师要的是特征和参数，不是一堆三角形。

3.3 参数化重建阶段——把网格变成可编辑特征

为了让深度学习生成的模型“可用”，学术圈和工业界在尝试第三阶段：参数化重建。核心思路是先从网格模型里识别平面、圆柱面、球面、圆角面等基本几何特征，再把这些特征参数化——比如识别出一个圆柱面，提取它的轴线方向、半径、高度；识别出一个孔特征，提取它的位置、直径、深度。然后根据特征间的拓扑关系，重构一个参数化建模脚本。

这个技术和逆向工程类似，但难点在于自动化地识别“设计意图”。比如说，一块板上有一个沉头孔，网格模型里它可能被表示成几个同心圆柱面的组合。系统需要判断这几个面其实是同一个特征，才能重建出“孔特征”而不是三个独立的圆柱凸台。目前的实现基于特征识别算法加机器学习分类，识别简单零件（无圆角、无复杂曲面）的准确率还不错，一到复杂件就掉链子。所以现阶段实用的做法是：用深度学习做初步形状，再用程序化模板的“半成品”来替换其中标准的部分，最后人工修正。

4. 实操落地：从零搭建一个最小可用的text-to-cad系统

4.1 系统架构选型与依赖准备

我建议从最实用的“模板匹配加参数提取”路线开始，做一个能真正跑起来的系统。这套系统只需要三样东西：一个支持Python API的CAD软件（我用的是FreeCAD，开源免费）、一个大语言模型API（可选，用于解析自然语言）、一个标准件参数库（可以用Excel或JSON维护）。整体架构是接收自然语言指令→LLM解析为JSON→查模板库→生成参数化脚本→执行脚本输出模型。

FreeCAD选择的原因很直接：它提供完整的Python API，可以在无界面模式下运行，非常适合做服务化封装。你需要安装FreeCAD 0.21及以上版本，并确认Python环境能导入FreeCAD模块。注意Windows和Linux下的导入路径不一致，我用的是Linux的AppImage版本，需要在代码里手动加入FreeCAD的lib路径。接下来准备一个零件模板目录，每个模板是一个Python文件，里面有一个generate(params)函数，负责建模主体逻辑。

4.2 模板库的编写规范

模板库是整个系统的心脏。每一个模板对应一种零件类型，比如内六角螺钉、六角螺母、垫圈、法兰盘。模板函数的输入是经过校验的参数dict，输出是FreeCAD的Part对象。我这里给出一个极简框架，让你理解结构。

# templates/screw.py import FreeCAD as App import Part def generate(params): doc = App.newDocument("Screw") diameter = params["diameter"] length = params["length"] head_diameter = params.get("head_diameter", diameter * 1.6) head_height = params.get("head_height", diameter * 0.7) # 建螺杆 shank = Part.makeCylinder(diameter / 2, length, App.Vector(0, 0, 0)) # 建头部 head = Part.makeCylinder(head_diameter / 2, head_height, App.Vector(0, 0, length)) # 合并 screw = shank.fuse(head) # 螺纹可以省略，或通过Part.ThreadBuilder实现 obj = doc.addObject("Part::Feature", "Screw") obj.Shape = screw doc.recompute() return obj.Shape

这个例子省去了螺纹和六角孔，但已经足够说明问题。真实模板里最麻烦的是螺纹建模，建议不要直接用FreeCAD的螺纹显示功能，而是用“实际轮廓扫描”或者干脆做简化处理——用圆柱面加视觉螺纹线，除非你要做3D打印，否则大多数仿真场景不需要真实螺牙。这个取舍，做过实际项目的人都懂。

4.3 大模型接口的接入与提示词设计

LLM在这套系统里负责“把话变成JSON”。这里提示词设计非常关键。经验是：不要给模型太多自由，一定要限定输出格式和枚举值。我用的提示词模板如下：

你是机械零件参数提取助手。根据用户输入，输出JSON，包含字段：part_type（取值范围：screw/nut/washer/flange/bearing_housing/custom）、diameter（数字，单位mm）、length（数字）、material（字符串）。如果输入中没有对应字段，用null代替。不要输出任何额外文字，只输出JSON。 用户输入：一个内六角螺栓，直径8毫米，长度30毫米 输出：

这样设计之后，大模型基本不会跑偏。但依然要加一层防御性校验：解析JSON之后，检查part_type是否在枚举范围内，diameter和length是否是正数，超出合理阈值（比如diameter大于500mm）要报警。我不会把大模型的输出直接传给建模函数，因为模型一旦犯错，生成错误的模型比报错更麻烦。

4.4 参数库与标准件查表逻辑

如果没有标准件参数库，模板就只能处理“任意圆柱体”这种简单形状，无法处理真正的国标零件。参数库建立方法很简单：从GB/T、ISO标准里找一张公称尺寸与各部位尺寸的对照表，录入JSON文件。举个例子，M6、M8、M10内六角螺钉头部参数保存如下：

{ "M6": {"head_diameter": 10.0, "head_height": 6.0, "hex_width": 5.0, "hex_depth": 4.0, "pitch": 1.0}, "M8": {"head_diameter": 13.0, "head_height": 8.0, "hex_width": 6.0, "hex_depth": 4.0, "pitch": 1.25}, "M10": {"head_diameter": 16.0, "head_height": 10.0, "hex_width": 8.0, "hex_depth": 5.0, "pitch": 1.5} }

实际使用时，先根据公称直径查这个表，取出对应的头部参数，再覆盖用户指定的参数（比如用户指定了头部直径就按指定值算）。这步查表逻辑一定要写在模板之外，作为公共服务，因为不只螺钉用得到，螺栓、双头螺柱也共享这些基础尺寸数据。

4.5 端到端的调用流程示例

把以上模块串起来，一个最小调用流程如下：

import json import sys def text_to_cad(user_text): # 步骤1: LLM解析 llm_json = call_llm(user_text) # 假设已实现 params = json.loads(llm_json) # 步骤2: 校验与标准件参数补全 validate_params(params) # 枚举、范围校验 fill_standard_params(params) # 查表补全 # 步骤3: 动态导入模板并建模 module = importlib.import_module(f"templates.{params['part_type']}") shape = module.generate(params) # 步骤4: 保存为STEP和Stl Part.export([shape], output_step_path) mesh = Mesh.meshFromShape(shape, 0.1) Mesh.export([mesh], output_stl_path) return output_step_path, output_stl_path

这个系统已经可以在公司内部跑一个非常实用的场景：给采购部门发一个链接，填写“型号+尺寸”，后端自动生成STEP文件，采购直接拿这个STEP文件找供应商询价。没有依赖任何商业CAD许可证，成本极低。

5. 实测案例：三种典型输入的结果与问题

5.1 案例一：标准件——内六角螺钉

输入“M8×30内六角螺钉，304材质，全螺纹”。LLM解析结果准确，正确识别part_type为screw，diameter为8，length为30。模板生成结果与标准GB/T 70.1完全一致，头部参数通过查表得到，螺纹采用简化圆柱面。实测输出STEP文件导入SolidWorks，尺寸测量正确，实体完整性好。这个案例的成功率接近100%，是系统的看家功能。

需要注意一个细节：全螺纹和半螺纹的处理。全螺纹时螺杆全长都有螺牙，需要把螺纹起始点设在头部底面；半螺纹时螺纹长度由参数指定。这个逻辑如果漏了，生成的产品会和标准不一致，采购拿去询价会被供应商质疑。

5.2 案例二：半标准件——带法兰的轴

输入“带法兰的轴，法兰直径60，轴径25，轴长80，法兰厚度10”。这个零件不是标准件，LLM解析时part_type返回了custom，diameter提取为25，length为80，同时多出两个参数flange_diameter和flange_thickness。模板库中我提供了一个“法兰轴”的通用模板，支持这些参数。生成过程是用两个圆柱体布尔合并，法兰与轴的连接处没有做圆角。结果导入CAD后基本可用，但圆角需要手工添加。

这个问题很典型：自然语言描述常常隐含工艺要求（倒角、圆角、退刀槽），但模型不会主动识别。我的经验是在提示词里要求LLM“如果用户没有提到圆角，则不要主动添加圆角”，否则模型会猜测一堆不存在的圆角，反而坏事。对于需要圆角的场景，更稳妥的做法是模板本身提供可选圆角参数，默认关闭。

5.3 案例三：复杂描述——壳体类零件

输入“一个矩形壳体，长100，宽80，高50，壁厚3，底部四个安装孔，直径5，孔距20”。这类零件是深度学习方案的强项，但程序化模板最难搞。我的模板库没有现成壳体模板，于是临时写了一个“盒子”模板：先画一个实体长方体，然后抽壳，再通过阵列生成四个孔。结果生成成功，但壁厚3mm导致壳体内腔尺寸是94×74×44，而用户没有明确说的是内腔尺寸还是外腔尺寸。模型默认按外廓加抽壳处理，如果用户想要的是“内腔长100”，结果就错了。

这个案例暴露出语言歧义是text-to-cad目前最大的坑。同样一句话，机械工程师理解成外廓，做CNC加工的理解成内腔，做钣金的可能理解成展开尺寸。应对方法是在系统里增加交互确认环节：当参数存在歧义时，自动生成一个确认问题返回给用户，而不是闷头生成。这个环节成本不高，却能把准确率抬上一个台阶。

6. 避坑指南：text-to-cad落地中的主要障碍

6.1 别迷信拖拖拽拽的“全自动”，要设计人机协同流程

我把text-to-cad落地时踩过的坑总结成几条，每一条都是用时间和返工换来的。

第一坑是“期望管理”。很多领导看到demo觉得文字就能生成模型，以后建模工程师可以砍掉一半。实际上一套生产级的text-to-cad系统，生成的模型顶多算“初稿”。后续还需要人工检查关键尺寸、添加公差符号、确认材料、调整表面粗糙度。公司内部推广时，一定要把流程定义为“AI出初稿，工程师做审核修正”，而不是“AI替代工程师”。否则预期过高，落地必然受挫。

第二坑是“标准库维护”。标准件尺寸表不是一成不变的，新标准发布后旧表要用新数据替换。我见过有人把ISO标准抄错一个零，结果M8螺钉头部直径变成了130mm，下游供应商一脸懵。所以在查表逻辑里必须写清楚数据来源和版本号，并建议每季度校验一次。

第三坑是“螺纹到底要不要画”。很多初学者花大量时间研究螺纹精确建模，其实在生产流程里，螺纹有专门的表示方法——工程图上用简化画法，有限元分析里用等效螺纹或螺栓连接，只有3D打印或CNC加工时才需要真实螺纹轮廓。text-to-cad系统默认输出简化螺纹是正确的，不要试图追求视觉上的“精致”，否则建模时间暴增，还没什么实际收益。

第四坑是“模型精度与单位”。FreeCAD的默认单位是毫米，但如果你接入了英制文本，比如“1/4 inch bolt”，系统必须统一换算成公制再进入模板。做过一次忽略单位换算，导致生成的螺栓实体大了25.4倍，直接废掉一批测试件。单位处理一定要放在参数校验的第一位。

6.2 深度学习方案还要不要关注

老实说，深度学习生成任意CAD模型的精度和可靠性在短期内很难达到工业交付标准。但它在两个方向有潜力：一是作为“灵感生成器”，输入“一个流线型外壳”，得到一个可以借鉴形态的网格，再让工程师在CAD里重新建模；二是用于“缺失模型补全”，比如历史图纸里只有二维视图，可以用深度学习推测三维形状作为初始解。所以建议保持关注，但别赌它立刻能上产线。

7. 常见问题速查表

这些问题里，出现频率最高的是“LLM输出非JSON”和“单位换算缺失”，线上服务一定要在这两处加硬校验。比如单位换算，我建议直接在参数校验函数里做：

def normalize_length(value, unit): if unit in ("inch", "in", '"'): return value * 25.4 elif unit in ("mm", "millimeter"): return value else: raise ValueError(f"Unsupported unit: {unit}")

这看似简单，却能让系统少报废一半以上的模型。

8. 扩展思路：从“零件生成”到“装配体生成”的下一步

text-to-cad目前主要在单零件层面应用，但未来的价值在于装配体。想一想，如果输入“一个带四个轮子的底盘，每个轮子由螺栓固定”，系统能自动生成底盘、轮子、螺栓的零件模型，并组装成装配体，还生成配合关系，那工程师的重复劳动会进一步大幅减少。这依赖于装配体拓扑库和配合规则库的建设——也就是说，系统不仅要懂零件特征，还要懂“什么零件和什么零件通过什么方式配合”。

我目前的方向是给每个装配模板定义一个接口清单：比如“底座”模板有四个安装面，每个安装面预留螺栓孔；“轮子”模板有一个中心孔；“螺栓”模板有标准型号。然后通过匹配接口名自动生成配合关系。这个思路还在探索中，但至少比单纯生成零件更接近实际工程需求。

另外还有一个非常实用的扩展：结合二维图纸识别。很多工厂还有大量旧图纸只有PDF或者打印件，没有三维模型。与其直接做text-to-cad，不如先做“PDF图纸→参数提取→三维模型生成”，这等于把识别的输入从自然语言换成了图纸，后台的逻辑可以完全复用现有的模板库。这个方向我尝试过，准确率比纯文本高不少，因为图纸上的尺寸标注是结构化明确的。

最后再分享一个小心得：做这类项目，与其追求“最先进”，不如追求“最实用”。先把标准件的text-to-cad做好，让采购、工艺部门真正用起来，再逐步扩展非标件和装配体。我在实际跑这个系统的过程中，最大的感受是：技术本身不难，难的是让人接受“自动生成的东西需要审核”这个流程。只要你把这个流程设计顺了，工具的价值很快就能体现出来。