企业官网建设流程全解析

最近几个月，我陆续在几个机械设计社群里看到有人讨论text-to-cad这个玩法，就是直接打字告诉AI“我要一个M6内六角螺栓”，它就能给你生成一个可以编辑、可以出工程图、可以拿去加工的CAD模型。早期这类工具生成的多是花哨的网格雕塑，好看但没法进制造流程，现在这帮人做出来的东西已经能直接打开参数化特征树了。

我花了两周时间把主流的几个 text-to-cad 方案都试了一遍，包括 Zoo 的公开测试版、两个基于 Llama 微调的本地模型，以及拿 GPT-4V 配合 OpenSCAD 手搓的偏门路子。这篇文章把我踩过的坑、总结的提示词模板、以及不同工具背后的原理差异完整写出来，想上手的人可以直接照着抄作业。

1. 从文本到 CAD 模型，这门技术到底改变了什么

先说结论：文本直接生成 CAD，不是要把设计师干掉，而是把“从想法到可编辑参数模型”这段最烦琐的路径打通。过去从一句需求到拿到一个能改尺寸的模型，至少经过概念草图、三维建模、特征调整三个环节，现在第一个环节被压没了。

1.1 传统建模流程的痛点

我最早是用 SolidWorks 做非标设备的，最熟悉的路径是这样的：先画草图，再拉伸、旋转、打孔、倒角，最后把尺寸约束表整理好。遇到改版，改一个关键尺寸，后面关联的圆角和孔位经常跟着崩，又要花时间修草图关系。这套流程本身没问题，问题在于它把“描述需求”和“构造特征”这两件事强行绑定在同一个步骤里。

你脑子里的想法其实是一句话：“底板长300，宽200，四周四个直径8的沉头孔，中间开一个40x40的方槽。”但软件听不懂这句话，你得手动把它翻译成草图线和特征命令。text-to-cad 想做的就是跳过手动翻译，直接让模型理解这句话，并输出对应的参数化建模代码。

1.2 为什么是 CAD 而不是生成 Mesh 或图片

早期 AI 生成三维内容，主流路径是生成三角网格（Mesh），比如点云重建、神经辐射场（NeRF）之类的，输出结果是一层表面，好看，但改不了参数，也没法直接进 CNC 加工或 3D 打印切片。

CAD 的底层数据结构完全不一样，它记录的是“特征历史树”，比如“先拉伸一个长方体，再在顶面打一个直径10的孔”。这个特征树是结构化、可编辑、可参数化的。text-to-cad 真正突破的点就在这里：它让模型学会了输出这种结构化描述，而不是一堆三角形顶点。

打个比方，Mesh 生成像是给你一张照片，你能看到样子，但改不了里面人物的表情。CAD 生成像是给你一份 PPT 源文件，每个文本框、每张图都能双击编辑。对于制造业来说，源文件才有价值。

1.3 适用人群：谁现在就能用上，谁还要等等

我实测下来，最受益的是这几类人：

• 机械设计工程师：做标准件、连接件、简单壳体时，一句话生成基础模型，再进软件微调，能省一半时间。
• 创客和硬件爱好者：想要一个 Raspberry Pi 外壳，不用再从零学建模软件，文本生成后直接导出 STL 打印。
• 非标自动化方案设计：前期做方案对比时，需要快速出概念模型，不需要精确公差，text-to-cad 输出的参数模型正好够用。

暂时不太适合的是做复杂曲面产品的工业设计师。像汽车覆盖件、鼠标曲面这类需要 A 级曲面（Class A）的场合，现阶段的 text-to-cad 还搞不定，毕竟曲面质量和连续性不是文本能描述清楚的。

2. 核心原理拆解：AI 凭什么能“看懂”一句话并写出建模指令

想用好这个工具，不能只当黑盒。我花了不少时间读相关论文和开源代码，把底层逻辑捋清楚了。说白了，text-to-cad 本质上是一个“文本到代码”的生成任务，只不过这个代码不是普通的 Python，而是 CAD 建模指令。

2.1 CAD 模型的表示方法：B-rep、CSG 和特征历史

要让 AI 学会生成 CAD，先得让 CAD 变成 AI 能理解的数据格式。目前主流的表示方法有三种：

边界表示（B-rep，Boundary Representation）是目前商用 CAD 内核最常用的数据结构，它用“面-边-顶点”的拓扑关系描述实体。B-rep 的好处是精确，适合加工，但缺点是数据格式非常复杂，直接让 AI 生成 B-rep 很难，因为拓扑关系稍有错误就是一个不闭合的废模型。

