干这行十年，CAD软件换了三四代，从命令行敲坐标到鼠标拖拽，再到参数化建模，我本以为这就是效率的极限了。直到最近几个月，我密集测试了一批text-to-cad工具，才意识到我们可能正站在一个真正的分水岭上——你只需要用自然语言描述“我要一个能卡在桌沿的C型夹，开口28毫米”，几秒钟之后，一个可编辑、可参数化的CAD模型就会出现在屏幕上。

这篇文章不是学术综述，也不是软件评测的搬运工，而是我作为机械设计从业者，在过去几个月里把主流的text-to-cad工具逐个拉出来“过堂”之后的实操总结。我会告诉你哪些工具能打、哪些是玩具，底层原理到底是什么，以及最关键的——在当前这个节点，它到底能替我们干多少活，又会在哪些地方让你摔跟头。无论你是机械工程师、3D打印玩家，还是做工业设计的，这篇文章应该能帮你省下不少试错的时间。

1. 什么是text-to-cad：从“画图”到“说图”的范式转移

1.1 一句话定义与核心价值

text-to-cad就是把自然语言描述转化为CAD模型文件的AI技术。你输入“一个带法兰的圆柱管，内径40mm，法兰上有6个对称的安装孔”，它输出一个可以下载的STEP或STL文件，或者直接在你常用的CAD软件里生成可编辑的特征树。

这件事的价值怎么强调都不为过。传统CAD建模的瓶颈从来不在“想”而在“画”——一个熟练工程师80%的时间花在了拉伸、切除、倒角、阵列这些重复性操作上，真正用于构思设计的时间少得可怜。text-to-cad直接砍掉了中间那个最耗时的环节，把设计意图到几何表达之间的距离，从“小时”压缩到了“秒”。

更重要的是，它把CAD建模的准入门槛拉到了历史最低点。过去一个外行想做个3D打印零件，光是学会SolidWorks的基本操作就得一两周；现在他只需要会说中文或英文，就能得到一版可用的模型。这种变化对于创客教育、快速原型验证、甚至非机械专业的跨学科协作，都是革命性的。

1.2 它和传统参数化建模的本质区别

很多人误以为text-to-cad就是“自动宏命令”，或者“语音输入版CAD”，这个理解偏差很大。传统参数化建模是“自底向上”的逻辑——你先画草图、标尺寸、做约束，然后拉伸切除，每一步都由你控制，模型是确定性过程的产物。而text-to-cad是“意图到几何”的端到端生成——你只给描述，模型内部通过深度学习网络直接预测几何体素、草图轮廓，甚至隐式曲面场（SDF），这中间是没有人类逻辑可循的黑箱。

这也解释了为什么text-to-cad生成的结果常常“形似而神不似”——它懂形状，但未必懂工程约束。比如你说“承重10公斤的支架”，它能给你画出一个支架的样子，但它内部并没有真正的力学计算引擎去验证这个支架能不能承重10公斤。它理解的“承重10公斤”可能只是训练数据里类似标注的统计相关性，而不是真正基于材料和结构的力学分析。这是个极其关键的区别，后面聊局限时我还会反复提到。

1.3 当前生态全景：三股势力

现在的text-to-cad赛道可以清晰划分为三股势力，理解这个格局有助于你选型。

第一类是“文本直接生成模型”的纯生成式工具，代表有Zoo（以前叫Zoo Text to CAD）、Luma AI的Genie等。它们通常跑在云端，你输入Prompt，后台用扩散模型直接生成整个几何体，输出STEP或STL给你。这类工具最适合快速出概念形状，手头没有CAD软件也能用。

第二类是“大模型+参数化CAD”的混合式工具，代表有借助GPT-4等多模态大模型驱动的CAD脚本生成器，比如CadQuery、OpenSCAD的AI封装层，以及Autodesk Fusion 360里的“Generative Design”相关的AI辅助功能。它们不直接生成网格，而是生成一段参数化建模的脚本代码，让你在原生CAD环境里回放这段脚本得到模型。这类工具的好处是修改极方便，坏处是复杂模型真不一定能生成对。

