Text-to-CAD实战：用自然语言生成可编辑STEP模型

做了十年机械设计，再往前数几年，天天跟CAD打交道最烦的三件事：装完CAD发现缺SHX字体，图纸莫名打不开；想卸载重装又卸不干净，二次授权直接卡住；画个法兰盘改了三版尺寸，模型树里全是失败特征。这些热搜词背后的画面太熟悉了。所以当text-to-cad这个方向火起来的时候，我第一反应是——终于有人想换个思路解决"画图"这件事了。

text-to-cad说人话就是：把"我想画一个M8的内六角螺栓，头部直径12，有效螺纹长度20"这种话直接丢给程序，它给你吐出一个能编辑、能导出STEP、能塞进SolidWorks或Fusion 360的实体模型。不是贴图，不是网格，是正经的CAD实体。这篇文章我把原理、工具选型、实操流程和踩过的坑一次讲透，内容偏工程向，适合做机械结构、产品设计，或者想用AI提效的工程师。

1. 从"画图"到"说图"：text-to-cad到底改了什么

1.1 传统CAD的日常：百分之八十的精力耗在"怎么画"上

你回忆一下自己用CAD的一天：打开软件，先解决字体缺失警告，SHX找不到就随便替换，反正看着差不多。画个零件，先想该用哪个命令，F命令突然用不了，原来是视图方向的问题。装配体改个尺寸，关联特征连环报错，模型树红成一片。更别提面对一堆散图的时候，图纸合并、layout导入操作，每一步都有一堆参数要调。我见过太多工程师，包括我自己早期，每天百分之八十的时间不是在"设计"，而是在跟软件操作周旋。

我做钣金件的时候更是如此，金林钣金CAD版这种插件为什么有人用？因为传统CAD里做展开图要手动算折弯扣除、K因子，一不留神算错了，下料就废了。这些痛点不是CAD不好，而是**"把脑子里的想法变成几何实体"这个过程本身太慢**。text-to-cad切入的正是这个环节。

1.2 核心价值：把"几何意图"变成"对话意图"

传统建模是你告诉软件"怎么画"——用哪个草图命令、画几条线、加什么约束、拉伸多少毫米。text-to-cad是你告诉程序"要什么"——零件是什么、大概什么形状、关键尺寸多少、有什么加工特征。底层的算法帮你把几何意图翻译成具体的建模操作序列。

我举个例子。你想画一个带六个螺栓孔的法兰盘。传统做法：画圆、拉伸、再画六个小圆、阵列、布尔减、倒角，一共至少六七个步骤。text-to-cad的做法：输入"直径100mm的法兰，中心孔30mm，6个均布的直径8mm螺栓孔，PCD 80mm"，程序自动规划出建模流程，直接出结果。

差距最大的是什么？不是那几分钟的建模时间，而是对"可修改性"的影响。程序生成的模型，参数改起来比手动建模还要方便——你只要改一句文本描述，重新生成就行。这在概念设计阶段特别有价值，因为那时候方案一天要变好几版。

1.3 这个赛道现在有什么能用的工具

目前我能确认可用、而且实际测试过的方案大致分三类：

其中Zoo的Text-to-CAD是风向标式的产品，它的API输出的是原生BRep格式，可以直接转STEP，精度比网格建模高一个量级。但它是闭源托管服务，要联网、要Key、可能要排队。CadQuery这条路线自由度更高，后面第五章我会详细讲怎么用它搭一个本地text-to-cad工作流。

2. 拆开看原理：大模型凭什么能"听懂"几何描述

2.1 最务实的落地路径：程序化建模

text-to-cad的实现原理，网上聊得玄乎，但拆开就三条路：程序化建模、BRep直接生成、以及离工程很远的网格/点云生成。真正能用在工业环境里的是前两种，而程序化建模是目前绝大多数开源方案的首选。

什么叫程序化建模？就是写代码生成模型。CadQuery、OpenSCAD、SolidPython都属于这一类。你写一段Python代码，描述"加一个20mm高的圆柱，在顶部挖一个直径10mm的孔"，代码执行后交给CAD内核（一般是OCCT）算实体，导出STEP。