构造实体几何（CSG，Constructive Solid Geometry）用布尔运算组合基本体，比如“长方体A 减去 圆柱体B”，再把两个体做并集。CSG 表达简洁，树形结构清晰，很适合 AI 生成。缺点是不太好表达倒角、圆角这类操作，而机械零件恰恰离不开倒角。

特征历史（Feature History）是 SolidWorks、Fusion 360 这类参数化建模软件内部记录的操作序列，比如拉伸、旋转、打孔、阵列。特征历史既有布尔运算的逻辑，又保留了参数，还带有顺序依赖关系，是最理想的 AI 输出格式。Zoo 的 Text-to-CAD 就是走的这条路，生成结果是可编辑的特征历史。

2.2 把建模操作翻译成“代码语言”

现在主流模型的做法，是把建模 SDK 的调用封装成文本格式，让大语言模型去生成这段文本。

最典型的例子是 Zoo 的 Text-to-CAD，它内部基于 Zoo Kit（一个 Zdog 的建模内核库），用类似 TypeScript 的代码描述建模操作。你输入“M8 六角螺母”，模型输出的是一段代码，定义了一个六棱柱和一个带内螺纹的圆柱孔，再通过布尔运算合成。

另一个路子是使用 OpenSCAD 作为后端。OpenSCAD 本身就是程序化建模工具，它的脚本语言直接支持 CSG 运算，非常适合做 AI 生成的目标。我一度用 Llama-3 微调模型直接生成 OpenSCAD 脚本，配合自动语法检查和预览，效果也能用，只是对复杂零件的理解不如专门了训练的商业模型。

从模型角度看，把这些建模代码作为训练语料，用海量的 CAD 模型库（比如 ABC Dataset、Fusion 360 Gallery）去喂 Transformer 模型。模型学到的不是“螺母长什么样”，而是“构建一个可接受的螺母，代码应该怎么写”。这是个非常关键的思维转换。

2.3 为什么纯文本输出比直接调用 API 更靠谱

可能有人会问：为什么不直接让 AI 输出一个最终的三维模型文件，而是绕一圈输出代码？

核心原因是可分步验证。代码可以检查语法、逐条执行，执行到哪一步出错一目了然。而直接输出三维模型文件，一旦出了问题，很难定位是哪个几何操作导致的。代码是天然的可解释中间表示。

另外，代码可以编辑。AI 生成的模型看不懂内部结构时，你可以直接改代码里的参数。这一点在实际工作中太重要了——没有哪个设计师愿意用完全无法修改的“黑盒模型”。

我在验证文本生成结果时，通常让模型同时输出两样东西：一段建模脚本和一段自然语言描述，描述里注明关键尺寸和约束关系。这样做有双重好处，一方面方便复查逻辑，另一方面出问题时可以快速定位是尺寸错误还是几何拓扑错误。

3. 主流工具横向实测：Zoo、本地开源方案和偏门组合拳

这个领域发展太快，我建议想用的人分三条路线去评估。我把三种方案都实测了，各自的优缺点列出来，方便按自己需求选型。

3.1 Zoo Text-to-CAD：当前最接近“能直接干活”的方案

Zoo 是从前谷歌 X 实验室的团队出来的，主打用 AI 生成可参数化的 CAD 模型。我测的是它的公开 alpha 版本，目前免费。功能上，它支持文本输入、参数化调整、导出 STEP/STL 格式。

实际体验：

• 输入“a flathead M3 screw, 6mm length”这类工业描述，它能生成带螺纹的模型，而且螺纹不是装饰性的表面纹理，是可参与装配的实体螺纹。
• 生成速度在10到30秒之间，复杂模型更慢。
• 生成结果在浏览器里直接预览，带一个简单的参数面板，可以拖动调整关键尺寸。

比较惊艳的点是它对机械标准件的理解度，比如螺丝、螺母、垫片、导轨、法兰盘这类常见件，生成的模型几何关系基本正确。但要注意，它用的是自己的 Zoo 内核，不是 SolidWorks 内核，生成结果导入 Fusion 360 或 SolidWorks 时可能会有特征丢失，需要通过 STEP 格式中转。

3.2 完全本地部署的 Text2CAD 开源方案

如果你有数据隐私要求，或者想在离线环境跑，可以考虑本地部署开源方案。目前 GitHub 上有一些把 Llama-2/Llama-3 微调成“CAD 代码生成器”的项目，比较典型的是 Text2CAD（论文 + 开源代码）。

