Text-to-CAD：用自然语言驱动参数化建模，重塑CAD设计流程

1. 先搞清楚：text-to-cad 到底是干什么的

最近“text-to-cad”这个词在三维设计圈子里热度不小。说白了，它就是让你用一句自然语言描述，直接生成 CAD 模型——“帮我做一个直径 20mm、高度 50mm 的圆柱体，底面带一个 5mm 通孔”——然后软件就真的给你把模型建出来了。我第一次看到这个效果的时候，说实话第一反应是“玩具”，直到自己亲手跑通了一遍完整流程，才意识到这里面的水比想象中深得多。

这个技术解决的核心痛点，其实是 CAD 建模的门槛问题。传统建模流程里，不管是用 Fusion 360、SolidWorks 还是 FreeCAD，你要先熟悉草图、约束、拉伸、旋转这一整套操作逻辑，光是把“脑子里想的东西”翻译成“软件的参数化操作”，新手就得磨几个星期。text-to-cad 想做的事情，就是跳过这层翻译，让设计意图直接变成几何结果。

适合谁来研究这件事？如果你是做机械零件设计的，可以把它当成一个快速出草稿模型的工具；如果你是搞 AI 应用的，它是一个非常典型的“大语言模型 + 专业软件”结合案例；如果你只是对 3D 打印感兴趣、想快速验证一个想法，它也能让你免去学建模软件的痛苦。当然，指望它现在就能替代工程师做完整的产品设计，那还早得很，但它已经足够值得花一个下午去玩明白。

2. 核心原理拆解：为什么 text-to-cad 能“听懂”建模需求

2.1 不是“画图”，而是“写代码”

很多人第一次听到 text-to-cad，会以为它是让 AI 直接生成一个 3D 模型文件。这个理解有偏差。实际上的主流实现思路，是用大语言模型生成一段“建模脚本”，然后把这个脚本交给 CAD 内核去执行，最终得到几何模型。

这段脚本通常有两种形式。一种是直接生成目标格式的代码，比如 OpenSCAD 的脚本语言，它就是通过布尔运算、挤出、旋转这些操作来描述几何体的；另一种是生成某个 CAD 软件的 Python API 调用代码，比如 FreeCAD 的 Python 脚本或者 CadQuery 的链式调用。

这两种方式的核心逻辑是一样的：把“自然语言描述”转成“参数化建模操作序列”。大语言模型在这里干的事情，本质上是一个翻译工作——它把“一个带法兰的管道”翻译成“先画一个圆、拉伸、再画一个大一点的圆、拉伸、然后做布尔并集”这样一串操作。

这也是为什么 text-to-cad 的生成结果往往比文生图类的模型更可控。图像生成是像素级别的概率采样，而 CAD 生成是严格几何操作的结果，每一个尺寸、每一个位置关系都是确定性的。模型要是理解错了，产出的不是“看起来差不多的图”，而是一个完全无法用的实体，或者说干脆报错。这种“非黑即白”的特性，反而让它的调试和改进路径更清晰。

2.2 主流技术路线对比：为什么大家偏爱程序化建模

先看几条技术路线，理解为什么行业里普遍选择了“语言模型 + 程序化建模”的组合。

第一条路线是直接生成网格或者 BREP 几何数据。比如让模型输出一个点云、一个三角网格的顶点坐标数组。这条路在数学上可行，但实际效果很差——大语言模型最擅长的是token序列的生成，不是精确的浮点数坐标序列。你可以让模型生成 100 个词的句子，但让模型生成 500 个精确到小数点后六位的坐标点，它大概率会在第几十个点之后开始胡编乱造。而且，直接生成几何数据意味着丢失了参数化信息，后续想改一个尺寸、调整一个圆角，都无从下手。

第二条路线是用扩散模型或者类似图像生成的方式去生成“CAD 模型的隐式表达”。这个概念上有意思，学术论文里也有不少人在做，但工程落地还很远。主要是生成结果的精度难以保证，而且需要对每个类型的零件单独训练，泛化能力差。

