text-to-cad全解析：从自然语言到参数化CAD模型的工程落地

text-to-cad 这个词，圈内人看到的第一反应多半是“又一个人工智能画图工具”。但真正上手试过之后就会发现，它要解决的根本不是“画图”这件事，而是把“脑子里想的一个零件”变成“能加工、能装配、能改尺寸的三维实体”这条完整链路。这两年我一直在折腾 AI 辅助设计，也拿 text-to-cad 的思路做了不少实际项目，从早期只能生成一堆好看的网格模型，到现在能稳定输出可编辑的参数化 CAD 文件，中间踩的坑比想象中多得多。

这个方向适合三类人：一类是做参数化设计的机械工程师，天天跟尺寸、约束、特征树打交道；一类是做自动化生成设计的开发者，想把“需求描述到模型生成”的环节用程序接管；还有一类是纯粹好奇 AI 建模的爱好者，想看看大语言模型在工程领域到底能走到哪一步。不管你是哪一类，这篇文章都值得看完——我会把 text-to-cad 背后的原理、工具链、实操流程和常见坑一次性讲清楚。

1. 先搞清楚 text-to-cad 到底在解决什么问题

1.1 传统 CAD 建模的痛点在哪里

我接触过的工程师里，几乎没有一个人喜欢“从零开始画图”。大家真正想要的是一个能直接表达设计意图的工具——我说“这里需要一个直径 30 的孔，深度 20”，软件就应该把这个孔建出来，而不是让我先建一个草图、选一个平面、画一个圆、拉一个深度，再点一堆约束。CAD 软件发展了四十多年，核心交互方式还是鼠标点选加键盘输入，学习成本极高，一个简单的零件，新手可能要学两周才能上手，老手建模也要不断在草图、特征、布尔运算之间来回切换。

text-to-cad 想做的事情很直接：把自然语言作为输入接口，让用户用说话的方式描述“我要什么”，然后自动生成对应的三维模型。这样做的价值不在“省去画图那几分钟”——几分钟对一个工程师来说不算什么，真正的价值在于把设计门槛打下来，同时让设计过程和需求描述直接挂钩。产品经理说“我要一个能放 4 寸手机壳的支架”，工程师不用先去理解“4.7 英寸”“卡扣配合”“脱模斜度”这些专业表达怎么翻译成 CAD 特征，而是让系统直接从一个口语化的需求描述里生成一个可用的初版模型。

这个方向还有一个隐性需求，就是批量化和参数化。如果你要生成 100 个不同尺寸的支架，传统做法是用参数化模板或者写脚本，但脚本也不是谁都会写的。text-to-cad 如果能把“描述中有哪些可变参数”这个信息自动提取出来，那批量生成就变成了改一句话的事。

1.2 它不是“文生图”的 CAD 版

很多人把 text-to-cad 理解为“文生图（text-to-image）在三维建模上的应用”，这个类比有道理但也最容易误导人。文生图生成的是像素矩阵，目标是视觉上“像”；text-to-cad 生成的是几何模型，必须在数学上精确。图生成出来哪怕某个倒角位置偏移了 0.5 毫米，人眼根本看不出来；但 CAD 模型里的孔位如果偏移 0.5 毫米，零件装不上就是装不上，这是物理世界的规则，不跟你讲“神似就行”。

所以 text-to-cad 的核心难点从来不是“让模型输出一个好看的三维形状”，而是“让生成的模型具备真正的工程可用性”。什么叫工程可用？尺寸精确、特征完整、约束清晰、可以被后续的特征操作继续编辑，还能量产加工。这个标准比文生图的“以假乱真”要苛刻得多。理解了这一点，后续所有技术选型和分析才有着落。

2. 两条技术路线，为什么主流的都选“代码生成”

2.1 路线对比：直接生成几何 vs 生成程序化建模代码

目前业界做 text-to-cad 大致有两条路线。

