文本生成CAD实战：原理、工作流与避坑指南

如果你在CAD行业待过三年以上，大概率经历过这种场景：一个小到不能再小的零件，打开软件、新建草图、拉拉伸、加约束、倒角、另存，一套流程下来十分钟就没了。碰上一个稍复杂的非标件，光调整视图和捕捉就耗掉大半天，回头一看，真正花在"思考结构"上的时间可能只占两成。这也是为什么这两年的text-to-cad话题会突然热起来——大家都意识到，与其把时间花在重复的"画线拉体"动作上，不如把意图直接告诉软件，让它先把草稿铺出来，再由人做决策。

text-to-cad，说白了就是"用自然语言描述需求，让AI自动生成CAD模型或图纸"。它能做的事，不是替代工程师的建模能力，而是把"从零建模"的动作压缩成"输入描述—审核结果—修正细节"这三个步骤，适合机械设计、3D打印、标准件选型、概念方案评审这些场景。无论你是刚装好AutoCAD还在摸索入门命令的新手，还是已经在用中望CAD、国产插件做项目的老师傅，这套思路都能帮你把原来两小时的建模时间压到二十分钟以内。

下面我把这个方向的实现原理、实操链路、以及我在真实项目里踩过的坑完整梳理一遍，内容偏实战，尽量少讲玄学。

1. text-to-cad到底在解决谁的什么问题——从"画图"到"说图"的转变

1.1 传统CAD工作流的真正瓶颈不是画图，而是"把语言翻译成几何"

先说一个容易被忽视的事实：大多数工程师熟练操作CAD之后，"画"本身并不慢，慢的是"想好怎么画"和"改来改去"。

举个例子。你接到一个需求，外协件是这样的："一块150×100的钢板，四角开直径12的通孔，孔中心距边15，中间再开一个腰型槽，槽宽10，总长60，圆弧过渡。"如果手头有现成的模板，改改参数一分钟搞定。但如果没有呢？你要新建草图、选基准面、定约束关系、检查过定义还是欠定义……真正耗时的不是那几笔直线圆弧，而是整个"从文字到几何的翻译过程"。

text-to-cad想解决的就是这个翻译环节。它把自然语言、设计意图、乃至草图输入，直接映射成参数化建模指令，让CAD软件按描述把模型铺出来。这不是"自动画一幅静态图"，而是"生成一个可继续编辑、可修改参数的活模型"，这也是它和传统图库、图块、预制模板的本质区别。

1.2 它能服务哪几类人：新手、标准件场景、方案评审

从我观察到的用户群体来看，text-to-cad目前最有价值的几类人刚好对应了热搜里那些高频词背后的真实需求：

• CAD新手：网上搜"cad制图初学入门"、"cad安装教程"的人，最缺的不是命令大全，而是"我说一个东西长什么样，软件怎么把它建出来"的桥梁。text-to-cad能把新手脑子里的想象变成可视模型，减少试错成本。
• 做标准件和常规零件的工程师：像盘扣、支架、底板这类结构规律性强、尺寸可参数化的零件，正好是文本生成最擅长的领域。输入参数化描述，自动生成带约束的模型，再手工微调尺寸标注。
• 概念方案评审：方案阶段不需要细节工程图，只需要一个能表达结构关系的三维模型。过去要花两小时建一个"像样"的模型，现在用文本生成十分钟就能有个大概，剩下时间全花在讨论结构合理性上，效率完全不同。

1.3 一个关键的认知修正：它不是"替代CAD"，而是"替代从零建模"

注意我说的是"从零建模"，不是"CAD"本身。

很多人在第一次看到text-to-cad生成一个像模像样的零件后，容易产生一个错误期待：是不是以后不用学CAD了？直接打字就行？我的实际体验恰恰相反。AI生成的模型在几何正确性、装配关系、制造可行性上，都还远达不到直接投产的标准。它更像一个"手速极快的绘图员"，帮你把80%的重复劳动做掉，剩下的20%——确定公差、检验干涉、完善标注——才是CAD工程师真正的核心价值。

2. 主流的text-to-cad实现路线：大模型生成脚本、AI原生建模与检索复用

2.1 路线一：大模型直接输出CAD脚本（OpenSCAD、FreeCAD宏、CadQuery）

