Text-to-CAD：从自然语言到三维模型的生成技术与工程实践

1. 从一句话到三维模型：text-to-cad 到底在解决什么问题

第一次听到 “text-to-cad” 这个说法，是在一个做机械设计的朋友那里。他当时正对着屏幕上一堆草图发愁，嘴里念叨着：“要是能直接打一行字就出模型，谁还愿意一根线一根线去画。” 这句话其实点到了很多做产品设计、工业建模、甚至三维打印的人心里最痒的那个地方——用自然语言直接生成可编辑的 CAD 模型。

text-to-cad，拆开来看就是 text 到 CAD。text 是自然语言描述，比如“一个边长 50 毫米、壁厚 3 毫米、带四个 M4 安装孔的正方体外壳”；CAD 则是计算机辅助设计模型，通常指参数化实体、网格或者可继续编辑的工程文件。它要解决的问题很直接：把人类脑子里的几何意图，用最省事的方式翻译成机器能理解的三维结构。传统路径是打开建模软件，画草图、拉伸、打孔、倒角，一套流程下来，简单零件也要十几分钟。text-to-cad 想做的，是把这段重复劳动压缩成一句话。

适合关注这个方向的人其实比想象中多。做快速原型的产品经理，需要频繁验证外观和装配关系；做三维打印的玩家，想批量生成小配件但不想学复杂建模；做机器人仿真的工程师，需要大量结构相似但尺寸不同的零件；还有做教育演示的老师，想让学生用文字描述就能看到三维结果。这些人未必都是 CAD 高手，但都有“把想法快速变成三维实体”的刚需。

我实测下来，目前 text-to-cad 并不是一个单一软件，而是一类技术路线的统称。有的走代码生成路线，把文字转成 OpenSCAD 或 CadQuery 脚本；有的走大模型直接生成网格路线，输出 STL 或 OBJ；还有的走参数化模板匹配路线，从预置库里找最接近的模型再微调。每条路线的成熟度、可控性和输出质量差别很大，后面会逐一拆开讲。

注意：text-to-cad 目前还远没到“一句话出完美工程图”的程度。它更像一个高级草稿生成器，能帮你跳过从零开始的阶段，但尺寸校验、公差配合、可制造性检查仍然需要人工介入。

2. 三条主流技术路线拆解与选型逻辑

2.1 代码生成路线：文字转 OpenSCAD 或 CadQuery

这是目前最可控、最适合工程场景的一条路。核心思路是让大语言模型把自然语言翻译成参数化建模脚本，再由脚本引擎渲染出三维模型。OpenSCAD 和 CadQuery 是两个最常被选中的目标语言。

OpenSCAD 的优势是语法极简，本质上是“描述几何体的编程语言”。比如要一个带孔方块，代码大概长这样：

difference() { cube([50, 50, 20], center=true); translate([0, 0, 0]) cylinder(h=25, r=2.5, center=true, $fn=64); }

这段代码的意思是：先做一个 50x50x20 的方块，然后在中心挖一个半径 2.5、高度 25 的圆柱孔。大模型要做的，就是把“边长 50、厚 20、中心有一个直径 5 的通孔方块”这样的描述，映射成上面的代码结构。

CadQuery 则更偏向工程化，基于 Python，能输出 STEP 这种标准工程格式，方便后续导入 SolidWorks 或 Fusion 360 继续编辑。它的代码风格是这样的：

import cadquery as cq result = ( cq.Workplane("XY") .box(50, 50, 20) .faces(">Z") .workplane() .hole(5) )

选这条路线的原因很实在：生成结果可复现、可参数化、可版本管理。你拿到一段脚本，改几个数字就能得到新零件，特别适合做系列化设计。而且脚本是纯文本，方便用 Git 管理，团队协作时 diff 一目了然。