第三类是“AI辅助设计平台”型的完整解决方案，比如PTC的Creo+、Onshape的FeatureScript AI辅助等，它们把text-to-cad作为CAD软件内置的一个入口，直接生成可编辑的特征历史。这类工具工程属性最强，但大多还在内测或功能受限阶段。

三股势力的选择逻辑很简单：你只需要一个看看样子的概念模型，选第一类；你要在现有项目中加入一个可编辑的零件，选第二类；你要在企业级环境中全流程使用，老老实实等第三类成熟，或者选一个混合方案的软件包。

2. 主流工具横向实测：哪款值得放进你的工具箱

2.1 实测环境说明

我测试工具的标准是固定的，避免“感觉不错”这种主观判断误导大家。测试环境是Win11工作站，i9-13900K，64G内存，RTX 4090显卡；模型导入到Autodesk Fusion 360和SolidWorks 2024里做后续验证。测试Prompt统一采用中英文双语，因为部分工具对中文支持差异很大。每个工具我至少跑了10个不同的Prompt，覆盖简单零件（方块、圆环）、中等复杂（支架、法兰配件）和复杂曲面（花瓶、人体工学手柄）三个难度等级。

评分维度包括：生成成功率（能导出合法文件的比例）、几何质量（网格或B-rep是否有破洞、自相交）、可编辑性（能否参数修改）、工程可用性（是否带圆角、壁厚是否合理）等。下面是我认为当前阶段最值得关注的几个代表。

2.2 Zoo：纯生成式工具里的头号选手

Zoo是我测试的所有“文本直接生成模型”工具中，几何质量最稳定、最接近可用的一个。它的核心强项在于对工程语义的理解——你说“M8螺栓”，它是真认识M8这个螺纹规格，而不是给你画一个光杆螺丝。它输出的STEP文件导入Fusion 360后，特征树直接存在，能进行常规的推拉操作。

实际测试中，我输入“a C-clamp that can clamponto a 28mm thick table edge, with a 75mm throat depth”，它的输出让我有点意外：不仅夹口开度是对的，还自动带了防滑齿纹和加强筋。虽然防滑齿的间距并不完全均匀，但作为概念设计完全合格。

Zoo的短板在于复杂装配体和运动机构。让它生成“四个齿轮啮合在一起的传动箱”时，它给出了四个互相穿插的齿轮，完全不考虑啮合干涉。这说明当前的生成模型对“装配关系”“运动副”这类高阶语义的建模能力还非常弱，只能处理单零件场景。

另一方面，Zoo的迭代改Prompt体验很好。你直接在对话里说“法兰盘上的孔从6个改成8个，孔径从8mm改成10mm”，它能在原模型基础上做局部修改，而不是推倒重来。这在生成式工具里很少见，实际用起来很顺手。

2.3 CadQuery代码生成：参数化建模的“穷人版”神器

如果你对生成结果的尺寸精度有硬性要求，纯生成式工具往往满足不了你——它生成的直径可能偏差零点几毫米，这在配合件里是致命的。这时候CadQuery的AI辅助生成就很有价值了。

CadQuery本身是个基于Python的参数化建模库，用代码定义模型，模型和代码是一一对应的。借助大模型生成CadQuery代码，你拿到的不是“一个模型”，而是一段可修改的脚本——想改壁厚？改个数字重新跑一下就行，精度是绝对的。

我的测试方式是这样的：要求模型生成一段CadQuery代码，做一个“外径60mm、内径50mm、高30mm的带法兰套管，法兰外径80mm、厚5mm，法兰上均布4个M5通孔”。生成Midjourney式的结果不太现实，但生成代码这件事，大模型做得相当好。这段代码第一次跑通率我实测在70%左右，剩下的30%通常是一些API参数名写错或逻辑顺序颠倒，人工修一下即可。

