为什么我现在愿意把text-to-cad当正经工具用了
先交代一个背景：我算是个老CAD用户了，SolidWorks用了小十年，Tinkercad、Fusion 360、FreeCAD都在项目里真刀真枪干过活。第一次听说text-to-cad这个词时，脑子里只有一个念头：又一个大忽悠。用大白话让软件自动建模？我连尺寸标个公差都要弹半天窗，你让AI凭空画个零件？绝对不信。
但事情在两个月前发生了变化。当时接了一个非标自动化的小项目，需要给一台老设备设计一套安装支架。甲方嘴上说"简单改改"，实际需求是：法兰盘要装四组传感器，孔位要避让原有管路，底面要做成斜面配合设备基座，每个版本还要出三视图和STEP文件。我在这种反复拉扯里被折磨了两周，光是孔径和孔距的排列组合就改了十几个版本。
直到有一天，团队里一个刚毕业的小朋友说：要不试试用自然语言直接生成模型？我当时想的是，让他折腾去，不行再回来。结果他用了不到一个下午，把一个我们改了四版的传感器支架，直接用一句话重新生成了一遍，而且特征树干干净净，参数还能改。我站在他屏幕前面愣了很久。
这篇文章不是来吹捧什么"AI淘汰设计师"的，那都是外行话。我真正想说的，是我从怀疑到上手、再到把它放进真实工作流之后，text-to-cad到底能干什么、不能干什么、原理上是怎么实现的、哪些坑我已经替你踩过了。如果你也在做机械设计、创客项目、3D打印或者工装夹具类的工作，这篇文章应该能帮你在十分钟内判断：这个方向值不值得投入时间。
1. 为什么"文字生成CAD"不是玩具项目：一个真实需求在背后推着它走
1.1 从"改图地狱"到"重写即改版"：我亲历的折磨式对比
传统参数化建模软件解决的是"你已经知道要什么"的情况。模型树摆在那，特征顺序、约束关系、基准面、草图全都等着你去定义。问题是，现实中很多需求在开始建模时根本没想清楚——尤其是设计早期和方案论证阶段。
打个比方：你接到一个需求，"在设备侧面加一个托架，放个两公斤的传感器，孔距大概40毫米，别挡着下面的油管"。这种活你拿SolidWorks建模型，半小时起步，中间还要反复确认尺寸。确认完，客户说孔距改成45，齿轮转动方向变了传感器要换个面装。怎么办？进草图改尺寸、改特征顺序、有时候一个特征过期了整个后面全红。
text-to-cad这类工具碰巧就戳中这个痛点。它背后的设计逻辑不是"参数化建模"，而是"描述即结果、重述即改版"。你不需要去软件里一圈圈找那个被隐藏的草图，直接重新组织语言描述你的新需求，它给你一个新模型。这个过程快的很，对于多版本尝试、二维转三维沟通、甚至教学演示都特别有用。
1.2 一个被大多数人忽略的事实：很多需求本来就是"说"出来的
我自己复盘了一下，在工厂车间、设备维护和现场沟通的场景里，老师傅跟你讲东西从来不是拿着图纸讲的。他抄起一个零件或者用手比划："这里做个耳朵，打个孔，能穿上M8螺丝就行""这边切个斜面，留两毫米壁厚""这个件跟那个件是配合的，中间留三丝的间隙"。
这些口语化、模糊、充满上下文依赖的需求，传统CAD根本吃不下去，必须有人把它翻译成精确的几何尺寸。而text-to-cad的技术路线恰好就是先解决"翻译"这件事。它把自然语言转换成结构化建模指令，再执行生成几何。换句话说，这本质上是一个"语言到参数"的中间层问题，而不是"软件自动化"问题。
这也是为什么text-to-cad在2024年到2025年突然成了热点方向——不是建模内核变魔术了，而是大语言模型在"理解模糊需求并生成结构化代码"这件事上成熟了。前端是聊天框，中间是LLM，后端就是那些我们已经用了几十年的开源建模内核。它不是替代我们画图，而是替代我们从"人话"到"CAD操作"之间那段最繁琐的翻译工作。
我一直觉得，真正推动一个工具火起来的不是技术炫技，而是它恰好解决了一个大量用户在高频场景下都很烦的问题。参数化建模软件把"改图"的成本压低了，但并没有把它消除。text-to-cad的路线则是彻底换了个思路：不跟你玩"改"，而是玩"重新生成"。
2. 一条指令背后的三层结构：text-to-cad的工作原理拆解
2.1 语言模型完成的翻译：从自然语言到参数化脚本
如果你用过text-to-cad类的工具，你会发现一个现象：它生成的结果通常不是一个直接的网格文件（也就是STL/OBJ那种），而是一段建模脚本，常见的形式是OpenSCAD、CadQuery或者build123d这类的程序化建模代码。这一步是整个流程的核心环节。
这里需要把"程序化建模"这个概念展开讲一下。传统CAD里，你画一条直线、拉一个凸台，每一步都用鼠标操作，软件在内部生成特征记录。而程序化建模不一样：整个模型是由代码定义的，几何体由代码逻辑构建。比如用CadQuery创建一个带法兰的圆柱套筒，本质上是"先拉个圆柱，再拉个法兰盘，然后布尔合并，再加一个孔"。每一步都有明确的函数调用和参数。
大语言模型在这里干的事情，就相当于一个"翻译+助理工程师"：它读取你的文字（比如"一个直径50毫米、高度30毫米的圆柱套筒，顶部带直径80的圆形法兰，法兰上均布6个M6通孔"），把这些话翻译成一段合法的CadQuery或OpenSCAD代码。这个翻译动作要求LLM同时理解几何语义、尺寸语义、特征语义和语法规范，一件都不少。
我观察到一个容易误导新手的细节：text-to-cad并不是在"生成模型"，而是在"生成模型的程序"。程序执行了，模型才出现。这个区别极其重要——因为程序的本质是参数化的，它允许你在不重新画的情况下，只改代码里的一个数字就得到一个新模型。这也是它与传统AI生成图片（用扩散模型生成像素）最根本的分野：一个是像素级"画"，一个是参数级"建"。
2.2 几何内核执行脚本：为什么底层跑的不是"画图"而是"布尔运算"
理解了text-to-cad生成的是程序之后，还需要理解程序是怎么变成实体的。这一步靠的是几何内核（geometry kernel）和CAD操作库，常用的有：
- 基于CadQuery的，底层依托OpenCascade（OCCT）
- 基于OpenSCAD的CSG（构造实体几何）方式
- 基于trimesh之类库直接在网格上做布尔运算
- 也有一些闭源工具直接在云端的BIM/机械CAD内核里跑
以CadQuery为例，它底层用OCCT这个工业级几何内核。OCCT能做的事很多：创建边、面、实体，做拉伸旋转扫掠，做布尔加/减/交，做倒角圆角，以及导出STEP、IGES这类工业交换格式。这是一个几十年的老内核，稳定性远胜于那些基于网格点的玩具库。
所以你会明白，text-to-cad的可靠性其实是"大模型的理解能力+工业内核的计算能力"两件事的叠加。模型负责把话说清楚，内核负责把事做对。前面那个兜底理解，后面那个兜底精度。这也是为什么我在实操中比较放心：即使个别生成结果有问题，只要看生成的代码，堆栈在哪一步基本能推理出来。相比"黑盒生成然后修网格"，这一步的可调试性好太多了。
2.3 从脚本到特征树：为什么"参数化"和"可编辑"是它的真正卖点
你要是在社区里看text-to-cad生成的结果，会发现很多项目除了给你模型，还会给你一份完整的建模脚本。这意味着什么呢？说明这个模型并不是一块"死疙瘩"（比如网格文件），它保留了完整的建模历史，你可以回到脚本里改任何一个参数，比如把法兰外径从80改成95、把孔数从6改成8，重新执行一遍就得到新模型。
这个能力在智能制造和快速迭代场景里是宝贵的。因为网格模型（STL/OBJ）一旦生成，改任何一个特征基本等于重画；而脚本模型从出生开始就自带"遗传信息"。我在一些开源项目里看到有人把一整套零件库全部参数化，只靠改Excel参数表重新生成整机装配。这种工作流在传统CAD里要建一整套"设计表"和"方程式"才能实现，门槛相当高。text-to-cad把它拉低到了"会改数字"的水平。
再看一遍它的层级结构：
- 输入层：自然语言，比如"给我一个带四个安装孔的主轴端盖，外径120，厚8"
- 理解层：LLM解析意图，确定特征序列（旋转体、孔阵列）、尺寸、约束
- 编码层：生成CadQuery/OpenSCAD等程序脚本
- 计算层：几何内核（如OCCT）执行脚本，完成实体建模和布尔运算
- 输出层：生成STEP/STL/glTF或直接在浏览器里显示模型
我在章节开头说"三层结构"，其实严格一点应该叫五层。但理解成三层更顺手：你负责"说人话"，模型负责"翻译成代码"，内核负责"执行出模型"。这三方各管一摊，清楚明了。
3. 从一行提示词到第一个零件：我的完整上手实测
3.1 环境准备与工具选型心得
如果你想试text-to-cad，现在有两条路：一个是直接用在线版（很多开源项目都有demo站），另一个是本地部署开源项目，比如知名的代码库配合Ollama加模型自己跑。
我建议新手从在线Demo开始——真的，不用一上来就折腾环境。我自己第一次用的时候就是直接在浏览器窗口输入：
Create a mounting bracket with a 40mm x 60mm base plate, two 10mm mounting holes at 20mm spacing, and a vertical plate with a 25mm hole at the center.几秒钟后，浏览器里出现了一个可以旋转、缩放查看的3D模型，旁边还有生成它的CadQuery代码。这个体验相当冲击——那种"一长串英文变成实体"的感觉，确实有点当年第一次看到参数化建模时的震撼。
但如果要做正经项目，我强烈建议本地跑一套。因为本地环境里，你可以完整控制模型版本、保存脚本、对接后处理流程。在线demo虽然方便，却受限于平台的功能边界，而且很多在线端为了性能，不支持太复杂的布尔运算。我目前的本地配置是Python + CadQuery + 一个开源的text-to-cad脚本工具，再用Qwen或者GLM这样的中文模型做语义解析。没错，中文描述也已经支持得很好了，后面我会专门说这一点。
3.2 三个实测例子：法兰盘、轴承座、带筋板的支架
为了客观评估，我做了三组测试，难度依次递增。第一组是法兰盘，第二组是轴承座，第三组是带加强筋的L形支架。直接看结果。
先说法兰盘。提示词大概是："一个直径80毫米的圆形法兰，外圆倒角C1，中心有一个直径30毫米的通孔，法兰面上均布6个直径6.5毫米的安装孔，分布圆直径65毫米。"
生成结果相当顺利。CadQuery脚本里用了旋转特征创建外圆盘，然后Cylinder创建通孔，再用Polar阵列打出6个安装孔。STEP文件导出后用FreeCAD打开，外径尺寸实测79.98毫米，倒角明显，孔距均匀，完全可以直接用于3D打印打样。这一局表现优秀。
第二个是轴承座。我描述了一个带底座和两个侧壁的U形轴承座，底部有四个沉头孔，侧壁上有用于装轴承的同轴大孔。这个任务开始有难度了，因为涉及多个特征组合和镜像操作。结果生成出来之后，模型形状是对的——U形结构、底孔、侧壁同轴孔都出来了——但是有一个问题：沉头孔的沉头深度做成了3毫米，而我设想的是1.5毫米。这属于"语义理解偏差"，它不是语法错误，而是对"沉头"的功能深度理解不到位。解决办法很简单：补一句"沉头深度1.5毫米，总孔径6.5毫米，沉头直径11毫米"，重新生成就对了。
第三个是带筋板的L形支架。我把筋板厚度、位置、圆角半径全都在提示词里写清楚了。结果生成的模型在布尔运算阶段出现了报警——两个体之间存在非流形边，也就是俗称的"破面"。这个在后面排查章节细说，这里先提一嘴：这类问题是几何内核和模型理解共同作用的结果，不是模型本身"笨"。
3.3 关于中文支持的真实体验
第一批text-to-cad工具几乎只支持英文，因为LLM训练数据里英文工程语料占大头。但到了2025年，我在本地部署的模型上直接写中文提示词：
"做一个底板，长120，宽80，厚12，四角开四个直径8的圆孔，孔心距边10毫米，底面四个角做R6圆角"
生成结果整体可用，圆角、孔位都正确。只是偶尔会把"孔心距边10毫米"理解成"边距中心线10毫米"，这个需要把提示词写得更明确一点。我的习惯是单位直接写"mm"，尺寸写成"X毫米"或"X mm"，避免歧义。中文支持能到这个程度，已经很能打了，日常工装夹具类的描述基本够用。
4. 连续两周实测出来的能力边界：哪些能信，哪些要警惕
4.1 表现稳定的常见结构类型
先给结论：目前text-to-cad在"通用机械零件"这个范畴里，表现已经从"偶尔能用"进化到了"基本能打"。我实测了两周，整理了下面这张表：
| 场景类型 | 典型例子 | 稳定性评级 | 备注 |
|---|---|---|---|
| 旋转类零件 | 法兰盘、轴套、皮带轮 | 很稳定 | 特征逻辑简单，孔阵列好生成 |
| 板金类外观件 | 底板、支架、外壳切片 | 稳定 | 只要描述清楚壁厚和孔位 |
| 组合类箱体 | 传感器盒、电池仓 | 看情况 | 多个壳体+卡扣容易出问题 |
| 螺纹特征 | 外螺纹、内螺纹孔 | 一般 | 需要明确"公制粗牙M6"这种表达 |
| 复杂曲面 | 叶轮、涡轮、外壳曲面 | 很不稳定 | 参数曲面生成完全看运气 |
| 复杂装配逻辑 | 齿轮啮合、多部件运动副 | 不可用 | 不适合整套装配设计 |
我个人的判断标准是：一个零件里"拉伸/旋转+孔/阵列+简单布尔"的比例越高，生成成功率越高。因为这些操作在代码层面就是几个函数调用，LLM在训练数据里见过大量类似代码，规律好摸。反过来，涉及曲面扫掠、放样、扭曲、以及需要满足特定公差配合的场景，成功率断崖式下跌。
4.2 容易翻车的五类提示词写法
这里把我踩过的坑总结一下，全是实操记录：
第一，含糊的尺寸关系。比如"孔要比轴稍大一点"——"稍大一点"对人是可以协商的模糊需求，对CAD就是灾难。LLM大概率猜一个0.5毫米或1毫米间隙，但你的"稍大"可能是0.02毫米的过渡配合。所以，只要涉及配合，请直接说公差等级（H7/g6）或者具体数值（间隙0.05mm）。
第二，多个特征互相参考。比如"A面和B面平行，A面比B面高5毫米"。这种描述在自然语言里顺滑，但生成的代码需要建立复杂的草图和约束关系。目前的text-to-cad工具往往直接采用"各自定位"策略，不会自动建关联约束。结果是位置对，但你要改A的高度，B不会跟着动。所以提示词里尽量用绝对数字，别用相对约束。
第三，"左侧""右侧""前面"这种方位词。模型没有固定视角坐标，如果前面没有基准轴约束，"左边"很容易理解成"朝向屏幕的左边"或者"模型坐标系X轴负方向"。我遇到过生成结果和预想镜像翻转的情况。建议直接用语"X轴正方向""Y轴负方向"或者"沿Z轴旋转"来替代。
第四，过度复杂的单条提示词。比如"设计一个带裙边、四个耳朵、四组阵列孔、顶面有散热鳍片的盒子，壁厚2.5，底部还有三个螺丝座……"这种信息量爆表的描述，LLM很容易丢掉一两个特征。我的经验是拆成多条对话，先基体，再特征，再细节，分步生成。
第五，"高级但没说全"的专业术语。比如你说"轴承位"，模型知道要做个圆柱台阶，但配合公差、粗糙度、退刀槽这些信息你都不给，它只能按默认做。不是它不专业，是信息缺失导致只能猜。
4.3 精度、可编辑性和文件交换的实测结论
精度方面，text-to-cad生成的STEP文件经过工业级几何内核计算，尺寸不会是像素猜的。我拿游标卡尺量过3D打印件，外径误差在0.1毫米级别，完全符合FDM打印的公差范围。但要注意：这个精度取决于生成的脚本本身，如果LLM生成的代码里给的尺寸就是错的（比如把80写成了88），那建模内核再准也没用。所以，生成之后第一步永远是"核对关键尺寸"，我最常用的方法是在FreeCAD里打开STEP，用测量工具直接量一遍关键位。
可编辑性分两层看。脚本层的可编辑性：非常好，你直接改参数重跑就行。模型层的可编辑性：一般，因为在传统CAD里打开生成的STEP文件，虽然能读进特征，但很多开源工具生成的模型，特征树没有体现出"垫片+凸台+孔"的清晰层次，更接近一个"实心体"，后续编辑不如原生CAD模型顺手。如果你要在SolidWorks里二次加工，建议先用STEP转一次，再用"输入诊断"修复特征，而不是直接拿原始脚本当SolidWorks原生模型用。
文件交换方面，CadQuery可以导出STEP、IGES、STL、SVG、DXF，覆盖面够用。我个人最常用的是先导STEP，再导入FreeCAD做装配干涉检查。这里有个小提醒：如果最终要跟客户或供应商对图，一定确认对方能打开STEP格式。遇到过有供应商只收SolidWorks原生格式的，这种就得再转一步了。
5. 距离生产力工具还差最后的工程性问题：我的巡检清单与个人体会
5.1 最容易忽略的坑：生成后的几何验证
哪怕text-to-cad生成模型再快，我始终保留一套人工巡检流程。不是不信任AI，是CAD模型出了问题检测成本太高，而且往往在装配或者加工阶段才爆雷，那时候代价就大了。
我的巡检清单固定只有五项：
- 关键尺寸核验：用测量工具量直径、孔距、壁厚，跟提示词比对。
- 布尔运算完整性：检查有没有非流形边、破面、悬空面。在FreeCAD里可以用网格检查工具跑一遍。
- 拔模和圆角：如果涉及注塑件，必须确认拔模角度和圆角在模型里都存在，否则加工出来就是废件。
- 装配意图：如果模型要配合现有零件，导入装配体里做干涉检查，别信"看起来差不多"。
- 单位制：STEP文件里单位错乱的坑我踩过好多回了。CadQuery默认毫米，但有些工具链默认英寸，导入时务必核对。
5.2 把text-to-cad放进团队工作流的两个实操建议
第一，把它定位成"早期方案验证工具"，而不是"最终交付工具"。我现在的用法是：接到需求后，先用text-to-cad生成3~5个概念外形，供团队和客户快速筛选。选定方向后，再进入传统CAD细化公差、标注、出工程图。这个流程让我们方案阶段的见效速度提升不少，但并没有替代原来CAD工程师的职责。
第二，把提示词当成项目资产管理。我现在每做一个模型，都会把最终成功的提示词、脚本和渲染图放在一起存进项目文件。因为text-to-cad的可复现性完全取决于提示词，好的提示词跟好的模型文件一样，是资产。下次碰到类似零件，直接改几个参数，复制改改又是一版。这个习惯带来的边际效益很高。
5.3 我的真实判断：这条路会走向哪里
我自己对这一块还是挺看好的。倒不是因为模型生成多惊艳，而是因为它把"设计表达"的抽象层级抬高了一层——从"操作坐标点"到"描述意图"。当设计师能直接用功能语义交流时，和制造端、客户端的沟通成本会降一个量级。
当然，它离"用一个提示词替代一个工程师"还差得远。没有约束求解器的深度支持、没有装配级的逻辑推理、没有公差分析和工程图标准，这些都还是不可逾越的边界。但作为概念设计、非标快速打样、教学演示、创客项目的工具，它已经能实实在在省时间了。
最后分享一个我的个人习惯：用中文描述时，我习惯把所有尺寸统一成毫米，把配合关系写成可校验的数值形式，并在最后加一句"请以标准ISO符号标注所有孔和螺纹"。这样生成的脚本质量，普遍比啥都不管直接一句"做个支架"好很多。你有兴趣的话，可以从一个法兰盘或底板开始试，十分钟就能感受这套工作流的独特节奏。