第三条路线，也是目前开源社区里跑得通的主流路线，就是让大语言模型生成参数化建模脚本。这条路有四个明显的优势。第一，语言模型生成代码的能力已经被反复验证过了，尤其是擅长“从描述到实现”这种场景。第二，脚本是可编辑的，你可以手动改参数、改逻辑，不需要推倒重来。第三，脚本天然带有降级方案——模型生成的代码就算一次跑不通，你可以把报错信息喂回去让它自己修，这个“自我纠错循环”是其他路线很难实现的。第四，它可以直接复用现有 CAD 软件的全部能力，不需要自己写几何内核。

这个选型逻辑值得多说两句。大语言模型本质上是“概率化的文本生成器”，它的强项是语义理解、知识关联和模式匹配，弱项是精确计算和高维空间推理。程序化建模恰好能扬长避短：语言模型负责“想清楚要做什么”，几何内核负责“精确做出这个形状”。把大模型不擅长的事情交给专业工具，这是 text-to-cad 技术栈设计的精髓。

2.3 从语言到参数：提示词里到底发生了什么

实际运行的时候，输入的自然语言要经过几个处理阶段。第一阶段是意图解析，模型要判断用户想要的是一个什么类型的零件，是轴套、法兰、支架还是壳体。第二阶段是参数抽取，模型要把描述里的数字、单位、相对关系抽取出来，比如“直径 20mm”“壁厚 2mm”“四个均匀分布的孔”。第三阶段是结构推理，模型要规划建模操作的先后顺序——先建主体再开孔，还是先做一半然后镜像。

这个过程里最容易翻车的地方就在第二阶段。用户描述里的信息经常是不完整的，比如“做一个茶杯”，没说杯壁多厚，没说杯柄多宽，这时候模型得自己做合理假设。有些实现会引入“默认参数表”，比如壁厚默认 2mm、圆角默认 1mm，这样至少能保证生成结果的可用性。

还有一点很多人没意识到：text-to-cad 的提示词不需要写得太“自然语言”。反而是那种“带约束的结构化描述”效果最好。比如“create a cylinder with diameter 20mm and height 50mm, with a central hole of diameter 5mm”就比“帮我画一个圆柱，中间掏个洞”更稳。原因在于，大模型的输出质量高度依赖输入信息的明确度，你给的约束越清晰，它越容易生成符合预期的脚本。

3. 实操碰到的关键环节：手把手跑通一个 text-to-cad 流程

3.1 工具链选型：开箱即用还是自己搭

如果你想亲自尝试 text-to-cad，现在有几条路可以走。我自己实际测试下来，从易到难大概是这样的排序。

最省事的是用在线工具，直接输入描述就能出模型。不过这类工具一般会限制生成次数，而且模型内部是怎么工作的、提示词是怎么设计的，对你完全不透明，适合先感受一下效果、不适合深入研究。

稍微进阶一点的做法，是用开源项目自己跑。GitHub 上目前比较有代表性的项目是 Zoo（原 AutoGPT 团队开源的那个）和一些基于 CadQuery 的 text-to-cad 实现。Zoo 的做法是把问题拆成了两个阶段：先用模型从文本中提取参数化约束，再调用一个程序化建模库去构建几何体。它还提供了一个可视化的验证环境，你可以直接在浏览器里看生成结果，并且对不满意的部分进行编辑。

如果你本身有编程基础，我更推荐基于 CadQuery 自己搭一套轻量级的流程。CadQuery 是一个非常优秀的 Python 参数化建模库，它跟 OpenSCAD 最大的不同是，CadQuery 用的是“构建实体模型”的思路，修行话叫做 Boundary Representation（BREP），生成的模型是真正的实体，壁厚、圆角、布尔运算这些操作都是精确的，不是靠网格近似。这意味着你生成的模型可以直接用于 3D 打印切片或者 CAM 加工，不需要额外的修复步骤。

我的建议是，如果你是第一次尝试，直接用开源的 Zoo 项目跑通全流程；如果你是开发者，想把这个能力集成到自己的应用里，那就认真研究 CadQuery + 大模型的组合。两者的核心流程是一样的，只是抽象层级不同。

3.2 用 Zoo 跑通第一个模型：完整的实操记录