这套方案的优点非常明显——和传统CAD工作流完美兼容，自带历史记录和参数约束；缺点是你要会一点Python和CadQuery的基本语法，而且模型极其复杂（比如复杂的曲面造型）时，生成的代码会非常冗长且八成就跑不通。

2.4 需要避开的坑：两个华而不实的选项

我为写这篇总结，还专门测了两个宣传很猛但实际体验较差的方向，给大家避个坑。

其一是某些“AI CAD插件”类的工具，号称在SolidWorks里装个插件就能用自然语言生成整个装配体的，实际测试下来基本就是“大语言模型套壳”——它把你输入的文本先变成一堆SolidWorks API的VBA代码，再执行代码生成特征。这个思路本身是通的，但一旦遇到复杂特征，VBA代码就变得异常冗长且容易出错，加上SolidWorks API本身对参数化历史的依赖很强，你生成一个圆角，代码里可能把之前的特征全部重建一遍，速度慢到没法忍。

其二是某些手机App里号称能用“文字生成3D模型”的，点进去你会发现大多数生成的其实是“一个看起来像那么回事的3D贴图模型”，面数极低，纯展示用途，导出后根本无法用于任何工程分析或3D打印。如果只是玩票拍个视频，那无所谓；如果你是认真的，建议直接绕过这些。

开发方向很明确：能用参数化脚本生成的，别用网格生成；能在原生CAD环境里回放的，别用孤立格式导入。这条原则会帮你省掉大量返工时间。

3. 底层原理拆解：它到底是怎么“听懂”人话并画出来的

3.1 从“语言理解”到“几何生成”的桥梁

text-to-cad之所以成为可能，底层是两个独立技术栈的合流：大语言模型（LLM）负责“理解人话”，生成模型负责“画几何”。而两者中间，需要一个“翻译层”。

在Zoo这类工具里，翻译层是在模型内部联合训练的——文本编码器把自然语言映射到一个高维语义空间，几何解码器从这个语义空间里“解码”出几何体素或者隐式曲面。你输入“一个马克杯”，编码器把它转化成“圆筒状+单侧把手+底部”的语义向量，解码器再根据这个向量生成体素分布，最终折出网格。

在CadQuery这类代码生成式工具里，翻译层更直白：LLM直接输出结构化代码，代码本身就是几何的精确描述。这里不需要额外的“解码器”，因为CadQuery的建模内核就是解码器——文本到代码，代码到模型，一步到位。

这也是两类工具最本质的区别。前者是“端到端生成”，后者是“代码中介生成”。前者的天花板在于几何解码器的表达能力，后者的天花板则在于LLM对API的掌握精度。就我目前的使用体验来看，后者在工程精度上的上限高得多。

3.2 训练数据从哪里来：这是个决定性问题

可能很多人没想过，AI之所以能“认识”法兰、支架、螺纹，前提是训练数据里有海量这样的模型和文本标注。这些数据从哪里来？这是目前整个行业最大的灰色地带之一。

一部分来自公开的3D模型库，比如Thingiverse、GrabCAD这些平台，上面海量的用户上传模型天然带文件名、描述、标签，可以做弱监督训练。Zoo背后的公司就明确说过用了大量的开源3D数据。

另一部分来自合成数据。所谓合成数据，就是用程序化生成的方式，随机组合几何图元，自动生成几百万个“怪模怪样但标注清晰”的模型，然后用它们来做预训练。这个做法能极大扩充数据量，但缺点是合成数据和真实工程的分布差异很大——AI看到的“法兰”和机械设计手册里的“法兰”是有差距的。

还有一小部分是用户反馈数据。你在工具里对它生成的结果点“有用”或“没用”，顺手调整个尺寸，这些交互轨迹会被记录下来，反过来微调模型。这也是为什么很多text-to-cad工具都要求你注册账号——账号体系本质上是为了攒行为数据。

3.3 一个关键概念：隐式曲面表示

