企业官网建设流程全解析

Text-to-CAD 这个词，我 2024 年在开发者社区第一次看到的时候，第一反应是“又来一个炒概念的”。在制造业界折腾了这么多年，我很清楚 CAD 模型不是一张渲染图，STEP 文件里那些 B-rep 面、边、环，背后全是设计意图和加工约束。直到自己亲手把一句话变成能导入 FreeCAD、能输出给加工厂的 STEP 文件，我才意识到这次不是噱头——它是把“想法到模型”这条链路真正剪短了。

这篇文章就围绕 text-to-cad 展开：它是什么、底层靠什么跑通、现在有哪些工具能直接上手、以及我踩过的一堆坑。适合机械工程师、创客、独立开发者，还有对 AI 生成 3D 内容好奇的同学。我会尽量少讲空话，多给能直接照抄的操作路径和排查经验。

1. Text-to-CAD 是什么：从自然语言到可制造模型

1.1 一句话定义与核心价值

Text-to-CAD，简单说就是输入一段自然语言描述，比如“一个 L 形支架，底板长 40mm，宽 20mm，厚 5mm，竖板高 30mm，底板上开两个直径 8mm 的通孔”，模型直接给你一个可编辑、可参数化的 CAD 模型文件。

核心价值不在“能生成一个 3D 模型”，而在“生成的是 CAD 模型”。这两句话差别非常大：普通的 AI 生图模型给的是像素，text-to-3D 给的是三角网格（STL/OBJ），而 text-to-CAD 给的是参数化实体模型，通常是 STEP 格式，包含精确的几何拓扑，能直接进 CAM 做刀路、能进 CAE 做仿真、能改参数重新生成。这意味着它输出的不是“看起来像的东西”，而是“能拿去加工的东西”。

我自己的理解是，text-to-CAD 的本质是让模型学会“用 CAD 的语言表达一个产品”。就像你让一个经验丰富的工程师画草图，他脑袋里想的不只是形状，还有“这地方要倒角、那地方要留配合间隙”。现在这个能力开始被模型替代一部分了。

1.2 和 Text-to-3D 的根本区别

很多人会把 text-to-CAD 和 text-to-3D 混为一谈，但其实完全是两个物种。text-to-3D 的代表如 Shap-E、Point-E 这类工具，输出的是点云或者网格，适合游戏资产、动画、渲染展示。网格模型的问题是没有拓扑信息，你没法在 CAD 软件里选中一个圆孔的边去改直径，更没法把它作为加工依据。

Text-to-CAD 走的是另一条路：它生成的是建模流程，比如先画草图、再拉伸、再打孔、再倒角。用我常跟朋友打的比方——text-to-3D 给你的是泥塑，表面好看但内部是实心的，改起来只能捏；text-to-CAD 给你的是加工图纸和步骤，每一刀怎么下都写清楚了，随时可以改。

所以如果你只是想要一张炫酷的产品图，text-to-3D 就够了；但如果你要的是能生产、能装配、能做公差分析的实体模型，那必须走 text-to-CAD。

1.3 为什么是现在才火

Text-to-CAD 的爆火不是凭空冒出来的，它是几个条件同时成熟的结果。

第一，大语言模型到了能稳定写代码的程度。CAD 建模本质上有很强的程序化语法，CadQuery、OpenSCAD 这些工具已经把建模抽象成可执行的代码，这让模型可以用“写代码”的方式输出建模过程。第二，CAD 领域积累了大量高质量的数据集，比如 ABC Dataset 里有上百万个 STEP 格式的真实模型，DeepCAD 数据集里有接近 18 万个从 Onshape 上解析出来的真实模型操作序列，这些正好是大模型最爱的语料。第三，云端推理和沙箱执行环境成熟了，模型生成代码后，可以自动在后端执行、校验、转格式，最后把 STEP 发给你。

这三个条件缺一个，text-to-cad 都只是实验室里的玩具。现在它已经是能跑通的工程方案了。

