text-to-cad 实战：自然语言生成参数化CAD模型的工作流与避坑指南

先把话放在前面：text-to-cad 目前做不到你念一句“给我一个完美的机械臂”，它就真给你吐出全套可加工的装配体。但论“把一段话变成一块能编辑、能出图、能拿去加工的 CAD 模型”，它已经能从论文实验室搬到普通人的桌面上了。

这一年我断断续续在玩 text-to-cad，身边不少朋友一听见这名字就问：是不是以后不用学 CAD 了？这个问题其实问偏了。text-to-cad 解决的从来不是“要不要学 CAD”，而是“从需求到模型的第一步能不能再快一点”。以前你要打开软件、建草图、画矩形、倒圆角、拉伸、开孔，每一步都是按部就班的几何操作；现在你只要把脑子里那张图说清楚，工具直接给你一份参数化的初始模型，剩下的精修仍然回到 CAD 里完成。

这篇文章不写论文综述，就从一个实际用户的角度聊聊：text-to-cad 现在到底能干什么、主流有哪些玩法、我跑通的最小工作流长什么样、以及一路踩过来的坑。不管你是画了十几年图的老师傅，还是刚下载 CAD 准备制图初学入门的新手，看完应该都能判断它对你有几分用处。

1. text-to-cad 到底解决了哪门子痛点

1.1 传统 CAD 建模的门槛不只是“软件难学”

很多人以为 CAD 的门槛在于软件命令多、快捷键记不住。这话对一半。真正拦住新人的，是“把脑海里的三维实体转成二维约束”这个过程本身。同样一块 120mm×80mm、厚 3mm、四角 R5 圆角、中间开直径 10mm 圆孔的板，老手五分钟能画完，新手可能要先想清楚：我是先画矩形还是先画中心线？圆角放在拉伸之前还是之后？要不要做全约束？

这些不是软件操作问题，是几何思维问题。CAD 要求你把最终结果拆成一步步可执行的构造过程，而正常人的大脑里存的是“最终长什么样”，不是“构造步骤”。text-to-cad 的聪明之处就在这里：它不要求你用人话去翻译几何过程，而是直接理解人话里的“结果描述”，然后替你完成从结果到构造步骤的反推。

我试过拿同样一段文字描述去问一个刚学会 CAD 基础操作的朋友，他花了十几分钟才把模型画对。而同样一段话丢给 text-to-cad 工具，一分钟内出初稿。差距不在软件熟练度，在于表达能力到几何模型的转译效率。

1.2 自然语言到参数化模型的转换逻辑

text-to-cad 的核心链路可以简化成三步：文本理解、几何参数抽取、模型重建。文本理解负责把“一块铝板，四角倒圆角，中间有个孔”这类自然语言拆成结构化信息；几何参数抽取负责识别尺寸、特征、位置关系，比如 120mm 是长度、80mm 是宽度、R5 是圆角半径、直径 10mm 是孔的大小；模型重建负责把这些参数喂给几何内核，生成可编辑的 B-rep（边界表示）模型或脚本代码。

关键在于“参数化”三个字。大多数人第一次接触 text-to-cad 时，最容易被“点击生成一个 3D 模型”这种宣传带偏。实际上真正有用的输出不是一张渲染图，而是一份能改尺寸、能再编辑的参数化结果。如果生成的是网格模型，你拿进 SolidWorks 或中望 CAD 里也只能看看，没法改厚度、改孔径，等于一次性的玩具。

我自己的判断标准很简单：能不能改参数。能改，它就进入工作流；不能改，它就是个预览器。

1.3 它擅长什么，不擅长什么

用了一个多月，我对 text-to-cad 的能力边界已经摸得很清楚。它擅长的是通用机械零件、规则几何体、板类零件、简单壳体，以及“以阵列、布尔运算、拉伸旋转为核心”的中低复杂度模型。描述越结构化，生成成功率越高。比如“直径 50mm 的圆柱，中心有一个直径 20mm 的通孔，圆柱高度 30mm”，这种描述几乎不会出错。

