作为一个在机械设计行当里泡了十几年的老工程师我第一次听到 “text-to-cad” 这个词时其实是不太当回事的。原因很简单CAD 建模哪是输一句话就能搞定的里面藏着公差、基准、加工工艺这些 “只可意会” 的讲究。但等我真正上手试了一圈把开源方案、商业插件、研究框架都折腾了一遍之后我越来越觉得这个方向可能真的要改掉我们做设计的底层方式了。这篇博文就从一个工程师的实际视角出发聊聊 text-to-cad 到底在解决什么问题、背后有哪些技术路线、我用过的工具和方案以及想把它真正落进日常工作里需要避开哪些坑。1. 从三维建模痛点说起text-to-cad 为什么值得工程人关注1.1 传统 CAD 建模流程里的隐形损耗我先问你一个场景现在有一个安装底板的需求长 120 毫米、宽 80 毫米、厚 10 毫米四角倒 R8 圆角中心一个直径 12 的过孔四角再各来一个直径 6 的定位孔孔心距边 12 毫米。如果按传统流程来做你得打开 CAD 软件新建零件选基准面画草图标约束拉伸倒圆角再定位打孔……一套操作下来快的话也要五到十分钟慢一点还会在草图和约束上报错返工。这中间的损耗不只是“动手的十分钟”更关键的是需求语言到模型操作之间的翻译成本。设计者脑子里想的是一个功能清晰、位置明确的零件但 CAD 软件只认点、线、面、约束、特征。每一步操作都要从“工程意图”降维成“几何动作”这恰恰是最消耗精力、也最容易出错的地方。而 text-to-cad 想干的就是把这层翻译直接交给模型去做。1.2 text-to-cad 能做什么现阶段不能做什么先把预期管理做在前面。text-to-cad 并不是一个“万能的建模机器人”现阶段它能稳定发挥的范围大概是这样能生成参数化特征模型拉伸、旋转、打孔、倒角、阵列、镜像这类机械零件常见特征问题不大。能输出可编辑的模型文件比如 STEP、STL或者直接生成 CadQuery、OpenSCAD 脚本拿到手还能继续调。能快速试错改一句“孔直径改成 10”整个模型重新生成只需要几秒到几十秒特别适合概念方案阶段的反复推敲。但它还做不到全自动的复杂装配设计也做不了真正从零开始的“创新构型”。你要是让它“设计一个能承受 50 牛载荷的轻量化支架”它大概率只能给你一个形状合理的参考轮廓具体拓扑优化还得靠专业工具。所以我的判断是text-to-cad 更像一个“需求翻译器 快速建模器”它不是要取代设计工程师而是把工程师从重复画图中解放出来。1.3 和文生图、文生 3D 的本质差异很多人容易把 text-to-cad 和 text-to-3D 搞混我多说一句。text-to-image 或者说 text-to-3D 生成的是像素、网格、神经辐射场本质上是“长得像”的图像级结果拿去做 3D 打印预览、游戏资产、影视概念还行但工程上需要的是精确尺寸、特征树、加工语义。text-to-cad 追求的是另一件事生成的结果不仅“看起来对”而且尺寸精确到毫米级、特征是参数化的、模型是可以进 CAM 或者 CAE 流程的。打个比方text-to-3D 是让 AI 捏一团泥巴给你看个大概样子text-to-cad 是让 AI 直接写出工程图纸和数控程序。这两条路的难度、技术路线、评估标准都不一样工程场景里真正有落地价值的是后者。2. text-to-cad 的技术原理拆解模型到底在“画”什么2.1 三条主流技术路线这几年 text-to-cad 相关的工作不管论文也好、开源项目也好基本可以归到三条路线里。我在做方案选型的时候也习惯先用这三条线去框一下免得被各种宣传词带偏。路线一让大模型生成建模脚本。这是目前最成熟、也最容易工程化的一条路。思路很简单把 CadQuery、OpenSCAD 这类程序化建模工具的脚本作为“目标语言”用大模型把自然语言转换成一段可执行的建模脚本再由脚本驱动 CAD 内核生成实体模型。本质上这是一个“自然语言到代码”的任务但目标语言从通用的 Python/JavaScript 换成了带有几何语义的建模脚本。路线二扩散模型直接生成三维表示。这条路线和 AI 绘画的关系更近模型直接输出体素、点云、三角网格或者用一个隐式场来表示形状。好处是自由度高理论上能生成任意形状不需要像路线一那样把模型拆成特征序列。坏处也很明显生成出来的网格往往是“一团肉”尺寸标注、特征树、可编辑性基本都没法保证工程落地的价值大打折扣。路线三大模型驱动原生 CAD 引擎 API。这是最近一两年商业软件比较偏爱的一条路。大模型不直接生成脚本而是生成一系列高层调用比如“创建草图”“添加拉伸特征”“添加圆角特征”由软件内部的特征树机制去执行。和路线一相比这条路的生成结果和软件原生数据结构一致可编辑性最好但通常只能在特定软件生态内跑通用性弱一些。我做过一个简单的对比供你参考选型技术路线可编辑性尺寸精度生成速度工程可用度通用性LLM 生成建模脚本高高由内核保证中高高扩散模型生成网格低低较快低中LLM 驱动引擎 API最高高中最高低绑定软件2.2 为什么参数化脚本路线先跑出来了并不是说扩散模型那一路没有前途而是在工程场景里路线一和路线三有天然的优势模型的几何精度由 CAD 内核计算而不是由神经网络“猜”出来的。这句话很关键。你让大模型直接预测一个点云坐标它有概率误差可能偏个零点几毫米但你要是让它生成一段 CadQuery 脚本里面写着box(120, 80, 10)那最终生成的模型宽度就是精确的 120一分不差。另外生成脚本这件事大模型本来就擅长。过去几年大量代码训练数据已经把模型的“代码能力”喂得很强建模脚本和普通代码有很多共通之处等于站在了巨人的肩膀上。加上建模框架本身是确定性执行模型的“幻觉”最多表现为脚本语法错误、特征冲突不会表现为莫名其妙的几何体。这两层兜底让路线一的可用性远高于其他方案。2.3 训练数据从哪里来这是 text-to-cad 的核心命门你可能好奇这么多“文字到 CAD 模型”的对应关系训练数据哪来的答案是主要是“程序化合成”的。工业界和学术界常用的几个公开数据集比如 DeepCAD、ABC、Fusion 360 Gallery里面包含了数以十万计的 CAD 模型及其特征构造历史。研究者把每个模型的构造过程转成指令序列——先画什么草图、做什么拉伸、在哪个面上打孔、倒多大的圆角再把构造序列转成类似“代码”的文本。然后再用大模型做一个反方向的学习给一段自然语言需求生成对应指令序列。这里有一个很有意思的点真实场景里的自然语言需求和数据集里那种“标准”指令文本差距其实很大。同样一个“底板上开四个孔”有人会说“四角打孔”有人会说“均布四个螺丝孔”还有人会直接给孔距坐标。所以最近的研究重点已经从“能不能生成”转向了“能不能理解各种口语化、模糊化的需求描述”。这也是你实际用起来会发现模型时好时坏的核心原因之一。注意很多公开数据集里的模型是简化过的教学级零件真实工业零件往往有复杂的型面、公差标注、表面处理要求。这些信息在数据集里是缺失的也是当前 text-to-cad 的天花板所在。3. 工具与选型参考开源框架、本地部署和商业产品怎么挑3.1 开源路线自己组一套“穷鬼方案”如果你想低成本先把 text-to-cad 跑起来我强烈建议从开源路线入手。有两条很成熟的搭配。搭配一CadQuery 大模型。CadQuery 是一个基于 Python 的参数化建模库生成的模型可以导出 STEP/STL。你只需要让大模型写 CadQuery 脚本然后在本地执行就能得到实体模型。这个方案的优点是结果可编辑、可追溯和工业流程贴得最紧。搭配二OpenSCAD 大模型。OpenSCAD 本身就是纯代码建模语法简单直接大模型学起来更快适合快速验证想法。缺点是 OpenSCAD 的建模能力偏“程序化”做复杂曲面和混合特征比较吃力。模型这一层我个人实测下来用在线 API比如 GPT 系列、Claude 系列效果最稳因为代码能力确实更强如果你有数据隐私要求就部署本地模型比如 Qwen2.5-Coder、DeepSeek-Coder 这类开源模型配合 Ollama 或者 vLLM 跑在内部服务器上。本地模型在简单零件上表现不差但复杂零件或者模糊需求时指令跟随能力会差一截需要多试几次。3.2 商业产品和云服务的现状商业这边最近两年变化特别快。几家主流的 CAD 厂商都在推自己的 AI 辅助建模功能Fusion 360、Creo、Onshape 里都能看到类似“自然语言生成特征”的功能基本走的就是我前面说的“大模型驱动引擎 API”这条线。体验上比开源路线顺滑因为直接嵌在软件特征树里生成完还能继续用原生的修改操作去编辑。另外还有一些创业公司提供“文字→CAD 文件”的云 API直接把提示词发过去返回 STEP 文件下载链接。这类服务胜在省心不用搭环境、不用管模型但数据要出网对军工、医疗、汽车这类对数据安全敏感的行业基本不可接受。3.3 我的选型心得如果你问我自己会怎么选我的默认组合是本地部署的开源模型 CadQuery 离线脚本环境。原因有三点第一数据不出内网合规上主动第二生成的脚本完全可控我能审代码再执行不担心模型乱来第三成本稳定不用按次付费跑多少次都是那么多钱。我也理解很多人就是想快速试试水那直接用一个商业软件的 AI 功能或者在线 API 也无妨。重点是别一上来就追求“最优方案”先用最小成本跑通一个真实零件再根据痛点决定要不要自建。注意不管选哪条路一定留好“生成后人工审查”的环节。现阶段没有任何 text-to-cad 工具能做到 100% 可靠自动生成只是提升效率不能替代设计责任。4. 实操记录5 分钟跑通一个真实机械零件4.1 环境准备这里我以最典型的开源方案为例CadQuery 大模型跑一个安装底板。你这台电脑上需要装好 Python 3.10 以上版本然后装 CadQuery 库命令行执行pip install cadquery即可。大模型侧可以调用云 API也可以本地起一个 Ollama 服务。为了演示通用性我下面写的提示词和代码不管用哪种模型都能跑。要说一下为什么选 CadQuery 而不是 OpenSCAD安装底板的特征顺序比较典型——拉伸主体、倒圆角、打孔CadQuery 的链式写法非常顺手而且导出 STEP 的兼容性比 OpenSCAD 好得多。这个选择在工程上是比较稳妥的。4.2 写一条“像工程需求文档一样”的提示词我见过很多人用 text-to-cad 效果不好最核心的原因就是提示词写得太口语化。你想想平时你给新来的同事提需求也不会只说一句“帮我做个底板”对吧你得告诉他尺寸、孔位、倒角、基准。写提示词也是一样。下面这条提示词模板是我实际项目里提炼出来的你可以直接抄我需要设计一块安装底板具体要求如下 - 外形尺寸长 120mm宽 80mm厚 10mm - 四角倒圆角圆角半径 8mm - 中心位置有一个直径 12mm 的过孔通孔无螺纹 - 四角各有一个直径 6mm 的定位孔通孔孔心到相邻边缘的距离均为 12mm - 所有尺寸单位使用毫米 - 请使用 CadQuery 生成模型先创建底板主体再倒圆角最后打孔注意看我把单位、特征顺序、孔的类型、基准关系全部写清楚了。模型收到这样一份“需求单”犯错的概率会小很多。如果你能再补一句“坐标原点放在底面中心”那生成结果基本就八九不离十了。4.3 执行脚本从自然语言到实体模型接下来就是见证奇迹的时刻。把上面提示词发给大模型让它输出 CadQuery 代码。核心逻辑大概是下面这个样子我加了注释方便你读import cadquery as cq # 第一步创建底板主体120x80x10 base ( cq.Workplane(XY) .rect(120, 80) .extrude(10) ) # 第二步四角倒圆角 R8 base base.edges(|Z).fillet(8) # 第三步中心直径 12 过孔贯通 base ( base.faces(Z) .workplane() .hole(12) ) # 第四步四角直径 6 定位孔孔心距相邻边 12mm base ( base.faces(Z) .workplane() .pushPoints([ (-48, -28), (48, -28), (48, 28), (-48, 28) ]) .hole(6) ) cq.exporters.export(base, mounting_plate.step) cq.exporters.export(base, mounting_plate.stl)这段代码的逻辑很直白先用rect画矩形草图再extrude拉出 10 毫米厚的板edges(|Z)选中所有竖直棱边并倒 R8 圆角然后选择顶面打中心过孔最后用pushPoints一次性放置四个定位孔并通孔。最终导出 STEP 和 STL 两个格式后面渲染、做有限元分析或者直接拿去 3D 打印都方便。4.4 验证模型别急着当成品用模型生成完一定不要急着交付。我会再做两步验证。第一步用代码读一下包围盒尺寸bb base.val().BoundingBox() print(bb.xlen, bb.ylen, bb.zlen) # 期望输出120.0 80.0 10.0尺寸对了再打开一个支持 STEP 的查看器比如 FreeCAD 或者在线 CAD 查看器肉眼检查圆角和孔位是否和你的需求一致。这一步不是走形式而是防大模型“一本正经地出错”。我遇到过好几回代码逻辑看着没问题但圆角半径写错、孔位坐标差了一毫米靠人眼过一遍才能真正放心。5. 常见问题与排查技巧实录5.1 问题速查表我在折腾 text-to-cad 的这段时间里踩过的坑不少挑几个典型的整理成了速查表你碰到类似情况可以直接对照。现象可能原因解决办法生成代码跑出语法错误模型输出了不兼容的 API 写法在提示词里注明 CadQuery 版本或让模型先输出伪代码再转换尺寸整体偏大或偏小单位制混乱被当成英寸处理提示词里强调“单位毫米”并在验证步骤打印包围盒孔位镜像反了坐标系基准描述不清明确“坐标原点在底面中心”或者给出具体的坐标偏移圆角后孔没了特征顺序不对先打孔再倒圆角在提示词里指定特征顺序先主体再圆角最后打孔结果是一个实心方块打孔特征被跳过或生成失败检查代码中 faces(Z) 的选择是否正确必要时换用 workplane 定位5.2 把提示词当成工程需求文档来写我再强调一次提示词是 text-to-cad 里最值得花时间的部分。与其反复试不如第一次就把“需求文档”写完整。我的习惯是包含五个要素几何尺寸、空间位置、特征类型、单位、特征顺序。其中“特征顺序”最容易被忽略但偏偏很关键。因为同一个零件先倒角再打孔和先打孔再倒角在有些 CAD 内核里可能产生完全不同的拓扑结果。你让模型先按合理顺序构造再逐步加细节成功率会明显提高。另外如果你发现模型老是漏掉某个特征试试在提示词最后加一句“请对照需求逐项检查确认没有遗漏任何特征”。这一招对大多数大模型都有效相当于给它一个自查的钩子。5.3 一个价值很高的附加技巧让模型同时输出设计说明最后分享一个让我很受用的技巧。除了生成建模代码我还会要求模型同时输出一份简短的“设计说明”内容包括零件用途、关键尺寸清单、公差建议、可能的加工工艺。这一份说明文本看起来只是顺手生成的副产品实际用处非常大。它能帮你快速核对模型是否符合需求减少一条条数特征的功夫还能在交付给同事、客户时直接作为沟通材料更重要的是它能把模型的“隐性假设”显性化——比如“孔中心距边缘 12mm”这个尺寸如果和压铆螺母的安装空间冲突设计说明里能看到模型是怎么理解的及早发现问题。我在实际项目里已经养成了“代码 设计说明 人工复核”三件套的习惯。用 text-to-cad 不是让 AI 替我做决定而是让 AI 帮我把重复劳动干掉然后我把省下来的精力放在真正需要经验判断的地方。这套工作流跑顺之后概念阶段的结构设计效率确实提升了好几个量级。现阶段我一定会建议每个做设计的朋友都去体验一把不管最后用不用它理解这个工具的能力边界对未来只有好处。