但这条路线也有门槛。大模型生成的脚本经常有语法错误，比如括号不匹配、变量未定义、坐标系搞反。我试过让模型生成一个“带四个角孔的板”，结果它把孔打在了侧面而不是顶面，原因就是 workplane 选错了。所以代码生成路线必须配一个“执行-报错-修正”的闭环，不能指望一次成型。

2.2 网格直接生成路线：文字转 STL 或 OBJ

这条路线更接近“AI 画画”的思路。用大规模三维数据集训练扩散模型或自回归模型，输入文字描述，直接输出三角网格。代表思路包括基于点云扩散、基于隐式场、基于体素的方法。

它的最大优点是形状自由度高。你描述一个“流线型、带有机曲面、像水滴一样的支架”，代码生成路线很难用简单几何体拼出来，但网格生成模型可以输出一个视觉上很接近的曲面。做概念设计、角色道具、艺术造型时，这条路很吸引人。

问题也同样明显。第一，尺寸精度不可控。你说“长 100 毫米”，它生成出来的模型可能实际尺寸是 97.3 毫米，而且没有参数可以调。第二，拓扑质量参差不齐。三角面片可能自交、法线翻转、存在非流形边，直接拿去打印会切片失败。第三，不可编辑。你没法像参数化模型那样改一个孔的位置，只能重新生成。

我个人的判断是：网格路线适合“看形状”的阶段，不适合“做零件”的阶段。如果你只是想要一个视觉参考，或者做渲染图，它可以省很多事。但如果你要装配、要受力、要加工，还是得回到参数化路线。

2.3 模板匹配与参数填充路线

这条路线介于前两者之间。系统预置一批参数化模板，比如“法兰盘”“支架”“外壳”“齿轮”“铰链”。用户输入文字后，模型先做意图识别，判断属于哪类零件，再抽取关键尺寸参数，最后把参数填入模板生成模型。

它的优势是输出质量稳定、尺寸精确、生成速度快。因为模板本身是人工校验过的，几何拓扑没问题，参数一填就能用。对于标准件、常用结构，这条路最实用。

局限在于覆盖范围受模板库限制。你描述一个模板库里没有的形状，系统就无能为力，或者只能强行套一个不合适的模板。所以这条路适合做垂直场景，比如“只做 3D 打印常用小配件”，而不是通用建模。

下面这张表可以帮你快速判断该选哪条路：

实操心得：如果你刚开始尝试 text-to-cad，建议从代码生成路线入手。它的反馈最直接，出错也最容易定位。网格路线看起来酷，但调试成本高，容易打击信心。

3. 核心环节实操：从文字到可打印模型的完整流程

3.1 提示词怎么写才不容易翻车

很多人以为 text-to-cad 的提示词就是随便说一句话，其实不然。自然语言有大量歧义，而几何建模对歧义零容忍。“一个圆角盒子”这句话，圆角半径是多少？盒子是空心还是实心？圆角加在哪些边？这些不写清楚，模型只能猜，猜错概率极高。

我总结了一个五要素提示词结构，实测能显著提升首次生成成功率：

1. 主体形状：方块、圆柱、球体、锥体、拉伸体、旋转体，或者组合描述。
2. 关键尺寸：长宽高、直径、半径、壁厚，单位统一用毫米。
3. 特征细节：孔、槽、倒角、圆角、凸台、螺纹，说明位置和数量。
4. 空间关系：对称、居中、阵列、同心、垂直、平行。
5. 输出要求：格式（STEP/STL/SCAD）、是否需要参数化、是否需要可打印。

举个例子，不要写“做一个安装板”，而要写：“一个长 120 毫米、宽 80 毫米、厚 6 毫米的矩形安装板，四角各有一个直径 4.5 毫米的通孔，孔中心距边缘 10 毫米，所有棱边倒 1 毫米圆角，输出 STEP 格式，尺寸参数化。”

这样一段描述，代码生成模型基本能一次写出可运行的 CadQuery 脚本。我试过用五要素结构对比随意描述，首次成功率从不到三成提升到七成以上。

