刚看到方向时，我一度以为又是哪个大模型团队拿扩散模型做了个“文本生成3D模型”的demo——能出个带贴图的网格体，能转一圈看看热闹，但拉进工业软件里就完全没法用。直到我实际把生成结果导进Onshape打开，看到左侧特征树里整整齐齐排列着拉伸、切除、倒角这些可编辑特征，才反应过来：Text-to-CAD这条路走的不是“生成一张图”，而是“生成一套建模指令”，最后在CAD内核里重新执行，得到的是原生参数化模型，不是一张网格皮。

这个定位非常重要。Text-to-CAD解决的痛点，是所有在机械设计、结构设计里被“从零建模”拖住的人——早期概念评审要一个支架、一个外壳、一块安装板，传统做法是打开SolidWorks、新建草图、画线约束、拉伸切除，怎么也要十来分钟。现在把这些“萝卜白菜”的需求写成一两句话，让模型先出一版能改能调的实体，你再决定是微调还是推翻，整个工作流的前半段就完全变了。

它适合谁？机械工程师、结构设计师、硬件创业者、3D打印爱好者，以及所有被“开软件画草图”劝退的非专业人士。跟常见文本生成3D不同，Text-to-CAD的输出不是卖给渲染场景的，而是能进入真实制造链条的参数化实体文件。这个差异决定了它的玩法、边界和坑都不一样，所以值得单独写一篇来聊，而不是和文本转3D混在一锅里煮。

1. 从“提示词到参数化实体”这条线到底改了什么——先厘清text-to-cad的真实定位

Text-to-CAD，顾名思义是“文本描述直接转成CAD模型”。但它和大多数人在短视频里看到的“AI生成3D模型”完全是两个物种。你在那些demo里看到的AI生3D，通常是输入一句话，输出一个带贴图的三维网格，专门给游戏、影视、电商展示用的；Text-to-CAD输出的是工程软件能直接编辑的实体模型，改一个直径、加一个圆角、把孔位挪一下，都在CAD参数体系内完成，这就是“原生”二字的含义。

我第一次用这个方向的产品时，给了个很朴素的提示：“M3 hex nut with 5.5mm across flats, 2.4mm thick”。十几秒后右侧预览出现一个六角螺母，我顺手把它导入配套的云端CAD工作区，特征树里清楚显示“六边形草图 → 拉伸24mm → 中心孔拉伸切除”。那一刻我意识到，这不是“画了一张螺母的图”，这是“替我执行了一次完整的建模过程”。

下面把这条线的底层定位和实际玩法拆开讲。

1.1 文本生成3D那么多，为什么text-to-cad值得单独讲

文本生成3D领域其实已经很热闹了：扩散模型生成体素、NeRF重绘、多视图重建、点云生成，各有各的粉丝。但它们的共同特点是输出离散三角网格。网格适合渲染，适合放进游戏引擎，却极不适合做工程——没有参数，没有特征历史，改一个直径得动整个网格外壳，更别提直接出工程图、做干涉检查、跑有限元分析。

Text-to-CAD则走了另一条路线。可以粗浅地理解成：模型先把你的话翻译成一套CAD建模操作序列，再在真正的CAD内核里执行。所以输出的是带特征的实体模型，有草图、尺寸、特征树，跟你手动建模出来的文件是同构的。这个同构带来的直接好处是：模型可以后期编辑，尺寸可以改，倒角可以加，特征顺序可以调整，甚至能跟企业已有的参数化设计规范打通。

1.2 它生成的“原生CAD文件”到底意味着什么

我在试用阶段做过一个小测试：让它生成一个M3六角螺母，并指定对边直径和厚度。模型返回后，我把原始文件直接打开，在草图上改内切圆直径，整个实体跟着更新；再往里加一个同心孔特征，所有下游圆角自动重新计算。这个体验在普通文本生成3D里完全做不到，但在原生参数化文件里就是基本操作。

“原生”还意味着下游链条全通。STEP文件可以进CAM做刀路规划，Parasolid格式可以进SolidWorks无障碍，云平台生成的典型场景还能直接开在配套工作区里继续编辑。换句话说，它不是给你一张“零件照片”，而是把CAD工作的底层数据结构直接生成好了。这个差异决定了工具能不能融入真实产品研发流程——能改、能存、能走标准交换格式，才有资格谈“工业化”。