这类方案的原理：

• 用 Fusion 360 的 API 文档作为知识库。
• 用海量 CAD 模型及其建模历史作为训练数据。
• 微调 LLM，使其学会输出符合 Fusion 360 API 调用的 Python 代码。

实际体验：

• 生成质量远不如 Zoo，尤其是复杂装配体，逻辑很容易混乱，生成的代码经常报错。
• 但它胜在完全离线、可控、可定制。我可以在它的基础上加一层规则校验，确保生成的代码只调用我指定的 API 子集。

如果你要走这条路，我的建议是不要直接让它生成最终模型，而是让它生成“建模方案描述+关键尺寸”，再让本地脚本把方案转成模型。这样模型即使写错代码，也不会影响整体流程。

3.3 偏门组合拳：大语言模型 + OpenSCAD + 参数模板

第三个方案是我自己搭的，适合手里有大模型 API 的开发者。思路很简单：构建一个 OpenSCAD 参数化模板库，大模型只负责从模板库里挑选合适模板并填写参数。

比如我预定义一个“带孔底板”模板，里面含length、width、thickness、hole_diameter、hole_spacing这些参数。用户输入“200 毫米长 150 毫米宽、厚 5 毫米、四角 8 毫米孔”描述，模型只需要把自然语言映射到参数值，再调用模板渲染。

这套方案的优点是准确性极高，因为模板是我自己写的，几何逻辑绝对正确。缺点是覆盖范围有限，只能做我预定义过的零件类型。但它适合企业内部的标准化零件库场景，直接把自己的零件库模板和 LLM 对接，形成“内部标准件文本生成系统”。

为了直观对比，我把三种方案的关键差异整理成一张表：

4. 实操全流程：从一句需求到可加工的 CAD 文件

接下来这部分是最能直接用的。我以开源的 Spoon 项目为例，拆解从文本提示到生成可用的 CAD 模型的完整操作流程。Spoon 是 2023 年底开源的一个 text-to-cad 项目，底层也用 LLM 驱动，支持直接生成 STEP 文件。流程同样适用于 Zoo 之类的工具，因为核心都在提示词和验证环节。

4.1 环境准备与安装

Spoon 的安装我建议用 Docker，一个命令拉起所有依赖，省心。以下是在 Ubuntu 22.04 上的实操记录。

先克隆项目代码：

git clone https://github.com/lingtxyz/spoon.git cd spoon

然后构建 Docker 镜像：

docker build -t spoon .

这里有几个坑要提醒。镜像比较大，第一次构建可能要十分钟以上，做好心理准备。如果服务器在国内，构建过程中拉取基础镜像或 Python 包经常超时，建议配置镜像加速器。最好提前把 Docker 的 DNS 设置好，否则后面调用 API 时域名解析不了，排查起来很头疼。

构建完成后启动服务：

docker run -it --rm -p 8000:8000 spoon

启动后访问http://localhost:8000，能看到 Web 界面。我用下来感觉最稳定的方式是通过 REST API 调用，Web 界面适合做演示和快速验证。

Spoon 默认需要配置大模型 API 密钥。项目里支持 OpenAI 兼容接口，所以你可以用官方 API，也可以用本地部署的模型。我因为数据敏感性考虑，在实验室里用了自建的模型网关，按 OpenAI 格式配置，改动很小。

4.2 提示词工程：准确描述一个 CAD 模型的技巧

文本生成 CAD 的核心在提示词。我试了几十次后总结出一套可复用的模板，能显著提高生成成功率。

先看一个标准的提示词：

Create a STEP file of a slotted flat head machine screw. Specifications: - Thread size: M4 - Thread pitch: 0.7 mm - Length: 16 mm - Head diameter: 7 mm - Head height: 2.2 mm - Slot width: 1.2 mm - Slot depth: 0.8 mm

这套提示词的关键点：

明确标准：直接说 M4、0.7 pitch，让模型能查到标准件参数，而不是自己瞎猜。

给几何参数：head diameter、head height 这些尺寸帮助模型快速定位头型。

指定输出格式：明确说 STEP 文件，避免模型输出一个可交互预览或其他格式。

说明视图方向：对非对称零件，我通常还会补充“the slot is aligned with the Y axis”之类的话，确保方位正确。

对比一下失败案例，错误提示词：

Make me a screw

