如果你一年前告诉我靠一句自然语言描述就能拿到一个可直接进CAM软件的法兰盘模型我大概率会当个笑话听。但最近我花了两周时间把 text-to-cad 这条新路子从头到尾完整走了一遍——从跑开源模型、写结构化提示词到导出的STEP文件真实开CAM模拟再到复盘哪些场景能用、哪些场景纯属浪费时间。这篇文章就是想把这些实测体感、技术原理和踩过的坑一次性说清楚给正在观望这个方向、或者准备在自家工作流里引入AI建模的工程师、创客和设计自动化从业者一个相对冷静的参考。1. text-to-cad 到底在解决什么问题从画图到说图的一次范式转移1.1 传统CAD建模的痛点在哪里传统CAD建模的学习曲线陡峭得有点反人类。一个新手要在SolidWorks或FreeCAD里画一个像样的带孔法兰需要先弄懂草图约束、拉伸、切除、圆周阵列、倒角这一整套操作顺序任何一个环节的约束交叉了模型就崩给你看。即便是有经验的工程师大量时间也消耗在重复劳动上改一个板厚、挪一个孔位、换一组螺栓分布直径往往要回到草图层面拖拽半天再等特征树全部重新计算。设计自动化喊了这么多年真正落地的还是参数化模板这类偏预定义的方案换个结构就得重新做人。text-to-cad 想解决的正是这个痛点把用鼠标和键盘描述几何变成用自然语言描述意图。它的输入是一段话比如一个外径80mm、内径40mm、厚度10mm的法兰盘在半径60mm的圆上均匀分布6个直径9mm的通孔输出是一个参数化的CAD实体模型——不是一张图片不是只能看的网格而是带特征树、可编辑、可重新参数化、能导出到CAM做加工的实体B-rep模型。这里要先泼一盆冷水不要把text-to-cad和你在Midjourney里生成一个法兰盘混淆。文生图生成的是像素网格拿不到制造环节需要的尺寸精度text-to-cad生成的则是数字孪生从根本上是两码事。1.2 text-to-cad 与 AI 生图的本质区别输出数字孪生而不是图片理解这个区别是整个技术方向的灵魂。文生图模型的输出是位图本质上是一堆RGB值的排列模型的嘴巴停留在视觉层面。而CAD模型在工业软件里的底层表达是B-rep边界表示由几何面、边、顶点以及它们之间的拓扑关系构成更重要的是它还带着参数、约束和特征历史。举一个实际例子我用text-to-cad生成一个六角螺栓得到的不是一张看起来像螺栓的图而是一段可执行的建模代码里面定义了六角头的对边距、螺栓杆的直径、长度、螺纹段参数等。我把它导入FreeCAD后直接修改杆长这个参数模型就自动重新生成了相应长度的新螺栓。这就像给你一份可折叠的工程图纸而不是一张螺栓照片。后者只能看前者能改、能算、能拿去加工。所以评估一个text-to-cad系统好不好用出图像不像只是最表层指标。真正的衡量标准是生成结果是否保存了完整的参数化特征、能否被下游CAD/CAM/CAE工具直接消费、改了参数之后是否还能保持拓扑稳定。这也恰恰是当前这个方向难度最大的地方。1.3 目前两条主流技术路线的分野据我实测和调研目前text-to-cad主要分成两条技术路线下面用一个表格直观对比。技术路线核心思路代表方向优点缺点程序化代码生成让LLM生成OpenSCAD、CadQuery或FreeCAD Python脚本再由脚本执行得到B-rep模型Text2CAD、CAD-Coder等天然参数化可编辑可编译推理成本低数据相对好造生成质量强依赖LLM代码能力复杂特征容易写错生成式重建训练扩散模型或Transformer直接输出SDF、点云或简化B-rep部分学术实验项目对复杂自由曲面更友好几何表达能力强输出困难不便参数化编辑离工程使用还远我先说结论现阶段真正能落地的其实是程序化代码生成这条路线。原因不复杂——工业界所有主流CAD系统都是基于参数化内核搭起来的代码生成路线天然能和这套体系对接。OpenSCAD的脚本语法很简单CadQuery更是把选中面、画草图、拉伸、倒角封装成了像样的Python API对LLM来说生成这种代码的难度比从零推断几何低得多。那条生成式重建路线我体验过几个demo结果基本都停留在点云轮廓像那么回事的程度真要拿去做装配干涉检查还差得很远。2. 我把这条路跑通了一次一个法兰盘六角螺栓的真实试验2.1 先确定输出格式而不是先选模型大多数人接触text-to-cad的时候习惯先纠结该用哪个模型我反而建议先想清楚输出格式。因为输出格式决定了整条链路怎么走也决定了哪些坑必然会踩。我这次测试选了 OpenSCAD 做第一输出目标理由有三条它的语义极简就是最基本的布尔运算、线性拉伸、旋转体、循环阵列LLM生成这类代码的成功率明显更高。它是纯文本格式的DSL不需要额外加载复杂图形环境批量测试速度很快。从OpenSCAD可以导出STEP格式后续可以和FreeCAD、CADQuery桥接。如果是生产级应用我其实更推荐CadQuery作为输出目标因为它的Python API表达能力更强对B-rep特征的控制粒度更细而且能直接用OCCTOpenCASCADE内核出STEP。缺点是对LLM的指令跟随能力要求更高初学者踩坑概率也更高。我在测试中总结出的一个体会是与其花大力气让模型直接输出完美的CAD文件不如让模型输出语法正确、逻辑结构清晰的建模代码然后把真实的几何计算交给CAD内核去完成。代码生成路线的精髓就是让AI和CAD内核各司其职——模型负责理解意图和编排特征顺序内核负责保证几何正确性。2.2 一个能稳定出结果的 Prompt 长什么样很多人把text-to-cad用失败第一原因就是提示词写得实在太随意。给模型一句我要一个法兰它当然给你造一个似是而非的东西。由于LLM对自然语言里的歧义极其敏感你需要把工程约束显式写清楚。我自己调了大概二十几轮最后稳定输出合格法兰盘的Prompt长这样用OpenSCAD生成一个法兰盘模型 - 外径 80mm - 内径 40mm - 厚度 10mm - 6个通孔直径 9mm均匀分布在半径 60mm 的螺栓圆上 - 通孔方向沿Z轴 - 法兰盘轴线沿Z轴中心位于原点 - 所有尺寸使用毫米不要做缩放这段Prompt里每个信息都有明确用途。外径/内径/厚度是基础几何尺寸6个通孔、直径、螺栓圆半径是特征布局通孔方向沿Z轴是方向约束中心位于原点是坐标基准毫米/不要缩放是单位约束。少了任何一项模型都会自由发挥。我做过对照实验把通孔方向沿Z轴去掉同一个模型有三次把孔生成在侧面上看起来就像法兰盘的圆柱外壁上打了洞完全不符合工程语义。这个现象说明text-to-cad的Prompt不是写作文是写需求规格书越接近结构化文档输出越接近你想要的东西。2.3 从代码出图到拿到可制造零件中间还得加一步生成代码只是第一步真正让text-to-cad进入可交付状态中间至少还要四道验证环节。第一道是语法编译检查把LLM生成的OpenSCAD代码丢进命令行执行看能不能通过编译这一步就淘汰了大概两三成的输出。第二道是几何离线渲染用OpenSCAD的预览模式快速确认形状是否合理有没有明显的悬空特征、莫名其妙的孔洞、或者比例失调的部分。第三道是格式转换与内核校验将模型导出为STEP文件后用FreeCAD或PythonOCC读回去让OCCT内核做一次真正的几何计算看面是否有缝、实体是否闭合。第四道是尺寸审核用测量工具核对关键尺寸是否符合Prompt里的要求这一步能发现模型在代码里写错数字的情况。听上去很繁琐但实际上大部分可以脚本化。我把编译、渲染、导出、尺寸核对写成了一个自动化流水线丢进去一批Prompt后它会自动把合格和不合格的输出分开。实测下来一个简单法兰盘的完整处理时间大概在30秒到1分钟大部分时间花在OCCT解析STEP上。这个效率对于快速打样场景已经相当可用了。3. 实测中最容易翻车的四个细节语义、坐标、单位与特征顺序3.1 语义歧义是最大的隐性成本Prompt写得再详细LLM对同一句话的理解还是可能跑偏。最典型的例子是顶部这个词。在工程语义里法兰盘顶部通常指沿轴线的上端面孔应该垂直于该端面贯穿。但模型对顶部的理解可能来自通用语料中的视觉概念于是把孔布置在圆柱外侧的顶部区域造成完全错误的几何布局。我用的处理方法是把这类模糊词汇从Prompt里彻底剔除全部替换为坐标方向描述比如孔轴线平行于Z轴特征位于XY平面。这看起来有点机械但恰恰是LLM最容易稳定执行的表述。如果你在做一个固定的业务域建议定义一套工程Prompt模板把常见的歧义词替换成确定性的几何术语。这既降低了模型的胡乱发挥空间也为后续批量生成不同尺寸规格的同类型零件提供了基础。3.2 单位与坐标系的混战单位问题比想象中严重得多。不同建模工具的默认单位不一致OpenSCAD默认毫米FreeCAD支持多种单位系统而CADQuery的依赖脚本经常在毫米和英寸之间切换。LLM学习过大量社区代码生成的代码里经常莫名其妙冒出inch单位或英寸数值比如把80mm写成3.15inch。坐标系更是重灾区。同一个模型在OpenSCAD里Z轴朝上在Blender里Z轴可能被理解成垂直方向的基础但在某些CAD软件里Y轴朝上。模型生成代码时经常把特征放在错误的轴上——本来应该绕Z轴阵列的孔变成了沿Y轴平移。此外负号问题也频繁出现一个本应凸出在正方向的拉伸特征被加了个负号之后整个实体跑到对面去了。对这个问题的治本方案仍然是在Prompt里规范坐标系并在下游验证流程中加入自动检测一旦发现模型落在预期包围盒之外直接判定为不合法输出。3.3 参数约束和特征顺序倒角为什么总翻车这是我在所有测试中最头疼的环节。即使几何形状对了建模步骤的顺序错了也会导致整个特征树崩溃。举个例子一个板件先加工出一个直径较小的通孔再围绕通孔做倒角通常没问题但如果调换顺序——先倒角再打孔——就可能出现倒角面被二次切割边界混乱甚至布尔运算失败。CAD内核在运算层面是严格的几何逻辑每一步操作都依赖上一步产生的拓扑结构。LLM如果对特征依赖树理解不到位生成的代码看似每一行都没语法错误但执行到某一步就报cant compute boolean operation due to non-manifold geometry。这类错误在生成CAD代码里几乎无法完全避免只能靠后置验证捕捉。我的经验是在Prompt里显式要求先创建基础体再做所有切割/孔洞类特征最后做倒角/圆角类修饰特征。这类操作顺序规范对提高编译成功率非常有帮助。实测中遵守这种顺序规则的法兰类零件生成成功率接近七成而不加规则的成功率在两成左右徘徊。3.4 公差语义你以为的通孔不是模型以为的通孔还有个容易被忽略的坑是工程语义里的公差。自然语言里的通孔在机械制图里隐含了孔直径的公差等级但模型根本不理解ISO公差配合关系。如果需求里说直径9mm的通孔配合M8螺栓真实设计时孔径可能需要按间隙配合或过渡配合选取9.2mm或9mm而不是死板的9.0。text-to-cad目前对这类工程约定几乎为零感知。解决方式是把所有关键尺寸明确到小数位并且自己把公差补偿算好再写进Prompt不要把配合紧配这种词交给模型去猜。4. 实测效果与适合的业务场景我踩完以后的真实判断4.1 简单机械件真的可以用起来了我在这两周里测试了法兰盘、六角螺栓、垫片、电机安装支架、带槽盖板等几类简单机械件。坦白说法兰盘和垫片这类规则回转体零件的生成效果超出预期在Prompt写规范的前提下一次通过率能达到六到七成剩余几成经过一轮纠错基本也能定型。电机安装支架这类零件更有代表性。它包含一块基板、四角的安装孔、一个向上翻起的轴承座面、以及座面上的中心孔——特征数量不多但有明显的体块组合逻辑。模型在理解了基板-翻边-座面的顺序之后生成的零件基本能符合设计意图。我算了下时间从写Prompt到拿到一个可以开CAM模拟的STEP文件大约花了40分钟其中大部分时间耗在我的反复测量和修正上。如果是熟练工程师直接在CAD里画这个件大概也要一二十分钟但那是纯体力劳动脑子里已经在构思最终形状而text-to-cad的价值在于它让想法到雏形这个过程变得几乎零门槛。4.2 装配体与复杂曲面零件暂时不要抱太大期望看到text-to-cad的效果后我又尝试了装配体和一个带复杂曲面的连接杆。结果非常诚实——大量时间被浪费在修正装配配合关系上。生成齿轮这类需要精确啮合的传动件时模型给出的齿形参数经常自相矛盾而两个独立生成的零件放到装配环境里配合约束几乎必然报错。倒不是模型不认识齿轮而是装配本身就是程序设计里最难的环节之一你需要让模型同时考虑两个独立零件之间的坐标对齐、自由度约束、公差配合而这远远超出了当前text-to-cad系统把自然语言映射为单个模型特征的能力范围。复杂曲面同理一个需要满足空气动力学的光滑曲面靠几段代码来描述并不现实生成式重建路线对这种几何更有潜力但目前的输出精度离可制造标准还很远。4.3 什么时候用它什么时候不用我的选型准则踩完这些坑之后我整理了一套自己的使用准则分享出来供参考场景是否适合text-to-cad说明标准件快速建模法兰/垫片/螺栓很适合规则清晰参数简单一次成功率较高板类/机架类非标零件打样比较适合需要Prompt写规范输出后仍需人工校验多方案概念对比很适合快速产生多个粗略形状供讨论筛选严格尺寸公差的出图交付暂不建议模型对公差缺乏理解仍需人工精确控制装配体/互相配合的零件暂不建议配合约束容易矛盾返工成本高复杂自由曲面/外观造型很不适合输出离可制造精度差距大换句话说text-to-cad目前在工业侧的靠谱定位是设计前期的加速器而不是能独立完成生产的工具。它擅长把脑子里模糊的想法快速变成可以讨论、可以迭代的初版实体但它不擅长处理工程里那些微妙的配合、公差和制造约束。5. 如果要自己搭建一个 text-to-cad 工具选型建议与评估方法5.1 数据从哪来公开数据集与自建语料如果你想基于开源权重微调一个自己的text-to-cad模型首要问题是训练数据。目前公开可用的典型数据集包括Text2CAD项目整理的自然语言-OpenSCAD/CadQuery指令对以及CADBench这类偏基准评测的代码建模数据。它们对验证模型能力很有用但用在特定业务领域里往往不够。我的建议是自建小规模业务语料做二次微调具体做法分三步先从公司历史CAD图纸里筛选出形态差异较大的典型零件再用CadQuery把每个零件写成可执行的参数化脚本最后拿这批脚本配合LLM直接用API即可反向生成对应的自然语言描述。这个流程本质上是造指令对比纯人工标注快得多。需要注意清洗步骤筛掉那些语法错误、特征缺失、和描述不匹配的样本否则噪声会直接传进微调过程。5.2 微调路线怎么走通用大模型还是专用小模型这是大家最常问的问题之一。我的判断是如果你的目标是简单规则零件一个7B级别的代码模型完全够用如果目标涉及复杂特征顺序和多步建模逻辑14B以上的模型差距立刻显现出来。从实操角度通用大模型的指令跟随能力和上下文理解能力更强但是部署成本和单次推理延迟更高专用小模型可以大幅压低成本却需要更精心的数据清洗和评估。另外建议优先选择代码能力强的基座模型而不是普通对话模型。因为text-to-cad的底层任务本质上是自然语言到结构化代码的翻译基座模型在代码任务上的训练充分度直接决定了你微调的上限。许可证问题也要提前看避免踩到商用限制。5.3 评估时别只看能不能出图我的三层评测清单最后说一说怎么评估一个text-to-cad系统。很多演示视频只展示成功的漂亮案例但真正投入生产前我建议至少跑三层评测第一层是编译成功率。把100条测试Prompt丢进去统计生成的代码有多少能通过语法编译。这一层能快速筛选掉模型能力不足的方案低于三成基本不用看后续。第二层是几何一致性。把生成的模型和预期尺寸做对比用包围盒中心偏差、关键孔径误差、特征数量差异三个指标来衡量。如果你的模型能导出STEP直接让OCCT内核做实体-实体对比可以得到非常客观的相似度分数。这一层主要防止模型能跑但生成的根本不是你要的东西这种情况。第三层是工程可用性评估。把每个输出放到一个模拟装配或CAM前处理流程里跑一遍看有没有干涉、有没有不可加工特征、孔的轴线与面是否垂直等。这一层最费时间但决定了一个模型能否真正进入你的生产链路。我个人的感受是多数项目在第一层和第二层看起来还行一到第三层就原形毕露。所以评估预算至少要留一半给最终场景的端到端测试不要被几个花哨的demo迷惑。我在实际使用中还有个体会text-to-cad最好的定位不是取代CAD工程师而是把工程师从重复劳动里捞出来。我后来把它接进了小批量非标零件的快速打样流程——需求一描述出来就能拿到一个可以讨论的实体雏形客户说孔再大一点板再薄一点改一句话重新生成就行省掉了大量的草图重画时间。如果你也想试这个方向建议从最简单的规则零件起步先把Prompt模板和验证流水线搭好再逐步往复杂特征推进。你踩过的每一个坐标轴错乱、每一次布尔运算失败都会变成这套工具在你业务里真正变可靠的路基。
如果你一年前告诉我靠一句自然语言描述就能拿到一个可直接进CAM软件的法兰盘模型我大概率会当个笑话听。但最近我花了两周时间把 text-to-cad 这条新路子从头到尾完整走了一遍——从跑开源模型、写结构化提示词到导出的STEP文件真实开CAM模拟再到复盘哪些场景能用、哪些场景纯属浪费时间。这篇文章就是想把这些实测体感、技术原理和踩过的坑一次性说清楚给正在观望这个方向、或者准备在自家工作流里引入AI建模的工程师、创客和设计自动化从业者一个相对冷静的参考。1. text-to-cad 到底在解决什么问题从画图到说图的一次范式转移1.1 传统CAD建模的痛点在哪里传统CAD建模的学习曲线陡峭得有点反人类。一个新手要在SolidWorks或FreeCAD里画一个像样的带孔法兰需要先弄懂草图约束、拉伸、切除、圆周阵列、倒角这一整套操作顺序任何一个环节的约束交叉了模型就崩给你看。即便是有经验的工程师大量时间也消耗在重复劳动上改一个板厚、挪一个孔位、换一组螺栓分布直径往往要回到草图层面拖拽半天再等特征树全部重新计算。设计自动化喊了这么多年真正落地的还是参数化模板这类偏预定义的方案换个结构就得重新做人。text-to-cad 想解决的正是这个痛点把用鼠标和键盘描述几何变成用自然语言描述意图。它的输入是一段话比如一个外径80mm、内径40mm、厚度10mm的法兰盘在半径60mm的圆上均匀分布6个直径9mm的通孔输出是一个参数化的CAD实体模型——不是一张图片不是只能看的网格而是带特征树、可编辑、可重新参数化、能导出到CAM做加工的实体B-rep模型。这里要先泼一盆冷水不要把text-to-cad和你在Midjourney里生成一个法兰盘混淆。文生图生成的是像素网格拿不到制造环节需要的尺寸精度text-to-cad生成的则是数字孪生从根本上是两码事。1.2 text-to-cad 与 AI 生图的本质区别输出数字孪生而不是图片理解这个区别是整个技术方向的灵魂。文生图模型的输出是位图本质上是一堆RGB值的排列模型的嘴巴停留在视觉层面。而CAD模型在工业软件里的底层表达是B-rep边界表示由几何面、边、顶点以及它们之间的拓扑关系构成更重要的是它还带着参数、约束和特征历史。举一个实际例子我用text-to-cad生成一个六角螺栓得到的不是一张看起来像螺栓的图而是一段可执行的建模代码里面定义了六角头的对边距、螺栓杆的直径、长度、螺纹段参数等。我把它导入FreeCAD后直接修改杆长这个参数模型就自动重新生成了相应长度的新螺栓。这就像给你一份可折叠的工程图纸而不是一张螺栓照片。后者只能看前者能改、能算、能拿去加工。所以评估一个text-to-cad系统好不好用出图像不像只是最表层指标。真正的衡量标准是生成结果是否保存了完整的参数化特征、能否被下游CAD/CAM/CAE工具直接消费、改了参数之后是否还能保持拓扑稳定。这也恰恰是当前这个方向难度最大的地方。1.3 目前两条主流技术路线的分野据我实测和调研目前text-to-cad主要分成两条技术路线下面用一个表格直观对比。技术路线核心思路代表方向优点缺点程序化代码生成让LLM生成OpenSCAD、CadQuery或FreeCAD Python脚本再由脚本执行得到B-rep模型Text2CAD、CAD-Coder等天然参数化可编辑可编译推理成本低数据相对好造生成质量强依赖LLM代码能力复杂特征容易写错生成式重建训练扩散模型或Transformer直接输出SDF、点云或简化B-rep部分学术实验项目对复杂自由曲面更友好几何表达能力强输出困难不便参数化编辑离工程使用还远我先说结论现阶段真正能落地的其实是程序化代码生成这条路线。原因不复杂——工业界所有主流CAD系统都是基于参数化内核搭起来的代码生成路线天然能和这套体系对接。OpenSCAD的脚本语法很简单CadQuery更是把选中面、画草图、拉伸、倒角封装成了像样的Python API对LLM来说生成这种代码的难度比从零推断几何低得多。那条生成式重建路线我体验过几个demo结果基本都停留在点云轮廓像那么回事的程度真要拿去做装配干涉检查还差得很远。2. 我把这条路跑通了一次一个法兰盘六角螺栓的真实试验2.1 先确定输出格式而不是先选模型大多数人接触text-to-cad的时候习惯先纠结该用哪个模型我反而建议先想清楚输出格式。因为输出格式决定了整条链路怎么走也决定了哪些坑必然会踩。我这次测试选了 OpenSCAD 做第一输出目标理由有三条它的语义极简就是最基本的布尔运算、线性拉伸、旋转体、循环阵列LLM生成这类代码的成功率明显更高。它是纯文本格式的DSL不需要额外加载复杂图形环境批量测试速度很快。从OpenSCAD可以导出STEP格式后续可以和FreeCAD、CADQuery桥接。如果是生产级应用我其实更推荐CadQuery作为输出目标因为它的Python API表达能力更强对B-rep特征的控制粒度更细而且能直接用OCCTOpenCASCADE内核出STEP。缺点是对LLM的指令跟随能力要求更高初学者踩坑概率也更高。我在测试中总结出的一个体会是与其花大力气让模型直接输出完美的CAD文件不如让模型输出语法正确、逻辑结构清晰的建模代码然后把真实的几何计算交给CAD内核去完成。代码生成路线的精髓就是让AI和CAD内核各司其职——模型负责理解意图和编排特征顺序内核负责保证几何正确性。2.2 一个能稳定出结果的 Prompt 长什么样很多人把text-to-cad用失败第一原因就是提示词写得实在太随意。给模型一句我要一个法兰它当然给你造一个似是而非的东西。由于LLM对自然语言里的歧义极其敏感你需要把工程约束显式写清楚。我自己调了大概二十几轮最后稳定输出合格法兰盘的Prompt长这样用OpenSCAD生成一个法兰盘模型 - 外径 80mm - 内径 40mm - 厚度 10mm - 6个通孔直径 9mm均匀分布在半径 60mm 的螺栓圆上 - 通孔方向沿Z轴 - 法兰盘轴线沿Z轴中心位于原点 - 所有尺寸使用毫米不要做缩放这段Prompt里每个信息都有明确用途。外径/内径/厚度是基础几何尺寸6个通孔、直径、螺栓圆半径是特征布局通孔方向沿Z轴是方向约束中心位于原点是坐标基准毫米/不要缩放是单位约束。少了任何一项模型都会自由发挥。我做过对照实验把通孔方向沿Z轴去掉同一个模型有三次把孔生成在侧面上看起来就像法兰盘的圆柱外壁上打了洞完全不符合工程语义。这个现象说明text-to-cad的Prompt不是写作文是写需求规格书越接近结构化文档输出越接近你想要的东西。2.3 从代码出图到拿到可制造零件中间还得加一步生成代码只是第一步真正让text-to-cad进入可交付状态中间至少还要四道验证环节。第一道是语法编译检查把LLM生成的OpenSCAD代码丢进命令行执行看能不能通过编译这一步就淘汰了大概两三成的输出。第二道是几何离线渲染用OpenSCAD的预览模式快速确认形状是否合理有没有明显的悬空特征、莫名其妙的孔洞、或者比例失调的部分。第三道是格式转换与内核校验将模型导出为STEP文件后用FreeCAD或PythonOCC读回去让OCCT内核做一次真正的几何计算看面是否有缝、实体是否闭合。第四道是尺寸审核用测量工具核对关键尺寸是否符合Prompt里的要求这一步能发现模型在代码里写错数字的情况。听上去很繁琐但实际上大部分可以脚本化。我把编译、渲染、导出、尺寸核对写成了一个自动化流水线丢进去一批Prompt后它会自动把合格和不合格的输出分开。实测下来一个简单法兰盘的完整处理时间大概在30秒到1分钟大部分时间花在OCCT解析STEP上。这个效率对于快速打样场景已经相当可用了。3. 实测中最容易翻车的四个细节语义、坐标、单位与特征顺序3.1 语义歧义是最大的隐性成本Prompt写得再详细LLM对同一句话的理解还是可能跑偏。最典型的例子是顶部这个词。在工程语义里法兰盘顶部通常指沿轴线的上端面孔应该垂直于该端面贯穿。但模型对顶部的理解可能来自通用语料中的视觉概念于是把孔布置在圆柱外侧的顶部区域造成完全错误的几何布局。我用的处理方法是把这类模糊词汇从Prompt里彻底剔除全部替换为坐标方向描述比如孔轴线平行于Z轴特征位于XY平面。这看起来有点机械但恰恰是LLM最容易稳定执行的表述。如果你在做一个固定的业务域建议定义一套工程Prompt模板把常见的歧义词替换成确定性的几何术语。这既降低了模型的胡乱发挥空间也为后续批量生成不同尺寸规格的同类型零件提供了基础。3.2 单位与坐标系的混战单位问题比想象中严重得多。不同建模工具的默认单位不一致OpenSCAD默认毫米FreeCAD支持多种单位系统而CADQuery的依赖脚本经常在毫米和英寸之间切换。LLM学习过大量社区代码生成的代码里经常莫名其妙冒出inch单位或英寸数值比如把80mm写成3.15inch。坐标系更是重灾区。同一个模型在OpenSCAD里Z轴朝上在Blender里Z轴可能被理解成垂直方向的基础但在某些CAD软件里Y轴朝上。模型生成代码时经常把特征放在错误的轴上——本来应该绕Z轴阵列的孔变成了沿Y轴平移。此外负号问题也频繁出现一个本应凸出在正方向的拉伸特征被加了个负号之后整个实体跑到对面去了。对这个问题的治本方案仍然是在Prompt里规范坐标系并在下游验证流程中加入自动检测一旦发现模型落在预期包围盒之外直接判定为不合法输出。3.3 参数约束和特征顺序倒角为什么总翻车这是我在所有测试中最头疼的环节。即使几何形状对了建模步骤的顺序错了也会导致整个特征树崩溃。举个例子一个板件先加工出一个直径较小的通孔再围绕通孔做倒角通常没问题但如果调换顺序——先倒角再打孔——就可能出现倒角面被二次切割边界混乱甚至布尔运算失败。CAD内核在运算层面是严格的几何逻辑每一步操作都依赖上一步产生的拓扑结构。LLM如果对特征依赖树理解不到位生成的代码看似每一行都没语法错误但执行到某一步就报cant compute boolean operation due to non-manifold geometry。这类错误在生成CAD代码里几乎无法完全避免只能靠后置验证捕捉。我的经验是在Prompt里显式要求先创建基础体再做所有切割/孔洞类特征最后做倒角/圆角类修饰特征。这类操作顺序规范对提高编译成功率非常有帮助。实测中遵守这种顺序规则的法兰类零件生成成功率接近七成而不加规则的成功率在两成左右徘徊。3.4 公差语义你以为的通孔不是模型以为的通孔还有个容易被忽略的坑是工程语义里的公差。自然语言里的通孔在机械制图里隐含了孔直径的公差等级但模型根本不理解ISO公差配合关系。如果需求里说直径9mm的通孔配合M8螺栓真实设计时孔径可能需要按间隙配合或过渡配合选取9.2mm或9mm而不是死板的9.0。text-to-cad目前对这类工程约定几乎为零感知。解决方式是把所有关键尺寸明确到小数位并且自己把公差补偿算好再写进Prompt不要把配合紧配这种词交给模型去猜。4. 实测效果与适合的业务场景我踩完以后的真实判断4.1 简单机械件真的可以用起来了我在这两周里测试了法兰盘、六角螺栓、垫片、电机安装支架、带槽盖板等几类简单机械件。坦白说法兰盘和垫片这类规则回转体零件的生成效果超出预期在Prompt写规范的前提下一次通过率能达到六到七成剩余几成经过一轮纠错基本也能定型。电机安装支架这类零件更有代表性。它包含一块基板、四角的安装孔、一个向上翻起的轴承座面、以及座面上的中心孔——特征数量不多但有明显的体块组合逻辑。模型在理解了基板-翻边-座面的顺序之后生成的零件基本能符合设计意图。我算了下时间从写Prompt到拿到一个可以开CAM模拟的STEP文件大约花了40分钟其中大部分时间耗在我的反复测量和修正上。如果是熟练工程师直接在CAD里画这个件大概也要一二十分钟但那是纯体力劳动脑子里已经在构思最终形状而text-to-cad的价值在于它让想法到雏形这个过程变得几乎零门槛。4.2 装配体与复杂曲面零件暂时不要抱太大期望看到text-to-cad的效果后我又尝试了装配体和一个带复杂曲面的连接杆。结果非常诚实——大量时间被浪费在修正装配配合关系上。生成齿轮这类需要精确啮合的传动件时模型给出的齿形参数经常自相矛盾而两个独立生成的零件放到装配环境里配合约束几乎必然报错。倒不是模型不认识齿轮而是装配本身就是程序设计里最难的环节之一你需要让模型同时考虑两个独立零件之间的坐标对齐、自由度约束、公差配合而这远远超出了当前text-to-cad系统把自然语言映射为单个模型特征的能力范围。复杂曲面同理一个需要满足空气动力学的光滑曲面靠几段代码来描述并不现实生成式重建路线对这种几何更有潜力但目前的输出精度离可制造标准还很远。4.3 什么时候用它什么时候不用我的选型准则踩完这些坑之后我整理了一套自己的使用准则分享出来供参考场景是否适合text-to-cad说明标准件快速建模法兰/垫片/螺栓很适合规则清晰参数简单一次成功率较高板类/机架类非标零件打样比较适合需要Prompt写规范输出后仍需人工校验多方案概念对比很适合快速产生多个粗略形状供讨论筛选严格尺寸公差的出图交付暂不建议模型对公差缺乏理解仍需人工精确控制装配体/互相配合的零件暂不建议配合约束容易矛盾返工成本高复杂自由曲面/外观造型很不适合输出离可制造精度差距大换句话说text-to-cad目前在工业侧的靠谱定位是设计前期的加速器而不是能独立完成生产的工具。它擅长把脑子里模糊的想法快速变成可以讨论、可以迭代的初版实体但它不擅长处理工程里那些微妙的配合、公差和制造约束。5. 如果要自己搭建一个 text-to-cad 工具选型建议与评估方法5.1 数据从哪来公开数据集与自建语料如果你想基于开源权重微调一个自己的text-to-cad模型首要问题是训练数据。目前公开可用的典型数据集包括Text2CAD项目整理的自然语言-OpenSCAD/CadQuery指令对以及CADBench这类偏基准评测的代码建模数据。它们对验证模型能力很有用但用在特定业务领域里往往不够。我的建议是自建小规模业务语料做二次微调具体做法分三步先从公司历史CAD图纸里筛选出形态差异较大的典型零件再用CadQuery把每个零件写成可执行的参数化脚本最后拿这批脚本配合LLM直接用API即可反向生成对应的自然语言描述。这个流程本质上是造指令对比纯人工标注快得多。需要注意清洗步骤筛掉那些语法错误、特征缺失、和描述不匹配的样本否则噪声会直接传进微调过程。5.2 微调路线怎么走通用大模型还是专用小模型这是大家最常问的问题之一。我的判断是如果你的目标是简单规则零件一个7B级别的代码模型完全够用如果目标涉及复杂特征顺序和多步建模逻辑14B以上的模型差距立刻显现出来。从实操角度通用大模型的指令跟随能力和上下文理解能力更强但是部署成本和单次推理延迟更高专用小模型可以大幅压低成本却需要更精心的数据清洗和评估。另外建议优先选择代码能力强的基座模型而不是普通对话模型。因为text-to-cad的底层任务本质上是自然语言到结构化代码的翻译基座模型在代码任务上的训练充分度直接决定了你微调的上限。许可证问题也要提前看避免踩到商用限制。5.3 评估时别只看能不能出图我的三层评测清单最后说一说怎么评估一个text-to-cad系统。很多演示视频只展示成功的漂亮案例但真正投入生产前我建议至少跑三层评测第一层是编译成功率。把100条测试Prompt丢进去统计生成的代码有多少能通过语法编译。这一层能快速筛选掉模型能力不足的方案低于三成基本不用看后续。第二层是几何一致性。把生成的模型和预期尺寸做对比用包围盒中心偏差、关键孔径误差、特征数量差异三个指标来衡量。如果你的模型能导出STEP直接让OCCT内核做实体-实体对比可以得到非常客观的相似度分数。这一层主要防止模型能跑但生成的根本不是你要的东西这种情况。第三层是工程可用性评估。把每个输出放到一个模拟装配或CAM前处理流程里跑一遍看有没有干涉、有没有不可加工特征、孔的轴线与面是否垂直等。这一层最费时间但决定了一个模型能否真正进入你的生产链路。我个人的感受是多数项目在第一层和第二层看起来还行一到第三层就原形毕露。所以评估预算至少要留一半给最终场景的端到端测试不要被几个花哨的demo迷惑。我在实际使用中还有个体会text-to-cad最好的定位不是取代CAD工程师而是把工程师从重复劳动里捞出来。我后来把它接进了小批量非标零件的快速打样流程——需求一描述出来就能拿到一个可以讨论的实体雏形客户说孔再大一点板再薄一点改一句话重新生成就行省掉了大量的草图重画时间。如果你也想试这个方向建议从最简单的规则零件起步先把Prompt模板和验证流水线搭好再逐步往复杂特征推进。你踩过的每一个坐标轴错乱、每一次布尔运算失败都会变成这套工具在你业务里真正变可靠的路基。