2. 它背后的模型是怎么“画”出可编辑CAD的：策略模型与强化学习的工作逻辑

如果你用惯了ChatGPT，可能会下意识认为Text-to-CAD就是个多模态大模型，把文本和形状映射到一起。其实不是。这类系统的核心，是拿“CAD建模指令”当语言来生成——模型不是在预测下一块网格，而是在预测下一步建模动作：画一条线、约束相切、拉伸到某个深度、加一个圆角。

这个设计选择相当关键。CAD模型本质上就是一条特征命令序列，像一段三维建模“代码”。既然像代码，就可以用处理序列的方式生成，而不用硬去预测每个顶点的坐标。于是模型的行为边界就清楚了：先起草图命令，再用拉伸、切除、旋转、阵列等特征命令覆盖后续，遇到复杂的自由曲线还能用样条来逼近。

2.1 生成的不是“图”，是“图纸意图”：从命令序列说起

如果你熟悉Onshape、SolidWorks、FreeCAD，你应该熟悉这套操作流：新建草图 → 画线画圆 → 添加几何约束 → 标注尺寸 → 拉伸 → 切除 → 倒角。所谓参数化建模，本质上就是执行的命令序列加参数形成的历史记录。Text-to-CAD把文本提示作为输入，然后生成这一整套命令序列。模型相当于一个“会讲命令的内核”，一边读你这句话，一边推测该怎么敲命令。

为了帮助你理解，抽象成一段伪代码：

sketch circle center=(0,0) radius=4 extrude depth=2.4 sketch circle center=(0,0) radius=2.5 cut through-all add fillet radius=0.5 on selected-edges

这段伪代码是六角螺母模型背后的特征骨架。模型最擅长做的事，就是按这种序列模式“续写”下去。这跟预测下一个网格顶点完全不同：网格顶点坐标是连续数值，轻微抖动造型就崩；预测下一个建模动作是离散选择，模型天然擅长“下一步做什么”这类游戏。再加上命令间有依赖关系，前一个特征会直接影响后一个特征能不能成立，这让整个生成过程更像写代码，而不是捏泥巴。

2.2 为什么必须用强化学习，而不是拿“文本+CAD”直接喂给大模型

有人会问：现在大模型能力这么强，直接用海量“文本+CAD”配对数据让它多模态学习不就行了？真正去做了才会发现，困难在于公开的文本-CAD配对数据太少，而且极度不均匀。大多数CAD模型文件里根本没有文字说明；网上能搜到的文字描述又往往含糊。纯监督学习很容易训练出一个“语法正确但几何废掉”的命令生成器，因为训练数据里缺少“做错了会怎样”的负例反馈。

强化学习在这件事里的作用，是让模型自己给自己造反馈。流程大致是这样：模型先生成一段命令序列，把命令扔进CAD内核去执行，内核返回是否成功、实体有没有自相交、特征有没有生效；再把这结果折算成奖励信号。成功构造出实体得正分，中途崩掉得负分，反复滚动训练，模型逐渐逼近“高成功率”的策略空间。需要注意，奖励不是“看起来像不像”，而是“在CAD内核里能不能真正把实体建模完成”。

类比一下AlphaGo：它不是靠背人类棋谱学会赢棋的，而是在不断对弈中自己发现“哪些走法能通向胜利”。Text-to-CAD的强化学习也是类似逻辑——让模型在参数化建模的天地里自己试出“哪些命令序列能让实体成立”。

2.3 训练数据哪来：程序化合成是这类项目的隐形底盘

那训练量从哪里来？公开资料显示，这类项目广泛采用程序化生成加批量推理的模式。团队写一套参数化零件生成脚本，把尺寸、孔位、倒角值做成随机参数，一次性批量生成大量互不相同但符合工程逻辑的零件，再把它们对应的建模命令序列拿去做预训练。这样做的好处是：训练数据量不受人工建模速度限制，且每个样本都自带完整特征命令，天然适合序列学习。

数据层面的另一条路子是从开源零件库反推。拿现成的STEP模型或者网格，逆向猜测它可能的草图步骤和特征顺序，再合成训练样本。不过这属于“临摹”，噪声大，只能当补充手段。理解了这个数据底色，你就能理解为什么它对“拉伸+打孔+倒角”这类特征组合特别有把握，而对自由曲面、多体装配极度陌生——没见过那么多复杂数据，喂不熟。

3. 真正上手：从浏览器到API，把text-to-cad接进现有工作流的实测路径

