把一句大白话变成能直接进CAM的STEP模型这事儿放在三年前听起来还像科幻。做机械设计的人都知道从想法到三维模型中间隔着软件操作、草图约束、特征树管理这一大堆门槛。而现在text-to-cad这个方向就是要把给我一个带4个安装孔的圆形法兰盘这种需求直接映射成参数化模型。这篇文章我会把text-to-cad的技术原理、工具选型、实操流程以及我踩过的那些坑都拆开讲清楚希望能帮正打算入场的工程师或产品经理少走弯路。text-to-cad的核心价值不在于生成一个看着像的网格体而在于输出真正可编辑、可装配、可加工的CAD数据。它跟AI绘画那些东西有本质区别——生成一张好看的图错了可以重画但生成一个尺寸差了0.1毫米的零件放到机床上就是废品。所以这个领域对模型输出的精度要求、参数化能力、拓扑正确性都非常苛刻这也是它一直看起来很美但落地难的根本原因。这篇内容适合谁如果你正在做三维建模相关的工作或者你所在团队想探索AI辅助设计的落地路径又或者你只是对AIGC在工业软件上的应用感兴趣那这篇文章值得你花十分钟认真读完。我会尽量用我自己实际跑过的流程来还原整个操作过程包括那些文档里不会告诉你的细节。1. text-to-cad是什么一句自然语言背后的技术链条1.1 从看懂文字到画出零件表面上看text-to-cad就是把文本输入一个模型然后输出三维文件但这里面实际存在一条完整的技术链路。首先模型要理解自然语言中对几何形状的描述——例如直径50mm的圆柱体、底部开一个20x10mm的矩形槽这一步属于语义理解。其次是几何推理——模型必须知道圆柱体和矩形槽之间的空间位置关系、主视图与剖视图的投影逻辑甚至还要判断哪些特征可以共存、哪些会互相干涉。最后才是几何构建——把上述推理转化成CAD内核能识别的数据结构比如B-rep边界表示或者CSG构造实体几何。我在第一次接触到这类项目时最大的不适应来自于自然语言描述几何体这件事本身。人类工程师之间沟通图纸默认是带着大量隐含知识的比如法兰盘就意味着它通常有一圈螺栓孔、有中心孔、可能有止口。但模型需要从训练数据中自己学到这些默认规则。如果你想让它生成一个法兰盘它大概率会给出一个统计学意义上的标准形态可如果给它更具体的参数比如直径120mm、6个等距分布的10mm螺栓孔、中间22mm通孔这种描述它就能生成与你的需求精确匹配的模型。这个差异直接决定了text-to-cad工具能否进入生产流程。1.2 为什么现在才真正能用text-to-cad涉及到的底层技术都不是全新发明。CAD内核的参数化建模能力是上世纪80年代就成熟的自然语言处理经过Transformer架构的迭代也算得上突飞猛进。但真正让这条链路跑通的关键,是这几年大语言模型在代码生成和逻辑推理上的长足进步。CAD模型从数据结构上看本身就是一种程序——一个STEP文件里的B-rep数据包含了面、边、顶点的拓扑关系一个OpenSCAD脚本就是一段描述几何体的声明式代码。LLM擅长把这些结构化的内容看成token序列来处理所以文本到代码、代码到CAD模型的映射路径就变得可行了。另一个助推因素是训练数据的开放。像Fusion 360 Gallery、ABC Dataset这类大规模的CAD数据集被公开出来之后研究机构和创业公司终于有足够的素材来训练专门的text-to-cad模型。这跟AI绘画火起来之前的逻辑是一样的——先有足够多的图-文配对数据再有大算力才能训出能用的模型。放在三维领域就是先有海量的模型-自然语言描述配对数据才可能让模型在生成几何体时找到语义与形体的对应关系。1.3 text-to-cad与其他3D生成的根本差异很多人会把text-to-cad和text-to-3D文本生成三维网格混为一谈包括一些做游戏资产生成的工具例如从文本生成带贴图的GLB模型。但这两者的工程目标截然不同。text-to-3D追求的是视觉真实感注重表面纹理、光照材质、形状的像不像输出通常是mesh网格这种格式对游戏引擎友好但对制造完全不友好——网格文件无法表达精确的尺寸公差也无法在CAD软件里直接修改特征参数。text-to-cad追求的是制造可行性和可编辑性。它输出的必须是精确的几何描述通常以STEP、IGES等标准交换格式交付或者直接生成可参数化建模的脚本例如OpenSCAD代码、CadQuery Python脚本。这意味着模型需要在拓扑结构上严格闭合、没有悬边悬面、没有非流形几何体。一个生成结果是视觉漂亮但破面的模型在text-to-3D里可能只是渲染时有点瑕疵但在text-to-cad里就直接宣判了死刑——下游的CAM编程和有限元分析都会因为这个小瑕疵彻底罢工。2. 主流技术路线四种方案逐个拆2.1 大语言模型直接生成CAD脚本这条路是最早被验证可行的也相对最容易复现。思路就是用GPT-4或者Llama这类大模型直接让它输出OpenSCAD、CadQuery或者PythonOCC的代码然后在本地执行脚本生成模型。这么做的好处是门槛低、可控性强而且生成结果天然是参数化的——因为代码本身就是可编辑的。我在实际测试中发现GPT-4对OpenSCAD语法的掌握程度相当不错尤其是处理基本几何体的布尔运算和线性拉伸这些操作。举一个很实际的例子如果要生成一个边长40mm的正方体中心位置挖一个半径12mm的圆柱盲孔只需要把这段需求翻译成OpenSCAD的CSG操作即可。大模型在训练时已经见过大量OpenSCAD脚本所以对这种简单组合体的代码生成准确率非常高。但一旦遇到复杂的自由曲面这种方案的短板就暴露了——代码会变得极其冗长而且模型容易在曲面的数学表达上胡编乱造。所以大语言模型直接生成脚本这条路更适合用在规则几何体、机械零件、夹具、外壳这类场景。如果要生成有机形态的零件就应该考虑其他方案。2.2 专用扩散模型生成B-rep几何体这是目前研究和工程应用最前沿的方向代表工作包括Autodesk Research的Text2CAD、Zoo等创业团队的产品、英伟达的CAD-CREATE项目等。这个方法的核心是训练一个条件扩散模型以自然语言为条件直接生成CAD模型的隐式表达或者离散表示。部分方案是先生成点云再将点云拟合成B-rep曲面也有一些方案直接在B-rep的拓扑结构空间里做生成。这种路线的优势是输出的模型和传统CAD软件的交互方式无缝衔接可以直接在SolidWorks、Fusion 360里打开编辑。但难点在于B-rep数据的生成比mesh困难得多。网格生成可以容忍一定的拓扑错误因为后续还能做remesh修复而B-rep要求生成结果必须满足流形条件每个边连接恰好两个面、每个顶点有连续的曲面邻域这种强约束让生成模型很难直接输出高质量结果。我对这一方案的实测观感是简单几何体如回转体、拉伸体成功率高但稍微复杂的多特征模型经常出现曲面间微小缝隙、面片自交这类问题。虽然可以用CAD内核的缝合功能修但修一个模型的功夫都够自己重新画两遍了。所以这类工具目前更适合概念设计阶段快速出方案而不适合直接上产线。2.3 检索式与程序化生成这个相对而言可能是最被忽视的一条路但从工程落地角度反而是最稳的。核心思想是建一个大规模的标准件库或参数化零件库然后用自然语言去检索最匹配的零件并通过语言模型提取描述中的参数来驱动该零件的参数化脚本。这本质上是一种NLU自然语言理解 程序化建模的组合。典型例子是Fusion 360的标准件库功能。用户输入M8螺母系统返回一个参数化的螺母模型螺栓公称直径、螺距、厚度这些参数都可以继续调节。如果把这种思路扩展到更大的零件库再结合LLM来解析用户文本中的尺寸参数就能做到用自然语言精确调用参数化模型。这条路的技术难度在于领域知识工程——需要为每个零件类型编写参数化脚本但一旦建好它的稳定性远超端到端生成。很多企业内部的智能设计系统其实走的就是这条路只是很少对外宣传。2.4 混合路线LLM加代码解释器混合方案是目前我认为实操首选。具体来说就是让LLM生成CadQuery或者PythonOCC代码然后在沙箱环境里执行将执行结果以STEP文件导出再通过一段验证脚本检查模型的体积、表面积、包围盒尺寸是否符合预期。不符合就自动反馈错误信息给LLM让它修正代码形成循环。这个方案的好处在于它结合了2.1的可控性和代码执行的可验证性。代价是需要搭建额外的工程框架包括代码沙箱、CAD内核、验证工具链。我在自己的项目中就是这么干的整个流程跑通之后效率提升非常明显。虽然单次生成可能因为代码错误反复迭代好几轮但最终一定能得到一个拓扑有效、尺寸正确的模型。这在纯端到端的生成方案里是做不到的。3. 实操从文本描述到STEP文件的完整流程3.1 环境准备与工具选型如果你看完上面的方案想自己动手试试我建议从混合路线开始因为它的环境搭建路径最清晰、依赖的开源组件最多。首先是CAD内核的选择。我推荐用CadQuery因为它的Python API设计得相当直观而且内置了STEP文件导出功能。安装CadQuery时要注意版本兼容问题建议直接用conda创建独立环境避免跟其他Python项目冲突。以下是常用的环境创建命令conda create -n cadq python3.10 -y conda activate cadq pip install cadquery其次是LLM接口。如果你有OpenAI的API密钥可以直接用GPT-4如果受限于网络环境使用国产大模型如通义千问、文心一言的API也行但生成效果有差异。实测下来GPT-4在复杂CadQuery调用的准确率上依然有明显优势尤其在涉及多实体布尔运算时。最后是验证工具。至少要准备一个可以自动读取STEP文件并计算体积/面积的库比如用CadQuery自己就能做。还可以加上trimesh用来做网格化和可视化检查。3.2 提示词设计CAD场景下的有效描述text-to-cad的提示词写法和文本生成图片差异很大。图片提示词追求语义丰富、风格多样而CAD提示词追求的是几何参数的精确性和特征描述的完备性。我总结了几个关键原则一是要给出明确的尺寸单位。模型对单位的感知很迟钝描述中如果不写毫米或者英寸生成结果很可能是默认系统的任意值。所以直径50和直径50mm在模型看来是两回事。二是要区分特征和操作。比如需要描述底板上开了4个通孔而不是说一个带孔的板。前者让LLM明确知道要用四条圆柱体去减材料后者可能导致它在板上生成一个凹槽而非通孔。三是要主动描述特征间的空间关系。像孔心到板边缘距离为10mm、六个孔沿圆周均布这类表述能显著提高LLM生成正确约束关系的概率。下面用CadQuery的案例来直观演示。拿一个100x60x10mm的底板四角各有一个直径8mm的通孔孔心距边10mm来说一段相对标准的CadQuery代码如下import cadquery as cq result ( cq.Workplane(XY) .box(100, 60, 10) .faces(Z) .workplane() .rect(100 - 20, 60 - 20, forConstructionTrue) .vertices() .hole(8) ) cq.exporters.export(result, plate.step)这段代码在CadQuery里的执行路径是先创建一个箱体然后选择顶面进入草图模式画一个倒角的矩形作为构造参考取矩形的四个顶点打孔。运行它就能得到一个STEP文件。这个案例的代码量不大但对初学者来说已经能覆盖80%的常规操作模式了。3.3 生成、评估与迭代优化在得到最初的STEP文件后千万别直接拿去用——先跑验证脚本。最常见的问题是生成结果比要求的尺寸大了一圈或者完全没做布尔减运算。遇到这种问题单纯改提示词可能效果有限更有效的办法是让LLM自己解释它生成的代码逻辑。实操中可以这样把校验错误反馈给模型我要求底板尺寸是100x60x10但你生成的体积是72000立方毫米对应尺寸是120x60x10请检查代码中box()函数的参数。 这个反馈回路非常关键它其实在模仿人类工程师的检查流程——发现有偏差就回到特征树里找问题。实测这样来回两三轮之后正确率会从最初的60%左右直接升到90%以上。如果一次生成就想要比较高的成功率建议在提示词里要求模型先输出参数列表再写代码。这种两步走的方式可以让模型显式地校验参数显著减少低级错误。4. 真实应用场景与项目落地经验4.1 快速原型与概念设计text-to-cad最有应用潜力的场景之一是产品构思阶段的快速原型。传统流程里工业设计师画完草图交给结构工程师做三维建模光沟通成本就吃掉大半天。现在设计师可以自己用自然语言描述概念模型一个圆角矩形的外壳顶部有一个椭圆形的凸台右侧有一个直径10mm的圆形开口让AI直接生成初版模型然后再导入CAD软件微调。我和几个设计师朋友交流过他们最认可的反而不是生成精度而是试错成本低。反正生成一个概念模型只要几十秒不满意就换个描述再来一次这比在软件里一点一点拉草图、做约束高效得多。不过要提醒的是AI生成的概念模型在审美和比例上往往偏保守看多了会有模板感所以它更适合做方案发散起点而不是设计终点。4.2 标准件库的自动构建把text-to-cad用在标准件库建设上是我目前见到落地价值最扎实的方向。很多非标设备制造企业手里有几万种历史零件模型但大多是老工程师手工建的命名混乱、参数不统一检索和复用效率极低。如果把这些零件按类型整理成参数化脚本再用LLM把图纸描述与脚本绑定就能构建出可自然语言检索的智能零件库。举例来说工厂里常见的带座轴承、直线导轨滑块、联轴器这些零件都可以写成CadQuery脚本把关键尺寸做成函数参数。然后用户只需要输入类似带座轴承 UCP205这样的描述系统就自动从库里调出脚本、生成模型并出BOM。整个过程不再依赖人工翻图库。这个场景的ROI非常高因为标准件本身形状稳定、参数体系清晰非常适合程序化建模。端到端生成反而没那么实用——因为它输出的模型不如参数化脚本稳定。4.3 教学与培训场景text-to-cad在教学场景的潜力经常被低估。我的一个朋友在大学教机械制图他发现学生最大的问题不是看不懂三视图而是很难把二维视图中的特征逻辑转换到三维建模的操作序列中。用text-to-cad工具学生可以输入主视图是一个直径40的圆左视图是一个宽30高20的矩形请生成对应的拉伸体然后立刻看到模型结果再反向推导这个模型对应CAD软件里的哪些操作。这种自然语言到特征树的映射讲解方式比传统PPT教学直观太多了。当然这也意味着老师需要提前设计好一套提示词模板控制生成模型的复杂度避免学生被不稳定的生成结果带到沟里。综合来看AI生成CAD的准入门槛正在快速降低但使用者的工程素养和几何直觉反而变得更加重要——因为你需要判断AI给你的模型到底对不对。5. 常见问题与避坑指南5.1 几何精度不够怎么办这是text-to-cad落地时遇到最多的抱怨。我自己的实测数据显示直接端到端生成的STEP文件尺寸误差平均在5%到15%之间。对于很多应用场景来说这个误差是不可接受的。要解决精度问题唯一的办法是改变工作流——不要期望端到端模型直接给出精确模型而是让LLM生成参数化逻辑尺寸由人工在代码里确认。我就是把尺寸参数拎出来放在一个配置文件中让LLM只负责生成建模逻辑这样即使模型第一次给错了尺寸改配置文件里的数值就能快速修复不需要重新生成整个代码。还有一个容易被忽略的精度点单位制。很多开源的CAD数据集以英寸为单位建模而国内工程场景普遍用毫米。如果直接使用国外预训练模型生成的STEP文件常常是英制单位转成公制后尺寸就变了。导入CAD软件后发现尺寸不对先查模型单位设置这个问题占了我前期踩坑比例的很大一部分。5.2 语义理解偏差的经典案例我整理几个典型的语义理解偏差案例供大家参考排查自己的提示词问题镂空和开槽混淆。模型可能把一个用文字描述的镂空装饰理解为完全穿透的孔洞导致生成结果在实际制造时变成废品。法兰隐含的孔位规则缺失。如果提示词只说法兰不提孔数和分布LLM生成的默认法兰几乎肯定和你需要的标准不一致。正确做法是给出完整的参数清单。圆角作用范围不明确。四边圆角LLM可能理解为在四个角点做球面圆角也可能理解为四条边线做等半径圆角描述时最好加一句圆角半径5mm作用于竖直边。这些偏差并非模型不够智能而是自然语言本身存在歧义。工程师之间的默契在AI这里并不存在所以写提示词时要像给供应商写技术要求一样严谨。5.3 算力与成本控制如果使用云端LLM API来驱动text-to-cad每次生成大约消耗几千到几万token。对个人开发者来说一个月几十美元还吃得消但企业级频繁调用的话成本会快速上升。一个可行的折中方案是小模型简单提示词生成初稿再用开源CAD内核做本地校验只把出错的案例发给大模型来回滚修正。这样能把大模型的调用量降低到原来的五分之一以下。另外在本地部署开源模型也是一种思路。目前有一些7B、13B参数量的代码模型在OpenSCAD/CadQuery生成上有不错表现比如DeepSeek-Coder和CodeLlama系列。它们的准确率比GPT-4低一截但胜在零成本、可私有化。实际使用中我用过本地模型做批量零件生成可以先把指令参数模板化再让本地模型填充参数化代码片段。最后提一个数据安全的大前提。text-to-cad如果要接云端大模型API输入的文本中不能包含内部型号、特殊公差等敏感信息。对于军工、航空航天等保密要求高的单位强烈建议使用本地部署的模型或私有化中间件不要为了一时的便捷埋下合规隐患。我在实际使用中的一个体会是不要试图用AI一次性完成从零到一的全部建模工作。更合理的方式是把text-to-cad当做一个高效的草稿助手让它帮你完成基础几何体的搭建和标准结构的排布然后由工程师做细节调整和工程验证。这个组合能发挥双方各自的优势——AI擅长快速生成符合常规结构的模型工程师擅长判断设计合理性、处理特殊约束。这套工作流我从今年年初开始系统性使用在非标零件模型生成上大约能节省30%到40%的建模时间。后续我还在试验把text-to-cad和有限元分析前处理打通让生成的模型直接进入仿真流程。如果跑通了再来分享一轮新的经验。