如果你去翻text-to-cad的技术文档，经常会看到“SDF”（Signed Distance Field，符号距离场）这个词。这是当前几何生成模型最主流的内部表示方式，值得花一点时间理解。

把三维空间想象成一块无限的豆腐，SDF就是在这块豆腐的每一个点上都记录“这个点到最近模型表面的距离是多少，正还是负”。表面本身，就是距离为0的那一层。模型生成的不是一个网格文件，而是“这块豆腐内部所有点的距离值”。表面提取则是一个纯数学操作——找出距离为0的等值面。

SDF的好处是它天然支持任意拓扑结构，不会像网格生成那样动不动就出现破洞或自交，而且它能轻松表示带有内部空腔的复杂零件。代价是计算量大、内存占用高，一般得靠GPU加速。你用text-to-cad工具时感觉“转圈思考很久”，有很大一部分时间就花在了SDF的推理和等值面提取上。

4. 实操工作流：从Prompt到可用模型的完整链路

4.1 我日常最顺手的三种用法

经过上百次测试，我总结出了目前text-to-cad在我工作中真正高频、有价值的三种用法，分享出来供你参考。

第一种是把text-to-cad当“快速草图”用。传统流程里，我们画概念草图是在纸上或CAD里拖线条；现在直接输入Prompt：“一个L型的工业支架，边长120mm和80mm，壁厚6mm，转角处带三角加强筋”，几分钟内拿到可以插入PPT汇报或发到微信群讨论的概念模型。它不用于生产，就是为了快速对齐团队认知、降低沟通成本。这个用途的实用价值被严重低估，实际上开会效率提升非常明显。

第二种是和3D打印配合做“快速样件验证”。比如我要设计一个树莓派外壳的电池仓卡扣，拿不准卡扣的倒扣量多少合适，旧的流程是画图、切片、打印、试装、改图，一轮至少半小时。现在我直接用text-to-cad生成三五个不同卡扣量（0.3mm/0.5mm/0.8mm）的方案，全打出来一个个试，省掉的是建模时间，保留的是物理验证环节。注意，text-to-cad生成的模型不一定壁厚均匀，打印前建议用Meshmixer之类的工具做个自动修复。

第三种是用来“逆向补全”历史模型。我们公司有一批老图纸，只有2D工程图，3D模型早丢了。我先用文字描述这些零件的结构，用text-to-cad生成一版3D模型，再把这版模型作为参照，在CAD里对着老图纸重新精确建模。这比从零开始对着2D图建模要轻松得多，因为至少你先有了空间结构和比例关系。

这三种用法的共同点：都不要求生成结果100%精确，都是拿生成结果当作“半成品”融入人类工作流。换句话说，现阶段指望它当“全自动设计员”是必然失望的，但当“高效率助理”确实经常真香。

4.2 一套能提高生成成功率的Prompt模板

既然它是AI，那你的Prompt质量就直接决定了输出质量。经过反复调优，我总结了一套在生成零件类模型时命中率比较高的Prompt模板，核心逻辑是“主体形状→关键尺寸→功能特征→工程约束”，按顺序写全。

示范一下：“一个旋转体的连接轴套，主体是直径35mm、高度50mm的圆柱体，中心有直径12mm的通孔，两端各有2mm的45度倒角，外壁一侧铣出一个宽10mm、深3mm的平面槽，材质是6061铝合金，用于电机输出轴和皮带轮的连接。”

这套写法的要点是，先给出最简单的主特征，再逐步追加细节。你会发现，如果你一开始就把所有细节全塞进去——“一个带倒角的、有槽的、有螺纹孔的、法兰连接的高40mm的轴套”——模型很容易迷失重点，生成一个不知道在干嘛的形状。主特征先行，细节递进，命中率高得多。

另外，单位一定要说清楚。当前大部分工具对单位敏感度不一，有的默认毫米，有的默认英寸，如果Prompt里不写单位，尺寸翻25.4倍的情况时有发生。我在所有Prompt里都会强制写“mm”，目前看下来是最稳妥的做法。

