上周加完班朋友发来一句话“帮我做一个L形支架长边80毫米短边60毫米宽度50毫米底部开两个对称的8毫米安装孔。” 我下意识打开CAD准备画草图突然意识到已经不用这么干了——把这句需求原样扔给text-to-cad工具几秒钟就能拿到一个可编辑的STEP文件。这个场景在两三年前还只能在论文demo里看到现在已经能实实在在嵌入工作流了。text-to-cad顾名思义就是把“自然语言描述”变成“CAD模型”的技术方向。核心是让大模型理解几何语义把一句话里的形状、尺寸、位置关系、连接方式翻译成机器可以执行的三维建模指令。这篇文章我会拆开聊三件事这类工具背后的技术路线到底有哪几种、哪条路现在真正能落地、以及我自己实测下来的一套完整工作流和一堆踩坑记录。适合正在选型、想自己搭一套文本建模工具链的工程师也适合刚接触这个方向、想知道“这玩意到底怎么work”的产品和技术同学。1. text-to-cad到底在解决什么问题1.1 从一句话到三维模型需求拆解先看一条典型的自然语言需求“做一个底板200长150宽10厚四角各有一个M6通孔孔心距边缘15毫米。” 人要理解这句话很容易但要让程序理解必须把它拆成结构化的几何约束。拆解下来大概是这么几类形状类型底板、总体尺寸200×150×10、特征数量4个孔、特征尺寸M6、特征位置距离边缘15毫米、位置关系四角对称。这正好对应传统CAD建模时的操作序列——先画草图拉伸成板再在四个角上打孔。text-to-cad的工作本质就是把这个“建模操作序列”自动生成出来。这个拆解过程并不只是做关键词提取难点在于空间关系推理。比如“孔心距边缘15毫米”意味着需要知道哪条边是“边缘”需要知道孔落在哪个面上需要处理“四角”这种隐式的对称关系。语言模型做这件事有一个天然优势它在海量文本上见过类似的描述方式能够在语义层面理解“四角各一个孔”等价于“4个孔沿中心对称分布”这种表述背后的几何意图。1.2 为什么现在才火起来其实“文本生成CAD”这个想法本身并不新。十几年前就有研究尝试用规则引擎解析自然语言当时的目标是“让不会用CAD的人也能做设计”但效果一直很差。原因是老方法靠的是有限的关键词库和手工编写的语法规则稍微换一种说法就彻底失效“在角落里打孔”和“在角落布置孔特征”在规则系统里是两条完全不同的逻辑路径。真正翻开这一页的是大语言模型。它能够从语义上理解多样化表达不需要你精确地说“创建草图-拉伸-去除材料”这种命令语言直接用口语就能反向推理出建模步骤。加上2024年以来出现了一批专门针对CAD领域的数据集和基准测试比如Text2CAD、CAD-Coder等方向把“自然语言映射到程序化建模代码”这件事从概念验证推进到了可评估、可迭代的工程阶段。现在你能看到的text-to-cad工具绝大多数背后都是语言模型在生成某种程序化建模代码而不是像普通文生图那样直接生成像素点阵。这背后的本质区别值得多说一句文生图生成的是位图像素错了肉眼未必看得出但CAD失败会直接报错或产出烂几何。所以text-to-cad的工程路径天然更接近“让模型写一段CAD脚本”而不是“让模型吐一个多边形网格”。2. 底层逻辑大模型不会画图但它会写程序2.1 技术路线的本质分歧目前做text-to-cad主流的实现方式可以粗暴分成三类检索式、命令序列式、端到端生成式。这三类不是同一个问题的不同解法而是完全不同的思路落地难度和效果上限完全不一样。有人可能会问为什么不用类似文生图的扩散模型直接生成一个三维模型这个问题问到点子上了。扩散模型生成点云或体素已经有了不少研究但它只能给出一个网格表面没法给出CAD意义上的几何内核——没有参数化的草图、拉伸、特征树、约束关系。对机械零件来说没有特征树的模型等于一张死图片改个孔位都要重新建模。所以端到端生成式目前只适合做外观造型不适合做工程零部件。2.2 路线一检索式生成检索式是三条路线里最“朴素”但也是最先商业化的路径。它的逻辑一句话就能讲清楚把用户的文本需求编码成向量到零件库里去搜索语义最接近的已有模型返回结果并按用户的需求做有限的参数适配。举一个实际产品例子某标准件平台的“语音搜零件”功能你输入“内六角圆柱头螺钉 M6×20”系统不是现场建模而是把这句话和库里的零件元数据做语义匹配直接返回对应的三维模型。这就是检索式text-to-cad。这种路线的优点是几乎不会产生“烂模型”因为返回的都是库里真实存在、已经过验证的零件。但它的天花板也非常明显库里没有的东西再搜也搜不出来。你要找一个特定形状的非标支架检索式基本无能为力它只能给你“最接近的那个”而你在工程上往往不需要“最接近”你需要“正好”。2.3 路线二命令序列生成命令序列式是目前最被看好的路线也是大部分真正“能用”的text-to-cad工具选择的方案。它的思路是不直接生成几何体而是生成一段可以被CAD内核执行的建模代码或命令流。具体来说常见的输出目标有三种一是CadQuery、OpenSCAD这种程序化建模库的代码二是FreeCAD、SolidWorks等软件的API调用脚本三是某种中间表示比如CAD命令序列。模型像一个会写代码的助手你告诉它需求它写出程序程序跑出来一个模型。这里有一个关键洞察语言模型在训练时并没有专门学过CAD但它见过大量的代码包括CadQuery的示例、OpenSCAD的手册、甚至论坛里的Python建模脚本。当它生成代码时实际是在模仿这些分布。所以你会发现越流行的程序化建模框架模型生成的效果越好——因为网上相关语料越多。2.4 路线三端到端生成与网格重建端到端生成走的是“生成式AI通用套路”用扩散模型或自回归模型直接生成三维表示体素、点云、隐式场再通过移动立方体等算法重建出网格。这条路看起来最“AI”但实际工程问题最多。首先是精度问题。重建网格的精度远远达不到机械加工的需求一个声称“直径8毫米的孔”重建出来可能是7.8毫米且截面不圆。其次是可编辑性问题。CAD工具对模型的操作是建立在参数化特征之上的网格模型没法直接改特征参数只能当作STL小面片使用这在工程上意味着它只能用于3D打印预览进不了正式的机械设计流程。目前比较靠谱的应用场合是概念设计阶段的外观探索——比如说“做一个类似水滴形态的壳体”端到端的生成结果可以给你灵感然后你再人工用曲面工具重新建模。把它当作一个快速草图工具可以把它当作CAD替代品还差得很远。3. 目前最靠谱的落地路径3.1 路线对比选哪条路取决于你的场景我不建议一上来就追最热的技术路线先看你要解决的到底是哪一类问题。三条路线的适用场景差异非常大选错了等于拿扳手拧螺丝刀工具再好也白搭。技术路线输出形式优点缺点适合场景检索式已有零件库中的模型稳定可靠、不改几何只能拿到“近似”结果标准件查询、零件库检索命令序列式CAD脚本/API调用结果可编辑、可复用需要代码执行环境、会出错非标零件快速建模、设计自动化端到端生成网格模型形状自由度最高精度差、不可参数化概念造型、灵感探索我推荐大多数工程师把精力花在“命令序列式”上也就是让语言模型写CadQuery或OpenSCAD代码。这不仅是技术上最现实的路线而且对工程师来说有个额外好处生成的代码本身就是一份建模过程文档你可以审查每一步出了问题能定位到具体行这和黑盒生成一个STL的体验完全不一样。3.2 方案A语言模型 CadQuery脚本CadQuery是一个基于Python的程序化建模库它对机械零件建模的友好程度很高。和OpenSCAD的纯CSG思路不同CadQuery的API非常接近传统CAD的工作方式你可以在一个工作平面上画草图、拉伸、开孔、倒角、圆角。用语言模型驱动CadQuery的流程大概是这样的先让模型理解需求生成Python代码然后用CadQuery执行代码生成实体最后导出STEP或STL。我实测下来对于板类、框架类、带孔带槽的零件模型的成功率最高因为这些零件的建模逻辑相对固定——拉伸出主体布尔运算减出孔槽。要注意一个细节CadQuery的版本兼容性问题。不同版本的API命名有细微差异比如旧版本用box()新版本可能推荐用box()但参数变了。模型训练时学到的可能不是最新版API生成代码偶尔会报错。我的习惯是在提示词里强制指定“按CadQuery 2.4版本语法”并且把常用的几行import语句模板直接塞进提示词里能省掉很多报错。3.3 方案B语言模型 OpenSCADOpenSCAD走的是纯代码建模路线没有交互式界面所有几何体都是通过代码里的CSG操作并集、差集、交集组合出来的。它的编程模型更简单直接非常适合语言模型推理。举个例子让模型生成一个L形支架OpenSCAD代码可能是这样module l_bracket(length, width, height, thickness) { // 长边 cube([length, thickness, height]); // 短边 translate([0, width - thickness, 0]) cube([thickness, width - thickness, height]); }这种代码的推理成本比CadQuery低因为OpenSCAD的概念更简单——基本几何体、坐标变换、布尔运算。语言模型在这类代码上的“幻觉”概率会小很多。代价是OpenSCAD对于复杂建模比如扫描、放样、变半径圆角支持较弱所以它更适合快速原型、外壳、支架这类零件。如果你只是想快速验证一个想法OpenSCAD的方案上手最快装个OpenSCAD往模型引擎里输入需求得到的代码直接在OpenSCAD里打开就能实时看到结果。但如果你需要交付STEP格式给下游配合CadQuery方案更稳因为它直接支持标准的STEP交换。3.4 方案C语言模型 参数化零件库调用这是我认为工程落地潜力最大、但容易被忽视的一条路。思路是不指望模型自己从零生成几何而是让它学会选择和调用你公司已有的参数化零件库。打个比方模型不是建造师而是仓库管理员。你说“我要一个M8的六角头法兰螺栓杆长30毫米”模型不生成螺栓的几何而是调用零件库里预制的螺栓生成函数传入对应参数。这种做法的优势非常明显所有几何都是由经过验证的参数化模板生成的形状完全可控公差体系、材质属性、甚至加工工艺信息都可以跟着模板一起带出来。本质上语言模型只是充当自然语言和参数化API之间的翻译器。实现上无非是给模型提供一份“工具说明”告诉它有哪些零件函数、每个函数接受什么参数。我见过一些自动化设备公司已经在内部这么干了——把标准件库包装成API让技术员直接用自然语言查料号、出模型准确率能做到九成以上。这个方向对中小企业尤其有吸引力因为它不需要训练自己的模型只需要梳理好现有的零件库和文档。4. 搭建一个能用的text-to-cad工作流4.1 工具链推荐以最通用的方案A为例我给你一份可以直接照抄的工具链。整体结构不复杂语言模型负责“理解需求并写代码”本地环境负责“执行代码并产出模型”中间记得加一层校验。语言模型接口建议用支持函数调用或代码生成能力较好的模型。你直接调用API也行用本地部署的开源模型也行取决于你的数据保密要求。工程建议保留一个“生成-重试”的循环模型第一次生成的代码错误率高是常态。代码执行环境本地安装CadQuery即可它是pip包pip install cadquery就完事。注意Python版本要匹配CadQuery目前对Python 3.10以上支持比较完善。可视化调试CadQuery官方有CQ-editor一个带视图的IDE能把生成的代码实时渲染成三维模型。强烈建议用它做中间检查别直接跳到导出STEP。文件输出CadQuery支持直接导出STEP、STL、SVG等格式。给下游制造或仿真时用STEP给3D打印用STL。4.2 一份我实测好用的提示词模板提示词是text-to-cad里决定性的一环。模型能不能生成对的代码很大程度取决于你怎么描述需求。我踩过无数坑之后总结出一套提示词结构先给角色和规则再给需求描述最后锁死输出格式。你是CadQuery建模专家。你的任务是把用户描述的三维零件需求转换成可直接运行的CadQuery Python代码。规则 1. 只使用CadQuery 2.x版本的API。 2. 所有尺寸默认单位是毫米。 3. 只输出完整Python代码不解释、不添加注释之外的内容。 4. 如果需求信息不足在代码开头用TODO注释标出缺失参数不要猜测。 需求{用户的自然语言描述} 输出代码这个模板看起来简单但每句话都有用。第2条锁死单位避免模型上次用毫米这次用英寸。第3条锁死输出格式不然模型会在代码前后夹带一堆解释文字解析起来很蛋疼。第4条特别关键——模型在信息不足时倾向于“猜一个数”这在CAD里是致命的宁可让它标注TODO也不能让它瞎填。另外一个小技巧对复杂零件别指望一条提示词一步到位。分成两步来第一步先让模型输出“约束清单”把自然语言里的尺寸、位置关系梳理成结构化表格第二步再把约束清单扔回去让它生成代码。这样能显著降低漏尺寸、错位置的概率。4.3 后处理与验证闭环text-to-cad的产出不能直接当最终交付物必须加一层自动化校验。我推荐至少做下面三项检查每一项都有具体的工具支撑。第一项是几何合法性检查。最简单的方法是检查模型是否水密、有没有自相交面。CadQuery生成的实体本身通常不会自相交但当你做布尔运算组合多特征时偶尔会翻车。可以写几行Python检查体积是否为负、边界是否闭合。第二项是尺寸抽检。把生成成品的实际尺寸和你需求里的关键尺寸做对比。这里可以用CadQuery内置的boundingBox()方法检查外轮廓尺寸是否符合预期比如需求是200毫米长结果代码执行完出来一个208毫米的实体说明某个参数推断错了。第三项是人工目检。在CQ-editor里打开模型旋转视角看一遍重点关注孔的位置、倒角的朝向、特征的相对关系。这一步虽然在AI时代显得有点土但依然是发现问题的最高效手段——人的视觉系统对几何异常非常敏感很多代码逻辑完全正确但结果就是“看起来不对劲”的问题只有这一步能兜住。整个流程走完再把验证过程中发现的问题反馈回提示词形成一个小的迭代闭环。我现在的习惯是第一轮生成后不急着从头改而是把验证代码输出给我的模型让它自己分析哪里偏离了需求再自动修正。这样跑两三轮大多数零件都能收敛。5. 实测场景与翻车记录5.1 典型实测案例我自己拿一个真实场景测过做一个电机安装支架需求是“底板120×80×8四角通孔M5中心凸台直径40高度12凸台正中有一个直径22的沉孔深8”。这是一个非常典型的机械零件有板、有凸台、有通孔、有沉孔逻辑不复杂但仍需要建模者正确推导特征顺序。用CadQuery方案一次生成成功率大概在六成左右。第一次跑出来的代码通常能建出底板和四角孔但凸台下方的沉孔经常被写成贯穿孔因为模型对“沉孔深8”理解成了“切除深度8”却忽略了一个重要前提——这个沉孔不是开在底板上而是开在凸台上位置不一样深度基准也不一样。这个例子很有代表性模型不是不理解“尺寸”而是搞不清特征的“依附关系”。它知道要做一个直径22的孔也知道深度是8但判断不了这个孔的起始面在哪。解决办法是在需求描述里加显式的空间锚点——不说“有一个直径22的沉孔深8”而是说“在凸台的顶面向上偏移x毫米处做一个直径22、深度8的沉孔”。描述得越像建模工序模型的成功率越高。5.2 高频问题速查表列一个我实测遇到最多的问题清单每一类都给出症状和解决方向。现象常见原因处理办法生成的代码有语法错误模型输出了幻觉API或截断了代码增加“只输出完整代码”约束加自动重试逻辑尺寸整体不对单位混用mm/in或约束漏读提示词锁死单位在末尾追加“关键尺寸确认”列表孔或槽位置偏移模型对“居中”“对称”理解有歧义在需求里给定坐标锚点不要用模糊语言特征顺序颠倒导致布尔运算失败实体未完全相交就做差集提示词要求“先定义所有主体再做差集”大零件生成了镂空体模型试图优化重量但你没要求明确“这是实体铸造件不是拓扑优化件”和需求完全不同但代码能跑模型“自创”了一个合理零件加强需求里的功能描述而不是形状描述关于最后一行多说几句这是最隐蔽的问题。模型生成一个能跑的代码形状也说得通但跟你想要的根本不是一回事。比如你想要一个“卡扣”模型生成的是一个“加强筋”。这种错误在自动校验阶段根本发现不了因为它不是一个“错误”而是一个“有逻辑的不同方案”。我唯一有效的手段是在提示词里描述功能场景——“用来卡住直径10的圆管”而不是只描述形状“半圆环”。功能描述才能约束模型的想象力。5.3 目前的能力边界text-to-cad不能干什么我帮大家画一条清晰的红线。第一高精度配合面做不了。模型的输出精度普遍在0.1毫米这个水平真要到配合公差比如H7/g6必须靠人工精修或者直接不用这条路。第二装配体级别的建模做不了。它擅长单个零件的建模但“做一个由5个零件组成的铰链机构并定义它们的装配关系”——这种任务目前基本只能生成零件装配关系还是要自己拖。第三复杂曲面和自由造型做不了。你让它生成“一个符合空气动力学曲线的前脸外壳”它生成的会是一个“由糊涂曲面拼起来的什么东西”离可用的工业曲面十万八千里。认清边界之后反而更好用——把时间花在它擅长的场景板类零件、支架、外壳、基础机械特征、标准件调用、概念验证模型。这些场景下它能帮你省下一半以上的建模时间这就已经非常有价值了。6. 我的一点实操体会最近用下来最大的感受是text-to-cad不是一个“不用学CAD”的解决方案而是一个“CAD建模效率倍增器”。它把从“想法到模型”之间的机械劳动压缩掉了但前提是你得懂建模、懂工艺才知道怎么跟它描述需求、怎么判断它生成的对不对。我的常规操作现在是这样的先在纸上画一个最粗糙的草图理清这个零件的核心拓扑关系然后写一句非常具体的自然语言需求塞给模型让它给约束清单确认无误后再让它生成代码最后用自动校验加人工目检收尾。整个流程走完快的时候几分钟能出一个可用零件慢的时候也就是多一轮迭代的事。如果你是想在团队里引入这套工作流我建议从“标准件库语言模型”这个方向起步先让采购和技术员用自然语言出标准件模型见效快、风险低。等大家用顺手了再逐步扩展到非标零件生成。工具迭代迭代很快但思路和方法是通用的——先拆需求再翻译成建模步骤最后用校验闭环兜住底线。这套逻辑不管底层模型怎么换都不会过时。