讲完原理，聊实操。我建议你直接找个入口试一遍。目前这个方向最有代表性的公开产品是Zoo团队做的“Text-to-CAD”，提供Web界面、API接口，也支持接主流CAD工作区。我第一次用就是在官网注册账号，把想法翻译成一句英文提示，敲进去，几秒钟后页面右侧出现一个带黄色草图线、蓝色实体高亮的3D预览；点一下按钮，还能直接跳到配套的云CAD环境里继续修改特征。

这一节把我实测过的完整上手路径拆出来，走一遍就知道坑在哪里。

3.1 浏览器端实测：从输入提示到拿到可编辑模型的完整路径

在Web端走通一次完整流程，基本是这六步：

1. 注册账号并登录。
2. 在文本框输入想要零件的特征描述。
3. 点击生成，等待十几秒到几十秒。
4. 在预览视口里旋转、缩放检查结果。
5. 选择“在CAD中打开”，跳到云端CAD工作区。
6. 或直接导出STEP文件，带进本地SolidWorks、FreeCAD等工具链。

我实测过的几类提示词，效果分化很明显：

• 结构明确、约束清晰的机械件，一次性成功率高：比如“a rectangular mounting plate, 80x60mm, 4mm thick, with 4 corner holes of 5mm diameter at 10mm from each edge”。
• 功能明确但缺少尺寸的，模型会猜测，只能当前期概念：比如“a smartphone stand with a bottom lip and a back support”，大概是底座加靠背的意思，模型能生成，但具体高低比例要人工再调。
• 涉及装配关系、多零件协作的，结果通常是一坨“形似神不似”的单体：比如“a drawer with four wheels”，它会把轮子焊死在抽屉体上，而不是生成四个独立零件。

浏览器端给我最大惊喜的是，生成结果不只是预览网格，很多能直接进云CAD工作区编辑。特征树里拉伸深度、草图约束都是现成的，改尺寸后所有下游特征自动重算。这意味着你可以把AI生成结果当成“第一版草稿”，而不是最终答案。

3.2 把text-to-cad接进代码工程：API调用与自动化批量生成

高级玩法是走API。手工在网页里输入，偶尔玩一玩可以；真要把它嵌入到项目流程里，就得让代码来调用。这类接口的调用姿势一般很常规：注册拿API Key，请求头带Bearer鉴权，POST一段文本提示词，后台异步执行，完成后返回结果。

我用curl做过一次最小化尝试：

curl -X POST \ -H "Authorization: Bearer $ZOO_API_KEY" \ -H "Content-Type: application/json" \ -d '{"prompt":"M3 hex nut with 5.5mm across flats, 2.4mm thick"}' \ https://api.zoo.dev/v1/alpha/cad/text-to-cad

第一次请求会拿到一个任务号，类似“task_xxxxxxxx”，然后再轮询查询状态；任务完成后，响应里往往带着预览数据入口和文件下载地址。这跟视频生成、图片生成API的异步架构是一样的，做工程的人都熟悉。

有了API，批量生成就可以自动化。我用Python写了个最简单循环：

import os import requests import time prompts = [ "spacer ring, inner diameter 10mm, outer diameter 20mm, thickness 3mm", "L-shaped mounting plate, two sets of holes, hole diameter 5.5mm", "rectangular enclosure, 100x60x30mm, with four M3 mounting bosses in corners", ] base_url = "https://api.zoo.dev/v1/alpha/cad/text-to-cad" headers = {"Authorization": "Bearer " + os.environ["ZOO_API_KEY"]} for prompt in prompts: resp = requests.post(base_url, headers=headers, json={"prompt": prompt}) task_id = resp.json().get("taskId") # 轮询任务状态，完成后下载 while True: status = requests.get( f"https://api.zoo.dev/v1/tasks/{task_id}", headers=headers ).json() if status.get("status") == "succeeded": download_url = status["result"]["downloadUrl"] # 拉取STEP文件，写入本地 break time.sleep(3)

把这段逻辑套进内部工具系统，就可以变成：需求清单 -> 自动生成概念模型 -> 保存STEP -> 交给下游工程师细化。这不是未来式，现在就能跑起来，而且对高频标准件特别划算。

3.3 不太容易注意到的工程细节：单位、约束、版本和交付格式

接口能跑通只是第一步，工程落地有几个细节我踩过，列出来供参考：