这是目前门槛最低、参数化程度最高的做法。原理很好理解：CAD软件本身支持脚本化建模，比如OpenSCAD用类C语言描述几何体，FreeCAD有Python宏，CadQuery更是直接拿Python写特征。那么问题就从"让AI建模"变成了"让AI写建模代码"——后者恰好是大语言模型最擅长的事情。

我用的最多的是这条路线。你给大模型一个描述，比如：

生成一个L型支架，竖板高80，厚6，宽50，底板长60，宽50，厚10，底板开两个直径8的通孔，孔距底板两端边缘15，竖板顶部开一个M8的螺纹孔。

大模型会返回一段OpenSCAD代码，由几个cube()、cylinder()、difference()组合而成。你复制进OpenSCAD，立刻就能看到模型。修改尺寸？直接改参数变量，重新渲染就是新模型。这种方案的优点在于：

• 改参数极其方便，本质是一份"可执行的工程说明书"；
• 生成速度快，一次对话通常几十秒；
• 零额外部署成本，本地装个免费软件就行。

2.2 路线二：专门训练的三维生成模型（文本/草图→B-rep与网格）

另一条路线是直接做"文本→三维几何"的端到端生成，类似图像生成领域里的扩散模型，不过目标从像素换成了体素、点云、网格或者B-rep（即边界表示法）。这类模型通常需要用海量的三维模型库和对应的文本标注做训练，比如让模型学会"带通孔的法兰盘"与某个几何特征之间的对应关系。

这条路线的上限更高，因为它不依赖脚本语法，理论上能生成任意复杂自由曲面。但目前的问题也很现实：输出的几何精度不高，单位、公差、特征约束都难以精确控制；模型哪怕表面上看着像那么回事，导入SolidWorks或AutoCAD之后，特征树是散的，没法参数化修改。对制造业来说，这几乎是致命的。所以现阶段它更适合"找灵感"和"快速看造型"，而不是"出工程图"。

2.3 路线三：检索式/参数化模板方案

还有一条相对务实的技术路线：先做模板库，再让AI理解文本意图，从库里检索最接近的参数化模型，把文本里的关键尺寸映射到模型参数上。比如用户说"直径50的法兰盘，四个安装孔，孔中心圆直径70"，系统先识别出"法兰盘"，检索到对应的参数化模板，再把50、70这些数值填进模板参数。

这条路线在工业界落地反而更稳，因为大部分企业常用零件就那几百种，模板覆盖率高、参数路径清晰、结果可预测。很多商业软件和插件走的其实是这个思路——看起来也像"text-to-cad"，但本质是"参数模板+自然语言映射"。

2.4 三条路线怎么选：我的判断标准

我个人的组合是：日常概念设计用"大模型生成脚本"，碰到企业标准件时优先查自建模板库，端到端生成只用来做方案草图预览。这三个路线不冲突，反而互补。

3. 从一句话到可编辑模型：我用OpenSCAD跑通完整链路的实操记录

3.1 环境准备与工具选择

先明确一点：text-to-cad目前没有"官方统一标准"这回事，不同的工具链组合千差万别。我自己最顺手的一套组合是：聊天式大模型 + OpenSCAD + FreeCAD，必要时再加一个DWG转换环节。

为什么选OpenSCAD而不是直接上AutoCAD？理由很朴实：

• OpenSCAD免费、轻量、脚本化程度极高，和文本生成天然配合；
• 它的代码结构和CAD中的参数化建模逻辑（实体、并集、差集、交集）高度对应，大模型容易理解；
• 跑通的模型可以导出STL给3D打印，也可以导出DXF、SVG给二维轮廓。

FreeCAD则用来做进一步的特征编辑，比如导入DXF后加标注、建装配关系。如果你是SolidWorks或中望CAD重度用户，思路也一样：让大模型生成脚本轮廓→导出中性格式→在你熟悉的CAD里继续加工。

3.2 把自然语言变成可执行的建模指令：输入工程约束

很多人第一次用text-to-cad生成模型不理想，十有八九是"人话"没翻译成"工程话"。我实践下来，有效的提示词必须包含四类信息：

1. 几何结构与特征：是支架还是法兰？有没有槽、孔、圆角？数量、位置？
2. 尺寸数据：长宽高、孔径、中心距、壁厚——单位一定要写明确；
3. 约束关系：孔距边缘多少、圆心是否共线、表面是否平行；
4. 输出格式：要脚本代码，还是直接要STL，还是只需要二维轮廓。

举个例子，我输入过这样一段描述：

