几个月前团队里几位机械设计的老同事接连给我转来同一个词Text-to-CAD。字面意思很好懂给一句话AI直接吐出一个能用的CAD模型。但真正上手试了一段时间后我才发现这件事远不是“给AI看图说话”那么简单它既要理解自然语言里的模糊意图又要输出精确到小数点后几位的几何数据还必须在拓扑连接上一点错都不能出。这篇文章我想从一个实际用过的工程师视角聊聊Text-to-CAD到底是什么、现在主流哪些方案能跑通、底层原理各自怎么设计以及个人上手时该选哪条技术路线、会踩到哪些坑。如果你是在做机械设计、3D打印、非标自动化或者单纯想用自然语言快速出模型草图这篇内容应该能帮你省下不少折腾时间。我不会只讲概念会把能落地的路径、可复现的步骤、参数设置和排错经验都摊开来说。1. Text-to-CAD的核心命题不是翻译文字而是生成拓扑1.1 先搞清楚它到底在解决什么传统CAD建模的工作流本质上是一个“需求转译”的过程。客户或者项目经理给你一段描述“底板长200、宽100四角各沉一个M8的孔中间留一个直径60的过孔”然后你在SolidWorks或者FreeCAD里画草图、加约束、拉伸、打孔、倒角。真正花时间的不是“画”这个动作而是把需求里的所有隐含信息尺寸、位置关系、公差、装配关系逐条确认、转译成建模操作序列。Text-to-CAD想干掉的就是这中间最耗时的一环直接从自然语言出发端到端生成一个可编辑、可加工的CAD模型文件。注意“可编辑”三个字很关键它和AI生图有本质区别。图片生成出来像素错了就错了人眼看不出来就行但CAD模型如果尺寸错了、孔位偏了、面与面之间没有正确缝合后续做仿真、做CAM、做装配每一步都会连环出错。所以Text-to-CAD不是“给文字配个三维图”而是要把一段口语化的描述转成一套精确、封闭、拓扑正确的几何表达。理解这一点再看市面上的方案思路就清晰很多。1.2 CAD模型在计算机里长什么样B-rep、CSG与网格的差别要理解Text-to-CAD的技术难度得先知道CAD软件在后台存的是什么。我们平时导出的STL文件只是用成千上万个三角形面片“糊”出来的表面近似工业软件一般不会拿它当生产数据——它没有面的连续性也没有几何特征信息。真正承载设计的是B-rep边界表示Boundary Representation和CSG构造实体几何Constructive Solid Geometry。B-rep用一张“拓扑-几何”双层结构来描述实体拓扑层记录顶点、边、面之间的连接关系几何层记录每个顶点坐标、每条边的曲线方程、每个面的曲面方程。STEP文件就是这类数据的标准交换格式。你可以把B-rep想象成一张建筑的施工图墙和梁的位置、门窗洞口的空间关系、每根柱子精确到毫米的尺寸全部按部件连接关系组织好。CSG则相反它像一份“操作记录”——先立方体再挖圆柱再和球体做布尔并集每一步都对应一棵操作树。这就解释了为什么Text-to-CAD这么难做CAD模型的终极产物不是“一张像样子的图”而是一套必须自洽的拓扑结构。拓扑上一条边连错模型导入软件后就是破面、烂边轻则报错重则直接无法打开。AI圈常说的“生成式模型擅长捕捉分布”在图片领域足够用了但在CAD领域光捕捉分布远远不够你还需要每次都精确命中那个封闭、有效、可计算的结构。1.3 为什么“文字→图片”好做“文字→CAD”难做我做了一段时间Text-to-CAD之后最大的感受是这个问题和文字生图表面上很像底层困难完全不同。监督信号的粒度不同。图片模型训练的损失函数是像素级差异稍微糊一点、歪一点视觉上依然“像那么回事”CAD模型需要的是拓扑正确加尺寸精确差0.1毫米在机械件上就是废品。输出空间的约束结构不同。图片是一大堆弱约束像素的集合CAD则是一堆强耦合的几何实体。生成器改了一个顶点的坐标可能连带影响三条边的曲线方程、五个面的边界环这种耦合关系很难靠“下一个token预测”这类序列模型稳得住。信息补全的难度不同。你说“一个带孔的长方体”图片模型可以根据训练分布猜一个合理孔径CAD模型猜错一个孔径后续的装配、加工全部崩。Text-to-CAD本质上是一个“信息补全约束满足”问题而这恰好是深度学习模型最不擅长的硬约束场景。这些难度决定了市面上跑通的方案并没有走同一条路——有的直接让模型输出几何序列有的绕道让模型写代码。下面拆开看。2. 主流技术路线拆解两条完全不同的实现路径2.1 路线一LLM直接生成B-rep序列Text2CAD为代表AutoDesk Research团队做的工作Text2CAD就是这个方向的代表性研究。它的做法一句话概括把CAD模型编码成一串离散token然后用大语言模型做next-token prediction输入文字输出B-rep序列再解析成STEP文件。具体拆开看有几个关键设计。怎么把CAD变成tokenB-rep中每个面都有曲面方程每个环都有边序列每个顶点都有坐标团队把这些几何元素做离散化编码让它变成一个扁平的长序列。这步很像“把一张工程图翻译成一篇字符文章”。用什么样的模型他们的实现分基于Mistral和基于LLaMA的两个版本。选择LLM做主干好处是自然语言理解能力现成不用另外训练一个文本编码器而且生成长的几何序列时LLM对上下文的记忆能力比传统seq2seq模型强很多。数据从哪来他们做了一套数据管线从公开的CAD模型库中批量生成“文本-模型”配对描述。这里有个细节很多描述是模板化生成的比如“一个边长为X的立方体中心有一个半径为Y的圆柱孔”覆盖的句型有限对真实世界五花八门的口语描述泛化能力偏弱。这条路线真正跑起来难点在推理后的几何修复。模型生成的序列很可能在拓扑层面有误——比如某个面引用了不存在的顶点ID或者两条边本应共享端点却各写各的坐标。AutoDesk的做法是先解析序列再用底层几何内核做合法性验证不合法就修修不了就废掉重新采样。实际用下来简单零件成功率还行一到复杂装配体、多特征叠加的场景精确率掉得很快。2.2 路线二LLM生成CadQuery代码ZooKitty为代表另一条路不直接生成几何而是让LLM生成一段Python代码代码调CadQuery库去建模。CadQuery是OpenCascade内核之上的参数化建模库特点是“用代码描述设计意图”先选一个工作平面画轮廓拉伸再在某个面上打孔每一步都是可执行、可修改的代码。社区里有一批工具走的就是这个路线ZooKitty是其中比较出圈的。用户输入“一个边长为50毫米的立方体顶部中心有一个直径10毫米、深5毫米的盲孔”LLM输出CadQuery脚本执行脚本得到STL或STEP。这样做有几个非常实际的优点不用重新训练大模型。LLM的代码生成能力是通用能力在训练阶段已经大规模对齐过不需要专门给它灌大量CAD数据接上API就能用。输出天然可编辑。生成的不是“一张僵死的几何快照”而是一段参数化脚本。想改孔径改一行代码就能重新生成这非常贴合工程师的实际工作方式。精度有保证。几何计算全部交给OpenCascade内核去算LLM只负责拼装正确的API调用序列只要代码能跑几何在数学上就是精确的。代价也很明显模型的表达能力被CadQuery的API上限锁死。遇到自由曲面、复杂倒角、曲面混合这类操作代码会变得非常长LLM很容易“幻觉”——生成一段看起来结构完整、函数也存在的代码但一运行就报错或者跑出来的形状和描述完全不沾边。另外让模型输出代码再执行还有代码注入的安全隐患必须放在沙箱里跑这点后面实操部分我会细说。2.3 两条路线的适用场景对比对比维度B-rep端到端生成CadQuery代码生成核心产物STEP/B-rep序列文件Python脚本 STEP/STL导出代表项目Text2CADZooKitty及类似工具训练数据门槛需要大规模文本-CAD对齐语料复用通用代码能力门槛低可编辑性弱生成的是最终几何快照强所有参数都在代码里精度保障靠解码后修复拓扑错误率偏高由CAD几何内核保证代码能跑就精确上手难度高需要GPU训练/推理环境低CPU即可运行当前适合场景学术研究、概念草图快速探索工程落地、参数化建模、3D打印做工具选型时我的建议非常直接个人和小团队优先走CadQuery代码生成路线端到端B-rep生成现阶段更适合作为研究方向观望或者用在“只需要一个粗糙外形参考”的场景。3. 上手实操从一句话到可编辑的CAD文件3.1 环境准备与模型选型先说环境。走CadQuery路线配置很低Python 3.10以上内存16GB足够CPU都能跑不需要GPU。重点提醒一下依赖问题——CadQuery和它的底层OCC绑定ocp库版本必须严格匹配。我最初直接pip install cadquery装出来的版本在FreeCAD导入时出现过奇怪的退化面后来按官方文档用conda装指定组合才稳定。conda create -n cad python3.10 conda activate cad conda install -c conda-forge cadquery2.4.0 pip install openai # 或者你用的本地LLM客户端如果是走Text2CAD这种端到端路线建议准备8GB以上显存的NVIDIA GPU并提前装好CUDA版本的PyTorch。Mac的M系列芯片跑不了这类权重推理原因很简单推理脚本依赖CUDA加速。退一步说即便没有GPU也可以拿现成的LLM API走代码生成路线这更贴近我实际工作流的常态。语言模型选哪个我自己的体验是GPT-4级别的模型生成的CadQuery代码明显比开源小模型稳定尤其在多特征叠加的场景小模型容易漏掉某个孔的定位参数。但开源模型跑本地数据安全性好适合公司内部有保密要求的场景。3.2 用CadQuery路线跑通第一个样例以“一个外径40毫米、内径20毫米、厚度10毫米、有6个均匀分布螺栓孔的法兰盘”为例。在OpenAI API里输入这段提示词你是一名CadQuery专家。请根据以下需求生成可运行的Python代码 1. 一个法兰盘外径40mm内径20mm厚度10mm。 2. 螺栓孔位置在半径30mm处6个均匀分布。 3. 使用毫米为单位。 4. 只输出代码不要解释最后导出为STEP格式。得到的代码大致长这样import cadquery as cq # 基础法兰盘体 flange ( cq.Workplane(XY) .circle(20) # 外径40 半径20 .circle(10) # 内径20 半径10 .extrude(10) # 厚度10mm ) # 在顶面打6个螺栓孔 flange ( flange.faces(Z) .workplane() .polarArray(30, 0, 360, 6) # 半径30mm整圆均匀分布 .circle(3) # 螺栓孔径直径6mm .cutThruAll() ) cq.exporters.export(flange, flange.step)保存成flange_gen.py直接跑python flange_gen.py。终端没有任何报错工作目录下就会多出一个flange.step用FreeCAD打开就能看到完整的法兰盘。这里有个细节值得单独说提示词里那句“只输出代码不要解释”非常重要。否则LLM经常给出“以下是你需要的Python代码”加上前后解释文本你脚本去执行还要先做文本清洗。更稳的做法是在提示词里要求“用JSON对象包裹代码”然后在Python侧用json.loads解出来能省掉一大半后处理麻烦。3.3 用Text2CAD路线生成B-rep模型再聊端到端那条路。以Text2CAD开源仓库为例基本步骤是克隆代码、装依赖、下载预训练权重、运行推理脚本。仓库里有一个公开数据集和Mistral/LLaMA两个基座版本我把流程压缩成下面几步实际操作时以仓库最新README为准git clone https://github.com/AutoDeskResearch/Text2CAD cd Text2CAD pip install -r requirements.txt python sample.py --description a rectangular plate with four holes at the corners --output out.step跑通demo不难但我必须泼一盆冷水这条路线的产出质量现阶段远不如代码生成路线。我实际跑过几个简单样例比如“中心带孔的长方体”输出确实能出一个差不多形状的STEP可一旦描述里出现“底部凸台”“侧面开口”这种需要跨面协调的特征生成结果经常出现面缺失或者孔位置偏移。另外Text2CAD输出的STEP直接导入FreeCAD偶尔会自动修复通过但更多时候会提示几何无效。所以我把这套流程定位为“快速看个形状方向”而不是“拿到就能用的成品”。如果真要用它出模型后处理是跑不掉的。3.4 后处理与格式转换无论哪条路线生成完之后都面临格式问题。STL适用于3D打印和可视化但丢掉了面和拓扑信息STEP才是工业交换的正确格式能进仿真和CAM。CadQuery本身支持两种导出我建议一律导出STEP需要打印再转STL。如果拿到一个破面或无效几何的STEP可以用PythonOCC做修复也就是调用OpenCascade的ShapeFix工具。from OCC.Core.STEPControl import STEPControl_Reader from OCC.Core.ShapeFix import ShapeFix_Shape # 读取STEP reader STEPControl_Reader() reader.ReadFile(broken.step) reader.TransferRoots() shape reader.OneShape() # 修复几何 fixer ShapeFix_Shape(shape) fixer.Perform()这里大概率会经历“修完还是不对”的情况尤其是自相交面ShapeFix只能处理一部分。我踩坑之后的教训是与其费劲修烂模型不如回到提示词层面把描述拆简单一点分段生成几个实体再在CAD软件里做布尔操作合成。这个思路绕开了端到端模型最不擅长的高组合复杂度问题。4. 参数调优与效果控制让模型听懂“工程话”4.1 提示词的三层写法很多人在Text-to-CAD上碰壁第一反应是模型太笨但看了实际提示词后我经常想说其实是话没说到位。自然语言有歧义模型只能按概率猜你不给限制它就会用最常见的默认值猜。我把提示词分成三个层级第一层只有描述“做一个带孔的法兰盘”。模型会自由发挥孔径、厚度、孔位全靠猜出来的东西基本不可用。第二层带上关键尺寸“外径40mm、内径20mm、厚10mm、6个螺栓孔均布在直径30mm的圆上”。这个级别能满足“外形对得上”的要求。第三层加入约束和意图“底面保留一个直径25mm、高5mm的凸台凸台用于定位需与下壳体配合”“未指定的圆角默认R1”。这个级别生成结果才真正接近可用的工程零件。我的习惯是用模板把第三层常见约束固定下来比如“所有未指定尺寸采用常规值并在代码注释中显式标注”“所有孔必须是通孔除非特别说明盲孔深度”。这种做法本质上是把模糊的文本需求“工程化”让LLM在信息缺失时有一套显式的默认策略而不是暗中乱猜。4.2 从粗糙到可用多轮精修闭环Text-to-CAD生成的结果极少一次就完全符合要求这不丢人传统CAD建模也要改好几轮。问题在于怎么改效率最高。我试过直接把描述重新发一遍、补充尺寸也试过把生成的STEP导回CAD看一眼再描述要改哪里。实用的闭环是这样第一轮生成代码/模型打开检查发现问题后把问题描述原样喂回LLM——“当前生成的代码如下法兰盘上6个螺栓孔的中心圆直径是60mm客户要求是40mm请你修改代码只输出修改后的完整代码”同时附上原始代码。这里有个技巧附件里给代码比给描述更高效。因为LLM可以精确定位到修改点而不是重新生成一个可能风格迥异的版本。这个多轮迭代闭环其实就是代码生成路线相对端到端B-rep生成最大的优势——你可以像跟一个远程工程师协作一样反复提修改意见而不是每次重新碰运气。4.3 精度与可编辑性的权衡做精密加工件的时候我对AI生成的模型始终保留一份警惕。LLM写代码这个环节本身不会引入几何误差OpenCascade的计算精度很高误差出在“文本到参数”的转译上——比如你描述“孔距40mm”模型在代码里可能因为单位换算错误写成了4mm或者40in。所以精度问题更像是语义转译问题而不完全是数值问题。想要缓解可以在提示词里要求模型在代码中显式声明单位并在注释里标注关键尺寸。我甚至会在代码生成后加一道自动检查脚本解析CadQuery代码里的关键尺寸值和需求文档里的尺寸做比对不一致直接打回重新生成。可编辑性则是另一层考量。B-rep端到端生成的是“结果”CAD设计师拿到后很难回推设计意图代码生成的是“过程”改一行参数整个模型重新生成。从实用角度看代码生成路线在可编辑性上的优势比它在精度上的优势更加明显这也是我更看好后者的原因。5. 常见问题与排查技巧实录5.1 问题速查表我在不同机器上跑过几十个样例把最容易踩的坑整理成一张表方便你直接对照排查。问题现象可能原因处理方案生成的Python代码运行报错LLM调用了不存在的API或缺少必填参数把报错信息逐字贴回LLM要求修复后只输出代码模型生成了但没有孔/凸台CadQuery工作平面选错特征建在无关面上在提示词中显式要求“先选择顶面作为工作平面”尺寸明显不对或偏大/偏小10倍单位混淆文本描述mm但代码用inch提示词强制“统一使用毫米并给出尺寸检查注释”STEP导入CAD提示无效几何B-rep序列拓扑错误或曲面未缝合用PythonOCC的ShapeFix修复或简化描述重新生成特征位置偏移定位基准不在预期坐标系上明确指定原点比如“螺栓孔圆心在原点”推理环节GPU显存不足模型参数量大batch设太高加入量化或使用半精度推理batch设为1生成STL有自交面代码里的布尔操作对象之间有重叠减小重叠体积或用“切割再合并”的方式建模5.2 两个最容易忽略的安全问题代码生成路线有个隐藏麻烦LLM生成的代码本质上是从互联网语料学来的没有人帮你保证它干净。我见过社区有人把生成的CadQuery代码直接在本地执行结果脚本里混入了读取环境变量的可疑操作。个人测试可以无所谓但公司环境一定要在隔离沙箱里跑最省事的做法是用容器挂载目录只允许写入输出文件夹。另一个问题是数据合规。如果你用的是云端LLM API把公司图纸需求文本发过去之前务必确认有没有保密审查流程。我在自己的项目里遇到客户图纸是机密文件处理办法是在本地起一个小参数模型。能力弱一点没关系配合多轮修正也能完成建模安全性比生成效果更重要。5.3 端到端模型的失败处理经验用Text2CAD跑批量生成时我发现一个规律一次性生成多个零件时模型偶尔会出现同一个失败模式反复出现的情况。比如连续三次在“侧面孔”特征上出错这种不是随机噪声而是数据分布里这种特征太稀疏模型压根没学会。我的建议是把复杂特征描述拆解成子步骤不要一次说“侧面带一个异形阶梯孔”而是让模型先生成一个底板再生成阶梯孔的单独实体最后用布尔操作合并。另外一个调试思路是降低生成温度。Text2CAD解码时温度越高序列越有“创造性”但几何上越容易胡来。我在自己测试中把采样温度从默认的0.8降到0.2无效拓扑的比例明显下降。等模型出一个稳定版本再调高温度尝试不同变体会更靠谱。6. 我对这个方向的个人判断与实操建议Text-to-CAD现在到底是玩具还是工具我的明确答案是它已经是3D打印爱好者和非标设计前期的效率工具但还不是精密制造环节的生产级工具。原因不在生成速度也不在可视化效果而在设计意图的承载。CAD文件不只是几何数据它内部隐含了公差、基准、装配逻辑、制造工艺信息。现有Text-to-CAD生成的模型大多停留在“几何外形正确”这一层到了设计意图这一层还有很长的路要走。但如果你愿意把使用场景放在“草图探索”和“参数化模板生成”上它能实打实地省时间。我个人试过的应用场景包括客户随口描述一个非标支架我生成几个外形方案供选择团队把常用的“底板螺栓孔通孔”系列产品描述固化成模板auto生成初稿3D打印模型网站上的用户用自然语言生成可打印结构然后再手工微调。跟着这个方向走下去我还想建议两件事。第一把你团队的描述习惯沉淀成提示词模板形成自己的“自然语言建模规范”——描述得越规范生成结果越稳定这是现在投入产出比最高的环节。第二关注数据闭环。如果你长期用某一款模型做代码生成可以把修正后的代码、最终模型和原始需求文本保存下来积累到足够数量后微调一个小模型生成的适应度和成功率会显著提升。这条路我团队已经走了一段时间效果比一开始预想的好很多。把一句话变成一台机器的零部件听起来很科幻但它现在确实可以在你自己的笔记本上跑通。多试几次之后你一定会遇到“它居然完全懂了我的意思”和“它完全没听懂我在说什么”两个极端这本身就挺有意思的。如果你已经跑通了第一个Text-to-CAD样例欢迎你在评论区分享你的提示词模板和踩坑记录我看了之后会接着写续篇。