大模型在这里的作用是什么？它是一个**"需求翻译器"**。它把自然语言翻译成CadQuery的API调用序列。你说"画一个法兰盘"，它知道法兰盘大概长什么样，然后生成对应代码。它本质上是在做代码生成，只不过代码的领域是几何建模。这也是为什么开源路线可行——LLM写代码的能力已经被验证得很充分了，而CadQuery的语法本身又足够简单，小模型都能写个八九不离十。

2.2 Zoo Text-to-CAD的推理链路：跳过代码直接生成BRep

Zoo走了一条更激进的路：不让LLM生成代码，而是让模型直接输出BRep格式的几何数据。BRep是CAD内核真正存储实体的方式——有面、有边、有拓扑关系。Zoo的模型内部有ECC（Extrude-Cut-Chamfer）这样的原语架构，通过预测挤出、切割、倒角的参数组合，直接构造出几何实体。

听起来很美好，实际用下来的感受是：几何正确性比代码生成路线更稳。因为代码路线有一个致命问题——代码写对了不代表几何就对，布尔运算失败是常有的事。Zoo把几何操作这个环节封装进去，减少了出错的概率。缺点就是闭源、收费、而且目前只能处理它见过的"典型操作组合"，太怪异的几何需求还是不行。

2.3 为什么网格生成路线走不通

现在有很多AI生成3D模型的技术是基于扩散模型直接生成网格（Mesh），或者生成点云再重建曲面。这类方案看起来酷炫，demo视频里什么都能生成。但工程上一用就露馅：网格模型没有拓扑关系，不能编辑特征，更谈不上约束和容差。你转成STEP导入CAD里，就是一堆没有特征的壳，想改孔径？只能重建。

换句话说，text-to-cad的难点从来不是"生成一个看起来像的物体"，而是"生成一个符合工程语义、能继续编辑的实体"。这也是这个方向跟其他AI生成3D最大的不同。

3. 方案选型：免费开源路线和商业托管API的取舍

3.1 先看一张对比表：不是所有text-to-cad都一样

我实际把几条路线都跑通了，踩了不少坑，直接说结论：

3.2 什么时候用Zoo，什么时候自己搭

如果项目时间紧、模型要求可靠，而且预算允许，Zoo是省心的选择。我拿它生成过一些标准件和简单结构件，基本一次成型，很少出现破面或者布尔失败。缺点除了钱，就是延迟和限流——高峰期排队严重的时候，一个简单零件等上半分钟都正常。

如果项目对数据安全有要求，或者需要高度定制输出格式，那就走CadQuery + LLM的自建路线。比如我需要把生成的模型自动加图号、塞进特定目录、直接出BOM，这类工作只有自己搭才能做到。而且自建路线的可编辑性是最好的，LLM生成的代码存下来就是一个参数化建模脚本，后面想改尺寸，直接改代码里的数字。

我自己目前的主力方案是：批量出概念模型用Zoo，需要长期维护的零件用CadQuery自建。两条线并存，不矛盾。

3.3 自建路线的推荐架构

python版本的架构大概是这个逻辑：

自然语言描述 ↓ LLM提示词工程（把需求转成CadQuery代码） ↓ CadQuery执行代码，生成实体 ↓ OCCT内核计算、检查几何有效性 ↓ 导出STEP/DXF/glTF ↓ CAD软件打开验证

关键技术点在于前面那个"LLM提示词工程"。我用的提示词模板有固定结构：目标描述 + 尺寸单位 + 关键尺寸列表 + 建模约束（比如"所有孔必须贯穿"）+ 输出格式要求。后面第五章实操里我会放一个完整示例。

4. 实操：从"一个M8六角头螺栓"到可编辑的STEP文件

4.1 环境准备

我假设你已经装好了Python 3.10或更高版本。CadQuery的安装很简单：

pip install cadquery

如果想用Zoo的API，去KittyCAD官网注册Key。不想注册也能跑通本地路线。

需要注意一个坑：CadQuery和Jupyter配合最顺，因为它自带show()可以预览。但在纯脚本环境里，要导出STEP再拿CAD软件看。我建议从一开始就建立"生成→导出→验证"的习惯，不要信任屏幕预览。

4.2 第一个示例：用CadQuery生成法兰盘

先用传统CadQuery手写一个法兰盘的代码，让你感受一下程序化建模的语法：

