打开文本编辑器写提示词的那天晚上，我其实没抱太大希望。结果十几秒后，一个带安装孔和加强筋的底座模型就出现在渲染窗口里，轮廓比例合理，倒角也对了。那一刻我意识到，text-to-cad 已经不再是论文里的概念演示，而是实实在在能进到工作流里的效率工具。

这篇内容我打算从技术链路、工具选型、实操过程和踩坑实录四个角度展开，把我最近实际用下来的经验一次性讲透。如果你是做结构设计、机械零件、创客 DIY，或者单纯想用自然语言把脑子里那个“大概长这样的东西”变成可编辑的三维模型，这篇文章应该能帮你少走一个月的弯路。

1. 文本到CAD到底在解决什么问题——先理清技术链路

1.1 从自然语言到三维模型的完整链路

很多人第一次听到 text-to-cad，第一反应是“这不就是 AI 生成三维模型吗”。我在接触之前也是这么想的，但真正上手之后才发现，它和那些直接生成网格模型的 AI 工具走的路线完全不是一个路子。

一条完整的文本到CAD流程，实际上是四个环节的串联：文本理解、工程意图解析、几何推理、程序合成。

文本理解这部分跟普通的对话式 AI 没什么区别，核心就是把你的话拆成一个个设计要素。难点在于工程意图解析。举个例子，“给我一个 M8 螺栓能穿过去的通孔”，这句话看着简单，但 AI 需要知道 M8 螺栓的头部直径是 13 毫米、通孔直径通常是 8.4 毫米或者 9 毫米（取决于配合等级），还需要知道孔的位置、方向、是否沉头。这里面既有机械常识，又有经验值，纯靠语言模型硬猜是猜不出来的。

等到几何推理环节，系统会把语言描述转换成几何约束和实体操作序列：拉伸、旋转、布尔运算、倒角、阵列。最后通过程序合成生成一段可执行的建模脚本，这段脚本会被 CAD 内核执行，才得到最终的三维实体模型。

这也解释了一个关键问题：为什么 text-to-cad 生成的一定是带参数的可编辑模型，而不是一堆三角形面片构成的网格模型。因为整条链路走的是“程序化建模”路线，语言模型负责写代码，真正的几何运算交给 CAD 内核。这也是它跟那些文生图、文生网格工具最本质的区别。

1.2 为什么“程序合成”是关键而不是直接生成网格实体

我看过一些基于扩散模型直接生成三维网格的方案，坦白说，作为灵感参考是有价值的，但距离真正可用还有不小距离。主要原因有三个。

第一，网格模型不可编辑。你拿到一个 .obj 或者 .stl 文件，想改一个孔的直径，对不起，做不到，只能回炉重造。而 CAD 建模的核心诉求恰恰是修改和迭代，零件不是一次性艺术品，是要反复调整的。

第二，网格模型没有工程语义。实体模型里有孔、有面、有倒角，有尺寸约束和配合关系。网格模型只有三角形面片，没有哪一层是“面”、哪一坨是“孔”的概念。你没法在网格模型的拓扑结构上做布尔运算，也没法直接导出用于加工的刀具路径。

第三，网格模型经常是非流形或者破损的。做过 3D 打印的朋友肯定有经验，一个破损的网格模型导入切片软件，要么切片预览有明显破洞，要么打印到一半悬空结构全部塌掉。程序化生成的实体模型天然是封闭的、流形的，因为每一步都是基于准确几何内核的布尔运算，不存在封闭性问题和面片翻转问题。

所以我在实际使用中的结论非常明确：text-to-cad 这类工具能进入生产流程，靠的就是“程序合成”这四个字。它的本质不是让 AI 直接“画”模型，而是让 AI 去写构建模型的“施工图纸”，然后交给人去执行和修改。

2. 工具选型解析：不同技术路线的取舍

2.1 OpenSCAD、CadQuery 还是自由建模——建模语言决定成败

既然核心是程序合成，那么底层用什么建模语言，就决定了生成结果的可控性和可编辑性。目前市面上主流的文本到CAD工具，底层基本都是这两条路线：OpenSCAD 和 CadQuery（或者 FreeCAD 的 Python 接口）。

OpenSCAD 走的是 CSG 构造实体几何路线，代码风格偏函数式，你用 cube、cylinder、difference、union 这些基础体素去拼出复杂模型。它的优势是语言简洁，规则清晰，AI 非常容易生成正确的代码。因为整套语法就那几个核心操作，模型复杂一点也无非是嵌套多几层。我在实际体验中，OpenSCAD 路线的生成成功率确实更高，出错的概率明显低。