它不擅长的是曲面造型、有机形态、精密配合关系，以及需要大量领域知识才能描述的零件。你让它生成一个符合钣金折弯工艺的机箱，它能给你画出来，但折弯系数、最小折弯半径、模具避让这些工艺规则，它大概率不懂。同样，复杂地形曲面、点云重构这类任务也啃不动，那玩意的数据量和几何拓扑复杂度，和“根据文字画零件”完全是两个赛道。

还有一个必须说清楚的边界：通用 text-to-cad 模型和行业专用 CAD 软件之间还有距离。像金林钣金 CAD、瑞丽服装 CAD 这类深耕特定工艺的软件，内置了大量行业规则和本地化标准，通用大模型短时间不可能覆盖。所以更现实的理解是：text-to-cad 负责把“想法”变成“毛坯模型”，行业软件负责把“毛坯模型”变成“能生产的图纸”。

2. 主流实现路线与工具选型怎么看

2.1 路线一：大模型生成脚本代码，这条路最务实的

目前最容易上手、也最适合个人复现的 text-to-cad 实现，不是某个专业的工业软件，而是“LLM + 程序化建模脚本”的组合。程序化建模工具有两类常见选择：一类是 OpenSCAD，用纯代码描述几何体，语法简单到像写作文；另一类是 CadQuery，用 Python 写模型，能直接导出 STEP 这类标准交换格式，工厂和下游软件都认。

这套路线的原理其实不复杂。OpenSCAD 和 CadQuery 的脚本本质上就是把“几何构造步骤”写成代码：先画什么、再布尔运算什么、最后拉伸多少。大模型在大量代码上训练过，生成这类 DSL（领域特定语言）的能力相当强。你给出一段自然语言描述，模型把它翻译成对应脚本，然后交给渲染器直接出结果。

我实测下来，OpenSCAD 路线的成功率明显高于直接让模型生成 STEP 文件。原因也简单：代码是文本，生成文本是大模型的老本行；而 STEP 是复杂拓扑数据，让模型直接推理 B-rep 结构非常容易翻车。

2.2 路线二：工业级 Text2CAD，LLM 驱动草图求解器

再往上游走，是 Autodesk Research 和 Princeton 等团队公开的工业级 Text2CAD 方案。这类系统的做法更接近“人类设计师的思考方式”：先用大模型把用户描述翻译成一系列 2D 草图指令，包括直线、圆弧、圆、约束关系，然后由几何求解器把草图精确重建出来，再通过拉伸、旋转等操作生成 3D 实体，最终输出标准的参数化 CAD 文件。

这条路线生成的结果质量更好，因为草图求解器保证了几何的精度，不会出现 OpenSCAD 方案里那种“代码逻辑对但渲染出来差一截”的情况。缺点也很明显：这类系统依赖庞大的训练数据和专门的数据集（比如 ABC 数据集、Fusion 360 Gallery），普通用户很难本地复现，目前大多以云端服务形式提供，能把你接入工作流，但你想魔改它内部的某个环节，门都没有。

对个人来说，我的建议是：优先把路线一跑熟，再去关注路线二的产品化进展。路线一的工具链完全开源、可控、免费，适合学习和理解原理；路线二更适合企业评估要不要引入到现有设计流程中。

2.3 路线三：文本直出网格模型，看着炫但别混淆

还有一类常被误认为是 text-to-cad 的工具，它们把文字描述直接生成网格模型，比如 Meshy、Tripo 这类 3D AIGC 工具。生成速度快、视觉效果惊艳，非常适合概念设计、游戏资产、电商展示。但从 CAD 角度讲，这类输出是网格（mesh），没有参数化特征树，没有约束关系，尺寸精度也没有保证。

曾经有朋友拿这类工具生成的“齿轮”模型导入到中望 CAD，想测量齿距，结果发现整个模型是一堆三角面片，完全无法按机械制图的逻辑编辑。后来他不得不重新建模。这就是典型的“看起来行，实际不行”。