3.2 代码生成路线的执行闭环搭建

光有提示词还不够，你需要一个能自动执行、捕获错误、反馈修正的闭环。我自己的做法是用 Python 写一个轻量调度脚本，流程如下：

1. 接收用户文字描述。
2. 调用大模型生成 CadQuery 或 OpenSCAD 代码。
3. 在沙箱环境中执行代码，捕获标准输出和异常。
4. 如果执行失败，把错误信息拼回提示词，让模型重新生成。
5. 最多重试 3 次，仍失败则返回错误报告。
6. 成功后导出 STEP 和 STL 两种格式。

关键点在于错误信息要完整回传。比如 CadQuery 报 “ValueError: Null topology”，你要把整段 traceback 都喂给模型，它才能定位到是哪一步的 workplane 或布尔运算出了问题。只给一句“出错了”，模型基本修不对。

另外，执行环境一定要隔离。大模型生成的代码可能包含死循环、超大内存分配、文件系统操作。用 Docker 容器或者子进程加超时限制，避免把主环境搞崩。我一般设置单次执行超时 30 秒，内存上限 2GB，足够跑大多数零件脚本。

3.3 尺寸校验与可打印性检查

模型生成出来只是第一步，能不能用是另一回事。我习惯在导出后加两道自动检查：

第一道是包围盒校验。读取生成模型的 bounding box，和提示词里的尺寸对比。如果偏差超过 5%，就标记为可疑。比如你说长 100 毫米，结果模型长 103 毫米，可能是某处圆角或倒角把外形撑大了，需要人工确认。

第二道是壁厚检查。对于要 3D 打印的模型，最小壁厚不能低于喷嘴直径的 1.5 倍。0.4 毫米喷嘴对应最小 0.6 毫米壁厚，低于这个值打印出来会破。可以用 trimesh 库做射线检测，估算最薄处的厚度。

import trimesh mesh = trimesh.load("output.stl") # 检查包围盒 print("Bounding box:", mesh.bounds) # 检查是否水密 print("Is watertight:", mesh.is_watertight) # 检查体积 print("Volume:", mesh.volume)

如果is_watertight返回 False，说明网格有破洞或非流形边，切片软件可能报错。这时候要么回到代码生成阶段调整布尔运算顺序，要么用网格修复工具补洞。

注意：STEP 格式是实体模型，天然水密；STL 是网格模型，才需要检查水密性。如果你走代码生成路线，优先导出 STEP，省去很多麻烦。

4. 常见问题与排查技巧实录

4.1 模型生成失败或形状完全不对

这是最常见的问题，原因通常出在提示词歧义或模型能力边界。排查顺序建议如下：

• 先看提示词有没有矛盾。比如“一个空心方块，壁厚 10 毫米，外形尺寸 15x15x15”，那内腔只剩 5x5x5，如果还要求“内腔放一个直径 8 的球”，就物理上不可能。模型会强行生成一个错误结果，而不是报错。
• 再看坐标系描述是否清晰。“在顶面打孔”和“在上表面打孔”在代码生成时可能被理解成不同 workplane。统一用“+Z 方向面”“XY 平面”这类明确表述。
• 最后看模型是否超出训练分布。特别复杂的有机曲面、大量阵列特征、非标准螺纹，代码生成模型容易胡编。这时候要么拆成多个简单步骤，要么换网格生成路线。

我踩过的一个坑是：让模型生成“一个渐开线齿轮”，它直接编了一个近似圆弧的轮廓，齿形完全不对。后来改成“一个 20 齿、模数 2、压力角 20 度的直齿轮”，并指定用 CadQuery 的 gear 扩展库，才得到可用结果。专业特征要用专业术语，不要用日常比喻。

4.2 生成速度慢或频繁超时

text-to-cad 的耗时主要花在大模型推理和代码执行两步。如果走本地模型，推理时间可能从几秒到几十秒不等；走云端 API 则受网络和排队影响。

