企业官网建设流程全解析

"给我生成一个M6内六角圆柱头螺栓，长度30mm。"第一次在网上看到有人用这句话直接在浏览器里生成并下载STEP文件的时候，我第一反应是又一个营销噱头。直到自己亲手跑通，把这个文件拖进FreeCAD，看着特征树里真真切切躺着一个可编辑的实体模型，才意识到text-to-cad这件事已经走到能落地用了。

简单说，text-to-cad就是通过自然语言描述，让AI直接生成可用的CAD模型文件。它解决了传统三维建模里"会画图的人和懂设计的人不是同一个"这个老大难问题——概念设计阶段，工程师脑海里的想法转成三维模型，过去要么自己啃建模软件，要么排队等专职建模的人，现在可以直接用一句话先拿到一个基础模型做方案验证。这篇文章我会围绕text-to-cad的技术原理、主流工具、实操流程和踩坑记录做一次完整梳理，适合机械工程师、创客、产品经理，以及对AI生成三维模型感兴趣但一直没弄明白"它跟AI绘画到底有什么不同"的读者。

1. text-to-cad是怎么工作的：一句自然语言如何变成几何实体

1.1 核心思路是"文本转代码"而非"文本转图形"

很多人第一次接触text-to-cad，很容易拿它跟Midjourney、Stable Diffusion做类比，以为AI是直接"画"出一个三维模型。实际完全不是这回事。目前最主流、工程可用性最高的text-to-cad方案，本质上是文本生成代码，再用代码驱动几何内核生成模型。

这条链路是这样的：你输入的自然语言 → 大语言模型理解语义并生成一段程序化建模代码（通常是Python里的CadQuery库，或者OpenSCAD脚本） → 代码在本地或云端执行 → 几何内核计算并输出STEP/STL文件。

这就解释了为什么text-to-cad生成的结果是精确的、可编辑的、带尺寸的，而不是像AI绘画那样输出一张像素图。因为LLM在一开始就没有直接去"想象"几何形状，它做的是它最擅长的事——写代码。这个思路的高明之处在于，它把"生成三维几何"这个对AI来说极其困难的连续问题，转化成了"写一段生成几何的程序"这个LLM相对擅长的离散问题。

用生活化的类比来说：AI绘画是让一个画家听了你的描述，直接画一幅画给你；text-to-cad是让一个程序员听了你的需求，帮你写了一个能生成CAD文件的程序，你自己运行一下就能在CAD软件里打开。显然后者更符合工程需求。

1.2 为什么偏偏是CadQuery：参数化建模的天然优势

搞过机械设计的朋友都知道，传统三维CAD软件里建模的核心操作其实是特征（Feature）——拉伸、旋转、打孔、倒角、阵列，每一步都记录在特征树里，模型因此是可以参数的、可回溯的、可改尺寸的。而CadQuery这个Python库，恰好就是用代码来表述"特征"的框架，它底层调用的是**OpenCascade（OCCT）**几何内核。

OCCT是一个工业级的B-Rep（边界表示）几何内核，跟FreeCAD、KiCad用的是同一套。这意味着CadQuery生成的不是一堆拼凑的三角面片（mesh），而是真正有拓扑结构的实体——有面、有边、有顶点，能进行布尔运算、倒角、抽壳，能被下游CAM软件识别用于加工路径规划。

相比另一个流行的程序化建模工具OpenSCAD，CadQuery的语法更接近传统CAD的设计直觉。OpenSCAD用的是纯函数式描述，做简单的方块减法还行，但遇到圆角、扫掠、放样这些高级特征就很别扭；CadQuery则用面向对象的方式组织建模流程，支持链式调用，写起来跟GUI操作的感觉高度一致。这也是为什么目前几家主流的text-to-cad工具都不约而同选择了CadQuery作为输出后端——它生成的文件能最大限度兼容现有的工程软件生态。

1.3 大语言模型在里面对应什么位置