直接生成几何：用神经网络直接输出体素、点云、隐式曲面或者网格（mesh），然后想办法转成 CAD 能识别的格式。这条路线学术论文里特别多，方法也很“酷”，因为你让模型直接预测一个三维形状的坐标和拓扑信息。但实际用起来问题很大：神经网络输出的曲面是近似的，转成 STEP 或者 BREP 格式之后边缘会毛糙，拓扑经常是错的，而且生成的结果无法参数化——你想改一个孔的直径，只能整个重新生成，或者回网格里手动调整，这跟 CAD 的工作方式根本不在一个频道上。

生成程序化建模代码：让大语言模型输出一段代码，这段代码调用某个程序化建模库（比如 OpenSCAD 的 CSG 语法、CadQuery 的 Python API），在本地执行这份代码，由几何内核生成最终模型。这个路线的核心思想是：LLM 不直接“画”几何，而是“写一段如何构建几何的指令”，真正的几何计算交给可靠的 CAD 内核完成。

第二条路线现在明显更受工程界认可。原因也简单——它把“AI 生成”和“CAD 内核精度”这两个优势结合起来了。LLM 负责它擅长的语言理解和结构化表达，几何内核负责它擅长的精确计算。你生成的不是一堆三角形面片，而是一份可执行的建模脚本，这份脚本回到 CAD 环境下还能继续编辑。前期我做技术选型时对比过大量方案，最终定下来也是走这条路线，实操下来的感受是：靠谱程度比直接生成几何高了一个数量级。

2.2 为什么 LLM 天然适合生成 CAD 代码而非几何

要理解这个选择，得先明白大语言模型的本质：它做的是离散符号的序列预测，不是连续数值的回归。而 CAD 几何模型是连续数学对象，一个自由曲面在数学上可能需要上千个控制点才能精确定义。你让 LLM 直接输出这些控制点，它在数学上不具备这个能力——这不是模型不够聪明，而是架构决定的：LLM 的每个输出 token 都是从离散词汇表里选的，拿它生成一串精确到小数点后六位的坐标序列，几乎必然出错。

但程序代码也是离散符号，而且代码的“单词”有限——cylinder、cube、difference、union，这些词汇是有边界的。LLM 对这类结构化语言的掌握能力非常强，它只需要把“描述”翻译成“API 调用序列”就可以了，几何的连续性由库的底层实现去保证。打个比方：LLM 不是那个雕塑家，它是那个拿着积木说明书给你念“把蓝色的 2x4 积木搭在红色 2x2 积木上”的讲解员。积木之间能不能严丝合缝，由积木本身的精度决定，讲解员只负责把组合顺序说对。

这条路线还有一个隐藏优势：纠错成本极低。生成的代码如果报错，日志里会告诉你哪一行有问题；如果几何不对，你可以在源码里看到具体的参数。对比之下，直接输出网格的路线，你连“错在哪”都很难定位。

2.3 程序化建模库的选型：OpenSCAD、CadQuery 还有谁

实操层面，生成代码的路线需要选定一个目标库，这决定了 LLM 要学习什么样的语法。目前主流选择集中在几个方向。

OpenSCAD 和它的 CSG 语法：这个开源工具是我最早用的一类，语法简单、纯粹靠代码定义几何，教程多、上手快，特别适合验证想法。它的核心是 CSG（构造实体几何）——用几何体做并集、差集、交集来生成复杂形状。LLM 学这种语法几乎没有压力，因为 API 的种类特别朴素。

CadQuery：用 Python 写的程序化建模框架，API 更接近传统 CAD 的操作逻辑，可以创建草图、拉伸、旋转、倒角，还可以基于面、边等几何元素做后续操作。如果你已经熟悉 Python 和传统 CAD 的建模流程，CadQuery 的表达能力远强于 OpenSCAD，生成的基础形状更加接近真实工程零件的建模习惯。

