这两年AI生成内容这条路走得飞快文字出图、文字出视频都已经不稀奇了真正让我觉得“有点东西”的是“text-to-cad”这个方向。一句话描述一个零件直接给你生成一个能编辑、能制造、能进装配的三维模型而不是一张看着像那么回事的渲染图。这玩意儿解决的不是“画个好看的图给人看”而是“把想法变成能用的模型给机器做”后者才是制造业里真正值钱的部分。我最初接触这个方向是因为一个机械设计的活儿客户口头提了一个支架需求说要“一个L型底座带四个安装孔侧面加一条加强筋”我需要在半小时内给出一个初版模型供评估。传统流程得开建模软件拉草图、定约束、拉伸、打孔一套下来怎么也要十几分钟。而用text-to-cad的思路我把这句话原封不动丢给模型十几秒后拿到一个参数化脚本再在本地CAD环境里跑一下模型就出来了。虽然尺寸需要微调但整体结构一点没跑偏。从那之后我就一直在折腾这个方向这篇文章把我这段时间的实践心得完整梳理一遍既有思路也有代码还有一堆踩过的坑。1. 内容整体设计与思路拆解1.1 为什么text-to-cad可行关键是要想清楚“CAD要的是什么”先聊一个很多人没想明白的问题为什么text-to-cad能成立文本转语音、文本转图片都好理解但CAD模型是精确的几何实体一个倒角半径写错整个零件就可能装不上。这看起来是个不可能完成的任务但实际做下来发现它成立的根基在于CAD模型本质上可以用“程序化建模脚本”来表达。什么意思你在建模软件里手动操作的那些步骤——画草图、加约束、拉伸、切除、打孔、倒角——每一样几乎都能对应到脚本代码里的一行或一个函数调用。比如画一个长方体代码就是给定长宽高和原点坐标打一个孔代码就是指定圆心位置、半径和深度。所以text-to-cad真正要做的不是让语言模型直接“变出”一个几何体而是让语言模型理解自然语言描述然后输出一段能生成这个几何体的脚本。这个思路跟让AI直接输出网格文件有本质区别。直接生成网格比如一堆三角面片看起来是三维模型但没法编辑没法改参数没法用于后续的CAM加工说白了就是个好看的摆设。而输出脚本得到的是一个参数化模型你说“孔距改成60毫米”改一下代码里的变量重新生成就行这才符合工程实践的真实需求。所以我一直坚持一个观点——text-to-cad的终点不是“生成几何”而是“生成可参数化编辑的几何生成逻辑”。1.2 核心链路拆解一段自然语言如何变成可制造模型整个text-to-cad的链路我通常拆成四段意图解析、建模方案规划、参数化脚本生成、本地渲染验证。这四个环节缺一不可每个环节都有它自己的难点。第一段是意图解析。语言模型需要从自然语言里抽出几何要素什么形状、放在哪里、尺寸多大、有哪些特征。这句话说得越口语化提取难度越大。比如“一个圆角的盒子上面开个方孔”这里“圆角”“盒子”“方孔”都是关键信息但“上面”是哪个面是顶面还是侧面这类歧义是第一个要解决的。第二段是建模方案规划。模型要想清楚用哪些基础特征来组合。比如L型支架可以拆成两个长方体的并集也可以用一个拉伸体加一次切除不同方案生成的代码差异很大。模型得在“最简步骤”和“几何正确”之间做权衡这一步直接决定脚本的质量。第三段是参数化脚本生成。这一步是把规划好的方案落地成具体代码需要生成一系列建模函数的调用。这里最容易出的问题不是代码格式而是数值坍缩比如该给3毫米的倒角给了0.3该在X轴偏移的跑到Y轴。这也是为什么提示词工程在text-to-cad里极其重要后面实操部分我会详细讲。第四段是本地渲染验证。脚本生成后必须在本地CAD环境里跑一遍得到实际几何体。这一步不是可选项而是必需品。因为语言模型生成的代码从语法上可能完全正确但几何上可能是非法的比如某个切除操作把整个实体切空了或者两个面之间出现了零厚度的接触。不实际渲染验证你根本不知道模型长什么样。1.3 为什么选择“脚本化建模”这条路在折腾text-to-cad的过程中我也试过其他路线。比如直接让模型输出STEP文件也就是通用CAD交换格式训练数据难搞生成质量也差。再比如让模型直接写网格顶点坐标效果更惨生成出来的东西根本没眼看。最后我确定走脚本化建模这条路线原因有三个。一是可解释性。脚本是人能读懂的中间哪一步出了问题打开代码一眼就能定位而不是面对一团黑盒网格不知道从哪里下手。二是可编辑性。生成的是参数化模型客户说“再加厚一点”改厚度变量重新生成而不是重新生成一个全新的随机模型。这个在真实施工和制造场景里是刚需。三是可验证性。脚本可以通过本地CAD内核渲染成实际几何体能测量、能检查壁厚、能验证布尔运算结果。这意味着我可以写一套自动校验逻辑比如“生成后体积必须大于某阈值”“不能有零厚度面”把模型错误挡在上游。2. 核心细节解析与实操要点2.1 提示词设计决定text-to-cad成败的第一道关口很多人以为text-to-cad就是把需求往对话框里一丢就完事真正自己动手做完一轮才发现提示词怎么写直接决定脚本能不能用。我踩过最大的坑就是把需求说太笼统比如“给我一个支架”。这个描述给到语言模型它只能猜。猜出来的结果就是模型看起来还行但尺寸完全随机孔径乱给位置靠感觉。后来我把提示词工程总结成一套固定套路效果稳定提升。第一步先给结构约束明确告诉模型这个零件由哪些特征组成以及特征之间的空间关系。比如“底板加四个凸台凸台分布在底板四角”这种描述比“带凸台的板”要强一个数量级因为它把空间拓扑关系说清楚了。第二步再给尺寸约束能写死就写死。长度、宽度、高度、孔距、孔径全部量化。“建议”这个词都不要用。模型天生擅长从文本里找规律你给了具体数字它就会照着数字走你给“适中”“稍微”这种模糊词它就会放飞自我。第三步最后给约束说明明确告诉模型哪些参数必须保持不变哪些可以自行推断。比如“孔间距为60毫米不可变孔数为4”这样生成出来的脚本孔距永远是60而孔的具体排布方式可以由模型决定。我自己常用的一个提示词模板大概是这样的请根据以下需求生成三维CAD模型的建模脚本输出格式为[目标脚本语言]。要求如下 - 几何类型钣金支架 - 主体尺寸长200mm宽80mm厚10mm - 特征四个安装孔孔径8mm孔间距60mm孔中心距边缘20mm - 加强筋位于长边外侧厚度5mm高度25mm - 必须保持孔间距60mm、主体尺寸200x80x10mm对比一下就能看出差别笼统描述跟结构化描述模型输出质量完全不在一个档次。这不是什么玄学是因为语言模型在长文本里对“精确数值”的记忆保持能力远好于对“模糊意图”的推断能力你给它精确的它还你精确的。2.2 建模内核选型脚本语言怎么选text-to-cad的文本理解部分可以靠语言模型但脚本要在本地跑起来就得选一个建模内核。我先后试过三个方案各有各的脾气。最省事的是基于CSG构造实体几何的脚本化建模工具。这类工具的特点是语法简单所有操作都是创建体、并集、差集、交集几分钟就能上手。给初级用户看很友好模型输出成功率也高因为语法结构足够规整语言模型容易学。缺点是遇到复杂曲面基本没辙圆角过度、可变截面扫描这类高端操作做不到。第二类是基于边界表示的参数化建模工具功能更接近工业级软件能做草图和约束生成的结果也更“工程化”。但API复杂语言模型学起来困难经常生成长长的代码然后报错debug成本高。第三类是直接用某开源内核做二次开发。灵活度和上限最高但开发成本也最高适合搞研究不适合快速出活。我的建议是如果你刚开始玩text-to-cad先选第一类也就是基础CSG工具的脚本语法。它能覆盖百分之七八十的简单零件场景而且因为语法足够规整语言模型生成的成功率肉眼可见地高。等你把整个链路跑通了再考虑往更复杂的建模内核迁移。2.3 维度与单位最容易翻车的地方text-to-cad生成模型翻车十个里面有八个跟尺寸单位有关。语言模型从文本里抽出来的数值默认是直接用的但问题在于用户描述里的单位可能跟建模脚本的默认单位不一致。举例来说用户说“一个直径5厘米的圆盘”建模内核默认单位是毫米那么这个5就得换算成50。如果脚本里直接写5生成出来的模型就是直径5毫米缩水到十分之一放到真实场景里一看就知道不对劲。我现在的做法是在提示词里强制指定单位并在脚本生成后加一个尺寸校验环节。提示词里固定写明“所有输入尺寸已换算为毫米请直接使用数值生成代码”把单位歧义在输入源头干掉。然后在校验环节我会对生成结果跑一次自动测量把主要特征尺寸打印出来跟预期值对比误差超过某个阈值就标记异常。单位问题看似不起眼但在text-to-cad里它属于“高频且致命”的错误因为尺寸错了一个数量级的模型在工程上是完全不可用的哪怕它看起来形状一模一样。这一点后面我在常见问题章节还会再展开。3. 实操过程从一句话到可编辑模型3.1 环境准备与工具链搭建先说环境。我的实操链路完全跑在本地不依赖云端API因为工程数据往往是敏感的不适合往外传。整套工具链由三个部分组成一个支持调用语言模型的推理环境、一个脚本化建模内核、以及一个用于查看模型的图形界面。语言模型这块我推荐用本地部署的开源模型。原因有两个一是提示词可以随便调反复试错不花钱二是数据不出内网合规压力小。模型参数量根据自己机器来能跑起来就行代码生成任务对模型的要求没有想象中高中等规模的模型就能胜任关键是提示词要写好。建模内核用开源的脚本化CSG工具这类工具能接受文本格式的脚本渲染后输出三维模型文件。图形界面我个人习惯配合一个通用的三维查看器来预览STEP或STL文件也可以直接在工具的预览窗口里看。我实际项目的目录结构大概是这样的text-to-cad-demo/ ├── prompts/ # 提示词模板 │ └── bracket.txt ├── scripts/ # 模型生成的脚本 │ └── bracket_001.py ├── models/ # 渲染输出的三维模型 │ └── bracket_001.step ├── check/ # 自动校验脚本 │ └── validate.py └── logs/ # 运行日志整个工具链用Python脚本串起来从调语言模型接口到执行建模内核再到输出模型文件一条命令跑完。3.2 实操案例一句话生成L型支架我用一个最典型的案例来演示整套流程生成一个L型安装支架。这是机械设计里最常见的零件之一特征简单但有代表性。假设用户的原始描述是这句“我要一个L型支架底边两个孔侧边两个孔底边那个面上有一条加强筋。”这句话信息量够但不够精确。我把这句话整理成结构化提示词后输入给语言模型让它生成建模脚本请生成L型支架的建模脚本尺寸如下 - 底板长120mm宽80mm厚10mm - 立板高100mm宽80mm厚10mm与底板长边垂直连接 - 底板安装孔2个孔径8mm孔距60mm位于底板短边中心线上 - 立板安装孔2个孔径8mm孔距60mm位于立板顶边中心线上 - 加强筋三角形位于底板底面与立板背面之间的转角处厚度8mm 输出为完整、可运行的建模脚本。模型输出的脚本经过我简化后核心逻辑长这样import cadquery as cq # L型支架主体底板 立板 base cq.Workplane(XY).box(120, 80, 10) vert cq.Workplane(YZ).box(10, 100, 80) bracket base.union(vert) # 底板打两个孔 bracket bracket.faces(Z).workplane() \ .center(-30, 0).hole(8) \ .center(60, 0).hole(8) # 立板打两个孔 bracket bracket.faces(X).workplane() \ .center(0, 40).hole(8) \ .center(0, -40).hole(8) # 加强筋三角棱柱 rib cq.Workplane(XY).moveTo(-40, 0) \ .lineTo(40, 0).lineTo(0, 30).close() \ .extrude(8) bracket bracket.union(rib) cq.exporters.export(bracket, bracket.step)这里用到了第四类建模内核的Python接口也就是工业级参数化建模库。可以看到代码逻辑不复杂用三个基本操作搭出主体然后逐个添加特征。关键点是坐标原点的设定和面的选择比如“Z”表示顶部面“X”表示右侧面这些面选择逻辑决定了孔打在哪个面上。跑完这段脚本后输出STEP文件然后在图形界面里打开检查形状是否符合预期。这就是我第一次实测跑出来的效果整体形状没有跑偏孔位尺寸完全匹配唯一需要调整的是加强筋的位置我第一次生成时把它放到了内角实际应该在外侧转角附近简单改一下坐标就解决了。3.3 校验与自动化不能只靠“肉眼看着像”模型生成完看一眼说“像”这不叫完成。在工程流程里你必须用可量化的指标来验证模型是否合格。我自己写了一个校验脚本做几件机械设计里最基础的事。先做体积与物理可行性检查。读取生成的STEP文件计算实体的总体积。比如L型支架按上面尺寸算下来理论体积大约是长120乘宽80乘厚10加立板100乘80乘10再减去孔的体积加加强筋体积应该在一个合理的数值范围内。如果脚本生成的模型体积是负数或者零说明布尔运算出了问题模型是空的直接判定失败。再做特征数量检查。用建模库的内置工具去数模型里面的孔、面、边数量。一个L型支架应该有4个圆柱孔每个孔贡献一个圆柱面。如果数出来只有2个孔说明脚本里某些步骤被模型省略了需要重新生成。最后做尺寸抽查。把关键尺寸列出来比如底板长宽高、立板高宽、孔径、孔距跟预期值比较。误差在1毫米以内的算通过超过5毫米的必须返工。整套流程脚本化之后我只需要跑一条命令所有检查自动完成报告直接输出到终端。python validate.py --model bracket.step --spec spec.json输出大概是[OK] 实体体积 147rb cm3符合预期范围 [OK] 孔数量 4全部检测到 [OK] 底板尺寸 120.000 x 80.000 x 10.000 mm [OK] 孔径 8.000 mm [OK] 孔距 60.000 mm这一步看似简单却是把text-to-cad从“玩具”推向“工具”的关键。没有自动校验你每一次生成都要靠肉眼去检查效率上不去不说还容易漏看细微但致命的错误比如某个圆柱与实体完全没有相交看起来像打了孔实际是个悬浮的柱体。4. 常见问题与排查技巧实录4.1 尺寸漂移模型看起来对但量起来不对这是我在text-to-cad实测中遇到频率最高的问题。语言模型生成的脚本语法完全正确实体渲染也正常就是一测量发现尺寸跟预期差了十万八千里。最典型的一个案例是我让模型生成一个直径40毫米的圆柱法兰结果出来的模型直径量出来只有4毫米。排查后发现原因在于语言模型内部的数值推理精度不够稳定。它在文本里看到“直径40mm”理解上是对的但在生成脚本时可能受到了其他干扰比如上下文里某个尺寸最终数值多位错位。这类问题靠肉眼检查根本发现不了所以必须依赖测量校验脚本。我的处理办法有两个。一是强制在提示词里加入“不要修改任何给定尺寸”的硬性指令从源头约束模型的数值行为。二是在校验环节把关键尺寸全部写进一个JSON规格文件自动检查生成结果的测量值与规格值的偏差偏差超过阈值直接重新生成。这两个办法组合起来尺寸漂移率大幅下降。4.2 布尔运算失败模型脚本跑通了但实体是空的CSG建模最核心的操作就是布尔运算——并集、差集、交集。text-to-cad生成的脚本最容易出的问题就在这里。举个例子你想在底板上挖一个孔脚本里的逻辑是用一个圆柱去和底板做差集。但如果你把圆柱的位置写错了圆柱没有跟底板实体相交差集操作逻辑上依然可以执行只是结果跟没挖孔一样。更隐蔽的情况是圆柱的一端刚好贴在底板的表面没有穿透。这种情况下差集在某些内核里会失败报错说“对象不重叠”或者在边界处产生退化几何生成一个壁厚为零的实体。这类问题在后续的加工中会导致零件直接穿孔或者强度不足属于模型层面的致命错误。我的排查思路是在自动校验脚本里加了对实体有效性的检查实体必须是流形实体所有边都必须被恰好两个面共享不能有悬边和悬面。如果检测到非流形几何直接判定脚本失败让模型重新生成。这里也体现了我前面说的“必须本地渲染验证”的重要性你不实际跑一遍几何内核光看代码永远发现不了这种问题。4.3 坐标混乱特征位置跑偏特别是旋转体的朝向另一个高频翻车点是特征的空间位置不对。最常见的结果是孔打歪了面、加强筋跑到体外、圆柱体方向翻转。这个问题的根源在于文本描述里的方位词和三维建模坐标系的对应关系是语言模型需要跨过的一道坎。比如用户说“顶面打孔”这个“顶面”在模型创建时取决于工作平面的朝向。底板的顶面是Z轴正方向但立板的顶面可能是Y轴方向模型如果没有正确理解不同面的空间关系就会把孔打到错误的位置上。我现在采用的办法是在提示词里使用坐标化描述多给模型明确的方向词。比如我会明确写“以底面原点为参考底板顶面为Z10平面立板前表面为Y80平面”。这样等于给模型提供了一个坐标系让它生成代码时不用靠“猜”。经实测加上坐标系说明后特征跑偏的概率大幅下降。另外我也会在自动校验里加入“孔的位置是否在目标面上”的检查把位置错误的孔直接拦下来。4.4 常见问题速查表我把实操中遇到的问题和排查方法整理成一个速查表方便后来者直接用问题现象可能原因排查与解决模型整体尺寸比预期小十倍单位未统一毫米与厘米混用提示词里强制指定毫米并跑尺寸自动校验布尔运算报错或实体为空特征未与主体相交、与非流形几何相交检查特征的位置坐标调整相对位置确保完全穿透孔位偏移到错误面方位词与坐标系理解错误提示词中用坐标面描述替代自然语言方位词倒角过大导致实体消失倒角值大于特征尺寸提示词中额外说明“倒角必须小于最小特征尺寸的1/3”模型形状正确但无法导出实体内部存在退化面用实体有效性检测工具检查并修复几何脚本运行超时生成的特征数量过多提示词中要求“使用最少的建模特征组合”这张表不是一次总结出来的是我一次次跑脚本、一次次看模型翻车、一次次排查之后整理出来的。每一行的排查步骤都是我实际验证过的照着做基本能解决绝大多数问题。5. 还能往哪走扩展应用的几个方向5.1 从零件到装配体text-to-cad的下一个台阶目前text-to-cad能稳定生成的基本都是单个零件。但工程实践里几乎没有哪个设备是由单独一个零件构成的。一台简单的小型设备可能涉及十几个零件加上紧固件、定位销、垫片数量很可观。所以我现在特别关注text-to-cad往装配体方向扩展的尝试。这个方向的核心难点在于零件之间的配合关系。不是生成两个零件那么简单得让这两个零件之间的尺寸互相约束。比如轴和孔的配合轴的直径必须等于孔的直径减去一个公差值这个约束关系必须体现在两段脚本里。我把这类约束关系已整理成固定的提示词模板比如“底板孔径为8mm对应的定位销直径为8mm减去0.02mm间隙”模型在生成时会把这种跨零件的数值关联一并处理。实测下来简单的两零件配合是能稳定生成的十几个零件的装配体还需要继续摸索。5.2 从文本到制造直接对接CAM加工text-to-cad如果只停留在“生成能看的三维模型”价值有限。真正的制造业场景里生成模型之后还得考虑怎么加工出来。所以我认为text-to-cad的下一步应该和CAM工具打通实现“自然语言到加工路径”的大闭环。这个链路可以这样理解用户输入“生成一个带四个安装孔的L型支架”然后系统自动生成模型再自动根据模型生成一个简单的数控铣削路径——先铣外形再钻孔最后清根。我见过一些原型项目已经在做这件事目前精度和效率都有瓶颈但方向是完全可行的。对整个制造业来说如果这项技术成熟设计到制造的周期可能会被压缩到分钟级那带来的行业变化会非常大。5.3 个人经验text-to-cad目前更靠谱的落地姿势说了这么多最后说点实在的。以text-to-cad目前的能力水平最靠谱的落地姿势是什么我的判断是它不适合做完全无人干预的自动化工具但非常适合做“设计者的加速器”。具体来说我把这个流程定义为“人类定参数AI出结构”。我告诉模型关键尺寸和特征组合模型生成脚本我再在本地作图界面里微调不合理的部分。整个过程下来比我从零开始建模至少快了三倍而且因为脚本是参数化的后续的迭代改动成本很低。如果你把它当作一个能自动写代码的建模助手而不是一个全自主的AI设计师它的实用性会超出你的预期。根据我个人的实操体会text-to-cad这条路真正难的不是模型本身而是你如何定义提示词、如何设计校验体系、如何把生成结果嵌进现有的工程流程里。这些活儿没有固定的标准答案但每做一步都是在把一个“看起来挺酷的AI玩具”推向“一台能真出活的机器”。后面我还会继续在这个方向上折腾特别是装配体约束和CAM联动那一块如果有新进展我再回来更新。