前阵子朋友扔给我一句话“给我生成一个带四个沉头孔的法兰盘”我打开电脑对着终端敲了一行命令还真就输出了一份可以直接拿去加工中心出活的STEP文件。这就是text-to-cad最朴素也最让我兴奋的场景把“脑子里的想法”直接翻译成“机器能读懂的模型”。这个方向最近在机械设计、3D打印、机器人抓取这些圈子热度很高我也花了几周时间把能跑的开源方案、能踩的坑都过了一遍今天这篇就把从原理到实操的完整链路拆开讲清楚。如果你是一个机械工程师、独立产品设计师或者哪怕只是业余玩3D打印的爱好者只要你受够了“对着软件画草图—拉伸—打孔”这种繁琐步骤这篇内容都值得看完。当然我也不打算把它吹成“AI取代建模师”的玄学text-to-cad现在能做的、不能做的我分别在后面用真实案例说明。1. 需求本质建模入口从“动手画”变成“开口说”1.1 传统CAD建模的痛点在哪传统CAD建模流程本质上是一个“翻译执行”的过程你脑子里有一个法兰盘先用草图把它投影成二维轮廓再通过拉伸、旋转、打孔、倒角这些特征一步步堆叠出三维实体。这个过程的瓶颈从来不是“思路”而是“操作”一个简单的圆盘加四个孔在SolidWorks里最快也要两到三分钟新手可能还要翻菜单找“圆周阵列”藏在哪个选项卡下面。text-to-cad想解决的就是这个翻译环节。它把“自然语言描述”直接映射成“建模操作序列”省掉人和软件之间的图形界面沟通成本。在批量生成相似零件、快速做概念验证、以及给非CAD专业人士提供建模能力的场景里这个优势非常明显。但要注意它不是替代整个建模流程而是把“建模指令”这部分自动化了后面的工程分析、配合干涉检查、出工程图仍然需要你动手确认。1.2 为什么是现在这个时间点爆发text-to-cad并不是今天才有的概念。早年间有些论文尝试用模板匹配或者传统NLP把文字转成建模宏效果一言难尽因为自然语言的歧义性和建模参数的结构化之间隔着一条巨大的鸿沟。真正的转折点是大语言模型LLM把“语义理解”和“代码生成”这两件事同时做到了可用的水平而现代CAD系统本身又越来越依赖脚本化、参数化接口比如CadQuery、OpenSCAD、Cascade Studio恰好给LLM提供了一个结构化输出目标。换句话说LLM擅长把模糊需求整理成结构清晰的指令脚本化CAD系统擅长把指令变成精确几何两者合在一起text-to-cad就成了一个工程上可行的产品。我自己的体会是这个时间点入场你不需要理解Transformer的数学细节只要能写好提示词、会跑通一条完整的命令链路就已经能比大多数人先吃到红利。2. 技术路线底层其实是一个“映射问题”2.1 路线一自然语言直接转参数化脚本目前工程上最成熟、也是我个人最推荐的路线是让LLM输出一段可执行的CAD脚本。只要脚本语法正确、运行环境完整CAD内核就会自动构建出实体模型并导出STEP、STL等通用格式。这有点像让AI写网页LLM不直接生成像素而是生成HTML/CSS浏览器负责渲染。在这里脚本就是HTMLCAD内核就是浏览器。以CadQuery为例它的建模方式非常符合机械直觉先用Workplane建立基准面然后.circle()、.extrude()定义实体再用.faces()、.hole()添加特征。LLM经过训练后能比较稳定地把“直径60毫米的圆盘厚度10毫米中心通孔直径12毫米”翻译成对应的代码。我实测下来只要提示词里把尺寸和特征说清楚生成的第一版脚本改写两次以内就能通过语法检查并导出几何体。这条路线最大的优势是“可编辑”。生成的脚本保留了完整的参数关系你可以回头改一个数字重新生成整个模型。对于需要频繁调整尺寸的零件这种参数化特性比直接生成网格模型实用太多。要手动修改时打开脚本改个数值就行整个工作流是透明、可控的。2.2 路线二直接输出B-Rep表示或者构造历史另一条更“硬核”的路线是让模型直接生成B-Rep边界表示几何或完整的CAD构造历史。比如DeepCAD那批工作训练模型输出的是“草图类型拉伸深度旋转角度”这种结构化的序列数据最后再交给几何内核重建出实体。这种方式的优势是生成的模型天然符合CAD数据的规范不需要经过脚本解析这一层折中缺点是数据获取难、训练成本高而且一旦生成结果是错的你很难像改脚本一样直接改一行参数。Text2CAD这类工作也是类似的逻辑构建大规模的自然语言-建模指令配对数据集训练模型从一句话直接生成对应的CAD操作序列。这条路线更接近学术界对“AI辅助设计”的理想定义但离“拿来当生产力工具”还有距离。目前开源社区里能直接跑的模型绝大多数还是走脚本生成路线因为它可以借用LLM已有的代码生成能力不用从零训练一个几何专用模型。2.3 当前工程落地的选择逻辑如果你是个人用户或者小团队想快速在项目里用上text-to-cad我建议不要一上来就折腾论文复现而是先选一条已经跑通的脚本生成链路。用现成LLM API写CadQuery脚本或者在本地部署一个开源模型跑Cascade Studio脚本都能在一天内看到效果。等你确认这个方向能解决实际问题再考虑要不要收集数据、微调一个专属模型。我自己试过几个方案之后总结出一个判断标准看它能不能导出STEP而不是截图或者网格。STEP是机械设计领域的通用交换格式带精确曲面信息能进CAM软件做刀路也能进仿真软件做有限元分析。如果哪个text-to-cad工具只能导出STL网格那它在机械加工场景里基本只能当玩具因为网格模型无法直接作为加工依据还需要重新曲面化这一步的精度损失和人工成本都不小。3. 能跑起来的工具与数据基础3.1 开源工具速览这个方向在GitHub上已经有不少能直接跑的项目我挑几个实际体验过的列出来可以按自己的硬件条件选择工具/项目输出形式运行门槛适合场景CadQuery LLM APIPython脚本 / STEP只需要Python环境个人批量建模、参数化设计ZooText-to-CAD开源模型Cascade Studio脚本 / STEP需要Docker和较大显存想完全本地化、离线生成OpenSCAD LLMOpenSCAD脚本 / STL极低网页IDE即可快速生成3D打印模型FreeCAD宏生成Python宏 / STEP中等需要进入FreeCAD继续编辑Zoo是近期热度比较高的一个开源项目用7B参数模型微调输入一句话输出的是Cascade Studio脚本再经过Cascade内核导出STEP。它官方推荐用Docker跑模型比较大我实测在8GB显存的卡上可以推理但速度偏慢一个中等复杂度的零件大概要等一两分钟。如果你不想折腾本地环境其实用LLM API生成CadQuery脚本是性价比最高的方案成本低、迭代快而且CadQuery本身就能直接导出STEP。3.2 数据从哪来Text2CAD与DeepCADtext-to-cad的模型能力很大程度上取决于训练数据。目前公开的比较有代表性的数据集是Text2CAD和DeepCAD。DeepCAD提供了几万个带建模指令序列的CAD模型每个模型都记录了一步步的草图、拉伸、旋转等操作Text2CAD则在这个基础上做了自然语言描述与建模序列的配对大概有接近20万条指令级数据让模型学习“一句话到一系列操作”的映射。这些数据集的价值不仅在于训练模型普通人也能拿来当“题库”用你可以随机抽几条人工标注的数据看看模型是怎么把一段话分解成建模步骤的这比直接读论文更容易理解text-to-cad的行为方式。我自己看了一百多条数据之后最大的收获是所有好用的提示词都有一个共性——先描述整体形态再描述每个特征最后明确尺寸和位置关系。这不是AI教育我而是数据集的标注方式本来就是这个逻辑。3.3 提示词在pipeline里的真实地位很多人以为text-to-cad只要装了模型就万事大吉实际用下来发现提示词写得好不好直接决定结果能不能用。一个模糊的“做一个支架”模型可能给你生成一个随机的L形实体一个清晰的“做一个L形支架底板尺寸100x80x5立板高60厚度5底板边角倒R5圆角底板上开两个直径8的安装孔”生成的模型基本就能直接进装配了。这背后的原因是LLM本质上是在做模式匹配你给的信息越接近训练数据中标注的结构它匹配到的建模方案就越可靠。不要把提示词想成“跟AI聊天”要把它想成“给一个执行力强但理解力有限的实习生写需求单”。尺寸、位置、数量、倒角半径这些硬参数一个都不能少最好是按“整体→特征→参数”的顺序组织成一段话模型输出的稳定性会明显提升。4. 本地实操记录从一句话到STEP文件4.1 环境准备我用的轻量方案为了降低门槛我用的是最轻的方案Python环境 CadQuery库 LLM API整个过程不需要本地显卡一台普通办公笔记本就能跑。CadQuery的安装很简单在终端执行pip install cadquery就能装上它会自动带OCCT几何内核负责把脚本变成真正的实体模型。如果你之前没用过CadQuery建议先跑一个最简示例验证环境import cadquery as cq result ( cq.Workplane(XY) .circle(10) .extrude(5) ) cq.exporters.export(result, demo.step)这段代码生成一个直径20mm、高5mm的圆柱体并导出STEP文件。如果这一步成功说明几何内核和导出链路都没问题后面就可以放心交给LLM生成更复杂的脚本了。我自己第一次跑的时候卡在“找不到OCCT依赖”上后来发现是Python版本太新换个旧一点的虚拟环境就解决了。这种环境问题很像木工活里的“工具没调好”不影响你最终的技术路线判断但会消耗不少耐心提前备好一个干净的Python 3.10环境比较省事。4.2 写提示词的通用模板我试过几次之后沉淀了一套自己能稳定复用的提示词模板请生成一个CadQuery脚本构建以下零件 1. 整体描述{这里是总体形状比如“一个圆形法兰盘”} 2. 特征列表 - {特征1比如“底部圆柱体直径60mm高度10mm”} - {特征2比如“中心通孔直径12mm贯穿”} - {特征3比如“四个安装孔直径6mm均匀分布在直径44mm的圆上”} 3. 所有尺寸单位均为毫米。 4. 只输出完整可运行的Python代码不要加解释。注意最后一句“只输出代码不要加解释”非常重要。LLM默认倾向于在代码前后加一段说明文字如果混在完整脚本里复制到Python运行时就会语法报错。使用规则里明确要求输出纯代码块能让解析过程省掉很多麻烦。还有一个细节明确写“所有尺寸单位均为毫米”因为CadQuery默认虽然用毫米但很多训练数据里混杂了英寸标注模型偶尔会把数字理解岔了写清楚能显著降低尺寸跑偏的概率。4.3 案例用text-to-cad生成一个法兰盘我拿前面提过的法兰盘做一次完整演示。假设需求是外径60mm、厚度10mm的圆形法兰盘中心一个直径12mm的通孔另外四个直径6mm的螺栓孔均布在直径44mm的节圆上。按照上面的模板我把描述交给LLM它返回了下面这段CadQuery脚本import cadquery as cq result ( cq.Workplane(XY) .circle(30) # 外圆半径30mm .extrude(10) # 拉伸10mm .faces(Z) # 选择顶面 .workplane() .hole(12) # 中心通孔直径12mm .workplane(offset0) .pushPoints([(22, 0), (-22, 0), (0, 22), (0, -22)]) .hole(6) # 四个螺栓孔直径6mm ) cq.exporters.export(result, flange.step)这段代码的逻辑很清晰先在XY平面画圆拉伸成圆柱再选中顶面打中心孔然后在顶面工作平面的四个坐标点上打螺栓孔。pushPoints接收四个位于半径22mm的坐标点正好满足“四孔均布在直径44mm节圆上”的要求。我把这段代码保存成make_flange.py在终端执行python make_flange.py几秒钟后目录下就多了一个flange.step文件。这里有一个从我自己的角度来说比较重要的验证步骤不要直接把这个STEP丢给加工厂先用一个能看模型的工具检查。我习惯用FreeCAD或者在线查看器打开STEP确认孔的数量、位置、直径和需求一致。曾经有一次LLM输出的螺栓孔坐标没有落在节圆上而是落在圆柱体内部视觉上看起来孔是“藏”在实体里的如果直接出STEP后续加工必废。问题就出在坐标计算上它把直径44mm算成了半径44mm用了一点三角知识检查坐标值后才发现不对。4.4 从脚本到实际模型导出与验证导出格式上我强烈建议优先选STEP而不是STL原因前面说过STEP保留精确几何信息后续做CAM、仿真、装配都不需要重新建模。CadQuery里导出STEP只需要一行cq.exporters.export(result, flange.step)如果只是给3D打印机用STL也够但要注意STL是三角网格精度取决于导出参数放得很大之后会出现棱角。CadQuery导出STL时可以通过exportOptions控制弦高误差我不太建议在这里省时间打印模型出现“台阶感”通常就是网格太粗。要做尺寸验证可以从导出的STEP文件里用代码读取实体属性也可以直接用FreeCAD的测量工具点两个面看距离后者更直观。5. 常见故障与排查技巧实录5.1 高频问题速查表在我折腾text-to-cad的过程里遇到的大部分故障其实不是模型“笨”而是链路里某个环节没对齐。整理一个速查表供你遇到问题时直接对照现象常见原因处理方法脚本运行报错NameErrorLLM用了CadQuery不存在的API在提示词里指定“只用circle/hole/extrude/faces/workplane等标准方法”导出的STEP打不开布尔运算失败生成了非流形实体简化特征减少环面交叉分步生成再合并孔的位置偏了坐标计算把直径当成半径手动验证pushPoints的坐标与节圆半径是否匹配尺寸单位不对模型把英寸当成毫米提示词里加一句“所有尺寸单位是毫米”输出内容夹杂解释文字提示词约束不严格要求“只输出代码块前后不要任何文字”模型卡住不动生成脚本太长上下文超限拆分成多个特征分步生成再组装生成结果与自己预期完全不符描述缺少特征级拆解按“整体→特征→参数”结构重写提示词5.2 三个特别容易忽略的细节第一个细节是布尔运算的顺序。CadQuery的hole打孔本质上是在已有实体上做减法布尔运算如果两个孔的深度方向、起始面选择不对很容易出现“怪形状”比如中心孔明明是通孔结果底部多了一层薄壁。这是因为hole的贯穿深度默认是穿破当前实体的但如果你在错误的工作平面上打孔它会往实体外侧而不是内部钻。我个人习惯是在打孔之后额外检查一下模型的Volume数值是否合理比用眼睛看更准。第二个细节是阵列的生成方式。要实现四孔均布我看到不少AI会生成四个单独的hole()调用坐标手工写死比如(22,0)、(0,22)、(-22,0)、(0,-22)。这种写法没问题但如果要改成六孔就得改多处代码。更好的方案是让LLM用polarArray或者循环生成均布点不过目前模型对这两个方法的输出稳定性不如手写坐标。务实起见我先接受手写坐标等模型能力再强一点再要求参数化阵列。第三个细节是倒角与圆角的顺序。很多零件需要fillet但倒角放在打孔之前和打孔之后效果完全不同。LLM经常给出一个先打孔后倒角的脚本结果孔的边缘也被倒角了这在某些装配场景里不符合要求。如果模型错了不要让它重写整个脚本而是直接告诉它“把fillet移到打孔之前”局部修正的准确率比重写高很多。这也是脚本生成路线比黑盒生成路线更优势的地方你能介入生成过程精准定位错误。5.3 一个“看起来对实际很糟”的典型案例有一次我让它生成“一个带U型槽的安装底板”模型输出的脚本语法完全正确STEP也能打开表面上看起来就是一块长方板在中间开了一个U型槽。但我放进FreeCAD做剖面检查时发现槽的底部没有圆角过渡而是直角边如果这是要加工成形的零件铣刀根本没法定刀因为直角内角对加工特别不友好。模型并没有错是我需求描述里漏了“槽底部需要铣削圆角半径至少3mm”这个关键加工约束。这个案例让我意识到text-to-cad能理解设计意图但它不懂加工工艺。你在提示词里不写的约束它默认不存在。所以在设计提示词时除了尺寸和特征还得把与制造相关的工艺要求显式列出比如“所有内角倒圆角R3”“避免封闭凹槽”“板厚不小于2mm以适应激光切割”。这一步能帮你挡掉一大批不合格的生成结果省得后面反复修。6. 实际业务场景里的落地建议6.1 3D打印快速原型工作流在我自己玩3D打印的工作流里text-to-cad目前已经能真正帮上忙主要用在“快速出原型”这个环节。以前我想到一个零件要花20分钟用建模软件“画”出来现在只需要把需求说清楚让LLM生成CadQuery脚本再导出STL直接切片打印。一个简单的带卡扣的电池盒从想到拿到实物压缩到了半小时以内而且因为脚本保留着参数改个尺寸重新生成只花几十秒。这种方式尤其适合做“探索性设计”不确定某个结构好不好用那就快速生成三五个变体每个改一个参数打出来实际装配感受一下。用传统方式做同样的事情时间成本会高到让你放弃尝试。但也要明确一点text-to-cad生成的模型目前主要面向“形状正确”对打印方向、支撑结构、壁厚均匀性这些工艺优化并不敏感这类调整仍然需要你在切片软件里完成或者在提示词里就把壁厚、公差这些参数写清楚。6.2 机械装配与参数化备件另一个我觉得很有潜力的场景是备件管理。工厂里有大量设备备件图纸往往不全或者老设备根本没有三维模型。现在可以用一段自然语言描述生成一个初版模型比如“一个直径40mm、厚度15mm、带6个M6螺纹孔的法兰”然后导入装配体里试装不对的地方再回改脚本。整个迭代过程的效率比从零开始测绘建模高不少。在参数化方面脚本路线有一个天然优势如果你的零件有系列化需求——同一个法兰有50mm、80mm、120mm三个规格用text-to-cad生成一次基本脚本之后只需要修改脚本里的直径变量就能批量输出多个规格的STEP文件。这一点对设备改造、工装设计、非标自动化场景特别实用。不过要提醒一句装配环境下的配合公差比如孔距精度、圆柱配合间隙不能靠AI凭空生成那些必须按工程手册或实际测量来定AI只是帮你省掉了“建模”这个动作。6.3 数据集与模型微调的下一步如果你背后有团队想从“用别人的模型”走向“训练自己的模型”目前比较现实的路径是先采集企业内部的零件库和设计规范整理成“指令-脚本”配对数据然后在开源模型基础上做指令微调。现阶段公开的Text2CAD数据覆盖的是通用机械零件对特定行业比如航空钣金、注塑模具、建筑构件的效果可能不够好垂直微调的空间很大。我个人的看法是text-to-cad并不会让CAD工程师失业它更像是给CAD配了一支“手写笔”以前键盘鼠标操作繁多现在多了一种直接输入想法的通道。最终工作流大概率是“AI生成初稿工程师修改参数和工艺约束再进入正式评审流程”人的角色从“一笔一笔画”变成了“审稿和决策”。这个转移不降低设计质量但会明显压缩重复劳动时间。6.4 个人经验从哪一步开始上手最稳妥如果你看完这篇内容想自己动手试我的建议是别先急着部署本地大模型。先从最简单的链条开始申请一个你常用的有代码能力的LLM API装好Python和CadQuery然后用一篇工程师需求文档里最基础的小零件作测试比如垫片、支架或者安装板。第一次跑通之后你会对这整个流程建立直觉知道模型在哪些环节容易出错也就能更有针对性地写提示词。等这套轻量链路用顺了再决定要不要上重型开源模型。千万别跳过中间的验证步骤每一次生成后都要在FreeCAD里打开、测量尺寸、检查特征否则漏掉一个孔的偏心错误后面整个装配方案都会跟着歪掉。我踩过最大的坑就是太相信模型第一版输出直到最后一刻才发现螺栓孔不在节圆上——那一次之后我给自己立了一条规矩text-to-cad生成的任何模型未经测量验证一律不进入下游环节。说到底text-to-cad真正改变的不是“你会不会建模”而是“你从想法到实体之间的距离有多短”。工具还在快速迭代但“描述清楚需求、验证生成结果、把工艺约束写进提示词”这三个习惯放之任何版本的模型都管用。先从最简单的圆柱开始给自己生成一个零件那种“一句话变成实物”的感觉是真的会上瘾。