还有更工程化的方案，比如直接生成某个商用 CAD 软件的宏脚本。但这类方案有个大问题：宏脚本跟软件版本强绑定，迁移性差，而且 LLM 对私有格式的学习语料有限，错误率明显偏高。我的经验是，先跑通 OpenSCAD 或者 CadQuery 这类开源方案，再根据实际需求决定要不要迁移到更重的平台。

3. 从零搭建一个可用的 text-to-cad 工作流

3.1 工具链准备

我之前搭建的这套工作流，全部基于开源和免费工具，不需要花一分钱，也可以完全在本地跑。

• LLM 部分：我测过多种模型，结论是逻辑和代码能力越强的模型，CAD 生成质量越高。不过受限于当前算力环境，这里就不给出具体的模型型号，你可以在开源社区找到推理能力不错且支持 Function Calling 的选项，效果都接近。关键点在于：选择的模型要能输出结构化代码，还要能遵循明确的格式约定。
• 程序化建模库：首选 OpenSCAD 作为初始验证目标，因为它的语法简单，LLM 不容易犯错。扩展到 CadQuery 可以后面再说。
• 模型预览：OpenSCAD 自带的预览渲染虽然简陋，但做基础验证足够。需要做光滑曲面预览时，可以导出 STL/STEP 后用免费查看器观察。
• 格式转换：这时用到openscad这个命令行工具，它可以直接把.scad文件导出成.stl、.step、.dxf等格式，方便后续检查或者切片。

核心闭环是这样的：自然语言描述 → LLM 生成代码 → 执行代码生成模型 → 可视化检查 → 反馈修正 → 得到可用 CAD 文件。如果没有图形界面环境，命令行也算顺手，反正几步操作而已。

3.2 提示词工程设计：把“一句话需求”变成“精确建模指令”

很多教程会让你直接输入“给我生成一个杯子”，然后期待 LLM 变出一个完美的杯子。实际结果通常是生成一个能看的杯子，但尺寸完全随缘——壁厚 5 毫米，容量少一半，谁拿这个去打样？问题就出在：你的提示词里根本没有给 LLM 足够的约束信息。

我用下来最稳的提示词结构是包含这几个要素的：目标物体名称、关键尺寸参数、特征描述、输出格式要求。下面这个示例可以直接照抄：

创建一个机械零件模型，文件名 output.scad。 零件类型：带法兰的圆柱壳体。 参数要求： - 法兰外径 80mm，厚度 8mm，法兰上有 4 个通孔，孔径 8mm，均匀分布在直径 65mm 的螺栓圆上； - 壳体部分外径 50mm，内径 44mm，高度 60mm； - 壳体底部封闭，顶部开口。 请使用 OpenSCAD 的 CSG 语法实现，并在代码中将要调整的尺寸定义为变量。 不要输出任何解释，只输出 .scad 代码。

看到没有，通孔数量、分布圆直径、壁厚（通过内外径间接定义）全都写清楚了。这里有一个细节值得解释：为什么用“内径 44”而不是直接说“壁厚 3”？因为 LLM 对“壁厚”这个概念有歧义——壁厚 3 可以指径向厚度，也可能让模型理解成加一个厚度为 3 的轮廓偏移，直接给内外径反而更不容易出错。类似这样的小技巧，都是我在反复试错中总结出来的。

反过来，如果你只写“给我一个带螺栓孔的圆法兰”，LLM 默认生成的可能就是 4 孔或 6 孔随机版本，孔的大小、分布圆直径全凭它的训练语料猜测。起一个具体的规格，生成的才算真正能用。

3.3 测试样例：从简单圆柱到多特征零件

当工具链准备完毕，我会用一个最简单的模型测试链路是否通畅：直径 30、高 50 的圆柱体。这个测试看起来有点傻，但它能快速验证 LLM、代码执行、格式导出、模型预览这一整套流程有没有断点。如果这一步都跑不通，后面复杂模型只会让问题加倍。

通过之后，紧接着会测试一个稍微复杂的模型，让提示词里同时包含“旋转”“阵列”“布尔差集”这些程序化建模特征。比如这样一段：