大语言模型在这条链路里承担的是"语义到程序"的翻译工作。GPT-4级别以上的模型，在训练语料里见过海量的CadQuery、OpenSCAD代码，所以它能够理解"一个带通孔的圆柱体"该用什么函数、什么参数来表达，也大致了解M6螺栓意味着6mm外径、1mm螺距这些工程常识。

但LLM毕竟不是CAD专家，它对几何的理解是"概率性"的。它知道"倒角"对应chamfer()方法，但不一定能精确算对你的倒角该是0.5mm还是1.5mm；它知道"法兰"通常是一个圆盘状的凸缘，但不一定清楚法兰厚度该跟轴套总长保持什么比例。这就是为什么做text-to-cad的提示词工程如此重要——你的提示词越接近"几何语义"，LLM生成出来的代码就越可靠。

2. 工具生态盘点：2025年能用的text-to-cad方案有哪些

2.1 ZOO Text-to-CAD：把"一句话生成零件"做成了产品

先聊目前普通用户最容易上手的工具——ZOO Text-to-CAD。这个平台的思路很直接：浏览器里输入提示词，后台调用大模型生成CadQuery代码，实时预览3D效果，满意就下载STEP或STL文件。

我实测下来的感受是，对于"标准件""简单轴类零件""带孔板件"这类几何特征明确的对象，ZOO的生成成功率相当高。比如输入M8 hex nut，它会给你一个带正六边形轮廓和中心螺纹孔的实体；输入bracket with two 6mm holes，它能给出一个L形或U形的支架。

ZOO的特点在于交互设计做得好——它会把CadQuery代码同时展示在预览窗口旁边，如果你懂一点Python，甚至可以直接手动修改代码参数再重新生成，相当于把"AI生成"和"参数化设计"串在了一起。免费额度对尝鲜够用，量大的场景就需要付费了。

2.2 本地部署路线：用CadQuery+API自己搭一套

对数据保密要求高的公司，或者需要把text-to-cad批量集成到内部流程里的团队，完全可以在本地自己搭一套。

核心组件就三样：一个能调用大模型API的Python脚本、一个CadQuery环境、一个输出验证工具。工作逻辑是：把用户的自然语言提示词打包进system prompt，让模型输出规定格式的CadQuery代码，然后本地执行这段代码，最后导出STEP文件并做基本的几何校验。

这里有个关键细节：永远不要让模型直接返回文件，而是让它返回代码。因为代码是可审查的、可校验的、可追溯的，文件是一条死数据。我在实际项目中甚至会让LLM在生成代码后，再另外生成一段自检测试代码，用CadQuery的val.isValid()接口确认生成的是不是有效实体，再决定是否进入下一步。

成本方面，按目前主流API定价，生成一个中等复杂度的零件大约消耗0.1到0.5美元token，批量做成内部工具之后，单件成本能压到几毛钱人民币，在原型验证场景下性价比已经可以接受了。

2.3 别混淆：Fusion 360的"生成式设计"不是text-to-cad

还有一个常见的误区需要澄清。很多人听说Autodesk有"生成式设计"（Generative Design），以为那就是text-to-cad的官方工业版，两者完全不是一回事。

Fusion 360的生成式设计，是基于你预设的载荷、约束、材料、保留区域，由拓扑优化算法自动推演出材料分布最合理的结构形状。它解决的是"在给定力学条件下如何设计最优结构"的问题，输入是边界条件，输出是一个有机形态的网格体。而text-to-cad的方向恰恰相反——它是把你脑子里的概念描述直接翻译成可编辑的工程模型，一个是从性能反推形状，一个是从语义直译形状。两者未来可能互补，但当前是完全独立的两条技术线。

3. 实操全流程：把一个带法兰的轴套"说"出来

3.1 提示词设计：把"外观语言"翻译成"几何语义"

这是整个text-to-cad流程里最核心的一步。我发现80%的失败案例都源于同一个问题——用户用描述外观的词汇去要求一个几何引擎。