先说明一下，我用 Zoo 跑通流程是在本地环境下一步步调试出来的，中间踩了几个不小的坑。下面把完整过程拆开讲。

环境准备方面，你只需要一台有 Python 3.9 以上环境的电脑，以及一个 OpenAI 兼容的 API key。项目本身是前后端分离的结构，后端负责调用大模型生成脚本，前端是一个基于 React 的交互界面。

安装过程就是标准的 Git 克隆加依赖安装。不过这里有个容易卡住的点：项目文档要求你配置环境变量、设置模型参数。我用的是 gpt-4o 系列的模型，效果最稳定；换成开源模型跑过几次，效果差距明显，主要是在复杂指令的理解上容易出偏差。

跑起来之后，界面会提供一个文本框。我输入的第一个请求是“create a flathead screwdriver”。系统的处理流程是：先把这条描述发给大模型，让它生成一段 CadQuery 脚本，然后在浏览器里渲染出 3D 预览。

第一次生成的内容，说实话效果还挺出乎意料——它真的生成了一个带手柄的螺丝刀形状，而且比例协调。但仔细看细节，问题就出来了：螺丝刀的头部没有做扁平处理，整个刀体就是个圆柱，也就是说模型的语义理解对了，但几何细节没跟上。

这时候我做了第二件事：手动编辑生成结果。在 Zoo 的界面里，会展示生成这条模型所用的全部参数，比如手柄长度、刀体直径、刀体长度。我可以直接把刀体的形状改成“flattened”类型，或者直接修改刀体直径和长度值。改完参数点重新生成，一个新的模型就出来了。这个过程给了我一个非常直观的感受：参数化建模的好处就在于，它的每一步都是可追溯的、可编辑的，而不是一个黑盒输出。

3.3 自己写 CadQuery 脚本：为什么这一步才是核心能力

用 Zoo 跑通之后，我回过头来自己做了一套轻量的 text-to-cad 流程，核心就是“CadQuery 脚本 + LLM 提示词工程”。这个过程让我对技术本质的理解深了一层。

先举一段 CadQuery 的代码例子，这是生成一个带法兰的管道的最简实现：

import cadquery as cq # 创建管道主体 pipe = ( cq.Workplane("XY") .circle(10) # 外径 20mm .extrude(50) # 长度 50mm .faces(">Z") .circle(10) .circle(8.5) # 内径 17mm .cutBlind(-50) # 挖出内孔 ) # 创建法兰 flange = ( cq.Workplane("XY") .circle(18) # 法兰外径 36mm .extrude(3) # 法兰厚度 3mm ) # 拼合 result = pipe.union(flange) # 导出 STEP 文件 cq.exporters.export(result, "flanged_pipe.step")

这段代码的逻辑非常直白：先拉伸一个圆环柱体作为管道主体，再拉伸一个大的圆柱体作为法兰，最后做布尔并集。

那么问题来了：大模型要什么样提示词才能稳定生成这样的脚本？我试了很多种写法，总结出一个规律——提示词里不能只描述最终形状，还要描述建模策略。如果你只写“generate a flanged pipe with outer diameter 20mm and inner diameter 17mm”，模型生成的脚本里经常会直接用两个圆环做拉伸，逻辑上没问题但代码风格很差，甚至偶尔会出现错误。但如果你在提示词里加上“use CadQuery Workplane, first create the pipe by extruding a circle, then create the flange and union them”，生成质量会明显提升。

这个现象背后有一个扎心的现实：大语言模型不是万能的，它对“建模策略”的理解，并不比你提示词里描述得更多。你给它越明确的步骤指引，它输出的脚本质量就越高。换句话讲，text-to-cad 最终效果的瓶颈，其实很大程度取决于你能不能把建模思路用自然语言清晰表达出来。这跟传统 CAD 建模里“先规划特征树”的思路，本质上是一回事。

3.4 从脚本到可制造模型：补全下游环节

text-to-cad 生成的不只是一个“看得见的三维形状”，它最终要产出的是能用于制造的数据。这一点在实际项目里特别容易被忽视。

