都说 2024 年是“文生 3D”爆发的一年，但你要真拿那些网格模型去做机械设计，保准被工艺和生产环节兜头浇一盆冷水。我这里说的不是“文生三 D 出个雕像再贴图”的那种，而是 text-to-cad：把一段自然语言指令，直接变成能进仿真、能标公差、能出工程图的实体模型，也就是后缀是 .step、.brep 这类带边界表示的 CAD 文件。
这活儿看着跟 AIGC 沾边，其实技术栈完全是另一套逻辑。过去两三年我一直在折腾 CAD 自动化和程序化建模，从早期在 FreeCAD 里写 Python 宏，到后来试 DeepCAD 那些基于命令序列的生成模型，再到最近在本地搭文本转 CAD 的推理链路，踩过的坑能写满一页 A4 纸。这东西不是简单的“换了个格式输出”，它的难点在“几何精确性”，在“拓扑有效”，在“能不能被下游 CAM 软件识别”。这篇文章我不打算给你复述论文摘要，而是把我实际跑通、也实际翻车过的经验统统倒出来：text-to-cad 到底在解什么题、主流技术路线长什么样、我目前最推荐怎么上手，以及出了烂模型时怎么救。
先说结论：目前没有任何开源模型能做到“一句话直接出可加工零件”的成熟度，但你把它当作设计初期的概念生成器，配合参数化软件二次修正，已经能省下大量从零建模的时间。这篇文章适合机械设计从业者、3D 打印爱好者、以及想往 CAD 生成方向卷的算法工程师，我会尽量用大白话讲清楚里面的门道。
1. 别把 text-to-cad 当文生 3D：它到底在生成什么
1.1 网格是“壳”，CAD 是“实体数学”
很多人第一次听 text-to-cad 都会误以为这是文生 3D 的高配版，反正都是“给句话出一个三维模型”嘛。真不是。文生 3D 的主流输出是网格（mesh），本质是一堆三角形面片拼出来的外壳，面里面是空的，拓扑关系也不严谨。你拿去 3D 打印一个摆件没问题，但要是拿去做装配干涉检查、做有限元分析、做 CNC 加工，网格这东西立刻原形毕露：倒角对不上、厚度没法保证、圆孔不是真圆，CAM 软件根本没法生成连续的刀具路径。
CAD 模型则完全相反。它底层是边界表示（B-rep），也就是用精确的数学曲面和曲线去描述实体的面、边、顶点，以及它们之间的连接关系。一个带孔的法兰盘，在 CAD 内核里是“一个旋转体减去一个圆柱体”的布尔运算结果，而不是一堆三角面片的集合。这种表达天然支持测量、支持装配约束、支持加工仿真。text-to-cad 的目标，就是让模型直接产出这种“实体数学”，而不是“视觉壳子”。
所以我一直强调一个判断标准：看一个文本生成三维模型的项目是不是真 CAD，别听宣传，直接看输出后缀。如果只能吐 obj、glb、stl，那它是“文生网格”；如果能吐 step、brep，或者能返回一段可以被 Open CASCADE 这类内核直接重建的命令序列，那才算沾了 text-to-cad 的边。
1.2 为什么一句话生成实体比生成一张图难一个量级
生成图片的难点在像素分布的合理性，生成网格的难点在形状的视觉合理性，但生成 CAD 的难点在“处处精确”。我给你举个机械设计里最常见的例子：一根直径 20mm 的轴，一端开 M12 螺纹孔，另一端铣出 10mm 宽的扁位。这串描述里每一个尺寸都是有明确物理意义的，20mm 必须是 20.00，不能是 19.97 也不能是 20.03，否则跟轴承配合就会出问题。
更麻烦的是拓扑有效性。CAD 实体要求闭合、无自相交、无悬面、边和面的连接严格一致。就算生成器嘴上说得头头是道，最终重建出来一个面片法线乱飞、内部有隐藏碎面的“实体”，在 CAM 里照样报错。我可以负责任地告诉你，目前绝大多数 text-to-cad 模型，最容易翻车的地方恰恰就在拓扑有效性上。生成一个“看起来像”支架的模型并不难，难的是生成一个“能通过内核检查”的模型。
1.3 真实需求场景：概念设计、夹具、与教学实验
抛开技术，text-to-cad 真正能落地的场景其实比很多人想的窄，但也比很多人想的实用。
第一个是概念设计。产品工程师拿到需求时，脑子里其实已经有大致形状了，但手工建模一个初步方案通常要半小时以上。用 text-to-cad 出三五个粗糙的变体，挑一个顺眼的进软件细改，效率明显不一样。我实测下来，描述得越像“加工图”，生成结果越接近可用状态。
第二个是夹具和简单结构件。很多工厂的非标夹具结构高度套路化：一块底板、几个定位销、若干安装孔。这类零件数据在训练集里一大堆，生成器很容易输出基本可用的主体结构，人工只需要补几个关键公差。这反而是 text-to-cad 目前最让我惊喜的领域。
第三个是教学演示。给学生讲“拉伸-切除-倒角”这些基础特征时，直接用自然语言生成一个示例模型，比一步步画快得多，也更能让学生体会“特征”和“实体”之间的关系。当然这个场景对精度没什么要求，所以模型翻车了也不心疼。
2. 主流技术路线拆解：那些“能跑”的模型背后都是什么思路
2.1 序列化建模：把 CAD 当成一种“方言代码”来生成
目前学术界最主流、我实际用下来效果也最稳定的路线，是把 CAD 建模过程编码成一串 token 序列，然后用训练语言模型的方式去生成这串序列，最后再用几何内核把序列“编译”成实体。先不要被术语吓到，这个思路其实特别好理解。
你在 FreeCAD 里建模一个零件，本质上就是依次执行一堆命令：新建草图、画直线、加约束、拉伸、倒角、打孔。在 DeepCAD 这类模型之前，研究者发现如果把每一步操作连同参数全部记录成文本，那么整个建模过程就可以被当成一段程序代码来处理。模型学到的不是“法兰盘长什么样”，而是“建一个法兰盘需要执行哪些操作、每个操作的参数是多少”。推理的时候，模型输出一段操作序列，调起 Open CASCADE 之类的内核逐条执行，最后得到实体模型。
这个路线最大的优势是：输出天然是可编辑的，因为它保留了一棵特征树。你在软件里打开生成结果，仍然能改拉伸深度、改孔径，这跟直接生成一个死的 B-rep 完全是两个体验。我用 DeepCAD 跑过不少轴类零件，生成的效果相当能看，尤其是旋转体相关的结构，准确率明显高于其他类型。
它的劣势也明显。训练数据来自 CAD 建模文件的操作历史，而真实工业界的大量模型是从其他格式转过来的，根本没有历史操作记录，能用来训练的数据少得可怜。另外，模型生成的是离散命令，一旦某一步参数算错，比如拉伸距离变成负值，后面的特征全部白搭，编译直接失败。这跟写代码遇到运行时错误一模一样——你看着语法没问题，跑起来就崩。
2.2 LLM Agent + 工具调用：让大模型“亲手”写建模脚本
如果你不想训练自己的模型，还有一条更取巧的路线：用现成的大语言模型当调度器，让它自己写 Python 脚本，调用 FreeCAD 的 API 或者 CAD 软件的自动化接口去建模。这种方案本质上是把 text-to-cad 问题，转化成了 code generation 问题。
我试过的做法是：给大模型一段预设的 API 文档，告诉它“你只能调用这十来个函数，比如 create_box、add_cylinder、boolean_cut”，然后让它输出一份完整的建模脚本。模型不需要自己懂几何内核，它只需要把自然语言里的意图翻译成正确的函数调用序列。这个方法在简单零件上表现相当好，尤其是那种“底板 + 孔阵 + 支撑块”的零件，大模型见过太多类似代码，生成的脚本经常能一次跑通。
不过这种方法非常吃提示词设计。你得把 API 的边界、单位制、坐标系约定全部写清楚，模型才不会把毫米当成英寸、不会把旋转轴搞反。我在本地跑过一轮，发现模型在“数量多、重复性高”的特征上特别容易偷懒，比如让它生成六个均布孔，它可能只给你写三个就收工，或者干脆用整列特征，但阵列参数又算错。所以用这招务必在脚本外面套一个校验函数，查特征数量、查尺寸范围，别把裸输出直接丢给内核。
2.3 神经隐式场与扩散模型：像文生图一样生成“几何场”，再转 CAD
还有一类路线是把扩散模型那套玩法搬到 CAD 上：训练一个网络直接生成体素场或神经隐式场，然后再用一个可微的算法把场转换成网格或 B-rep 近似。这条路目前商业化产品最喜欢讲，因为它的生成结果“看起来”最自然，能出很多自由曲面造型，不像命令序列路线那么生硬。
但我要给想入坑的朋友泼冷水：这类方法做视觉展示可以，做工程交付还差得远。隐式场天然擅长表达连续光滑的形状，但在表达平面、圆柱面、球面这些精确解析曲面时非常吃力，而机械零件恰恰是这些解析曲面的天下。把场转成 B-rep 的过程也充满数值误差，转出来的模型经常出现微微扭曲的“假平面”，看着平滑，一测尺寸就开始飘。除非未来出现一种能从场里直接提取精确几何内核数据的方法，否则我只拿这类结果做视觉预览，不拿去做工程判断。
2.4 三种路线横向对比：从精度、可控性、易用性看
我把上面三条主流路线的实测感受整理成一张表，方便对照参考。
| 技术路线 | 代表思路 | 输出形式 | 几何精度 | 特征可编辑性 | 上手门槛 | 我实测的翻车点 |
|---|---|---|---|---|---|---|
| 序列化建模 | DeepCAD 和后续的 text-to-cad 变体 | 建模操作序列 / STEP | 高，取决于命令参数 | 强，保留特征树 | 中，需要跑推理环境 | 某一步参数错导致后面编译全崩 |
| LLM Agent 写脚本 | 用大模型生成 FreeCAD / 内核脚本 | 脚本 / STEP | 中高，取决于脚本质量 | 强，脚本即特征历史 | 低，只要会写提示词 | 特征数量漏加、阵列参数漂移 |
| 隐式场扩散 | 神经网络生成 SDF / 体素再转实体 | 网格 / 近似 B-rep | 低，数值误差明显 | 弱，转完就死 | 低，商业产品最常用 | 平面变波浪、圆孔变形、尺寸失准 |
强调一点：表格里的精度判断是基于我自己的测试环境，不同模型差异很大。如果你只是想给 3D 打印做个外观件，第三种路线完全够用；如果是正经机械设计，老老实实走前两种，并在下游做好几何检查。
3. 想把 text-to-cad 用在真实工程里？我建议这样操作
3.1 本地环境准备：FreeCAD 是性价比最高的“编译后端”
无论你用什么模型生成命令序列或脚本，最终几乎都需要一个能执行这些命令的 CAD 内核。商业软件的内核不开源，指望不了；Open CASCADE 是开元场里最强的几何内核，而 FreeCAD 把它包了一层友好的 Python API，所以我强烈建议把 FreeCAD 当作 text-to-cad 的默认后端。
具体准备不复杂：装一个 FreeCAD，把 Python 环境跟系统解释器打通。我比较推荐直接用 FreeCAD 自带的 Python 控制台跑脚本，省去一堆依赖编译的麻烦。如果你要处理大批量、自动化的验证，再额外装一个 pythonocc-core，它的底层 API 更贴近 Open CASCADE，适合做几何检查、布尔运算和 STEP 读写。我的环境就是 FreeCAD 起交互、pythonocc-core 做批处理，两者切换用同一个文件格式中转。
还有一个容易被忽略的细节：单位制。FreeCAD 默认毫米，但很多模型生成的脚本里面用的是米制或者英制，混着混着就是一个零件大出 25.4 倍。我建议在提示词里明确写“单位使用毫米”，并且在脚本执行完以后加一个全模型尺寸扫描，超过预期范围立刻报警，别等导入 CAM 才发现。
3.2 提示词写得好不好，直接决定模型下限
text-to-cad 模型对自然语言的理解能力比很多人想象中差，差的不是语言本身，而是“语言背后的工程约束”。你说“一个坚固的支架”，模型只能给你一个通用支架；你说“一个 L 形支架，底板长 80mm、宽 40mm、厚 5mm，竖板高 60mm、厚 4mm，底板上四个直径 6mm 的安装孔，孔心距边界 10mm”，生成结果立刻上一个台阶。
我把这类高可用提示词的常用句式整理成一套模板，你直接往里套就行：
- 一句话定主体：什么类型的零件、大概外形。
- 给关键尺寸：长、宽、高、厚度、孔径、孔距，一律带数字和单位。
- 明确特征类型：用“拉伸”“切除”“倒角”“阵列”这类建模动作描述，比用形容词描述更有效。
- 交代空间关系：哪个面朝上、孔在哪个平面上、对称轴是哪里。
- 最后加一句“所有单位默认为毫米，请忽略装饰性圆角”。
举个例子，我最近测试时用的一句提示是：“生成一个电机安装座，底板 100x60x8mm，四角有 5mm 倒角，四个直径 5.2mm 的安装孔均匀分布在 80x40mm 的矩形上，底板中央有一个直径 30mm、深 3mm 的圆形凹槽。”这个提示跑出来的结果，比我早期用“一个带凹槽的电机座”精细了不止一个数量级。不是模型变聪明了，是我把模型需要猜测的信息全都喂给了它。
3.3 生成之后，必须做的两步“体检”
任何 text-to-cad 模型的输出都不能直接进生产线，这是铁律。我做生成后处理，永远先跑两步：几何检查，和尺寸抽查。
几何检查用 Open CASCADE 的 shape analysis 工具，一次性检查实体是否封闭、有没有自相交、边数面数是否异常、体积是否为正。这一步能拦下八成“看起来正常，一加工就废”的模型。我见过太多模型在渲染窗口里完美无瑕，但一跑检测，边界表示里藏着几十个微小的退化面。
尺寸抽查更简单。把生成的 STEP 文件导入 FreeCAD，用测量工具量三到五个关键尺寸，跟提示词里的目标值对比，误差我一般允许 0.1mm 以内。这一步的成本只要两分钟，但能帮你在后续 CAM 编程前把比例错误、单位错误全部拦住。我踩过的最大一个坑就是单位问题，生成的轴直径 20 英寸而不是 20 毫米，渲染时因为视口缩放没注意，直接导进车床程序，还好在模拟阶段发现了。
4. 踩坑实录：为什么生成的 STEP 文件老出问题
4.1 编译失败与空实体：模型的“运行时错误”
序列化建模路线的模型最常出的问题，是生成的命令序列在编译阶段直接失败。原因五花八门：拉伸距离超出了草图平面的范围、布尔运算选择了两个不相交的实体、倒角半径大于边本身长度。这些问题有一个共同特征：语言模型对“几何可行性”完全没有概念，它在训练时只学过命令的文本分布，没学过几何内核的执行规则。
我最初的应对方式很笨，把失败的命令序列丢回去让模型重新生成，但成功率堪忧。后来学乖了：在提示词里刻意限制特征数量，把要生成的实体控制在二三十个操作以内；同时把模型输出的序列做一次预处理，凡是超出合理范围的数值全部截断到预设上下限。简而言之，别让模型自己放飞参数，你替它设好安全围栏。
4.2 拓扑有效但几何变形的“隐形损坏”
比编译失败更恶心的是“编译过了，实体也有，但形状就是不对”。正常情况是平面变成了微微扭曲的曲面、圆柱面变成了椭圆锥面，肉眼在模型旋转时根本看不出异常，测量出来却差了 0.3mm 以上。这个问题多发于隐式场路线，少见于命令序列路线，因为命令序列的参数只要没错，重建出来的解析面就是精确的。
遇到这类问题，第一反应应该是查导出格式。有些模型内部处理精度不够，导出 STEP 时把曲面离散成了样条逼近。解决办法是换一个导出精度更高的内核，或者在建模阶段改用更基础的解析面操作。命令序列路线天然免疫这个问题，这也是我始终最看好它的原因。
4.3 漏特征与阵列偷懒：大模型的老毛病
如果你用 LLM Agent 那条路让大模型写脚本，很容易碰到“漏特征”问题。比如让它生成四个螺纹孔，它可能只生成三个，然后振振有词地说“第四个与第三个对称”。这种现象在语言模型里非常普遍，本质是它在模仿人类“懒人式表达”，而不是在真算特征位置。
我的防范手段是建立“特征计数清单”。生成脚本之前，先把提示词里所有带数量的特征列出来，比如“四个孔”“两排散热片”“三处倒角”，然后在脚本末尾加一个断言函数，逐个核对数量。数量不对直接抛异常，根本不给它蒙混过关的机会。这个方法听起来简单，但真的救了我无数次。
4.4 格式与版本：STEP 也有“水土不服”
最后提醒一个很多人不知道的坑：STEP 文件本身有多个版本和多种实现，不同 CAD 软件对不同版本的支持程度不一样。Open CASCADE 导出的 STEP 在 SolidWorks 里打开没问题，但到了某个特定版本的 Fusion 360 里可能丢颜色、丢图层，甚至部分曲面被自动修复掉。我一般是导出 AP214 格式，它在兼容性上表现最稳。如果你发现导入后模型自动变了个样，别急着怪生成模型，先换一个 STEP 版本试试。
这里我把实际排查的经历整理成一张快捷表，方便你照着查。
| 异常现象 | 高概率原因 | 推荐排查动作 |
|---|---|---|
| 生成后编译直接报错 | 命令序列中参数越界 | 截断参数范围，减少特征数量 |
| 能导入但无法选中实体内部 | 边界表示有退化面 | 跑 shape analysis，用内核工具修复 |
| 尺寸比提示词大 25.4 倍 | 单位制混用 | 重跑前统一毫米单位，做尺寸冒烟测试 |
| 漏特征、数量对不上 | 大模型“偷懒” | 脚本末尾加特征计数断言 |
| 导入软件后变形 | STEP 版本兼容问题 | 改用 AP214，检查软件修复选项 |
5. 一些系统上的经验体会
text-to-cad 这个方向，真正的进化速度非常快，今天跑起来还很费劲的环节，可能三个月后就变成常识了。但我始终觉得，理解这类工具的使用边界比追新模型更重要。以目前的技术状态，把文本生成的模型直接当作最终加工模型是危险的，但是把它当作“可快速迭代的草稿”，配合参数化软件做二次调整，价值能立刻体现出来。
我个人的工作习惯是，把 text-to-cad 生成的 STEP 文件看作一种“带误差的初始装配”，进入 FreeCAD 之后先解除它的参数化关联，重新建立我自己能够控制的特征树。说白了：模型负责把抽象描述变成一个有形的几何体，真正的工程决策还得靠人。我试过完全信任生成结果，结果就是交期压力最大的时候翻车翻得最狠。
另外一个小经验是，同一个提示词可以多生成几个候选，把它们排成一排对比，比反复调一个提示词效率高得多。模型有随机性，十个结果里通常有一两个特别接近可用状态，剩下九个就当噪声。与其跟单个结果死磕，不如批量生成、批量筛选。这个思路在我在处理标准件库扩容时尤其好用——一口气生成 20 个简单结构件，挑出可用的入库，速度远超手工建模。
往后我准备把 text-to-cad 的验证流程再往前推一步，不仅检查几何，还要在生成的模型上直接跑简单的静力学仿真，筛掉那些“几何正确但结构弱智”的设计。毕竟，CAD 最终服务于制造，能生成一个形状只是第一步，能生成一个真正扛得住工况的零件，才是这个方向真正值得期待的未来。