• 单位。提示词里尽量写“millimeter”或“mm”这类国际单位，别混用英寸、英尺，模型容易出现数值偏差。我习惯在提示词末尾固定加一句“dimensions in mm”。
• 约束。模型在生成布尔运算、圆角顺序时，偶尔会产生过约束或欠约束的情况。如果在CAD里发现草图变成蓝色欠定义但特征树又显示“已固定”，多半是模型偷懒直接给了固定约束，要手动检查。
• 版本。这类工具迭代快，同一个提示词可能隔一两周就出不同结果。做严肃项目时，导出文件后备份当时的模型或生成的任务ID，否则后面想复现同一个几何会非常麻烦。
• 交付。默认拿到的是可编辑文件，不附带完整工程图信息。下游如果是固定历史版本CAD内核，可能遇到版本兼容问题。最稳妥的交付格式还是STEP，属于中性交换格式，各家软件都认。

4. 哪些需求它能接住、哪些需求它会翻车：提示词设计与能力边界

写提示词和产品经理写需求文档有点像：需求越清晰，结果越可控。Text-to-CAD目前并不适合天马行空。给它一句“一个很酷的未来机器人”，它顶多拼出一堆毫无装配关系的简单几何体，很难产生真正有用的实体。

从实测和公开案例看，它最擅长的是结构明确、几何简单、特征可参数化的机械类零件：支架、螺母螺栓、垫片、接线盒、结构外壳、安装板、法兰、简单齿轮箱体外壳。这些大多由拉伸、旋转、阵列、圆角组成，而这些恰好是训练数据里最常见的命令。换成曲面放样、扫掠、抽壳、多体布尔，表现就开始掉队。

4.1 明确说清“是什么”，也要说清“尺寸是多少”：好提示词和坏提示词

一个有效的提示词，建议按三段式来组织：零件类型 + 关键尺寸 + 必要的孔、槽、倒角等细节。这么说有点抽象，对比例子最直观：

坏提示词：“一块能用螺丝固定在墙上的板，有几个孔。”

模型输出：一块板，孔数量随意，孔距随意，厚度随意。你事后在CAD里逐项修改的时间，可能已经超过自己重画的成本了。

好提示词：“A rectangular mounting plate, 80x60mm, 4mm thick, with 4 corner holes of 5mm diameter at 10mm from each edge.”

模型输出：尺寸明确，孔位明确，一次成形的概率非常高。省下的是“跟模型商量”的时间。

更进阶一点，把功能意图、层次约束都写进去：“a cable clip holder, two slots width 5mm, height 3mm, center distance 15mm， with mounting hole at both ends.”有了具体槽宽、间距、孔位，结果的可编辑度明显提高。模型不需要理解“为什么要这样设计”，但它能把你说出的每个数字都当成硬约束，尽量兼顾。

4.2 容易翻车的场景在哪里：有机造型、薄壁结构、装配一体化和核心公差

翻车最严重的场景，我归纳成四类：

第一类是有机曲面。茶杯、耳机、鼠标、玩偶这些自由曲面零件，CAD特征很难用一个草图拉伸搞定，需要的是放样、扫掠、曲面填充这类高阶命令。模型对雕塑式建模的掌握非常弱，生成结果通常是几个互相穿插的简单几何体，远看像，近看全是破绽。

第二类是薄壁抽壳。抽壳命令非常依赖前面特征的连续性和封闭性，一步出错后面全崩。模型经常把壳体厚度算错，或者干脆抽壳失败退回一个实心块。想生成一个带薄壁的手机壳，建议先把外形实体生成出来，再用CAD里的抽壳命令自己补一步，别指望模型一次性给你抽壳到位。

第三类是多体装配。提示词里写“一个包含4个零件的装置”，它通常给的是一个“看起来像由4个零件拼到一起”的单体，而不是真正分离的4个零件。装配关系、配合约束、自由度，这些概念目前不在它的能力范围内。它更擅长生成“单个实体的形状”，而不是“一套机构的设计”。

第四类是公差与工艺语义。前面提过，公差、表面粗糙度、材料热处理这些制造语义属于高级工程要求，不是模型输出重点。提示词里写了“±0.05mm”，它大概率只会当成数字噪声忽略掉。真要做精密制造，生成完必须进CAD重新标注所有的GD&T。

4.3 到了提效阶段，如何把“不可靠”变成可控流程

