从去年开始我陆陆续续尝试了好几个号称“你用一句话就能生成三维模型”的工具体验最深的感受是大部分产品要么只能出个“好看的图”要么生成的模型根本没法进工程软件。直到我真正把 text-to-cad 这类工具放进设计流程里跑了一遍才意识到这个方向真正要解决的并不是“生成一个模型”而是“生成一个能用的、可编辑的、符合工程约束的CAD模型”。这篇文章我不讲那些浮于表面的功能介绍直接把我拆解技术路线、跑通工作流、踩过坑的全过程整理出来希望能给正在评估这个方向的工程师或者想入手的创客一些参考。1. 项目概述从“画图”到“说图”text-to-cad到底改变了什么1.1 一句话说清楚text-to-cadtext-to-cad从字面理解就是“文本到CAD”用自然语言描述直接生成CAD模型。你输入一句“一个带四个安装孔的矩形底板长100毫米宽60毫米厚5毫米四角倒圆角”系统就能生成对应的三维模型并且输出 STEP、IGES 这类标准CAD交换格式或者直接生成参数化特征树让你能在 SolidWorks、Fusion 360、FreeCAD 里继续编辑。它和传统建模方式最大的区别在于把“操作软件”变成了“表达意图”。过去你建一个零件脑子里想的是“我要用拉伸、切除、阵列”现在你只需要想“我要什么形状什么尺寸什么约束”剩下的交给模型去推理。这个转变看起来只是交互方式变了但底层其实是把几何推理、参数化建模、制造约束这些原本靠人脑完成的工作一部分移交给了算法。1.2 它到底解决了什么痛点我先说一个实际场景。我手上有一批老设备的备件需要逆向建模有些零件结构很简单比如一个法兰盘、一个支架但传统流程也得开CAD软件、建草图、拉伸、打孔一个零件少说半小时。如果是标准件还好直接调用库文件但很多非标件每次都要从头画重复劳动非常重。text-to-cad 真正切中的就是这类“小零件、快交付”的痛点它能把一个简单零件的建模时间从半小时压缩到几分钟。对于结构工程师做前期方案评审、机械加工厂快速出毛坯模型、创客做外壳原型这类工具能明显缩短从“想法”到“模型”的路径。另外一个价值被很多人忽略它能降低三维建模的入门门槛。很多产品经理、工艺工程师、采购人员不需要深度掌握CAD软件但他们对零部件结构是有判断力的。有了文本生成这层“翻译”他们可以直接产出初步模型再交给建模工程师优化信息传递的损耗会小很多。1.3 这个领域为什么值得关注我把话放在这里text-to-cad 不是个噱头它是生成式AI在工程软件领域最有可能率先规模化落地的方向之一。原因很简单机械零部件的几何结构相比科幻场景、游戏角色来说规律性更强、约束更明确尺寸、配合、公差、制造工艺都是可量化的硬约束这些约束对生成模型反而是一种“锚点”能让模型输出更稳定。更关键的是CAD数据的价值密度远高于一张图片或一段视频。一个STEP文件里包含的不只是几何形状还有BOM信息、装配关系、制造特征这些数据一旦能通过文本直接生成对设计自动化、柔性制造、小批量定制都会有连锁影响。我个人的判断是未来两到三年会有越来越多的企业把 text-to-cad 集成到 PLM/PDM 流程里作为前期概念设计的标准入口。2. 核心技术路径语言到CAD的底层逻辑拆解2.1 四条技术路线对比我调研了大量相关项目和论文目前 text-to-cad 的主流实现思路可以归纳为四条路径。这里我直接放一张对比表方便大家理解各自的定位。技术路径基本原理输出形式优点缺点典型代表程序化生成大模型生成CadQuery/OpenSCAD代码执行代码生成模型参数化脚本 实体模型模型可编辑、尺寸精确、特征参数化受脚本语言表达力限制复杂曲面难处理CadQuery 结合 LLM 的方案参数模板匹配从文本提取参数匹配已有参数化模板参数化实体模型稳定可靠、适合系列化零件需要预建模板库灵活性差定制化企业内部方案深度生成网络扩散模型/GAN直接生成体素、隐式场或网格网格/隐式场能生成复杂自由形状精度差、拓扑错误多、难以参数化编辑早期的一些研究项目多模态融合大模型同时理解文本草图点云综合输出建模指令多种混合形式输入灵活、适合复杂场景工程化成熟度低、系统复杂偏前沿探索从这张表能清楚看到越是接近“能用”的路线越倾向于让算法去生成“建模指令”而不是直接生成“几何形状”。这个逻辑其实不复杂CAD软件的核心数据结构是边界表示B-rep它记录的是一个实体的面、边、顶点以及拓扑关系而不是一堆三角形网格。要让生成结果能被工程师正常编辑、修改、装配最好的方式不是让算法“猜”一个形状而是让算法“写”一套建模过程。2.2 为什么“程序化生成”最适合工程场景我在测试多个方案后最推荐关注的是“代码生成再执行”这条路径也就是让语言模型直接生成 CadQuery、OpenSCAD 这类程序化建模脚本。CadQuery 本身就是一种“用代码描述建模过程”的 Python 库它把拉伸、旋转、布尔运算、倒角这些操作封装成方法执行脚本后能输出 STEP 文件。这个方案的核心优势在于可编辑性。脚本里的每个数字都是一个参数比如“length 100”“hole_diameter 8”你想改尺寸直接改参数重新执行就行完全不需要重新输入一遍自然语言。这正好契合工程设计的迭代逻辑设计师很少一次建模到位通常要反复调尺寸、改结构参数化脚本天然支持这种工作方式。另外一个隐藏优势是可靠性。语言模型直接生成网格时经常会出现面片相交、翻转法线、非流形边这些问题但在代码生成这条路径里建模操作是全确定的拉伸就是拉伸布尔运算就是布尔运算只要脚本逻辑正确几何一定正确。哪怕生成的脚本有语法错误也只是报错不会产出一个“看起来对但实际没法用的坏模型”。2.3 几何表示与文件格式的底层逻辑很多人会忽略一个关键问题生成的结果应该用什么格式输出。这里我展开讲讲。CAD 软件内部使用的 B-rep 和 3D 打印常用的网格格式之间存在本质差异。B-rep 记录的是一个精确的数学曲面边界比如一个圆柱面它记录的是轴线方向、半径和高度而不是成千上万个三角形。网格格式则用离散三角形近似逼近曲面精度取决于细分密度。text-to-cad 工具如果输出 STEP 文件意味着生成结果的底层是精确几何可以被工程软件直接识别、装配、做干涉检查。如果只输出 STL 或 OBJ 网格文件虽然能 3D 打印但进入机械设计流程时几乎没法用工程师还得重新建模。这个差异直接决定了工具是“玩具”还是“生产力工具”。我判断一个 text-to-cad 方案值不值得用的第一标准就三条能不能输出标准STEP格式生成的模型有没有参数化特征树改一个尺寸需要重新生成还是直接改参数。三条全过的才值得纳入工作流。3. 实操过程跑通一个完整的text-to-cad工作流3.1 环境和工具选型我目前跑得比较顺的的组合是本地部署的 CadQuery 环境 一个经过微调的大语言模型 API FreeCAD 作为查看和后期编辑工具。这套组合的安装配置过程不复杂明确分工CadQuery 负责把脚本转换成三维实体。它是整个链路里最关键的执行器相当于一个“从代码到几何”的编译器。语言模型负责理解自然语言并生成 CadQuery 代码。我试过通用大模型直接调用也试过专用模型后者在生成 CadQuery 代码时的准确率明显更高主要因为训练数据里包含了大量建模示例。FreeCAD 负责查看模型并进行手动修改。它的Python控制台可以直接调用 CadQuery 生成的 STEP 文件也可以作为最终交付前的人工检查环节。这套工具链的好处是完全开源不需要额外购买商业软件许可。如果你在公司环境里使用也建议优先确认 CadQuery 和 FreeCAD 的商业授权情况避免法律风险。3.2 提示词写作方法把“需求”翻译成“约束”text-to-cad 的提示词和写 ChatGPT 的提示词完全是两码事。日常对话你可以写“帮我设计个好看的支架”但文本生成CAD你必须把约束说清楚。我总结了一套“五要素描述法”在实际测试中效果非常稳定形状类型你描述的是板类、轴类、壳体、箱体还是法兰类零件。这决定建模的基本思路。例如“一个矩形安装底板”。关键尺寸尽量给出具体的数值和单位比如“长100毫米宽60毫米厚5毫米”。单位要写清楚我遇到过一次默认单位不一致导致模型缩放了25.4倍的惨痛经历后面细说。特征操作明确哪些地方需要开孔、倒角、切除或阵列比如“四角倒R10圆角”“中心开一个直径8毫米的通孔”。装配关系如果这个零件要和其他零件配合描述配合面、螺纹规格、定位方式。比如“四个安装孔中心距分别为80毫米和40毫米孔径6.5毫米用于M6螺栓穿过”。制造约束说清楚后续加工方式。3D打印的件和CNC加工的件在壁厚、圆角、拔模角上的要求完全不同。举一个具体的示例提示词“生成一个矩形安装底板长度100毫米宽度60毫米厚度5毫米。四角倒圆角圆角半径10毫米。底板中心有一个直径8毫米的通孔。四角附近各有一个直径6.5毫米的安装通孔孔心距边缘10毫米。材质为铝合金用于3D打印原型。输出格式为STEP文件。”这个提示词里包含了建模所需的90%以上信息语言模型生成脚本时几乎不需要“自由发挥”出错的概率自然大幅降低。如果只说“生成一个底板”模型就只能猜尺寸、猜孔位、猜圆角生成结果必然需要大量返工。3.3 生成、检查与迭代的完整流程实际执行时我建议按以下流程操作每一步都不要跳过先在 CadQuery 环境里搭建好基础代码框架定义好单位我的实践是用毫米然后让语言模型根据提示词生成建模脚本。生成后不要立刻执行先人工快速核对脚本里的关键参数有没有明显的数字错误、单位错误、逻辑颠倒。确认没问题后执行脚本CadQuery 会输出 STEP 文件。接着用 FreeCAD 打开第一件事不是看外观而是检查模型树里有没有出现“实体”节点。如果只出现了“形状”或者“网格”说明模型不是合法实体得打回去重新生成。这个检查非常重要很多生成脚本执行后模型看起来是“显示”出来了但实际上是个空壳或者无法编辑的复合体。如果模型正常再做三件事测量关键尺寸是否和设计值一致检查特征数量是否齐全比如该有四个安装孔就绝对不能少一个检查可编辑性尝试修改一个参数重新生成看模型能否正确更新。尺寸一致性检查我强烈建议用脚本去对比不要肉眼估。CadQuery 提供了shape.val().length、shape.faces()这类接口可以直接用代码验证关键尺寸。我在实际中就遇到过模型渲染得挺好看但长宽和设计要求的差了0.5毫米的情况这种误差在概念阶段无所谓但在需要配合的场合就致命了。4. 常见问题与排查我在实际使用中踩过的坑4.1 几何精度与单位问题最坑的一点就是单位。我的第一个测试任务是做一个直径50毫米的圆盘生成结果在 FreeCAD 里打开测出来却是50英寸。后来排查发现底层建模内核默认单位是英寸但语言模型生成的代码里没有显式声明单位CadQuery 按默认单位执行尺寸直接放大25.4倍。从那以后我在所有生成脚本开头都会强制加一行import cadquery as cq; cq.Workplane(XY)并显式声明使用毫米单位同时在提示词里再强调一遍“所有尺寸单位为毫米”。另一个精度问题是圆整误差。语言模型生成的代码里有时会写diameter 7.999而不是8这种误差在单个特征上不明显但如果这个尺寸参与装配配合就可能出现公差冲突。排查方法很简单用代码检查所有关键尺寸变量确保没有出现奇怪的“非整数”数值。4.2 拓扑正确性问题所谓拓扑错误指的是模型的点、线、面之间的连接关系不对。典型症状包括模型看起来是实心的但导出 STL 切片时出现破洞模型能显示但布尔运算时报错“无法计算”装配时两个面明明贴合但干涉检查却报异常。这类问题大多是脚本里的布尔运算顺序导致的。比如你先建了一个底板又建了一个圆柱凸台最后想把两者合并成一个实体如果合并操作里用了union而不是newZ这些 CadQuery 特有的语义或者两个实体的面恰好共面内核就可能产生退化面。排查时我会把布尔运算的分步结果分别输出逐个检查每个实体的边长和面数定位到具体是哪一步融合出了问题。再补充一个技巧如果生成的模型拓扑总出错尝试调整特征操作顺序。比如先做倒角再做孔或者先合并再做切除不同顺序对结果影响很大。我测试下来CadQuery 里“先生成主轮廓再叠加所有特征最后合并”这个顺序的容错率最高。4.3 生成结果不可编辑的困境这类问题最让人头痛模型的形状完全正确但在 CAD 软件里打开后发现它是一整个“钉子户”形状块没有特征树没法改任何一个参数。凡是遇到这种情况基本都是因为生成路径走的是“直接转网格再转回实体”的链路而不是“脚本流程化建模”。我判断能不能编辑有一个土办法在 FreeCAD 里点击模型如果左侧模型树显示的是多个步骤比如“拉伸”“打孔”“倒角”说明是可编辑的如果只显示一个孤零零的“Shape”节点那就基本废了。真正可用的 text-to-cad 工具输出结果必然是一棵特征树。如果你遇到不可编辑的结果别试图修复它直接改提示词重新生成效率反而更高。4.4 文本描述与模型理解偏差语言模型理解自然语言时经常会忽略一些工程师认为“理所当然”的隐含约束。比如你说“安装孔”工程师会默认孔是通孔、是圆柱形、轴线垂直于安装面但模型可能生成一个盲孔或者孔轴歪了。所以提示词里凡是涉及孔、槽、凸台这类特征都建议明确加上“通孔”“圆柱形”“垂直于表面”“完全贯穿”这类限定词不要怕啰嗦。我测试时验证过同一个零件描述补充完这些限定词后一次通过率从不到50%提升到了80%以上。所以提示词不是越短越好而是该有的限定必须有。5. 使用场景与工具盘点哪些领域能先吃到红利5.1 最值得优先尝试的五个场景机械设计领域标准件、常用件的快速生成是最直接的应用。法兰盘、轴承座、支架、安装板、防护罩这类结构规则、参数明确的零件几乎就是为 text-to-cad 量身定做的。我实测下来这类零件用文本生成要比从零建模快3到5倍。3D打印领域创客做外壳、夹具、传感器支架时用 text-to-cad 生成初稿再修整能省掉大量“从草图开始”的时间。这里的优势是3D打印对壁厚的宽容度高即使生成的模型有一些小瑕疵切片软件也能处理。非标自动化领域项目前期做方案概念设计时需要快速验证结构可行性如果每个零件都建模时间成本太高。用文本生成快速搭一个粗略装配体用来评审布局和干涉情况效率和精度都足够用。消费品设计领域比如手机壳、音箱外壳、灯具底座这类产品外形相对规则text-to-cad 可以快速探索多种形态变体然后导入工业设计软件细化。它最大的价值在于批量生成变体而不是单个精修。教学培训领域机构教学生理解“参数化建模”思维时可以用 text-to-cad 让学生直接观察不同参数对模型的影响对建立“参数驱动设计”的概念非常直观比手把手教拉伸和切除更快。5.2 当前值得关注的开源项目与商业产品工具层面我关注到已经有开源社区在尝试把大语言模型和 CadQuery 或类似库集成做成了“文本输入-脚本输出”的 Web 界面这类项目的思路很清晰直接把生成代码暴露给用户看透明度高。商业方面已有公司发布过面向工程师的文本建模工具提供基于浏览器的界面和标准格式导出。选择时我建议重点考察三点是否支持 STEP 输出是否支持参数化编辑是否开放脚本查看和修改。三条都满足的不管开源还是商业都可以深度试用。至于那些只能输出 STL 网格的“三分钟建模神器”我的建议是玩玩可以别放进正式工作流。5.3 这套技术带来的设计流程变革我从最开始的好奇到现在的深度使用最大的感受是整个设计流程的“入口”变了。以前一个设计任务从需求到模型中间隔着建模软件的学习成本和操作门槛现在用文本生成需求本身就是起点模型是需求的直接投影。这带来的变化是项目前期可以更快地验证更多结构方案而不是因为建模时间太长而只做一两个方案。另外text-to-cad 让“非设计师”参与设计过程变得容易了。工艺工程师能直接生成自己需要的焊缝定位板装配工程师能快速生成检具模型。这种从“专业分工”到“需求驱动”的转变我觉得才是它最值得期待的地方。6. 写在最后从项目实践中学到的两件事第一次完整跑通 text-to-cad 流程时我只是觉得“挺方便”并没有太当回事。直到后来我把它用在一个真实交付项目里用文本生成了一套12个零件的工装模型才真正意识到这个工具链的价值——那套件从需求到初审模型只花了一下午换传统方式至少两天。但我必须诚实地说它目前还替代不了工程师的最终把关。生成模型在细节上仍然需要大量人工修正尤其在公差标注、表面处理、材料选择这些制造层面的信息上语言模型的理解还非常浅。我个人在实际操作中发现真正好用的工作流是把 text-to-cad 当作“方案加速器”而不是“设计替代品”先用文本快速搭出方案骨架再在 CAD 里细化优化。如果后续能把它和自动化尺寸标注、BOM生成、DFM分析这些下游环节打通那这套流程的效能就不是提升一点半点而是直接改写机械设计的协作模式。未来如果看到更多企业基于这个思路做内部工具我一点都不意外。