1. 从生成式AI到生成式CAD这个赛道凭什么爆火过去两年AI绘画把关键词变成了图片画一只赛博朋克风格的猫已经不算新闻。但当帮我生成一个带法兰安装孔的减速器箱体这句话能直接变成可编辑的STEP文件时事情的质变就发生了。这就是text-to-cad——把自然语言直接转化为CAD模型——正在做的事。我在这个方向断断续续研究了几个月跑了Zadok的Text-to-CAD、Zebrahub的Zebrax也读了Meta和MIT联合发表的Text2CAD论文、CADBench基准数据集的相关资料。说实话第一周我是抱着看热闹的心态第二周开始觉得不对劲第三周已经在认真评估这玩意能不能塞进我现有的设计流程。今天这篇就把我这几个月的实测、拆解和踩坑记录整理出来给同样关注这个方向的设计师、结构工程师和AIGC开发者一个尽量完整的参考。先交代一个基本判断text-to-cad在2024年下半年开始从玩具转向工具2025年会是大量小团队把它接进预研和概念设计流程的一年。但它离万能还差得很远现阶段最靠谱的用法是快速生成概念几何辅助方案对比而不是替代工程师做详细设计。这套思路的底层逻辑其实不复杂既然ChatGPT能理解给我写个排序算法并输出Python代码那为什么不能理解给我生成一个带四孔的安装底板并输出OpenSCAD或CadQuery代码模型的输出从文本变成了程序代码代码经过CAD内核执行就变成了可参数化的三维模型。这个代码即模型的路线是当前text-to-cad实现路径里最主流、也最容易被低估的一种。整篇文章我会先讲原理和框架再做工具实测然后专门花一章讲我在使用中遇到的坑和排查链路最后聊聊这个方向目前的天花板和可能的分叉点。如果你时间不多可以直接跳到第4章的避坑清单那部分是我最想让你带走的内容。2. 自然语言到三维模型的完整链路拆解2.1 为什么选择代码生成而不是直接生成网格在text-to-cad的早期尝试里有很多团队尝试过端到端生成——让模型直接输出三维网格mesh或体素voxel数据。这个思路跟AI绘画完全一致输入文本输出一个representation。但做出来的东西有个致命伤它生成的几何是死的。什么意思AI画画生成的图像本质是像素矩阵你没法单独选中那只猫的耳朵去改大一点。同样端到端生成的网格模型没有特征树、没有参数约束、没有草图与拉伸的层级关系。对一个设计师来说这种模型基本不可用——我拿到一个未缝合的mesh连倒角都做不了更别提放进装配体里配合。所以当前的text-to-cad主流路线全部绕开直接生成几何改为先生成程序再让程序生成几何。这就像不直接给你盖一栋房子而是给你一套设计图和施工规范让你用搭建的方式把房子造出来。房子模型保留了设计图代码的全部信息任何一面墙特征都可以拆了重建。这个选择带来了几个关键优势参数化可编辑生成的是CadQuery或OpenSCAD代码修改一个参数比如板厚整个模型跟着变。格式兼容经由CAD内核导出的STEP/STL文件可以被SolidWorks、Fusion 360、FreeCAD等直接打开。可追溯性每个特征对应一段代码方便检查这个孔到底是不是用户要的那个孔。代价也很明显模型的表达能力完全取决于程序脚本能表达的范围。如果你要生成一个带有复杂曲面A级面的汽车覆盖件让LLM写一段CadQuery代码来构造Class-A曲面它基本做不到。所以现阶段text-to-cad最擅长的是钣金件、支架、壳体、法兰、齿轮这类以拉伸、旋转、阵列、布尔运算为主要特征的机械零件。2.2 大语言模型在这里扮演的角色从文本到约束的执行器很多人把text-to-cad想象成懂CAD的ChatGPT这个比喻大体成立但不够精确。我来拆一下它内部到底发生了什么。当你输入生成一个外径100mm、内径60mm、厚度10mm、带8个M6通孔的法兰盘时模型内部要做的事情分三件第一理解并抽取约束参数。模型需要从自然语言中识别出100mm是外径、60mm是内径、10mm是厚度、8个M6通孔分别是阵列数量、螺纹规格、孔的类型。这一步本质上是信息抽取任务难点在于处理隐含语义比如用户说标准法兰盘模型需要知道标准法兰的螺栓孔分布圆直径、螺栓孔数量是有国标或行业惯例的而不是随便挖八个孔。第二把约束映射为程序结构。这一步是LLM最核心的推理工作决定用什么函数、什么顺序、什么参数来构建模型。生成法兰的过程通常是先拉伸一个圆柱作为主体再打中心孔然后根据螺栓孔分布圆直径和角度阵列生成8个孔最后做布尔减运算。模型需要把人类的设计意图翻译成CAD内核的操作序列顺序一旦错了模型就废了。第三生成可执行代码并提供自校正。好的text-to-cad工具不是输完代码就结束而是要能执行代码发现报错后自动修复。我在实测中见过Zadok的模型自己debug的场景——第一次执行因为某个参数类型不匹配挂了它读错误信息改掉那行代码重新执行成功。这个过程很像程序员修bug只不过它修的是自己刚写的bug。所以说LLM在text-to-cad里承担的不是渲染器而是设计师程序员调试器的三合一角色。这也解释了为什么这个领域的关键壁垒不在模型参数量而在CAD代码作为中间表示的生成质量和纠错能力。2.3 支撑技术CAD内核、程序化建模库与数据基准光有LLM远远不够它写出来的代码得有个编译器去执行这个编译器就是CAD内核。目前text-to-cad产品背后几乎都站着开源或商业化的程序化建模库OpenSCAD最老牌的程序化CAD工具用文本描述几何体缺点是不支持原生B-rep边界表示的布尔运算和倒角复杂模型容易出问题。CadQuery基于Python底层用的是OpenCASCADE内核支持完整的B-rep建模、布尔运算、倒角、圆角是目前text-to-cad工具最爱用的库。build123dCadQuery的进化版语法更接近现代Python建模逻辑更清晰正在被越来越多的新项目采用。OpenCASCADE是整个链条里最不起眼但最关键的一环。它是一款开源几何内核能处理NURBS曲面、布尔运算、拓扑操作几乎所有开源CAD软件和不少商业软件都构建在它之上。CadQuery写出来的代码最终都会交给OpenCASCADE去执行。内核稳不稳直接决定了生成的模型会不会在倒角时崩掉。另外数据基准是这个领域快速迭代的燃料。Meta和MIT在2024年发布的Text2CAD论文配套构建了一个包含约15万对自然语言文本-CAD模型的训练数据集模型从这些数据里学设计意图与建模操作之间的对齐关系。CADBench则是专门用来评估text-to-cad工具质量的基准它包含一组从简单到复杂的CAD建模任务按生成成功率、参数准确率等维度打分。如果你想去评测某个工具的好坏直接看它在CADBench上的表现比看宣传材料靠谱得多。3. 三个主流工具实测提示词、流程与产出对比3.1 工具光谱从训练专用到产品化text-to-cad目前没有一个绝对的老大工具之间的定位差异很大。我花了几周时间把最典型的三个都跑了一遍这里给你一个维度的对比和实测感受。工具底层路径核心优势明显短板适合人群Zadok Text-to-CADLLM生成CadQuery代码 OpenCASCADE执行产品化程度高界面友好支持多轮迭代复杂曲面能力弱依赖提示词准确性设计师、工程师快速出概念模型Zebrahub ZebraxLLM生成OpenSCAD/CadQuery代码科研背景强对参数约束理解准交互体验一般缺少产品级打磨研究者、喜欢折腾的技术型用户Meta Text2CAD论文专用数据集训练的开源模型可本地部署数据可追溯离产品化远需要自己搭工程链路AIGC开发者、学术研究者这个表格是我评审完之后的结论。Zadok和Zebrax我之前都实际跑过Meta的模型由于是论文附带的开源代码也尝试着在本地部署过——部署过程不算难难点在于模型生成质量的稳定性和工程化能力需要自己做不少后处理。选哪个工具本质取决于你的终点是拿一个能看的模型还是拿一条能规模化生成模型的管线。前者选产品化工具后者建议选开源模型自己微调。3.2 实际操作流程从一句话到STEP文件我拿Zadok Text-to-CAD走了一遍完整流程用了一个典型的机械零件需求生成一个带有四个安装孔和中心轴孔的矩形底座尺寸120mm x 80mm x 10mm四角孔距边缘10mm孔径8mm。步骤拆解如下进入工具界面在文本输入框给出需求描述。模型返回第一版CadQuery代码和渲染预览。检查预览发现四角孔的位置偏移了——模型把距边缘10mm理解成了坐标系原点偏移我加了一句四个孔相对于底板的角落偏移10mm不是相对于原点。模型重新生成位置正确。导出STEP文件用FreeCAD打开检查确认特征树完整、参数可编辑。在Fusion 360里重新导入配合零件验证尺寸确认与实际需求一致。整个过程从输入到拿到可用的STEP文件大约花了四分钟。这个速度作为概念设计阶段的迭代工具已经完全可用了。比较关键的经验是提示词要尽量结构化并且把坐标系关系说清楚。比如孔的定位是相对于哪个面、哪个点这类信息你不说清楚模型很容易默认从绝对原点开始算。我一开始写提示词太口语化生成的孔位总是不对后来改成精确的描述方式成功率直线上升。如果你想让模型生成完全符合要求的模型我建议提示词按这个模板来零件类型法兰盘/底座/支架/壳体关键尺寸用外径XXmm、内径XXmm、厚度XXmm这种明确表达特征明细孔的规格、位置关系、阵列方式约束关系哪个特征相对哪个面/哪个点定位特殊要求倒角、圆角、公差、是否为通孔3.3 实测不同提示词风格对结果的影响为了验证提示词的影响我做了一组对比实验同一个底座零件用三种不同的提示词风格第一组口语化帮我搞一个板子120长80宽10厚四个角打孔中间再来个孔——结果生成的孔位完全随机四个角孔的位置歪歪扭扭中心孔甚至跑到了板的边缘。模型把中间理解为了板中心的绝对位置但四个角打孔没有明确的偏移值它就自由发挥了。第二组带尺寸但结构松散120x80x10的矩形板四角孔直径8mm中心孔直径15mm——这一版孔的类型对了但四角孔的位置变成了距离边缘5mm和20mm的混合分布模型对四角的语义理解不够精确中心孔偏移到了板的一端。第三组结构化精确描述如上一节所示——这一版完全正确所有特征到位位置关系全部符合要求。这个对比的结论是text-to-cad模型的语义理解能力远没有达到人类设计师的水平。它更像一个很聪明但缺乏常识的实习生你给它的需求越结构化它表现越好你越依赖它自动脑补它越容易在细节上翻车。这跟用Midjourney写提示词的逻辑完全不同——AI绘画需要你提供风格和氛围text-to-cad需要你提供坐标、尺寸和约束。这是很多第一次用的人最容易忽视的心智模型转换。4. 落地中的翻车实录模型能看不能用的问题排查链路4.1 眼见不为实预览渲染和实际导出模型的差异我遇到过最坑的一件事是生成预览看着完全正常导出的STEP文件在FreeCAD里打开却直接崩了——模型没有实体只有一堆悬浮的面。这个问题在text-to-cad工具里出现频率很高本质原因是预览用的渲染器通常是Three.js等WebGL渲染器和CAD内核OpenCASCADE对几何体的处理标准不一样。WebGL渲染的是可视化的三角网格哪怕拓扑关系有瑕疵也能正常显示但OpenCASCADE要求的B-rep模型拓扑关系必须严格闭合任何一个面缺失或翻转整个实体就变成非流形状态。排查这个问题的完整链路如下检查模型生成过程中是否有警告信息。Zadok这类工具会在控制台输出OpenCASCADE内核的执行日志里面如果出现non-manifold或wire not closed之类的关键字基本就是拓扑问题。用FreeCAD或CADQuery打开导出的STEP文件。FreeCAD的Part Check Geometry功能能快速报告模型的流形状态、自相交、无效边等。如果问题出在流形性上优先让模型重新精简特征——把复杂的倒角、圆角去掉再试。布尔运算越多产生非流形几何的概率越高。如果仍然报错试着把提示词改为不生成圆角全部倒角改为锐角然后再在CAD软件里手动补上圆角特征。我自己项目的解决办法是生成后用脚本批量过滤掉非流形模型只保留检查通过的STP进资料库。这么做的代价是能用的比例下降了不少但换来的是——接管的模型不会中途崩掉可靠性比数量重要得多。4.2 局部修改提示词导致全局约束失效第二个高发坑是牵一发动全身。我测试时生成了一个轴承座一开始提示词是底座长100mm板厚10mm中心孔直径40mm带4个安装孔。生成正常我后来想把底座长度改成120mm于是只改了提示词里的100mm为120mm结果重新生成的模型里安装孔的位置和中心孔的直径也全变了。这个现象的根本原因是LLM在修改模型时不是在做局部更新而是从零开始重新创作。你以为是在编辑同一个模型的参数实际上它是在重新写一遍CadQuery代码而它在重写过程中可能会对之前理解正确的其他参数产生新的误解。应对策略有两条每次修改提示词时把所有关键约束都重新写完整不要依赖模型记住上一轮的参数。生成完成后用参数检查脚本逐一核对关键尺寸而不是只看渲染预览。我曾经因为没核对尺寸把一个本该是M8螺纹孔的法兰件直接拿去3D打印结果孔是M6的——模型的螺纹注释在生成的代码里标的是M8但实际构造的孔直径只有6.5mm打印出来的零件压根拧不上螺栓。后来我们的流程里强制加了一道尺寸自动校验工序用代码读取所有孔直径和预期值做对比虽然增加了工作量但避免了更大的浪费。4.3 单位换算与公差标注text-to-cad的隐性陷阱机械设计里单位制和公差是灵魂。但text-to-cad模型对这两个东西的把握极其不稳定。先说单位。模型的训练数据里混合了毫米、英寸、厘米等多种单位体系。你输入1 inch thick它有可能生成25.4mm也可能生成1mm——取决于模型在生成代码时把单位换算逻辑漏掉了。我实测过最离谱的一次提示词明确写了底板尺寸120mm x 80mm生成的模型在CAD里打开却是12cm x 8cm数值一样但单位错了导出到SolidWorks里直接显示成一个小指甲盖大小的零件。再说公差。目前所有主流text-to-cad工具我都还没见过能在模型里正确携带GDT几何尺寸与公差信息的。LLM生成的代码里即使写了公差注释导出的STEP文件也不会包含PMI产品制造信息。这意味着什么生成的模型只能用于概念展示和3D打印原型真正进入CNC加工环节所有公差都必须人工重新标注。这个局限短期内无解因为STEP格式本身虽然支持PMI但大部分CAD内核的导出实现并不完整CadQuery更是完全没做这块。4.4 我的实际规避方案经过这几个月的折腾我自己整理了一套在项目里实际使用的规避方案分享出来供参考第一生成环节分层筛选。模型生成后先做几何合法性检查流形性、尺寸一致性检查关键尺寸与提示词匹配、可编辑性检查特征树完整。三层过完才进资料库。第二所有需要加工生产的零件强制人工复核。text-to-cad目前只配当方案生成器不配当图纸替代品。生成完的模型丢给工程师做一轮完整审查该补的公差补上该调整的结构调整再往下走流程。第三用参数化模板文本填充的思路替代纯自由生成。如果你做的是系列化产品与其让LLM每次都自由发挥不如提前准备好CadQuery模板让LLM只负责把提示词里的参数填进模板。这样既保留了text-to-cad的交互便利又大幅提升了生成结果的确定性。我在支架类零件的测试里把纯自由生成的合格率从六成提升到了九成以上。5. 边界在哪里text-to-cad做不了的事和正在发生的变化5.1 三类任务现阶段碰都不要碰第一类是复杂曲面建模。像汽车覆盖件、消费电子外壳这种以自由曲面为核心的设计任务text-to-cad目前完全做不了。因为CAD程序化建模的本质是用参数化曲线曲面去逼近几何而LLM不擅长美学曲面这种非结构化、难以用参数穷尽的语义。文本无法充分描述一个曲面该有怎样的光影流动代码也无法轻易构造出符合审美要求的连续曲面。第二类是装配体级别的交互设计。如果你需要让这个轴和那个轴承配合保证间隙0.02mm这种涉及多个零件相互约束的任务text-to-cad还做不到。目前的工具都是单零件生成缺少装配上下文的概念模型不知道零件A和零件B之间的配合关系生成出来的东西无法直接组装。第三类是高度依赖工程经验的详细设计。散热计算、强度校核、材料选择、工艺可行性分析——这些知识LLM确实有但它无法在生成模型时自动应用。它会问你要不要加散热筋但不会主动判断这里温度太高必须加散热筋。设计意图中属于经验判断的部分它不参与。5.2 正在发生的三个值得关注的变化第一驱动引擎正在迁移。从CadQuery到build123d的趋势已经很明显后者的API设计更接近现代编程范式更适合LLM生成。我预测未来半年新出的text-to-cad工具大部分会转向build123d。第二多模态输入正在融合。业界已有研究在探索草图文字的混合输入模式——用户手画一个大概轮廓再用文字补充尺寸和特征。这对实际设计场景意義很大因为很多设计需求根本无法用纯文字说清楚尤其是那些大概长这样的形态描述。一旦草图能作为输入通道text-to-cad的可用性会跃升一个台阶。第三从生成模型到生成仿真。CAD生成只是第一步更性感的想象是文字—模型—仿真—优化的闭环你描述设计目标工具生成方案自动跑仿真根据结果调整参数再生成。目前这个链路上离散的环节都有对应的AI工具但还没有人把它们串成完整产品。谁先做到这个闭环谁就是这个赛道的分水岭。6. 写在最后我对text-to-cad的真实态度回头看我这几个月的实践最强烈的体感是这是一个典型的高潜力、低成熟度的方向。它的营销势头很猛但离生产效率工具还有最后一公里。那最后一公里不是模型能力问题而是工程化问题——如何保证生成结果的确定性如何把AI模型和传统CAD流程无缝衔接如何让工程师信任AI生成的几何体。我个人现在的用法是把它当高级草稿生成器。方案评审前用text-to-cad快速生成3-5个备选结构比手画草图直观得多比从零建模快得多。一旦方案定了正式的详细设计还是回CAD软件里做只是参考AI生成模型的拓扑思路。这个搭配目前看是收益和风险最平衡的用法。另外给所有想入坑的读者一个建议用好text-to-cad的关键不是学提示词技巧而是学机械设计常识。这个工具对懂设计的人和不懂设计的人的价值差异是数量级的——懂设计的人知道该让模型生成什么、如何检查模型的正确性、哪里需要人工干预不懂设计的人只会收获一堆空有形状、没有约束的模型。工具替你写代码但不会替你当工程师。后续如果这个方向有新的进展我会再来更新。希望这篇实测记录能帮你少走一些我走过的弯路。