4.3 导出后必做的三件事

无论哪个工具，生成的模型导出后，我强烈建议你按以下三步走，踩过坑的人都知道这不是可选项而是必选项。

第一步是“几何体检”。把STL丢进Meshmixer或者Windows自带的3D Builder里检查有没有破洞、坏边、自相交面。生成式工具和代码生成式工具在这一步的表现差异很大：CadQuery生成的模型几乎永远是干净的B-rep边界表示，而网格生成工具则经常出现各种微小的拓扑瑕疵。好在这类自动修复工具已经非常成熟，一分钟能搞定95%的问题。

第二步是“尺寸标定”。生成模型时Prompt里写“直径50mm”，不代表实际模型真是50mm。网格生成类工具尤其容易出现比例漂移。我的做法是在CAD里量一遍关键尺寸，发现偏差超标就用缩放命令统一修正。这里要特别提醒：不要只查一个尺寸就完事，因为生成模型经常只在单一方向漂移（比如Z轴被拉长），必须X、Y、Z三个方向都量一下。

第三步是“壁厚检查”。很多text-to-cad生成的模型在屏幕上看很漂亮，但它是表面网格，内部是实心的还是空心的可能跟你预期不符。3D打印时这可能导致莫名其妙浪费材料，或者结构强度远低于设计预期。用切片软件（比如Cura）切一刀看填充，或者在CAD里做剖面视图检查，这个环节绝不能省。

5. 核心痛点与排查技巧：避坑实战

5.1 问题一：生成结果和描述完全“驴唇不对马嘴”

这是最让人抓狂的一类问题——你明明说的是“方形法兰”，结果出来一个圆形垫片。大多数时候问题出在Prompt歧义上，英文里“flange”这个词本身就同时有“法兰”和“凸缘”两个含义，如果描述不够具体，模型就会随机挑一个。

排查思路是先简化Prompt，只保留最关键的主特征词：“a square flange with 4 holes”，如果这一步输出正确，再逐句加特征，就能定位到是哪一个词导致了漂移。

另一个技巧是加对比性的限定语：“a rectangular plate, NOT round, with two rows of holes”，很多模型对这类否定式的限定效果显著。这与图像生成模型的行为高度一致——文本编码器对否定词的注意力权重更高。

5.2 问题二：生成过程报错或超时中断

使用云端text-to-cad工具时，生成到一半突然报“generation failed”或者卡在进度条上不动，这是我遇到频率最高的问题，尤其在模型比较复杂的时候。

实际上是因为云端算力资源是按请求动态分配的，高峰期长Prompt更容易被掐断。解决思路有三个：一是把Prompt拆短，先只生成主体形状，成功后再单独生成细节特征自己拼装；二是避开欧美时区的白天高峰期（这些工具的服务器大多在海外）；三是确实复杂的模型，优先选择本地部署的开源模型，虽然效果略差，但至少不会断。

顺带说一句，别在浏览器里挂着下载大STL文件时去生成复杂模型，带宽挤占会导致上传/下载互卡的“假死”状态，我至少碰到过五次，全部发生在多线程下载场景下。

5.3 问题三：生成的模型尺寸标注和实际测量不一致

这个现象初看非常诡异：Prompt里写“内径40mm、外径60mm”，生成结果的“属性面板”里显示的也是这两个数字，但你导入CAD一量，发现实际是“内径39.2mm、外径59.6mm”。

根因在于网格离散化。生成模型时表面是SDF等值面提取出来的，提取精度受限于体素分辨率。打个比方：你在一张低分辨率照片里画一个圆，圆的边缘不可能完美精确，只能是被像素格“锯齿化”后的近似。对于需要精密配合的零件，这种误差是完全不可接受的。