CadQuery 则是完全面向对象和参数化的 Python 库，它模拟的是你在真实 CAD 软件里的建模思路：先画草图、再拉伸、再打孔、再阵列。CadQuery 生成的代码可读性很强，一个特征对应一段代码，修改起来思路非常清晰。但它的 API 层级更深，语言模型偶尔会生成不存在的函数名或者参数组合，如果项目自身没有做好 API 文档的约束，生成结果的稳定性会差一些。

自由建模路线（比如让 AI 输出 STEP 或 BREP 数据）目前还不太成熟，理论上是未来的终极形态，但现阶段工程化落地还不够，我就不多推荐了。

2.2 主流文本到CAD方案横向对比

我实际用过几个方案，给它们做了个简单的对比，方便大家快速选型。

说实话，现阶段我没有只押一个方案。日常做快速验证的时候，我会用 OpenSCAD 路线，生成速度快、成功率高，几秒钟就能看到形态方向对不对。等到要进入细化设计、给零件加工程语义、做装配验证的时候，就切换到 CadQuery 路线，优点是可读性和结构化程度更好。

2.3 我自己的工具组合建议

如果你现在想开始用 text-to-cad，我建议先别急于选型，从最容易上手的 OpenSCAD 路线开始。理由很简单：语言足够简单，AI 不容易写错，你能快速建立起“文本到模型”的完整心智模型。

跑通一条链路之后，再尝试 CadQuery 路线，去生成那种带装配约束或者复杂孔位分布的零件。这个时候你已经有基础认知了，就能更清楚地感受到两种路线的差异，也更容易判断自己实际项目里更适合哪一种。

另外强烈建议给建模语言配一份精简版的“API 速查表”放在提示词上下文里。很多工具支持系统级提示词注入，你可以直接把 OpenSCAD 的常用函数清单、CadQuery 的常用方法签名丢给 AI，生成准确率会明显上一个大台阶。后面我在实操部分会给出具体示例。

3. 实操过程与核心环节实现

3.1 写提示词的技巧：把“人话”翻译成“建模语言”的能力

text-to-cad 能不能出好活，一半看模型能力，一半看你的提示词功底。我试过大量不同风格的说法，最后总结出一个核心原则：你的提示词越像一份设计需求文档，生成结果就越贴近预期。

先看一个反面典型：“做一个法兰盘”。这种说法信息量太低了，AI 不知道法兰盘外径多少、厚度多少、孔数几个、孔径多大、中心孔要不要凸台。结果就是它根据自己的“平均印象”给你生成一个通用法兰，大概率和你想要的对不上。

再看我一般怎么写的：

生成一个圆形法兰盘，外径 80mm，总厚度 12mm。中心有一个直径 20mm 的贯穿孔，中心孔周围均匀分布 6 个直径为 6.5mm 的螺栓安装孔，螺栓孔中心圆直径 60mm。法兰盘外圈倒角 1mm，所有边缘需要光滑过渡。材质按铝合金处理，只输出三维模型。

这种描述方式有三个好处：尺寸信息明确、位置关系清楚、加工语义附加在上面。AI 在解析时能顺畅地完成“文本要素 → 几何约束 → 建模操作”的映射，生成出来的代码质量自然高。

还有一个进阶技巧：把设计意图讲清楚，而不是只报参数。比如你写“这个支架底部要加一条加强筋，因为受力方向垂直于底面”，AI 就能推理出筋应该沿受力方向布置、厚度和高度要有一定的尺寸比例。这一段“意图描述”往往比单纯加参数更有价值。

3.2 从模型文案生成可编辑的CAD脚本

我拿 OpenSCAD 路线举个例子，展示一下从提示词到最终代码的全过程。假设需求是做一个带提手的圆形盖子，盖体直径 100mm，厚度 5mm，中心有一个拱形提手。

我先写提示词：

用 OpenSCAD 生成一个大直径 100mm 的圆形盖子，盖体厚度 5mm。盖体中心上方有一个半圆拱形提手，拱形内径 40mm，提手截面为矩形，宽 15mm、高 10mm。提手两端自然融入盖体表面，连接处做圆角过渡。整体对称，输出结构化清晰的 OpenSCAD 代码。

实际生成出来的核心代码大致长这样：