2. 技术拆解：模型到底在生成什么

2.1 三条主流技术路线

我研究过目前开源和商业项目里的主流做法，基本可以分成三条路线，每一条对“CAD 模型”的理解都不一样，这也是最值得掰开讲的部分。

第一条是代码生成路线。代表是 Zoo 在 2024 年放出来的 Text-to-CAD，我记得它是基于开源大模型微调出来的，输出的是 CadQuery 的 Python 代码。模型生成代码后，系统在沙箱里执行，把代码转换成完整的 STEP 文件。这条路线的最大好处是每个人都能读、能改、能复现，而且 CadQuery 背后的 OpenCascade 内核本身很成熟，能保证生成的实体模型是严格正确的。

第二条是命令序列预测路线。代表是 DeepCAD 和一些后续的 Text2CAD 研究。这类做法不直接生成代码，而是把 CAD 建模过程表示成一串离散 token——先画什么草图、用什么约束、拉伸多少、倒角多少。模型像生成一句话一样生成这串 token，然后用专门的几何引擎把 token 重建成实体。优势是推理速度快、规模容易控制，劣势是可编辑性差，你想改一个参数就得重新跑一遍模型。

第三条是目前还在快速演进的扩散模型路线。有人试着把扩散模型用在 B-rep 的图结构上，直接生成面、边、顶点的拓扑关系。这个方向学术价值很高，但离产品化还有距离。

我自己实际工作中最常用的是第一条路线。原因很简单：代码是中间表示，如果模型出了一点小毛病，我能直接看到是哪句代码有问题，甚至手动改掉，而不用重新生成。

2.2 数据与 Tokenization 背后的功夫

不管哪条路线，都绕不开数据和 token 化。CAD 模型不像文本那样天然是一串字，必须先把几何和操作转成模型能理解的形式。

以 DeepCAD 这类做法为例，一个模型会被解析成类似这样的操作序列：画一个圆心在某个坐标、半径为 10 的圆，然后向上拉伸 5mm，再在边缘倒一个 1mm 的圆角。每个操作和参数都会被量化成离散的 token，比如半径这一项会被切到 256 或 1024 个区间。模型的任务就是预测接下来该出现哪些操作和参数。这跟语言模型预测下一个词本质上是同一件事。

而代码生成路线更直接，模型只是在学“代码语法 + CAD API 的使用规律”，训练时把十几万个真实 CAD 模型的对应 CadQuery 脚本喂进去，再用 GPT-4 之类的大模型为每个模型生成文字描述，配对成指令微调数据。等模型看到一句话时，它就能联想出对应的脚本风格。

这里面最花功夫的不是模型结构，而是数据清洗。真实 CAD 模型往往是几十个步骤堆积出来的，很多步骤对最终形状没有影响，直接拿原始操作序列训练，模型会学出一堆废话。所以要做“化简”，去掉冗余操作、合并共线线段、规范坐标系，才能得到干净的训练样本。这块工作没有捷径，全是体力活。

2.3 为什么大模型擅长生成 CAD 代码

我自己觉得，大模型在 CAD 这件事上比在写小说上可靠得多，原因是 CAD 代码的“语法性”极强。你写一句诗，可以有无数种解读；但 CadQuery 里box(40, 20, 5)就只能是长 40、宽 20、高 5 的长方体。大模型在约束明确的 DSL（领域专用语言）里发挥是非常稳定的。

更重要的是，CAD 建模过程有很多“套路”：开孔之前要先在面上新建工作平面、要切除就得先有实体、倒角要选边而不是选面。这些套路就是顺序决策问题，而 Transformer 这类模型恰恰擅长捕捉长程依赖。模型学会了“先拉伸成板，再在顶面上打孔”这类顺序逻辑，输出自然就比随机堆操作靠谱得多。

另一个不可忽视的点是，代码是可校验的。模型写错了一句 API，执行引擎会报错，你可以把报错信息原样贴回去让模型自己改。这种“生成—执行—反馈—修复”的闭环是 text-to-CAD 能走向实用的关键，也是纯文生模型做不到的。