比如你输入"一个好看的支架"，LLM完全不知道该怎么办。它需要的是：一个L形支架，长边80mm，短边50mm，厚度5mm，长边远端有一个直径8mm的通孔。你在提示词里给出的几何约束越详尽、越量化，生成的结果就越接近可用状态。

通用的提示词模板我总结了一个，可以直接抄：

生成一个[零件类型]，整体外形是[基本几何描述]， 关键尺寸：[尺寸1]+[尺寸2]+[尺寸3]， 表面特征：[孔/槽/螺纹/倒角]的位置、数量、大小， 材料默认不做考虑，单位使用[毫米/英寸]， 需要导出的格式：STEP

反面教材和正面案例对比如下：

注意：text-to-cad是对真实工程物品的简化，跟Midjourney那种追求视觉华丽的提示词完全不兼容。如果不给尺寸，LLM就会按训练数据里的常见值随机填充，出来的模型99%不可用。

3.2 完整生成过程演示：法兰轴套

我用ZOO平台实际跑一个例子。最终提示词如下：

A flanged bushing, body outer diameter 30mm, inner diameter 18mm, body length 25mm, flange diameter 50mm, flange thickness 4mm, flange located at one end of the bushing, share the same axis. Four mounting holes on the flange, diameter 5mm, positioned on a bolt circle with radius 20mm, evenly spaced at 90 degrees.

需要说明的是，这里的平台操作部分基于我用ZOO和本地CadQuery的实践经验梳理，不同版本界面可能有微调，但核心流程是通用的。

提交后大约10到20秒，平台返回一段CadQuery代码，预览窗口出现模型。如果满意，直接下载STEP文件。我习惯把每个生成结果都下载后拖进FreeCAD做一次"体检"，确认实体有效性、测量关键尺寸，防止直接进入下游流程后才发现尺寸偏离。

3.3 关键代码逐段看

假设我们选择本地CadQuery方案，模型生成的代码核心部分是这样一段：

import cadquery as cq # 主体外径30mm 内径18mm 长度25mm body_outer_d = 30 body_inner_d = 18 body_length = 25 # 法兰参数 flange_d = 50 flange_t = 4 # 安装孔参数 hole_d = 5 hole_radius = 20 hole_count = 4 # 先创建主体圆柱(外径 - 内径 → 轴套壁) bushing = ( cq.Workplane("XY") .cylinder(body_length, body_outer_d / 2) .faces(">Z") .hole(body_inner_d / 2) ) # 在轴套一端创建法兰 result = ( bushing .faces(">Z") .workplane() .circle(flange_d / 2) .extrude(flange_t) ) # 在法兰面上开安装孔 result = ( result .faces(">Z") .workplane() .pushPoint((hole_radius, 0, 0)) .circle(hole_d / 2) .cutThruAll() # 旋转复制其余3个孔 .pushPoint((0, hole_radius, 0)) .circle(hole_d / 2) .cutThruAll() .pushPoint((-hole_radius, 0, 0)) .circle(hole_d / 2) .cutThruAll() .pushPoint((0, -hole_radius, 0)) .circle(hole_d / 2) .cutThruAll() ) cq.exporters.export(result, "flanged_bushing.step")

这段代码的核心逻辑值得拆一遍：先用cylinder画一个外径15mm的圆柱，用hole打出18mm的孔得到轴套壁；然后在轴套顶面新建工作平面，画一个半径25mm的圆并拉伸4mm生成法兰；最后在法兰面上定位4个点，逐个开直径5mm的贯通孔。每一行代码对应的都是一个你平时在SolidWorks里点击按钮的操作，代码跑完模型也就建好了。

这里要注意：hole()方法默认是从选定面打孔到实体另一侧，如果轴套壁没穿透就需要指定depth参数；安装孔我用了cutThruAll()确保完全贯通，这在某些工程场景下是必须的。这种细节问题，LLM十次里有三四次会漏掉，人肉检查代码时重点看这些地方。