所以大家在做工具选型时，第一件事就是分清输出格式：是 STEP/IGES 还是 STL/OBJ。前者是 CAD 世界的通用语言，后者是 3D 打印和渲染世界的语言。你的下游是加工还是打印，决定了该选哪条路线。

2.4 选型对比与我的建议

把三条路线放到一起看，各自的定位就很清楚了：

我个人的经验是：如果只是想体验一下 text-to-cad 到底什么感觉，先装 OpenSCAD，免费、轻量、没有环境依赖，五分钟就能跑通；如果是要接到正经设计流程里，那 CadQuery 加一种好的 LLM 提示词模板更合适，因为 STEP 文件可以直接在各大主流 CAD 软件里打开编辑；如果你想在企业里落地，再认真评估工业级 Text2CAD 的 API 成本和精度指标，别一上来就拍板。

另外提醒一句，开源方案的好处不只是省钱，更在于你能动手改。我在二次开发时就踩过不少闭源服务的坑：想批量生成多个变体模型，API 接口不支持批量参数传入，只能一个个调，效率极低。自己搭 OpenSCAD 加 LLM 的工作流，一次循环能生成几十个尺寸变体，这才是 text-to-cad 真正值钱的地方。

3. 实操：从零跑通一个 text-to-cad 的最小工作流

3.1 环境准备：OpenSCAD、Python 与运行库问题

先说说环境这件事。很多新手折腾 text-to-cad 卡住，不是死在 AI 环节，而是死在最基础的软件安装上。OpenSCAD 本身是免费的，官方直接下载安装包就行。

但这里有一个高频坑：老版本软件在安装或首次启动时经常报 C++ 运行库错误。我见过很多人问“安装 CAD 一直出现 C++ 2005 错误怎么办”，这类问题在不少图形软件上都会遇到，OpenSCAD 的旧版本也有类似迹象。解决办法很简单：先去微软官网下载对应的 Visual C++ Redistributable，注意把 32 位和 64 位两个版本都装上。装完再运行 OpenSCAD，基本就顺了。不要随便去第三方网站下载所谓的“完整安装包”，捆绑软件和小广告的教训不用我多说了。

如果你选择 CadQuery 路线，还要装 Python 环境和相关依赖。我用的版本是 Python 3.10 以上，配合 cadquery 的 pip 包。安装命令一行搞定：

pip install cadquery

装完以后顺手验证一下能否正常导入，避免后面排查问题时把环境问题和技术问题混在一起。

3.2 写一条合格的“文字图纸”

这是整个流程里最考验人的一步。很多人以为“用自然语言生成 CAD”嘛，我随便说一句就行。但实际操作下来，描述方式直接决定生成质量。

我给你一条我自己验证过的“文字图纸”模板：

一块 120mm 长、80mm 宽的矩形铝板，厚度 3mm，四角倒圆角，圆角半径 5mm。板的中心位置开一个直径 10mm 的通孔。在中心孔四周对称布置 4 个螺栓安装孔，孔直径为 4.2mm，呈矩形分布，横向间距 60mm，纵向间距 50mm。所有尺寸单位均为毫米。

注意我在这里刻意写清楚了：尺寸数值带单位、特征位置用“中心”“对称”这类锚点词、孔径和间距分开说明、最后专门补充“所有尺寸单位均为毫米”。这些都是给大模型减少歧义的咒语。如果你只说“一块板中间打个孔”，模型可能给你生成任何比例的板，孔的尺寸也完全随机。

我做过对比实验：同一句话，加了“对称”“中心”“单位均为毫米”这三类约束后，生成模型的尺寸准确率从大概五成提升到九成以上。这就是提示词工程的直接价值。

3.3 调用 LLM 生成 OpenSCAD 代码并渲染

描述写好之后，下一步就是让大模型把它翻译成 OpenSCAD 代码。你可以用任意主流大模型的 API，也可以本地部署开源模型。我这边开发时用的是 OpenAI 兼容接口，提示词里加了一句“只输出 OpenSCAD 代码，不要解释”，然后直接把上一节那段描述丢进去。

