1. 当"说一句话就能建模"不再只是Demo
最近不少人在群里讨论 text-to-cad 这个方向，热度确实上来了。从最早的文本生成图片，到文本生成视频，现在轮到文本生成CAD模型——你输入"一个带四个安装孔的法兰盘，外径80毫米，内径32毫米，厚度10毫米"，它直接给你输出一个可以编辑、可以导入SolidWorks或Fusion 360的参数化模型。这不是渲染图，不是网格文件，是真正带特征树、带草图的CAD模型。
说实话，我第一次看到这种输出时还是挺震撼的。但接触多了之后也发现，这类工具的"能"和"不能"之间的界限非常鲜明，很多人第一次上手就被"生成结果不可编辑""面数太多""特征树一塌糊涂"这些问题劝退。这篇文章想把我知道的东西一次性说清楚：它怎么工作的、哪些工具值得试、提示词怎么写才能出好结果、导出之后怎么接入现有设计流程，以及在什么场景下真的能帮你省时间而不是浪费时间。
这篇内容适合三类人看：一是日常用CAD但没接触过AI生成模型的工程师，二是做设计自动化、想评估一下能不能把这类工具接进内部流程的开发者，三是纯粹对AI生成3D好奇、想搞清楚它和普通文生3D到底差在哪里的爱好者。不管你是哪一类，读完至少不会踩我踩过的那些坑。
2. 理解text-to-cad的原理和它到底生成的是什么
2.1 它不是在"画"模型，而是在"写代码"
很多人一听到text-to-cad，下意识会把它和之前的AI生成3D模型（比如文本生成Mesh、文本生成NeRF）混为一谈。但这两者的技术路线本质上是完全不同的。前面的那些方案，本质是在做几何生成——让模型去预测三维空间里的点、面、体素，然后再用Marching Cubes之类的算法把预测结果"捞"出来变成三角形网格。这种端到端生成方式的典型特点就是：出图快，看起来像，但是在工程上是不可用的——网格文件没有特征、没有参数、没有历史记录，你没法在它上面打个孔、改个倒角，更别说做装配配合了。
text-to-cad走的是另一条路：它把生成CAD模型的任务，转化成了一个代码生成任务。更准确地说，是"程序化建模代码生成"。
现在主流工具的实现方式，基本都是先用大语言模型理解你输入的文本描述，然后把它翻译成一段调用CAD内核API的代码。这个内核可能是OpenCascade，可能是CadQuery，也可能是某个商业内核的Python绑定。代码里定义了草图、拉伸、布尔运算、倒角、阵列这些特征操作，执行之后才真正"生成"了你看到的那一坨几何体。
打个比方：你以前用CAD是自己在软件里"搬砖砌墙"——画条线、拉个面、挖个洞，一步一步手动操作。text-to-cad则是你告诉 AI "帮我砌一堵两米高的墙，中间留一扇窗户"，AI帮你写了一份详细的施工图纸，然后机器按图纸施工。图纸（代码）是核心资产，墙体（几何体）只是执行结果。
这个思路的聪明之处在于，它绕开了"直接从文本预测三维几何"这个极其困难的问题。因为几何预测本质上是连续空间里的回归问题，小误差会被放大成明显的形变，而且全局一致性和拓扑正确性非常难保证。但代码是一维的离散序列，大语言模型对"文本到代码"这件事已经训练得滚瓜烂熟，把"自然语言到CAD API代码"类比成"自然语言到Python代码"，模型的学习难度就大大降低了。生成的代码只要语法正确、逻辑正确，执行出来的几何体天生就是水密的、拓扑闭合的，而且在很多情况下是参数化的——因为你改代码里的一个数字，模型就变了。
2.2 当前方案的分水岭：生成式大模型与检索式/程序化模板派
理解了"生成代码"这个大方向之后，你会发现市面上的text-to-cad工具其实分两个流派，弄清楚这个对后续选型很重要。
第一类是端到端的生成式大模型。用海量的"文本描述-程序化建模代码"配对数据去训练大模型，输入文本，直接吐代码。这种方案的泛化能力上限高，你告诉它"一个长得像章鱼的支架"，它也能给你编一个接近的答案。但它的输出稳定性是相对不可控的，可能这次生成的模型加料过度，下次又缺了关键特征，你需要反复迭代提示词和重新生成，然后挑一个能用的版本去改。
第二类是程序化模板加约束求解。系统内置了大量参数化模板库，每个模板对应某一类常见机械零件——法兰、轴承座、支架、齿轮、外壳等，模板里的尺寸和特征通过约束求解器去自动匹配你的文本描述。这种方案输出的稳定性非常高，执行速度极快，几乎不会出现"模型奇形怪状"的情况，但它的天花板也很明显：只能生成模板库里有的类别,超出范围就只能报错或者强行套用最接近的模板。
这两种方案在工程实践中的选择逻辑，其实跟你选数据库是选传统关系型还是向量型一样——你要清楚你的核心场景是"高可控的标准化生成"还是"高上限的开放生成"。如果你所在的公司做的是非标自动化设备，经常要快速生成各类标准件变体，那第二类方案可能更适合引入。如果你做的是概念设计、外观探索，需要AI帮你跳脱惯性思维，那第一类方案的开阔度会更适合。
2.3 工具现状一览：从Zoo到CAD-PHI
目前这个方向我实际用过的、也在持续跟进的开源工具主要有这几个：
- Zoo.dev 的 Text-to-CAD：这是个Web端工具，背后用的是他们的推理模型，输出CadQuery代码。目前免费程度比较高，日常用用足够，我也拿它来做一些机械零件的快速建模测试。
- CAD-PHI：把它视为"用视觉-语言模型去理解线稿和草图，再生成CAD参数"的方案吧。它比较适合你有一些参考图形、想让AI帮你补全或参数化的场景，但我个人感觉它目前的生产可用度一般，更适合做研究探索。
- AutoCAD AI：这是Autodesk官方推的，基于他们的ARCADIA模型，主打就是用自然语言在AutoCAD里生成二维CAD草图。如果你想在二维图框、轴测图这些环节提效，可以保持关注。
- CadQuery本身：它不是AI工具，但它是文本生成CAD这个方向的一个关键基础设施。因为很多AI生成的结果，最后都以CadQuery代码的形式给你，你可以在本地自由修改、重新执行，这比给你一个死模型要有价值得多。
顺便提一下，用CadQuery的好处不仅是它可以配合AI，更在于它本身就是一个用纯代码定义CAD模型的库，有完整的特征操作，生成的STEP文件可以直接被主流CAD软件读取。后面我会讲到怎么把这套东西接到你的现有工作流里。
3. 一个完整的text-to-cad实操复盘
3.1 从文字描述到可编辑模型的完整流程拆解
先别管太玄的技术原理，我们从"你想得到一个可用的CAD模型"这个最终目标倒推，梳理一下整个流程要经历哪些环节。我以Zoo.dev的Text-to-CAD为例，因为它是目前上手门槛最低、网上讨论也最多的一个。
第一步，打开网页，在输入框里写清楚你的模型需求。比如："一个用于固定电机的L型安装支架，底板上两个直径6mm的安装孔，孔距40mm，垂直板上开一个直径12mm的轴孔，支架整体厚度5mm。"点击生成，等它运行一会儿（通常十几秒到半分钟左右，取决于模型复杂度），页面会显示生成结果的三维预览。
第二步，检查生成结果是否符合预期。这个步骤很多人会忽略，但恰恰是最关键的。Zoo生成的预览是"可交互的"——你可以旋转、缩放、看各个角度，但它本质上显示的是你生成的代码执行后的结果，不代表你最终拿到的文件一定可编辑。这里我教你看几个关键指标：模型有没有明显的破面、有没有多余的悬空特征、孔的位置和数量对不对、壁厚方向对不对。
第三步，导出文件。这个步骤的选型会直接影响后续使用，建议优先导出STEP格式，因为STEP是几乎所有主流CAD软件都能原生打开的格式，且能保留实体信息。如果你只想要一个能在网页里看的预览，那就导出glTF；如果只是要个占位模型，STL也够用，但STL是网格，不适合继续编辑。
第四步，在本地CAD里打开并处理。这是决定"这个模型是不是真能用"的一步。拿到STEP文件之后，用SolidWorks、Fusion 360、FreeCAD等打开，检查特征树。这一步你会发现，AI生成的STEP在你本地软件里通常不会带有原始特征树——它只是一坨"死"实体，你后续编辑它的方式就只剩下"直接改体"了。
所以，如果你想拿到的模型是可以继续用参数化方式修改的，我强烈建议你在生成后，直接把输出切到"查看CadQuery代码"这一档，把代码复制保存成一个.py文件，后续所有修改都通过改代码来实现。尤其是当你需要重复生成相似零件时，你会发现"手里拿着代码"比"手里拿着一个STEP文件"要灵活得多。
3.2 提示词才是真正的核心技术壁垒
做了几十次生成实验之后，我得出的结论是：text-to-cad的生成质量，50%取决于你提示词的水平，30%取决于模型底座能力，20%取决于运气。而偏偏提示词是所有人都觉得"我会"但实际上一塌糊涂的环节。
先说一个最常见的失误：描述过于笼统。"生成一个齿轮"——这种提示词基本等于没说。AI会给你生成一个"看起来像齿轮的东西"，但它不知道你要的是模数多少的、齿数多少、有没有轴孔、压力角是20度还是14.5度。而实际工程里，"齿轮"的规格参数几十个都不嫌多。
我总结出来的提示词写法是：主体+关键尺寸+位置关系+特殊特征。具体来说，先一句话定性你要什么东西（L型支架、法兰盘、外壳），然后给关键尺寸（外径、内径、厚度、孔距、孔径），再描述特征之间的位置关系（"底板上有四个孔，均匀分布在直径50的圆周上"），最后列出特殊的附加需求（"边缘倒角2mm""底部开一个矩形槽方便走线"）。这里的核心技巧是能用数字就不要用程度副词。不要说"大一点的孔"，要说"孔径8mm"；不要说"间距适中"，要说"孔距40mm"。AI对数字的敏感度远高于对形容词的敏感度——你给的数字越明确，输出的几何体就越接近你的预期。
另外我特别想强调一个容易被忽略的点：单位。大部分text-to-cad工具在你输入提示词的时候，默认你用的是毫米，但它在模型内部做单位换算时可能并不是百分百严格的。我遇到过好几次，我写的是"外径80毫米"，生成出来一看，模型的尺寸直接大了25.4倍——它把我给的80当英寸换了。所以生成之后，第一件事就是量一下模型的关键尺寸对不对，养成这个习惯可以帮你省下大量返工时间。
3.3 让生成结果可用的文件处理与二次调整流程
好不容易生成一个看起来符合预期的模型，接下来是真正体现工程师素养的时候——你怎么处理和二次调整它，决定了它是"一个能看的模型"还是"一个能用的模型"。
如果你选择的是代码路径（强烈推荐），在本地打开CadQuery脚本后你会发现，可调整的空间非常大。CadQuery代码的结构一般是这样：用一个Box或者Workplane来定义基础体，然后用faces工作平面去选择面、用hole打孔、用fillet倒角。这些特征操作几乎是text-to-cad模型最喜欢生成的模式，也意味着你不需要从零学CadQuery，只需要掌握最基础的那几个操作命令，就能对AI生成的代码做修改。
举个例子，AI生成了一块带四个角孔的底板，但你觉得孔距想从50改成60，直接找到代码里的50这个数字，改它，重新运行代码，模型就自动更新了。这比你在SolidWorks里改草图还要快——因为你要改的不是一个参数，可能是一个隐藏的方程式或外部参考关系。而在代码里，所有的关系都是显式写出来的。
如果你选择的是STEP文件路径，那你得接受一个现实：你在本地CAD里能做的只有"直接编辑"模式，特征树是不会有的。这种情况下，我的建议是：把STEP当作用来"看"和"量"的参考，而不是最终的交付物。用它对一下关键尺寸，然后基于它在你的主流CAD软件里重新建模——因为你心里已经有了一个明确的参考物，重新建模的速度会比从零开始快很多。尤其是在生成复杂曲面、流道这类手工建模很费时间的形状时，"AI出形状，人工补特征"这套配合非常高效。
3.4 不同场景下的选型建议与落地案例
我在前面花了不少篇幅讲工具的原理和操作细节，现在回答一个更实际的问题：text-to-cad到底是噱头还是真的能落地？
我的看法是：它适合特定场景下的特定环节，不适合拿来替代你现有人工建模流程。具体来说，它在以下几个场景中的价值是明确的：
- **标准件和常用件的参数化变体，可以快速出初版。**比如"带4个M6安装孔的电机安装板，板厚5mm"，这种零件你本来就要画，AI帮你10秒出一个初版，你只需要检查尺寸、微调细节，就能直接下单加工。这块的效率提升是实打实的。
- **概念设计阶段的快速探索。**你脑子里有一个模糊的形态，用手在纸上画出大致比例，然后用文字把这个形态描述给AI，让它生成几个不同的"解释结果"。这些结果不一定对，但能给你一些"原来还可以这样"的灵感，帮你打破思维惯性。
- **教学场景中的CAD建模概念演示。**对于刚学CAD的学生来说，亲眼看到"一句话+一行代码→一个三维实体"的完整映射过程，比对着一堆菜单找"拉伸"命令要直观得多。它可以帮你理解参数化建模的本质是怎么回事。
但如果你期待的是用一句话生成一套完整的、带公差标注、带表面粗糙度、可以直接发到加工厂的图纸，那现阶段最好把期望放低。因为那些属于"工程语义"层面的信息，在目前的模型和文件格式中都还没有合适的载体——你生成的STEP文件甚至不带单位信息，更不要谈GD&T标注了。
4. 把text-to-cad接入现有设计流程的三种姿势
4.1 作为插件或脚本嵌入你的CAD环境
现在的主流CAD软件，不管是SolidWorks、Fusion 360还是FreeCAD，都支持脚本化和插件扩展。把text-to-cad的工具能力接进来，通常的做法是走"外部生成+本地加载"的路线：你先在text-to-cad工具里生成好代码或STEP文件，再通过API或脚本把文件导入当前CAD会话中。这种方案很轻量、不需要动你的CAD环境，适合个人和小团队。
更重一点的方案是把推理模型放到你本地运行。比如你可以自己在本地部署一个支持代码生成的模型（比如Llama系或Qwen系），然后用CadQuery写一个脚本包装层：把你的文本需求发送给本地模型，拿到生成的CadQuery代码后直接在本地执行，再把结果导入CAD。这样你就得到一个完全自主可控的text-to-cad流程，不依赖外部API，也不受网络环境影响。如果你对延迟、隐私和数据安全有要求，这条路值得投入研究。
4.2 在批量参数化设计流程里当"草图加速器"
我在做非标自动化设备时，经常碰到一种场景：客户给了一张手绘草图，上面标注了几个关键尺寸，要求出一版初步方案。以前我需要对着草图一点点画，现在我会先把关键尺寸提取出来，整理成一段描述性的文字，扔给text-to-cad工具生成对应的模型，再导入CAD微调。典型效率可以提升不少，尤其适合那些结构相对简单但尺寸变来变去的零件，比如安装支架、底座板、防护罩。
在我自己的实践里，这类工具的定位是"从0到70分的草图加速器"。70分到100分（处理公差、配合关系、标准件选型）还是得靠人手完成，但能够快速把"一个大致的想法"变成立体的、可测量的实体模型，已经能帮我在前期沟通中省去大量反复确认的时间。
4.3 把生成结果与BOM、加工信息衔接的思路
这里我分享一下我总结的一个过渡性做法：让AI生成模型的同时，强制它附赠一个参数清单。做法是，在你本地封装一个"文本转CAD服务"，输入除了包含模型描述外，还要求给出所有关键参数的list（材料、表面处理、数量等）。这样生成结果出来之后，模型是模型、参数是参数，两边分开走，你既可以用参数去生成BOM，也可以用模型去做设计评审。
这个思路虽然朴实，但在当前这个阶段，它可能是让text-to-cad真正从"玩具"走向"工具"的关键一步：它不改变你的所有现有流程，只把"建模"这个最耗精力但技术含量相对成熟的部分交给AI，剩下的工程判断、信息流转，仍然完全由你来掌控。
5. 常见问题与避坑实录
5.1 生成模型尺寸不对：先在预览里量一遍再导出
尺寸问题是我在实践中遇到频率最高的问题。解决方案的核心就一句话：在导出文件之前，先利用预览窗口的测量工具把关键尺寸量一遍。不用量所有尺寸，量最大外形尺寸和一个孔的尺寸就够了，这两个能对上，其他基本不会有太大偏差。如果量出来不对，优先去检查你是不是用了英寸、是不是描述里少了"毫米"这个单位词、是不是尺寸数值本身写错了。这三个排查点能覆盖绝大多数尺寸异常的情况。
5.2 生成代码报错：学会看报错信息再考虑重写提示词
用代码路径的时候你迟早会遇到CadQuery代码执行报错的情况。最常见的报错是名字错误和几何操作失败。名字错误通常是因为AI生成的代码里用了workplane变量但实际没有定义——这一般是模型输出的小bug，手动修正一下就行。几何操作失败则更麻烦，比如fillet选择了一个不存在的边——这种情况通常意味着生成的代码逻辑有硬伤，我建议不要浪费时间修代码，直接重新生成或者改提示词更高效。一个实用的经验是：一旦代码报错，第一时间考虑重新生成而不是修补，因为你不知道AI在哪个环节产生了幻觉。
5.3 单纯修提示词修不好的问题：跨界使用传统CAD进行修复
有一些问题，是纯粹改提示词解决不了的。比如你生成的外壳内部有干涉结构，或者两个特征之间的布尔运算结果跟你预期的不一样。这种时候，我的建议是：不要执着于纯AI流程——把模型导出STEP，用你熟悉的传统CAD软件里的"直接编辑"功能做修复。比如在FreeCAD里把多余的实体切掉、把干涉的部分移除，修完之后再导出STEP反哺到你的模型库里。AI负责量、你负责质，分工明确，才是高效的配合方式。
如果你还没接触过任何传统CAD软件，那在处理这一步的时候，我建议至少掌握一种支持直接编辑的轻量CAD软件的基本操作。哪怕只是会用"移动面"和"布尔减"这两个命令，也能覆盖text-to-cad绝大多数"AI修不好"的后续调整场景了。
6. 一些个人心得与后续可以探索的方向
用了大半年的text-to-cad，我最核心的感受是：它真正革新的不是"建模速度"，而是"建模入口"本身。以前你打开CAD软件，面对的是一个复杂的、充满功能按钮的工作界面，你的操作路径是非常线性的——画草图、加约束、拉伸、打孔。现在你只需要对着对话框说清楚"我想要什么"，生成结果它就摆在那里了。这个入口的改变带来的效率提升，远不只是省了几分钟操作那么简单，它缩短的是从"想法"到"可视化模型"的距离。
但我也要提醒一句，目前这个方向还远没到"生成即交付"的阶段。如果你是一个还在观望的工程师，我的建议是：现在开始尝试、熟悉提示词写法、积累你自己的常用指令库。因为工具的能力每隔几个月就有一次明显迭代——我用的第一个版本和现在用的版本体验差距巨大。提前积累的经验不会白费，当工具的生成精度上了新台阶之后，你手里的这批"指令规范"和"处理流程"就变成了一种优势。
我接下来打算做的事有三个方向：一是把这个工作流集成到公司内部的设计提审流程中，让前端工程师也能自己生成初步模型做结构验证；二是尝试在CadQuery代码层封装一批我们常用的标准件库，让AI生成的结果优先从标准件库里组合而不是凭空捏造；三是探索一下把生成结果直接转成有限元分析前处理模型的可能性，看看能不能顺手把仿真这块也打通。这几个方向每一个都有不少坑要趟，后面有了阶段性成果我会再来分享。