创建一个法兰底座，底座为边长 70mm 的正方形板，厚度 10mm； 在底座中心生成一个圆柱形凸台，凸台外径 36mm，高度 25mm； 凸台中心打一个直径 20mm 的贯穿通孔； 底座四个角上各有一个直径 7mm 的贯穿孔，孔心距相邻两边 12mm； 所有边添加 2mm 倒角。 使用 OpenSCAD 语法生成。

这里明确要求“贯穿孔”就非常关键。中文里“孔”是个模糊概念，盲孔和通孔在建模上完全是两件事。LLM 对这类语义的区分能力比想象中差，尤其是训练数据里中英文混杂的情况下，我遇到过不少把通孔生成盲孔的例子。所以作为用户，你得在提示词里把这类语义决策替它做了。

生成后的代码大概长这样，我贴一段经典的 CSG 示例，你可以直接跑：

$fn = 64; // 参数变量 plate_w = 70; plate_t = 10; boss_d = 36; boss_h = 25; hole_d = 20; corner_hole_r = 3.5; corner_offset = 12; chamfer = 2; // 底座板 difference() { // 带倒角的板 minkowski() { cube([plate_w - chamfer * 2, plate_w - chamfer * 2, plate_t - 0.01], center = true); sphere(r = chamfer, $fn = 32); } // 四个角孔 for (x = [-1, 1], y = [-1, 1]) { translate([x * (plate_w / 2 - corner_offset), y * (plate_w / 2 - corner_offset), -1]) cylinder(r = corner_hole_r, h = plate_t + 2, $fn = 32); } } // 圆柱凸台 translate([0, 0, plate_t / 2]) cylinder(d = boss_d, h = boss_h, $fn = 64); // 中心贯穿孔 translate([0, 0, -1]) cylinder(d = hole_d, h = plate_t + boss_h + 2, $fn = 64);

这段代码不复杂，但它示范了“参数变量 + 布尔运算 + 循环阵列”这三个程序化建模最核心的能力。LLM 生成这类代码的完成度，在现有模型下已经相当高了，偶尔会有小语法错误，但基本是可修正级别——这比直接生成几何要可控得多。

3.4 输出的验证与迭代闭环

很多人拿到生成的模型就完事了，这是新手最容易犯的错误。text-to-cad 流程里，验证和迭代不是可选项，是必选项。我自己的标准流程分三步：

第一步，代码编译检查：运行 OpenSCAD 编译，有报错就贴回给 LLM 改。这个循环通常只需要两三轮就能过。

第二步，视觉检查：看渲染结果，重点关注特征数量对不对、孔的阵列位置对不对、有没有明显的布尔运算残留（比如壳体上多出一块没减干净的材料）。这里注意，预览分辨率会影响显示效果，把$fn调高再看一次，别被低分辨率假象骗了。

第三步，尺寸抽查：直接打开生成的模型或者读取脚本里的参数变量，确认关键尺寸和需求描述一致。如果是 STL 导出，还可以用测量工具量一下关键特征，防止某些库处理布尔运算时产生微小偏差。

实测下来，一个中等复杂度的零件，通常需要 2-5 轮“生成—检查—修正”循环才能达到可用状态。这不是失败，而是工作流的一部分。那些声称“一句提示词直接出可用模型”的演示，大概率只停留在演示层面。

4. 实操中常见的坑与排查思路

4.1 参数幻觉：LLM 会“一本正经”地编尺寸

这是 text-to-cad 最典型的问题，没有之一。你让模型生成一个 50mm 高的壳体，它可能输出h = 55，而且代码完全符合语法，渲染也能跑，不仔细看根本发现不了尺寸是对不上的。原因在于 LLM 本质上是在做“最可能的词序列”预测，它并不理解“50mm”这个数在物理上意味着什么，只是觉得“50 附近出现 55 也合理”。