3. 实操：跑通你的第一个 Text-to-CAD 工作流

3.1 工具选型

目前能直接上手的 text-to-CAD 工具，我按用途分成三类。

第一类是商业化在线服务，最典型的就是 Zoo 的 Text-to-CAD。在官网输入描述就能生成，也可以走 API 批量调用。它输出 CadQuery 代码和 STEP 文件，对非程序员特别友好，适合快速验证想法。

第二类是开源研究项目，比如 Text2CAD 这样的仓库。它们通常包含完整的训练、推理和重建代码，但部署成本偏高，还需要自己下数据集和 checkpoint。适合想做研究或者想深入理解原理的人，不适合只想拿结果的生产环境。

第三类是自己搭的“LLM + CadQuery”工作流。你手头已经有了 ChatGPT / Claude 这类代码能力很强的大模型，只是让它专门输出 CadQuery 脚本，在本地执行预览。这条路线可控性最高，我日常用的就是这一种。

选型建议很简单：如果你只是好奇，直接用在线服务，五分钟就能看到结果；如果你想在生产里稳定复现，建议走本地 CadQuery 路线；如果你要发论文或者调模型，再去碰开源研究项目。

3.2 在线与 API 快速体验

在线体验真的很省事。到 Zoo 的 Text-to-CAD 页面，在输入框里用英文或中文描述你的需求，提交后等十几秒到几十秒，它会给你一段 CadQuery 代码和一个可下载的 STEP 文件。

如果要把这个过程接进自己的脚本，可以用 Replicate 之类的推理平台。大致流程是：注册拿到 API token，安装 Python SDK，提交 prompt，轮询结果。代码很少，核心就这几步：

import replicate client = replicate.Client(api_token="你的token") prediction = client.predictions.create( model="zoo-ai/text-to-cad", input={"prompt": "A simple L-shaped bracket, base 40mm x 20mm x 5mm, vertical plate 30mm high, two through holes of diameter 8mm on the base."} ) result = prediction.wait() print(result.output)

注意模型标识符可能会随平台更新变化，跑之前先看官方文档确认一下最新的名称。在线服务适合做批量测试，比如你想比较 10 个不同 prompt 的效果，写个循环调 API 就行了。

还有一个技巧：大部分在线服务的输入框支持多行描述，你可以直接把需求写详细，不用缩写。模型对“详细描述”的容错度比“模糊描述”高得多。

3.3 本地 DIY：用 CadQuery 加 LLM 搭一个

如果你希望完全掌控生成过程，我推荐本地搭一个“LLM + CadQuery”工作流。步骤不复杂，环境配置一次后面就顺了。

第一步，安装 CadQuery。建议在 Python 3.8 以上的虚拟环境里执行pip install cadquery。在 Linux 和 macOS 上通常很顺利，Windows 上需要确保有合适的预编译 wheel，如果装不上，可以考虑用 WSL 或者官方 Docker 镜像。

第二步，准备一个支持代码的 LLM 客户端。我用的是 Claude 的 API 加一个简单的前端脚本，也可以用 ChatGPT 的代码解释器，甚至是本地部署的 Qwen、Llama，只要能稳定输出 Python 代码就行。

第三步，设计你的 prompt。这一步是最关键的，我后面专门讲。模型会输出一段 CadQuery 脚本，比如这样：

import cadquery as cq # 一个 50x30x5mm 的板，中心开一个直径 6mm 的通孔 result = ( cq.Workplane("XY") .box(50, 30, 5) .faces(">Z") .workplane() .circle(3) .cutThruAll() ) cq.exporters.export(result, "plate.step")

第四步，在 CQ-editor 或者启用了 CadQuery 扩展的 Jupyter 里运行代码。你可以在 notebook 里调用show_object(result)做 3D 预览，确认形状对不对、孔位对不对、方向对不对。

