1. 先拆清楚text-to-cad到底在解决什么问题先说个直观的场景。机械设计群里经常有人发一句话求助帮我画一个直径30mm、高度50mm、带M6螺纹孔的圆柱体。以前这种需求要么靠人手把手教建模步骤要么干脆甩一个教程链接让对方自己学。而现在这句话可以作为一个设计意图输入直接进入现代CAD流程并生成对应的三维实体模型。这就是text-to-cad这个方向在做的事情。不过我得先泼一盆冷水text-to-cad并不是你输入一句话软件就自动给你蹦出一个完美零件。它解决的是从模糊语言描述到明确几何表达这一段转化问题也就是把自然语言翻译成机器可以理解和执行的建模指令。至于这个模型做出来能不能加工、强度够不够、装配有没有干涉那是另一个层面的工作。搞清楚这个边界比急着上手更重要。从技术演进角度看text-to-cad其实站在两个大方向交汇点上一个是大语言模型LLM对语义和上下文的深度理解另一个是参数化建模和程序化建模的长期积累。早年CAD界就有过宏录制模板库之类的半自动化尝试但那些东西本质上还是人工预设规则换个说法就失效了。LLM带来的变化是你不需要预先写死规则模型可以通过海量语料和代码训练把带法兰的圆管接头这样一句描述对应到一堆具体的建模函数调用和参数赋值上。这是过去十年里最根本的差别。所以这篇文章我想围绕几个实操层面展开一是text-to-cad背后到底跑的是什么逻辑二是目前有哪些真正可用的工具和接入方式三是怎么把一句话变成真正可用于后续设计、修改、导出的CAD模型四是那些让新手崩溃、让老手抓狂的失败案例和参数设置问题最后是它的能力边界——知道它不能做什么比知道它能做什么更重要。适合看这篇文章的人我默认是这几类做机械设计、工业设计、非标自动化的人做3D打印、手办原型、快速打样的创客以及正在评估AI辅助设计工具、准备往团队工作流里引入这类能力的研发负责人。你可以没有深度编程背景但至少要明白CAD软件里特征草图约束这些基本概念不然后面聊到模型生成逻辑时会有点吃力。2. 两条技术路线的底层逻辑为什么有些工具懂你有些工具只会猜text-to-cad表面上看是一件事但实际落到实现层面目前市面上能跑通的东西基本都是两条路线之一。不搞清楚这一点你选工具的时候会被各种宣传口径带偏。2.1 路线一代码生成型用程序文本作为中间表达这条路线最主流核心逻辑是LLM先把你的自然语言描述转换为一串程序化建模代码然后由CAD内核执行这段代码最终生成实体模型。典型的底层库是CadQuery、build123d这种以Python为基底参数化建模库也有些工具走OpenSCAD的CSG构造实体几何语法。为什么这条路线会成为主流因为它在可编辑性和可追溯性上占了大便宜。生成的不是一堆无法修改的三角形网格而是一段带参数关系的程序。用户改一个数字变量整个模型的尺寸、位置、配合关系就能联动更新。这在工程场景里几乎是必备能力——一个零件如果改不了尺寸那它就是个摆件不是设计。举个具体例子你用CadQuery写一个带法兰的圆管大致是这样的逻辑import cadquery as cq result ( cq.Workplane(XY) .circle(20) # 外径40mm的圆 .extrude(60) # 拉伸60mm形成主管 .faces(Z) .workplane() .circle(35) .extrude(5) # 顶端加一个法兰盘 .faces(Z) .workplane() .rect(50, 50) .circle(6) .cutBlind(-5) # 法兰上挖四个安装孔 .edges() .fillet(1.5) )你让text-to-cad生成模型它做的就是把你的话转成这串代码或者类似的等价代码再去调内核执行。所以这类工具出模型的质量上限很大程度上取决于它对CadQuery这类API的掌握程度而不是它理解了你的话。2.2 路线二端到端生成型直接输出网格点云另一条路线更接近大众认知里的AI画画给文本直接输出一份网格模型或点云数据格式通常是STL、OBJ这类几何描述文件。这类工具在学术界和一些云端demo里很常见用户输入一把符合人体工学的椅子或者一个造型优雅的花瓶系统通过扩散模型或生成对抗网络直接输出三角网格。它的优点很直观上手门槛极低适合外观探索、概念造型、快速可视化。但它的问题也很致命输出不是参数化实体不能直接进装配体做配合也难以进行后续的特征编辑。你用这个流程生成的法兰圆管如果想要调整壁厚或者改孔位基本只能重新生成或者丢进Mesh-to-BRep网格转实体的工具里做逆向转换而那个转换过程的精度损失和拓扑修复工作量足矣消磨掉你省下来的所有时间。我个人的结论很直接如果目的是做机械结构或任何要拿去加工的零件优先选代码生成型工具。如果目的是外观概念、快速可视化、3D打印摆件端到端生成型完全够用。这两种工具的使用逻辑完全不同选错方向后面每一步都会别扭。3. 主流工具横向实测从云端Demo到本地工作流这两三年里text-to-cad相关工具冒出来不少有的是初创公司的在线产品有的是开源社区的实验项目还有的是传统CAD大厂内置的AI助手。我把自己实测下来印象比较深的几个工具整理成了一张对比表方便你建立初步印象。工具名称 / 项目技术路线输入形式输出格式可编辑性适合场景Zoo.dev Text to CAD代码生成CadQuery/OpenSCAD自然语言STL、STEP、GLB、参数化代码强代码可复用修改机械零件、3D打印件、参数化结构件Autodesk CADmT代码生成/API调用自然语言设计上下文依赖CAD平台格式强Fusion 360/SolidWorks流程里的辅助建模Local LLM CadQuery 自建代码生成自然语言STEP、STL强想保住数据隐私、需离线部署的团队Meshy/Point-E 类生成工具端到端网格生成文本/图片OBJ、STL、GLB弱需网格转实体概念造型、游戏资产、快速可视化BlenderGPT 文本建模插件代码生成 Blender API自然语言Blender工程中动画、视觉设计、非精密建模SolidWorks 内置智能建模辅助混合语义解析规则库自然语言SLDPRT强已有SW环境、需内部知识闭环的企业这张表里我特别想展开讲讲Zoo.dev因为它是目前社区里口碑比较稳的一个且能直接接入主流工作流。它的前端交互做得比开源项目友好免费额度对个人学习基本够用更重要的是它输出的不仅仅是模型还有一份你可以拿走继续改的代码。这就意味着你可以在它的基础上二次开发把常用的几个零件模板沉淀成自己的组件库。3.1 自建方案的不可忽视优势如果你所在的企业有数据合规要求比如图纸内容不能出内网那云端工具再香也白搭。自建方案其实没想象中复杂本地或私有云部署一个大模型推荐参数规模在7B到14B之间兼顾效果和显存虚拟环境里装好CadQuery和必要的Python包预置一份精心编写的CadQuery使用手册和示例库放进模型上下文做参考RAG或Few-shot自己写一个脚本把模型输出的代码抓出来、做语法检查、执行渲染预览。这套下来预算不高一台带24G显存的机器就够跑得很舒服。我自己测试过7B的模型配合Few-shot示例在标准机械零件上的生成成功率能到70%以上——这个数字在工程场景里已经有了实际应用价值尤其是把人工校验环节再压一压的话。4. 端到端实操从一段文字到一个可以修改的STEP文件好工具选定了接下来我们走一遍完整流程。我以Zoo.dev CadQuery路线为例目标是生成一个带四个安装孔的法兰底座这个零件简单但具备典型性能覆盖拉伸、打孔、倒角、阵列这些最常见的建模操作。4.1 第一步写一条可被机器理解的需求描述这一步是整个流程里最容易被低估的。很多人随便丢一句做个法兰就等着出图结果模型出来完全没法用然后得出text-to-cad是人工智障的结论。实际上问题大多出在描述侧。有效的描述应该包含这四个维度定位基准法兰在哪个平面上生长默认是XY平面但如果你不写模型很可能给出一个坐标轴上歪斜的结果。外形轮廓和关键尺寸直径多少、厚度多少、圆角多少。别只给一个大小这种定性词机器对形容词的理解远不如对数字的把握。孔系布置和规格孔的数量、分布圆直径、孔径大小这几个信息必须明确。特征操作类型是通孔还是盲孔要螺纹还是光孔要倒角还是倒圆角所以我推荐的输入长这样生成一个法兰底座。基准面为XY平面中心在原点。底座为直径80mm、厚度10mm的圆柱体中心有一个直径25mm的通孔。在直径为60mm的分布圆上均匀布置4个直径6.5mm的通孔。底座外缘倒圆角R3顶面边缘倒角C1。这条描述里包含了几乎每个特征的具体参数。你不需要一次性写完美但信息越完整生成结果质量越高。实测下来结构化描述的成功率往往是模糊描述的3倍以上。4.2 第二步生成、预览、检查输入描述后工具会先返回一段CadQuery代码和模型预览。这里我要强调的是拿到预览图别急着点头或摇头先旋转视角检查几个最容易出错的地方。最容易出错的有三处孔是不是真的通了。很多生成的代码里孔是用圆拉伸再切割实现的切割深度如果和板厚差0.0001mm显示上看着通了导出STEP拿去加工就会出问题。阵列的个数和分布圆直径是否匹配。4个孔分布在直径60mm的圆上它们之间的夹角是90度但如果模型在语义解析时4和60这两个数字配对错了出来的就会是3个孔或者分布在错误直径上。倒角/倒圆发生在哪个面。CadQuery里chamfer和fillet的调用对象是Edge而不是Face选错边导致的几何错误在预览里非常隐蔽。这个阶段强烈建议直接看生成的代码不要只看渲染结果。代码比图形诚实。4.3 第三步修正与导出实测下来一次生成就完美的概率并不高多数情况下需要你针对性问题做少量修正。比如上面那段描述生成的代码里孔没完全穿透、圆角选错边——这些是小问题直接在生成的代码里修改对应行的参数就行不需要重新写描述。比如这段修正逻辑# 错误只切了5mm深没穿透10mm厚的底座 .cutBlind(-5) # 修正改为穿透切割 .cutBlind(-12)改完代码重新执行得到预览确认无误后就可以导出为STEP文件。这个STEP文件是实体模型格式可以直接丢进FreeCAD、Fusion 360、SolidWorks里做后续设计也可以转成STL切片用于3D打印。我强烈建议你养成每生成一次就导出一个STEP并做版本标记的习惯。因为text-to-cad的生成过程有一定随机性你这次得到的结果即使同样代码也可能有微小差异保留版本才方便回溯。4.4 常见场景的实操参数速查表为了让你少走弯路我把做机械零件时最常用的设计意图和对应的CadQuery操作整理成一张速查表设计意图常用CadQuery方法关键参数建议常见坑点拉伸实体extrude()距离值注意正负方向方向反了导致实体在错误一侧挖通孔cutBlind()深度需大于材料厚度深度不够形成盲孔圆孔阵列polarArray/rectArray数量、分布圆直径要配对正确直径给错导致孔系错位倒圆角fillet()半径不能大于相邻面尺寸半径过大导致拓扑失败倒角chamfer()距离值须小于边长同样有拓扑阈值问题螺纹表达用螺旋扫掠HelixCut螺距和深度需匹配标准简化画法用装饰螺纹线更合理抽壳shell()壁厚值留足余量抽壳遇到孔会按外壳方向开口这张表是我的经验总结不是官方文档建议你收藏起来实际用的时候对照着来能规避掉大量莫名其妙的失败。5. 那些让新手崩溃的失败模式完整排查链路复盘text-to-cad的坑很多是工具本身之外的语言障碍。我把自己踩过的坑按现象→根因→解决路径的顺序梳理一遍这个思路也可以复制到其他类似的AI生成任务里。5.1 失败模式一生成模型巨大或微小到看不见现象描述输出预览区域一片空白或者出现一个比预期大几千倍的实体视角缩放也救不回来。根因分析这类问题九成出在单位换算缺失上。不同代码生成库的默认单位不一样CadQuery默认毫米OpenSCAD默认毫米但部分云端实现会换算成英寸而你描述里的50到底是毫米还是厘米没有体现模型就会按自己的默认单位来。修复路径在描述中明确写出单位不要只写数字。比如直径50mm而不要只写直径50。如果生成的代码里出现0.05、5000这类极端数值直接检查单位换算逻辑给长度参数乘上一个修正系数如25.4或1/25.4。自查清单描述里是否所有关键尺寸都标注了单位生成代码里的数值量级是否符合直觉多个尺寸之间的比例关系是否合理5.2 失败模式二草图轮廓自相交或无法闭合现象描述执行时报错像face could not be created或wire not closed或者生成了形状但表面出现肉眼可见的扭曲。根因分析这个问题的核心在于你描述的轮廓看起来没问题但几何上不自洽。比如你要一个正方形带一个圆角缺口不同工具对这两个特征的布尔运算顺序理解不同会导致自相交。修复路径别先怀疑工具把描述简化。把带缺口、带切角这类复合轮廓拆解成先画基础形状再执行布尔运算两段式描述。代码生成模型对于单步操作的成功率远高于复合操作。实战复盘我之前做过一个带方形观察窗的圆柱壳体按照完整描述去生成连续四次失败。后来改成两步先生成圆柱壳体再单独生成方形窗口特征并执行cut布尔减一次成功。经验就是复杂形状要拆步骤不要指望一句话搞定。5.3 失败模式三生成结果永远差一点点现象描述模型大体上是对的但某些细节和想象中的不一样——孔位偏了、圆角缺失、某个面没有倒角。根因分析一次给太多指令模型在长序列操作里出现注意力漂移。实验数据表明当指令包含5个以上独立特征时小模型的完成率会从70%骤降到40%上下。修复路径采用全局描述 局部追加的方式。第一次只描述基础外形和主要特征生成并通过检查后再追加次要特征描述比如在刚才的底座上继续添加一个通孔位置在X方向偏45mm处。这样模型每次处理的复杂度维持在一个合理水平。失败案例统计我实际统计过自己在不同指令数量下的生成效果单一特征描述的成功率约为85%5个特征混合描述的降低到50%左右8个特征以上基本只能当参考稿再手改。6. 影响出图质量的四个关键参数给文本做一次语义工程在text-to-cad里文本就是原料原料质量直接决定成品质量。下面这四个维度我每次写描述时会刻意检查。6.1 方位与参考基准的显式化大部分失败的根因是方位描述缺失。人脑默认上面模型默认副法线方向CAD软件默认全局坐标系——三者经常不一致。所以描述里要明确写上基准面为XY平面沿Z轴正方向拉伸孔的朝向为朝上把参考基准显式化。还有一个实操习惯描述每一个新增特征时先重述它的父特征。比如在圆柱体顶面Z方向所在面上打孔远比在顶部打孔可靠。这种写作方式对人工读可能冗余但对LLM是必要的定位信息。6.2 尺寸标注的密度与冗余在设计文本时我会遵循一个原则能加数字的地方都加数字数字边上配上单位必要时用约来标记非关键公差。比如差描述底座厚度适中好描述底座厚度10mm允许±0.1mm这样做的本质是给模型减少自由度。LLM本质上是概率预测器在模糊表述上它确实自由发挥而这个自由度在工程里就是不可控变量。你钉得越死生成越稳。6.3 特征类型的精确命名很多新手用生活语言描述特征结果模型执行了错误的建模操作。比如挖一条槽和创建一条凹槽在代码生成模型里可能指向完全不同的操作序列。槽在制造语境里是圆形铣刀走过的形状Slot凹槽是在面上做的凹陷Groove/Recess两者的CadQuery实现完全不同。解决办法把你想要的特征翻译成CAD术语再输入。哪怕你不记得精确术语也尽量用拉伸切除旋转切除扫掠这类操作型词汇而不是开个口挖个孔这类生活化词汇。6.4 约束关系的逻辑链条在有配合关系的零部件描述里这一点是最值钱的。比如法兰上四个孔分布在直径60mm的圆上等间距这串描述里其实隐含了一个非常关键的约束孔与孔之间的角间距是90度。模型需要自己推导出等分角一个常用技巧是显式写出相邻孔夹角90度。工程零件的装配和配合关系应该在描述里以另一种结构化方式呈现体积配合孔与轴间隙、位置配合中心对齐、公差配合H7/h6这类加工配合代号。text-to-cad模型不会主动知道这些细节你不写它就默认不做。7. 背后的工程价值恰好解决从意向到草图这一步的浪费把text-to-cad放进更大场景里看会发现一个很有价值的点。传统设计流程里方案讨论阶段的很多意向没法快速变成可视化草模一个零件如果只是简单地板状壳体可能完全不值得投入一小时的建模时间但如果画了一小时才发现方向错了那个时间就白白浪费了。text-to-cad的出现恰好能填补这段空白。举个例子我之前做一个非标自动化项目需要在装配方案会上快速评估几个不同规格的电机安装板。参数无非是底板尺寸、安装孔位置、中心高度这三组数。用传统方式每个规格画一遍至少15到20分钟三个规格就是将近一小时。而用text-to-cad流程把同一段模板描述改几个数字每个版本三分钟出STEP直接拉到装配体里做干涉检查。这在提案阶段的价值是巨大的。同样地逆向工程里也会用。客户给一张模糊的草图照片和几句话的尺寸要求以前要重新建模猜意图现在先把关键尺寸和连接关系列出来直接生成几个候选模型给客户确认让客户在半成品上提意见而不是对着空气讨论。但也要清醒text-to-cad不能替代结构计算和强度校核。它能帮你快速把几何形状做出来但应力分析、疲劳寿命、运动仿真这些重活还是得依赖传统分析工具。所以更准确地说这个技术的落点是把设计意图到初步几何之间的死重解掉让人的精力集中在真正需要工程判断的地方。8. 自建text-to-cad工作流时的几个接地气建议如果看完上面的实测你动了自建一套的念头我最后再给你几个接地气的建议。第一个建议是不要一开始就追求大模型。很多人问你要部署就是至少要70B的模型吧其实不是。在text-to-cad这类任务里7B到14B的模型配合精心设计的Few-shot提示词效果已经相当能打而且推理速度快吃显存少。真正决定效果上限的是你预置的CadQuery示例代码够不够贴切、说明文档够不够清晰。模型只是个翻译器翻译得准不准取决于参考语料好不好。第二个建议是把输出的代码纳入代码审查流程。就像团队里别人提交的代码要review一样text-to-cad生成的代码也应该被审查后再投入使用。这也意味着你团队里至少要有一个懂CadQuery或build123d的人这个人不需要是AI专家但需要能在关键时刻判断代码是能跑还是跑对了。实测下来能跑但结构逻辑有问题的代码占比不低靠人工审查能把这类问题在进入CAD内核前拦下来。第三个建议是不要只把text-to-cad当生成器要当模板库。当你某次生成了一版结构非常漂亮的代码保存下来清洗变量名写清楚注释沉淀进你的私有组件库。下一次遇到类似需求时直接复用那套代码结构只需改几个参数。这个从AI生成到人工沉淀再到AI复用的闭环才是这个技术最大的价值。我的个人经验是持续沉淀三个月之后我可以处理的需求范围会大幅扩大因为我的组件库越来越丰富新需求的描述可以精确地指到已有的代码结构上。最后一个建议是务必设立人工确认环节。AI生成的模型必须有人在发布或加工前做最终确认这是工程伦理也是职业保护。不要因为工具输出得快就放松把关加工一个报废件的成本远比手动建模高得多。你要把text-to-cad当成一个手脚特别快的实习生而不是免检的设计师。text-to-cad这个方向还处在快速迭代期每几个月就有新的模型、新的接口、新的实践出现在社区里。我先说句实在话目前它在精密机械结构上还替代不了有经验的建模工程师但在概念快速验证、标准化零件出图、跨部门沟通可视化这些环节它已经开始实打实地提升效率了。如果你手头正好有一个参数明确的简单零件需求我建议你今晚就拿它试一次text-to-cad——试完你大概就能理解我把这个流程比作给AI配了一把CAD的钥匙是什么意思了。 
长河君 · 2026/10/26 16:02:50 · 阅读 1.2k text-to-cad技术解析：从自然语言到可编辑CAD模型的生成逻辑
1. 先拆清楚text-to-cad到底在解决什么问题先说个直观的场景。机械设计群里经常有人发一句话求助帮我画一个直径30mm、高度50mm、带M6螺纹孔的圆柱体。以前这种需求要么靠人手把手教建模步骤要么干脆甩一个教程链接让对方自己学。而现在这句话可以作为一个设计意图输入直接进入现代CAD流程并生成对应的三维实体模型。这就是text-to-cad这个方向在做的事情。不过我得先泼一盆冷水text-to-cad并不是你输入一句话软件就自动给你蹦出一个完美零件。它解决的是从模糊语言描述到明确几何表达这一段转化问题也就是把自然语言翻译成机器可以理解和执行的建模指令。至于这个模型做出来能不能加工、强度够不够、装配有没有干涉那是另一个层面的工作。搞清楚这个边界比急着上手更重要。从技术演进角度看text-to-cad其实站在两个大方向交汇点上一个是大语言模型LLM对语义和上下文的深度理解另一个是参数化建模和程序化建模的长期积累。早年CAD界就有过宏录制模板库之类的半自动化尝试但那些东西本质上还是人工预设规则换个说法就失效了。LLM带来的变化是你不需要预先写死规则模型可以通过海量语料和代码训练把带法兰的圆管接头这样一句描述对应到一堆具体的建模函数调用和参数赋值上。这是过去十年里最根本的差别。所以这篇文章我想围绕几个实操层面展开一是text-to-cad背后到底跑的是什么逻辑二是目前有哪些真正可用的工具和接入方式三是怎么把一句话变成真正可用于后续设计、修改、导出的CAD模型四是那些让新手崩溃、让老手抓狂的失败案例和参数设置问题最后是它的能力边界——知道它不能做什么比知道它能做什么更重要。适合看这篇文章的人我默认是这几类做机械设计、工业设计、非标自动化的人做3D打印、手办原型、快速打样的创客以及正在评估AI辅助设计工具、准备往团队工作流里引入这类能力的研发负责人。你可以没有深度编程背景但至少要明白CAD软件里特征草图约束这些基本概念不然后面聊到模型生成逻辑时会有点吃力。2. 两条技术路线的底层逻辑为什么有些工具懂你有些工具只会猜text-to-cad表面上看是一件事但实际落到实现层面目前市面上能跑通的东西基本都是两条路线之一。不搞清楚这一点你选工具的时候会被各种宣传口径带偏。2.1 路线一代码生成型用程序文本作为中间表达这条路线最主流核心逻辑是LLM先把你的自然语言描述转换为一串程序化建模代码然后由CAD内核执行这段代码最终生成实体模型。典型的底层库是CadQuery、build123d这种以Python为基底参数化建模库也有些工具走OpenSCAD的CSG构造实体几何语法。为什么这条路线会成为主流因为它在可编辑性和可追溯性上占了大便宜。生成的不是一堆无法修改的三角形网格而是一段带参数关系的程序。用户改一个数字变量整个模型的尺寸、位置、配合关系就能联动更新。这在工程场景里几乎是必备能力——一个零件如果改不了尺寸那它就是个摆件不是设计。举个具体例子你用CadQuery写一个带法兰的圆管大致是这样的逻辑import cadquery as cq result ( cq.Workplane(XY) .circle(20) # 外径40mm的圆 .extrude(60) # 拉伸60mm形成主管 .faces(Z) .workplane() .circle(35) .extrude(5) # 顶端加一个法兰盘 .faces(Z) .workplane() .rect(50, 50) .circle(6) .cutBlind(-5) # 法兰上挖四个安装孔 .edges() .fillet(1.5) )你让text-to-cad生成模型它做的就是把你的话转成这串代码或者类似的等价代码再去调内核执行。所以这类工具出模型的质量上限很大程度上取决于它对CadQuery这类API的掌握程度而不是它理解了你的话。2.2 路线二端到端生成型直接输出网格点云另一条路线更接近大众认知里的AI画画给文本直接输出一份网格模型或点云数据格式通常是STL、OBJ这类几何描述文件。这类工具在学术界和一些云端demo里很常见用户输入一把符合人体工学的椅子或者一个造型优雅的花瓶系统通过扩散模型或生成对抗网络直接输出三角网格。它的优点很直观上手门槛极低适合外观探索、概念造型、快速可视化。但它的问题也很致命输出不是参数化实体不能直接进装配体做配合也难以进行后续的特征编辑。你用这个流程生成的法兰圆管如果想要调整壁厚或者改孔位基本只能重新生成或者丢进Mesh-to-BRep网格转实体的工具里做逆向转换而那个转换过程的精度损失和拓扑修复工作量足矣消磨掉你省下来的所有时间。我个人的结论很直接如果目的是做机械结构或任何要拿去加工的零件优先选代码生成型工具。如果目的是外观概念、快速可视化、3D打印摆件端到端生成型完全够用。这两种工具的使用逻辑完全不同选错方向后面每一步都会别扭。3. 主流工具横向实测从云端Demo到本地工作流这两三年里text-to-cad相关工具冒出来不少有的是初创公司的在线产品有的是开源社区的实验项目还有的是传统CAD大厂内置的AI助手。我把自己实测下来印象比较深的几个工具整理成了一张对比表方便你建立初步印象。工具名称 / 项目技术路线输入形式输出格式可编辑性适合场景Zoo.dev Text to CAD代码生成CadQuery/OpenSCAD自然语言STL、STEP、GLB、参数化代码强代码可复用修改机械零件、3D打印件、参数化结构件Autodesk CADmT代码生成/API调用自然语言设计上下文依赖CAD平台格式强Fusion 360/SolidWorks流程里的辅助建模Local LLM CadQuery 自建代码生成自然语言STEP、STL强想保住数据隐私、需离线部署的团队Meshy/Point-E 类生成工具端到端网格生成文本/图片OBJ、STL、GLB弱需网格转实体概念造型、游戏资产、快速可视化BlenderGPT 文本建模插件代码生成 Blender API自然语言Blender工程中动画、视觉设计、非精密建模SolidWorks 内置智能建模辅助混合语义解析规则库自然语言SLDPRT强已有SW环境、需内部知识闭环的企业这张表里我特别想展开讲讲Zoo.dev因为它是目前社区里口碑比较稳的一个且能直接接入主流工作流。它的前端交互做得比开源项目友好免费额度对个人学习基本够用更重要的是它输出的不仅仅是模型还有一份你可以拿走继续改的代码。这就意味着你可以在它的基础上二次开发把常用的几个零件模板沉淀成自己的组件库。3.1 自建方案的不可忽视优势如果你所在的企业有数据合规要求比如图纸内容不能出内网那云端工具再香也白搭。自建方案其实没想象中复杂本地或私有云部署一个大模型推荐参数规模在7B到14B之间兼顾效果和显存虚拟环境里装好CadQuery和必要的Python包预置一份精心编写的CadQuery使用手册和示例库放进模型上下文做参考RAG或Few-shot自己写一个脚本把模型输出的代码抓出来、做语法检查、执行渲染预览。这套下来预算不高一台带24G显存的机器就够跑得很舒服。我自己测试过7B的模型配合Few-shot示例在标准机械零件上的生成成功率能到70%以上——这个数字在工程场景里已经有了实际应用价值尤其是把人工校验环节再压一压的话。4. 端到端实操从一段文字到一个可以修改的STEP文件好工具选定了接下来我们走一遍完整流程。我以Zoo.dev CadQuery路线为例目标是生成一个带四个安装孔的法兰底座这个零件简单但具备典型性能覆盖拉伸、打孔、倒角、阵列这些最常见的建模操作。4.1 第一步写一条可被机器理解的需求描述这一步是整个流程里最容易被低估的。很多人随便丢一句做个法兰就等着出图结果模型出来完全没法用然后得出text-to-cad是人工智障的结论。实际上问题大多出在描述侧。有效的描述应该包含这四个维度定位基准法兰在哪个平面上生长默认是XY平面但如果你不写模型很可能给出一个坐标轴上歪斜的结果。外形轮廓和关键尺寸直径多少、厚度多少、圆角多少。别只给一个大小这种定性词机器对形容词的理解远不如对数字的把握。孔系布置和规格孔的数量、分布圆直径、孔径大小这几个信息必须明确。特征操作类型是通孔还是盲孔要螺纹还是光孔要倒角还是倒圆角所以我推荐的输入长这样生成一个法兰底座。基准面为XY平面中心在原点。底座为直径80mm、厚度10mm的圆柱体中心有一个直径25mm的通孔。在直径为60mm的分布圆上均匀布置4个直径6.5mm的通孔。底座外缘倒圆角R3顶面边缘倒角C1。这条描述里包含了几乎每个特征的具体参数。你不需要一次性写完美但信息越完整生成结果质量越高。实测下来结构化描述的成功率往往是模糊描述的3倍以上。4.2 第二步生成、预览、检查输入描述后工具会先返回一段CadQuery代码和模型预览。这里我要强调的是拿到预览图别急着点头或摇头先旋转视角检查几个最容易出错的地方。最容易出错的有三处孔是不是真的通了。很多生成的代码里孔是用圆拉伸再切割实现的切割深度如果和板厚差0.0001mm显示上看着通了导出STEP拿去加工就会出问题。阵列的个数和分布圆直径是否匹配。4个孔分布在直径60mm的圆上它们之间的夹角是90度但如果模型在语义解析时4和60这两个数字配对错了出来的就会是3个孔或者分布在错误直径上。倒角/倒圆发生在哪个面。CadQuery里chamfer和fillet的调用对象是Edge而不是Face选错边导致的几何错误在预览里非常隐蔽。这个阶段强烈建议直接看生成的代码不要只看渲染结果。代码比图形诚实。4.3 第三步修正与导出实测下来一次生成就完美的概率并不高多数情况下需要你针对性问题做少量修正。比如上面那段描述生成的代码里孔没完全穿透、圆角选错边——这些是小问题直接在生成的代码里修改对应行的参数就行不需要重新写描述。比如这段修正逻辑# 错误只切了5mm深没穿透10mm厚的底座 .cutBlind(-5) # 修正改为穿透切割 .cutBlind(-12)改完代码重新执行得到预览确认无误后就可以导出为STEP文件。这个STEP文件是实体模型格式可以直接丢进FreeCAD、Fusion 360、SolidWorks里做后续设计也可以转成STL切片用于3D打印。我强烈建议你养成每生成一次就导出一个STEP并做版本标记的习惯。因为text-to-cad的生成过程有一定随机性你这次得到的结果即使同样代码也可能有微小差异保留版本才方便回溯。4.4 常见场景的实操参数速查表为了让你少走弯路我把做机械零件时最常用的设计意图和对应的CadQuery操作整理成一张速查表设计意图常用CadQuery方法关键参数建议常见坑点拉伸实体extrude()距离值注意正负方向方向反了导致实体在错误一侧挖通孔cutBlind()深度需大于材料厚度深度不够形成盲孔圆孔阵列polarArray/rectArray数量、分布圆直径要配对正确直径给错导致孔系错位倒圆角fillet()半径不能大于相邻面尺寸半径过大导致拓扑失败倒角chamfer()距离值须小于边长同样有拓扑阈值问题螺纹表达用螺旋扫掠HelixCut螺距和深度需匹配标准简化画法用装饰螺纹线更合理抽壳shell()壁厚值留足余量抽壳遇到孔会按外壳方向开口这张表是我的经验总结不是官方文档建议你收藏起来实际用的时候对照着来能规避掉大量莫名其妙的失败。5. 那些让新手崩溃的失败模式完整排查链路复盘text-to-cad的坑很多是工具本身之外的语言障碍。我把自己踩过的坑按现象→根因→解决路径的顺序梳理一遍这个思路也可以复制到其他类似的AI生成任务里。5.1 失败模式一生成模型巨大或微小到看不见现象描述输出预览区域一片空白或者出现一个比预期大几千倍的实体视角缩放也救不回来。根因分析这类问题九成出在单位换算缺失上。不同代码生成库的默认单位不一样CadQuery默认毫米OpenSCAD默认毫米但部分云端实现会换算成英寸而你描述里的50到底是毫米还是厘米没有体现模型就会按自己的默认单位来。修复路径在描述中明确写出单位不要只写数字。比如直径50mm而不要只写直径50。如果生成的代码里出现0.05、5000这类极端数值直接检查单位换算逻辑给长度参数乘上一个修正系数如25.4或1/25.4。自查清单描述里是否所有关键尺寸都标注了单位生成代码里的数值量级是否符合直觉多个尺寸之间的比例关系是否合理5.2 失败模式二草图轮廓自相交或无法闭合现象描述执行时报错像face could not be created或wire not closed或者生成了形状但表面出现肉眼可见的扭曲。根因分析这个问题的核心在于你描述的轮廓看起来没问题但几何上不自洽。比如你要一个正方形带一个圆角缺口不同工具对这两个特征的布尔运算顺序理解不同会导致自相交。修复路径别先怀疑工具把描述简化。把带缺口、带切角这类复合轮廓拆解成先画基础形状再执行布尔运算两段式描述。代码生成模型对于单步操作的成功率远高于复合操作。实战复盘我之前做过一个带方形观察窗的圆柱壳体按照完整描述去生成连续四次失败。后来改成两步先生成圆柱壳体再单独生成方形窗口特征并执行cut布尔减一次成功。经验就是复杂形状要拆步骤不要指望一句话搞定。5.3 失败模式三生成结果永远差一点点现象描述模型大体上是对的但某些细节和想象中的不一样——孔位偏了、圆角缺失、某个面没有倒角。根因分析一次给太多指令模型在长序列操作里出现注意力漂移。实验数据表明当指令包含5个以上独立特征时小模型的完成率会从70%骤降到40%上下。修复路径采用全局描述 局部追加的方式。第一次只描述基础外形和主要特征生成并通过检查后再追加次要特征描述比如在刚才的底座上继续添加一个通孔位置在X方向偏45mm处。这样模型每次处理的复杂度维持在一个合理水平。失败案例统计我实际统计过自己在不同指令数量下的生成效果单一特征描述的成功率约为85%5个特征混合描述的降低到50%左右8个特征以上基本只能当参考稿再手改。6. 影响出图质量的四个关键参数给文本做一次语义工程在text-to-cad里文本就是原料原料质量直接决定成品质量。下面这四个维度我每次写描述时会刻意检查。6.1 方位与参考基准的显式化大部分失败的根因是方位描述缺失。人脑默认上面模型默认副法线方向CAD软件默认全局坐标系——三者经常不一致。所以描述里要明确写上基准面为XY平面沿Z轴正方向拉伸孔的朝向为朝上把参考基准显式化。还有一个实操习惯描述每一个新增特征时先重述它的父特征。比如在圆柱体顶面Z方向所在面上打孔远比在顶部打孔可靠。这种写作方式对人工读可能冗余但对LLM是必要的定位信息。6.2 尺寸标注的密度与冗余在设计文本时我会遵循一个原则能加数字的地方都加数字数字边上配上单位必要时用约来标记非关键公差。比如差描述底座厚度适中好描述底座厚度10mm允许±0.1mm这样做的本质是给模型减少自由度。LLM本质上是概率预测器在模糊表述上它确实自由发挥而这个自由度在工程里就是不可控变量。你钉得越死生成越稳。6.3 特征类型的精确命名很多新手用生活语言描述特征结果模型执行了错误的建模操作。比如挖一条槽和创建一条凹槽在代码生成模型里可能指向完全不同的操作序列。槽在制造语境里是圆形铣刀走过的形状Slot凹槽是在面上做的凹陷Groove/Recess两者的CadQuery实现完全不同。解决办法把你想要的特征翻译成CAD术语再输入。哪怕你不记得精确术语也尽量用拉伸切除旋转切除扫掠这类操作型词汇而不是开个口挖个孔这类生活化词汇。6.4 约束关系的逻辑链条在有配合关系的零部件描述里这一点是最值钱的。比如法兰上四个孔分布在直径60mm的圆上等间距这串描述里其实隐含了一个非常关键的约束孔与孔之间的角间距是90度。模型需要自己推导出等分角一个常用技巧是显式写出相邻孔夹角90度。工程零件的装配和配合关系应该在描述里以另一种结构化方式呈现体积配合孔与轴间隙、位置配合中心对齐、公差配合H7/h6这类加工配合代号。text-to-cad模型不会主动知道这些细节你不写它就默认不做。7. 背后的工程价值恰好解决从意向到草图这一步的浪费把text-to-cad放进更大场景里看会发现一个很有价值的点。传统设计流程里方案讨论阶段的很多意向没法快速变成可视化草模一个零件如果只是简单地板状壳体可能完全不值得投入一小时的建模时间但如果画了一小时才发现方向错了那个时间就白白浪费了。text-to-cad的出现恰好能填补这段空白。举个例子我之前做一个非标自动化项目需要在装配方案会上快速评估几个不同规格的电机安装板。参数无非是底板尺寸、安装孔位置、中心高度这三组数。用传统方式每个规格画一遍至少15到20分钟三个规格就是将近一小时。而用text-to-cad流程把同一段模板描述改几个数字每个版本三分钟出STEP直接拉到装配体里做干涉检查。这在提案阶段的价值是巨大的。同样地逆向工程里也会用。客户给一张模糊的草图照片和几句话的尺寸要求以前要重新建模猜意图现在先把关键尺寸和连接关系列出来直接生成几个候选模型给客户确认让客户在半成品上提意见而不是对着空气讨论。但也要清醒text-to-cad不能替代结构计算和强度校核。它能帮你快速把几何形状做出来但应力分析、疲劳寿命、运动仿真这些重活还是得依赖传统分析工具。所以更准确地说这个技术的落点是把设计意图到初步几何之间的死重解掉让人的精力集中在真正需要工程判断的地方。8. 自建text-to-cad工作流时的几个接地气建议如果看完上面的实测你动了自建一套的念头我最后再给你几个接地气的建议。第一个建议是不要一开始就追求大模型。很多人问你要部署就是至少要70B的模型吧其实不是。在text-to-cad这类任务里7B到14B的模型配合精心设计的Few-shot提示词效果已经相当能打而且推理速度快吃显存少。真正决定效果上限的是你预置的CadQuery示例代码够不够贴切、说明文档够不够清晰。模型只是个翻译器翻译得准不准取决于参考语料好不好。第二个建议是把输出的代码纳入代码审查流程。就像团队里别人提交的代码要review一样text-to-cad生成的代码也应该被审查后再投入使用。这也意味着你团队里至少要有一个懂CadQuery或build123d的人这个人不需要是AI专家但需要能在关键时刻判断代码是能跑还是跑对了。实测下来能跑但结构逻辑有问题的代码占比不低靠人工审查能把这类问题在进入CAD内核前拦下来。第三个建议是不要只把text-to-cad当生成器要当模板库。当你某次生成了一版结构非常漂亮的代码保存下来清洗变量名写清楚注释沉淀进你的私有组件库。下一次遇到类似需求时直接复用那套代码结构只需改几个参数。这个从AI生成到人工沉淀再到AI复用的闭环才是这个技术最大的价值。我的个人经验是持续沉淀三个月之后我可以处理的需求范围会大幅扩大因为我的组件库越来越丰富新需求的描述可以精确地指到已有的代码结构上。最后一个建议是务必设立人工确认环节。AI生成的模型必须有人在发布或加工前做最终确认这是工程伦理也是职业保护。不要因为工具输出得快就放松把关加工一个报废件的成本远比手动建模高得多。你要把text-to-cad当成一个手脚特别快的实习生而不是免检的设计师。text-to-cad这个方向还处在快速迭代期每几个月就有新的模型、新的接口、新的实践出现在社区里。我先说句实在话目前它在精密机械结构上还替代不了有经验的建模工程师但在概念快速验证、标准化零件出图、跨部门沟通可视化这些环节它已经开始实打实地提升效率了。如果你手头正好有一个参数明确的简单零件需求我建议你今晚就拿它试一次text-to-cad——试完你大概就能理解我把这个流程比作给AI配了一把CAD的钥匙是什么意思了。