直接说结论text-to-cad 这个方向我盯着它已经大半年了。从最早看到论文里“输入一句话直接生成CAD模型”的演示到自己动手把开源方案跑通、踩坑、再调通我最大的感受是它确实还没法替代工程师手头的活儿但作为“从需求到模型”的第一公里价值比大多数人想象中要大得多。这篇文章不聊虚的。我把text-to-cad 的技术原理、主流实现路线、一套能直接复现的最小工作流以及我在实际运行中遇到的坑和解决办法全部拆开。如果你是在校学生、机械/建筑方向的建模新人或者是想给3D打印、非标设计流程里塞一个“自动出图”环节的从业者这篇文章应该能帮你少走很多弯路。1. text-to-cad 到底在解决什么问题先把话说明白text-to-cad 不是一个软件名它是一类技术的统称。核心目标就是通过自然语言描述由算法直接生成可供CAD软件打开、编辑和加工的几何模型。换句话说让“说人话”变成“出图纸”。1.1 传统CAD建模的痛点在哪里做机械设计或3D建模的人都有体会一个简单零件从0开始建哪怕再熟练也得经历“拉伸、切除、倒角、打孔”这一套组合拳。工具本身不复杂复杂的是把脑子里那个“大概的样子”翻译成参数化特征。这个翻译过程才是大部分新手的真实门槛。我见过不少刚入行的同学制图课理论背得滚瓜烂熟真让他画一个“带四个沉头孔的方形法兰盘”照样要卡半天——不是不会用命令而是不知道这个零件该由哪些特征组成、特征顺序怎么排。这其实就是“语义到几何”的映射能力没建立起来。text-to-cad 切入的正是这个环节。它尝试把“四个沉头孔的法兰盘”这种自然语言直接映射成一组特征序列或几何参数让软件替你完成特征建模的逻辑编排。1.2 text-to-cad 的定位与核心价值那它到底想做成什么我的理解是三层第一层替代重复性的草图绘制和特征堆叠比如标准件、简单支架、壳类零件。第二层把产品需求文档、口头描述、甚至技术方案里的文字描述自动转成初步几何模型作为设计评审的起点。第三层打通“自然语言—参数化模型—仿真/加工”的全链路让非专业人员也能在早期阶段介入设计。这是从“画图”到“设计意图表达”的转变。也就是说你不再需要纠结“第一步拉伸还是旋转”而是把注意力放在“这个零件要承受什么力、有什么功能”上。网上关于cad下载、cad制图初学入门的搜索热度一直很高这恰恰说明一个问题大量用户有出图需求但卡在工具使用上。text-to-cad 类工具如今最大的现实意义就是把这一层“工具使用”的摩擦降下来。2. 主流的实现路线与工具选型text-to-cad 看着玄乎实际落地的技术路线无非三条。我分别跑过不同的方案下面按照工程实用度排序讲清楚。2.1 路线一生成式模型直接输出几何体这条路以 Zoo 团队的 Text2CAD 为代表整体思路是用 Transformer/扩散模型把自然语言编码成隐变量再解码为体素、点云、或者CSG构造树。输出后处理成STEP、STL这类通用格式。我个人的评价是作为研究原型很有价值但工程化程度一般。原因在于直接生成点云/体素的方式在几何精度上很难满足机械加工要求。你拿到一个花瓶、一把椅子这类自由曲面没问题但拿到一个配合公差0.05mm的轴孔结构基本没法用。CSG构造树路线相对更好一些。因为CSG本质上是“布尔运算基本体素的组合”生成结果天然带参数化属性导出STEP后能被主流CAD识别。但它的表达范围受限——复杂自由曲面、变半径圆角、放样类特征很难用纯CSG表达。2.2 路线二LLM生成参数化建模代码这条路线是我目前最看好的也是我实际项目中主要采用的。思路非常直接让大语言模型生成CadQuery 或 build123d 这类参数化建模代码然后由脚本执行生成模型。类比一下CSG/点云路线是“AI直接画图”代码生成路线是“AI写图纸的施工说明”再由“施工队”CAD内核把说明变成实体。后者看起来绕了一圈但每一步都可控、可修正。CadQuery 是用 Python 写参数化模型底层基于 OpenCascade 内核生成的STEP文件精度高、特征树完整、可编辑。最关键的是它的代码可读性很强生成错了你知道错在哪一行而不是面对一团乱七八糟的点云干瞪眼。实际用下来LLM CadQuery 这条路线在“标准件、简单壳体、规则板类零件”上成功率很高。我让LLM生成过一个带加强筋的钣金支架一次通过导出的STEP在FreeCAD里打开特征和尺寸完全正常。2.3 路线三草图识别与约束求解还有一类方案输入文本后先通过NLP抽取关键尺寸和几何关系然后在二维草图层面自动生成轮廓再用约束求解器如SolveSpace的内核转化为三维特征。这种方案比较适合轴类、盘类、型材类零件。我试过一个基于开源约束求解器的实验性项目对“直径50mm、长度100mm的圆柱两端各倒角2mm”这类描述处理得非常稳定因为它本质上是把文字抽成参数再套到预设模板里。但换个说法比如“一根一头粗一头细的棒子”它就懵了——因为模板库里没有“变径”这个预设。所以这条路线更适合行业专用场景比如法兰、轴、标准件这类“参数变、结构不变”的零件。服装CAD里的版片生成、钣金CAD里的展开图生成本质都是这个思路。2.4 工具选型建议根据我的实操经验给出一个比较实用的选型建议场景推荐路线理由研究/学习原理生成式模型Text2CAD论文复现算法透明适合理解技术边界规则机械零件LLM CadQuery/build123d精度高、可编辑、错误可追溯轴/盘/型材类草图约束求解 模板匹配稳定、可控、速度快自由曲面外观件生成式模型 Mesh后处理能出复杂形状但精度需手工修3D打印爱好者LLM CadQuery 输出STL流程短迭代快记住一个原则能参数化的就别用纯生成能代码描述的就别依赖黑盒输出。这不是保守是工程上对可维护性的要求。3. 实操搭一套文本转CAD的最小可用流程这一节直接上可落地的方案。我会带你从零跑通“一句话 → STEP文件 → CAD软件打开”的完整流程。所有工具均为开源方案不需要额外授权。3.1 环境准备与核心依赖建议用 Python 3.10 以上版本我实测在 Windows 11 和 Ubuntu 22.04 下都能正常跑通。核心依赖就三个cadquery参数化建模的Python库底层是OpenCascadetransformers 或 openai SDK用来调用LLM生成CadQuery代码OCPOpenCascade Python绑定CadQuery的底层依赖安装时自动带上安装命令如下pip install cadquery pip install transformers torch如果你用本地LLM比如跑一个Qwen或Llama的量化版只需要保证显存够用如果调用云API那更省事。我自己的环境是本地部署了一个7B参数量的模型生成CadQuery代码完全够用且不用把数据传到外部。3.2 提示词设计和约束条件用LLM生成CadQuery代码最关键的不是模型聪明不聪明而是你怎么把需求“翻译”成它听得懂、而且没有歧义的话。我踩过几次坑之后总结出一套固定的提示词结构角色设定明确告诉模型“你是一名资深机械设计师熟悉CadQuery库”输出格式要求“只输出Python代码不要多余解释代码块用纯文本”几何要求写明单位毫米、坐标系方向、关键尺寸约束条件明确禁止生成STL网格类输出只允许使用CadQuery的实体建模方法一段比较靠谱的提示词模板如下你是一名资深机械设计工程师使用CadQuery库编写参数化建模代码。请根据以下需求生成Python代码 - 零件带4个安装孔的矩形底板 - 外形长200mm宽100mm厚10mm - 4个安装孔分布在四角直径8mm孔中心距边沿15mm - 底板中央有一个直径40mm的沉孔沉孔深度5mm通孔直径20mm - 代码中所有尺寸必须用变量定义单位默认为毫米 - 只输出完整的Python代码不要输出解释性文字注意我提到的“所有尺寸必须用变量定义”——这是我试过很多次后加的关键要求。原因很简单变量化之后生成错了你可以直接改变量数值重新跑一遍而不是回到LLM重新生成一大段代码。这个细节在后续尺寸迭代时能救你命。3.3 生成流程实测从英文描述到CAD模型文件我的完整脚本逻辑如下你可以直接抄来改from cadquery import exporters import openai # 或者用本地模型接口 # 1. 构造提示词 prompt build_prompt(带4个安装孔的矩形底板) # 2. 调用LLM生成CadQuery代码 response llm_generate(prompt) cad_code extract_python_code(response) # 3. 执行CadQuery代码得到模型对象 exec_namespace {} exec(cad_code, exec_namespace) result exec_namespace.get(result) # 约定生成的变量名必须叫result # 4. 导出STEP文件 exporters.export(result, output.step)这里有一个非常重要的约定生成代码中必须有一个名为result的变量指向最终的CadQuery Workplane/Shape对象。这样我的脚本才能从命名空间里把它取出来。这个约定相当于你和LLM之间的“接口契约”没有这个契约后面流程没法自动化。我实测跑通的一个真实案例提示词写的是“一个外径120mm、内径80mm、高25mm的环形垫片上下表面各倒角1.5mm”。模型生成的CadQuery代码大致如下import cadquery as cq outer_d 120 inner_d 80 height 25 chamfer 1.5 result ( cq.Workplane(XY) .circle(outer_d / 2) .circle(inner_d / 2) .extrude(height) .faces(Z).chamfer(chamfer) .faces(Z).chamfer(chamfer) )这段代码生成后在FreeCAD里打开STEP文件尺寸全部正确倒角方向没有问题。整个过程从输入文字到拿到STEP文件大约耗时20秒包含LLM推理时间。3.4 输出格式转换与下游使用CadQuery支持导出多种格式我在项目中常用的有三种STEP用于工程交换、CAM编程、装配体配合精度最高STL用于3D打印和网格可视化适合非精密场合DXF用于激光切割、钣金展开、二维出图你可以在脚本里快速导出多种格式exporters.export(result, output.step) exporters.export(result, output.stl, tolerance0.1, angularTolerance0.1) exporters.export(result, output.dxf)其中STL导出有两个关键参数tolerance控制线性偏差angularTolerance控制角度偏差。这两个值越小网格越精细文件越大。3D打印的话tolerance0.1已经足够如果是做有限元仿真建议设置成0.01级别。关于用户经常搜索的cad转pdf问题我的建议是不要直接从3D模型转PDF正确流程是“生成STEP → 导入CAD软件出工程图 → 导出PDF”。这一步text-to-cad管不到但它生成的高精度STEP模型能让你的出图环节省掉重新建模的时间直接进入标注环节。4. 关键细节为什么生成结果经常“看着像实际不能用”跑通流程后你会发现更大的挑战不是“能不能生成模型”而是“生成的结果能否进入真实生产流程”。这里有几个我反复踩坑、反复总结的关键点。4.1 几何闭合性与水密性有一次我让模型生成一个带内腔的壳体输出的STL在切片软件里疯狂报错一查原因是内腔和外壳之间没有形成闭合的实体边界存在“开口”面。这在实际加工中是完全不可接受的。这里涉及一个概念水密性Watertight。简单说一个水密模型的所有边都是两个面共用的没有“漏风”的边界。生成式模型直接输出点云/网格时最容易出这个问题CadQuery这类基于B-rep边界表示的程序化建模则天然水密因为OpenCascade内核自带拓扑修复能力。所以我在方案选择上坚持用CadQuery理由就在这程序化建模不会产生“看着像、实际缝补不了”的网格漏洞。4.2 参数化约束缺失的问题纯生成式模型第二大致命伤是模型是“死”的。生成一个直径50mm的圆孔它就是50mm你要改成52mm没法直接改只能重新跑一遍生成。而参数化模型的核心价值在于“改参数就能更新模型”。我在提示词里强制要求“所有尺寸用变量定义”就是为了保留这个可迭代能力。设计是个反复的过程尺寸改三遍五遍太正常了。没有参数化能力每次修改都是一次重新生成效率极低。另外约束还体现在特征之间的关系上。比如“4个螺栓孔到中心孔的距离必须相等”这类几何约束纯生成模型很难保证而CadQuery代码里用变量定义中心距后再均布阵列天然满足约束。这件事本质上是“把设计意图编码成数学关系”而不是靠模型“猜”。4.3 提示词工程对生成质量的影响我实测发现同一句话加不加单位、说得具体还是抽象结果天差地别。比如差劲的描述“一个方形底板上面有孔”好的描述“长200mm宽100mm高10mm的矩形底板4个直径8mm的圆孔布在四角孔中心距边沿15mm中心一个直径20mm通孔”差距不仅仅是有没有尺寸更关键的是“特征顺序”。LLM生成CadQuery代码时特征的先后顺序决定了建模过程能否成功。比如先倒角后打孔和先打孔后倒角结果完全不同——后者会倒掉孔的边缘线前者不会。我踩过最深的坑就是倒角和孔的顺序。后来我在提示词里加了一句“先完成所有布尔运算和打孔最后统一处理倒角和圆角”生成成功率立刻提升了一大截。问题典型表现修复策略特征顺序错误倒角把孔口搞变形规定“先主体后细节先打孔后倒角”尺寸缺失生成结果比例奇怪提示词强制给每个特征标尺寸单位歧义零件大十倍或小十倍明说“单位毫米1毫米1单位”约束缺失孔位不对称要求用变量定义相对位置代码变量未定义脚本报错中断约定变量命名规范全部在开头定义4.4 可制造性检查最后还要说一个很多人忽略的点生成出来的模型即使几何上正确也可能无法加工。比如太薄的壁低于0.5mm、负角度拔模、没有避让的尖角这些都会让CNC和注塑工艺头大。我的经验是text-to-cad生成的模型在进入CAM之前必须做一轮可制造性审查。最偷懒的办法是把生成结果导入CAD软件手动检查最小壁厚和拔模角度。更高级的做法是在提示词中直接加入工艺约束比如“最小壁厚不低于2mm”“所有外圆角不小于半径1mm”——这相当于是把工艺规范前置到自然语言阶段。5. 常见问题与排查技巧实录最后这部分是我在实际使用中积累的排查经验。每条都是真实踩坑换来的希望能帮你省时间。5.1 生成速度慢、显存不足怎么办本地跑LLM最大的瓶颈就是显存。我用的7B模型量化后大约需要6GB显存加上CadQuery建模部分的开销16GB显存是够用的。如果显卡不够我用下来最有效的方案是折腾一个“两段式”在本地用小的规则模型做初步验证比如让模型先生成代码框架确认逻辑没问题后再调用大模型完善细节。这样比直接用大模型反复试错便宜得多。如果显存真的不够还有一个思路控制提示词长度。英文提示词比中文省token简单的零件控制在50词以内生成的代码体量会小很多显存压力也会小很多。5.2 模型输出无法被CAD软件打开这是高频问题。我遇到过的原因有三类第一类是格式版本过新CAD软件版本太老。STEP格式有AP203和AP214等版本有些老CAD对新的Step文件支持不好。解决办法是导出时显式指定使用老版本兼容格式。第二类是文件损坏多见于磁盘空间不足或运行中意外中断。CadQuery导出是原子操作一般不会有半截文件但如果断电或强制终止文件也可能写不完整。重新执行导出即可。第三类最隐蔽模型为空。如果CadQuery代码逻辑有问题导致生成的是空对象导出时会得到空白文件。排查方法是打印result.isValid()和result.Volume()如果体积为零或无效回头查生成代码。我建议在导出前加一个校验逻辑if not result.isValid(): raise ValueError(生成结果无效请检查CadQuery代码) if result.Volume() 1e-6: raise ValueError(生成结果为空可能是尺寸单位或特征逻辑错误)这个校验逻辑让我免掉了无数次白费功夫的导出和导入操作。5.3 生成结果与描述偏差很大这种情况十有八九是提示词不够具体。最常见的问题是说得太抽象比如“好看一点的支架”——“好看”没有可量化标准模型只能自由发挥。解决办法是把抽象词翻译成具体几何描述。比如“好看”翻译成“左右对称”“表面圆角过渡”“主体比例为1:2”等等。这个过程相当于把审美需求转换成可计算的参数。另外一个常见问题是中英文混用。CadQuery模型对中文提示词的支持还行但涉及技术名词时英文识别更准确。我的做法是整体用中文但关键尺寸和特征词用英文写在括号里如“圆角fillet半径3mm”。LLM对这种中英对照的提示词处理效果很好准确率能提高不少。5.4 围绕CAD生态的现实问题搜索热词里出现“cad如何彻底卸载不影响二次安装”“cad激活页面脚本发生错误”这类问题虽然和text-to-cad没有直接关系但反映了大量用户其实是在“工具安装层”就卡住了。text-to-cad对这种场景的意义是它让CAD的价值前置到了“描述需求”阶段而不是“熟悉界面”阶段。如果你正好也被CAD安装、卸载、报错这些问题折磨我的建议是优先考虑CadQuery FreeCAD这套组合CadQuery负责程序化建模FreeCAD负责可视化检查和工程图输出。两款都是开源工具不存在激活和卸载遗留问题装错了大不了删掉重来不会有后台服务残留。5.5 我的独家排查技巧汇总下面这几条是通用文档里基本不会写的让LLM生成代码后先在本机用python -m py_compile做语法检查能拦截大半低级语法错误避免污染整个流程。处理复杂零件时不要让模型一次性全生成先让它生成“主体框架”再逐个加细节。分步生成、分步验证比一次到位成功率高出太多。把常用的提示词模板保存成配置文件比如“底板类零件”“轴类零件”“法兰类零件”下次直接套模板不要把同样的描述反复重写。如果LLM生成代码引用了你未定义的函数别急着骂模型试着在提示词中补充一句“只能使用CadQuery官方API”能显著降低幻觉API的调用频率。最后再分享一个我在实际项目中摸索出来的经验text-to-cad 目前效率最高的用法不是让它独立完成一个零件而是把它嵌入到“参数化模板库”的思路里。你把公司常用的零件族写成变量化的CadQuery模板然后用LLM做“自然语言 → 模板参数”的翻译。这句话200mm×100mm的底板实际就是往模板里填入几个数值。这个思路既规避了LLM在复杂几何建模上的短板又保留了自然语言交互的便利性。我自从把这个方案跑通之后整个非标件的前期建模时间大概缩短了一半而且格式规范、参数可查、改起来也方便。你如果正考虑把text-to-cad落到实际工作里我强烈建议从这条“模板化参数翻译”的路子入手而不是一上来就指望它什么都能画。