设计一个带法兰的连接盘以前我至少要打开CAD软件建草图、标约束、拉伸、打孔、倒角熟练的话十分钟生手半小时起步。而现在我只需要在对话框里输入一句“外径50mm的圆盘中心开直径20mm的孔在半径38mm的圆周上均布4个6.5mm通孔厚度8mm”等上十几秒STEP文件和STL文件都能直接拿到手。这条把自然语言变成三维CAD模型的技术路线就是现在机械设计圈和AIGC圈都在聊的text-to-cad。这篇文章不是论文解读也不是工具广告。我花了几周时间把目前主流的text-to-cad路线都实测了一遍包括MIT的开源项目Zack、Text2CAD论文的思路以及自己用CadQuery搭的一套工程化工作流中间踩了不少坑。接下来我把这些经验按原理、工具、搭建、避坑、落地五个方向整理出来想入坑的读者可以对照着少走弯路只关心技术原理的直接看第二部分。1. text-to-cad到底在解决什么问题1.1 传统CAD建模的门槛和重复劳动很多人觉得CAD建模的难点在“软件操作”但真正的门槛其实是两件事一是把脑子里模糊的设计意图翻译成精确的几何约束二是熟练操作特征树、草图、基准面这套抽象概念。一个老师傅画一个零件可能很快但让他把经验复制给新人光是草图约束的逻辑就能讲半天。更何况企业里大量的建模工作并不需要多高的创造性。自动化设备设计里法兰、支座、轴套、安装板这类标准件和非标件占了日常建模相当大的比例。这些零件的共同点是结构明确、参数固定、重复性极高。工程师大部分时间不是在“设计”而是在“把参数敲进软件里”。text-to-cad切入的正是这个痛点把“设计意图”直接翻译成“几何操作序列”跳过CAD软件的操作层。LLM负责理解语言CAD内核负责计算几何这两者结合理论上可以把一个零件的建模时间从十分钟压缩到十几秒。这也是我最初被这个方向吸引的原因——它不是玩具是真的能提高生产力的东西。1.2 三条技术路线快速扫描我实测下来目前text-to-cad的技术路线大致分三类差别非常大。第一条是LLM生成程序化建模脚本。让GPT这类大模型直接输出CadQuery、OpenSCAD或者FreeCAD的Python脚本然后本地执行得到精确的B-Rep实体模型。MIT的Zack就是这条路的代表我自己搭的工作流也走这条路。第二条是专用生成模型。把CAD建模命令序列当成语言建模比如DeepCAD的思路每个模型都是“画一个圆→拉伸→打孔→倒角”这样的命令序列训练一个Transformer来生成。Text2CAD这篇论文则进一步加入了文本条件输入一句话直接输出命令序列。第三条是3D扩散模型和多模态生成比如Meshy、Shap-E这类工具以及Autodesk的Project Bernini研究方向。用户输入文字或图片直接生成网格或者神经隐式场。三条路线的对比我直接列了个表路线代表项目输出类型可编辑性工程精度当前成熟度LLM生成程序化脚本Zack、自建CadQuery参数化B-Rep实体高特征可回放高由CAD内核保证最实用专用生成模型DeepCAD、Text2CAD命令序列转B-Rep中可回放但难微调中尺寸容易偏学术前沿3D扩散/多模态Meshy、Shap-E网格/隐式场低基本不可编辑低仅限可视化适合游戏影视我的结论很直接想落地到机械设计第一条路线是当前唯一靠谱的第三条路线做做概念演示还行但网格模型进不了数控加工和装配仿真流程第二条路线在学术上很有价值工程化还差得远。2. 原理拆解LLM是怎么把一句话变成实体的2.1 程序化建模路线的底层逻辑很多人第一次接触text-to-cad时会有一个误解以为LLM直接输出了一个三维模型文件。实际上完全不是这样LLM输出的是一段代码真正的几何计算由CAD内核来完成。拿CadQuery举例它的底层是OpenCascadeOCCT几何内核CadQuery只是把OCCT复杂的C接口封装成了好用的Python API。开发者在代码里先创建一个二维草图工作平面画圆、画线、画圆弧然后拉伸、旋转、扫描成三维实体最后用布尔运算做打孔、切槽、倒角。整个流程和你在CAD软件里手工建模的步骤几乎一一对应。text-to-cad在这里面扮演的角色是帮你把自然语言“翻译”成这段CadQuery代码。比如“厚度8mm”翻译成.extrude(8)“中心孔直径20mm”翻译成.circle(10).cutBlind(-8)。因为几何计算是OCCT内核做的所以只要代码没有逻辑错误生成出来的尺寸就是精确的不存在“AI画了个大概”的情况。一个最小例子让LLM生成“直径30mm、厚5mm的实心圆柱”import cadquery as cq result ( cq.Workplane(XY) .circle(15) # 半径15mm .extrude(5) # 拉伸5mm )这段代码让LLM来写几乎不会出错。难点在于复杂零件特征一多LLM就容易在特征顺序、参数传递、参考面选择上出问题。这也是为什么后面讲工程化时校验环节极其重要。2.2 生成式模型路线把CAD操作序列当语言DeepCAD和Text2CAD走的是另一条路。它们的核心洞察是CAD建模过程本质上是“一串有序的操作”每个操作有类型、有参数。比如一个简单的零件可能是circle(radius15) - extrude(depth5) - hole(diameter6) - fillet(radius1)。既然操作序列本质上是一维的、有顺序的、有依赖关系的那就可以把它当成语言来处理。DeepCAD的做法是从Fusion 360 Gallery这类大型CAD数据库里抽取几百万个真实零件的建模历史把每个操作命令和参数离散成token训练一个Transformer解码器。生成时模型直接输出一串token再经过一个解释器还原成B-Rep模型。Text2CAD2024年发表于AAAI的工作在这个基础上加入了文本条件。它的思路是两阶段先用模型从自然语言提取出二维草图参数再用类似Sketch2CAD的方式把草图转成完整的CAD特征序列。实际效果是输入“一个带四个安装孔的方形底板”模型会生成对应的草图轮廓再生成拉伸和打孔命令。这条路线的优点是不依赖第三方LLM API模型小、推理快缺点是训练数据需求极大而且对精确尺寸的把握不强。我看了论文附带的示例输出生成“直径50mm”的零件实际结果经常差出1到2毫米。这个误差在机械设计里是不可接受的。2.3 为什么参数化约束是成败的分水岭判断一个text-to-cad工具能不能用于工程最重要的标准不是“生成得像不像”而是能不能参数化修改。扩散模型生成的网格模型生成完就固定了想改一个孔的直径只能重画。而参数化B-Rep模型不同它的尺寸都是变量特征树完整保留后续想改外径、改孔距、改厚度在代码里改一个数字整个模型自动更新。这正是工程师的工作习惯。所以你会发现目前所有想往工程落地的text-to-cad方案都在往“参数化、特征历史可回放”这个方向收敛。LLM生成CadQuery脚本之所以最有前途恰恰是因为CadQuery本身就是参数化建模工具。文本里的“直径50mm”被LLM提取为变量生成的是参数化脚本而不是死模型。这个认知决定了我后面的所有技术选型不追求好看的多边形网格只追求可编辑、可验证、可制造的B-Rep实体。3. 我把主流工具都实测了一遍效果差多少3.1 MIT的Zack开箱即用的LLM加CadQueryZack是MIT那边开源的一个项目思路很直接用GPT-4生成CadQuery代码再在网页上渲染出三维预览。用户在文本框里输入“I want a hollow cylinder with thickness 2mm”回车几秒钟后就能看到模型。我实测下来Zack对简单几何的处理确实不错。法兰盘、带孔圆柱、简单的支座生成结果都很标准。但一旦进入复杂场景比如一个带凹槽和加强筋的安装支架它生成的代码经常出现特征丢失、尺寸错乱的问题。而且Zack依赖GPT-4 API跑一次要花不少token没有工程校验生成完模型对不对完全看运气。对于刚接触text-to-cad的人来说Zack是个很好的入门工具能快速建立“原来一句话真的能生成CAD模型”的直觉。但想拿它做正经设计还差得远。3.2 Text2CAD论文与DeepCAD的学术路线我把Text2CAD论文的代码和数据管线也跑了一遍。它的生成速度确实快模型在本地GPU上几十毫秒就出一串命令序列完全不需要调用外部API。但问题也很明显生成的模型和用户要求之间的对齐程度不稳定。我试过输入“一个直径40mm、厚度10mm的垫片中心孔直径12mm”它生成的结果经常是外径偏大或者中心孔偏移。原因在于这类生成模型本质上是“概率生成”它学的是“类似文本通常对应什么样的模型”而不是“严格按文本参数执行”。在学术benchmark上这种生成质量可以得高分在工程场景里毫米级偏差就是废品。不过我也要说这条路线的价值在于速度。如果只是做概念方案的批量试探或者生成一堆不要求严格精度的参考模型它比LLM逐条生成要高效得多。3.3 自己用GPT加CadQuery搭上限最高的方案跑了一圈之后我最后还是回到自建路线上来。原因很简单可控性。自己搭工作流我可以控制prompt模板、控制生成代码的规范、加校验逻辑、失败自动重试。这些是Zack和Text2CAD给不了的。我自己的实测数据直接用GPT-4生成CadQuery代码不校验一次成功的概率大概在65%左右。70%的失败集中在API调用错误和特征顺序错误。加上自动校验和报错回喂重试之后成功率拉到85%以上。别小看这20个百分点在工程里这就是“能用”和“不能放心用”的差别。3.4 工具对比与我的评分方案生成速度尺寸精度可编辑性工程可用度我的评分MIT Zack中中高高中3/5Text2CAD快低中低2.5/5GPT CadQuery自建中高高中高4/5扩散模型网格生成快极低低不可用1.5/5这个评分可能比较个人化但我的出发点始终是“能不能直接用于实际零件建模”。从这个角度看自建路线虽然麻烦却是最值得投入的。4. 从prompt到STEP文件一条可复现的text-to-cad工作流4.1 整体架构和依赖选择我搭的这套工作流整体分为四层输入层用户写一段自然语言描述必须包含功能和关键参数。生成层把描述套进预先设计好的prompt模板发给LLM要求它输出一段CadQuery代码。执行层在安全的Python子进程里执行生成代码得到B-Rep实体。校验和输出层对实体做几何检查、导出STEP/STL、生成元数据JSON。环境依赖很简单Python 3.10以上cadquery2.4OCPCadQuery自带再加一个trimesh用于网格检查。LLM方面我同时测过GPT-4和Claude生成质量差别不大但Claude对CadQuery API的熟悉程度略高典型错误更少。如果你做纯本地部署也可以用开源的Qwen-Coder效果会打折扣但数据不出内网。整个服务用FastAPI包一层接收JSON请求返回STEP文件URL和模型元数据。注意一个关键设计LLM生成的代码必须在子进程里执行设置内存和CPU上限。因为LLM偶尔会写出死循环或者超大阵列子进程直接杀掉最省事。4.2 设计一份不会把模型带偏的prompt模板prompt模板是整个工作流里最容易被低估的部分。我最初只是把用户描述原样丢给LLM结果生成的代码非常随性变量名乱起、特征顺序随机、甚至用法完全错误。后来我把模板改成“结构化任务说明书”成功率立刻上了一个台阶。下面是我现在用的模板框架请生成一段CadQuery 2.x的Python代码实现以下零件 - 零件用途{用户输入} - 关键尺寸参数{尺寸列表} - 建模顺序建议先建主体再打孔最后倒角 - 代码要求 1. 所有尺寸用变量定义在代码头部变量名用可读英文 2. 中间步骤用变量承接最终实体变量必须命名为result 3. 不要import任何CadQuery之外的库 4. 代码中不要写if __name__块不要print 5. 如果某个特征无法实现宁可省略也不要乱编API这里面的关键是第五点“宁可省略也不要乱编API”。LLM在不确定时会编造看起来合理但不存在的函数加了这条约束后幻觉API的出现频率明显下降。另一个细节是“建模顺序建议”CadQuery里特征顺序会影响布尔运算结果先主体后打孔再倒角是最不容易出错的顺序。尺寸参数一定要显式列出不要指望LLM从一段口语描述里准确提取所有数值。我实测过用户说“差不多”“左右”“稍微大一点”这类模糊词LLM会自己脑补数值这是生成偏差的主要来源。所以我在输入层加了参数解析器把尺寸、数量、注释归类再填进模板。4.3 生成、执行、校验、导出的完整脚本核心校验脚本大概是这样的import cadquery as cq import math from pathlib import Path def execute_and_validate(code_str: str, params: dict, save_prefix: str): # 1. 先做语法编译检查语法错误直接抛出来 compiled compile(code_str, generated, exec) # 2. 隔离命名空间执行捕获LLM产生的全局变量 ns {cq: cq} exec(compiled, ns) result ns.get(result) if result is None: raise RuntimeError(生成代码中缺少result实体) solid result.val() # 3. 基础几何校验实体体积必须为正 vol solid.Volume() if not math.isfinite(vol) or vol 0: raise RuntimeError(模型体积异常几何无效) # 4. 包围盒校验尺寸必须落在用户预期范围内 bbox solid.BoundingBox() actual_size [bbox.xlen, bbox.ylen, bbox.zlen] for i, (name, expected) in enumerate(params[expected_size].items()): if abs(actual_size[i] - expected) params[size_tolerance]: raise RuntimeError( f{name}尺寸偏差超限: 期望{expected}mm, 实际{actual_size[i]:.2f}mm ) # 5. 导出STEP和STL cq.exporters.export(solid, f{save_prefix}.step) cq.exporters.export(solid, f{save_prefix}.stl) return { volume: vol, size: actual_size, step: f{save_prefix}.step, stl: f{save_prefix}.stl, }这套校验至少能挡住三种最常见的翻车体积非正说明布尔运算把实体算没了包围盒超差说明LLM把尺寸理解错了编译失败说明API调用有问题。每次校验失败我会把异常信息原样回喂给LLM让它自己改代码重试最多重试3轮。实测中前两轮重试能解决绝大多数问题第三轮基本是在碰运气。跑通这个闭环之后你会发现text-to-cad真正难的根本不是“让AI生成几何”而是“让几何可预期”。5. 实测翻车现场这些坑是真会咬人的5.1 LLM幻觉API与错误调用CadQuery的API设计整体很简洁但LLM还是会编造出不存在的函数。我遇到最典型的一个LLM生成了cq.Workplane(XY).cylinder(10, 5)意图是画一个半径10、高5的圆柱。实际上CadQuery里根本没有cylinder方法正确写法是.circle(10).extrude(5)。这种幻觉在简单场景下还好编译阶段就能发现。真正麻烦的是“看起来合法但语义错误”的调用比如在错误的面上打孔、把拉伸方向搞反、把布尔运算的combination参数写错。这类错误编译能过、执行能跑但生成的零件和用户要求完全对不上只能靠尺寸校验来抓。对策有两个。一是在prompt里加白名单约束直接告诉LLM“只允许使用circle、rect、polygon、extrude、cutBlind、hole、fillet、chamfer、translate这几种方法”把自由度收窄。二是在校验脚本里做AST扫描检查代码里是否出现了预期之外的CadQuery方法名一发现就重试。5.2 过约束、欠约束和布尔运算失败几何内核的报错非常晦涩。OCCT抛出的错误信息长这样BRep_API: command not done或者Shape is not a solid。新手看到基本一脸懵根本不知道是代码哪一行出了问题。我总结了一下这类错误背后有三个高频原因欠约束草图草图层不是闭合区域拉伸无法生成实体。比如画了一个圆弧但没画直线把两端连起来圆弧不是闭合轮廓OCCT直接拒绝拉伸。过约束的重合边两个面之间出现细微的重叠或者共享边布尔差集时内核计算失败。倒角或圆角半径大于壁厚比如壁厚只有2mm倒角半径给了3mm结果就是几何内核崩溃。面对这种问题光靠LLM自己反思很难解决因为LLM对OCCT内核的约束条件没有直觉。我的做法是加一层“特征参数合理性检查”在生成代码时额外要求LLM输出一个“特征参数表”把每个倒角半径、拉伸深度、圆角半径都列出来校验脚本先检查这些参数是否小于对应主体的最小壁厚。这一步能在执行前就拦住60%的内核崩溃问题。5.3 单位、坐标系和“看着对但实际错”的经典案例单位问题是text-to-cad里最隐蔽的坑。用户说“这个板子厚1 inch”LLM在代码里写的是1CadQuery默认单位是mm结果生成一个厚度只有1mm的板子体积差了25.4倍。后来我在prompt里强制要求“所有尺寸一律使用毫米并在代码注释里标明单位换算关系”这个问题基本绝迹。坐标系问题也很典型。LLM默认所有零件都从XY平面开始建但实际零件可能需要从侧面或者顶面开始拉伸。比如一个L型支架如果从XY平面拉伸配合面方向就是错的。现在的解决方案是让用户在描述里显式指定“在YZ平面创建草图”然后在prompt里转成CadQuery的cq.Workplane(YZ)。还有一类“看着对但实际错”的情况最坑网格渲染预览没问题但导出STEP后放进CAM软件发现模型有烂面、缝隙或者微小的自相交。这类问题网格检查根本发现不了必须用OCCT自带的BOPAlgo_ArgumentAnalyzer做实体自交检测。我的建议是做工程交付的模型审核对象永远要选STEP而不是STL。6. 如何把text-to-cad接进真实产品流程6.1 从单件生成到参数化零件族一个text-to-cad工具如果能生成单个零件那它离生产力工具还差一步能不能批量生成一个系列。自动化设备里很多零件是同一个拓扑结构、不同尺寸参数。比如同样是一块安装板有80x60、120x80、160x100三种规格孔位、孔径、槽宽都跟着变。用我前面搭的工作流只要把外径、长度、孔数这些参数从用户描述里抽出来放进一个JSON配置然后用循环调LLM就能自动生成一整个零件族。import json configs [ {name: plate_80, w: 80, h: 60, holes: 2}, {name: plate_120, w: 120, h: 80, holes: 4}, {name: plate_160, w: 160, h: 100, holes: 6}, ] for cfg in configs: prompt render_prompt_template( 一块长方形安装板长{w}mm宽{h}mm四角倒角R5均布{n}个孔直径6.5mm, **cfg ) code llm_generate(prompt) result execute_and_validate(code, prefixcfg[name]) print(cfg[name], result)生成完每个零件后我会把STEP文件连同体积、质量、尺寸的元数据JSON一起入库。这一步对接PLM系统非常关键——以后做BOM比对、重量估算直接查元数据就行不用重新打开模型。6.2 迭代流程里的最实用玩法搭配版本管理我目前最常用的做法是把text-to-cad跑出的成果纳入版本管理流程用CI/CD负责任务调度每次跑完自动构建。具体的做法很简单把项目里所有零件描述写成一个parts.yaml一个零件一行描述里写清楚要求参数。提交到Git仓库后用CI jobs拉一次跑一遍完整的“生成→校验→导出”流程如果某一个零件尺寸校验失败了CI失败整个提交被拦截。用这个方式模型参数管理做到了可追溯、可回滚、可协作。用Git管理CAD模型还有个额外的好处改了一个尺寸git diff能看到具体是哪个参数变了评审效率比传统设计高得多。配合Git LFS存STEP文件团队协作的体验和管代码一样顺手。6.3 后续方向与我的个人判断text-to-cad这个方向接下来一两年的演进我个人判断有几个值得关注的信号一是LLM和专用生成模型的混合路线。LLM负责理解文本和做全局规划专用模型负责快速生成草图轮廓再由CAD内核做精确化处理。Text2CAD的“两阶段”思路和Zack的“端到端代码生成”会在某个点汇合。二是多模态输入。很多实际需求是“参照这张图做成M6螺栓孔的间距”纯文本描述不够图片加文本的混合输入会更接近真实工作场景。Autodesk的Project Bernini已经在往这个方向做值得关注。三是大厂把text-to-cad集成进现有CAD软件。当生成结果可以直接在原生CAD环境里打开并继续编辑时这个技术的价值会彻底释放。到时候AI生成的不再是孤立文件而是设计流程里的一个起点。在目前这个阶段我对所有想尝试text-to-cad的人只有一句劝告别追求一步到位先把“生成→校验→重试”的闭环做扎实成功率上去了再谈自动化。我踩过的坑里百分之八十不是因为AI不够聪明而是因为缺少工程化的兜底机制。把校验脚本写好了这个工具就真正从“玩具”变成了“生产力”。