Text-to-CAD实测：用自然语言生成参数化CAD模型的完整指南

如果你一年前告诉我，靠一句自然语言描述就能拿到一个可直接进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主要分成两条技术路线，下面用一个表格直观对比。

我先说结论：现阶段真正能落地的其实是"程序化代码生成"这条路线。原因不复杂——工业界所有主流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特征的控制粒度更细，而且能直接用OCCT（OpenCASCADE）内核出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如果对特征依赖树理解不到位，生成的代码看似每一行都没语法错误，但执行到某一步就报"can't 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目前在工业侧的靠谱定位是"设计前期的加速器"，而不是"能独立完成生产的工具"。它擅长把脑子里模糊的想法快速变成可以讨论、可以迭代的初版实体，但它不擅长处理工程里那些微妙的配合、公差和制造约束。

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模板和验证流水线搭好，再逐步往复杂特征推进。你踩过的每一个坐标轴错乱、每一次布尔运算失败，都会变成这套工具在你业务里真正变可靠的路基。