解决思路分三档：对非配合面，直接用；对一般装配关系，在CAD里重建关键草图特征（反正有原模型做参考，画起来快）；对精密配合面，老老实实完全重建模型。务必清醒认识到：到目前为止，还没有任何一款主流text-to-cad工具能在输出端做到“标注公差级”的尺寸精确性，这是原理层面的限制，不是调参能解决的。

5.4 问题四：可编辑性和特征树质量问题

Fusion 360或SolidWorks导入text-to-cad生成的STEP文件后，你有没有遇到过“特征树完全不可用”的情况？打开一看，整个模型只是一个“导入特征”，没有拉伸、切除、倒角的历史步骤，你想改个孔的位置，对不起，没法直接改。

这是因为大部分纯生成式工具输出的是边界表示（B-rep）的孤岛几何，或者直接是网格，它们根本不含参数化历史记录。能编辑的唯一方式是把模型“还原”成参数化特征——Fusion 360里有个“Mesh to B-rep”和“Form”工具可以做一些重构，SolidWorks里也有“ScanTo3D”，但效果都比较勉强，复杂模型基本没法用。

这也是我前面为什么如此推崇CadQuery代码生成路线——它输出的是一段代码，代码本身就可以随时改。相比之下，Zoo这类工具虽然生成快，但在“可编辑性”这个维度上和前者完全不是一个量级。如果你拿模型是为了在不断迭代中调整设计，尽量选代码生成式的路线，这是目前实现“真参数化”推荐的路径。

6. 开源方案与本地部署：彻底脱离平台限制

6.1 目前值得折腾的开源模型

如果你因为数据安全要求不能用云端工具（不少企业有这条红线），或者就是喜欢自己掌控技术栈，本地部署开源text-to-cad模型是一条可行的路。当前社区活跃度最高的开源方案包括：

• Tex2CAD：南洋理工大学等机构发布的研究项目，利用LLM生成CAD脚本并执行，是早期最受关注的开源方案之一。
• CadQuery AI相关：社区有人基于HuggingFace上的CodeLlama，微调出专门生成CadQuery代码的模型，效果虽然没有商业工具惊艳，但完全免费。
• Blender+AI辅助工作流：严格说不是纯text-to-cad，但结合Blender Python API和本地LLM也能实现“文本到模型”的效果，胜在免费且灵活。

老实说，开源方案的生成质量比商业工具差一截，尤其对复杂曲面零件的处理普遍吃力。但在“能跑”和“干净”这两个维度上，开源方案没有黑盒行为，出问题完全可排查，这点反而是商业工具比不了的。

6.2 本地部署的硬件门槛与优化心得

本地部署text-to-cad的硬件门槛取决于你选哪条路线。如果只是跑文本到CadQuery代码的模型，一个8GB显存的显卡就足够，因为这类任务的瓶颈主要在于LLM推理，代码生成的token数不算多。如果你要跑体素扩散模型或SDF生成模型，显存需求就往16GB以上走了，我用RTX 4090跑体素模型，单次生成峰值显存占用在11GB左右。

跑过一次你会项目经验明显上来。我的优化心得就三条：一是别在Windows上硬跑，WSL2里面环境干净得多，依赖冲突少，很多开源项目直接给的是Linux安装脚本；二是模型尽量用量化版（如GGUF格式），精度损失肉眼几乎不可见，但显存压力骤降；三是Batch Size不要图大，text-to-cad这类生成任务不是渲染，并发请求只会让显卡显存一路爆红，单次一个请求最稳。

本地部署还有一个隐性的好处：你可以自己微调模型。用你们公司过去几年积累的零件库和命名规则做增量训练，让模型越来越懂“你们的语言体系”。比如我测试过，让模型学习“我们公司管这种带防尘罩的轴承座叫‘护套座’”之后，再输入“按护套座标准做一个”，生成的准确率立刻上了一个台阶。这是云端公共模型无论如何做不到的。

7. 局限性与未来：它不会取代工程师，但会重塑工作方式

7.1 四个暂时绕不过去的天花板

