去年年底，我接了一个挺尴尬的活儿：要给一个设备外壳设计一个安装支架，客户要求两周内出三维模型和加工图。我本身不是专职CAD工程师，主职是机电系统集成，SolidWorks的水平停留在“能拉伸、能切孔、能导出STL”的程度，碰到不规则曲面就手忙脚乱。就在那段时间，我注意到“text-to-cad”这个概念开始频繁出现在圈子里——用自然语言直接让AI生成CAD模型。说实话，我一开始是抱着看热闹的心态去试的，但试完之后发现这个方向和我预想的完全不一样。它真正改变的，不是“会不会画画”，而是“能不能把自己的想法快速变成可编辑、可制造的三维模型”。这篇文章就把我这段时间的实测过程、踩过的坑、以及我对这套工具链的理解整理出来，不吹不黑，给你一份可以照着操作的经验参考。
1. 从一句自然语言到一颗螺栓孔：text-to-CAD真正解决的问题
1.1 我对“让AI画三维模型”的天然怀疑
在真正上手之前，我对这类工具是持怀疑态度的。过去十年我们见过不少“文本生成3D”的demo，最典型的就是输入“一只戴着帽子的柴犬”，然后网络模型哗啦啦给你生成一个三角网格文件STL。这东西当头像、当游戏道具、当手办原型确实有意思，但你把它拖进SolidWorks或者FreeCAD，会发现它是个“死疙瘩”——没有特征树、没有草图、没有可编辑的尺寸，你想改一个孔的直径都得用删面重建这种野路子来操作。
做产品设计的人都知道，CAD文件的真正价值，不是那个“看起来像”的曲面，而是背后的参数化逻辑：哪个面依附于哪个草图、圆角是倒在哪条边上、螺栓孔的阵列由几个变量控制。没有这些，模型就是一次性的雕塑，不是工程资产。
我当时的心里话是：如果text-to-CAD只是把“文本生成立体网格”包装成新概念，那它就是个换汤不换药的玩具。如果它真能生成带特征树的实体模型，那这工具就值得好好研究。
1.2 text-to-3D是“捏泥巴”，text-to-CAD是“造砖头”
这两者的技术路线差异，决定了它们能走多远。text-to-3D主流做法是用扩散模型（类似图像生成的那个思路）直接在三维空间里预测体素、点云或者SDF隐式场，最后提取成三角网格。它能塑造出复杂的有机形态，比如动物、人物、场景道具，但这种网格天生就是“表示形状”的材料，没有拓扑关系，也没有“这根柱子是阵列出来的”这种语义信息。
真正的text-to-CAD走的是另一条路。以我用的Zoo系工具和Text2CAD开源项目为例，它们的核心机制是：让大语言模型理解自然语言，再让LLM生成一段可执行的CAD脚本，通常是CadQuery、OpenSCAD或者Python代码，然后本地执行脚本，编译生成真正的实体模型，导出为STEP、STL、DXF等工业格式。
这里的关键词是“脚本即特征”。你看到屏幕上那个法兰盘、那个底座，底下全是一行行可读的建模语言。你改一个变量，模型跟着变；你删一行倒角代码，特征就消失。这本质上就是在创造B-rep实体，只是生成方式从“鼠标点按拖拽”变成了“语言描述加脚本编译”。
我用一个粗糙的类比来解释：text-to-3D像捏泥巴，捏完是一个整体，想改五官就只能重新捏；text-to-CAD像造砖头，每一块砖都能挪动、替换、量尺寸。前者适合创意表达，后者才适合工程落地。
1.3 自然语言建模的边界：它不是万能草图师
明确了底层逻辑之后，我对text-to-CAD的边界也有了判断。它擅长的是“规则明确、几何清晰、参数可描述”的零件，比如法兰、支架、外壳、卡扣座、散热孔阵列这些标准机械件。这类零件本身是程序化设计的产物，用文字描述绰绰有余。
但你要是想让它生成一辆车的流线型引擎盖、一套符合人机工学的鼠标外壳，或者一堆自由曲面拼接的消费电子外观，它目前会变得相当挣扎。因为这类设计依赖大量交互式草图扫描、曲面拟合、G2连续判断，这些不是靠一句“圆润一点”能传递的信息。
这个认知特别重要。你只有先搞清楚它行与不行的分界线，才不会拿它去干注定失败的事情，也才知道怎么给AI“下需求”。下面我详细说说我实测过的几条落地路线。
2. 我实测过的几条落地路线：写脚本的黑盒、白盒和灰盒
2.1 路线A：类Zoo架构——让LLM直接写CadQuery脚本
这一条路线是目前最成熟、最接近“工程可用”的方向。Zoo是最典型的代表，Text2CAD开源项目也基本沿用同一套架构。
它的工作流程是这样的：你在输入框里打一句：“创建一个法兰底座，外径80毫米，内孔25毫米，四个直径6.6毫米的螺栓孔分布在直径60毫米的均布圆上，法兰厚度15毫米。”后台的LLM会把这句自然语言拆解成一系列建模指令，然后生成一段CadQuery脚本。这段脚本会用变量定义各个尺寸、用语义清楚的操作依次构建基础特征、拉伸、挖孔、阵列。紧接着一个本地执行器会编译这段脚本，并在浏览器里展示粗略预览，同时把模型导出成STEP、STL甚至DWG等格式。
我实测下来的体感是：对于刚才描述这类标准特征，它生成的成功率相当高。生成的模型不是糊成一片的网格，而是完完整整的实体，你在FreeCAD里打开，能看到完整的特征树——BasePad、HoleArray、Chamfer这些节点清清楚楚。想改孔距？改脚本参数即可。想导出给机床？切STEP，导入CAM系统，没有障碍。
2.2 路线B：纯黑盒生成模型——大厂的原生AI CAD方向
跟路线A对着干的是Autodesk的Project Bernini这类大厂研究项目。它们的思路不是让LLM去写代码，而是直接在B-rep实体空间的表征层做生成。也就是说，AI直接预测实体模型的边界表示、面片拓扑和几何约束，输出的是一个原生CAD实体，而不是脚本。
这个方向的优点是不需要经过“代码中间层”，理论上可以生成更复杂、更有机的几何形态，生成速度也可能更快。缺点也明显：可控性和可编辑性差，生成结果像一张渲染好的图片，你想“改一处参数”就没那么容易。它目前更多停留在实验室和封闭测试阶段，普通用户摸不到，即使摸到了也很难把它接进需要反复迭代的工作流里。
所以我在现在的实际项目中，基本不指望路线B，我的重心还是放在“脚本化CAD”这个可解释、可改、可版本控制的框架上。
2.3 路线C：通用LLM写FreeCAD/OpenSCAD脚本——最接地气的灰盒路线
还有一个对普通工程师非常友好的思路：用通用的大语言模型（ChatGPT类产品或者本地部署的开源模型）去生成FreeCAD的Python脚本，或者OpenSCAD代码，然后自己在本地软件里执行。
这个路线的门槛极低。你不需要注册什么复杂平台，直接打开大语言模型对话窗口，描述零件需求，让它输出一段FreeCAD Python代码。你把代码复制到FreeCAD的Python控制台跑一下，模型就出现在场景里；你也能通过修改代码变量来调整几何。
我用这个方式生成过一些测试用的标准零件，比如带U型槽的滑块、带沉孔的基座等。效果不能说惊艳，但作为概念草图和内部验证是够用的。这条路线的最大优势是不依赖特定平台，所有东西都在你自己的机器上，数据安全可控，而且脚本改起来没有黑盒限制。
我把三条路线的差异整理成了一张表，方便你按场景选型：
| 路线 | 生成方式 | 可编辑性 | 技术成熟度 | 数据合规性 | 适合场景 |
|---|---|---|---|---|---|
| 类Zoo架构 | LLM生成CadQuery脚本后本地编译 | 高，脚本即特征树 | 相对成熟，开源项目多 | 可控，代码可在本地跑 | 标准机械件、概念设计、快速出样 |
| 大厂黑盒生成 | 直接在B-rep空间生成实体 | 低，结果难以局部修改 | 实验室阶段 | 受限于云平台 | 复杂曲面、创意形态探索 |
| 通用LLM+脚本软件 | LLM生成FreeCAD/OpenSCAD脚本 | 高，可逐行改 | 完全可用 | 完全本地化 | 通用工程师、特别适合已有FreeCAD基础的用户 |
3. 实操复盘：我说一句“法兰底座”，AI给我交付了什么
3.1 输入Prompt的设计：像写零件需求书一样写描述
很多人第一次用text-to-CAD，喜欢甩一句特别写意的话：“给我一个机器人的连接件。”然后看着AI生成一个看起来酷炫但完全没法用的东西，转头就骂工具不行。
我的实测经验是：prompt的详细程度，决定了生成结果的上限。你给AI的信息越像一个认真工程师在写“零件需求书”，它给你的回应就越像一个合格的设计师。我总结出的一套有效prompt模板是下面这样：
- 明确零件类型（是法兰、是支架、是壳体，还是轴套？）
- 明确主尺寸和各特征尺寸（外径、长度、孔径、厚度）
- 明确特征空间位置（孔距、中心距、阵列圆直径）
- 明确提出工艺相关要求（是否有倒角、是否要沉头孔、壁厚最小多少）
- 明确导出格式（STEP、STL还是DWG）
打个具体的例子。我实际用过这样一个prompt：
“创建一个方形铝制安装基座，长度80mm，宽度60mm，高度15mm。顶面四个角倒R5圆角。基座中心开一个直径20mm通孔。以中心孔轴线为中心，在直径40mm的圆周上均匀分布4个直径6.6mm通孔。底面挖一个深度8mm的矩形减重槽，长度60mm，宽度40mm，四角倒R3圆角。导出为STEP。”
这听起来啰嗦对吧？但正因为每一句话都能映射到具体的几何约束，LLM生成的CadQuery脚本才不出错。AI不懂“好看”“结实”“稍微大一点”这种模糊形容词，它只认数字和拓扑关系。信息密度越高，翻车率越低。
3.2 生成后的三项检查：尺寸、单位、几何合法性
脚本执行完，屏幕上出现了模型，可别高兴太早。生成三维模型只是第一步，紧接着必须做三项检查，我每次都执行，一次都省不了。
第一项是尺寸检查。逐项核对模型里的关键特征是否和需求相符。翻车场景极其经典：你要求直径80mm，AI理解成半径80mm，或者把mm写成了inch，整个模型尺寸直接变成2.54倍。这种错误在视觉预览阶段根本发现不了，必须用测量工具精确点选。
第二项是孔位计算。CAD脚本里的阵列运算不是物理仿真的结果，它是纯几何计算。比如我刚才要求“直径40mm圆周上均匀分布4个孔”，这个阵列的起始角度、跨距都可能因为浮点数误差出现微小偏差。我实测中碰到过孔位重复、阵列角度错位导致螺栓孔和传感器窗口干涉的问题，视觉上根本看不出来，一上装配体就暴露。所以对关键孔位，我习惯用计算器独立算出期望的极坐标值：4个M6孔在40mm圆周上，相邻角度90度，每个孔的xyz坐标用x = 20*cos(40°)这种方式先手算一遍，再跟模型对照。
第三项是几何合法性。用CadQuery或FreeCAD的Part菜单里的“检查几何”功能，确认实体是封闭的、没有碎面、没有非流形边。这步很重要，因为它直接决定后面STL切片或者STEP导入CAM时会不会报错。如果检测出开放面或者重叠面，别懒得修，回脚本里删掉或重建相关特征，比在锅里修网格快得多。
3.3 导出与二次编辑：把AI生成的草稿接进真实工程流
三项检查做完，接下来就是导出和二次加工。
我在Zoo和FreeCAD这边一般直接导出STEP格式，这是工程里最通用的“无损交换”格式。STEP文件携带准确的B-rep实体数据，导入SolidWorks、Fusion 360或者CATIA都不会变成面片。需要注意一点，导入前一定确认软件的默认单位设置。FreeCAD默认mm，SolidWorks通常也是mm，但个别软件或者插件默认是英寸（in）。单位错了，一个小小的大拇指形状的零件可能直接就变成一个机械巨兽。
导入主流CAD软件之后，我通常还会做几件AI目前做不到的事：添加公差标注（比如内孔标H7配合）、加表面粗糙度符号、处理出工程图时的视图投影。这部分不是“修模型”，而是在“完善交付物”。AI能生成的是几何，图纸上的工艺语言必须人来落笔。也正因为如此，我从不把text-to-CAD的输出称为“完成品”，它只能算作一个精度足够好的设计底稿。
4. 生成翻车诊断：为什么结果“看着对却又不对”
4.1 自然语言的“歧义”会直接变成模型错误
前端时间我用text-to-CAD试着生成一个带U型槽的滑块，我输入的是“一个长60mm宽30mm高20mm的滑块，顶部有U型槽，槽深10mm，槽宽8mm。”结果AI给我做的槽，宽度和深度都没问题，但槽的位置不在顶面中心，而是歪到了侧边。
后来我一想，问题出在我自己身上。我只说了“顶部有U型槽”，没说“U型槽居中对称”，更没说“槽的中心线沿着长度方向居中”。大语言模型不是人，它不会主动推断“顶部开槽默认居中”这种潜规则。它只会按字面把所有可能的约束条件都减少到刚刚满足你提到的那些，其余全靠“训练统计分布”猜。
这个案例给我的教训非常深刻：凡是涉及配合、安装、对称这些要求，一律得用数值或明确位置来限定，不要指望AI懂“常识”。
4.2 特征顺序和父子依赖：关系一旦错了就全崩
UV槽那个问题只是位置错，更隐蔽的是特征顺序错乱。有次我生成一个“带八条加强筋的方形底座”，AI的脚本把加强筋拉伸放在了底座挖减重槽之前。结果就是：它先生成加强筋，然后再在底座上切掉一块材料，切槽直接把筋的根部切断了。这种错误在屏幕上看起来只是少了一块材料，等到分析受力或者做DFM时才意识到加强筋的截面被挖掉了大半，整个结构强度从设计层面就废了。
对于这类问题，我现在的做法是拆开prompt：把“先创建底座”“再切除减速重槽”“最后拉伸加强筋”这种步骤顺序直接写进描述。更好的办法是生成后去看脚本，检查建模操作的顺序是否有逻辑问题。规则很朴素：先主体特征，后切减特征，最后加附属特征。AI自动生成的顺序不一定遵循这些工程习惯，必须人工检查。
4.3 制造约束上的“想当然”：AI默认的工艺参数很可怕
在DFM层面，AI的“想当然”更是重灾区。规定壁厚至少2mm，但实际上生成出来的筋板最薄处只有0.3mm；要求在注塑件上开螺纹孔，AI生成的是通孔而不是带锥度的自攻螺纹底孔；要求“表面光滑”，AI给所有棱角都加了大r圆角，结果圆角半径反而让后续加工无法装夹。
我一度被这些坑气到想放弃这类工具，后来想通了：AI根本不理解制造过程，它只是把语言里的形容词对应到一些几何操作上。你以为“光滑”是指Ra3.2的表面粗糙度，在它那里就变成了加一个两毫米圆角。所以从那次之后，我在所有涉及圆角的prompt后面都会强制加上“仅在外露棱边倒角，配合面保持直角”这样的事无巨细的要求。
4.4 我整理的一份问题排查清单：从症状到根因
为了让自己和团队不再反复踩坑，我整理了一份常见问题排查清单，分享出来供你参考：
| 症状 | 根因 | 解决路径 |
|---|---|---|
| 模型整体尺寸莫名放大/缩小 | 单位混淆（mm误作inch等） | 检查脚本里的尺寸变量和单位换算，STEP导入时强制指定单位 |
| 孔位设置偏移或阵列角度不对 | 阵列圆心/起始角未明确定义 | 手工复算PCD和孔位极坐标，回脚本修正 |
| 实体无法切片或导入CAM报错 | 存在开放面、非流形边、重复面 | 用模型检查工具做布尔分析和实体诊断，重建相关特征 |
| 筋类结构根部被切除 | 特征顺序错误，切减发生在拉伸前 | 调整脚本内部建模操作顺序，先主体后切减再加附属 |
| 零件拔模角为0出模卡死 | 忽略脱模方向需求 | 在prompt里强制要求拔模角度，并在脚本中验算 |
| 圆角/倒角位置与意图不符 | 自然语言描述里的“光滑”等模糊词被过度解读 | 消除模糊词，精确指定倒角位置和半径 |
5. 从“能出模型”到“能上机器”：补齐工程化最后一步
5.1 公差和表面质量必须人来补
AI生成的几何体是理想的数学实体，它没有尺寸公差、没有几何公差、没有表面粗糙度要求。但真实制造的每一个零件都必须有这些工艺语言。孔是H7还是H8，轴承位是js6还是k6，表面要不要磨削，这些信息AI标志没法表达在STEP文件里，必须在工程图阶段用标注说明。
我的做法是：AI生成模型完成并检查合格后，就把模型拖进CAD出工程图模块，手动补标关键配合尺寸的公差，并根据加工方式注明表面粗糙度。这部分没有任何捷径，懂工艺的人才能干好，所以text-to-CAD替代不了有经验的工程师，它只是把出草图的耗时压缩了。
5.2 DFM检查：壁厚、拔模斜度、最小圆角
下一步是把模型丢进DFM检查流程。如果你做的是注塑件或压铸件，开模前必须检查三个指标：最小壁厚是否均匀、拔模斜度是否符合脱模方向、最小圆角是否满足材料流动要求。这些参数取决于具体材料和工艺，AI不可能根据你的注塑机吨位和模具钢材去推算。
我习惯在生成模型时采用保守目标：壁厚均匀2.5mm起步，拔模斜度1度起步，内部圆角0.5mm以上，外部圆角根据外观需求单独指定。这些保守值哪怕后续加工方案改了，也不至于让结构出现致命缺陷。注意，这不是AI教我的，是我在生成后手动回到脚本改动变量再重新编译得到的。恰恰因为脚本化，修改这些关键参数的成本低得惊人，这也是为什么我坚持走“脚本生成”这条路而不是黑盒模型。
5.3 团队协作和历史追溯：一套可行的“提示词+脚本”仓库
把自然语言看作是设计入口之后，整个图纸流转的链路也应该跟着变。我在项目里采用了一个内部习惯：每条text-to-CAD需求都附带一个提示词说明文档，里面写清需求的背景、名词解释、数量级假设以及生成的脚本文件路径。脚本文件本身放进Git仓库，和源代码一起版本管理。
这样做的好处非常直接：三个月后这个零件要改版，同事打开Git历史，看到的不只是一堆几何特征，还有当时“为什么要这样设计”的完整上下文。这件事在传统CAD协作里很难做到，因为Fusion 360或SolidWorks虽然也有特征树，但没人会认真写设计说明。而text-to-CAD的脚本本身就是一种自文档化的设计过程，把这段脚本和提示词绑定，就相当于拿到了设计过程的完整录像。
6. 一个资深用户的冷静结论：什么场景值得上，什么场景别凑热闹
6.1 我推荐你立刻试试的场景
如果你跟我一样经常要出一些标准支撑件、安装支架、壳体底座、板类零件，而且耐心有限，那么text-to-CAD值得花一个下午认真测试。特别是以下几类情况，它是真能改变效率的：
- 定制化夹具/治具设计，这类零件形状简单但变化多，每改一次客户需求就要重画一遍。
- 快速概念验证，你在评审会前需要一个模型跟同事说明空间位置关系，不需要精细结构。
- 标准件库扩充，把螺丝座的孔位、底板的长宽高参数化后，批量生成多个规格。
- 3D打印爱好者或小批量数控加工的“够用就行”场景，只要几何正确，不追求复杂曲面。
这些场景的共同点是你需要的模型偏功能而非形态，几何信息完全可以靠几句话描述清楚，而AI刚好把这部分执行的非常稳定。
6.2 我不会把它作为主力工具的任务
反过来，下面这些任务我不会用text-to-CAD去碰：自由曲面造型（消费电子外观、汽车内外饰、运动器材手感面）、复杂装配体干涉验证（涉及上千件零件的总装，需要严谨的装配约束和逻辑）、高精度注塑模具设计、以及需要大量现有标准件库复用的产品改型。不是说AI做不到，而是在这些领域，专业软件沉淀的知识体系和设计意图是语言模型难以复刻的。硬把它用在那种场景，只会得到一堆修修补补的重工活，不如老老实实打开专业CAD按部就班地建模。
6.3 我的工作流建议：让AI干最快的那段路，而不是替你走完全程
最后说说我现在的工作流落点。我的实际项目里，text-to-CAD已经固定成了一个“起步加速器”角色。接手新任务时，我会先根据自己的经验把需求拆成标准零件描述，然后用text-to-CAD快速生成一个结构草样，再把这个草样导入FreeCAD进行细节调整、装配验证、出图。
这么做的好处是，我把一两个小时的基础建模压缩到了十分钟。坏处也明显，前期生成的模型有时候会出现一些“智障性错误”，比如没留避位间隙、倒了个莫名其妙的圆角。所以我从一开始就没打算让它独立完成任务，而是把它当作一个能快速响应需求的助手。人负责提需求和做检查，AI负责把极耗时间的那段几何构建跑完，这个分工是目前最靠谱的协作模式。
我个人还有一个很实用的习惯：无论用Zoo还是通用LLM生成代码，跑通之后我一定会把那段脚本复用模板化。同类型的零件，只需要改几个核心尺寸变量，就能在半小时内派生出一整个系列。这在传统CAD里需要做系列化零件设计表，在text-to-CAD里只是改一行参数的事。省下的时间，足够你去认真琢磨公差和工艺了。这个方向的技术迭代还很快，但原理已经稳定：语言描述进入、脚本编译生成实体、人工检查导出交付。只要你不指望它是灵丹妙药，它就能成为你手里一把相当称手的快刀。