3.4 下游处理：从STEP到可用的工程零件

拿到STEP文件只是第一步。我建议的执行流程是这样的：

1. 打开检查：用FreeCAD或任意支持的CAD软件打开，先看几何树是否干净，是否存在重复面、退化边。
2. 尺寸验证：用测量工具核对所有关键尺寸，特别是孔距、配合直径。这一步不能省，LLM对"bolt circle radius 20mm"的理解可能跟你不一样——它可能理解成直径20，也可能理解成半径20，实测经常出错。
3. 特征重构建：如果你要在自己常用的CAD里做参数化修改，最好把导入的"哑体"重新用本地特征覆盖一遍（比如删掉原孔，用自己软件的孔命令重打），这样才能获得完整的参数化能力。
4. 干涉检查：如果是装配体里的零件，生成后第一时间在装配环境里做干涉检测，尤其是配合面。

经验之谈：下载后直接用原样建模软件出图加工，现阶段风险很大。text-to-cad更适合做"方案级"验证，拿到的是讨论基础，不是最终图纸。

4. 常见问题与排查技巧实录

4.1 能预览但下载后打不开，或者打开是空实体

这个问题我至少遇到过十几次，原因基本都在单位和布尔运算失败上。CadQuery默认走毫米单位，但有些平台后端在导出时会丢单位信息；一些复杂的多实体模型在布尔求差时如果出现面重叠，会生成"无效实体"（invalid solid），CAD软件打开后表现为空白或不可选。

排查思路：先不要直接用目标CAD软件打开，改用CadQuery自己重新导入验证，在Python里执行以下检查：

import cadquery as cq part = cq.importers.importStep("flanged_bushing.step") print(part.val().isValid()) # 输出True才是有效实体

如果输出False，基本确认是布尔运算出错，让LLM换一种布尔策略重新生成（把多次cutThruAll()改成先建一个多孔集合再一次性做差）。

4.2 螺纹、倒角细节缺失，或者生成了但出不来

LLM默认倾向生成"简化模型"——你让它做螺栓，它大概率给你一个光杆加六角头，没有螺纹。这其实不是Bug，是模型对"螺栓"这个概念的默认泛化：测试集里大量代码都是简化表示的。

如果螺纹必需，提示词里必须显式声明，比如with M6 screw thread profile，或者actual helical thread, not simplified。但这一条也不是100%可靠，因为CadQuery本身的螺纹绘制就需要用到import外部库或者复杂扫掠，LLM未必每次都写得出来。

我的建议是：螺纹这类纯细节特征，用text-to-cad生成完主体结构后，自己在CAD里补。既保留效率又保证可控性，没有必要在这上面跟AI较劲。

4.3 修改提示词后结果差异巨大，不可控

这是LLM的随机性导致的。同一个提示词跑两次，结果可能一个是对的，一个完全跑偏。解决办法有两个：

一是尽量把提示词写"死"，减少歧义空间。a bracket with holes改成a flat rectangular plate, 100mm x 50mm x 5mm, with four round through holes of diameter 6mm at the four corners, each hole center 10mm from the nearest edge，AI发挥的空间被压缩到近乎为零，输出自然稳定。

二是在本地部署方案里，给API调用固定temperature（建议0到0.2之间），开启seed固定参数。温度设得越低，生成结果越稳定，代价是偶尔会有"过于保守"的倾向，但在工程场景里稳定性远比创造力重要。

4.4 生成结果尺寸对不上，整体比例失调

比如你要求法兰直径50mm、轴套外径30mm，生成结果里法兰看起来跟轴套差不多粗。这是因为LLM对"绝对数值"的敏感度远低于对"相对关系"的敏感度。它知道法兰应该比轴套大，但50对30这个具体比例它不一定算得准。

解决方法是把相对关系也写进提示词，不给它"猜"的机会：flange diameter is 50mm, which is significantly larger than the body diameter of 30mm。或者更直接，给关键尺寸加上明确的数学表达：flange_d / body_d = 50 / 30。