用OpenSCAD生成一个电机安装座，外形为100×80×8的矩形板，四角倒R5圆角，板上开四个直径6.5的通孔，呈矩形阵列分布，横向间距70，纵向间距50，孔中心距离边缘15。板中心再开一个直径30的通孔，用于电机轴穿过。厚度8，所有通孔为贯穿孔。使用毫米为单位。

这段描述里"尺寸数据"和"约束关系"占了主要篇幅，把"四角倒圆角""孔呈阵列分布""贯穿孔"这些工程语义都说清楚了，大模型就很容易生成可用的代码。

3.3 一个完整案例：螺栓连接支架的文本生成与校验

下面这段是我实际用过的OpenSCAD代码，大模型生成后我只做了很小的修改：

// 电机安装座 module mount_plate() { difference() { // 外形：100x80x8 矩形板，倒R5圆角 linear_extrude(height = 8) { offset(r = 5) square([90, 70], center = true); } // 四个安装通孔，直径6.5 for (dx = [-35, 35], dy = [-25, 25]) { translate([dx, dy, 0]) cylinder(h = 10, d = 6.5, $fn = 32, center = true); } // 中间电机轴孔，直径30 translate([0, 0, 0]) cylinder(h = 10, d = 30, $fn = 64, center = true); // 中心轴孔的反向沉孔，开口直径35，深3 translate([0, 0, -3]) cylinder(h = 3, d = 35, $fn = 64); } } mount_plate();

这段代码的思路很直白：先做一个带圆角的矩形外形，再用差集挖掉六个圆柱孔。第一步生成后，我在OpenSCAD里旋转观察，发现沉孔方向反了，于是把translate([0, 0, -3])改成translate([0, 0, 8 - 3])，把沉孔放到板的上表面。这种小修小补是正常流程，别指望一次成型。

校验模型我一般分三步：

• 结构校验：旋转视角看孔位是否在预期位置、特征是否完整；
• 尺寸校验：用OpenSCAD的echo命令输出关键变量的实际值，或者直接用尺子量导出的DXF；
• 布尔运算校验：确认差集区域没有意外穿透，倒角有没有把安装孔边缘吃掉。

3.4 输出DXF与导入AutoCAD的衔接问题

模型建完只是第一步，真正出工程图、出加工文件，还要回到传统CAD生态。这里就有个实际衔接问题，也是热搜里"cad转pdf"、"cad图纸合并"、"cad导入layout"这些高频词背后的痛点。

OpenSCAD导出二维轮廓默认是DXF格式，但它的图层命名、线型、尺寸标注都是"极简风"——导入AutoCAD后你要重新归图层、加标注、补图纸框架。我自己的处理流程是：在OpenSCAD里用projection()投影得到关键视图轮廓，导出DXF，再用FreeCAD或AutoCAD的导入功能打开，重画中心线、补尺寸、设置打印样式，最后转PDF发出去。

这里有个体会：text-to-cad生成的模型再快，工程图环节目前还是绕不开CAD软件本身。别指望AI连图框、标题栏、公差都帮你搞定，那不是文本生成能解决的事。

提示：从OpenSCAD导出DXF时，单位一定要选对。OpenSCAD内部以毫米为逻辑单位，导出DXF时如果不额外设置，部分导入程序会按英寸理解，一个25.4倍的比例错误会让整张图纸报废。我在这个坑上栽过一次，后面专门写了个校验脚本，每次导出后先量一次外包矩形尺寸，再进CAD。

4. 核心原理拆解：为什么LLM写建模代码这件事成立，又卡在哪里

4.1 参数化建模的本质：CAD模型的"源代码"

要理解text-to-cad为什么用"生成脚本"这条路线最靠谱，得先理解参数化建模的本质。

你打开SolidWorks建一个法兰盘：画草图、标尺寸、加拉伸特征、阵列孔、倒角。在软件界面里，这是一串鼠标操作；但在底层，它对应了一棵特征树，每个特征里存了一堆参数和约束。这棵特征树，本质上就是模型的"源代码"。OpenSCAD和CadQuery把这层源码直接暴露给了用户，写代码的过程和你在界面里拉特征的过程，逻辑几乎一样。

大语言模型最擅长的事，正好是"根据人类语言描述生成结构化代码"。所以当建模过程变成代码之后，文本生成CAD的难度就从"生成三维几何"，降级成了"生成一段结构化程序"——这是个已经被验证过的任务。这也是我坚定推荐脚本路线的首要原因。