这种写法生成的结果基本没法用，因为“screw”太泛了，模型只能猜，猜错概率极大。

再分享一个高级技巧：对复杂零件，先用自然语言描述整体结构，再分步骤描述特征。比如：

Generate a STEP file of a bearing housing. The housing is a rectangular block: - Length: 80 mm - Width: 40 mm - Height: 30 mm On the top face, create a cylindrical bore: - Diameter: 25 mm - Depth: 20 mm, through all Add 4 mounting holes at the bottom corners: - Diameter: 6.6 mm - Counterbore: 11 mm diameter, 6.5 mm deep - Hole spacing: length 60 mm, width 20 mm, symmetrical

这种结构化的描述方式，模型理解起来容易很多。本质上，这是在用“特征历史”的思维去组织语言。

4.3 生成过程与结果验证

在 Spoon 的 Web 界面里输入提示词后，点击生成，后台会先调用大模型生成 CAD 脚本，然后交给内核解析执行。正常流程下 15 秒左右就能看到结果。

拿到生成结果不要急着导入软件，先做三步检查：

第一步，检查步骤树。如果是 Zoo，看左侧特征树里是不是包含了预期步骤，比如“拉伸-打孔-倒角”。如果只有单个布尔运算，说明模型偷懒了，后续改参数很难。

第二步，检查关键尺寸。用界面自带的测量工具，抽查提示词里提到的关键尺寸，比如螺纹直径、孔距。我经常发现模型生成的模型里，尺寸和文本请求不一致，可能是它的内部换算有问题。

第三步，导出 STEP 并重新导入。我用 FreeCAD 做这一步，主要验证文件是否损坏、拓扑是否正确。FreeCAD 对 STEP 支持良好，而且免费。

实测中我发现，Spoon 和 Zoo 生成的 STEP 文件导入 FreeCAD 后，绝大多数情况下模型能正常显示，但偶尔会出现面片缺失或缝合问题。这种情况下不要尝试在 FreeCAD 里修复了，直接把提示词里的关键尺寸再明确一次，重新生成。修复一个 broken 的 STEP 通常比重新生成更耗时。

4.4 直接调用 API 的自动化流程

如果想把 text-to-cad 集成到内部工具链，Web 界面不够用，我建议直接走 API。Spoon 和 Zoo 都提供 REST API，大致流程是：提交生成任务，轮询状态，结果完成后下载文件。

伪代码示意：

import requests import time API_URL = "http://localhost:8000" headers = {"Authorization": "Bearer YOUR_API_KEY"} # 提交任务 response = requests.post( f"{API_URL}/api/generate", headers=headers, json={ "prompt": "M4 slotted flat head screw, length 16mm, generate STEP", "format": "step" } ) task_id = response.json()["task_id"] # 轮询状态 while True: status = requests.get( f"{API_URL}/api/tasks/{task_id}", headers=headers ).json() if status["state"] == "succeeded": break time.sleep(2) # 下载结果 result_url = status["result"]["download_url"] model_file = requests.get(result_url).content with open("output.step", "wb") as f: f.write(model_file)

把这个流程包装成一个函数，就能批量生成标准件库了。我建议做好任务队列，因为生成任务很重，并发太多会把服务打崩。

5. 常见问题与故障排查实录

我把两周里遇到的所有坑整理了一遍，这里挑最常见的五个，给排查思路。

5.1 生成的模型是空壳，不是实体

典型表现：导入 FreeCAD 后看起来有东西，但剖开一看是片体，不是实体。

原因分析：这类问题大多是底层几何内核的布尔运算失败导致的。尤其是螺母的螺纹建模，需要非常精确的曲面求交，模型输出的参数稍有偏差，求交就失败。

排查思路：

• 先看日志里有没有报布尔运算失败的记录。Spoon 的日志里会明确写Boolean operation failed。
• 检查提示词里是否包含了会冲突的尺寸，比如孔直径大于底板的宽度。
• 不要一开始就生成带螺纹的零件，先用不带螺纹的版本测试流程，通了再加上。

这种问题目前没有有效的程序化修复手段，只能修改提示词重新生成。我在实践中会把“几何简单”放在提示词第一位，比如不要求生成螺纹细节，而是用简化几何表示，生成成功后再在 CAD 里加真实螺纹。

5.2 提示词没问题，但生成的零件方向反了

典型表现：孔位在 X 方向，实际生成在 Y 方向。

原因分析：大模型对空间方向的泛化能力并不强，尤其是在没有明确指定坐标系的情况下，它倾向于把长边放在 X 轴，但这可能不符合你的预期。