既然不可靠，就别让它当“决定者”，而是让它干“发散”的活。我的做法是：同一个需求写五个变体提示词，每个只改一个参数，比如板厚从3mm改到4mm、孔距从30mm改到25mm；生成五版结果，人工快速筛选一版最顺眼的，再进CAD细化。这个过程有点像设计师拿手绘草稿做快速头脑风暴，只不过现在草稿不再是白纸上的线条，而是有真实尺寸、能进CAD改的实体。

还有一个非常实用的小技巧：把复杂件拆成多个简单件分别生成，再在CAD里组装。模型对单一简单实体的把握大，对复杂联合体的把握小。宁可拆成四个任务、调四次API，也别把所有细节堆成一段“长城提示词”。拆分提示词，是当前阶段最实在的降错手段，没有之一。

5. 对建模流程的冲击与我的使用心得

聊点更宏观的：这项工具到底给建模流程带来了什么变化。很多人在讨论“AI会不会取代设计师”，我反而觉得，真正很快就会发生的是“建模入口被重写”。过去想从零得到一个CAD零件，方法是开软件画草图，现在多了一个入口：先打字，后修图。这个入口让“不会CAD软件”的人也能介入建模早期的探索，也让“会CAD但怕重复”的人省掉大量机械操作。

5.1 与OpenSCAD、CadQuery这些脚本建模完全不同的心智模型

我过去非常喜欢OpenSCAD、CadQuery这类程序化建模工具。它们的核心逻辑是“用代码描述几何”，再由内核执行出模型。这跟Text-to-CAD有个共同点——都不是手动拖拽界面，而是“描述转实体”。但差别也在那里：脚本建模的“描述”由你完全控制，写错一个参数，你清楚知道哪里错；Text-to-CAD的“描述”是自然语言，模型负责把它编译成可能的命令序列，你对最终几何形态的掌控弱一些，换来的却是“几乎不用学”的极低门槛。

所以它并不是要替代脚本建模，两者天然互补。我工作中出现频率最高的流程是：先用Text-to-CAD把概念形体用自然语言“塑”出来，下载成STEP，再导入CadQuery或者FreeCAD里做精确化处理。前面快，后面准；前面容忍随机，后面要求确定。这套组合拳，比我在任何一个单一工具里死磕都舒服。

5.2 我实测后的几个判断：它适合当“联想发散器”而不是“出图老师傅”

用了一段时间，我对这个工具在自己工作流里的定位越来越清楚，三条判断供参考：

一，适合快速探索。要求不高的支架、盒体、垫块，生成完直接导入项目，用来评估装配空间、走查干涉位置，效率远高于手动建模。这类“占位件”本来也不是最终交付物，AI生成的精度足够。

二，适合初始化特征历史。哪怕生成后要改一大堆，这个初始特征历史也比我从零开始画要省时间，尤其孔位、圆角这类重复操作，一次次重新干真的非常折磨人。有了初始特征，改起来就是点选、拖动、输入新数值，完全是CAD里熟悉的手感。

三，不适合直接交付。做高精度制造件、有限元参考件、需要完备图纸和GD&T标注的场合，文本生成结果只是起点，不是终点。谁把“生成即交付”当预期，谁就会失望。它的定位更准确地说，是CAD工作台边上那台“快速原型机”，负责出毛坯，不负责精品。

我最后分享一个小心得：把提示词沉淀成自己的“提示词库”。我现在维护了一套高频零件提示词，M3螺母、86接线盒、3030铝型材支架、各种垫片法兰，一整套标准化描述，再用脚本循环批量生成。整条链路跑顺之后，新项目报上来，先让AI把常用件变体生成出来，再由工程师手工校核。概念阶段的人力消耗整体降了一个量级，而且因为每个零件都有自己的特征历史，后续改版、复用、参数化变体都变得极其顺畅。

下一步我打算把这些生成结果接入内部的参数化零件库，跟产品BOM联动。到时候新项目一立项，BOM里那些常用件不再需要工程师逐个画，AI先生成参考模型，工程师只做确认和修错。这就是我对Text-to-CAD目前的真实体会：它不是一个放进新功能菜单里吃灰的玩具，而是一个还没完全定型、但已经能挤进生产流程的AI原生CAD入口。唯一要记住的是，AI负责联想，你负责判断；它是工作台上的一台快速原型机，真正出定型图纸的，还是你手上那些确认过、校验过、满足标准的细活。