第五步，导出。CadQuery 支持cq.exporters.export(result, "filename.step")输出 STEP 文件，也可以输出 STL 做 3D 打印切片。STEP 是首选，它保留了实体拓扑，后续在 FreeCAD、SolidWorks、Fusion 360 里都能继续编辑。

这个小工作流看起来简单，但它解决了最核心的问题：模型只负责“写代码”，而你拥有最终的裁决权。代码错了可以改，几何错了可以量，每一步都可追溯。

3.4 Prompt 工程核心技巧

Text-to-CAD 的 prompt 和写文书不一样，不能只描述外观，得描述“建模步骤”。我总结了四个字：具体、步骤化。

第一，把单位写死。模型默认视 mm 为单位，但如果你描述的是“两英寸长的板”，模型可能还是按 2mm 输出，出来就是 50 倍的大小误差。所以我每条 prompt 都会显式带上单位：“单位为 mm”。

第二，按建模顺序描述，而不是按视觉顺序描述。比如你要一个带孔的底座，不要只说“中间有孔的方形座”，而要拆成“先创建一个 50x30x5mm 的长方体；然后在顶面中心开一个直径 6mm 的通孔”。模型对步骤化描述的理解准确率高得多，因为它本来就是在学操作序列。

第三，限制 API 范围。在 prompt 里明确要求“只使用 CadQuery 标准 API，如 Workplane、box、circle、extrude、cutThruAll、fillet、union”。这样能大幅减少模型幻觉出不存在的函数。

第四，留好迭代空间。第一次生成很少一次到位，拿到结果后，把错误信息或者尺寸偏差贴回去，让模型“根据这个 error 修正”。这比重新描述一遍需求有效得多。

我可以分享一个我自己的 prompt 模板：

请用 CadQuery 生成一个参数化模型，单位为 mm。 需求： 1. 先创建一个底板，长 40，宽 20，厚 5。 2. 在底板长边的一侧创建竖板，高 30，厚 5。 3. 竖板顶部倒 R2 圆角。 4. 底板上沿中心线等距开两个直径 8 的通孔，孔间距 24。 约束：只使用 CadQuery 标准 API，输出可运行的 Python 脚本，不要额外的解释。

用了这个模板之后，成功率比“帮我画个 L 形支架”高出一大截。

4. 落地场景与影响范围

4.1 三类立刻能落地的场景

第一个场景是概念设计和方案比选。以前工程师要出三个概念方案，得各自建模，一个下午就过去了。现在你把三个方案的文字描述丢给模型，十分钟能拿到三个 STEP 文件，再在 CAD 里细化和评估。它不替代你的设计能力，但替代了“把脑子里想法变成可讨论实体”的时间。

第二个场景是非标件和小批量定制。我见过不少做设备集成、工装夹具的团队，经常要为一块挡板、一个电机支架建模型。这些件结构简单，但很烦人，卡住就得半小时。用 text-to-CAD 生成初稿，再人工修正孔位和公差，能压缩掉大半时间。尤其对独立开发者和三人小团队，这个提效非常直观。

第三个场景是教育和入门教学。以前教学生认识 CAD 模型，得先教软件操作，学生卡在界面里出不来。现在可以让学生直接描述一个物体，然后看模型生成步骤代码——他看到的不是一个结果，而是一连串建模逻辑。这对理解“草图—拉伸—特征”的工作流反而更直接。当然，这只适合作为辅助教学手段，不能替代规范的软件操作训练。

4.2 对工程师工作方式的影响

很多人担心 text-to-CAD 会取代机械工程师，我的判断是不会，至少在可预见的时间内不会。它取代的不是工程判断，而是“把自己想法翻译成 CAD 指令”这个偏执行层的环节。

这跟集成开发环境对程序员的影响很像。IDE 不会让程序员失业，它只是把“记住所有 API 拼写”这件事外包给了工具，让程序员把精力放在架构和逻辑上。text-to-CAD 对外行的意义是降低了建模门槛，对工程师的意义是降低了重复劳动。