踩坑踩多了，我对text-to-cad的局限性有了非常清醒的认知。第一是装配体和运动机构，目前生成式工具只能生成单零件，涉及多个零件配合、相对运动、装配约束时，模型基本无能为力。第二是工程计算和仿真，生成模型不内置力学验证，不知道应力分布、不校验干涉，它“画得出”不等于“造得出”。

第三是精度公差和标准件体系，目前生成尺寸只能接近描述值，达不到图纸公差和国标要求，GB标准下的螺纹、轴承配合等也基本是外行水平。第四是复杂曲面造型能力，你可以让它生成一个花瓶，但让它生成一个符合A级曲面光顺要求的汽车外板件，结果离可用状态差得还非常远。

这四条天花板都是原理层面的瓶颈，不是升级一版模型就能解决的。指望text-to-cad短期内完全替代工程师是不现实的。但反过来看，把工程师从重复建模、改图、格式转换这类低价值劳动中解放出来，恰恰是它最擅长的事。

7.2 未来三年值得关注的演进方向

我的预判是这样的：第一，多模态输入会成为标配。现在的入口只有文本，很快会进化到“文本+参考图+手绘草图”的混合输入。你画一个潦草的草图，配合一句“这里的孔距改成20”，它就能在这个基础上生成正式模型，这会大幅降低沟通成本。

第二，CAD原生大模型会出现。目前还在“大模型生成脚本”或“大模型生成网格”的阶段，真正的CAD原生大模型应该是直接在B-rep空间里做生成，输出的直接就是有完整特征历史的实体模型。一旦这个突破实现，text-to-cad才真正到了可以大规模进入工程流程的临界点。

第三，生成式设计与仿真会融合。大模型不再只生成几何，而是同时给出材料、工艺和力学性能建议——你说“承受3kN弯矩的L型支架”，它会自动选材并生成一版初步满足静力要求的模型，把生成和验证放在同一个循环里。目前已经有研究机构在做这类“智能拓扑优化+文本控制”方向的尝试，相信不久会有产品落地。

第四，垂直领域的小模型会大量涌现。“通用text-to-cad”注定做不深，但“针对卫浴管道接头的text-to-cad”或者“针对3D打印铰链的text-to-cad”这类垂直小模型，会以极低的微调成本在细分行业快速落地，效果反而比通用大模型好得多。这个方向很值得行业从业者重点关注，甚至可以考虑自己用开源模型微调。

8. 我的最终建议：今天就可以上手的行动清单

写了这么多，该给个落地收尾了。如果你今天看完这篇文章，决定“我也试试”，那我建议你按下面的清单走：

第一，先不急着买任何付费工具。用Zoo的免费额度和开源的CadQuery AI方案各生成一个模型，感受一下“自然语言到CAD”的爽快感，也感受一下它的残缺感，建立第一手体感。

第二，选一个你日常工作里最“无聊”的零件作为测试样本——越简单越好，比如垫片、支架、挡板这类。用text-to-cad生成，再和传统建模对比一次耗时。你会惊讶于它在简单规则零件上的效率优势，也会直观感受到它的尺寸不准到底有多不准。

第三，当你确定要把它纳入工作流时，从“快速概念生成”这个场景切入先，不要一上来就试图用它交付生产图纸。让团队用它出方案、做沟通、提速讨论，等大家对它的脾气摸透了，再逐步往覆盖更深的环节推进。

第四，如果你所在的公司对数据安全有管控要求，尽早调研本地部署开源模型。开源模型的生成质量每月都在提升，半年后可能就达到足够日常使用的水平，那时候你已经跑在同行前面了。

最后说一句个人的真实感受吧。我用了十年CAD，从“鼠标点到手抽筋”到“一句话生成模型”，这种转变确实很奇妙。但它不是让你失业的东西，而是把你从“画图工”变成“真正的设计师”的杠杆。省下来的时间，与其焦虑，不如拿去琢磨结构怎么更合理、成本怎么更低、用户体验怎么更好——这些事，AI在很长一段时间里都替代不了你。