CadQuery 可以直接导出 STEP 格式，这是机械设计领域最通用的交换格式，几乎所有的 CAD 软件和 CAM 软件都支持。导出的时候要注意单位问题：CadQuery 默认以毫米为单位，导出的 STEP 文件也是毫米单位，但如果你的下游流程用的是英寸，那么要么在建模时做单位换算，要么在导出时处理。

另外还有一个很多人容易踩的坑：布尔运算后的模型表面可能会存在微小的拓扑瑕疵。在屏幕上看起来没问题，但是在切片软件里就可能导致破面或者打印失败。我的处理习惯是，导出之前用 CadQuery 的clean()方法做一次几何清理，并且用validate()方法检查一下实体合法性。这一步能拦截住大部分“看起来正常但实际有毛病”的模型。

4. 拿来即用的 prompt 模板：我实测出来的有效套路

4.1 稳定的三步式模板结构

实测下来，光说“帮我做一个 XX”是远不够的。我把这几年写 prompt 的经验全部收敛到一个通用模板上，这个模板对 text-to-cad 场景的命中率非常高。模板的结构是：角色设定 + 建模约束 + 输出要求。

角色设定是为了让模型进入“CAD 程序员”这个语境。我通常会在开头加上一句“You are an expert in CadQuery and parametric CAD modeling. Only output the Python code, no explanations.”，目的是去掉模型的解释欲，让它专注于生成可执行代码。

建模约束是整个模板的核心。它必须把用户需求拆成四类信息：基础形状、关键尺寸、位置关系、制造约束。基础形状告诉模型“主体是一个圆环”，关键尺寸告诉它“外径是 20，内径是 17”，位置关系告诉它“法兰在管道的一端”，制造约束告诉它“需要留出 0.5mm 的公差配合间隙”。

输出要求要明确指定代码格式。我会要求模型用cq.Workplane作为起点、用cq.exporters.export导出 STEP 文件，并且要求它只输出一个完整可运行的 Python 代码块。

这个模板可以套到很多场景里。比如做齿轮：

You are an expert in CadQuery and parametric CAD modeling. Only output the Python code, no explanations. Create a spur gear with the following constraints: - Module: 2mm - Number of teeth: 20 - Pressure angle: 20 degrees - Face width: 10mm - Hub diameter: 12mm - Bore diameter: 6mm Use CadQuery. Start with a Workplane. Use the gear generation method if available. Export STEP with key "gear.step".

这里用到了一个重要技巧：如果模型内置了齿轮生成函数，就直接让它调用，而不是让它手写渐开线。原因很简单——大模型手写渐开线的出错率极高，而且出来的齿形不一定符合标准。让模型调用库函数，相当于把专业工作交还给专业工具。

4.2 提示词里最容易忽略的三个细节

第一个细节是“单位”。CadQuery 默认单位是毫米，但很多用户习惯说“cm”或者“inch”。你不告诉模型单位，它就会默认用毫米。我测试过一个案例，用户写“做一个 2cm 高的块”，模型居然生成了 2mm——因为它在抽取参数的时候把“2”单独抽出来了，忽略了单位。现在我的模板里都会强制要求：明确声明所有尺寸都以毫米为单位。

第二个细节是“特征之间的相对关系”。很多新手提示词会写“做一个带孔的圆盘，孔在中间”，但没说孔到底多大。模型只能猜。与其让它猜，不如在约束里明确“通孔直径是外径的一半”。这种相对关系一旦写清楚，模型的正确率能提升一个台阶。

第三个细节是“不要让它做选择”。如果你问模型“你觉得用什么材料合适”，它可能会犯难。但在代码生成任务里，你要的是确定性，不是创意。所以约束条件里不应该出现“或者”“更优”“看情况”这类词，每一项都应该是明确的、不含糊的。这跟写代码的体验一致——越确定的输入，越能产生确定性的输出。

5. 影响范围与应用场景：从快速打样到批量定制

5.1 机械零件快速打样：把“想”变成“可打印”