import cadquery as cq # 法兰盘：外径100，中心孔30，6个均布φ8孔，PCD 80 result = ( cq.Workplane("XY") .circle(50) # 外圆半径50 .extrude(10) # 拉伸10mm .faces(">Z") # 选顶面 .workplane() .hole(30) # 中心孔 .faces(">Z") .workplane() .pushPoints([(40 * a, 0) for a in [0, 60, 120, 180, 240, 300]]) # 均布6点，半径40 .hole(8) # 钻孔 .edges(">Z") .fillet(1) # 顶部边倒角1mm ) # 导出STEP cq.exporters.export(result, "flange.step")

这段代码的逻辑很直白：画圆→拉伸→选面→打孔→阵列打孔→倒角。跑完会得到flange.step，直接拖进任何CAD软件都能打开编辑。

4.3 让LLM来做这件事

现在关键一步：把我刚才手写的代码，换成让LLM生成。提示词我实测这个写法最稳：

你是CAD建模专家。请根据需求生成CadQuery Python代码： 零件：法兰盘 外径：100mm 厚度：10mm 中心孔：直径30mm 螺栓孔：6个，直径8mm，均布在直径80mm的圆上（PCD 80） 顶部边缘倒角1mm 要求： 1. 使用cadquery库，所有尺寸单位为mm 2. 生成完整可执行的Python代码 3. 只输出代码，不要解释

这个提示词的关键是把尺寸和约束一次给全，不让LLM瞎猜。我试过只写"生成一个法兰盘"，结果它默认给了一堆莫名其妙的参数。写清楚"外径100、厚度10、PCD 80"之后，生成结果基本稳定。

跑出来的代码结构比我手写的还规整。而且你会发现一个好处：改需求就是改文本。"把PCD改成90mm"——重新生成一次，代码里的数字自动变，比手动改参数树还快。

4.4 用Zoo的Text-to-CAD出更复杂的模型

遇到CadQuery代码生成搞不定的复杂几何，比如有曲面、有复杂过渡的结构件，我会切到Zoo API。调用方式其实就是一个POST请求，但它背后的模型做了很多几何推理工作。

import requests url = "https://api.zoo.dev/v1/tt/cad" headers = {"Authorization": "Bearer {YOUR_API_KEY}", "Content-Type": "application/json"} payload = { "prompt": "M8 hex bolt, head across flats 13mm, head height 6.5mm, shaft diameter 8mm, shaft length 40mm, thread pitch 1.25mm", "format": "step" } r = requests.post(url, json=payload, headers=headers) with open("m8_bolt.step", "wb") as f: f.write(r.content)

输出是STEP文件，直接能用在装配体里。我多说一句：Zoo对不同提示词风格的敏感度很高。写"M8 bolt"和写"M8 hex bolt, head across flats 13mm"得到的结果根本不是一回事，后者几乎能精确还原国标尺寸。提示词要给全，这里的技巧我放第五章讲。

4.5 生成结果的验证清单

拿到生成模型别急着用，一定要做下面这些检查：

• 尺寸验证：在CAD里量关键尺寸，确认单位是毫米、数值符合预期。出现过LLM把"PCD 80"写成"radius 80"导致螺栓孔跑到外圆外面的情况。
• 几何检查：跑一下CAD的自带检查，看有没有破面、干涉。
• 干涉分析：如果是装配体，导入装配环境做干涉检查，text-to-cad生成的零件经常在装配配合上出问题。

5. 踩坑记录：我在实际测试中遇到的四个问题

5.1 单位漂移：LLM的"毫米幻觉"

第一次用Zoo生成一个轴类零件，提示词里明确写了"diameter 20mm"，导出来一量——直径0.02米，数值没错，但单位变成了米。这说明模型内心深处会把数值和单位拆开处理，单位预测错了。这个问题的解决方式很粗暴：在提示词里加一句"All dimensions are in millimeters. Do not include units in the output."实测有效，出错的概率下降很多。

CadQuery路线没有这个问题，因为代码里写死的就是毫米。但如果你接的是FreeCAD，它的内部单位是毫米没错，导出设置里可能会变成英寸，注意检查。

5.2 特征顺序错误导致布尔运算失败