4.2 文本到CAD的难点：单位、语义歧义、几何约束

虽说脚本路线可行，但"可行"不等于"没有坑"。文本到CAD真正难在三个地方：

单位与量纲。中文描述里说"一块厚8个的板"，到底是8毫米、8厘米还是8英寸？大模型默认按毫米处理，但如果用户说的是"板厚1寸"而AI理解成了25毫米，尺寸就错了。这个问题在跨文档、跨地域协作时特别容易出现。

语义歧义。"在板中间开个槽"这句话，槽的方向是沿长边还是短边？槽的终点是通到底还是留一段？这些在人类工程师之间可以通过图纸语言轻松消除歧义，但自然语言天生模糊。AI只能猜，猜错了就只能返工。

几何约束缺失。CAD模型不是简单的一堆实体叠加，它隐含着"此面与彼面平行""两孔中心共线""边线与轴线垂直"这类约束。纯文本描述往往漏掉这些信息，生成出来的模型几何上是"一个东西"，但特征树里没有约束关系，后续编辑反而比从头建模更痛苦。

4.3 大模型的"幻觉"在几何场景下会放大

语言模型有一个通病：在不确定的时候会强行生成看似合理的答案。在文本创作里，这顶多是一段有文采但不着边际的话；但在几何建模里，一个不存在的孔、一个错位的倒角，就是实打实的产品缺陷。

举个例子，我问过一个大模型："生成一个边长50的正方体，其中一个面开直径10的盲孔，深度5。"它返回的代码里用了linear_extrude(50)建了一个长方体，然后盲孔部分用的是cylinder(h=55)——这个圆柱比板还高，等于直接开了一个通孔。代码语法完全正确，OpenSCAD也能正常渲染，但结果和需求差了十万八千里。

所以你一定要明白：AI生成的建模代码，语法上再漂亮，也只代表"它知道如何写这段代码"，不代表"它知道你要什么"。后面每一步的审核责任，都在人身上。

5. 实测中踩过的五个坑，以及对应的规避办法

5.1 坑一：单位混用，25.4倍比例灾难

前面提过OpenSCAD导出DXF的单位问题，其实在更早的环节就存在了。有一次我让AI生成一个100mm长的导轨滑块轮廓，生成的代码里写的却是cube([100, 40, 12]);，一切正常。结果另一个需求里，我顺手写了"1英寸长的夹块"，AI很"贴心"地按25.4毫米转了，但代码里的注释写的是"1 inch = 25.4mm"，我后续手工调整尺寸时没注意，把它当成了25毫米，最终零件装不上。

规避办法：所有提示词里强制要求"所有尺寸均以毫米为单位，不得混用其他单位"，并在生成代码顶部用变量集中管理关键尺寸，plate_length = 100;而不是直接写数字。这样万一单位错了，改一个变量就行。

5.2 坑二：未闭合轮廓导致拉伸失败

文本生成CAD时最典型的几何错误之一，就是轮廓未闭合。大模型生成的DXF轮廓或OpenSCAD多边形，有时因为坐标计算微小的数值误差，最后一个点没有回到起点，或者相邻线段端点差了0.001毫米。2D环境下肉眼根本看不出，但一拉伸、一导入数控CAM就报错。

规避办法：生成后先用脚本检查轮廓的多边形顶点是否首尾重合；在OpenSCAD里尽量用offset()、polygon()配合列表推导，减少手工输入坐标点；真的要手写坐标时，要求AI使用"闭合路径"句式，并计算最后一段回程向量。

5.3 坑三：中文提示词的几何理解偏差

中文自然语言在描述几何关系时比英文更模糊。比如"在板子左边开孔"，这个"左边"是从看图者的视角，还是从零件自身的坐标系？大模型在训练数据里接触的中文工程语料远少于英文，对这种方位词的理解往往跟着感觉走。

我后来养成了一个习惯：不在提示词里用"左边、右边、上面、下面"，全部改成绝对坐标系表达——"在X=35，Y=0的位置开孔""沿X轴正方向偏移35"。虽然写起来麻烦一点，但生成的代码几乎不用猜。

5.4 坑四：生成的模型"能看不能改"

这个坑最隐蔽。AI生成模型时，有时候为了省事，会把一个应该由两个特征组成的结构合并成一个整体，比如把底板上四个安装凸台和底板本体合并成一个union()实体。渲染出来一模一样，但导入CAD软件后，特征树里只有一个"凸缘体"，你想单独改某个凸台的高度根本没门。