但影响范围是实在的：它会改变初阶 CAD 工程师的成长路径。以前入行得靠大量画图练出手感，以后可能是靠“描述设计意图并审查 AI 输出”的能力。我对新人的建议一直是：可以早点学会用这些工具，但必须自己动手把每一步几何关系搞清楚，否则你连模型错在哪都看不出来。

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

5.1 生成失败与 API 报错

我在实际使用中遇到最多的问题，是模型输出了一段看起来没问题但一运行就报错的代码。CadQuery 的报错信息通常很直白，比如调用了不存在的方法、参数传了负数、工作平面选择语法不对。

处理办法有两个。第一，在 prompt 里锁死 API 范围，这是预防。第二，把完整报错信息原样复制回给模型，让它自己修。我试过很多次，让模型修自己的代码，成功率比重新写一段还高，因为它能看到具体错误。

如果代码能运行但结果异常，比如缺了一个孔、多了一块体，这时候靠改 prompt 往往不如直接改代码来得快。我通常会把导出的 STEP 文件先转回代码看一遍，定位到具体某个extrude或cutThruAll行，手动调节参数再重新导出。这就是选代码生成路线的好处——可以人机协作。

5.2 单位与几何错误

有一个特别隐蔽的坑：模型会“理解”尺寸，但不一定“尊重”尺寸。你说“直径 3mm 的孔”，它可能生成半径 3mm 的孔，整整大了一倍。所以拿到模型后第一件事是量尺寸，而不是看形状像不像。

导出 STEP 后，我习惯用 FreeCAD 或者 CadQuery 的boundingBox做一次快速校核：

bb = result.val().BoundingBox() print(bb.xlen, bb.ylen, bb.zlen)

如果整体尺寸差得离谱，大概率是单位或半径/直径的语义理解出了问题。尺寸对但位置不对，比如孔偏了，就回去改代码里的坐标或pushPoints参数。

另外一个常见几何问题是布尔运算失败。两块体刚好共面，或者有零厚度的缝合边，union或者cut会直接报错。解决办法是在 prompt 里避免设计共面结构，或者代码里留出极小的间隙。实在不行就先分体导出，在真正 CAD 软件里做布尔运算，那边容错更好。

5.3 从结果到实物的质量检查

生成模型最终要走到加工，所以质量检查不能省。我整理了一个排查清单，每次生成后按顺序过一遍：

这五条都过了，我才会把文件发给加工或者切片软件。行业里的真实项目，精度和公差是靠工程师控制的，AI 生成结果只能当“毛坯”。

5.4 一批实用避坑技巧

最后分享几个我用下来的小技巧，都是常规文档里不会写的。

一是描述里尽量少用“好看”“圆润”这类模糊形容词，大模型对美学词的理解不稳定。你要圆角就直接写“给顶边倒 R2 圆角”，效果完全不同。

二是复杂零件一定要拆分。一次让模型生成整体复杂的装配体，大概率翻车。我习惯把一个零件拆成几个子部件，分别生成，再用 CadQuery 的union或直接在 CAD 软件里组装。子部件越简单，成功率越高。

三是善用“生成两版”的策略。同样的 prompt 提交两次，模型可能给出不同方案。其中一版出错，另一版可能就是对的。在线服务有随机性，这是免费的多样性。

四是我个人很推荐的：不要只看渲染结果，一定要切开看剖面。很多模型表面光鲜，内部孔道是断的。对非关键零件影响不大，但对需要走管线或装配的零件就是致命的。提前剖视能省下不少返工时间。

我自己在实际操作中的体会是，text-to-CAD 现阶段最舒服的定位是“设计初稿生成器”，而不是“设计器”。一个合格工程师需要的能力依然没变：判断尺寸合不合理、工艺能不能落地、装配有没有干涉。AI 只是把画图的时间从一小时压到一分钟，剩下的判断你必须拿回来自己把关。后面如果再遇到什么新坑，我继续补在这篇里。