企业官网建设流程全解析

画一个法兰盘需要多久？如果按传统CAD流程，建草图、画中心线、拉伸出外圆、挖内孔、布置螺栓孔、阵列、加倒角，熟练的工程师也得五六分钟。但最近我试了一轮Text-to-CAD工具，输入一句“一个外径60毫米、内径12毫米、6个直径5毫米均布螺栓孔、厚度5毫米的法兰盘”，几秒钟后直接拿到了一个可以导出STEP的实体模型。这不是demo里的炫技，而是机械工程和生成式AI交叉地带正在发生的真实变化。

这篇文章我想把“Text-to-CAD如何用代码直接生成工业零件图纸”这件事讲透。不是堆概念，而是从原理、工具实测、翻车案例到落地建议，把我实际试出来的经验和坑一起聊完。适合机械工程师、CAD二次开发人员，也适合那些做产品设计但每次都被“画图”卡住的朋友。

1. 为什么“用代码画图”这件事，对机械设计是个真需求

1.1 传统CAD工作流里最浪费时间的一环

很多非机械行业的人以为，工程师画图最大的成本是“把形状画出来”。实际上不是。真正吃时间的是改图和生成变体。客户说“孔间距往右移5毫米”，你要进草图、改约束，然后担心关联的特征会不会跟着崩；领导说“给这个零件出三个不同壁厚的方案”，你可能要重复三遍建模操作，或者小心翼翼地调整特征树参数。

这种工作流的本质是：几何形状被锁定在图形界面里，重复操作很难自动化。你虽然在用参数化建模软件，但每次“修改”依然高度依赖人肉操作。

我自己做机械设计这些年，最烦躁的不是复杂零件，而是那些结构相似、参数不同的系列件。每次都要重新画，纯属体力劳动。这种痛感，是理解Text-to-CAD价值的前提——它不是替你把图纸“变漂亮”，而是把机械设计里最机械的那部分工作自动化。

1.2 “代码即图纸”早就存在：从AutoLISP到CadQuery

如果只说“用代码生成图纸”，这其实是机械行业的老传统。早在AutoCAD时代就有AutoLISP，后人用参数化族表、方程式驱动曲线，本质上都是把几何关系写进代码。更典型的是OpenSCAD，从诞生第一天起就是靠写代码建模。现在还有CadQuery、SolidPython这类Python库，把“拉伸”“打孔”“倒角”这些操作变成函数调用。

代码建模的好处非常明显。第一，可复用，写一次，换参数就能生成整个零件族；第二，可版本管理，git能管理代码，就能管理带注释的模型生成历史；第三，可审查，几何逻辑一行行摆在那，出错能定位。

但过去这套方案门槛高，你得会编程，得懂几何API，还得能接受“在文本编辑器里设计零件”的原始感。所以它一直是小众玩法，没能大规模普及。

1.3 生成式AI补上了“自然语言到代码”这块短板

Text-to-CAD之所以在最近一两年火起来，不是因为程序化建模新，而是因为大语言模型把最后一道门槛拆掉了：你不需要会写CadQuery代码，只需要能准确地描述你要什么零件。

LLM最擅长的事情之一，就是把自然语言转换成结构化的代码。CAD建模恰好是高度程序化的几何构建过程——一个法兰盘就是“圆柱体减去内孔、再在圆周阵列的位置挖掉几个圆柱”。LLM只要能把“法兰盘”“均布孔”“外径”这些语义映射成正确的几何操作，几何内核就能输出精确的实体模型。

所以Text-to-CAD的本质可以概括成一句话：它不是一个“画图AI”，而是一个“翻译器”，把人的设计意图翻译成几何内核能执行的代码，再由代码生成精确模型。这一点理解了，后面很多工具选择和翻车原因就都好解释了。

2. 从文本到可加工图纸：Text-to-CAD背后的几何生成逻辑

2.1 自然语言描述是怎么变成几何实体的

把一个自然语言描述变成CAD实体，至少要经过三层语义映射。

