做了十年机械设计再往前数几年天天跟CAD打交道最烦的三件事装完CAD发现缺SHX字体图纸莫名打不开想卸载重装又卸不干净二次授权直接卡住画个法兰盘改了三版尺寸模型树里全是失败特征。这些热搜词背后的画面太熟悉了。所以当text-to-cad这个方向火起来的时候我第一反应是——终于有人想换个思路解决画图这件事了。text-to-cad说人话就是把我想画一个M8的内六角螺栓头部直径12有效螺纹长度20这种话直接丢给程序它给你吐出一个能编辑、能导出STEP、能塞进SolidWorks或Fusion 360的实体模型。不是贴图不是网格是正经的CAD实体。这篇文章我把原理、工具选型、实操流程和踩过的坑一次讲透内容偏工程向适合做机械结构、产品设计或者想用AI提效的工程师。1. 从画图到说图text-to-cad到底改了什么1.1 传统CAD的日常百分之八十的精力耗在怎么画上你回忆一下自己用CAD的一天打开软件先解决字体缺失警告SHX找不到就随便替换反正看着差不多。画个零件先想该用哪个命令F命令突然用不了原来是视图方向的问题。装配体改个尺寸关联特征连环报错模型树红成一片。更别提面对一堆散图的时候图纸合并、layout导入操作每一步都有一堆参数要调。我见过太多工程师包括我自己早期每天百分之八十的时间不是在设计而是在跟软件操作周旋。我做钣金件的时候更是如此金林钣金CAD版这种插件为什么有人用因为传统CAD里做展开图要手动算折弯扣除、K因子一不留神算错了下料就废了。这些痛点不是CAD不好而是**把脑子里的想法变成几何实体这个过程本身太慢**。text-to-cad切入的正是这个环节。1.2 核心价值把几何意图变成对话意图传统建模是你告诉软件怎么画——用哪个草图命令、画几条线、加什么约束、拉伸多少毫米。text-to-cad是你告诉程序要什么——零件是什么、大概什么形状、关键尺寸多少、有什么加工特征。底层的算法帮你把几何意图翻译成具体的建模操作序列。我举个例子。你想画一个带六个螺栓孔的法兰盘。传统做法画圆、拉伸、再画六个小圆、阵列、布尔减、倒角一共至少六七个步骤。text-to-cad的做法输入直径100mm的法兰中心孔30mm6个均布的直径8mm螺栓孔PCD 80mm程序自动规划出建模流程直接出结果。差距最大的是什么不是那几分钟的建模时间而是对可修改性的影响。程序生成的模型参数改起来比手动建模还要方便——你只要改一句文本描述重新生成就行。这在概念设计阶段特别有价值因为那时候方案一天要变好几版。1.3 这个赛道现在有什么能用的工具目前我能确认可用、而且实际测试过的方案大致分三类类型代表工具原理适合场景商业托管APIZooKittyCAD的Text-to-CADLLM直接生成BRep数据快速出概念模型愿意付费开源程序化建模LLMCadQuery 各类LLMLLM生成参数化Python代码自建流程、可控性强、免费传统CAD内置AISiemens NX、SolidWorks的AI辅助厂商自研功能已经在用特定CAD软件的企业其中Zoo的Text-to-CAD是风向标式的产品它的API输出的是原生BRep格式可以直接转STEP精度比网格建模高一个量级。但它是闭源托管服务要联网、要Key、可能要排队。CadQuery这条路线自由度更高后面第五章我会详细讲怎么用它搭一个本地text-to-cad工作流。2. 拆开看原理大模型凭什么能听懂几何描述2.1 最务实的落地路径程序化建模text-to-cad的实现原理网上聊得玄乎但拆开就三条路程序化建模、BRep直接生成、以及离工程很远的网格/点云生成。真正能用在工业环境里的是前两种而程序化建模是目前绝大多数开源方案的首选。什么叫程序化建模就是写代码生成模型。CadQuery、OpenSCAD、SolidPython都属于这一类。你写一段Python代码描述加一个20mm高的圆柱在顶部挖一个直径10mm的孔代码执行后交给CAD内核一般是OCCT算实体导出STEP。大模型在这里的作用是什么它是一个**需求翻译器**。它把自然语言翻译成CadQuery的API调用序列。你说画一个法兰盘它知道法兰盘大概长什么样然后生成对应代码。它本质上是在做代码生成只不过代码的领域是几何建模。这也是为什么开源路线可行——LLM写代码的能力已经被验证得很充分了而CadQuery的语法本身又足够简单小模型都能写个八九不离十。2.2 Zoo Text-to-CAD的推理链路跳过代码直接生成BRepZoo走了一条更激进的路不让LLM生成代码而是让模型直接输出BRep格式的几何数据。BRep是CAD内核真正存储实体的方式——有面、有边、有拓扑关系。Zoo的模型内部有ECCExtrude-Cut-Chamfer这样的原语架构通过预测挤出、切割、倒角的参数组合直接构造出几何实体。听起来很美好实际用下来的感受是几何正确性比代码生成路线更稳。因为代码路线有一个致命问题——代码写对了不代表几何就对布尔运算失败是常有的事。Zoo把几何操作这个环节封装进去减少了出错的概率。缺点就是闭源、收费、而且目前只能处理它见过的典型操作组合太怪异的几何需求还是不行。2.3 为什么网格生成路线走不通现在有很多AI生成3D模型的技术是基于扩散模型直接生成网格Mesh或者生成点云再重建曲面。这类方案看起来酷炫demo视频里什么都能生成。但工程上一用就露馅网格模型没有拓扑关系不能编辑特征更谈不上约束和容差。你转成STEP导入CAD里就是一堆没有特征的壳想改孔径只能重建。换句话说text-to-cad的难点从来不是生成一个看起来像的物体而是生成一个符合工程语义、能继续编辑的实体。这也是这个方向跟其他AI生成3D最大的不同。3. 方案选型免费开源路线和商业托管API的取舍3.1 先看一张对比表不是所有text-to-cad都一样我实际把几条路线都跑通了踩了不少坑直接说结论维度Zoo Text-to-CadCadQuery LLM自建传统CAD参数化建模成本API按次计费免费只要算力跑得动LLM软件授权费准确性几何正确率高依赖提示词工程完全可控可编辑性中等会丢失部分特征历史高保留完整建模代码最高学习门槛低调用API即可中要会CadQuery看软件熟练度部署形态联网、闭源本地、开源、可定制本地3.2 什么时候用Zoo什么时候自己搭如果项目时间紧、模型要求可靠而且预算允许Zoo是省心的选择。我拿它生成过一些标准件和简单结构件基本一次成型很少出现破面或者布尔失败。缺点除了钱就是延迟和限流——高峰期排队严重的时候一个简单零件等上半分钟都正常。如果项目对数据安全有要求或者需要高度定制输出格式那就走CadQuery LLM的自建路线。比如我需要把生成的模型自动加图号、塞进特定目录、直接出BOM这类工作只有自己搭才能做到。而且自建路线的可编辑性是最好的LLM生成的代码存下来就是一个参数化建模脚本后面想改尺寸直接改代码里的数字。我自己目前的主力方案是批量出概念模型用Zoo需要长期维护的零件用CadQuery自建。两条线并存不矛盾。3.3 自建路线的推荐架构python版本的架构大概是这个逻辑自然语言描述 ↓ LLM提示词工程把需求转成CadQuery代码 ↓ CadQuery执行代码生成实体 ↓ OCCT内核计算、检查几何有效性 ↓ 导出STEP/DXF/glTF ↓ CAD软件打开验证关键技术点在于前面那个LLM提示词工程。我用的提示词模板有固定结构目标描述 尺寸单位 关键尺寸列表 建模约束比如所有孔必须贯穿 输出格式要求。后面第五章实操里我会放一个完整示例。4. 实操从一个M8六角头螺栓到可编辑的STEP文件4.1 环境准备我假设你已经装好了Python 3.10或更高版本。CadQuery的安装很简单pip install cadquery如果想用Zoo的API去KittyCAD官网注册Key。不想注册也能跑通本地路线。需要注意一个坑CadQuery和Jupyter配合最顺因为它自带show()可以预览。但在纯脚本环境里要导出STEP再拿CAD软件看。我建议从一开始就建立生成→导出→验证的习惯不要信任屏幕预览。4.2 第一个示例用CadQuery生成法兰盘先用传统CadQuery手写一个法兰盘的代码让你感受一下程序化建模的语法import cadquery as cq # 法兰盘外径100中心孔306个均布φ8孔PCD 80 result ( cq.Workplane(XY) .circle(50) # 外圆半径50 .extrude(10) # 拉伸10mm .faces(Z) # 选顶面 .workplane() .hole(30) # 中心孔 .faces(Z) .workplane() .pushPoints([(40 * a, 0) for a in [0, 60, 120, 180, 240, 300]]) # 均布6点半径40 .hole(8) # 钻孔 .edges(Z) .fillet(1) # 顶部边倒角1mm ) # 导出STEP cq.exporters.export(result, flange.step)这段代码的逻辑很直白画圆→拉伸→选面→打孔→阵列打孔→倒角。跑完会得到flange.step直接拖进任何CAD软件都能打开编辑。4.3 让LLM来做这件事现在关键一步把我刚才手写的代码换成让LLM生成。提示词我实测这个写法最稳你是CAD建模专家。请根据需求生成CadQuery Python代码 零件法兰盘 外径100mm 厚度10mm 中心孔直径30mm 螺栓孔6个直径8mm均布在直径80mm的圆上PCD 80 顶部边缘倒角1mm 要求 1. 使用cadquery库所有尺寸单位为mm 2. 生成完整可执行的Python代码 3. 只输出代码不要解释这个提示词的关键是把尺寸和约束一次给全不让LLM瞎猜。我试过只写生成一个法兰盘结果它默认给了一堆莫名其妙的参数。写清楚外径100、厚度10、PCD 80之后生成结果基本稳定。跑出来的代码结构比我手写的还规整。而且你会发现一个好处改需求就是改文本。把PCD改成90mm——重新生成一次代码里的数字自动变比手动改参数树还快。4.4 用Zoo的Text-to-CAD出更复杂的模型遇到CadQuery代码生成搞不定的复杂几何比如有曲面、有复杂过渡的结构件我会切到Zoo API。调用方式其实就是一个POST请求但它背后的模型做了很多几何推理工作。import requests url https://api.zoo.dev/v1/tt/cad headers {Authorization: Bearer {YOUR_API_KEY}, Content-Type: application/json} payload { prompt: M8 hex bolt, head across flats 13mm, head height 6.5mm, shaft diameter 8mm, shaft length 40mm, thread pitch 1.25mm, format: step } r requests.post(url, jsonpayload, headersheaders) with open(m8_bolt.step, wb) as f: f.write(r.content)输出是STEP文件直接能用在装配体里。我多说一句Zoo对不同提示词风格的敏感度很高。写M8 bolt和写M8 hex bolt, head across flats 13mm得到的结果根本不是一回事后者几乎能精确还原国标尺寸。提示词要给全这里的技巧我放第五章讲。4.5 生成结果的验证清单拿到生成模型别急着用一定要做下面这些检查尺寸验证在CAD里量关键尺寸确认单位是毫米、数值符合预期。出现过LLM把PCD 80写成radius 80导致螺栓孔跑到外圆外面的情况。几何检查跑一下CAD的自带检查看有没有破面、干涉。干涉分析如果是装配体导入装配环境做干涉检查text-to-cad生成的零件经常在装配配合上出问题。5. 踩坑记录我在实际测试中遇到的四个问题5.1 单位漂移LLM的毫米幻觉第一次用Zoo生成一个轴类零件提示词里明确写了diameter 20mm导出来一量——直径0.02米数值没错但单位变成了米。这说明模型内心深处会把数值和单位拆开处理单位预测错了。这个问题的解决方式很粗暴在提示词里加一句All dimensions are in millimeters. Do not include units in the output.实测有效出错的概率下降很多。CadQuery路线没有这个问题因为代码里写死的就是毫米。但如果你接的是FreeCAD它的内部单位是毫米没错导出设置里可能会变成英寸注意检查。5.2 特征顺序错误导致布尔运算失败我让LLM生成一个带沉孔的安装板结果它先生成沉孔、再生成底板两个特征在空间上重合布尔减失败整个模型报错。教训是提示词里必须明确特征的先后顺序比如先创建底板然后在底板上打孔最后在孔口做沉头。实际代码里特征是顺序依赖的LLM不懂CAD的建模顺序你要替它规划好。这个问题的本质是text-to-cad模型目前对几何操作顺序的推理能力还偏弱。它知道什么是沉孔但不知道沉孔必须依附在已有实体上。我现在的提示词模板里专门有一栏建模步骤强制LLM按顺序输出。5.3 参数化不足生成一次就死了用Zoo生成的STEP文件导入SolidWorks模型树里只有一个输入实体没有特征历史。你想改孔径没门只能重做。相比之下CadQuery生成的代码保留了全部参数改一个数字就重新生成。所以我的经验是需要反复修改的零件永远走CadQuery代码生成路线一次性概念验证才用Zoo出网格或STEP。5.4 提示词工程真的比想象中重要最后说说提示词。很多人用text-to-cad觉得不好用八成是提示词写得太笼统。画一个齿轮——模型确实会生成一个齿轮但模数、齿数、压力角全是模型自己猜的大概率不是你要的。正确的姿势是像给加工厂下图纸一样写提示词。我会把关键尺寸、公差等级、表面处理、建模约束全写进去。以下是目前我的模板零件名称驱动法兰 材质6061铝合金 外形圆形法兰盘外径120mm厚度15mm 中心孔直径25mm带1mm×45°倒角 螺栓孔8个φ9mm通孔均布在直径100mm的圆周上 表面处理阳极氧化黑色 其余所有锐边倒角R1注意看我把表面处理也写进去了。虽然生成STEP时不会带表面处理属性但提示词中的这类信息会影响LLM对零件用途的判断从而间接影响几何形状。实测下来提示词越接近真实工程图生成结果越靠谱。6. 对CAD工作流程的影响我的几个判断6.1 工程师的活儿不会消失但会变看到这里你可能会担心text-to-cad是不是要取代CAD工程师我的看法恰恰相反。它取代的是基础重复建模这个动作而不是设计决策这件事。相反它逼着工程师把模糊的大概感觉变成清晰的尺寸和公差。你描述得越清楚生成结果越符合预期这个过程本身就是一种设计能力的体现。以前画一个概念模型要两小时用text-to-cad只要两分钟省下来的时间应该花在哪花在审模型上——观察它是否符合装配要求、加工约束、成本考量。我现在越来越觉得未来的CAD工程师是提需求者 审图者而不是绘图员。6.2 实际工作中的整合思路我这半年的工作流已经固定下来了概念设计阶段一天变好几版text-to-cadZoo出STEP → Fusion 360里快速装配看干涉 → 不满意就直接改文本重新生成。详细设计阶段要出图、要加工CadQuery代码生成 → 代码里写死尺寸参数 → 转进SolidWorks出二维图 → 手工补公差标注和表面粗糙度。标准件库批量用CadQuery生成国标件 → 存成带参数的STEP → 装配时直接从库调。这半年下来重复建模时间至少少了六成。最赚的是法兰、支架、盖板这类零件以前画一个半小时现在五分钟出STEP准确率还能保证。当然也有翻车的时候这时候记住text-to-cad本质上是把画图变成审图它负责快你负责对。顺便分享一个不算技巧的技巧生成完的STEP别急着导入大软件先用cq.edges()或者Zoo自带的预览快速看一眼轮廓。很多明显错误比如圆孔变成椭圆孔、尺寸错了十倍在预览阶段就能发现。我见过太多同事跳过了这个步骤把错误的模型拖进SolidWorks然后卡在模型报错哪里来的的排查里。text-to-cad不是魔法它只是一把更快的尺子——尺子再快也得有人去量、去看、去判断。少了这道人工把关再好的生成结果也只是一堆漂亮的几何垃圾。