Text-to-CAD 这个词最近在各个 3D 建模、AIGC 相关的社区里热度一直没降过但很多朋友对它的理解还停留在用一句话生成一个模型的层面。作为常年跟 CAD 打交道、也研究了不少 AI 生成方案的从业者我想把这条线上从原理到落地的整体情况好好拆一拆。这篇内容不堆术语尽量讲人话同时把该给的实操路径、工具清单、参数细节都补全适合所有想入局这个方向的建模工程师、产品设计师、创客以及没事喜欢折腾 AI 工具的技术爱好者。先说结论现在的 text-to-CAD 不是单纯靠一个魔法模型把文字变成模型文件背后其实是好几条技术路线在并行演进每条路线成熟度、适用场景、学习成本都不一样。你如果抱着装个软件就能一句话出零件图的期待来大概率会失望但如果你理解清楚它的底层逻辑配合好现有的 CAD 工作流这绝对是能把重复劳动压缩一个数量级的利器。1. Text-to-CAD 到底是什么为什么值得关注1.1 先分清文本转网格和文本转 CAD的本质区别很多人一听到 text-to-CAD想到的是以前那些文本转 3D 模型的工具比如输入一只戴帽子的猫然后生成一个三维网格模型Mesh。这类模型看起来像那么回事但你要把它导入 SolidWorks、Fusion 360 做装配、做仿真、出工程图基本是不可能的。为什么因为网格模型本质是一堆三角形面的集合没有参数化特征树没有草图约束没有拉伸、切除、圆角这些特征概念工程意义上不具备可编辑性。真正的 CAD 模型核心是特征树 参数化约束。你可以随时修改草图的尺寸模型自动更新你可以把一个零件的厚度从 2mm 改成 3mm装配体里的配合关系照样成立。text-to-CAD 要做的事情是让机器根据自然语言描述直接生成这种具有完整特征历史的参数化模型而不是生成一个长得像的外观壳子。这个区别决定了整个技术路线的选择。如果只是为了视觉预览、游戏资产、展示渲染那文本转网格就够了但如果目标是制造、装配、仿真、出图必须走文本转 CAD 这条路。1.2 为什么 2025 年这个方向突然爆火text-to-CAD 的热度不是凭空来的有几个直接的推力大语言模型的编程能力成熟CAD 建模本质可以理解为用代码描述几何操作而 LLM 最擅长的恰恰是代码生成。之前制约它的不是模型能力而是缺少把自然语言意图翻译成CAD 操作序列的中间层。参数化 CAD 脚本生态的完善CadQuery、OpenSCAD、FreeCAD 的 Python API 这几年质量越来越高尤其是 CadQuery 用起来非常顺手天然适合作为 LLM 的输出目标。大量公开的 3D 数据集自然语言标注ShapeNet、ABC、Fusion 360 Gallery 等数据集的积累让研究者有料可训。尤其是 Fusion 360 Gallery 数据集里面保留了完整的建模操作序列这是训顺序生成模型的黄金数据。硬件与算力不再是门槛单张消费级显卡就能微调中小尺寸的模型个人开发者也能参与这个方向的研究和实践。所以你现在看到的 text-to-CAD 产品大量都是LLM 当大脑 程序化建模库当手的组合。理解这条主干后面所有内容你都能轻松接上。2. 实现文本到 CAD 的核心技术路线盘点2.1 路线一LLM 直接生成 CAD 脚本当前最主流这条路线的基本逻辑是把 CAD 建模脚本比如 CadQuery 的 Python 代码、OpenSCAD 的 .scad 文件当作一种编程语言然后让大语言模型根据自然语言描述去写这段代码最后在本地环境里执行生成 B-rep 或 STEP/STL 文件。具体到实现又有两种子方式方式 A零样本/少样本提示Zero-shot / Few-shot Prompting直接用通用大模型 API 或开源模型在提示词里塞几段文本-代码样例让模型照着生成。优点是不需要训练上手快缺点是复杂几何的生成成功率不高模型对 CAD API 的掌握深度有限经常产生看起来合理但跑不通的代码。方式 B微调专用模型Fine-tuned Model研究界已经有团队用了这个方法比如 Text2CAD 论文就是基于 CodeLlama 或者类似的开源模型在自然语言指令 CadQuery 代码对上面做了指令微调instruction tuning。微调后的模型在零件生成任务上几何合理性和代码可执行率都大幅提升。我个人的判断是对于个人开发者或者小团队现阶段用方式 A 精心设计的提示词模板已经能覆盖很大一部分标准机械零件生成需求。方式 B 更像是工业界产品化的方向因为你要维护训练数据、验证集、评估管线成本高不少。2.2 路线二CAD 操作序列预测Seq2Seq这条路线不是生成代码而是预测一条 CAD 建模操作序列。什么意思你去 Fusion 360 里画一个零件其实经历了一串操作新建草图→画圆→拉伸→倒角→抽壳。这串操作如果按顺序记录成 token那 text-to-CAD 就转化成了从文本预测 token 序列的序列生成任务。代表工作就是基于 Fusion 360 Gallery 数据集训练的各种模型。这个数据集里包含了几万个真实零件的详细建模历史每个零件都记录了完整的操作树。模型训练出来后给定文本描述它逐个预测下一个操作最终重建整个特征树。这条路线的优点是生成的模型天然具备特征历史工程可用性极强缺点是数据获取难度大需要完整建模历史而不是只有最终模型而且推理过程较长对复杂零件容易在中间步骤产生误差累积。2.3 路线三多模态扩散模型直接生成几何扩散模型在图像生成领域大杀四方之后也有团队尝试把它用到 CAD 生成上。典型做法是把 CAD 模型的边界表示B-rep或体素表示融入扩散模型的去噪过程或者用点云作为中间表示。但在这里我必须泼一盆冷水扩散模型生成面向制造的参数化 CAD目前还非常不成熟。原因很简单CAD 模型有严格的拓扑约束和几何约束扩散模型擅长捕捉分布但并不天然理解一条边必须属于两个面一个实体必须封闭这种硬约束。因此这类方法目前的输出通常还需要后处理修复工程实用性不高。如果只是做概念设计的视觉探索这条路线也有一席之地你可以快速生成大量形态方向然后人工筛选再在 CAD 里重新建模。但凡是要求高精度、高可靠性的场景我还不太建议把这条路线作为主力。2.4 选路线的决策逻辑路线代表模型/系统输出形式工程可用性上手成本适用人群LLM 生成脚本GPT-4 CadQuery / Text2CADPython 脚本、STEP/STL中高低设计师、工程师、创客操作序列预测Fusion 360 Gallery 系列模型特征树/建模历史高高需训练工业软件厂商、研究团队扩散模型生成各类 text-to-3D 衍生工作Mesh / 隐式场低中概念设计、AI 研究者选哪条路线首先要看你的输出要拿去做什么。如果你只是想要能导进 CAD 继续编辑的模型选路线一就对了如果你是想做AI 原生的 CAD 建模软件那路线二和路线三都要深入研究。3. 实操基于 LLM 驱动 CadQuery 生成参数化 CAD 零件3.1 为什么我推荐 CadQuery 作为默认的模型之手在尝试了 OpenSCAD、FreeCAD 的 Python API、SolidWorks API、CadQuery 之后我个人做 text-to-CAD 实验时最顺手的是 CadQuery。原因有三第一CadQuery 是纯 Python写好脚本直接执行就有结果和 LLM 生成的代码天然同构这是最重要的。OpenSCAD 虽然是文本化建模的老牌工具但它的语法是自定义的LLM 训练语料里相对少见生成的语法错误率偏高。第二CadQuery 的建模原语非常干净默认坐标系是 Z 轴向上符合机械加工的直觉支持导入 STEP 格式方便和主流 CAD 软件互通。第三CadQuery 的构建顺序是从草图到特征的链式调用跟人类建模思维接近。比如下面这个一长串.cq()→.workplane()→.rect()→.extrude()的模式LLM 很容易模仿。顺带一提CadQuery 背后还集成了cq-editor这个可视化调试工具可以实时看模型变化排错效率极高。我做实验时基本是让 LLM 写 → 在 cq-editor 里跑 → 看报错 → 把报错喂回 LLM → 改代码这个循环非常顺手。3.2 环境配置五分钟搭好本地实验环境这一步很关键很多教程直接跳过环境配置结果新手卡在装库上。我直接把一套经过验证的流程放这里第一步创建 Python 虚拟环境python -m venv cad_env source cad_env/bin/activate # Windows 下是 cad_env\Scripts\activate第二步安装 CadQuery 和 Jupyterpip install cadquery jupyter如果你要可视化再装一个cq-plot或者直接用cq-editorpip install cq-editor安装完成后在终端输入cq-editor就能启动可视化界面。左侧写代码右侧看 3D 模型有报错直接定位到行号。第三步确认基本可用新建一个脚本跑通最最简单的模型import cadquery as cq result ( cq.Workplane(XY) .box(10, 20, 30) ) cq.exporters.export(result, test.step)跑完你会在目录下看到test.step文件用 FreeCAD 或者 Fusion 360 打开应该是一个 10×20×30 的长方体。到这一步环境就算通了。3.3 设计一套优质的提示词模板这里是我反复踩坑后总结出来的经验。直接丢一句话给 LLM给我生成一个法兰盘出来的代码大概率不理想。问题是模型不知道你要什么标准的法兰、几个孔、孔距多少、外径内径什么关系。所以提示词要当需求文档写信息密度越高生成成功率和准确性越高。我常用的模板分成四块任务定义明确你要生成一个 CadQuery Python 脚本用于创建 XXX 零件几何约束给出关键尺寸外径、内径、厚度、孔数、孔距等有公式的写公式建模顺序建议建议先画哪个草图、再执行哪个特征减少模型推理时瞎猜的概率输出要求要求代码可执行、变量命名清晰、导出 STEP 文件拿一个简单的带法兰的管接头举例你是一个 CadQuery 专家。请生成一个 CadQuery Python 脚本来构建一个带安装法兰的圆形管接头零件。 要求 1. 法兰外径 60mm内径 24mm厚度 8mm 2. 管身外径 30mm内径 24mm长度 40mm 3. 法兰上有 4 个均布的安装孔直径 6mm孔心所在圆直径 48mm 4. 法兰与管身一体成型沿 Z 轴方向法兰在底部 5. 请使用变量定义所有尺寸方便后续修改 6. 代码须可直接运行并导出 STEP 文件这段提示词丢给 GPT-4 或者 Claude生成成功率非常高。为什么因为你把描述意图压缩成了明确规格 模型擅长的代码生成任务模型的自由度小了准确性就大了。如果用的是开源模型比如 Qwen2.5-Coder 或 DeepSeek-Coder建议在提示词里再附一段 CadQuery 的hello world示例代码作为少样本参考效果会明显提升。这招我屡试不爽。3.4 完整案例从文本到 STEP 文件的实录为了让你看得更清楚我现在把一次完整的生成过程拆开来讲。目标零件一个带中心孔的底板要求长 100mm、宽 60mm、高 10mm四角有半径 5mm 的圆角中心有一个直径 20mm 的通孔。我用的提示词就是按上面模板写的。模型返回的代码大致如下import cadquery as cq # 定义尺寸 length 100.0 width 60.0 height 10.0 fillet_r 5.0 hole_d 20.0 result ( cq.Workplane(XY) .box(length, width, height) .edges(|Z) .fillet(fillet_r) .faces(Z) .workplane() .hole(hole_d) ) cq.exporters.export(result, base_plate.step)这段代码的核心逻辑拆解一下.box(length, width, height)创建一个以原点为中心的长方体Z 轴方向高度为height.edges(|Z)选择所有平行于 Z 轴的边也就是四条竖边.fillet(fillet_r)对选中的边做半径为 5mm 的圆角.faces(Z)选中顶面Z 方向的最大面.workplane()在这个面上创建新的工作平面.hole(hole_d)在原点位置打一个直径 20mm 的通孔自动贯穿执行这段代码后用cq-editor打开模型形状正确。再导出 STEP放到 SolidWorks 里打开特征虽然没有完整的草图-拉伸历史树因为是从 STEP 导入的但是几何完全精确可以基于它继续做后续设计。这一步实操下来你就明白了text-to-CAD 的核心价值不是一键出成品而是把重复性高的标准件生成从 10 分钟缩短到 10 秒。对于那些你画过一百遍的垫片、支架、法兰、底板你完全可以建立自己的提示词库以后直接复用。4. 工具选型与生态盘点4.1 主流 LLM 在 text-to-CAD 场景的表现我在同样的提示词下对比过几款主流 LLM 生成的 CadQuery 代码质量结论仅供参考因为模型更新快具体情况要以你实测为准模型代码可执行率几何正确率复杂零件表现备注GPT-4 / GPT-4o高高较好通用能力强提示词友好Claude 3.5 Sonnet高高较好长代码稳定性好DeepSeek-Coder中高中高中性价比高本地可部署Qwen2.5-Coder中高中高中中文理解好开源通用小型模型7B 级别低中低中差没有专门微调的话不太够用这里说的可执行率指的是代码跑完不报语法错误的概率几何正确率指的是跑出来的模型符合自然语言描述的关键尺寸约束的比例。两者差距很大的案例非常多代码能跑但生成的是一个完全不是你想要的形状。另外提醒一点如果你要用开源模型本地部署一定选代码模型而非通用对话模型。代码模型在训练语料里见过大量的 CadQuery/OpenSCAD 代码生成质量明显高一个档次。部署工具可以用 Ollama一句话就能启动ollama run qwen2.5-coder:14b14B 的量化版本在 16GB 显存的显卡上跑基本够用速度也还行。再小就是 7B 了作为实验玩玩可以但别指望它能稳定生成复杂零件。4.2 周边工具与项目实际动手前先看这些CadQuery核心建模库必学。cq-editorCAD 代码调试可视化必装。OpenSCAD另一个文本化建模工具适合程序员思维语法类似 C 语言也是 LLM 生成的良好目标。但它的 CSG 建模方式布尔运算组合和 CadQuery 的特征建模风格不同看你个人偏好。FreeCAD Python API如果你希望生成后保留完整的特征树而不只是 STEP 实体直接用 FreeCAD 的 Python 接口也是一个方向但目前 LLM 对 FreeCAD API 的掌握程度不如 CadQuery。Text2CAD 项目学术界代表性工作基于微调模型生成 CadQuery 代码值得关注它的论文和数据集设计方法。AutoGPT cadquery一些社区玩家把 text-to-CAD 做成了多智能体协作一个 agent 负责写代码一个 agent 负责检查代码一个 agent 负责执行和反馈。复杂零件的成功率会提高不少但资源消耗也大适合技术爱好者折腾。4.3 工程化时一定要考虑的后处理环节很多人拿到 STEP 文件就以为完事了事实上从 AI 生成的模型到可以直接加工或装配中间还差着几步后处理这也是新手最容易栽坑的地方。单位检查CadQuery 默认单位是毫米但某些模型输出可能是英寸或没有单位。导入 SolidWorks 前一定要确认 STEP 文件的单位设置否则一个 100mm 的零件会变成 100 英寸直接爆炸。几何修复AI 生成的代码偶尔会导致非流形non-manifold几何比如一个面被边穿透、两个面重叠但不合并等。建议在导入 CAD 后做一个检查实体操作SolidWorks 的输入诊断、Fusion 360 的修复及时发现问 题。特征转换可选如果你需要在 CAD 里大量修改这个零件最好用识别特征功能把 STEP 导入的实体转换成可编辑的特征树。Fusion 360 有直接编辑模式SolidWorks 有 FeatureWorks都可以做半自动化的特征识别。这是个深度话题简单说就是AI 生成的是结果不是过程真要改设计的时候还得靠参数化重建模。命名与归档建议把生成这个零件的提示词 代码 版本号一起归档我一般会在项目目录下建一个ai_generated子目录里面按零件名_日期_版本组织这样后面追溯设计意图会方便很多。AI 生成的内容也有设计意图只是这个意图是你用提示词定义的留档非常必要。5. 常见问题与排查技巧实录5.1 提示词写得很好但代码总是报错怎么办这是出现频率最高的问题。几个常见报错和对应处理No workplane found或Projected workplane is not on the face核心原因是模型在workplane()之前选择的面有问题。排查顺序是这样的先看是不是.faces(Z)这种选择器写错了方向再看是不是前一步布尔运算之后生成了多个实体或者碎面最后确认工作平面的法线方向。CadQuery 的工作平面选择逻辑其实很直观Z表示 Z 轴正方向最大面Z表示最小面。如果你想要顶面但模型代码里用了X那就完全不对了。Cant compute value due to multiple solids当你有多个实体时某些操作会无法执行。这时候一般是提示词没说清楚这些特征要建模在同一个实体上或者代码里用了多个.cq()链没有合并。解决方法是检查是否应该用.union()或者把多个特征写进同一条链式调用里。布尔运算失败Boolean operation failed这个问题很隐蔽。通常是因为两个实体有共面、共边或者几乎接触但不完全接触的情况CAD 内核OpenCASCADE对这类拓扑比较敏感。我的经验是让 LLM 把厚度尺寸稍微改大一点或者给提示词加上所有实体必须完全用参数关联不能有悬空的几何体之类的要求。还有一种办法是让模型放弃布尔运算改用多工作平面顺序建模。5.2 生成的模型尺寸对不上怎么看这种情况比代码报错更头疼因为代码跑通了你也看到了一个形状但外径、孔径就是和需求差了几个毫米。我建议用 CadQuery 内置的查询接口做自动验证import cadquery as cq # 假设 result 是你的模型 print(result.val().Volume()) print(result.val().BoundingBox())打印体积和包围盒可以快速核对。如果你要严格验证孔径可以用截面法或者用cq.occ_impl.shapes.Shape去查边。但说实话最实用的方法是把模型导出 STEP 后在 SolidWorks 里直接测量一步到位。与其事后验证不如事前约束。在提示词里要求将关键尺寸定义为变量并在代码最后打印所有关键变量值这样跑完代码成员一眼就能看到外径、内径、厚度等参数核对起来爽快多了。这个习惯我非常推荐甚至可以说这是 text-to-CAD 工作流中最重要的工程习惯之一。5.3 LLM 总是自由发挥不遵守尺寸约束这个问题也很典型。你明明写了外径 60mm它给你生成一个外径 50mm 的。根因在于 LLM 在生成代码时更多是模式匹配而不是严格按规格执行。它见过太多类似的法兰代码倾向于复用记忆里的典型值。对策是在提示词里加重强调 代码里加断言。前者好理解比如用你必须严格使用给定尺寸不能修改这种强约束表述有一定效果后者更可靠——让 LLM 在代码末尾加上assert断言# 尺寸验证 assert abs(result.val().BoundingBox().xlen - 60) 0.001, Width mismatch!如果模型生成的代码不符合尺寸脚本会直接报错你就能及时发现问题而不用等模型导出后再量。这个方式我强烈建议纳入你的常规提示词模板它能显著提高你发现问题的速度。5.4 本地开源模型生成的代码老是缺 import 或者多了没定义的变量小模型7B、14B 级别在生成较长的代码时经常漏掉 import 语句、变量名前后不一致、使用未定义的函数。原因是它们的上下文窗口和代码推理能力有限生成中途忘了开头写了什么。处理方案有三个第一把提示词模板里的参考代码片段压缩得再精简一点保证模型注意力集中第二在生成后做一个简单的代码静态检查可以用ast.parse()检查语法用python -m py_compile跑一遍第三写一个自动修复脚本把常见漏掉的 import 自动补上。不过说实话如果你对成功率有硬性要求直接用 API 调用强模型是目前最省心的选项。6. 应用场景、行业影响与下一步扩展6.1 哪些场景现在就能用起来第一个能立刻落地的是标准件库生成。机械设计中到处是垫片、法兰、支架、定位块这类标准特征零件。过去你要么翻标准库找要么自己画一张图纸可能一小时。现在建立一套提示词模板输入GB/T 97.1 垫圈规格 M8AI 直接生成对应 STEP 文件整个过程一分钟以内。虽然这些零件标准库本身就有但在企业内部非标定制场景下改孔径、改厚度这套流程的效率优势更加明显。第二个场景是概念设计的快速形态探索。工业设计师在做前期方案时常常想快速看很多形态变体。用 text-to-CAD 生成底座往左偏移、侧面开两个散热槽等变体比在 CAD 里手动改特征快得多。即使最终方案还要人工精修前期的方向探索用 AI 辅助效率极高。第三个是教学与培训。教 CAD 建模的时候学生描述一句我要做一个带圆角的 L 形支架然后看 AI 生成的代码能直观地理解描述 → 特征 → 几何的映射关系。这比老师一遍遍演示鼠标操作效率高。而且代码形态的建模思路很清晰非常利于初学者建立三维空间和特征操作之间的对应认知。6.2 对工程师和设计师的工作方式影响我判断未来一两年内text-to-CAD 不会替代任何人做真正的创新设计但它一定会改变大家的日常工作流。以前接一个任务拿到需求→打开 CAD→想步骤→动手建模可能要一个小时以后的流程会变成拿到需求→调用已有的提示词模板→AI 生成初版→人工审查修改→定稿可能只要十分钟。省下来的时间不是用来摸鱼的而是用来做更关键的判断这个设计能不能加工、装配有没有干涉、成本和重量优化空间在哪里。这里要给你一个比较诚恳的建议现在就开始积累你自己的提示词资产。每次你成功生成一个零件把提示词、代码、遇到的问题都存下来。三个月后你手上会有几十上百个高质量模板这就是你在这个领域里最早的护城河。AI 是放大器前提是你得有自己的设计方法论否则放大出来的只是垃圾。6.3 从 text-to-SIMPLE 到 text-to-ASSEMBLY 的扩展目前大多数 text-to-CAD 系统解决的是单个零件的生成但真实工业场景需要的是装配体——几十个零件之间的配合关系远比单个零件的形状复杂得多。LLM 是否能理解轴插入轴承的内孔两者同轴轴肩贴紧轴承端面这种装配语义我最近的实验是朝这个方向做的。用 CadQuery 分别生成轴和轴承再用 Python 代码进行装配约束比如将两个零件的坐标系对齐。现在 LLM 能生成比较可靠的独立零件但装配级的生成还有很大的改进空间主要难在模型很难掌握多个零件之间的坐标变换和依赖关系。不过在特定领域的受限装配场景里比如螺栓连接件text-to-assembly 的雏形已经可以用了。以后如果配合强化学习或者图神经网络做装配关系预测这块还会有一个大爆发。6.4 给入门者的一个最小行动路径如果你今天看完这篇文章想自己动手试试我建议按这个顺序走花一晚上把 CadQuery 环境搭好跑通第三节里的 hello world 案例打开 ChatGPT 或 Claude用第三节的模板生成 5 个简单零件底板、法兰、带孔块、轴套、支架每天积累一个文本 → STEP的案例持续两周两周后开始整理自己的提示词模板库按零件类型分类一旦你对 CadQuery API 的常见操作拉伸、切除、旋转、倒角、镜像、阵列都熟悉了再挑战一些复杂一点的零件比如齿轮、壳体这个路径不涉及任何训练模型的操作只需要会用 Python 和 LLM 聊天基本一周就能看到实际产出。这也是我目前最推荐的个人入门方式——先跑通闭环再研究深度。我个人在实际操作中还有一个体会text-to-CAD 的提示词写得好不好很大程度上取决于你对自己零件的理解是否清晰。很多时候模型生成的代码不如预期不是模型不够聪明是你给的规格描述本身就含糊其辞。所以在写提示词之前先在纸上画一画草图、标一标关键尺寸这比折腾任何模型参数都管用。最后分享一个小技巧常用的零件类型建议把提示词做成填空式模板把尺寸参数抽象成{length}、{diameter}这样的占位符。这样每次使用时只需要替换变量值不用每次都从头写大段文字。配合脚本或者低代码工具你甚至可以实现填表 → 自动调用 API → 自动执行脚本 → 自动导出 STEP的全自动流水线。等这一条流水线跑顺了text-to-CAD 对你来说就不再是一个新鲜词汇而是一件趁手的工具了。