模型返回的代码经过我整理之后，是这样一个可以用 OpenSCAD 直接渲染的版本：

module plate_with_holes() { // 先用偏移实现四角 R5 圆角，再统一做孔特征 offset(r = 5) square([120 - 10, 80 - 10], center = true); // 中心孔 circle(d = 10); // 四个螺栓孔，中心孔四周对称布置 for (x = [-30, 30], y = [-25, 25]) { translate([x, y]) circle(d = 4.2); } } linear_extrude(height = 3) plate_with_holes();

在 OpenSCAD 里按 F5 预览，你会看到一个带圆角的板子悬浮在空间里，按 F6 完成渲染，就能得到可导出的实体模型。这里有个小技巧：offset做圆角比手动去拼圆弧和直线简单得多，而且修改 R 值只需要改一个数字，这就是参数化的好处。

第一次跑通这个流程时，说实话我是有点震惊的。从文字描述到三维实体，中间没有任何手工几何操作，整个过程不到两分钟。哪怕它是初稿，也足够省掉以前从零画草图的那些基本功时间。

3.4 导出 STEP/DXF/PDF：从三维模型到二维图纸

跑通生成环节之后，紧接着的问题是：这模型怎么用？如果你是做机械加工，最需要的往往是 STEP 文件，因为加工厂和结构设计软件都认这个格式。OpenSCAD 默认导出的 STL 网格并不够用，需要额外处理才能转成 STEP。

我的做法是把模型导入 FreeCAD 之后再导出 STEP。FreeCAD 是免费软件，打开 OpenSCAD 生成的文件后，用“Part 模块”把实体选中，再导出 STEP 格式即可。这个路径虽然绕了一步，但胜在完全免费、全流程可控。

如果你需要的是二维工程图，那就涉及“CAD 转 PDF”的操作了。把 STEP 文件导入 FreeCAD 的 TechDraw 工作台，自动生成三视图，再调整标注和标题栏，最后导出 PDF。这里有一个很实用的注意事项：图纸里的中文注释在导出 PDF 时经常出现乱码或方块字，这是字体映射问题。你在系统里装好完整的中文字体，并在 TechDraw 里把注释字体切成中文字体，问题就解决了。和传统 CAD 里的 SHX 字体缺失是同一个道理，核心思路就是“让软件找到正确的字体文件”。

整个导出链路跑通以后，你手里就有了一套“自然语言 → 参数化模型 → STEP 加工文件 → PDF 图纸”的完整流程。这套流程对我最大的价值，是它把产品从想法到图纸的周期从几个小时压缩到了十几分钟，尤其是方案前期反复改尺寸的时候，优势极其明显。

4. 工程落地中的踩坑记录与排查思路

4.1 尺寸不对、特征丢失：提示词与自校正

我实际使用中翻车频率最高的，就是生成结果和预期尺寸不符。典型场景是：我说“直径 20mm 的孔”，模型给我生成了半径 20mm 的孔；我说“长度 100mm 的板”，它理解成了总长 100mm、但四角 R10 圆角后又变成了 80mm。这类问题不是模型笨，而是自然语言里“直径”和“半径”、“外形尺寸”和“有效尺寸”本身就存在歧义。

我的排错顺序是这样：先确认提示词里有没有明确的“直径还是半径”说明；再检查有没有给出“外形优先”或“孔心距优先”这类优先级声明；最后才是换模型或调温度参数。比如上面那块板的描述，如果我想强调外形尺寸，可以写成“板的外形尺寸为 120mm×80mm，圆角不改变外形边界”，这样模型就不容易把圆角算进外形里。

还有一个很实用的技巧叫“生成后自检”。把你需要的尺寸清单列出来，让大模型在生成代码的同时，输出一份“尺寸校验表”，对照代码里的参数值逐项核对。我后来把这一步做成了脚本，自动提取 OpenSCAD 代码里的数字参数，和需求清单做比对，不匹配的自动重新生成。这比肉眼盯代码靠谱得多。

4.2 环境与安装系列问题：运行库、路径、缓存

前面提到过 C++ 运行库问题，这属于环境排查里的一个大类。实际操作中我还遇到过 OpenSCAD 打不开、显示异常之类的情况，多半是显卡驱动或 OpenGL 兼容问题。解决办法：更新显卡驱动到最新版，如果还不行，在 OpenSCAD 的偏好设置里把渲染模式切换成软件渲染，性能差点但稳定性会好很多。

Python 侧的环境问题也不少。最常见的是装了 Python 3.12 后，CadQuery 的某个依赖编译失败。我自己踩过之后给出的建议是：别追求最新版 Python，装 3.10 或 3.11，生态兼容性最好。另外，如果用虚拟环境（venv 或 conda），一定要确认终端里激活的是正确的环境，否则你会对着一个“ModuleNotFoundError”排查半天，最后发现是环境串了。

另外补充一点下载安全：任何“CAD 下载”相关的需求，尽量从软件官网或官方 GitHub Releases 页面拿安装包。第三方网站的“破解版”“绿色版”轻则有广告弹窗，重则带着木马，我身边真的有人中过招。text-to-cad 的工具链全都是正规开源软件，完全不需要走灰色渠道。

4.3 批量生成变体：用 Python 串起全流程

text-to-cad 在工程里最实用的场景，我认为不是单个建模，而是批量生成变体。设计一个零件时，你可能要试五档厚度、三种孔径、两类圆角半径，传统做法就是手工改参数重建一遍又一遍。但如果你有了“文字生成脚本”这条链路，批量化的瓶颈就只剩提示词模板了。

我写了一个 Python 脚本，流程大概是：定义参数组合列表 → 逐组生成描述文本 → 调用 LLM 接口生成 OpenSCAD 代码 → 用 OpenSCAD 命令行工具批量渲染并导出 STL → 用 FreeCAD 的 Python API 转成 STEP。整套流程跑一次，能一口气产出几十个变体模型，然后我拿着这些 STEP 文件在主流 CAD 软件里批量打开审核。

这里要特别提醒一个点：批量调用 LLM 接口时要做好失败重试机制。网络抖动、接口限流都可能导致生成失败，我的脚本里加了三秒超时后的重试逻辑，连续失败三次就跳过该参数组合，并生成一份失败清单。工程化永远要考虑到“机器会出错”，而不是假设它每次都完美。

至于“CAD 图纸合并”这类需求，在批量场景里也会遇到：几十个零件生成以后，经常需要把相关的几个合成一张总图。FreeCAD 里可以新建一个装配文件，把所有零件以链接方式导入，再统一出图。注意别用“复制粘贴”方式合并，否则改动源文件后总图不会自动更新，链接才是正确的用法。

4.4 多软件命令冲突与工作流衔接

搭建这套工具链的过程中，我电脑上同时装了 OpenSCAD、FreeCAD、中望 CAD，还有原来的老牌 CAD 环境。软件一多，问题就来了：快捷键冲突、临时文件目录互相干扰、甚至命令行工具路径都互相打架。

这让我想起一个很早以前的老问题：有人问“CAD 里面的 BL 命令在 CASS 里面是什么”，其实就是不同软件对同一个缩写命令的映射不一样。在 text-to-cad 工具链里也一样，不同软件的命令行工具都叫openscad或freecadcmd，如果你把它们都加进系统 PATH，往往会调用到错误的那一个。

我的解决方案是写一个项目级的环境配置脚本，在每次运行前把 PATH 里的工具路径显式指定，不依赖全局环境变量。比如这样：

set OPENSCAD_PATH=C:\Program Files\OpenSCAD\openscad.exe set FREECAD_CMD=C:\Program Files\FreeCAD\bin\freecadcmd.exe

这样做的好处是，不管系统全局里装了什么版本、哪个先被找到，我的流程始终调用正确的那一个。这类问题在工程落地上很常见，刚接触的人会觉得莫名其妙，但只要你理解了“它本质上就是软件间的命令映射歧义”，排查思路就清晰了。

5. 给普通用户和设计师的几条实用建议

5.1 对制图初学者：别急着学命令，先把需求讲清楚

如果你刚接触 CAD 制图，还没有形成完整的建模思路，text-to-cad 其实可以当你的“陪练”。我的建议是不要拿它代替学习，而是拿它当参照物：你先自己用自然语言描述一个零件，让 AI 生成模型，然后回到 CAD 软件里，照着这个模型反推它的构造步骤。

这个过程很像学书法时的“描红”。你不需要从零构思几何构造顺序，只需要理解“这个模型是怎么一步步被定义出来的”。一旦理解了，再去系统学习 CAD 的核心命令，效率会高很多。我自己教过几个零基础的朋友，用这个方式入门，比抱着教程啃命令快一半以上。

但要坦诚提醒一个误区：text-to-cad 生成的模型，几何正确不代表工艺正确。比如开孔位置太靠近板边，强度不够；又比如倒圆角半径大于板厚，实际加工会有问题。这些工艺知识，工具给不了你，还是要在制图规范里积累。AI 能帮你把“形状”画出来，能不能“造出来”靠的还是你的专业判断。

5.2 对专业工程师：当“需求转译器”而不是“全套方案”

我见过不少工程师朋友对 text-to-cad 特别抵触，觉得这是外行抢饭碗的工具。实际用过之后，他们的态度大多变成“真香”。道理很简单：他们最讨厌的不是建模本身，而是方案前期反复改尺寸的琐碎劳动。

你做结构设计时，客户一句“板子再薄一点”就要改全局。在传统流程里，你要找到所有关联特征逐个改参数，改完还要检查有没有特征报错。用 text-to-cad 工作流，你只需要修改描述里的“厚度 3mm”改成“厚度 2mm”，重新生成、重新导出，一分钟内完成一轮迭代。这时候你会发现，工具不是替代你，是帮你把重复劳动吃掉了。

我的建议是把 text-to-cad 定位成“需求转译器”：你仍然负责判断方案的合理性、确定设计约束、审核最终图纸，AI 只负责把确认过的需求快速变成可编辑的模型草稿。砍掉的不是你的专业价值，而是那些低价值的重复操作。

5.3 数据安全与本地化部署

最后必须认真强调数据安全的问题。如果你只是玩一玩、做个人项目，直接用云端大模型 API 问题不大。但如果是企业项目，设计的零件图纸往往涉及核心产品信息，把图纸描述发到云端接口，等于把设计思路交给了别人。我的做法是本地部署一套开源模型，代码生成能力要求不算极端，用 7B 级别的模型在消费级显卡上就能跑得动。

具体来说，我用的组合是本地部署的大模型加 OpenSCAD，完全不依赖外网接口，图纸描述只在本机流转。性能比云端 GPT 级别的大模型差一些，但胜在私密可控。对大多数个人开发者和中小企业来说，这是性价比最高的方案。

如果你想从零开始搭这整套环境，又不想被各种软件安装坑折磨，我的建议是直接用一个带 GUI 的集成工具先跑通流程，建立体感之后再去碰底层 API。体感非常重要，它让你知道“这件事到底行不行”，而不是陷入“环境装不好是不是我操作问题”的自我怀疑。工具永远在进步，但你对工作流的感觉是任何工具都替代不了的。

最后分享一个我自己一直在用的小技巧：描述零件时，永远先用一句话说清楚“这是什么、整体外形什么样”，再逐条列出特征。比如“这是一个安装支架，外形是 L 形折弯结构。竖边高 80mm，底边长 120mm，折弯内角 R3，厚度 2mm。底边有两个直径 6mm 的安装孔，间距 60mm，距底边前端 10mm。”这句话的结构，就是“总述外形 + 分述特征 + 相对定位”。凡是按这个结构写的描述，生成成功率都显著高于随口一句“帮我画个支架”。这个经验我从第一次跑通一直用到现在，你要是开始玩 text-to-cad，不妨直接拿来用。