第一层是零件类别识别。模型需要知道“法兰盘”意味着什么：一个回转体、带中心孔、周围有螺栓孔。第二层是参数抽取。外径60、内径12、螺栓孔直径5、厚度5，这些数字必须从文本中被准确拎出来。第三层是几何关系解析。“6个均布螺栓孔”意味着要在圆周方向做360度/6的阵列；“内孔与外圆同心”意味着两段草图的圆心要重合。

这三层里，LLM在第一层和第二层表现已经相当好，因为本质上就是“阅读理解”。第三层最容易出问题，尤其是涉及公差、配合、沉孔深度这类工业语义时，模型经常不自洽。比如你说“M8螺栓通孔”，它可能给你生成一个直径8毫米的孔——但实际M8通孔应该用8.4或者8.5毫米。这就是后面翻车的一大来源。

2.2 两条技术路线：直接回归3D vs 生成代码调内核

现在市面上的Text-to-CAD方案，技术路线大致分两类。

第一类是让神经网络直接回归几何，比如预测体素（Voxel）、点云、或者带符号距离场（TSDF），然后把离散结果拟合成曲面。这条路的好处是“看起来更像AI”，端到端训练，输入文本直接出网格。但缺点是精度不够，工业零件要的是小数点后好几位的精确尺寸，神经网络直接输出的网格本质上是一堆三角形近似，离“可加工”差得很远，而且没有特征树，后续修改极其困难。

第二类路线是LLM生成程序化建模代码，再交给传统几何内核去计算。最典型的就是基于CadQuery的方案：AI输出Python代码，CadQuery调用OpenCascade内核，生成精确的B-rep实体。这条路没有“画图”，本质上是一种代码生成，但效果反而最实用，因为几何精度交给成熟的CAD内核兜底，LLM只需要管代码逻辑正确。

目前能实际生成STEP模型的工具，大多是第二条路线。少数走第一条路线的项目，比如生成2D矢量图的MLC-CAD，输出的是SVG，不是完整的工业模型。这两条路线各有存在的价值，但如果你追求“可直接加工”，第二条路线是当前唯一靠谱的选择。

2.3 为什么输出STEP比输出STL更关键

很多不接触制造业的人分不清STEP和STL的区别。STL是网格格式，用一堆三角形去贴合曲面，适合3D打印展示，但进了CAM或者有限元软件里，精度和拓扑都有问题。STEP是边界表示模型（B-rep），里面存的是真实的几何曲面和拓扑关系，是工业软件之间交换数据的标准格式。

Text-to-CAD到底有没有用，就看它能不能导出STEP。能导出STEP，意味着这个模型可以进CAM生成刀路、可以进ANSYS做仿真、可以进CMM做检测编程。如果只能导出STL，那它在工业流程里基本是个玩具。

但有一点必须清醒：就算导出了STEP，也不是完整的“工程图纸”。工程图纸还包含尺寸标注、公差、粗糙度、标题栏、技术要求这些信息。Text-to-CAD目前生成的是“几何体”，不是“生产图纸”。这个边界感，决定你怎么正确使用它。

3. 四款代表性工具实测：从安装到生成一张工业零件图

3.1 工具选型对比

我这一轮选出四类有代表性的方案做了实测：Zoo Text-to-CAD、MLC-CAD、CadQuery加LLM脚本、OpenSCAD加LLM脚本。选它们不是因为只有这四款，而是因为它们覆盖了两种技术路线、两种输出精度、两种使用难度。

从表格能看出来，实用性和难度基本成正比。Zoo最省事，但Prompt可控性比纯代码差一点。CadQuery加LLM脚本最灵活，但要求你至少看得懂Python。

3.2 Zoo实测：用一句话生成法兰盘

Zoo是我最早试的一个。它是网页版，不需要本地装环境。核心思路就是输入一个描述，生成基于CadQuery的脚本，然后在后端跑出模型，最后让你下载STEP。

我用的Prompt是这样的：

Create a flange with outer diameter 60mm, inner hole diameter 12mm, 6 bolt holes of diameter 5mm equally spaced on a 50mm bolt circle, thickness 5mm.