4.5 平台生成超时，或高复杂度零件直接失败

text-to-cad生成的零件复杂度如果超过一定阈值（比如特征超过30个、涉及扫掠/放样/多实体布尔），云端平台很容易超时。这不是你的提示词写得不好，而是LLM生成代码的可靠性在长序列下急剧下降。

我的处理原则是分而治之：把一个复杂零件拆成三到五个"可单独生成的子零件"，分别生成，最后在CAD里装配。比如一个带法兰的异形壳体，先生成壳体主体（旋转体+抽壳），再生成法兰盘，再生成加强筋，最后在CAD软件里用布尔合并。整个过程仍然比传统建模快得多，而且每一步的稳定性都大幅提升。

5. 实战效果对比与工具选型建议

5.1 text-to-cad与text-to-3D的关键区别

这两个概念经常被放在一起提，但目标完全不同。

一句话总结：text-to-3D追求的是"看起来像"，text-to-cad追求的是"造得出来"。前者服务于视觉和游戏资产行业，后者服务于工程制造行业。如果你的目标只是快速拿到一个模型做3D打印看效果，text-to-3D反而更省事；如果要进装配体做干涉检查、要出工程图、要CNC加工，那只能走text-to-cad。

5.2 什么场景真的适合用，什么场景先别用

基于我跑了上百个案例的经验，以下场景是text-to-cad目前的"舒适区"：

• 方案快速选型：同时生成三种不同结构的支架，打印出来对比装配可行性
• 标准件与非标简洁件：法兰、轴套、垫片、外壳底座、固定块
• 教学演示：让学生直观看到"文本描述如何被翻译成特征操作"
• 个人创客原型：丢给3D打印机之前快速验证外形和孔位
• 设计沟通：跟客户/同事对齐"我要的零件大概长这样"

不建议用的场景：

• 复杂装配体设计：一个有几百个零件、互相约束的产品，text-to-cad完全无能为力
• 外观设计导向的零件：消费电子外壳、汽车内饰这些形态自由度高的对象，网格生成方式更合适
• 需要严格公差标注的零件：AI生成的是几何，不是工艺，GD&T公差标注还得靠人
• 批量标准件选型：有现成标准件库的情况下，没必要让AI重新"发明"一个M8螺母

5.3 这条路的下一步会往哪走

从发展趋势看，text-to-cad正在从"单轮生成"走向"多轮对话式设计"。当前工具基本都是你给一句话，它出一个结果，不满意再重新写一句话——这个体验其实还停留在搜索引擎早期阶段。真正工程化的方向应该是：能基于上一轮结果做局部修改，比如"法兰厚度再厚2mm，安装孔改成腰形槽"，而不是每次都从零生成。

另一个值得关注的方向是text-to-cad跟仿真分析的联动。既然生成的是带参数的实体会话模型，那在STEP文件落地之前，直接让AI调用一个轻量级仿真求解器做快速强度校核，不满足条件就自动调整参数重新生成，相当于把"设计-仿真-迭代"链路压缩到分钟级。目前已经有一些科研团队在探索这个方向，估计一两年内会有产品化落地。

我自己现在的工作流是：概念阶段用text-to-cad先丢出三五个候选方案，STEP文件统一拖进FreeCAD做尺寸复核，选定后导入Fusion 360做详细设计。从一句自然语言到第一个可讨论的原型，过去最快也得半天，现在基本十分钟内能搞定，这省下来的时间全都能花在真正值钱的方案权衡和细节推敲上。

最后补充一个自己的体会：text-to-cad输出的是"方案的起点"，不是"设计的终点"。别指望一句prompt能替代工程师的设计判断。把AI当合作伙伴，而不是替代者，这个工具才会真正为你创造价值。这也是我特别想把这篇实战记录整理出来的原因——希望大家少走弯路，尽快越过"生成即垃圾，不知如何调整"的挫败阶段，真正用起来。