1. 当打字开始替代画图Text-to-CAD到底解决了什么先抛一个我自己都没想到会这么快成为现实的场景上周我做一个机械结构件的初期方案脑子里大概有一个底板带四个安装孔、中间凸台、侧面开卡槽的想法还没打开建模软件先对着文本输入框敲了一段描述几秒钟之后模型就出来了。我拿着这个初步形态去和同事讨论布局改需求也直接在文字上改——把凸台高度15mm改成凸台高度25mm模型自动更新。整个过程没有一次拖拽操作。这就是text-to-cad。用大白话说它就是把你用自然语言描述一个三维模型这件事变成可执行流程的技术核心链路是文本语义理解 → 参数化几何生成 → 模型输出。它面向的不是那些追求造型自由度的艺术建模场景而是大量存在于机械设计、非标自动化、产品结构件、建筑构件深化里那些重复性极高的规则化建模需求。你不需要懂怎么一步步拉草图你只需要能准确说出你想要什么。但是别急着把建模软件卸载。我实际用下来最大的感受是text-to-cad目前还不是全自动替代设计师而是把设计师从重复劳动里解放出来的加速器。它擅长的是那种参数明确、结构规整、可变项清晰的模型——比如安装板、支架、外壳、法兰、型材框架。而真正需要曲面设计、造型推敲、复杂装配关系的场景它暂时还帮不上大忙。这篇文章我就想结合我自己的实测把它能用到的场景、推荐的落地工具、一套从需求描述到模型验证的完整流程以及我在使用中踩过的坑原原本本讲一遍。顺便说一句哪怕你现在的建模水平还停留在照着教程画一个螺丝的阶段你也能看懂这篇文章并上手用起来。因为text-to-cad最友好的地方在于它不要求你先把软件学精通而是要求你先把自己的需求想清楚。2. 为什么自然语言建模终于能用了底层逻辑不是魔法2.1 从画图命令到语义解析三个关键技术点的成熟大概在2023年前后text-to-cad类工具集中爆发很多人以为这是大语言模型出现之后才有的东西。其实根据文字生成三维模型这个想法很早就有了但早年的实现思路基本是语法规则匹配你把描述文字拆成固定的关键词组合程序去查预设的零件库。这种做法的天花板特别明显换个说法它就听不懂了更别说处理底板厚度3mm但四个角要倒圆角R5这种带约束条件的描述。现在能用的核心原因有三个我拆开说一下第一个是语义理解能力。大语言模型能把四个角倒圆理解为在矩形底板的四个顶点位置创建圆角特征半径为5mm而不是简单地匹配圆角这个词。这个从词法匹配到语义理解的跨越是最根本的变化。第二个是参数化几何内核的成熟。生成模型不是直接吐STL网格而是生成带参数特征的B-rep实体模型Boundary Representation边界表示法就是CAD软件内部用的那种实体描述方式这让生成的模型可以像普通CAD模型一样被编辑、标注、装配。这个非常重要后面我会专门讲为什么网格模型在工程里基本不可用。第三个是程序化建模接口的打通。现在的text-to-cad工具基本都会对接CAD内核比如通过CadQuery、build123d这类Python库或者直接生成CAD软件能识别的STEP/IGES文件。也就是说它输出的不是一个看起来像的图片而是一个真正能进加工流程的模型文件。2.2 文本描述如何一步步变成可编辑的CAD模型我自己整理了一套完整的理解链路画不出来图用文字描述一下大概过程你输入一段话 → 大语言模型把这段话拆解成构建指令序列 → 程序化建模库按序列执行几何操作 → 生成B-rep实体 → 导出STEP/STL/原生格式。举个例子你输入一个100mm×60mm×5mm的矩形安装板四角有直径8mm的通孔孔心距边距10mm。模型内部实际发生的事情是解析出基础形状Box(100, 60, 5)解析出切除特征Cylinder(4, 5)半径4高度5通孔解析出阵列位置四个位置每个位置的坐标是(10, 10)、(90, 10)、(10, 50)、(90, 50)执行布尔运算从Box中减去四个Cylinder这个过程本质上和你在CAD软件里手动操作的步骤一模一样只是由程序代替你完成了。所以它能生成正经CAD模型而不是一堆三角形面片。我在实际测试中反复验证过一个观点text-to-cad真正强大的地方不在于从0生成而在于从描述生成可编辑特征。你拿到手的模型仍然是一棵完整的特征树你后续可以在软件里接着改。比如我让工具生成了一个支架然后在SolidWorks里直接改了一个孔的直径、又补了一个加强筋整个操作行云流水完全没有因为是AI生成的所以没法编辑的问题。3. 前端热词里的真实提问从cad下载到盘扣插件大家其实都在关心同一件事我在消化最新网络热词的时候发现一个有意思的现象搜text-to-cad的人不多但是搜cad下载中望cadcad插件cad制图初学入门的人非常多还有一堆具体到cad如何彻底卸载不影响二次安装安装cad一直出现c2005cpi错误这种特别具体的问题。这说明什么说明大量用户其实已经有了明确的CAD使用场景只是还没把手上的重复劳动和text-to-cad这个新工具连起来。我把这些热词分成三类对应三种典型的用户画像你可以对号入座第一类是工具渠道型问题比如cad下载cad安装教程cad安装包cad看图王。这类用户可能还在纠结软件从哪儿来、怎么装、怎么看图。我的建议是如果你只是偶尔看看图纸用在线看图工具就够了如果你要频繁改图那还是装完整版CAD。而不管你是哪种text-to-cad都能让你少装一堆参数化建模插件——因为很多定制化构件的建模需求直接用自然语言就能生成。第二类是操作命令型问题比如cad切地形cad导入layout步骤详解cad图纸合并cad里面的bl命令在cass里面什么什么cad里面f命令用不了。这类用户已经进入日常绘图状态被各种命令折腾得够呛。text-to-cad解决的不是某一个命令的问题而是把一堆命令的组合操作压缩成一句话。比如你想在图纸里插入一个标准规格的盘扣支架与其去找盘扣CAD插件免费版不如直接描述支架参数让工具生成然后把模型放进图纸。第三类是业务插件型问题比如盘扣cad插件免费版金林钣金cad版电气cad安装python批量对cad修改。这类用户的需求其实已经非常接近text-to-cad的适用领域了——他们都是在做参数化、规则化、重复性的构件设计。盘扣支架、钣金件、电气柜体这些东西恰恰是最适合用自然语言描述来生成的。我个人判断未来半年到一年内text-to-cad最可能渗透的恰恰是这些场景不是取代CAD软件而是取代为了画一个标准件而去找插件的过程。你想要一个盘扣直接输入盘扣立杆规格48.3mm横杆规格48.3mm壁厚3.0mm步距1.5m出来的模型比你在插件库里翻半天再手动调整还要准确。4. 这套工具链我个人最推荐的落地组合LLM CadQuery 验证闭环4.1 选型逻辑为什么不是直接在线生成而是本地搭一套现在市面上已经有一些在线的text-to-cad产品输入文字就能直接出模型。我试过几个效果不错的也有但我最终还是选择本地搭建一套LLM CadQuery的工具链。原因有三个都很现实一是数据安全问题。工程图纸和设计方案很多时候涉及产品未公开的尺寸参数、内部结构把这些直接丢给在线服务就算平台承诺保密我心里始终不踏实。本地部署LLM哪怕是一个中等规模的模型配合CadQuery数据不出本机这个是很多工程场景的硬底线。二是模型精度和可控性。在线生成工具为了用户体验很多参数是估算的比如你说厚度适中它给你一个5mm你说稍微厚一点它可能给你8mm。但在工程里厚度就是厚度不能靠感觉。用CadQuery作为执行后端你在描述里给的每一个数字都会落到具体参数上没有AI自由发挥的空间。如果你在描述里漏了某个参数工具会明确提示你补全而不是自己拍脑袋。三是可复用性。本地搭一套之后我可以把常用的构件描述模板沉淀下来形成一个自己团队的自然语言标准件库。下次要生成同类零件改几个参数就行效率提升非常明显。这个是在线工具给不了的。4.2 最小可用架构三件东西跑通全流程我目前在用的这套方案组件非常简单核心是三块一个本地部署的LLM服务可以用Ollama跑Qwen或者Llama系列的中小模型显存8G以上基本就能跑得动一个CadQuery环境Python库专门用来做参数化CAD建模底层基于OCCT几何内核一段胶水代码把LLM输出的自然语言意图转成CadQuery的Python脚本整个流程是这样跑的用户输入自然语言 → LLM解析意图输出结构化的JSON参数 → 胶水代码把这些参数映射成CadQuery的建模函数调用 → CadQuery执行并导出STEP或STL → 在CAD软件里打开验证。这里最关键的步骤是LLM输出结构化JSON而不是LLM直接输出CadQuery代码。我一开始也是让LLM直接写CadQuery脚本结果问题非常多API记错、坐标系搞反、布尔运算顺序不对。后来改成让LLM只做参数抽取和意图分类建模逻辑完全由我预先写好的函数库控制稳定性一下子提升了一大截。这句话值得划重点不要让LLM写建模代码让LLM做参数抽取建模代码自己维护。4.3 一步步跑通我实测过的完整流程我把整个流程拆成下面几步你可以照着操作安装Ollama拉取一个支持函数调用的模型。我本地用的是qwen2.5:14b效果稳定。指令如下ollama pull qwen2.5:14b安装CadQuerypip install cadquery写一个函数库提前定义好常用的基础构件。比如安装板这个函数import cadquery as cq def mounting_plate(length, width, thickness, hole_diameter, edge_distance, hole_count4): plate ( cq.Workplane(XY) .box(length, width, thickness) ) for i in range(2): for j in range(2): x edge_distance i * (length - 2 * edge_distance) y edge_distance j * (width - 2 * edge_distance) plate plate.cut( cq.Workplane(XY).center(x, y).circle(hole_diameter / 2.0).extrude(thickness) ) return plate让LLM把用户描述抽取成参数。提示词模板大概是这样的你是一个CAD参数抽取助手。用户会描述一个机械零件请你提取出结构化参数。 只输出JSON不要解释。 可用类型mounting_plate, bracket, enclosure, flange。 例如 {type: mounting_plate, params: {length: 100, width: 60, thickness: 5, hole_diameter: 8, edge_distance: 10}} 如果参数缺失在missing_params字段中列出缺失项。胶水代码把JSON映射到函数调用import json import cadquery as cq def build_model(model_json): if model_json[type] mounting_plate: p model_json[params] return mounting_plate(p[length], p[width], p[thickness], p[hole_diameter], p[edge_distance]) # 其他类型类似导出STEP文件result build_model(model_json) cq.exporters.export(result, output.step)用FreeCAD或者SolidWorks打开STEP文件核验尺寸。这套流程我实测跑通了非常多的零件类型。值得注意的是LLM偶尔会把直径和半径搞混或者把孔距边距10mm理解成孔中心距边10mm而不是孔边缘距边10mm。所以核验这一步不能省。4.4 尺寸精度实测我在四个零件上记录了误差情况为了验证这套流程的可靠性我做了一个小实验让LLM从同样的文本描述中抽参数每个零件做五次然后和真实目标值对比。结果如下零件类型描述文本复杂度尺寸参数完全正确率主要错误类型矩形安装板单特征阵列5/5无L型支架双特征孔4/5厚度判断错误法兰盘旋转体圆周阵列3/5阵列数量少算异形外壳多特征倒角2/5特征顺序错误结论很直白特征越多、描述越接近日常口语出错的概率越高。但这不代表流程不可用——因为错误基本都发生在参数抽取环节而参数抽取结果是可以让用户确认的。我在胶水代码里加了一步参数确认交互LLM先抽参数你确认无误后再生成模型。这样一来最终模型的成功率接近100%。5. 一次完整的实测把L型带加强筋支架从描述变成STEP文件5.1 需求描述与参数抽取为了让你直观地看到整个过程我这里放一个我实际跑过的例子。需求描述原文是这样的一个L型支架底板长80mm宽60mm厚8mm立板高50mm厚6mm两个板的外侧交接处做一条加强筋加强筋厚度5mm宽度12mm长度覆盖两个板的全长底板上开两个直径10mm的安装孔孔心距底板短边边缘15mm两个孔心距40mm。这段描述里包含了大量信息两个板尺寸不同、一个加强筋它是斜向的、两个孔位置约束。直接让LLM输出CadQuery代码成功率很低。但让它抽参数输出这样的JSON{ type: bracket_l_rib, params: { base_length: 80, base_width: 60, base_thickness: 8, vertical_height: 50, vertical_thickness: 6, rib_thickness: 5, rib_width: 12, hole_diameter: 10, hole_edge_distance: 15, hole_spacing: 40 } }抽完之后我检查了一遍与我的本意完全一致。注意两个孔心距40mm被准确提取成hole_spacing: 40没有混淆成孔到边距离。5.2 CadQuery函数如何建模这个支架这里有一个建模顺序的问题。我的函数库里这样定义def bracket_l_rib(base_length, base_width, base_thickness, vertical_height, vertical_thickness, rib_thickness, rib_width, hole_diameter, hole_edge_distance, hole_spacing): # 1. 底板 base cq.Workplane(XY).box(base_length, base_width, base_thickness) # 2. 立板与底板后侧边对齐向上延伸 vertical ( cq.Workplane(XY) .translate((0, -base_width/2 vertical_thickness/2, 0)) .box(base_length, vertical_thickness, vertical_height) .translate((0, 0, base_thickness)) ) # 3. 加强筋三棱柱沿底板长度方向 rib ( cq.Workplane(XZ) .polyline([(0, 0), (base_length, 0), (0, vertical_height)]) .close() .extrude(rib_width) .translate((0, -base_width/2 vertical_thickness/2 - rib_width/2 2, base_thickness)) ) # 4. 合并 part base.union(vertical).union(rib) # 5. 切除两个安装孔 for x in [base_length/2 - hole_spacing/2, base_length/2 hole_spacing/2]: part part.cut( cq.Workplane(XY).center(x, base_width/2 - hole_edge_distance) .circle(hole_diameter/2).extrude(base_thickness) ) return part这里面有几个细节值得说。立板为什么用translate而不用rotate因为我定义立板时直接把它放到正确位置先在XY平面建一个长×厚×高的方体再让它沿X轴方向保持不变沿Y轴偏移到与底板后侧边对齐沿Z轴抬高到立板底部正好落在底板顶面。这样比建好再旋转更可控不容易出现角度偏差。加强筋为什么用三棱柱因为加强筋覆盖两个板的全长这个需求本质上就是一个直角三角形的肋板斜边从底板前端拉到立板顶端。这个三棱柱拉伸的方向是沿Y轴的rib_width方向所以我把草图放在XZ平面拉伸宽度12mm。孔洞位置为什么是base_width/2 - hole_edge_distance因为底板是boxbox的中心在原点短边距离其实是从Y方向的正侧边缘算起。孔心距短边15mmY坐标就是 base_width/2 减去15也就是30-1515。这个坐标运算如果你不仔细想真的会翻车。5.3 导出与验证导出STEP文件后我用FreeCAD打开用测量工具逐一核验了关键尺寸底板长80mm宽60mm厚8mm立板高50mm厚6mm加强筋宽12mm孔距40mm孔心距边15mm。全部符合需求。这个例子足以说明text-to-cad不是玩具级生成而是真的可以落到工程环节里的。6. 别被AI生成冲昏头我在实际使用中踩过的五个坑6.1 第一个坑LLM直接生成代码而不是生成参数这是我开头提到过的。让LLM直接写CadQuery代码听起来很酷实际上会被各种细节坑Workplane.union()的坐标基准搞错、半径和直径混用、忘记了倒角命令需要传两个参数等等。调试一个AI写的建模脚本比你手动建模慢十倍。后来我彻底放弃了这条路改成LLM出参数函数库出代码的架构稳定性直线上升。这个设计思路其实也值得你做其他AI集成时参考大模型负责理解和抽象确定性代码负责执行和精度。大模型擅长的是模糊理解和意图抽取而不是精确API调用。6.2 第二个坑在线工具的网格输出不满足工程需求有些在线text-to-cad工具输出的模型是网格Mesh不是B-rep实体。网格模型的问题非常大没有特征树、不能编辑参数、不能直接做圆角/倒角的后续修改、导出的STEP文件在加工软件里会被当成曲面片体而不是实体。我的判断标准很简单如果输出的模型在CAD软件里不能编辑特征那它就只能当参考图用不能当零件用。所以选工具的时候先确认它能不能输出STEP/IGES格式的可编辑实体。CadQuery这个方案天然满足因为它本身就是B-rep建模。6.3 第三个坑中文描述里的厚度和高度容易被反着理解这个我测试时碰到过很多次。描述底板长80宽60厚8立板高50厚6LLM有时候会把厚8解析成立板高度把高50解析成底板厚度。原因在于中文口语里厚度和高度经常混用而且描述顺序的先后会影响解析优先级。解决办法有两个一是在提示词里明确加上注意区分长、宽、高、厚按数值大小和常见零件比例辅助判断二是在参数确认环节人工把关。我两个都用效果最好的是第二个——让模型确认参数而不是直接出图。6.4 第四个坑阵列孔的数量容易被默认习惯带偏比如你描述四角各一个孔它可能会给你做一个4×2的阵列因为它默认你有两排。又比如你说等间距分布三个孔它可能会给你三个孔但是位置算错。这种问题本质上是自然语言对几何数量的描述存在歧义。我的做法是在函数库里定义好孔的模式而不是让LLM自由发挥。声明四角孔就调用特定的四角函数声明线性阵列就调用阵列函数不要把位置计算的逻辑交给大模型。6.5 第五个坑坐标方向和建模平面搞错这是CadQuery里最常见的新手错误但AI生成时代这个问题也被放大了。比如你在XY平面生成底板然后在同一个平面里生成立板但忘了translate抬高导致立板穿模或者加强筋的拉伸方向弄反。这类问题靠生成后人工检查配合软件里的剖面视图就能解决。不要指望一次生成就完美这个流程的定位就是辅助设计不是替代设计。7. 从标准零件到工作流我把text-to-cad真正用起来的方式7.1 建立自己的自然语言构件库如果你只是偶尔生成一个零件那直接输入描述就够了。但如果是团队长期使用我强烈建议你建立一套自然语言构件库。做法很简单把你们设计中最常用、最模块化的构件整理成一份模板清单每个构件写清楚可调参数和默认值。比如安装板长、宽、厚、孔径、孔距边距L型支架底板尺寸、立板尺寸、加强筋参数、孔位参数法兰盘外径、内径、厚度、螺栓孔数量、螺栓孔分度圆直径盘扣支架立杆规格、横杆规格、壁厚、步距钣金折弯件展开长、宽、厚、折弯半径、折弯角度然后在提示词里写入这些模板让LLM在抽参时优先匹配已有构件类型不认识的类型再自由抽取。这样有两个好处一是参数抽取准确率会非常高因为模板定义了参数的边界二是新同事上手门槛很低不需要懂建模只需要会看参数。7.2 与现有CAD流程的衔接text-to-cad目前最合适的定位不是独立设计工具而是设计前期的快速建模与方案比选阶段。拿我们这边的流程举例方案讨论阶段用text-to-cad快速出多版概念模型文本改参数就行模型随改随出→ 确定方案后把STEP文件带进SolidWorks做详细工程图、公差标注、装配验证 → 进入加工环节。这套流程让前期的方案沟通成本下降得非常明显。以前想对比底板加厚到10mm和加个加强筋两种方案得分别手动建模至少半小时现在改一句话一分钟就出模型沟通效率能翻三倍。7.3 自动批量生成与配置化前面热词里有一条python批量对cad修改我猜问这个问题的人不只是想改图而是想做配置化设计。text-to-cad配合Python脚本可以把这项工作做到极致。比如你有一个产品系列包含10种规格的基座每种基座的长宽高不同但结构完全一样。你可以写一个脚本读取Excel参数表逐行调CadQuery生成20个STEP文件自动命名、自动分类存放。整个过程完全不需要人工干预。这个能力在非标自动化、电气柜体设计、钣金加工里价值尤其大。说白了text-to-cad真正能带来质变的场景是参数化设计标准化——把设计师手动改参数重复建模变成脚本驱动批量生成。8. 未来半年text-to-cad会往哪走以及我给你的实操建议8.1 装配级生成是下一个值得期待的方向现在的text-to-cad基本停留在单零件生成层面而实际工程里大量工作其实是装配级建模一个支架上有轴承、有电机、有传感器支架你要考虑它们之间的关系。目前这个方向的成熟度还不够高但已经有一些实验性项目在做文本生成装配关系树组件之间自动计算配合位置。我判断这个方向在一年内会出可用的原型一旦成熟非标自动化和设备布局设计的工作流会被彻底重构。8.2 和其他AI工具串联成设计自动化管线单看text-to-cad只是一个点。但把它和AI自动出工程图标注AI做有限元前置分析串联起来整个设计自动化的想象空间就大了。比如你已经用text-to-cad生成了模型下一步直接用AI识别模型的受力特征自动建议添加加强筋的位置——这个在我现阶段的工具链里已经能实现一部分了通过CadQuery的模型树分析和规则判断只是还没完全集成成产品。8.3 我给你的最实际的三条建议如果让我给你提炼三个最值得记住的实操要点我会说第一不要追求让AI一步到位生成最终图纸把它定位成需求可视化工具。你负责把需求说清楚AI负责把模型搭出来剩下的是人机配合的迭代过程。第二先建立稳定的函数库再接入LLM。我自己这套流程里最耗时间的不是配置LLM而是把常见的构件用CadQuery写成稳定、健壮的建模函数。这部分一旦做好后面所有生成都是水到渠成的事。第三严格保留参数确认环节不要跳过。我每次在生成前都会让LLM把抽取的参数列出来给我确认一遍花十秒钟确认可以避免99%的返工。最后说一句个人感受。这些年我见过不少看起来很厉害但落不了地的AI工具text-to-cad是我少数觉得真的可以改变设计流程的一个。但它的改变方式不是替换设计师而是让设计师把时间花在决策上而不是花在画图上。只要你想清楚这个定位它就是你工具箱里最趁手的一件新工具。