把一句话变成能编辑的 CAD 模型，text-to-cad 在过去两年里从实验室玩具变成了可以放进工作流的实用工具。这篇文章不聊概念，直接讲清楚它背后的三条技术路线、最小可用实现，以及我在实操里踩过的坑，给正在观望或准备动手的朋友一份能直接抄作业的参考。

1. 为什么突然聊 text-to-cad：传统 CAD 输入方式的天花板

1.1 传统建模流程的痛

用过 CAD 的人都知道，从需求到模型，中间隔着一大堆重复劳动。你画一个零件，先建草图，再拉伸，再打孔，再倒角，每一步鼠标点得清清楚楚。哪怕你用参数化建模，改尺寸也得进草图改约束。这个流程有个隐藏问题：想法在脑子里是“一个带 USB 口的塑料盒子”，但软件只认“先画一个矩形，拉伸 30mm，再在侧面开一个 12mm×4.5mm 的槽”。把语言描述翻译成几何操作，这件事本身消耗了大量时间。

text-to-cad 想解决的就是这个翻译过程。它的目标不是“输入一句话直接出图这么玄乎”，而是让模型理解你这句话里的设计意图，再把它转成 CAD 内核能执行的动作序列。注意，动作序列这个词很重要，它意味着输出不仅是一张图片或一个网格，而是真正意义上可编辑、可装配、可加工的参数化模型。

1.2 text-to-cad 的核心逻辑

从工程角度看，text-to-cad 本质上是“大语言模型 + 几何内核”的组合。语言模型负责理解自然语言里的实体、尺寸、空间关系、约束条件，几何内核负责把理解结果变成实体模型。市面上大多数方案都有这个框架：前端是 LLM，后端是某个 CAD 内核，中间通过代码或中间表征来对接。

相比传统建模，它把“描述—建模”之间的沟壑直接架了一座桥。你不需要记住命令名，不需要掌握草图的约束关系，只要能用自然语言把需求说清楚，剩下的交给模型。对老工程师来说这可能像偷懒，但对产品概念设计、3D 打印爱好者、非机械背景的设计师来说，这个输入方式的改变是实质性的。

1.3 适合谁用，不适合谁用

我实际跑了一轮之后发现，它的适用边界比很多宣传稿说得要窄，但也没有窄到鸡肋。适合的人群有这么几类：

• 做概念验证的产品设计师，需要快速出多个方案对比
• 3D 打印爱好者，想做个外壳、支架，不想钻研复杂草图
• 需要自动化出图的工程师，比如批量生成同类零件变体
• 教育场景里学 CAD 的新手，先看到结果再反推建模过程

不适合的则是精密模具、复杂曲面、有严格公差要求的领域。现阶段 text-to-cad 生成的模型在拓扑和尺寸上还不够稳定，用来做最终制造件风险很大。它更适合当前端方案的产出，后续再人工在 CAD 里精修。这个定位理解清楚，就不会对工具有过高的期待。

2. 三条实现路线的技术拆解

2.1 路线一：让 LLM 直接生成脚本代码

这是最直觉的做法：给大语言模型一个任务，让它输出 CadQuery、OpenSCAD 或 PythonOCC 的脚本，然后本地执行脚本生成模型。以 CadQuery 为例，它是基于 Python 的参数化建模库，代码本身描述的就是“在平面上画什么轮廓，拉伸多高，union 还是 cut”，这恰好是 LLM 擅长的代码生成范畴。

我在测试中最常用的是 CadQuery 方案，因为它对 LLM 最友好。CadQuery 的 API 设计接近自然语言的可读性，比如box(30, 20, 10)就是建一个 30×20×10 的立方体，edges().fillet(2)就是给所有边倒 2mm 圆角。模型不需要理解复杂的 B-Rep 理论，只要学会调用这些高层 API 就能出有效模型。

这条路线的好处是门槛低、可解释性强。脚本就是中间产物，你可以直接改代码调参，比黑盒出模型灵活得多。缺点则是 LLM 容易在复杂几何逻辑上犯错，比如布尔运算的顺序、面与面的相对关系，输出代码经常在语法上正确但几何上无效。需要在外层套一个校验和重试机制，脚本报错就反馈给模型再改一遍。

2.2 路线二：学习中间表征，Text2CAD 就是典型代表

真正把 text-to-cad 做成严肃研究方向的是 MIT 那篇 Text2CAD 论文。它不生成代码，而是训练模型直接输出一种叫 ESC-Net 的中间表征。这个表征把 3D 模型拆成“图元类型 + 参数 + 空间关系”，比如“一个圆柱，半径 5，高度 20，圆心在 (10, 10, 0)”。