规避办法：在提示词里明确要求"每个孔、每个凸台、每处倒角必须拆分为独立特征模块，使用模块化函数封装"，同时在代码里把关键尺寸抽成变量。这样就算AI生成的代码和预期不完全一样，至少你还能在代码层面改得动。

5.5 坑五：图层、线型、标注的"水土不服"

如果你以为文本生成完模型，剩下的CAD工序就能"躺平"，那就错了。我导出的DXF文件进AutoCAD后，经常遇到图层全是0层、线型全部是Continuous、尺寸标注一个都没有的情况。这不算"bug"，是这个工具链的天然短板：AI生成的是几何体，不是工程图。

规避办法是做好工作流切割：文本生成负责"出几何"；工程图交给CAD软件完成"加图层、标注、图框、打印样式"。看清边界，才不会一整天耗在让AI凭空生成一张完美图纸上。

6. 把text-to-cad接进现有生产流程：半自动工作流模板与收益评估

6.1 适合接入的环节：概念设计、标准件库、BOM前置

在我自己的项目里，text-to-cad真正发挥价值的环节不是"最后出图"，而是最前端那几步。

• 概念设计评审：快速生成三五个结构方案，团队过一遍比空谈效率高得多。这个阶段不需要精确公差，模型"看着像、结构逻辑对"就行。
• 标准件库扩充：很多企业的盘扣件、连接块、支撑座都是重复性结构。我建议把这些零件的参数化描述和AI提示词沉淀成模板，下次生成直接把参数填进固定句式，出来的模型一致性极高。
• BOM前置统计：AI生成的代码里如果规范命名，可以直接用脚本批量提取关键尺寸、材质信息，生成初步BOM草表，减少手工录入。

6.2 不适合接入的环节：精密配合、复杂曲面、协同审图

同时我也要泼盆冷水。下面这些场景现阶段强行上text-to-cad，大概率是负收益：

• 精密配合面：轴孔配合间隙、公差带、表面粗糙度，不是自然语言能说清的，AI生成的结果也精确不到那个量级；
• 复杂曲面造型：自由曲面、汽车A级曲面、流体仿真用的几何，靠文本生成是天方夜谭，老老实实用手工建模工具；
• 多方协同审图：涉及多个工程师、多部门签审的正式图纸，AI生成模型的版本管理、审批流程都跟不上，乱接反而添乱。

6.3 我建议的半自动工作流模板

最后分享一套我目前的实际工作流，你完全可以照搬：

需求确认（口头/文字） → 编写结构化提示词（含尺寸+约束+格式） → 大模型生成脚本 → OpenSCAD/CadQuery本地渲染 → 自动校验（尺寸边界、轮廓闭合、特征完备） → 人工视角审查（旋转模型、检查孔位倒角） → 导出DXF/STL → 导入FreeCAD/SolidWorks/中望CAD → 补图层、标注、图框 → 转PDF/打印 → 归档

整个链路里，真正"人在做"的部分是：提示词编写和模型审查。这两步省不得。省的代价就是返工，返工时间往往比一开始手工建模还要长。

提示：如果你团队里有人负责CAD插件维护，完全可以把这个工作流封装成一个小工具——输入自然语言描述，前端调大模型API，后端接OpenSCAD渲染，最后输出参数化脚本。技术上不难，但能把全组最重复的建模需求吃掉一大半。

我个人在实际操作中的体会是：text-to-cad目前最舒服的用法不是"把AI当建模员"，而是"把AI当参数化建模的加速器"。它的价值评估标准很简单——如果一段文本描述能减少你一个小时的重复劳动，那就是值得用的；如果为了生成一个精密配合件还要来回调试十几轮提示词，那还是直接打开CAD画更划算。

另外给一个小技巧：无论用哪个工具，先把提示词模板沉淀成自己的"零件描述库"。同一个支架、法兰、底板，改改数字就能复用。我整理了几十条常用句式之后，现在的生成成功率从最初的六成提升到九成以上，省下来的时间全花在真正需要动脑的设计决策上。

这个方向后续还会继续向"手绘草图生成CAD""照片反构参数模型"演进，但底层逻辑不变——让机器处理重复几何，让人专注工程判断。你现在拿这套东西去接几个日常零件试试，比看再多的趋势分析都有用。