text-to-cad 最直接的应用场景，就是快速打样。我之前做过一个实验：设计一个带有卡扣结构的小型外壳，传统建模方式下，从画草图到完成特征大概要十几分钟。但如果用 text-to-cad 把需求描述清楚，再手动微调参数，整体能在五分钟内完成。

这个效率差异在“探索性设计”阶段尤其有价值。设计过程中经常有大量“试一下”的需求，这个形状能不能行、那个比例合不合适。传统流程里，每次调整都要回到草图画几笔，改了尺寸还要检查关联约束是否被破坏。text-to-cad 的场景里，你只需要改一句话或者改一个参数，生成新版本就是瞬间的事情。

我实际用过的一个场景是设计 FDM 打印的线材导轮。我只需要告诉它“做一个 V 型槽的导轮，外径 25mm，V 槽角度 60 度，中心孔 5mm，轮宽 8mm”，生成结果基本上一次就能用。这种零件本身结构简单，几何关系明确，是 text-to-cad 的“舒适区”。

5.2 设计自动化的新范式：批量生成变体

text-to-cad 的底层能力是“参数化描述 + 自动建模”，这意味着它天然可以做批量变体生成。如果有 50 种不同规格的支架需要建模，传统做法是建一个参数化模型，然后逐个修改参数生成配置。text-to-cad 的做法更直接：给大模型一个模板风格描述，然后列出一张参数表格，让模型循环生成。

我在实际测试中做了一件这样的事：给出同一个提示词模板，改变关键尺寸参数，让模型生成了一批不同尺寸的垫片模型。整个过程不需要写一行代码，只需要维护一个 CSV 文件，每一行是不同规格的参数。这个能力对非程序员背景的设计师特别友好，他们不需要学参数化建模软件的操作逻辑，只需要会填表就行。

当然这里有个现实问题，批量生成时的可靠性不像传统参数化建模那么高。50 个模型里大概率有 2~3 个会出现局部错误，需要检查。我的做法是添加了一个自动化的“尺寸抽查”环节：用 CadQuery 的val()方法提取关键尺寸，跟参数表做对比，不一致的标红。这一套流程跑下来，基本能保证最终的模型清单可用。

5.3 教学与知识管理：用自然语言沉淀建模经验

还有一个我关注的方向，是 text-to-cad 对 CAD 知识管理和教学的影响。

在传统 CAD 教学里，最大的难点是“参数的抽象理解”。学生要搞清楚“为什么这个特征是先建主体再切孔”“为什么这个约束必须加在草图上”。text-to-cad 其实改变了这个认知过程：你不需要先学会软件操作，而是先学会“用语言表达设计意图”，然后观察大模型是怎么把语言翻译成建模操作的。这个过程本身就是一种“建模思维”的教学。

另外，text-to-cad 的 prompt 也可以当成一种“可执行的知识文档”。过去记录一个零件的建模方法，你要么写文档配截图，要么录视频，要么分享源文件。现在你可以直接写一段自然语言描述，存下来，下次要生成同样类型的零件时直接复用。描述越精确，复现效果越好。这相当于把建模经验变成了一种可以被检索、被复用的“活性资产”。

6. 常见问题与排查技巧：我踩过的那些坑

6.1 代码生成正确但执行报错：大概率是依赖环境问题

我在实际操作中最常遇到的一类问题，是大模型生成的代码看起来完全正确，但一跑就报错。比如 CadQuery 报出ValueError: Can't extract vertices from a non-solid这类错误，新手很容易慌，以为是模型写错了。

遇到这种情况，我会按固定顺序排查。第一步，检查 CadQuery 版本。不同版本的 API 有细节差异，比如circle()方法在旧版本里需要传半径、在新版本里可以传直径，这种差异很容易导致报错。第二步，检查是否存在多余的几何操作。比如你先拉伸一个圆柱，然后又对同样的面做一次拉伸，可能产生无效的过度约束。第三步，用最简代码复现。如果一段代码里有多步操作，删掉后面的一半，看前半段能不能正常运行，用二分法定位错误点。

这里也要提一个现实问题：大模型有时候会“幻觉”出一些不存在的 API 方法。比如我让它生成螺纹的时候，它给我编了一个thread()方法，CadQuery 里根本没有这个方法。遇到这种情况，最好的策略不是在提示词里纠正它，而是在提示词里明确要求“only use standard CadQuery Workplane methods”,模型就不太敢自由发挥了。