优化手段有几个：一是缓存常用模板，对于重复出现的标准结构，直接查缓存不重新生成；二是限制生成长度，代码生成不需要长篇大论，设置 max tokens 在 1024 以内通常够用；三是并行执行，如果批量生成多个零件，可以用多进程同时跑，但注意每个进程独立沙箱。

代码执行超时多半是布尔运算过于复杂。比如一个模型里做了几十次差集和并集，CadQuery 的 OpenCASCADE 内核会非常慢。解决办法是合并操作，能一次布尔运算完成的，不要拆成多次。另外，圆角操作尽量放在最后做，因为圆角会显著增加拓扑复杂度。

4.3 导出文件在切片软件里报错

STL 导入切片软件报错，九成是网格问题。常见错误包括：非流形边、法线不一致、自交面、零面积三角形。排查可以用 trimesh 或 MeshLab 先做一轮清理。

如果走的是代码生成路线，导出 STEP 再转 STL 通常能避免大部分网格问题。因为 STEP 是 B-Rep 实体，转网格时由内核保证拓扑正确。我现在的习惯是：工程用途一律 STEP，展示用途才用 STL。

4.4 参数化修改后模型崩溃

参数化是代码生成路线的核心优势，但改参数导致模型崩溃也很常见。比如你把孔直径从 5 改成 8，结果孔壁和外形面相交了，布尔运算直接失败。

预防办法是在脚本里加约束检查。比如：

hole_d = 8 wall = 3 outer_d = 20 assert hole_d + 2 * wall <= outer_d, "孔太大，壁厚不足"

这样在生成前就能发现参数不合理，而不是等到执行时报错。另外，关键尺寸尽量用变量表达，不要硬编码数字。这样改一个地方，所有相关特征自动联动。

实操心得：我习惯在 CadQuery 脚本开头集中定义所有参数，后面全部引用变量。这样不仅好改，而且方便做参数扫描，批量生成不同尺寸的系列零件。

5. 工具链选型与本地环境搭建建议

5.1 大模型选择：本地还是云端

如果你对数据隐私不敏感，云端 API 是最省事的选择，推理质量也通常更好。但如果你的设计涉及未公开产品，或者你想离线使用，本地模型是必须的。

本地跑 text-to-cad，对硬件有一定要求。7B 参数级别的代码生成模型，量化后大约需要 6-8GB 显存；13B 级别需要 12-16GB；再大就得上多卡或 CPU 推理，速度会明显下降。我实测下来，7B 量化模型在消费级显卡上就能跑出可用结果，虽然偶尔语法出错，但配合重试闭环基本够用。

选模型时重点看它在代码生成任务上的表现，而不是通用对话能力。有些模型聊天很流畅，但写 CadQuery 脚本一塌糊涂。可以先用几十条标准提示词做一轮评测，看首次执行成功率。

5.2 执行引擎与依赖管理

OpenSCAD 和 CadQuery 是两条最成熟的执行引擎。OpenSCAD 安装简单，命令行调用方便，适合快速验证。CadQuery 基于 Python，依赖 OpenCASCADE，安装稍麻烦，但输出格式更工程化。

我建议用 conda 或 venv 隔离环境，避免和系统 Python 冲突。CadQuery 的安装命令大致如下：

conda create -n cadquery python=3.10 conda activate cadquery conda install -c conda-forge -c cadquery cadquery=master

OpenSCAD 则直接下载对应平台的安装包，把可执行文件路径加入环境变量即可。命令行调用方式：

openscad -o output.stl input.scad

如果你要同时支持两种引擎，可以在调度层做路由：简单几何走 OpenSCAD，复杂工程件走 CadQuery。

5.3 版本管理与协作

text-to-cad 的产出物包括提示词、生成脚本、模型文件三部分。提示词和脚本是纯文本，用 Git 管理最合适。模型文件是二进制，不建议直接入库，可以用 Git LFS 或者只保留生成脚本，需要时重新生成。