我的对策是：在生成代码之后，强制要求模型把所有关键尺寸提取成变量，并在代码开头注释里标注“以下变量必须与需求一致”。这一步不能省，标注不仅提高模型即将生成数字对应关系的注意力，还能让你在后续检查时有明确的对照表。更进一步的骚操作是：在提示词里要求模型在代码末尾加一段assert或者以注释形式输出参数表，然后我会写一个小脚本自动解析参数表，跟原始需求自动比对。这个自动化检查对批量生成特别有用。

4.2 布尔运算失败：CSG 的“共面”陷阱

程序化建模最常见的失败模式是布尔运算不稳定。两个几何体如果完全共面，或者两个面只是恰好贴合，CSG 内核在计算差集、交集时经常出问题——要么报错，要么留下零厚度的面片，要么“减掉”的部分突然反弹出来。

这个问题的根源是工程的精度问题：计算机里不能精确表示“面刚好贴合”，浮点数精度有限，共面的判断本身就不可靠。解决方案有三板斧：

• 差集运算时，让被减的几何体比目标深一点点或大一点点，比如通孔的高度多加 1mm，避免底面恰好共面；
• 联合运算时，给相邻体之间留 0.01mm 的微小重叠，而不是单纯靠边贴合；
• 遇到圆角、倒角操作时，把倒角放在最后一步，因为倒角会改变拓扑结构，先倒角再打孔容易产生碎边。

这些都不是 LLM 特有的坑，传统 CAD 建模也经常遇到。但因为 LLM 生成代码的随机性，它踩中这些坑的概率比人类建模师高得多。所以我在提示词里会特别叮嘱一句——如果要做布尔差集，让减除部分略微超出主体边界，这能显著降低失败概率。

4.3 格式选择：STL 不是 CAD

很多用户生成完模型直接导出 STL 就“收工”了。如果只是 3D 打印，那问题不大；但如果你要把它导入到传统 CAD 环境做后续设计，或者交给加工厂 CNC 加工，STL 就是灾难——它是网格格式，没有参数特征，没有历史树，只有一堆三角面片，改任何一个尺寸都等于重画。

正确的做法是：从工作流一开始就想清楚最终交付格式。需要参数化编辑就用.scad或 CadQuery 的.py文件作为主格式；需要和其他 CAD 平台交换就用.step；只有确定直接 3D 打印才考虑 STL。在 text-to-cad 的语境下，“可编辑的程序化文件”才是真正的产出物，渲染出来的网格只是中间检查用的半成品，别把顺序搞反了。

4.4 中文描述的处理和表达精度

用中文描述 CAD 需求时，有很多表达容易产生歧义。“穿个孔”是通孔还是盲孔？“削平一块”是切一个台阶还是去掉一个长方体？“圆角”是半径多少？这些在工程图里都有严格定义的东西，在自然语言里全都模糊了。

我的建议是，在提示词里建立一套“需求描述规范”：尺寸必须带单位；所有孔位标明是通孔还是盲孔；涉及位置关系时用绝对坐标或相对基准面来描述；特征操作尽量用 CAD 术语，少用日常口语。这不是因为 LLM 理解不了口语，而是口语带来的歧义会显著降低输出稳定性。如果你希望模型稳定，给你的输入降噪。

4.5 复杂装配体和功能约束仍是难点

text-to-cad 目前在“单个零件”层面的表现已经可圈可点，但如果你试图让它一口气生成一个包含 20 个零件的装配体，结果通常很惨——零件之间的配合关系、干涉检查、运动自由度这些信息，光靠一段自然语言描述根本无法完整传递。LLM 会各自生成每个零件，但零件之间没有相互约束，尺寸不匹配、坐标系不对齐是家常便饭。

现阶段务实的做法是生成单个零件或者简单的零件组，装配层面的工作仍然需要人工介入。更合理的工作流是：用 text-to-cad 快速生成各零件的初版，再导入传统 CAD 环境里做配合约束。相当于 AI 负责出“毛坯”，工程师负责“精加工”。

