我最早被“text-to-cad”这个词吸引是因为一句特别朴素的话跟软件说人话软件还你真模型。不需要菜单点半天不查命令手册不打草稿——直接说“我要一个带四个安装孔的L型角码板厚3mm”十个手指头就能敲完的一段自然语言回车之后屏幕上真的出现了一个能旋转、能缩放、能改尺寸的三维零件。老实讲第一次看到这个结果时我是有点头皮发麻的。但先别急着高潮。用了一个多月我的判断是text-to-cad很香香在有边界里它不是万能出图机别指望它直接吐出一张带标注、带图层、带图框的施工图。这篇内容我想认真拆一拆text-to-cad到底是什么、有哪些路线能落地、原理上它凭什么能把语言变成模型以及我在实际建模流程里踩过的那些坑。适合正在做机械结构设计、钣金、非标零件、创客打样或者日常要跟AutoCAD、中望CAD打交道的工程师朋友参考。1. 先说清醒话text-to-cad真正交出的是“可编辑模型”不是成品图纸1.1 它和“AI画图”根本不是一回事很多人第一次看到text-to-cad脑子里浮现的是Midjourney那种输入一句话出图的画面。这个联想基本是错的。text-to-cad产出的不是一张位图也不是一串不可编辑的网格而是带参数的可编辑CAD对象——在AutoCAD官方方案里是原生图元和实体在开源方案里是一段参数化建模脚本在LLM库的组合方案里是一段Python或OpenSCAD代码。换句话说LLM在这里干的是“写代码的建模工程师”的活真正的几何计算和渲染由背后的程序化建模内核完成。这个区别非常重要因为它决定了你能拿它干什么结果是参数化的、可进CAD继续编辑的而不是一次性图片。正因为它是一个“活”的模型你才能改尺寸、做系列件、汇入装配体这才是工程意义上的价值。1.2 哪些场景真正受益哪些场景别指望我连续实测了机械小零件、支架角码、法兰盘、外壳底座、简易钣金件以及与建筑相关的构件形体。text-to-cad在这些场景下的表现确实能省掉大量重复建模时间尤其是“形状清晰、尺寸明确、约束简单”的零件基本是降维打击。反过来也有明显的盲区。复杂曲面大曲面、自由造型类工业设计靠文本描述很难约束生成结果基本是“看起来像实际上歪”。大装配体几十上百个零件的装配关系、约束配合LLM目前的上下文和空间推理能力扛不住。完整施工图标注、公差、粗糙度、图层规范、图框、图纸目录这些不是生成模型能解决的必须靠CAD软件人工完成。高精配合公差等级、过盈配合、同轴度等微米级要求目前的生成逻辑还达不到经验工程师的判断水平。1.3 我给的定位一个“懂点设计的快速建模同事”用下来我的结论是text-to-cad最合适的定位是给你配了一个“懂点设计的快速建模同事”。他上手很快能照着你的要求出第一版模型速度非常惊人但你让他直接交付生产图纸他会给你一堆需要返工的东西。你要做的是把它当作前期方案和标准件建模的加速器而不是替代CAD工程师的出图工具。想清楚这个边界接下来的使用体验会好很多。2. 主流text-to-cad实现路线这段时间实测过的三种方案2.1 AutoDesk官方路线AutoCAD里的文本转CAD能力AutoDesk在2025版AutoCAD中开始内置text-to-cad能力直接在AutoCAD里输入自然语言描述可以在模型空间中生成对象。这条路线的优点是很“正统”生成的图元和AutoCAD原生环境完全打通后续编辑、加标注、出图都在同一套流程里不需要额外转格式。不过它也有自己的限制依赖AutoCAD环境需要账号和正版订阅对中文描述的支持以及生成结果的复杂程度目前还处于“能跑但别太刁难它”的阶段。如果你本身就是AutoCAD的重度用户这一条值得关注如果你只是在需要时接个图后面的开源方案可能更轻便。2.2 开源路线Zoo Text-to-CAD OpenSCADZoo Text-to-CAD是zoo.dev推出的开源项目核心理念是用LLM直接生成OpenSCAD脚本然后在网页或本地渲染出可交互的三维模型。这条路我在实际项目里用得最多。选择它的原因其实很朴素OpenSCAD本身就是“以代码建模”的工具几何完全由脚本定义天然适合机器生成。生成结果是文本脚本你可以逐行检查、修改参数比黑盒生成更可控。完全本地可跑隐私性可控不依赖商业云服务。导出DXF/STL非常顺畅后续进任何CAD软件都不费劲。2.3 自己拼装路线LLM CadQuery/FreeCAD脚本第三种路线适合有一定Python基础、想把text-to-cad嵌进自动化流程里的工程师。原理很简单用大模型辅助生成CadQueryPython库的代码然后本地执行代码生成几何模型并导出STEP/DXF。CadQuery和OpenSCAD的底层思路不一样。OpenSCAD用的是CSG构造实体几何的代码化表达CadQuery则是“以面向过程的方式描述建模步骤”——拉伸、切槽、开孔、倒角更像传统CAD建模顺序。所以在需要精确控制建模逻辑、或者要建复杂零件时CadQuery的生成结果往往更接近工程师的习惯。2.4 三方案横向对比与选型判断对比维度AutoDesk官方Zoo Text-to-CAD OpenSCADLLM CadQuery/FreeCAD上手门槛低在AutoCAD内直接用低浏览器可用中需要Python基础结果可编辑性AutoCAD原生对象编辑方便OpenSCAD脚本改参数重生CadQuery脚本改代码重生导出格式DWG/DXF等原生格式STL/DXFSTEP需中转STEP/DXF工程格式更全复杂曲面能力弱弱中等批量自动化一般好脚本可批量最好适合程序控制环境依赖官方订阅开源免费开源免费选型上我的建议很简单日常出图用AutoCAD的优先研究官方路线想免费快速验证概念直接试Zoo要做批量系列件和自动化流程就上CadQuery方案。三条路不冲突反而是互补的。3. 它凭什么能工作自然语言驱动参数化建模的底层逻辑3.1 LLM的角色是“写脚本的工程师”不是几何内核要理解text-to-cad为什么能跑通必须先厘清一个分工LLM不负责计算几何它负责把自然语言转换成一段可执行的建模脚本。你在提示词里描述一个法兰盘LLM根据海量训练数据里见过的建模套路生成一串OpenSCAD或CadQuery代码然后由OpenSCAD/CadQuery的计算内核把这个脚本编译成真实的实体模型。这就像你请了个学过制图的助理他听懂了你的需求然后帮你把图纸画出来——画图的是CAD软件理解需求并转译成图纸语言的是助理。3.2 为什么程序化建模适合LLM输出这里有个非常核心的原因程序化建模把几何变成了一串有逻辑、有序、有参数的“指令序列”这恰好是LLM最擅长的输出形式。比如描述一个带螺栓孔的法兰盘程序化脚本的逻辑是创建一个圆柱体外径、高度减去一个同心圆柱体内径、高度在指定半径的圆周上均匀切出N个螺栓孔对边缘做倒角每一步都是“函数参数”LLM只要理解“是什么形状、尺寸多大、位置在哪、做什么运算”就能把它翻译成代码。这比让LLM直接输出三角形网格要可靠得多——网格是成千上万个顶点坐标任何一点错误都会肉眼可见而脚本是几步逻辑错了可以改、可以重跑。3.3 一个真实的法兰盘例子从需求描述到可改尺寸的脚本我在Zoo里实测过一个DN50法兰盘提示词这样写生成一个DN50法兰盘外径165mm内径61mm厚度18mm8个直径18mm的螺栓孔均布在直径125mm的螺栓圆上边缘倒角0.5mm。全部尺寸以毫米为单位输出OpenSCAD脚本。生成的核心代码整理后大致是这样的逻辑difference() { // 法兰主体 cylinder(h 18, d 165, $fn 100); // 内孔 cylinder(h 18, d 61, $fn 100); // 8个螺栓孔均布 for (i [0 : 45 : 315]) { rotate([0, 0, i]) translate([125 / 2, 0, 0]) cylinder(h 18, d 18, $fn 24); } }这份代码逻辑完全不复杂但干净地表达了法兰盘的几何本质。更关键的是所有尺寸都以变量的形式出现在脚本里——要改成DN80只需要改外径、内径、厚度、螺栓孔数和分布圆直径重跑一次即可。3.4 可编辑性藏在“参数”里改一个数字整件重生这是text-to-cad相对传统手动建模最大的红利可编辑性不是“改模型的形状”而是“改参数模型自动重生”。传统CAD里我要是把一个法兰盘的螺栓孔从8个改成12个通常要删除孔、重新定位、逐个阵列操作半天。但在程序化建模里只需要把for循环的步长从45度改成30度或者把数量改成12脚本一跑新模型就出来了。我把这个思路扩展成了一个系列的“支架家族”同一个L型支脚改变长宽、孔径、孔距这些参数就能快速生成不同负载等级的产品系列。这个能力在后续对接“python批量对cad修改”时更是如虎添翼后面细说。4. 上手实操从一句产品需求到可编辑CAD对象的完整链路4.1 环境准备三条路线分别需要什么如果你想快速感受text-to-cad最低成本的路径是打开浏览器直接进Zoo Text-to-CAD官网体验web版如果想在本地玩透我建议安装两个东西OpenSCAD免费官网直接下载用于本地渲染生成的脚本、导出STL/DXF。Python CadQuery依赖pip install cadquery用于走LLM脚本的自动化路线。如果你是AutoCAD 2025用户直接在软件里的text-to-cad入口体验官方能力即可。不管哪条路环境准备阶段的坑都不多真正花时间的是下面要说的提示词。4.2 提示词模板我验证过的一套高效句式我实测了大量不同风格的提示词最终固定下来一套句式出图稳定度明显更高。核心原则是**“对象关键尺寸位置单位约束输出格式”**六个要素缺哪个模型就可能跑偏。推荐模板【对象】一个带四个安装孔的L型角码支架 【关键尺寸】长边80mm短边50mm板厚3mm安装孔直径6.5mm 【位置】长边两端各一个孔距边10mm短边两个孔孔距30mm居中分布 【单位】全部使用毫米 【约束】长边与短边之间做R2圆角过渡 【格式】输出OpenSCAD脚本不要任何解释这个模板看起来很简单但它解决了一个经常被忽略的问题LLM默认会有自己的“脑补”你不给它位置信息它就可能把孔放在任意位置。把所有要素说清生成结果基本能一次到90%。4.3 生成、渲染、导出的一连串动作在Zoo里生成脚本后我的标准动作是把生成的OpenSCAD代码复制到本地OpenSCAD。按F5快速预览线框确认没有明显的破面、干涉、离谱尺寸。按F6完整渲染CGAL计算这一步会生成可导出的几何体。检查渲染日志有没有“Object may not be a valid 2-manifold”非流形警告有就必须回头修。导出DXF二维轮廓或STL三维网格。到这一步你已经拿到了“带参数的模型雏形”。接下来要进工程环境了。4.4 进入主流CADDXF导入AutoCAD/中望CAD的细节这一步很多新手容易卡住。我的经验是vector笔画的问题选DXF而不是STL。OpenSCAD导出的DXF默认是二维轮廓适合生成法兰、支架、剖面等需要拉伸或标注的零件在AutoCAD或中望CAD里直接“插入→DWG参考”或“导入DXF”即可。如果零件是三维的、后续需要跟标准件装配优先导出STL再在CAD里网格转实体或者用CadQuery直接导出STEP精度和兼容性更好。导入后先全选看图层和颜色text-to-cad生成的DXF通常没有图层规范花5分钟整理图层、线型、颜色后面出图和转PDF会省很多事。实测下来从一句需求到DXF进入CAD熟练之后大概5分钟。这个速度放在以前光算螺栓孔分布就得磨蹭半天。5. 实测中反复踩到的坑错误样例与完整排查思路5.1 坑一单位混乱导致零件放不进装配体我遇到的最频繁的坑是单位脑补偏差。有一次提示词里写“支架高30mm板厚3mm”生成结果在OpenSCAD里预览时看着很正常但导入装配体后尺寸小得诡异——检查代码才发现LLM把30mm换算成了“1.181inch”这种带英制转换的数据导致模型被缩小了25.4倍。排查思路很简单生成脚本后先不要急着渲染看数值部分有没有异常的倍率关系。比如“1.181”“0.984”这类带小数且跟25.4相关的数基本都是英制换算痕迹。遇到这种情况把代码里的尺寸改成毫米整数或者在提示词里再次强调“不要换算单位直接用毫米数值”。5.2 坑二看起来对但拓扑不对后续倒角全崩第二个经典坑是表面看起来完美但内部拓扑有问题。比如“8个孔均布”生成出来是用布尔减法切出来的但$fn设得不够大孔壁呈现明显的棱面更麻烦的是有些布尔操作会让模型变成非流形后续在CAD里做圆角、抽壳时直接崩。我的处理方式是检查OpenSCAD控制台有没有“WARNING: Object may not be a valid 2-manifold object”警告有就必须解决。把圆柱体、孔类的$fn设到60以上保证圆弧平滑度但不建议无脑拉到几百渲染会卡死。如果布尔减法产生拓扑问题改用“先建整体再用更小的负实体去切”的思路避免零厚度实体。5.3 坑三提示词漏约束模型“过度设计”这是最隐蔽的坑而且越有想象力的LLM越容易踩。我试过提示词只说“一个电机安装支架”结果它给我生成了一堆莫名其妙的散热孔、加强筋、异形切角——功能没毛病但完全不是我想要的东西。后来总结提示词里的“约束”部分必须写到“不允许出现什么”。比如“不要加强筋、不要散热孔、不要任何装饰特征”。LLM太热衷于“补全”了不给它限制它就会自由发挥。约束写得越死生成的模型越接近工程实际。5.4 坑四$fn拉满导致渲染卡死有些小伙伴为了让圆看起来更圆把$fn设到300甚至500结果OpenSCAD直接假死。原因很简单$fn控制多边形细分数量每一个圆面都由几百上千个三角面拼成布尔运算的计算量跟着爆炸。我的经验值直径50mm以内的圆$fn设到80-120足够大直径的圆面设到150也够了。再大就属于浪费算力视觉上根本看不出差别。真需要高精度弧面后期在CAD里用圆弧重画反而更可靠。5.5 我惯用的排查链路从代码到几何再到CAD完整的排查流程我总结成一条链路读代码先看尺寸数值有没有异常倍率、单位换算痕迹。看警告渲染时控制台的任何警告都必须处理不处理就是带着隐患进CAD。量关键尺寸在OpenSCAD里用测量工具或者直接对比草图确认“描述尺寸”和“实际尺寸”一致。切面检查对疑似有问题的部位做剖切确认内部结构没有重叠、零厚度、悬空。导出后复核DXF/STL进入CAD后用CAD的测量和分析工具再验一次特别是圆弧半径和孔位分布。这套流程走下来我基本能把text-to-cad生成模型的返工率控制在可接受范围内。别嫌麻烦程序化建模最大的优势就是“可改”排查成本远比手工建模重来低得多。6. 把text-to-cad嵌进现有设计流程进阶用法与收尾心得6.1 模板化与参数批处理批量生成系列件text-to-cad真正的高光时刻不是单件建模而是批量系列件的自动化生成。我用过CadQuery方案做了一次“多规格法兰系列”的批量生成写一个基础建模函数把外径、内径、厚度、孔数、孔径作为参数配合外部脚本循环调用一次性生成30多个规格的法兰模型并导出DXF。原来这个量级的系列件在CAD里手工建模少说一天半现在从写代码到全部导出大概两个小时其中大头还是检查。这也是为什么我一直建议有编程基础的工程师优先考虑CadQuery路线——脚本化建模批量循环才是text-to-cad的终极玩法。6.2 与python批量对cad修改的配合说到批量自然绕不开“python批量对cad修改”这条工作流。很多人以为text-to-cad是孤立功能用完就完了。但实际上生成模型后的批量调整、图纸合并、格式转换都可以用Python脚本统一处理。我的一个常规操作是用CadQuery生成一批参数不同的零件导出DXF后再用Python批量修改DXF里的图层、文字高度、标注样式甚至把几十张图纸按图幅合并到一个DWG里。这样text-to-cad负责“从无到有”的建模Python负责“从有到规范”的加工两者配合起来非常顺手。6.3 在CAD环境中的落地组合拳出图、转PDF、归档生成模型进入CAD之后真正面向交付的流程还是传统那套标注、套图框、cad转pdf、图纸归档。text-to-cad在这一步的价值是帮你把“重复画形状”的时间省下来把精力集中到真正的工程判断上。我现在的固定节奏是text-to-cad生成可编辑模型5分钟导入CAD整理图层、线型、标注30分钟出图、转PDF、合并归档10分钟。对比以前从零建模整个流程效率大概提升了三四倍。尤其是标准件、通用支架这类重复度高的零件省下来的时间非常可观。6.4 我对这类工具的最终判断与边界感最后说一条我最想强调的实战心得text-to-cad目前最适合的定位是“前期方案加速器”和“标准件批量建模器”而不是“替代工程师的出图机”。它能把你的想法快速变成可编辑、可修改、可重生的参数化模型但真实项目里的公差配合、材料工艺、装配逻辑、出图规范还是得靠你。别指望提示词写得好就能绕过工程师的核心判断那样的项目迟早翻车。如果你现在还在犹豫要不要试我的建议是从Zoo web版走一遍法兰盘和L型支架这两个例子5分钟就能感受完整个流程。等你觉得“这玩意儿能进工作流了”再往CadQuery方向深入。工具迭代很快但工程师的手感和判断力永远是最值钱的部分。