做CAD这么些年我一直觉得最浪费时间的事情不是画图本身而是把一句清楚的话翻译成一堆坐标、图层和约束。老板说“给我一个DN50法兰盘4个螺栓孔”听起来多简单但落到CAD里就是一堆圆、阵列、布尔运算和公差标注。text-to-cad这个方向说白了就是想让软件替我们干这件翻译的活——你把需求说清楚它把模型给你。这篇文章我会结合自己用开源方案做测试的真实体验把text-to-cad的原理、最小可落地的实现流程、以及我踩过的坑一次性讲透。1. 为什么text-to-cad值得认真对待1.1 传统CAD建模的卡点在哪里很多刚入行的朋友会觉得CAD难在命令记不住快捷键用不熟。但干久了你会发现命令只是工具层的事真正卡住效率的是“需求到模型”这一段过程。一个零件从口头描述变成可用的三维模型中间要经过需求拆解、尺寸确认、特征规划、草图绘制、特征建模、约束添加、检查修改任何一个环节出现理解偏差模型就得推倒重来。我见过太多老师傅嘴里讲得头头是道但一到软件里输入参数就犹豫半天也见过新手对着一个简单轴套翻来覆去改特征树改了十几遍。这不是操作水平的问题而是“语言表达”和“几何表达”之间缺失了一座桥。传统CAD擅长的是从草图到特征的建模过程但它不懂“我的意思是法兰面厚度按标准走”这种人类语言。text-to-cad这个方向的本质就是给这座桥打桩。1.2 text-to-cad 到底在解决什么用最直白的话说text-to-cad就是把自然语言描述比如“一个直径50mm、高度30mm、中心有直径10mm通孔的圆柱体”转换成一个可以被CAD软件打开和继续编辑的三维模型或者是一段可以直接生成模型的参数化代码。它要解决的核心问题有三个。第一是降低门槛不需要熟练的建模操作也能产出基础模型第二是节省重复劳动像螺栓、垫片、支座这类标准化零件直接用文字生成比翻标准库还快第三是打通上下游设计需求往往由非技术人员提出如果这些需求能直接变成模型初稿整个流程能缩短一大截。但它不是要替代CAD软件而是做一个“前置生成器”。真正到出工程图、公差标注、有限元分析的环节依然要回到专业CAD环境里完成。理解这一点很关键它决定了你用什么思路去评估和引入这个技术。1.3 典型适用场景从零件到构件从我这段时间的实测来看text-to-cad最适合的场景是参数化特征明显的机械零件比如法兰、轴套、支架、壳体、齿轮毛坯这类有明确几何规律的东西。因为它们能用“直径、高度、孔数、壁厚”这些参数说清楚模型生成的成功率非常高。建筑和工程构件方向也有应用比如用文字生成门窗洞口、幕墙分格、标准立柱节点。这些构件重复度高、参数体系成熟天然适合用文字描述驱动。但草地、树木、雕塑这类自由曲面就不太适合至少现阶段的大语言模型和生成网络做这类东西还很吃力容易生成一堆看着像模型、实际没法用的破面。2. 把一句话变成CAD模型内部发生了什么2.1 先拆解自然语言怎么变成参数这一步本质上是大语言模型在做意图识别和参数抽取。你输入“一个直径50mm、高度30mm、中心有直径10mm通孔的圆柱体”模型需要做的第一件事是把这句话拆成关键实体圆柱体是基础体素50mm和30mm是尺寸参数10mm通孔是特征操作。实际测试下来模型的抽取效果取决于两个因素一是描述句里的参数是否完整二是单位是否明确。我试过输入“一个50的圆柱”模型经常猜不准这50到底是指直径还是半径是毫米还是厘米。所以我现在自己写需求描述时都会刻意把“直径”、“高度”、“通孔”这类词带上同时强制加上单位。这一点后面我会给一套提示词模板照着写基本不会翻车。2.2 几何生成的三种主流路线第一种是程序化建模典型代表是OpenSCAD、CadQuery和Build123d。这些工具接受代码形式的几何描述比如“ cylinder(d50, h30) ”再加一个“ hull() ”布尔运算就能得到模型。text-to-cad在这里的落地方式是让大语言模型直接生成这段代码我再拿到CAD环境里执行。这种方案的优点是结果可编辑、参数可改、溯源清晰缺点是你得选一个支持程序化建模的CAD工作流。第二种是参数化特征建模典型代表是AutoCAD的智能块、Fusion 360的API二次开发以及FreeCAD的Python脚本。这类方案的思路是事先定义好特征模板大语言模型只负责把自然语言匹配到模板参数上。优点是稳定、可控、生成的特征树干净缺点是需要预先做大量模板库建设属于“一次投入长期复用”。第三种是神经隐式表示也就是用Point-E、Shape-E这类扩散模型直接生成网格或点云。这条路线视觉效果好、自由形状能力强但输出结果通常要经过网格修复、曲面重建才能进入实体建模流程离真正的制造级CAD还有距离。我的判断是短期看方案一和方案二最实用方案三更适合做概念设计和前期可视化。2.3 输入质量如何决定输出质量这里必须说一个很残酷的现实text-to-cad的输出质量九成取决于输入描述的质量而不是模型本身。我做过一组对比实验同样的生成模型输入“做一个法兰”出来的是一坨无法辨认特征的东西输入“做一个DN50法兰外径165mm内径61mm螺栓孔4个直径18mm均布在直径125mm的螺栓圆上”出来的模型几乎可以直接用。这说明什么说明自然语言的歧义性才是最大的拦路虎。模型再强也没法替你猜“差不多”、“按标准来”这些词的具体含义。所以我在所有流程里都会强调一句给模型的文本描述就当作你在给一个经验不足但执行力极强的实习生下需求必须把参数、单位、特征方向、布尔关系全部拆清楚。3. 动手做一个text-to-cad最小流程用开源方案生成一个法兰盘3.1 准备环境Python、OpenSCAD、大语言模型API先说结论我目前最推荐的最小验证方案是“大语言模型 OpenSCAD”。OpenSCAD是一个免费开源的实体建模工具建模方式就是写代码非常适合作为text-to-cad的落点。整个链路是我用Python写一个脚本把文本描述发送给大语言模型模型返回OpenSCAD代码我保存成 .scad 文件再用OpenSCAD打开渲染或导出STL。环境准备清单如下安装Python 3.9以上并安装 openai、anthropic 或其他模型提供商的SDK看你自己用哪家。安装OpenSCAD官方下载对应系统版本即可。安装后建议把 openscad 命令加到系统PATH里后面可以命令行直接调用。准备一个大语言模型的API Key。我用的是Claude和GPT系列来回对比本地模型我也试过比如调用 Ollama 跑 Qwen2.5-Coder效果也够用主要看你的机器配置。这里提醒一下不要把API Key硬编码在脚本里。我之前图省事写在代码里结果不小心把仓库推到了公开平台差点被薅走额度。现在都是统一放到环境变量里脚本里用 os.getenv() 读取。3.2 设计一句话描述DN50法兰盘的需求拆解接下来我们用一个具体例子走通全流程。假设要做的是DN50法兰盘我先按标准把关键参数列出来再拼成一段结构化的文本描述。我常用的描述模板是基础体素 尺寸参数 特征操作 单位。我先在草稿里写清楚参数法兰外径165mm内径61mm厚度18mm4个螺栓孔直径18mm均匀分布在直径125mm的螺栓圆上。然后拼成下面的提示词“创建一个实心的圆柱体作为法兰盘主体外径165mm厚度18mm在圆柱中心打一个直径61mm的通孔在距离圆心62.5mm的位置均匀分布4个直径18mm的通孔孔中心所在的螺栓圆直径为125mm。请生成OpenSCAD代码。”核心要求是“把特征顺序交代清楚”。先主体、再主孔、再阵列孔模型理解起来会轻松很多。如果一次把所有特征混在一起比如“DN50法兰35度斜角4个孔外径165”生成结果大概率会漏特征。3.3 让模型生成OpenSCAD代码并导入查看直接上脚本示例我用的就是简单的CLI方式import os import subprocess from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) prompt 创建一个实心的圆柱体作为法兰盘主体外径165mm厚度18mm。 在圆柱中心打一个直径61mm的通孔。 在距离圆心62.5mm的位置均匀分布4个直径18mm的通孔 孔中心所在的螺栓圆直径为125mm。 请生成OpenSCAD代码只输出代码不要解释。 resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: 你是一名资深CAD建模工程师精通OpenSCAD。}, {role: user, content: prompt}, ], temperature0.2, ) scad_code resp.choices[0].message.content.strip() with open(flange.scad, w, encodingutf-8) as f: f.write(scad_code) subprocess.run([openscad, -o, flange.stl, flange.scad])这里有两个细节值得注意。第一我把 temperature 设成0.2因为模型生成代码需要确定性优先而不是创意优先。第二我在提示词里要求“只输出代码不要解释”否则模型有时会加上一大段文字说明导致 .scad 文件没法直接渲染。跑完脚本后用OpenSCAD打开 flange.scad正常情况下你会看到4个螺栓孔均匀分布、中心孔贯通、主体尺寸符合我们输入参数的法兰盘。我记得第一次跑通时还挺激动虽然模型生成的代码里变量命名有点乱但几何结果确实是对的。3.4 扩展接入AutoCAD的DWG/DXF流程如果你日常工作还是在AutoCAD、中望CAD这类传统环境里想接入text-to-cad最稳妥的路径是走DXF/DWG中转。OpenSCAD可以直接导出2D轮廓的DXF或者导出STL后再导入到Fusion 360、FreeCAD做后处理。我个人的经验是零件如果只需要二维工程图那就直接在OpenSCAD里导出DXF如果需要三维实体编辑我会用FreeCAD打开STL再转成实体或者直接让模型生成CadQuery代码绕一圈导入到FreeCAD的Python环境里执行。操作路径比OpenSCAD繁琐一些但对实体特征的保真度更好。接入传统CAD时还有个老生常谈的问题单位。OpenSCAD默认单位是毫米但导入到AutoCAD时如果模板是英寸整个模型就会被缩放24.5倍。建议每次导入前先在源环境里把单位统一导出后再用CAD的“单位检查”确认一遍能省掉后期大量调整时间。4. 落地时最容易踩的坑4.1 单位与比例漂移单位问题是我遇到最多的坑没有之一。大语言模型在处理“50”这种数字时经常会默认它是毫米但如果你在提示词里写了“法兰盘直径50”模型可能生成 radius50 的圆柱而不是 diameter50。这一来一去实际尺寸直接翻倍。我现在有两个硬性习惯。第一所有提示词里必须明确写“直径”、“半径”、“单位mm”同时在系统提示词里加一句“所有尺寸均以毫米为单位请明确区分直径和半径”。第二生成代码后第一件事不是渲染而是先检查代码里的变量值跟我输入的参数是否一致。这一步虽然费几秒钟但能拦住九成以上的低级错误。4.2 特征约束缺失第二个常见问题是模型生成的模型“成形但没约束”。比如生成了一个带孔的板但孔的位置没有加坐标约束或者圆角没有明确半径导致模型看着没问题一进参数化环境就没法改尺寸。因为大语言模型生成的是静态代码它不像人建模时会主动考虑可编辑性。解决思路是引导模型“用变量代替硬编码”。比如在提示词里加一句“请使用变量定义所有关键尺寸并在代码开头集中赋值”。这样生成的OpenSCAD代码就是参数化的后面想改外径只需改一个变量模型整体跟着变。这个技巧我试过很多次能显著提升生成结果的可维护性。4.3 生成结果无法被传统CAD打开虽然STL格式是通用的但STL本身是三角网格进入SolidWorks、NX这类实体建模软件后不能直接编辑特征。很多朋友第一次跑通text-to-cad兴冲冲把STL导入到CAD里结果发现只能看不能改顿时就觉得这个方向不行。这不是方向的问题是格式链路的选型问题。要做实体可编辑最好让模型生成CadQuery或Build123d脚本然后导入到FreeCAD执行或者直接用AutoCAD的AutoLISP脚本生成模型后基本能保留原始特征树。STL只适合做3D打印和可视化验证别拿它当工程交付格式。4.4 与现有图纸库、标准库脱节最后一个大坑是企业落地时才会碰到的text-to-cad生成的模型用的是输入文本里的参数跟你公司内部的物料编码、标准件库、出图模板完全脱节。比如生成一个螺栓模型可能按公制普通螺纹建了模型但公司标准用的是带垫圈的组合螺栓细节完全对不上。我的建议是别指望通用模型能懂企业内部规范。比较务实的路径是做一个中间层把企业标准件参数表持久化大语言模型先做需求识别再从参数表里查匹配项匹配到了就用参数表数据生成匹配不到才让模型自由发挥。这样一个简单的RAG流程就能让text-to-cad在企业场景里从“玩具”变成“工具”。5. 一些实用经验和下一步玩法5.1 提示词工程把需求说清楚我把自己反复打磨的提示词模板分享出来照着用基本不会出大问题角色设定“你是一名资深CAD建模工程师精通OpenSCAD/CadQuery只输出代码。”功能描述“根据以下描述生成参数化模型代码。”参数结构化“基础体素是XXX尺寸是XXX特征是XXX每个尺寸都用变量定义。”单位锁定“所有尺寸均以毫米为单位明确区分直径和半径。”输出限制“只输出代码不输出解释和说明文字。”这套模板的核心价值是把“让模型自由发挥”变成“让模型按我们的约束执行”。顺便说一句网上很多人抱怨text-to-cad生成结果烂我看了下他们的提示词基本就是一句“帮我画个支架”——模型不是不想帮你是真的不知道你说的“支架”是什么规格、什么结构、什么安装方式。5.2 用参数化模板做约束兜底另一个实用技巧是做参数化模板库给模型一个“语境”。我在本地维护了一个基础的OpenSCAD模板文件里面有法兰、轴套、支座、垫片这些常用特征的代码骨架每个骨架的尺寸都留成变量。让模型生成时我会要求它“基于我提供的模板修改参数”而不是自创一套代码风格。这个做法的好处非常明显生成结果的代码风格统一、变量命名规整、后续维护成本低。更重要的是代码里所有特征都是模板里验证过的不会出现莫名其妙的自相交曲面或悬垂边。虽然模型每次生成的代码还是会有些小毛病但整体可信度高了一大截。5.3 评估一个text-to-cad模型好不好用最后聊聊怎么评估text-to-cad模型因为它和评估一般聊天机器人完全是两回事。我自己的评估维度是三维几何正确性、参数还原度、代码可读性、工程可用性。几何正确性最简单用OpenSCAD渲染出来看一眼就知道实体有没有破面、布尔运算对不对。参数还原度要对比输入参数和模型输出代码里的数值重点看直径和半径有没有搞混。代码可读性看变量命名、注释、结构因为后续要维护。工程可用性则要看能否直接导出STEP/IGES进入加工流程这一步目前只有CadQuery这类方案能做到。我实测了多个模型包括商用API和本地开源模型整体感受是代码生成类大模型表现优于通用对话模型商用模型整体稳定但成本偏高本地模型通过量化部署后也能达到不错的水平。关键还是看你的场景重不重视数据隐私重视的话本地模型基本是唯一选择。5.4 再分享一个我最近在玩的扩展最后分享一个我正在做的扩展玩法把text-to-cad和参数化出图串起来。我先让大语言模型根据需求生成CadQuery模型然后在FreeCAD里调用Python脚本自动生成三视图和标注再导出DXF进AutoCAD排版出图。目前已经能让“一个自然语言描述”一路跑到“一张可打印的图纸”整个过程大概需要十几分钟中间基本不需要人介入。做这套流程的初衷是想把text-to-cad从“生成一个孤立的模型”升级成“生成一套可交付的工程文档”。虽然离真正的生产级还有距离但至少证明这个方向是有实际价值的。等我把模板库扩充到覆盖常用非标件再抽时间把完整的流程沉淀成一篇文章。text-to-cad还在快速演进今天写这些经验过半年再看可能就过时了。但核心思想不会变模型负责理解语言工程师负责定义标准。把这两件事分清楚什么时候都不会错。