5. 技术边界：识别“可用”与“不可用”之间的分界线

不只是工具，更是一个关于预期管理的问题。

什么样算“可用”？以我自己大量的实操经验来看：单个中等复杂度的零件，语义上能正确识别主要特征，几何尺寸可以通过参数核对校准到能用公差范围内，特征树大致合理，可以被后续操作继续编辑——这就是可用的门槛。至于外观是否完全符合直觉（比如某个圆角位置跟你想的不一样），反而不那么关键，因为这类视觉层面的偏差，修改一个参数往往就解决了。

什么样算“不可用”？输出的是网格而非参数化实体；特征之间没有清晰边界，整个物体是一坨融合在一起的曲面；尺寸语义完全错乱（比如把通孔做成盲孔）；或者关键功能特征（比如螺纹、卡扣）丢失——任何一个问题都能让生成的模型无法进入下游制造流程。

我见过最典型的“现象级翻车”是：提示“创建一个有 8 个螺纹孔的圆形端盖”，结果生成的是一个圆形端盖加 8 个圆柱凸起，没有沉孔的概念，螺纹孔被翻译成了固定圆柱。这种问题不是尺寸偏差，而是语义级错误——LLM 对“螺纹孔”这个装配特征的建模表达方式理解不足。应对方法是：提示词里提前定义“螺纹孔 = 先打底孔再生成螺纹特征”，把复杂概念拆解成它熟悉的基础操作，效果立竿见影。

6. 文生 CAD 的趋势和扩展空间

做完整套工作流之后，我对这个方向的判断是：它不会取代 CAD 工程师，但它一定会改变 CAD 的使用方式。就像命令行没有取代图形界面，但让专业用户有了更高效的操作路径一样，text-to-cad 会成为设计流程里的“加速器”和“接口层”。

扩展空间有几个明显的方向值得关注：

一是从“零件级”到“装配级”的跃迁。当前主流方案聚焦在单个零件，下一步的关键突破点在于零件间配合关系的自动推导——需要在语言描述里引入“约束传播”的机制，让 LLM 输出的不只是独立零件，而是带配合基准的零件集。

二是从“几何生成”到“功能生成”。现在的 text-to-cad 生成的是形状，但工程师真正关心的是功能——这个支架能不能承受 50kg 的力？这个卡扣能不能扣合 5000 次？如果能在生成阶段引入仿真反馈，让模型根据应力分析结果迭代修改几何，这就不是“文生 CAD”了，这是“文生设计”。

三是和制造约束的打通。生成模型时同步考虑加工工艺——这个内腔结构 CNC 能不能加工出来？那个悬垂部分 3D 打印需不需要加支撑？把 DFM（面向制造的设计）规则编入提示词约束或后处理检查环节，会让生成结果的可用率再上一个台阶。

我自己目前在做的一个小项目，就是把 text-to-cad 的输出和自动化出图绑在一起——生成模型后，自动计算质量、重心、投影视图，直接输出初步工程图。技术上没什么难度，但实际用起来非常爽，因为从“一句话”到“一张可评审的图纸”这件事情，过去最少要半天，现在几分钟搞定。

写在最后的一点个人体会

text-to-cad 这个名字听起来像是个科幻概念，但真正落地实现以后，它反而让 CAD 变得更“不酷”了——这里的“不酷”是褒义。AI 把那些繁琐的建模步骤吃掉了，剩下的才是设计里真正有价值的判断：这个零件为什么要长这样，这个尺寸为什么定成这个值，这个特征和那个特征之间应该是什么关系。我实操下来的体会是，能把 AI 生成的模型用好的人，往往不是提示词写得最华丽的，而是对自己的需求描述得最清楚的人。反过来，这也逼着使用者把脑子里的模糊想法梳理成精确的工程语言——这个过程本身，就是一个合格工程师的必修课。如果你打算入坑，第一课就从这个梳理开始吧。