搞懂 text-to-cad：为什么“AI 一句话直接出工程图纸”这件事，比你想的难得多
最近大半年，我在各种 3D 打印和机械设计社群里被问得最多的话题，已经从“哪个渲染器好用”变成了“能不能用 AI 直接根据文字生成 CAD 模型”。我自己也连续试了不少工具，从在线 Demo 到本地开源模型都折腾过一轮。先说结论：这类 text-to-cad 的技术确实已经走出实验室，但它的“好用程度”被短视频严重高估了。它能很流畅地帮你生成一块带孔的板、一个齿轮外壳、一个支架，但离“替工程师画完整装配图”还差着好几个版本。
这篇文章不打算给你堆砌论文名词，我会把 text-to-cad 目前在做什么、背后有哪几条主流技术路线、哪些资源真的能跑、我自己实测时踩过的坑，以及最关键的——你在什么场景下该用它、什么场景下千万别用，一次讲清楚。适合正在做设计自动化探索的工程师、想给产品加 AI 建模功能的开发者，以及纯粹想搞清楚“这玩意儿到底是不是噱头”的人。
1. text-to-cad 到底在解决什么问题：从“看图说话”到“听着干活”
很多非工程背景的人觉得“用文字生成 3D 模型”不是早就有吗？像文生图工具生成一个“像机器人一样的东西”也能转成 3D 网格。但如果你真做机械设计、结构设计或者 3D 打印模型修复，就会明白这两件事差着十万八千里。
1.1 “能看的模型”和“能用的模型”是两种东西
文生图工具、甚至很多 AI 3D 生成模型，输出的一般是体素、点云或者三角网格（mesh）。这类模型看起来像那么回事，但放进 CAD 软件里就废了——因为它是“一张蒙着皮的雕塑”，不是“一张标满尺寸的图纸”。你没有办法在网格模型上直接改一个孔的直径，也没办法让某个面和一个基准面保持平行，更没法把它扔进 CAM 软件里生成刀路。
这里要引入一个关键背景知识：真正用于工程设计的 CAD 模型，主流表达方式是边界表示（B-Rep），也就是用精确的几何面、边、顶点，以及它们之间的拓扑关系来描述实体。更核心的是，现代参数化 CAD 软件会保留一份“特征树”，比如你先后做了什么草图、拉伸、倒角、阵列，这些操作像履历一样记录在模型里。设计人员拿到模型后要改尺寸，改的是参数，而不是直接拖拽顶点。
所以 text-to-cad 要解决的真正问题，不是“生成一个像样的三维形状”，而是“从自然语言直接生成一套带特征历史、可参数化编辑、符合工程语义的 CAD 模型”。这是它和普通 AI 3D 生成最本质的区别。
1.2 传统建模流程的门槛到底高在哪
一个传统设计师接到“帮我画一个 100 x 50 x 20 毫米的矩形板，四角圆角 R5，中间开四个直径 6 的螺丝孔，孔心距边缘 10 毫米”这样的需求，他脑子里的处理流程是：先建草图，画矩形，标注尺寸约束；拉伸成实体；倒角；在草图上画四个孔；拉伸切除。整个过程需要熟悉软件操作、掌握草图约束逻辑、理解特征顺序，新手可能折腾半小时，老手五分钟。
text-to-cad 的野心，就是把上面这段“人话”直接变成特征树和参数。你说一句“创建 100x50x20 的板，四角 R5 圆角，中心对称开四个 M6 通孔，孔距边缘 10”，系统直接吐出一个参数化模型，打开就能继续编辑。这件事之所以难，是因为自然语言有歧义、有省略、有隐藏约束，而 CAD 模型要求的是精确的、无歧义的几何拓扑。把一连串模糊的话翻译成一套确定性的建模命令，本质上是一个“结构化生成”问题，比翻译文章难得多。
1.3 text-to-cad 的最小工作闭环应该是什么样
我理解一个合格的 text-to-cad 系统，至少应该包含四步：理解用户描述中的构件语义和空间关系；生成对应的建模命令序列；在软件内核里重建出实体模型；把参数和特征历史完整保留下来。如果缺了最后一步，那它只是个“一次性雕塑工具”，而不是“设计伙伴”。
你马上会看到，现阶段的 text-to-cad 工具在这四个环节上进展很不平衡。
2. 三条主流技术路线：代码生成、参数回归、多模态扩散
现在做 text-to-cad 的团队，基本是沿着三条路线在走。每条路线都有各自的优势和死穴，我先画个表格对比，再逐个展开。
| 技术路线 | 核心思路 | 输出形式 | 代表性方向 | 优点 | 主要瓶颈 |
|---|---|---|---|---|---|
| 代码生成路线 | 让大语言模型写建模脚本 | Python 脚本 / SCAD 代码 / 宏命令 | 基于 LLM 的 CAD 代码生成 | 可编辑性强，可解释，直接进现有软件 | 生成代码可能有语法错误、逻辑幻觉 |
| 参数序列回归路线 | 把建模操作编码成 token 序列，交给模型预测 | CAD 操作序列（如 sketch、extrude、fillet） | DeepCAD 系列、Text2CAD 论文思路 | 符合 CAD 特征树语义，专业性强 | 依赖专用数据，复杂模型效果一般 |
| 多模态扩散路线 | 用扩散模型直接生成几何体表达 | B-Rep 参数、隐式场、网格 | 神经 CAD 生成、3D 扩散模型 | 几何形状表现力强 | 可编辑性差，难以保证工程拓扑有效 |
2.1 路线一：让大语言模型直接“写图纸”——代码生成路线
这是我个人最看好、也是目前最“可落地”的一条路。它思路很朴素：既然通用大语言模型已经会写 Python、C++，而 FreeCAD、OpenSCAD、AutoCAD 这类软件都支持脚本化建模，那能不能让模型直接生成一个建模脚本？用户跑完脚本，就得到模型。
实际操作中，这条路线跑得通的原因有两点。第一，建模脚本本质上是带强语法规则的代码，大语言模型生成代码的能力已经有目共睹。第二，脚本天然是文本，不需要额外设计复杂的模型架构，你可以直接把“文字描述 + 建模脚本示例”喂给模型，做一个指令微调就能出效果。我见过的一个开源分支就是这么干的：把 FreeCAD 的 Python 接口文档和一批示例脚本整理成训练语料，用户输入“带六个孔的安装板”，模型输出一段 Python 脚本，运行后模型直接在软件里重建出来。
这条路线的问题也很明显。模型经常“想当然”地调一个不存在的函数；坐标系理解错乱；尺寸单位搞混；生成的特征顺序在几何上自洽但在制造上不合理。比如它在板上先打了孔，后做了圆角，结果圆角把孔口轮廓破坏了，这在特征树里是允许的，但实际加工时就会出现问题。不过这属于工程经验问题，可以通过多轮修正和约束注入来改善。
2.2 路线二：把建模过程当成语言来学——CAD 序列回归（最“正宗”的一条线）
如果你去看 DeepCAD 这类研究的思路，会发现它的做法更像“翻译”：先把大量已有 CAD 模型的构建历史拆解成有序的建模命令，比如“草图平面选哪个面 / 画什么线 / 拉伸多高 / 做个什么布尔运算”，把每一步操作变成一个 token，整条操作序列就是一句话。然后，用类似机器翻译的模型结构，学习从“几何结果”或者“文字需求”到“操作序列”的映射。
Text2CAD 那篇论文的做法就是在 DeepCAD 这类基础上，把自然语言文本和 CAD 命令序列配对，训练一个模型让文本能映射到命令序列。最后通过一个渲染器和建模内核，把序列变成实体模型。
这条路线的好处是，它的输出天然是特征树——因为它生成的每一步就是实际操作。模型学会的不仅是“画一个方块”，而是“用什么操作过程画出一个方块”。这意味着生成的模型是可编辑的参数化模型，和你手动建模得到的文件长一个样。这才是最符合“text-to-cad”这个概念的实现方式。
但它最大的限制，是训练数据。你需要海量的、带文本描述的 CAD 操作序列。真实工程模型的数据不仅稀疏，而且很多企业的模型出于知识产权考虑根本不会公开。所以目前公开的数据集，比如 DeepCAD 数据集和 Fusion 360 Gallery，主要来自教学案例、参数化模型库，覆盖面集中在机械零件，对自由曲面、钣金、焊接件这些工程上常见的下游领域覆盖很差。
另外，这类模型的序列长度很容易失控。一个稍微复杂一点的零件，操作序列可能就是几百上千个 token，模型生成长序列时非常容易“失忆”——前面画了个草图，生成后面的拉伸时忘了草图约束，结果特征树能执行，但几何体完全不是你想要的形状。我测试过一个类似模型，让它生成一个带加强筋的外壳，它给出来的特征树整整四十几步，看着很专业，但执行到一半就报错，因为某个参考边根本不存在。
2.3 路线三：用扩散模型直接“捏”出几何体——多模态扩散
前面两条路线本质上都在“理解建模过程”，而扩散模型路线想直接“理解形状”。它的做法是用扩散模型生成某种几何表达，比如点云、隐式场、甚至 B-Rep 的某种参数化表示。用户输入一句话，模型直接输出一个三维形状，再通过后处理把它转成 CAD 可编辑的格式。
这条路线的优势是表现力强，特别适合搞有机形态、概念设计、玩具外观，这些本来就难以用标准特征树表达的东西。Stable Diffusion 扩展出去做 3D 生成的玩法，很多是这条路子。你让它生成一个“像海豚一样的水龙头”，它真能给你整出个曲线优美的造型。
但问题恰恰出在“工程”二字上。扩散模型生成的几何体，普遍存在不封闭、自相交、面片密度不均匀的问题。转成 CAD 实体时，经常需要一堆修复操作。更重要的是，生成结果不具备特征历史，你拿到的是一坨几何，而不是一组可改的参数。对工程师来说，这就等于收到一张不能修改的三维照片，版权意义上的“参考图”。
由于这个方向偏离“CAD”的“可编辑参数化”核心太远，我把它排在最后。
2.4 我的选型判断：不要迷信“专业”，要看你的用途
如果你是要给自己的产品做“从文字到 3D 模型”的功能，我会建议优先考虑代码生成路线，因为它最容易接入现有软件生态，也最容易迭代修正——生成错了就让模型改代码，不需要去重构整个几何内核。如果你要做学术研究、想做“像 CAD 专家一样按步骤建模型”的助手，那序列回归路线更有深度。如果你只是想要一个概念模型帮助产品评审，扩散模型那条路可能更出效果。
3. 想复现 text-to-cad，先把手头这些数据集和工具整理明白
无论你打算做二次开发，还是单纯想自己玩一下 text-to-cad，有一件事绕不开：数据。文本到 CAD 的特殊之处在于，它不像文生图那样可以随便从互联网抓数据。我们需要的不仅是“模型文件”，还需要模型的“构建历史”和“文本描述”，三者缺一不可。
3.1 数据集现状：DeepCAD 也好、Fusion 360 Gallery 也好，都有自己的脾气
我最早接触的是 DeepCAD 数据集。它是从某个大型 CAD 模型社区爬取并清洗出来的，包含十几万个实体模型和对应的建模操作序列。每个样本都由一串命令组成，比如“平面选择、画圆、拉伸、添加圆柱、布尔合并……”。DeepCAD 解决的问题是“有了模型几何，怎么反推出它的历史步骤”，这本身就是一个难点。它的数据比较偏向机械加工特征，比如孔、轴、槽，这正是数控加工里最常见的东西，所以特别适合做“机械件 text-to-cad”的训练。
Fusion 360 Gallery 则是 Autodesk 研究团队放出来的，包含两万多个 Fusion 360 设计，每个设计都保留了完整的参数化历史。如果说 DeepCAD 更像“操作路径”，那 Fusion 360 Gallery 更像“参数化设计文件”。缺点是数量少，很多样本是学生作业或教学案例，复杂度不高。
还有 ABC 数据集，规模很大，号称有上百万个 B-Rep 模型，但它主要是从 STEP 文件里提取的纯几何信息，基本没有建模过程，也没有文本描述。用来做形状理解不错，用来做“text-to-cad 序列生成”就不太行了。
坦白说，text-to-cad 领域目前最大的瓶颈就是：缺乏一个大型的、标注好的“自然语言—建模过程”配对数据集。我见过几个团队的做法是，拿 CAD 命令序列倒推生成中文描述，比如“extrude 10mm”就生成“拉伸 10 毫米”，再用大语言模型把这些模板描述改写成自然流畅的句子。这能造出数量可观的训练对，但有一个问题：机器写的描述和设计师真实的说法差异很大。真实工程师可能会说“给我一个 3mm 的加强筋”，而不是“创建厚度为 3 毫米的凸台拉伸特征”。
3.2 开箱即用的工具和在线服务
如果你不想从头训练，现在有几类现成的东西可以用。
第一类是开源模型和 Notebook 教程。GitHub 上搜 “text-to-cad” 能看到好几个仓库，大多数是研究人员放出的训练代码和预训练权重，基于 LLaMA 或 CodeLlama 微调而成，训练数据通常是“自然语言 + FreeCAD/OpenSCAD 代码”的配对。这类模型体积不大，消费级显卡也能跑推理。缺点是没有统一封装，没有图形界面，你多半需要自己写一段调用脚本。
第二类是商业或半开放的 API。一些 3D 工具平台把 text-to-cad 封装成了 API，上传提示词就能拿回一个模型文件。这类服务通常集成了后处理修复，体验比开源模型稳定，但有免费额度限制，而且生成的模型编辑自由度要看供应商有没有把特征历史也导出来。我见过一个平台，导出的是带特征树的原生文件，另一个平台导出的却是已经“塌缩成实体”的 STEP，后者虽然也能用，但基本没法改参数了。
第三类是 CAD 软件内置的 AI 助手。主流 CAD 软件这两年的功能更新里，都在推“AI 辅助”能力。你在对话框里输入需求，软件自动生成特征步骤，或者自动完成重复性操作。这类助手更侧重交互协同，比如你选中一个面，让它生成垂直的支撑柱，而不是直接生成整个装配体，属于把 text-to-cad 理念部分落地到日常画图流程里。
3.3 关于“命令序列作为中介”的一个关键设计
在复现 Text2CAD 那类工作时，会涉及一个设计决策：到底让模型直接输出建模脚本，还是输出一个受约束的命令序列？
直接输出 Python/OpenSCAD 脚本的优点是灵活、人类可读、容易调试；缺点是不够稳。模型可能会调用不存在的 API，比如生成了FreeCAD.Sketch.addLine()这种虚构方法。而受约束的命令序列更像“把选项填在表格里”，比如指定“操作类型 = 拉伸”、“截面 = 圆”、“参数 = 直径 20”，模型自由度低，生成稳定程度高，但后期要写一个解析器把命令序列转成真正的 CAD 操作。
我自己的实验体验是：纯自由脚本适合生成“一次性原型”，约束序列适合做“产品级工具”。如果你要接进业务流程，我建议让模型输出结构化的 JSON 命令流，而不是裸代码。这样后续校验和人工修正都方便得多。
4. 一条能跑通的实操路径：从自然语言描述到可编辑 CAD 文件
讲完理论和资源，我们来点能直接上手的东西。为了不依赖某个特定云服务，我选了 FreeCAD 作为目标环境，因为它是免费的，并且有完整 Python API 和宏录制功能。下面是我在本地跑通的一个最小流程。
4.1 环境准备和选型建议
你需要准备的软件只有一个：FreeCAD，建议用较新的 0.21 或 1.0 版本。模型方面，有两种选择：如果你显存在 8GB 以上，可以跑一个开源微调模型；如果没有，直接调用大语言模型的接口也行。我这里用大语言模型接口做演示，因为生成质量相对稳定，也不需要折腾部署。
还有个很好用的技巧：让模型先“写代码”，你再把代码贴进 FreeCAD 的 Python 控制台执行。FreeCAD 宏录制的机制决定了代码和界面操作是高度对应的，只要代码对，模型就能出现在三维视图里。
4.2 提示词怎么写才能得到能用的模型
我试着用下面这段描述来测试，效果比随口说“给我一个板子”好得多：
创建一个长方体底板，长度 120 毫米，宽度 80 毫米，高度 10 毫米。在中心位置创建一个直径 30 毫米的通孔，孔轴线垂直于底板的上表面。创建四个直径 7 毫米的安装孔，位于四个角，孔心距边缘 8 毫米。最后对底板四条竖边添加 3 毫米的圆角。
注意关键信息点：尺寸、位置参照（“中心位置”“距边缘”）、特征类型（“通孔”“圆角”）。模型对这类结构化描述的理解准确率明显更高。如果你只说“一个壳子”“带孔的板”，模型生成的坐标和尺寸大概率是乱猜的。你甚至可以在描述里添加一句“所有尺寸以毫米为单位”，这句话能有效降低它把尺寸按英寸或像素处理的概率。
4.3 生成结果长什么样：一段可运行的 FreeCAD 脚本
大语言模型输出的内容经过我轻微整理后，大概是下面这个形态，你需要把它保存为 Python 文件或在 FreeCAD 控制台执行：
import FreeCAD as App import Part doc = App.newDocument("Text2CAD_Demo") # 底板 box = doc.addObject("Part::Box", "BasePlate") box.Length = 120 box.Width = 80 box.Height = 10 # 中心通孔 center_hole = doc.addObject("Part::Cylinder", "CenterHole") center_hole.Radius = 15 center_hole.Height = 30 center_hole.Placement = App.Placement( App.Vector(60, 40, 0), App.Rotation(App.Vector(1, 0, 0), 90) ) # 四个角的安装孔 for x, y in [(8, 8), (8, 72), (112, 8), (112, 72)]: hole = doc.addObject("Part::Cylinder", "MountHole") hole.Radius = 3.5 hole.Height = 30 hole.Placement = App.Placement( App.Vector(x, y, 0), App.Rotation(App.Vector(1, 0, 0), 90) ) # 布尔运算：挖除孔 fuse = doc.addObject("Part::MultiFuse", "FusedPlate") fuse.Shapes = [box, center_hole, doc.getObject("MountHole001"), doc.getObject("MountHole002"), doc.getObject("MountHole003"), doc.getObject("MountHole004")] doc.recompute()如果你直接把这段脚本丢进 FreeCAD，大概率能看到三个圆柱和一个长方体，但还没有真正“切削”出孔，因为Part::MultiFuse默认是合并，不是布尔求差。要让孔真正挖出来，需要改用Part::Cut，把圆柱作为“工具”去切割底板。很多模型最容易在“布尔方向”上犯错——它把挖孔做成了合并，结果模型变成一个带“凸起圆柱”的板子。
4.4 导入、校验以及把脚本变成可编辑特征
到了这一步，你可能会觉得“生成的模型和描述基本符合”。但别急着结束，真正关键的还在后面。
第一，检查特征树。如果脚本里每个圆柱都是独立特征，后续你想改孔的位置，直接改Placement里的坐标就行。如果模型把所有几何合并成一整个实体，那就完蛋了——你得到的只是一个不能编辑的“死模型”。所以拿到 AI 生成结果后，第一件事永远是看左侧的特征树，“有没有可编辑特征”是判断这个工具好坏的核心标准。
第二，手工修复。模型生成的代码里，布尔运算可能有误，坐标系可能偏移，圆角可能出现在错的边上。你需要像“改代码”一样去改这些参数，而不是像“雕刻”一样去拽点。这就是我强调代码生成路线的原因：至少你能改，扩散模型生成的东西你想改都没地方下手。
第三，导出格式。FreeCAD 可以导出 STEP 用于机械设计和 CAM，可以导出 STL 用于 3D 打印，也可以导出 SVG 用于激光切割。不同制造方式决定了你导出前要检查哪些方面。比如要 3D 打印，就要检查有没有悬空面；要 CNC 加工，就要检查有没有小于刀具半径的内角。
5. 实测中的坑与局限：为什么它还替代不了工程师
前几部分我确实给了不少正向描述，但如果你去亲手试一圈，很快就会碰到几个让人血压升高的时刻。这里把我踩过的坑集中列一下。
5.1 坐标系的“想当然”问题
text-to-cad 模型最大的通病之一，是坐标系理解混乱。你对它说“孔位于板中心”，它会找出一个看似合理但实际上完全跑偏的位置。原因是它没有真正理解三维空间，只是在靠文本和坐标之间的统计关联猜，碰到模糊表述时就会随机选择一个“看起来差不多”的答案。
我遇到过一次很典型的案例：让模型在“底面中心”打一个盲孔，它直接在顶面的中心打了孔，而且孔的轴线方向和预期完全相反。在 CAD 里，底面和顶面从几何上完全对称，但工程语义不同——底面通常指基准面，顶面指相对面。模型不理解这种“名词背后的工程常识”，这是自然语言界面绕不开的坎。
5.2 特征顺序和约束的“幻觉”
另一个坑是模型把特征顺序搞错。生成很多特征时，模型经常先创建孔、后创建临时基准面，结果临时基准面在最后一步被删掉，孔就悬空了。或者，它会把两个本应独立移动的特征做成一个关联约束，你动一个，另一个跟着跑。
这种东西历史很诡异：它可以造出“一看就很专业”的特征名称，比如Chamfer_For_Bolt、Boss_For_Cable，但实际几何往往不符合名字含义。这是不是意味着模型在“说谎”？我倒觉得更像它在训练数据里见过大量类似命名，于是按概率复现了这些名词，但并没有把这些名称和真正的功能绑定。
5.3 复杂曲面、装配体和图纸标准：三座大山
如果你把 text-to-cad 用到一个常见但稍微复杂一点的零件上，比如带弧形外观的手机外壳，或者一个由十几个零件组成的装配体，效果会迅速劣化。代码生成路线生成的脚本长度会爆炸，序列回归路线会直接“失忆”，扩散模型则会在可制造性上翻车。
此外，工程设计不只是生成几何体，还包括公差标注、表面粗糙度、基准符号、材料信息等。text-to-cad 现在能做的“模型”只代表几何形状，离“图纸”差的太远。而制造领域恰恰是靠图纸上的非几何信息来完成交付的。这一点经常被 AI 产品演示刻意忽略。
5.4 最常见的格式兼容问题：看着是 CAD，其实是“哑巴几何”
提到格式兼容，有一个隐蔽的大坑：有些 text-to-cad 工具为了让展示效果惊艳，会把模型输出成网格文件，然后用一个软件插件“伪装”成 CAD。你从文件后缀名看是 STEP，但模型内部根本没有参数化特征，只有一堆三角面。你想编辑某个尺寸，对不起，改不了。
判断方法很简单：在 CAD 软件里双击模型，看能不能弹出可编辑的尺寸参数；或者在特征树里看看有没有“拉伸”“旋转”“倒角”这类特征节点。如果一个 STEP 文件导入后，软件只是把它整体识别为一个“实体”，那基本可以断定这是“哑巴几何”，不是真正的参数化 CAD。这个判断方法，建议你收藏。
6. 我的判断与使用建议：在什么场景下值得用，什么场景下千万别用
回到最开始的问题：text-to-cad 到底是什么水平？我的结论是：它是个好用的“概念草图生成器”，也是个不错的“自动化助手原型”，但它现在的定位更像是一个“高水平实习生”，而不是“老工程师”。
6.1 真正适合用 text-to-cad 的场景
第一个比较适合的场景是概念设计阶段的快速探索。你心里大概有个想法，但还没想清楚具体尺寸时，可以让它快速生成几个候选造型，帮你找方向，节省大量起型的操作时间。哪怕生成结果不精确，也能给设计师提供灵感。
第二个适合的场景是标准件和参数化零件的批量生成。比如固定尺寸的安装板、密封垫圈、支架、线缆接头座，这些零件结构相对固定、参数少，text-to-cad 能可靠完成。我甚至觉得，如果能把产品里大部分标准件自动化掉，它能帮小型工作室省下大量重复劳动。
第三个适合的场景是非专业人士“自助出件”。比如创客想给自己的 Arduino 套件做个外壳，又不熟悉 CAD，用自然语言让 AI 生成一个带孔盒子，再导成 STL 去 3D 打印，这个闭环已经可以被 AI 很好地完成。
6.2 千万别指望它的场景
反过来，在以下场景里，我建议你保持警惕，别直接把它生成的模型甩给下游。
第一是精密机械加工。如果零件有严格公差、有配合关系、有加工工艺要求，AI 生成的几何完全不可信。它既不懂公差，也不懂加工顺序，更不懂刀具干涉。第二是关键结构件。涉及到受力分析、疲劳寿命、安全裕度的零件，AI 模型既没有计算力学支撑，也没有工程判断，直接用等于拿安全开玩笑。第三是任何需要交付正规图纸的项目。没有标注、没有标准视图、没有 BOM 的项目，光有三维模型无法支撑生产制造。
6.3 我的扩展方向建议：把 text-to-cad 当“模块”而不是“产品”
如果你问我在实际项目里会怎么用它，我的心态是：把它当作一条高效的“录入通道”，而不是“思考的大脑”。比如，让 AI 先把“语音描述”变成“参数表”，再由模板自动驱动 CAD 生成模型。这样既规避了 AI 对三维空间的薄弱理解，又把它的优势——快速提取信息、生成结构化参数——发挥了出来。
我还试过一种讲法，可能是未来的方向：AI 负责出方案，人类设计师负责定“设计意图”，再让 AI 根据设计意图去调整参数。比如你告诉它“这里的圆角将来可能要加大，你要保留特征树”，它会刻意在特征树里保留可编辑的圆角节点。这种“人提约束、AI查几何”的协作方式，比“甩一句话给 AI，等着拿现成模型”要靠谱得多。
最后再分享一个小技巧：如果你准备在团队里推广这类工具，不要一开始就追求“全自动产出装配体”，而是先从“单零件 + 固定模板 + 标准件库”做起，给 AI 画好边界。把边界定得越清楚，AI 给出来的东西就越可靠。以我自己实测几千个生成结果的经验来看，现阶段 text-to-cad 的价值不在“替代”，而在“压缩重复劳动”——谁能围绕它搭出一套可控的流程，谁就能在下一轮设计工具竞争里省下大量时间。