生成结果基本正确，外圆、内孔、六个螺栓孔的位置关系都对。导出STEP后，我直接拖进FreeCAD检查，几何是可用的，没有破面。

这里多说一句：Zoo这一套看似玄学，其实本质就是把自然语言翻译成了下面这种CadQuery代码：

import cadquery as cq flange = (cq.Workplane("XY") .circle(30) # 外圆半径30 .circle(6) # 内孔半径6 .extrude(5) # 厚度5 .faces(">Z") .workplane() .pushPoints([(25, 0), (12.5, 21.65), (-12.5, 21.65), (-25, 0), (-12.5, -21.65), (12.5, -21.65)]) .hole(5)) cq.exporters.export(flange, "flange.step")

注意那六个坐标点，就是六个螺栓孔在直径50mm圆周上的位置。这个例子很好地说明了我说过的观点：AI画图，画的是代码。

3.3 MLC-CAD实测：文本生成2D矢量图纸

MLC-CAD走的路线不太一样。它输入文本，输出的是SVG格式的2D矢量轮廓。你可以理解成：它不生成实体模型，而是生成一张“零件的轮廓草图”。

我用它输入“a simple wrench outline”这类描述，图形轮廓大致能看出是个扳手，但细节比较粗糙，直线和弧线的过渡明显有近似痕迹。把它导入CAD软件，需要重新整理曲线才能继续用。

所以我对MLC-CAD这类工具的定位是：它适合在设计早期做“视觉发散”，给设计师看“这个形状大概长什么样”，但离真正的参数化设计还很远。它相当于一个“带形状意识的草图板”，而不是设计工具的替代品。

3.4 用LLM直接写CadQuery/OpenSCAD的玩法

除了专门的Text-to-CAD平台，还有一个非常实用的玩法：直接用现成的ChatGPT/Claude生成CadQuery或OpenSCAD代码，然后本地运行。

我不是开玩笑，这可能是当前工程落地最顺的一条路。比如我想做一个轴套，直接让LLM写代码：

import cadquery as cq bushing = (cq.Workplane("XY") .circle(15) # 外径Ø30 .circle(8) # 内孔Ø16 .extrude(20) # 长度20 .edges("|Z").fillet(1.0) # 两端棱边倒R1 cq.exporters.export(bushing, "bushing.step")

在本地装一个CadQuery环境，把代码跑一遍，就能拿到STEP。这种方式的好处是：每一步几何操作都在代码里，想改哪里改哪里。如果你熟悉OpenSCAD，同样逻辑也成立：

module flange(od=60, id=12, thickness=5, hole_circle=50, holes=6, hole_d=5) { difference() { cylinder(h=thickness, d=od, $fn=64); cylinder(h=thickness, d=id, $fn=64); for (i = [0:holes-1]) { rotate([0, 0, i * 360 / holes]) translate([hole_circle/2, 0, -1]) cylinder(h=thickness+2, d=hole_d, $fn=32); } } } flange();

这个参数化的法兰模块，以后换任何尺寸，只要改参数就行。比起重新画图，效率完全不在一个量级。

4. 生成式CAD的翻车现场与边界判断

4.1 翻车案例：看着对，一加工就废

我不能只报喜不报忧。这一轮实测里，翻车案例不少。最典型的一个是让AI生成“带沉孔的安装板”，Prompt写的是“6个直径6mm的沉孔，沉头直径11mm，深度6mm”。结果模型出来，沉孔位置在3D视图里看着很正常，但一量尺寸发现沉孔深度做成了贯穿，而且底孔的直径没有按设计意图留出配合间隙。

这种问题在屏幕上看不出来，因为你视觉上看到的只是“有个孔”，但拿到加工师傅那边就是废件。还有一个高频翻车是螺纹孔。你说“M8螺纹孔”，AI经常只生成一个直径8的光孔，没有底孔概念，也不知道M8底孔应该钻6.8左右，更不会自动加倒角。纯粹从几何表达上，它确实生成了一段圆柱腔体，但完全不具备螺纹的工艺语义。

4.2 常见的四类问题归类

把这一堆问题归纳起来，我总结出四类常见毛病。

这四个问题里，最危险的不是误差大，而是“看起来没问题”。误差大你一眼能看出来，但“看起来正常”的模型往往会直接流到下游。所以任何生成式CAD结果，都必须走一遍设计评审，不能跳过。

4.3 可验证性：生成结果必须能回到参数化树里改

我踩过一个更隐蔽的坑：生成模型是不可编辑的。有些工具为了生成速度，直接把几何结果存成网格导出，导致你在CAD里打开后，特征树是空的，只有一个“导入几何”。这种模型一旦要改，只能从头再生成一轮，完全没法做局部修改。

这也是我强烈建议优先选“代码驱动”方案的原因。CadQuery脚本生成的结果，本质上保留的是“如何构建这个模型”的方法。你觉得某个倒角半径不对，直接改代码里那个数字，再跑一遍，就得到新的STEP。这种可返工性，在工程环境里极其宝贵。

我个人的工作习惯是：生成模型后，一律先导入FreeCAD查看特征树和几何检查结果。FreeCAD里有一个“几何检查”功能，能发现很多肉眼看不出来的破面和拓扑错误。如果这一步检测出来一堆问题，直接放弃这个方案，回到Prompt或代码层去调整，而不是在GUI里修。

5. 机械工程师怎么把Text-to-CAD接进现有工作流，以及给它留什么位置

5.1 最适合切入的三个位置

用了一段时间后，我最大的感受是：Text-to-CAD当前最适合切入的是三个位置，而不是“所有零件都用AI生成”。

第一，概念设计与方案比选。项目前期要快速比对外形、工艺可行性，用自然语言出一个粗略模型，比手动建模快得多。反正是用来讨论的，细节后面再补。

第二，参数化零件族批量生成。同一个零件换尺寸出一批变体，这是Text-to-CAD最舒服的场景。只要把参数列清楚，让AI生成一个CadQuery脚本，之后批量改参数跑一遍就行。

第三，工装夹具的快速草稿。很多工装外形简单，但数量多、改得快。用AI生成毛坯模型，确认后再精修，效率提升非常明显。

5.2 不适合做什么

Text-to-CAD不适合所有“重要”的零件。具体来说，高精度传动件（齿轮、蜗杆）、铸件分型面、有严格GD&T要求的核心结构件，这些领域模型根本没有工业经验数据可依赖，硬要生成也只能得到一个外形参考。

复杂装配体和运动关系也不要指望它。当前主流方案都是单体建模，你没法用一句话生成一个带配合、带自由度约束的完整机构。这是技术路线上暂时无法跨越的边界。

5.3 给工程师的落地建议

结合我自己这一轮的实操，我有几条非常具体的建议。

第一，建立属于你自己的Prompt模板库。不要每次临时想描述。把常用零件整理成固定句式，比如“外径XX、内径XX、厚度XX、N个均布孔、倒角Cx”，写清楚单位，写清楚公差要求。模型的表现会稳定很多。

第二，把生成结果当“外购毛坯”对待。也就是说，拿到AI生成的模型，默认它不可靠，必须经过你的设计评审、尺寸核实、标准件对照之后才能流向下游。不要因为“AI生成快”就放松警惕，AI生得越快，你错得越快。

第三，涉及公司产品数据和内部图纸，不要上传到公有云端AI。这个不只是效率问题。你让第三方模型生成一个带螺纹孔的支架，等于把零件的几何特征和组合逻辑发给了别人。有些公司图纸本身就是技术资产，用之前一定先问合规。

第四，有条件的话，学一点CadQuery或OpenSCAD。不用精通，能看懂生成的代码、能改一个数字，就够了。这样你就从“用AI”变成了“完全控制AI”，可返工性和可维护性完全不一样。

我目前的工作流是：概念阶段用Zoo快速出几个方案，选定方向后用CadQuery脚本生成参数化模板，再导入FreeCAD做几何检查，最后才进入正式的CAD环境补工程信息。整个过程里，AI承担的是“从0到1”的初稿生成，人承担的是“从1到100”的工程化。这个分工，未来很长一段时间应该都不会变。