我自己的仓库结构是这样的：

project/ prompts/ # 提示词模板 scripts/ # 生成的 CadQuery/OpenSCAD 脚本 outputs/ # 导出的 STEP/STL，gitignore checks/ # 校验脚本 README.md

这样每次修改提示词或脚本都有记录，出问题可以回滚。团队协作时，别人拉下代码就能复现同样的模型，不需要传大文件。

6. 影响范围与能力边界：哪些场景已经能用，哪些还早

6.1 已经比较成熟的场景

标准结构件快速生成是目前最稳的场景。法兰、支架、外壳、安装板、简单齿轮、皮带轮，这些形状规则、参数明确、模板丰富的零件，text-to-cad 已经能显著提效。我实测一个带孔安装板，从写提示词到导出 STEP，熟练后不到两分钟，比手动建模快五到十倍。

批量系列化设计也很适合。比如你需要 20 个外形相同但长度不同的支架，用参数化脚本改一个变量就能全部生成，不需要一个个画。这在做产品系列、实验夹具、教学套件时特别有用。

三维打印前的快速验证同样受益。很多打印玩家不需要精确工程图，只要形状对、尺寸大致对就行。text-to-cad 生成的网格模型直接切片打印，省去学建模软件的时间。

6.2 还需要人工深度介入的场景

复杂装配体目前基本做不了。多个零件之间的配合关系、运动约束、公差链，自然语言很难描述清楚，模型也缺乏全局装配推理能力。你可以生成单个零件，但装配还得手动做。

高精度配合面也不可靠。比如轴承孔、导轨槽、密封面，这些对尺寸公差和表面粗糙度有严格要求，text-to-cad 生成的模型只能算毛坯，必须人工精修。

有机曲面与自由造型虽然网格路线能生成，但质量不稳定，而且不可编辑。做概念图可以，做产品不行。

可制造性设计更是空白。模型不知道你的加工方式是 CNC、注塑还是打印，不会自动加脱模斜度、圆角、加强筋。这些仍然依赖工程师经验。

我的判断是：text-to-cad 在未来几年会成为一个高效的“第一稿工具”，但不会取代 CAD 工程师。它把重复劳动自动化，让人专注于真正需要判断力的部分——功能定义、装配逻辑、制造约束。

7. 我踩过的坑与最后分享的几个技巧

第一个坑是过度信任模型输出的尺寸。早期我直接拿生成模型去打印，结果装配时发现孔位偏了 0.5 毫米，整批零件报废。后来养成习惯，任何关键尺寸都用卡尺量一遍，或者用切片软件的测量工具核对。text-to-cad 给的是“名义尺寸”，实际几何可能有微小偏差。

第二个坑是提示词里用了模糊形容词。“大一点”“薄一些”“差不多”这类词，模型只能猜。现在我一律用具体数字，实在不确定就先给一个估计值，生成后再调参数。

第三个坑是忽略单位。有些模型默认单位是英寸，有些是毫米，混用会导致尺寸差 25.4 倍。我在提示词里永远写明“单位毫米”，脚本里也统一用毫米。

最后分享一个提效技巧：建立自己的提示词片段库。把常用的结构描述存成模板，比如“四角安装孔”“中心通孔”“边缘倒角”“阵列散热槽”，需要时拼装组合。这样写提示词从每次十分钟缩短到一两分钟，而且质量稳定。

还有一个技巧是用截图反推提示词。如果你看到一个想要的形状但不知道怎么描述，可以先让多模态模型看图生成文字描述，再把描述喂给 text-to-cad。虽然多一道转换，但比凭空想词容易得多。

这个方向变化很快，工具和模型几个月就更新一轮。我的建议是保持关注，但不要追新追到影响干活。先把一条路线跑通，形成自己的提示词库和校验流程，比什么都重要。