这个思路的核心是绕开代码生成的不稳定性。LLM 生成代码，错误是分散的、难定位的；而中间表征是结构化的，模型只需要在固定格式里填参数，几何合法性检查也更容易做。论文里用 Transformer 架构来解码自然语言和中间表征之间的映射，本质上是把 text-to-CAD 当成一个 seq2seq 任务，而不是代码生成任务。

实测下来，这种方案在“简单零件族”上效果很稳，比如法兰盘、轴套、支架这类规则零件。它能做到多轮修改——你追加一句“孔距改成 40mm”，模型在保持整体结构不变的情况下更新参数，这在代码生成路线里往往会导致整个脚本重写。缺点是训练数据难搞，需要大量人工标注的 CAD 设计树，目前公共数据集还不够大，项目也主要停留在学术阶段。

2.3 路线三：商业工具的取巧方案

Zoo、Blender AI 这类商业工具走的是另一条路。它们没有试图从零训练一个 CAD 模型生成器，而是用“多模态大模型 + 程序化模板库 + 约束求解器”的组合。用户输入文字后，系统先检索模板库，匹配最接近的零件族，再根据文字里的尺寸和特征参数实例化模板。

这个做法有点像你搜素材库然后改参数，只不过搜索和参数填写的动作由 AI 完成。它最大的优势是稳定，产出的模型都是经过人工校验的模板变体，拓扑一定没问题。缺点是创新性差，只能生成模板覆盖范围内的形状，遇到没见过的设计需求基本无能为力。

我个人的判断是，三到五年内，商业工具会更偏向路线三，因为用户要的是“能用”，不是“能创新”。但如果你想做开源插件、研究项目或自动化管线，路线一和路线二才是可以动手的方向。

3. 零基础实操：让一段文字描述变成可编辑模型

3.1 环境准备

想跑通最小流程，其实不需要买服务器也不需要装完整 CAD。你需要三样东西：Python 3.9 以上版本、CadQuery 库、一个 LLM 接口。

CadQuery 的安装有几个隐藏坑。直接pip install cadquery在 Windows 上经常失败，因为它的底层依赖 OCP（OpenCascade Python 封装）需要预编译的 wheel。我建议去 cadquery 官方 GitHub 看 Releases，下载对应 Python 版本的 wheel 文件，然后本地安装。装完一定要跑一遍import cadquery，确认没报 DLL 加载错误。Windows 上常见的OSError: [WinError 126]基本是缺 Microsoft Visual C++ Redistributable，去装 2019 版本的运行库就能解决，这和装 CAD 报 C++ 2005 错误的处理逻辑是一样的，先把运行库补齐。

LLM 接口的选择，有 API Key 的话直接用 OpenAI 兼容接口即可，本地跑可以用 Ollama 加载 Qwen2.5 7B 这类支持函数调用的模型。如果你只是测试，API 比本地模型省心得多，本地 7B 模型在复杂指令上的遵循能力明显弱一截。

bash # 海外用户直接用 pip，国内用户建议加镜像 pip install cadquery -i https://pypi.tuna.tsinghua.edu.cn/simple

3.2 最小代码实现

我写了一个最简 pipeline：用户输入描述，LLM 返回 CadQuery 脚本，执行脚本导出 STEP 文件。代码不长，但每个模块都很关键。

python import cadquery as cq import openai def generate_script(prompt): response = openai.ChatCompletion.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一个 CadQuery 建模助手，只输出可直接执行的 Python 代码，不要解释。"}, {"role": "user", "content": prompt} ], temperature=0.2 ) return response["choices"][0]["message"]["content"] def execute_and_export(script, output_path="output.step"): # 直接 exec 有风险，生产环境建议用 docker 或子进程隔离 exec_globals = {"cq": cq} exec(script, exec_globals) # 约定脚本最后一行把模型赋值给 result result = exec_globals["result"] cq.exporters.export(result, output_path) # 示例 prompt = "创建一个外壳盒子，长 80mm，宽 50mm，高 25mm，壁厚 2mm，顶面开一个 USB 接口槽，尺寸 12mm x 4.5mm，中心在顶面中心偏右 10mm" script = generate_script(prompt) print(script) execute_and_export(script)

这个流程跑通后，你会看到输出脚本类似这样：

python import cadquery as cq result = ( cq.Workplane("XY") .box(80, 50, 25, centered=(True, True, True)) .shell(-2) .faces(">Z") .workplane() .rect(12, 4.5) .cutBlind(-2) )