我让LLM生成"一个带沉孔的安装板"，结果它先生成沉孔、再生成底板，两个特征在空间上重合，布尔减失败，整个模型报错。教训是：提示词里必须明确特征的先后顺序，比如"先创建底板，然后在底板上打孔，最后在孔口做沉头"。实际代码里，特征是顺序依赖的，LLM不懂CAD的建模顺序，你要替它规划好。

这个问题的本质是：text-to-cad模型目前对"几何操作顺序"的推理能力还偏弱。它知道什么是沉孔，但不知道沉孔必须依附在已有实体上。我现在的提示词模板里专门有一栏"建模步骤"，强制LLM按顺序输出。

5.3 参数化不足：生成一次就"死"了

用Zoo生成的STEP文件导入SolidWorks，模型树里只有一个输入实体，没有特征历史。你想改孔径？没门，只能重做。相比之下，CadQuery生成的代码保留了全部参数，改一个数字就重新生成。所以我的经验是：

需要反复修改的零件，永远走CadQuery代码生成路线；一次性概念验证，才用Zoo出网格或STEP。

5.4 提示词工程：真的比想象中重要

最后说说提示词。很多人用text-to-cad觉得"不好用"，八成是提示词写得太笼统。"画一个齿轮"——模型确实会生成一个齿轮，但模数、齿数、压力角全是模型自己"猜"的，大概率不是你要的。正确的姿势是像给加工厂下图纸一样写提示词。我会把关键尺寸、公差等级、表面处理、建模约束全写进去。以下是目前我的模板：

零件名称：驱动法兰 材质：6061铝合金 外形：圆形法兰盘，外径120mm，厚度15mm 中心孔：直径25mm，带1mm×45°倒角 螺栓孔：8个φ9mm通孔，均布在直径100mm的圆周上 表面处理：阳极氧化黑色 其余：所有锐边倒角R1

注意看，我把"表面处理"也写进去了。虽然生成STEP时不会带表面处理属性，但提示词中的这类信息会影响LLM对零件用途的判断，从而间接影响几何形状。实测下来，提示词越接近真实工程图，生成结果越靠谱。

6. 对CAD工作流程的影响：我的几个判断

6.1 工程师的活儿不会消失，但会变

看到这里你可能会担心：text-to-cad是不是要取代CAD工程师？我的看法恰恰相反。它取代的是"基础重复建模"这个动作，而不是"设计决策"这件事。相反，它逼着工程师把模糊的"大概感觉"变成清晰的"尺寸和公差"。你描述得越清楚，生成结果越符合预期，这个过程本身就是一种设计能力的体现。

以前画一个概念模型要两小时，用text-to-cad只要两分钟，省下来的时间应该花在哪？花在审模型上——观察它是否符合装配要求、加工约束、成本考量。我现在越来越觉得，未来的CAD工程师是"提需求者 + 审图者"，而不是"绘图员"。

6.2 实际工作中的整合思路

我这半年的工作流已经固定下来了：

• 概念设计阶段（一天变好几版）：text-to-cad（Zoo）出STEP → Fusion 360里快速装配看干涉 → 不满意就直接改文本重新生成。
• 详细设计阶段（要出图、要加工）：CadQuery代码生成 → 代码里写死尺寸参数 → 转进SolidWorks出二维图 → 手工补公差标注和表面粗糙度。
• 标准件库：批量用CadQuery生成国标件 → 存成带参数的STEP → 装配时直接从库调。

这半年下来，重复建模时间至少少了六成。最赚的是法兰、支架、盖板这类零件，以前画一个半小时，现在五分钟出STEP，准确率还能保证。当然也有翻车的时候，这时候记住：text-to-cad本质上是把"画图"变成"审图"，它负责快，你负责对。

顺便分享一个不算技巧的技巧：生成完的STEP别急着导入大软件，先用cq.edges()或者Zoo自带的预览快速看一眼轮廓。很多明显错误，比如圆孔变成椭圆孔、尺寸错了十倍，在预览阶段就能发现。我见过太多同事跳过了这个步骤，把错误的模型拖进SolidWorks，然后卡在"模型报错哪里来的"的排查里。text-to-cad不是魔法，它只是一把更快的尺子——尺子再快，也得有人去量、去看、去判断。少了这道人工把关，再好的生成结果也只是一堆漂亮的几何垃圾。