6.2 模型尺寸稳定但几何关系错乱：语义理解偏差

另一种典型问题是：尺寸都对，每个圆直径都对，但位置关系错了。比如孔应该在外围均匀分布，结果全部排成一条直线。

这个问题归根结底是模型的空间推理能力不足。大语言模型本质上是一个“文本模式匹配器”，它能把关键词对应上，但没法真正“想象”空间里这些几何元素的位置关系。

我实测了一些改进办法，最有效的是“用相对坐标描述位置关系”。不要写“四个孔均匀分布在法兰上”，而要写“four holes at radius 12mm, evenly spaced at 0, 90, 180, 270 degrees”。显式的角度信息能让模型少走很多弯路。同理，描述偏置特征时，不要说“靠右边”，要说“offset 10mm in X direction”。

另一个办法是加“中间步骤”。如果模型一次生成完整代码经常出错，你可以把建模拆成两步：先生成主体几何，再生成附加特征，然后在最终代码里把它们组合起来。我自己常用的一种做法是：先让模型生成一个“实体外壳”的代码，运行验证通过了，再让它在这个外壳上加“加强筋阵列”。分步走之后，出错率会大幅下降，因为每一步的上下文更简单，模型不容易“丢信息”。

6.3 生成结果太“塑料感”：缺少制造意识

最后一个问题比较隐蔽，但做实际制造的人一定会遇到——模型生成的几何形状“看起来对”，但完全不懂加工工艺。比如有个模型给你生成了一个薄壁壳体的底部是尖角，没有圆角过渡，这在 3D 打印时会产生应力集中，在 CNC 加工时也无法直接用刀具加工出来。

这不是模型能力的问题，而是提示词里缺少制造约束。解决办法是给提示词加一道“工艺说明”：“This part will be CNC machined from aluminum. Avoid sharp internal corners; use fillets with radius at least 1mm at all internal edges.” 加上这类约束之后，模型生成的代码里会自动出现fillet()操作。

我一直觉得这是 text-to-cad 最有意思的地方——它的上限其实不是由模型决定的，而是由你的领域知识决定的。你越懂制造、越懂 CAD，你就越知道要在提示词里补充什么约束，你的生成结果就越可用。

7. 一点个人体会：别神话它，也别低估它

在这件事上玩了几个月之后，我最想说的是：text-to-cad 是一个非常好用的“草稿生成器”，但离“智能设计助手”还有不小的距离。它最擅长的场景是：你脑子已经有一个清晰的几何形状，只是不想手动一步步操作建模软件。它最不擅长的场景是：你只有模糊的功能需求，希望它帮你从零构思一个合理的设计方案。

举一个例子。你告诉它“帮我设计一个能放两个手机和一个钥匙的桌面收纳盒”，它大概率会给你生成一个方盒子，但你想要的可能是带倾角的分隔槽、预留充电线孔、圆角防刮手——这些“设计决策”如果不在提示词里明说，模型是想不出来的。

所以在使用这个工具的时候，我的建议是：把它当成一个“高效的建模手”，而不是“设计师”。你想清楚要什么，它帮你把实现过程自动化。这种分工目前来看是最高效的。

还有一个实际操作的彩蛋：如果你后续要把模型导入到 Fusion 360 或者 SolidWorks 里继续编辑，建议直接生成 STEP 格式而不是 STL。STEP 保留了实体边界表示的所有信息，包括面、边、拓扑关系，后续修改起来要方便得多。STL 只是一个三角网格近似，一旦导入，就基本没法做参数化编辑了。

text-to-cad 这个方向肯定是会持续发展的，因为它的价值链条很清晰：降低建模门槛、加速设计迭代、让设计经验变成可复用的资产。如果你也想研究这个东西，不要只看演示视频，自己动手跑一遍、改几个参数、写几段不同类型的提示词，比看一百篇分析文章都有用。这个领域最好的学习方法，就是亲手把第一个模型制造出来。