1. 从一句话需求到可编辑模型text-to-cad到底在解决什么问题如果你最近刷社交媒体应该见过不少一句话生成3D模型的演示视频输入一个带波浪把手的马克杯几秒钟后屏幕上就转起来一个看起来相当完整的CAD模型。这正是text-to-cad这个方向火起来之后最常见的场景。作为常年泡在CAD软件里的用户我一开始对这种演示是持怀疑态度的——毕竟从参数化建模的角度看看起来对和能真正进入工程流程完全是两码事。但过去几个月我把能试的主流text-to-cad方案都试了一遍包括大家讨论比较多的Zoo原Former2团队、Autodesk的Project Bernini还有几个开源项目。这篇文章就基于这些实测经验聊聊它到底是什么、怎么工作的、目前能做到什么程度以及在工程流程里应该怎么用。1.1 传统建模流程里的语言断层先说一个我一直觉得很反直觉的事实CAD软件发展了几十年但在表达意图这件事上它依然停留在非常原始的阶段。设计师脑子里想的往往是一个完整的意图一个杯身直径40毫米、杯壁厚度2毫米、带把手便于手持的马克杯。但CAD软件并不理解马克杯这个概念它只认识草图、拉伸、旋转、抽壳、扫掠、圆角这些原子操作。要把一句话的意图翻译成几十步操作中间需要大量空间想象和几何分解能力。新手卡在第一步往往是我不知道该用哪个命令老手则卡在改尺寸会连锁崩坏牵一发动全身。这种翻译过程本质上是一个语言断层自然语言描述的是功能、约束、目的而CAD数据结构记录的是点、线、面、特征、参数。过去这个断层只能靠人脑去弥合一个人要经过几百个小时的训练才能把马克杯这个语义概念稳定地翻译成一条可编辑的特征树。而text-to-cad想做的是让机器直接学会这种翻译。理解了这一点你就能明白为什么它更准确的定位是给CAD装上了自然语言接口而不是简单的AI生成3D模型。1.2 生成3D模型和生成CAD模型是两回事很多人容易把text-to-cad和那些AI生图的3D版本混为一谈。生成网格的AI模型比如基于扩散模型的方案输出的是三角形网格或体素适合游戏资产、影视渲染甚至可以直接拿去3D打印。但网格模型在CAD的世界里几乎不可用——你不能在SolidWorks里改一个网格的圆角半径也无法在Fusion 360里给一个网格加厚2毫米。工程师需要的不是一张好看的皮而是一个自带特征历史、参数可以改、拓扑合法、能进下游CAE/仿真流程的实体模型。所以text-to-cad的精确含义应该是输入自然语言描述输出能在传统CAD工具里被打开、继续编辑、且边界表示B-Rep合法的三维实体。输出常见格式是STEP、BREP以及可重放的特征构造脚本。它的核心价值是把人工建模的几十步操作压缩成一句话需求让没有受过专业CAD训练的人也能表达设计意图同时让受过训练的人把时间花在真正的设计决策上而不是机械重复的建模动作上。2. 三条技术路线以及为什么生成网格这条看似聪明的路反而不主流2.1 路线一扩散模型直接生成网格/隐式场提到AI生成三维模型很多人第一时间想到的是Point-E、Shap-E这类基于扩散模型的工作。它们的思路大致是用海量三维数据训练一个扩散模型输入文本编码后模型直接在体素空间、点云空间或隐式场里进行去噪最后通过Marching Cubes之类的算法提取出三角网格。这条路在视觉表现力上确实强复杂曲面、有机形态都能生成生成速度也算快。但它有一个致命问题输出的是离散网格不是CAD的母语。网格转B-Rep在几何处理领域是出了名的老大难问题即便转成功了得到的也是无数个小平面片拼出来的近似曲面完全丢失了原始的设计特征和参数信息。我实测过用这类方案生成一个机械法兰盘视觉上看起来有模有样但导入CAD软件之后既不能改孔径也不能重新定义厚度只能当一个雕塑看。所以现在业内的共识在逐渐形成这条路线更适合做游戏资产、影视道具、快速3D打印原型而不是面向工程设计的text-to-cad。2.2 路线二大模型生成程序化建模脚本第二条路线是目前开源社区热度最高、也最容易自己搭的让大语言模型直接生成程序化建模代码。CadQuery、OpenSCAD、pythonOCC这类库天生就是用代码描述几何一段代码就是一个可复现的建模过程。大模型最擅长的恰恰是生成结构化文本所以你把需求描述给它让它写一段CadQuery脚本然后在本地执行脚本输出STEP文件整个过程非常顺滑。这条路线的优势在于天然可编辑。生成的代码本身就是一种特征历史——想改杯壁厚度改脚本里的wall_thickness参数重新执行一遍就行。而且代码是显式的每一步做了什么、为什么这么做清清楚楚出了问题也容易定位。缺点是模型的代码生成能力有上限面对复杂装配体或者需要精密空间关系的几何比如齿轮啮合它生成的代码经常逻辑上自洽但空间上错误。我刚开始搭这条流水线时生成的零件十个里有六七个需要人工修代码后来通过把任务拆细、逐个特征生成才把成功率拉上来。2.3 路线三原生B-Rep生成与草绘特征推断第三条路线是Zoo和Autodesk这些公司主推的方向直接用神经网络生成原生的边界表示B-Rep数据或者推断出完整的草绘特征序列。Zoo的Text-to-CAD就是在浏览器里运行一个Transformer模型输入文本后直接输出BREP实体用户可以下载STEP文件导入到主流CAD软件。它不生成网格不生成代码输出的是CAD软件能直接识别的曲面与边拓扑结构。Autodesk的Project Bernini也走了类似的路而且更进一步支持文本、图片、点云三种输入方式输出的是原生CAD数据意味着它生成的模型自带约束和特征历史。这类方案理论上最接近设计者的真实需求——拿到的就是一个正经的CAD文件。但它对训练数据的要求极高B-Rep数据不像文本和图像那样容易获取和标准化这也是为什么目前只有少数大厂和初创公司敢碰这条路线。三条路线的对比可以归纳成一张表技术路线数据介质输出格式可编辑性典型工具扩散模型体素/点云/网格STL、OBJ几乎不可编辑Point-E、Shap-ELLM生成脚本程序代码STEP、脚本高参数化修改CadQuery GPT 等原生B-Rep生成几何拓扑数据BREP、STEP中高保留特征Zoo Text-to-CAD、Project Bernini3. 我实测过的text-to-cad工具效果、差异与使用技巧3.1 Zoo Text-to-CAD的实测体验Zoo是目前普通用户最容易接触到的text-to-cad工具打开网页就能用不需要部署环境生成结果可以下载STEP文件。我第一次试用时的输入是一个直径40mm、高60mm的圆柱形杯子杯壁厚度2mm带一个矩形把手。说实话第一次看到生成结果时我有点兴奋——形状是对的圆柱杯身、抽壳效果、把手位置都算合理模型也能顺利导入Fusion 360。但随着测试次数增加问题就暴露出来了。把手的连接处经常出现明显的台阶或者说非光滑过渡杯壁厚度的标注精度也不太稳定有时候明明写了2mm实际量出来是1.8mm或者2.3mm。我总结的规律是提示词必须极度量化不能只写一个杯子。把单位、尺寸、数量、位置都写清楚生成的稳定性会明显提升。比如在距离杯底10mm处生成一个宽度20mm、厚度6mm、高度45mm的矩形把手把手与杯体连接处倒圆角R2mm这种写法明显比带个把手靠谱得多。Zoo目前还有个限制一次生成基本只能处理单个主体如果你想要一个装配体——比如一个带盖子的茶壶——那就很难一次搞定。更实际的做法是先生成壶体再生成盖子最后在自己熟悉的CAD软件里做装配。3.2 Autodesk Project BerniniProject Bernini我一开始以为只是Autodesk的又一个技术演示后来看了它的技术博客和公开演示才意识到分量不轻。这个项目的关键是多模态输入和原生CAD输出。文本、图片、点云都能作为输入这意味着你可以直接丢一张手绘草图进去或者丢一组三维扫描点云进去让它生成一个可编辑的CAD模型。这个方向对制造业的意义非常大。我目前主要关注它在两个场景下的潜力一是逆向建模比如现场扫描了一个损坏的零件点云数据丢进去直接得到参数化模型二是概念设计设计师用草图快速表达想法AI把它转成正式的三维模型。按照官方公开的信息Bernini目前还在实验室阶段没有大规模开放使用我也没有办法做一个系统的对照测试。但从公布的结果看它生成的模型确实保留了一定的特征可编辑性而不仅仅是看起来像。3.3 开源方案与自建流水线如果你想自己搭建一套text-to-cad流水线最现实的路线还是LLM加建模脚本。我目前在自己工作流里用的一套组合是GPT-4系列模型生成CadQuery代码在Docker容器里跑cq-cli自动把脚本转换成STEP文件再用pythonOCC做实体合法性检查。整体流程不算复杂但每一步都有坑。我给一个最小可运行的思路先把需求写清楚发给模型让它生成CadQuery脚本然后在本地执行并输出STEP最后用pythonOCC写几行代码检查这个STEP文件是否是有效实体。检查和验证这步千万别省它是我把生成成功率从三成拉到七成的关键。具体做法我会在第四章详细说。如果你的需求比较固定比如标准零件族、夹具、注释模型这套开源方案完全够用没必要等商业工具的正式版。4. 大量实测后总结的踩坑清单单位、特征数量与拓扑错误4.1 单位与尺寸的反直觉行为我在实测中遇到的第一个诡异问题就是单位。同一个提示词壁厚2mm在不同模型、不同工具下的输出可能是0.002mm也可能是2000mm。后来我想明白了这类模型在数值推理上并不像人一样有毫米的直觉它只是在模仿训练数据里的统计规律。再加上训练数据里公制英制混杂一个词在不同语境下可能对应完全不同的数值量级。解决办法有两个层面。第一在提示词里显式声明单位比如加上All dimensions are in millimeters之类的固定前缀实测确实能减少单位错误。第二在后处理阶段做一个自动缩放兜底读取生成STEP文件的包围盒尺寸和提示词里声明的设计尺寸做对比按比例进行统一缩放。这个逻辑不复杂但非常实用。我用pythonOCC把这一步做成了一个函数每次生成完自动跑一遍基本不用手动干预。4.2 特征数量失控与细节消失另一个高频问题是特征数量失控。我试过输入一个长方体长60mm、宽40mm、高20mm在顶面上开四个直径5mm的通孔结果模型有时候只生成两个孔有时候生成四个孔但位置完全是随机分布的甚至有几次把四个圆孔合并成了一个异形孔。原因是这类模型倾向于输出统计意义上的平均几何而低频的、需要精确计数的细节恰恰是它们最容易丢失的部分。对付这个问题我的经验是把一个完整零件拆成基体加特征两步走。先只生成主体形状确认没问题后再单独生成孔、槽、倒角这些特征最后在CAD软件里合并。另外提示词里的数量词要靠前放把四个直径5mm的通孔放在句首比放在句末的成功率高不少。单就这一个改动把这类特征的生成成功率从不足30%拉到了70%以上。4.3 实体合法性校验给生成结果加一道质检门就算视觉上看起来没问题的模型也不一定能进得了你的CAD软件。我遇到过的典型问题包括非流形边一条边被三个面共享、自相交面、微小碎片面、实体内部有缝隙等。这些问题的共同特点是你在网页预览里根本看不出来只有导入到SolidWorks或者Fusion 360的那一刻才会报错。后来我养成了一个习惯在生成结果进入正式流程之前先跑一个自动校验脚本。核心逻辑是用OpenCASCADE的BRepCheck_Analyzer检查每个Solid是否有效同时检查体积是否大于零、包围盒尺寸是否在合理区间。这一步相当于给text-to-cad加了一道质检门不合格的结果直接扔回去重新生成而不是浪费时间在手工修破面上。下面是这个校验脚本的简化版本我实际用的就是在此基础上加了一些项目特定的判断逻辑。from OCC.Core.BRepCheck import BRepCheck_Analyzer from OCC.Core.BRepBndLib import brepbndlib from OCC.Core.Bnd import Bnd_Box from OCC.Core.STEPControl import STEPControl_Reader reader STEPControl_Reader() reader.ReadFile(generated_part.step) reader.TransferRoots() shape reader.OneShape() # 1. 实体合法性检查 analyzer BRepCheck_Analyzer(shape) print(valid:, analyzer.IsValid()) # 2. 体积检查面积分法 from OCC.Core.GProp import GProp_GProps from OCC.Core.BRepGProp import brepgprop_VolumeProperties props GProp_GProps() brepgprop_VolumeProperties(shape, props) volume props.Mass() print(volume:, volume) # 3. 包围盒检查判断尺寸量级是否合理 bbox Bnd_Box() brepbndlib.Add(shape, bbox) xmin, ymin, zmin, xmax, ymax, zmax bbox.Get() print(bbox:, (xmax - xmin), (ymax - ymin), (zmax - zmin))这套脚本跑一遍只需要几秒钟但省下来的排查时间是以小时计的。5. 从演示级到工程级还差哪几步基础设施5.1 可靠性、置信度与人工审查如果翻看各种演示视频text-to-cad确实让人眼前一亮但工程落地的第一关是可靠性。目前按照我的实测不同工具的端到端成功率大概在15%到50%之间具体取决于几何复杂度和提示词的量化程度。这个数字距离可以放心交给机器自动执行还差得远。所以现阶段我的判断是它适合做辅助思考和初步方案生成不适合做无人值守的自动建模。工程化落地需要的是可重复、可预期。这也意味着任何text-to-cad系统在生产环境里都应该有一个置信度的概念模型输出结果的同时应当给出一个关于自身可靠性的评估信号。比如用后处理脚本自动检查实体有效性、尺寸范围、特征数量是否与提示词一致而不是让用户靠肉眼去判断生成得好不好。我建议团队在接入这类工具时把这个质检门作为强制步骤不合格的结果直接丢弃或标记为低置信度避免污染后续流程。5.2 与现有设计流程衔接的三种务实用法把text-to-cad接到现有流程里我测试下来最顺手的方式有三种。第一种是概念发散阶段拿到一个粗略需求后批量生成多个形态不完全相同的备选方案让设计师从里面挑方向再在传统CAD工具里精修。这种方式对模型的精度要求不高但能很大程度拓展思路。第二种是标准件和参数化族库的生成比如公司经常用到的特定规格的支架、夹具、壳体用text-to-cad生成初始版本再加上参数化约束放进企业标准件库以后直接调用。第三种是逆向建模从手绘草图或者三维扫描数据出发用text-to-cad生成初始实体模型大大缩短从实物到数字模型的路径。至于输出格式我的首选永远是STEP因为它通用性最好几乎任何主流CAD软件都能打开。如果生成工具支持输出特征历史比如Fusion 360的F3D格式或者FeatureScript那更好但目前这类能力还比较稀有。普通场景下STEP加合理命名已经足够香了。5.3 给设计团队的上手路径建议如果你所在团队想认真试一下text-to-cad我的建议是不要一开始就追求复杂零件而是从几何规整、特征明确、数量可控的零件练手。比如带孔的安装板、带凹槽的滑块、简单法兰这类件它们的特征边界清晰一旦出错也容易定位原因。同时团队应该尽早建立提示词模板库把写得好、成功率高的提示词沉淀下来而不是每个人各自摸索。提示词模板和具体CAD文件一样是知识资产。还有一个很容易被忽略的点把生成结果纳入版本管理。text-to-cad的迭代速度快同一个需求今天生成的明天可能就不一样如果不做记录很难追溯问题。我现在的习惯是把提示词、生成日期、模型版本、校验结果一并放到文件描述里出问题的时候可以快速复盘。就我个人的使用体会来说现在的text-to-cad更像是一个经验丰富但脾气很大的实习生——它经常能拿出让人眼前一亮的初稿但也经常在细节上出幺蛾子。你不要指望它独立交付终版图纸但把它放在构思阶段、方案发散阶段、标准件初稿阶段它确实能帮你省下大量的重复劳动。我觉得未来一年这个领域的变化会比过去几年加起来还快值得每个接触CAD的人保持关注。