重点看两个操作：shell(-2)是抽壳，负号表示向内掏空，壁厚 2mm；cutBlind(-2)是切一个深度 2mm 的槽，方向是向下。这两个是生成外壳类零件最常用的操作，模型只要学会了这组搭配，很多外壳需求都能覆盖。

3.3 关键参数调优

用 LLM 生成 CAD 脚本和生成普通代码有个不同点：几何错误不会在语义层面报错，脚本能跑但产出的模型拓扑是坏的。所以参数设置上要偏保守。

温度保持在 0.2 以下，我测过 0.7 以上时模型会开始“发挥创意”，比如在盒子里凭空加几个孔，这是灾难。模型选型上，指令遵循能力比代码能力更重要。我用过 DeepSeek Coder 和 GPT-4o-mini，后者在“严格遵守系统提示词、只输出代码”上的稳定性明显更好。

另外，务必给模型限定输出格式。不加只输出 Python 代码这个约束，模型会在代码块外写一堆解释文字，exec 会直接报语法错误。我在生产 pipeline 里还加了后处理：用正则提取第一个 ```python 代码块，然后丢弃其他内容。

3.4 数据格式与下游兼容

导出的 STEP 文件是 CAD 领域的通用格式，SolidWorks、FreeCAD、Fusion 360 都能直接打开。如果你需要的是图纸而不是模型，可以再写一步把 STEP 转成 DXF 或 PDF，用 FreeCAD 的命令行批处理即可。

很多人在这一步卡住，是因为软件用的 CAD 格式不同。我给你的建议是标准数据流：text → CadQuery 脚本 → STEP → 目标软件。到了 STEP 这层，所有专业 CAD 软件都能接，没必要纠结某一个软件的命令行接口。

4. 实测中踩过的坑与排查清单

4.1 盲区一：圆角与布尔操作的顺序

这是最容易翻车的地方。模型经常生成这样的代码：先建一个盒子和一个圆柱，然后 union 在一起，最后统一倒圆角。问题是如果圆柱和盒子的交面处有缝隙或重叠，fillet 会报错“could not compute fillet”。

修法其实简单，把倒角放在每一步布尔运算之后立刻执行，而不是攒到最后。CadQuery 的edges()默认选取所有边，但在复杂几何里应该用.edges("%>Z")指定 Z 轴正向的边。LLM 不擅长这种选择逻辑，需要你在 prompt 里给样例，或者在脚本后处理里做校验。

python # 错误示范：最后统一倒角，容易拓扑失败 result = box.cut(hole).edges().fillet(1) # 正确做法：分步处理，布尔运算后立刻圆角

4.2 盲区二：单位与坐标系错乱

CAD 的默认单位是毫米，但很多开源模型训练语料里混着英寸、厘米甚至自定义单位。模型输出一个box(2, 3, 1)，你不确定它画的是 2mm 还是 2 英寸，这在装配时会出大问题。

对策是在 prompt 里反复强调单位：所有尺寸以毫米为单位。后处理里也要做一次体量校验——如果生成的模型 bounding box 为 0.1mm 或 1000mm，基本可以断定单位错了，直接让模型重写。另外注意原点位置，很多模型默认centered=(True, True, False)，也就是说底面在 Z=0；如果你的流程里要求对齐到原点，需要单独加约束。

4.3 盲区三：设计意图的歧义

这是最隐蔽的坑。你输入“一个中间带孔的方块”，模型到底会在哪里打孔？中心？还是默认位置？实际测试中，模型倾向于把孔放在坐标原点，而不是几何中心，因为训练数据里原点出现的频率太高。

我的经验是描述要具体到可量化：不要写“中间”，写“中心在顶面 X=40, Y=25 处”，不要写“一个圆角”，写“四条垂直边倒半径为 3mm 的圆角”。prompt 写得越像工程量，模型输出越稳定。顺带一提，这一条对所有 text-to-cad 工具都适用，包括商业插件。

4.4 实测问题速查表

5. 如何把 text-to-cad 接到真实工作流

5.1 批量改图与参数化变体

如果你用 Vulcan、AutoCAD Plant 3D 或 SolidWorks，不妨换个思路：text-to-cad 主要不是帮你从零画新图，而是把重复性的参数化工作自动化。比如你要生成一批规格不同的法兰盘，过去是一个一个改尺寸，现在可以写一个循环，把规格表喂给 text-to-cad pipeline，自动输出一整套 STEP 文件。批量的效率提升非常明显，我实测 50 个变体只需要几分钟，传统手工至少两小时。

这种场景下，除了 prompt 里写清规格，还要给模型一个样板脚本。模型参考了样板之后会严格遵守既有的建模流程，不会自由发挥。这其实是提示工程里最实用的一招——给模板比给规则好用得多。

5.2 与 CAD 软件的管线协同

在专业环境里，text-to-cad 应该作为“前端生成器”，生成的模型要进到 CAD 里做二次编辑。管线推荐是：文本描述 → CadQuery 脚本 → STEP → FreeCAD 二次编辑 → DXF/DWG 出图。FreeCAD 的 Python 接口支持导入 STEP 后再添加约束和标注，这样既享受了 AI 生成的速度，又保留了传统 CAD 的精确控制。

如果你现在用的是中望 CAD 或其他国产 CAD，同样走 STEP 中转即可，不必为了接 AI 流程换软件。绝大多数主流 CAD 都支持 STEP 格式，这是共识。另外，生成 DXF 时需要特别注意图层组织，CadQuery 默认把所有几何放到一个图层，到了 CAD 里不方便管理，建议导出前在 CadQuery 里给不同特征指定不同图层名，这一步直接决定下游出图效率。

5.3 从生成模型到生成图纸

text-to-cad 的下一个延伸是自动生成配套图纸。我最近在实验的流程是：文本生成模型后，再用多模态模型把 STEP 文件渲染成三视图，自动标注关键尺寸。目前尺寸标注的精度还达不到出图标准，但作为方案评审的前置参考已经够用。

如果你做的是自动化方向，可以将这个管线接入现有的 ERP 或 PDM 系统：设计人员输入需求描述，系统生成候选模型并发起评审，评审通过后自动流转到详细设计。这个流程能把设计周期最前端的一两天压缩到几小时，这才是 text-to-cad 在工业场景里真正创造价值的地方。

6. 下一步能怎么扩展

6.1 本地化部署与数据安全

对很多制造企业来说，把设计数据发给外部 API 是不可接受的。好在目前生态里已经有完全本地化的选项：Ollama 部署开源模型，模型跑在自己服务器上，CadQuery 脚本执行也在本地。唯一要权衡的是效果——开源模型在遵循能力和多轮修正上比商业模型差，但可以用 RAG 把产品标准、建模规范注入上下文，弥补一部分弱势。

我实测用 Qwen2.5 7B + RAG 的效果，在“箱体类零件”这个细分领域能接近 GPT-4o-mini 的八成水平。关键是把历史建模脚本做成知识库，让模型检索到相似案例再模仿，而不是凭空生成。这一步值得做，因为数据不出内网对有合规诉求的单位是硬前提。

6.2 多模态输入

纯文本描述在表达复杂曲面时很乏力。目前我看到的实验方向是把图像输入也纳入进来：用户给一张手绘草图，多模态模型识别轮廓，再结合文字描述生成 CAD 模型。OpenAI 的视觉模型、国内各大厂的 VL 模型都能做初步识别，但距离自动化生成 B-Rep 模型还有一段距离。

不过，图像先转成草图的思路是实用的。手绘轮廓经过视觉模型提取关键点，再离散成多段线，导入 CadQuery 作为草图轮廓挤出。这个流程在手感上已经很接近“对着图纸建模”了，适合改造旧件翻模或逆向设计的场景。

6.3 与生成式设计的结合

生成式设计作为一个独立工具已经存在很多年，但传统上需要设计者先定义优化目标和约束空间。text-to-cad 可以作为生成式设计的前置入口：你用语言描述“我要一个承受 500N 载荷的支架，安装孔间距 40mm，最大尺寸 80mm”，AI 先生成初始几何，再交给拓扑优化引擎迭代。这样一来，整个“需求到优化结果”的链路都可以用自然语言驱动。目前这条路径还没有成熟的商业产品，但构造这个 pipeline 的技术栈——LLM + CadQuery + 拓扑优化库——已经全部开源可用。

从我自己的实践来看，把 text-to-cad 当成一个“能写脚本的建模助手”而不是“自动出图机”，它的可用性会大大提升。所有不切实际的期望，几乎都源于对 LLM 几何能力的高估。最后分享一个我在 prompt 里的固定模板，它有四个层次：角色定义、任务描述、单位约定、输出格式。把这四行写清楚，成功率比啰啰嗦嗦描述形状高得多。

text 你是 CadQuery 建模工程师。根据用户需求生成 Python 脚本。 使用 CadQuery 库，所有单位是毫米。 只输出 Python 代码，不要任何解释。 任务：{描述}

再提醒一次：每一步生成结果都用.isValid()校验，这是最容易忽略但最值得加的代码。等到你在 CAD 里打开发现模型穿孔再回去排错，成本至少翻三倍。这个习惯养成之后，text-to-cad 的管线才算真正可靠。