// 盖体 module cover_body() { cylinder(h = 5, d = 100, $fn = 120); } // 提手横向梁 module handle_bar() { translate([0, -7.5, 5]) cube([40, 15, 10]); } // 提手拱形部分 module handle_arch() { difference() { cylinder(h = 10, d = 50, $fn = 120); translate([0, 0, -1]) cylinder(h = 12, d = 40, $fn = 120); } } // 整体组合 module lid_cover() { union() { cover_body(); translate([-20, 0, 0]) handle_arch(); translate([20, 0, 0]) handle_arch(); handle_bar(); } } lid_cover();

生成结果不是一次到位的。实际跑第一版的时候，提手两端和盖体的连接处是直角过渡，视觉上比较生硬。我把反馈丢回去：“提手与盖体连接处增加 5mm 圆角过渡，确保连接自然平滑”，AI 重新生成了带圆角过渡的版本，通过引入 hull 操作把两个圆柱体做了外轮廓融合，最终效果就顺眼多了。

这类基于反馈的迭代过程，正是 text-to-cad 相比传统 CAD 建模最有趣的地方。传统建模里你每改一处都是手动操作，而这里你只需要描述问题，代码层面的修改由 AI 完成。

3.3 后处理与参数化调整的实操记录

拿到生成代码之后，我一般不会直接用。先检查几个关键点：尺寸数值是否符合预期、布尔运算是否产生多余的内部面、倒角和圆角是否应用在正确的位置。

检查通过之后，我会把关键尺寸提取成变量，做成参数化模型。还是以法兰盘为例，我会把外径、厚度、孔数、孔径都定义成顶部变量：

outer_diameter = 80; plate_thickness = 12; center_hole_diameter = 20; bolt_hole_diameter = 6.5; bolt_circle_diameter = 60; bolt_hole_count = 6;

这样后面改一个参数，整个模型自动更新。在批量生成系列化零件（比如不同规格的法兰、支架、盖板）时，这个参数化能力价值极大。AI 帮你生成一次逻辑，你就能用一个参数控制一个系列。

还有一个实操细节：筛选器设置。OpenSCAD 里我习惯把 $fn 设置为 120 以上，保证圆柱面和圆弧足够光滑，但要提醒的是，这种高精度扫描显示会增加预览计算量。我的做法是预览时用 $fn=60，导出 STL 时再切换到 $fn=200，兼顾流畅度和精度。

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

4.1 尺寸瞎编怎么办——几何约束的闭环

text-to-cad 最常见的翻车事故就是尺寸问题。AI 有概率把两个互相矛盾的尺寸一起写进代码，比如法兰外径 80mm、螺栓孔中心圆直径却写了 90mm，结果螺栓孔直接跑到法兰外面去了。

这类问题的本质是语言模型缺少“无效结果验证”能力。它写代码的时候，并没有把几何约束关系实时校验一遍。我在实践中用了一个比较可靠的兜底方案：要求生成代码里必须包含 assert 检查，或者要求关键尺寸之间的关系以等式形式体现。

示例提示词可以这样加一句：“如果螺栓孔中心圆直径大于外径减去 2 倍边距，请给出警告并自动调整。”这样即使 AI 一开始写错了，它也会在生成逻辑里加入约束检查，后续修正就只是参数跳动的问题。

另一个笨办法但很有效：生成之后用测量工具快速核对几个关键尺寸。我一般在 FreeCAD 里加载 STEP 文件直接量一遍，20 秒就能排查掉大半问题。尺寸可信度在 text-to-cad 里永远不会是 100%，人工抽查是必要的质控环节。

4.2 生成结果无法编辑怎么处理

还有一种高频问题：AI 给出了一个很唬人的模型图片，但你发现代码里所有操作都是硬编码的，改一个尺寸等于重写整个文件。这种模型“能看不能用”，比生成失败更让人头痛。

我的应对思路是：在提示词里强制要求“模块化拆分”。把每个特征独立成模块，模块内部用参数、模块之间通过坐标变换组合。

module base_plate(w, h, t) { translate([0, 0, 0]) cube([w, h, t]); } module mounting_holes(x, y, dia) { translate([x, y, -1]) cylinder(h = 4, d = dia, $fn = 32); }

如果你拿到的代码已经是硬编码的，也有补救办法。先把代码丢给 AI，附加指令“识别这段代码里所有硬编码尺寸，提取为顶部参数变量，并保持模型形状不变”，连改造带回归测试一次完成。我试过把一段 30 行的硬编码代码改造成 60 行的参数化版本，模型形状完全没变，后续改尺寸就很舒服了。

4.3 迭代失败的几个典型场景和排查思路

迭代式生成过程中，一个常见痛点是“上一轮改好了，这一轮又改回去了”。AI 在生成新版本代码时，有时会丢弃之前的修正内容。这个问题在长对话里尤其明显，上下文太长，模型注意力分散。