排查思路：

• 在提示词里显式加一句“the long dimension is along X axis”。
• 对轴对称零件，生成后再统一旋转，这个可以在代码里自动完成。
• 如果你用的工具支持二次编辑，直接在参数面板里调整方向。

这个问题的规律是：提示词越短，方向出错的概率越高。信息丰富度很重要。

5.3 API 返回超时，但服务没有崩溃

我遇到过一次 API 调用 120 秒才返回的现象，直接触发了客户端超时。

原因分析：复杂模型的生成时间本来就长，加上服务器资源有限，队列里若有多个任务排队，单个任务的响应时间会指数级增长。

排查思路：

• 把客户端的超时时间从 30 秒调大到 300 秒。
• 用异步任务队列替代同步等待，也就是前面伪代码里轮询的方式。
• 检查服务器内存。我实测发现，内存不足时生成速度会骤降，因为这触发了 swap。强烈建议给容器分配至少 8GB 内存。

5.4 生成的模型完全不符合几何逻辑

典型表现：输入“a bracket with two holes”，生成的模型只有一个 L 型板，没有孔。

原因分析：这常发生在模型对文本特征的理解遗漏。本质是提示词中特征描述不够突出。模型有注意力机制，如果前面的铺垫描述太长，核心特征词会被淹没。

排查思路：

• 把核心特征放到提示词最开头，比如第一句就是“Create a bracket with two through holes”。
• 避免使用“some”“a few”这类模糊数量词，直接写“two holes”。
• 如果仍然不行，把整个特征重新用一句话明确描述。

我自己的经验是：给模型一个结构化的提示词模板，成功率能提升到 80% 以上。模糊自然语言的成功率只有三四成。

5.5 生成的 STEP 文件导入 SolidWorks 后特征树是空的

典型表现：Zoo 生成的 STEP 在浏览器里看没问题，但导入 SolidWorks 后是一个“哑体”（无特征树）。

原因分析：这是格式本身的限制。STEP 格式只保存几何和拓扑，不保存建模历史。你在 Zoo 里看到的特征树，导出成 STEP 后确实就丢了。

排查思路：

• 如果需要特征树，直接复制 Zoo 生成的建模脚本，在你的 CAD 软件里重放，而不是导 STEP。
• 或者使用中间格式导入，比如导入为 BREP 再转换。Fusion 360 对这类文件的兼容性比 SolidWorks 稍好一点。

这是所有 text-to-cad 工具在联调阶段都容易忽略的问题。如果你要的不是最终模型，而是可编辑的建模过程，一定要确认工具支持导出原生参数化格式，比如 Zoo 的.zoo文件或 Fusion 360 的.f3d，而不是 STEP。

6. 我在实际使用中的几点体会

最后分享一些实操经验，想到哪说到哪。

第一，把 text-to-cad 当作“参数化标准件自动生成器”来用，别当作“万能建模器”。现阶段它对标准件、板类零件、简单壳体、连接件这类规则几何的理解已经很好，一旦涉及复杂曲面、装配约束、公差标注，基本帮不上忙。

第二，多准备几个版本的提示词模板。我在本地建了一个提示词库，按零件类型分类。比如“螺栓类”“轴承座类”“钣金件类”，每种分类下有几套已验证可用的模板。这样再来新需求时，改参数就能用，不用每次从头写。

第三，生成结果一定要过一遍人工检查。我用过几次直接拿生成结果去 3D 打印，偶尔遇到模型上有一个微小但致命的几何错误，比如孔没有完全贯穿，打印出来才发现，浪费时间又浪费材料。就算 text-to-cad 以后变得再强，最终作为工程交付物的审核环节是省不掉的。

第四，注意用“工艺可行性”来描述模型，而不是用“视觉外观”。一个很典型的案例：你输入“一个漂亮的支架”，模型可能会给你生成一个有复杂曲面的东西，好看，但没法加工。你换一种说法“a simple L-shaped bracket with two mounting holes, suitable for CNC machining from aluminum plate”，生成的模型才真正能进入产线。text-to-cad 背后的模型其实更重视文本的精确性，越接近加工语言，结果越可用。

这个方向的技术还在快速演进中，但就目前的成熟度而言，text-to-cad 已经不只是极客玩具了。它在你处理标准件、概念模型、前期方案验证时能节省大量时间，值得花一个下午试一遍，它会让你重新思考“建模”这件事本身。