排查思路很简单：每一轮迭代之后，把当前代码固定下来作为基准，下一轮提示词里带上“基于以下代码修改，不要重写整个文件”。如果 AI 仍然重写，就改用 diff 工作流：让 AI 只输出修改部分的代码块，而不是完整模型代码。这样你就能以补丁方式手工应用修改，最大限度地避免回归。

另外一个典型场景是布尔运算产生了非预期的实体碎片。举个例子，在一个圆柱体上切 6 个孔，个别情况下会留下薄壁残片或者内部孤立实体。这种问题通常是编程上的逻辑错误，比如差集对象并没有完全贯通主体，差集深度小于主体厚度。排查方向是检查截切体的尺寸是否足够穿越主体，必要时把差集体的高度额外增加 0.1mm 做重叠处理。

5. 应用场景与影响范围

5.1 设计早期探索：从概念到草模的效率革命

text-to-cad 目前对我价值最大的使用场景，并不是最终出图，而是设计早期的概念探索阶段。

以前做结构设计，脑海里有个初步想法，要把想法变成可评估的三维形态，至少要在 CAD 里经过建模操作，就算熟练工也得花一两个小时。而且一旦形态方向不对，这一两个小时就白费了。

现在我的做法是：用文字描述初始概念，几分钟内生成三五个不同形态的候选方案，快速在视觉层面和结构层面做初筛，选出一个方向后，再基于参数化结构进入精细设计。相当于把“三维头脑风暴”的成本压缩到了原来的十分之一。

这种方式的改变不仅仅是快，更重要的是思维模式的改变。以前因为建模成本高，你会有意无意地收敛思路，不敢多做几个变体。现在是零成本生成，你更愿意放开脑洞去尝试不同方向，这在设计过程中是极其可贵的。

5.2 非专业用户参与定制化设计

我在社区里看到不少非专业用户的案例，他们可能完全没学过三维建模软件，但通过文本对话的方式做出了像样的定制化零件：给空气净化器做一个适配旧款滤芯的转接环、给手柄加一个符合手型的舒适握把、给桌面支架打一组心形排布的孔位。

这些人并不是工程师，他们的优势在于很准确地知道“我要什么”，缺的只是“怎么把它画出来”的能力。text-to-cad 恰好把后者代劳了。自然语言是人类最基本的表达方式，让 AI 做“翻译”，非专业用户也能参与到过去需要多年软件经验才能完成的设计活动中来。

不过也要泼一盆冷水：非专业用户在使用时更容易踩“尺寸瞎编”的坑。他们通常没有预判尺寸合理性经验，生成什么就信什么，最后打印出来装不上、对不齐的情况屡见不鲜。所以我一直建议非专业用户至少要学一个基础技能：会测量、会看尺寸。知道自己物品的关键尺寸，并在提示词里明确写出来，很多问题就能从源头避免。

5.3 对工程师工作流的影响边界

说到工程师群体，我有几句比较实在的观察。text-to-cad 不会取代工程师的设计能力，但它确实在挤压常规、重复、低创造性建模工作的空间。

批量零件库建立、系列化规格派生、标准件变体生成，这些工作以前需要工程师手动花时间做参数化建模。现在只要语义描述准确，AI 能在几分钟内生成规格系列模型。工程师的工作重心，正在从“操作建模软件”转向“定义需求和验证结果”。

但设计始终有它的硬边界：需要物理试验、强度仿真、加工工艺验证的地方，AI 替代不了。任何一套文本生成的模型，最终都必须经过工程校核才能投产。理解这个边界，你才能真正把 tool 用成工具，而不是神化成万能方案。

写在最后的一点个人体会

用了一段 text-to-cad 之后，我的一个直观感受是，真正拉开差距的不是会写提示词，而是你脑子里有没有清晰的几何和工程概念。AI 再怎么强，它也只能作为你的“执行放大器”，负责把模糊的想法快速变成具体模型，但想法本身的质量、判断模型是否合理的眼光，仍然是人力核心价值所在。

另外一个我一直在用的习惯是：生成结果之后，永远要亲自检查一遍关键尺寸和装配关系。AI 能帮你把 80% 的重复劳动消化掉，剩下 20% 的工程判断需要你自己兜住。这种“人机各司其职”的配合方式，应该就是接下来的主流形态。如果你正准备尝试 text-to-cad，我建议直接从一个小零件开始，给它配好参数、写好需求描述、跑通一次完整流程，那种感觉会瞬间打开你对设计工具想象力的边界。