★ FEATURED ARTICLE 做结构设计、机械加工或者产品开发的朋友这两年大概率已经被“text-to-cad”这个词反复刷屏。它不是一个具体软件而是一类工具的总称你把“一个带四个M5安装孔的铝合金外壳底座内腔深度22毫米外轮廓120乘80乘30”这种自然语言描述丢进去它替你生成对应的CAD模型而且是带特征树、能继续编辑、能导成STEP供加工的那种不是渲染一张效果图糊弄你。这个方向最近热度很高GitHub上相关的开源项目star涨得很快论文也一篇接一篇。我自己的判断是它正在改变“从想法到三维模型”这条链路里最耗人的那一环。这篇文章我不打算复述论文结论而是从使用者和复现者的角度把text-to-cad的原理、路线、实操步骤、踩坑记录完整梳理一遍。适合以下几类人想评估这个技术能不能引入自己工作流的机械工程师做AI产品想找落地场景的开发者以及想用文本生成快速出方案的概念设计师。文章涉及的内容我会尽量讲透尤其是那些论文里不会写的细节。1. 先看懂 text-to-cad 要解决的真实痛点1.1 传统 CAD 建模的隐性门槛很多人觉得机械设计门槛在数学和力学实际上工具本身才是普通人最先撞上的墙。以Fusion 360或者SolidWorks为例你要做一个稍微像样的零件得先掌握草图绘制、几何约束、尺寸标注、拉伸、旋转、阵列、倒角、抽壳这一整套操作每个操作背后还有一堆快捷键和面板选项。这里面的学习成本不是一两天能过的往往是三到六个月。我见过不少工程师明明对加工工艺很熟建模却要反复查教程。更要命的是设计过程中有大量重复劳动标准件底座换个孔位法兰盘改个直径这类活儿高度套路化但每改一次都要重新操作一遍建模界面。text-to-cad想解决的正是这个“想法到模型”过程中由工具操作带来的隐性成本——它把建模的意图表达从“操作软件”变成了“描述需求”。这个转变听起来简单实际影响却不小这意味着建模这件事开始从“技能密集型”往“表达密集型”迁移。1.2 为什么是现在大模型能力拐点文本生成图像早在2022年就已经火过一轮但文本生成CAD始终慢半拍原因并不复杂图像是像素网格错了顶多是画面难看CAD模型是严格几何实体差一个约束就可能导致布尔运算失败或者加工出来废件。早期基于规则的方法根本撑不住自然语言那种含混表达而传统机器学习又处理不了三维几何的结构化复杂性。真正让text-to-cad迎来拐点的是大语言模型和多模态模型带来的两个能力一是对自然语言意图的理解能力强了很多二是代码生成能力成熟到了可以直接输出CAD脚本。同时开源的CAD数据集规模也到了可以用深度模型训练的程度。技术、数据、算力三条线凑到一起才让“给我一个带孔的法兰”这种话真正能变成可编辑的三维模型。另外OpenCASCADE这类开源几何内核的成熟也功不可没它让“执行代码生成真实实体”这件最底层的事变成了免费可用的基础设施。1.3 目标用户与实际落地场景以我周围接触到的情况来看text-to-cad最现实的落地场景集中在几个方向前期方案快速迭代概念设计阶段一天要出十几个外形方案用文本改描述比重新建模快得多。非专业人员的定制化需求采购、销售拿着客户描述想让结构工程师快速出一版示意模型避免反复邮件沟通。参数化标准件库的自动化扩充把现有标准件用文本描述一遍批量生成不同规格型号省去手工建模的时间。教育培训让学生用自然语言先学会表达几何需求再回头看建模软件怎么操作学习曲线会平滑很多。当然这些场景能落地的前提是生成结果必须是真正的CAD实体能进工程软件继续编辑而不是一个静态的三维网格。这正是text-to-cad和普通3D生成比如生成STL网格模型最本质的差别也是后面所有技术难点的根源。如果只是要一张好看的效果图现有方案早就够用了要的是能生产、能编辑的实体模型才需要专门研究这个方向。2. 核心技术路线拆解2.1 路线一把 CAD 建模当作编程任务我最早尝试的text-to-cad方案其实不是那些听起来很前沿的生成模型而是大语言模型加CadQuery脚本。思路很简单CAD有成熟的脚本化接口CadQuery、FreeCAD的Python API、OpenCASCADE底层内核都能用代码描述几何操作。那么让大语言模型直接生成这一段Python代码再在本地执行就能产出CAD模型。这条路线本质上是用代码生成来代理几何生成优势非常明显模型不需要专门训练直接用现成的代码大模型就能胜任生成结果天然是参数化的因为有Python代码在后续改尺寸、改特征都方便只要代码语法正确OpenCASCADE内核会保证几何至少是合法的实体不容易出现破面。我在内网环境里试用过7B级别的小模型来生成CadQuery代码效果虽不如大模型稳定但处理中等复杂度的规则零件已经够用这对企业数据保密是个好消息。缺点也很直接大语言模型对三维几何的理解是“符号化”的它并不真正知道一个扫掠路径在空间里怎么走复杂曲面和复杂装配很容易生成出逻辑正确但几何错误的代码。所以这条路线适合轴套、法兰、支架、箱体这类规则机械零件对自由曲面和复杂型面基本无能为力。我自己的评估标准是凡是能用“二维草图拉伸/旋转/打孔”三步描述出来的零件这条路线都很稳。2.2 路线二序列生成与扩散模型生成更贴近“生成模型”正统的是序列生成路线。这类方法的核心是把CAD建模过程编码成一系列离散的token就像把一段话拆成词一样把“画一个草图”“拉伸10毫米”“倒角”这些操作拆成token序列然后用类似Transformer的模型自回归地生成整段建模操作序列最后把生成的序列重放成CAD模型。最典型的开源代表是Text2CADZoo团队的工作,以及DeepCAD系列。它们的训练数据来自Fusion 360的公开数据集每个模型都被提取成“草图-拉伸-打孔”这样的操作记录序列。训练时模型看到的是文本描述和对应的操作序列学的是“从语义到操作”的条件映射。推理时模型先输出一整段操作序列再用CAD内核重放得到一个真正的参数化模型。扩散模型路线则是另一类做法把CAD操作序列映射到一个隐空间用扩散模型在这个隐空间里做去噪生成过程中用文本嵌入作为条件控制。相比自回归的逐token生成扩散模型在生成整体形状一致性上往往更好但控制精度和编辑性稍弱。这两条路线我实际跑下来的感觉是序列生成的模型对“可编辑性”更友好因为输出的操作序列本身就是特征树扩散生成在形状多样性上有优势但要把它变成能生产使用的模型中间还得接一步参数化重构建流程更长。2.3 几何表示的选型B-Rep、CSG 与网格为什么text-to-cad不能直接复用Stable Diffusion那套核心在于几何表示。图像模型处理的是像素网格而CAD领域的主流表示是B-Rep边界表示也就是把实体描述成一组精确的表面、边和顶点的拓扑关系并且带上曲面方程Nurbs、平面、圆柱面等。B-Rep的优势是数学精确、能直接用于CAM加工缺点是没有统一的token化方式模型很难直接输出。另一类表示是CSG构造实体几何用布尔运算把基本体组合起来表达简洁但表达能力有限多数机械零件并不适合纯CSG描述。网格表示STL/OBJ则是3D生成模型最常用的形式也是text-to-cad在实际评估时踩过的坑视觉上看起来像但网格模型没法直接编辑、没法标注尺寸、更没法直接生成加工刀路。所以text-to-cad技术演进中一个很重要的努力方向就是让模型直接输出CAD原生表示或者至少保证输出结果能无痛转换回CAD。从实际使用角度看用户拿到手的如果是一个STL网格基本只能看看外观拿到STEP或者参数化特征树才谈得上继续设计。这也是我评估一个text-to-cad方案好不好用的第一标准。顺便说一个容易忽略的点即便是同一类表示不同CAD软件之间的兼容性也有差异所以生成结果最好统一用STEP中性格式交付避免直接跨软件编辑原生文件带来的一堆兼容性麻烦。2.4 数据集与训练细节聊CV和NLP的人可能对数据集规模习以为常但CAD领域的数据稀缺是真实痛点。目前用得最多的几个来源DeepCAD数据集包含约17万个从Fusion 360社区采集的机械零件每个零件都被拆解成一套“草图-拉伸”操作序列ABC数据集有约100万个零件覆盖面更广但注释质量参差Text2CAD这类文本到CAD任务还需要额外的文本描述很多是用点云/三维模型的自动标注模型或大语言模型生成的合成描述。我就遇到过一个数据相关的坑模型在训练时把“圆孔”和“盲孔”混淆。查下来是数据集里这两种孔的描述标注高度相似而且实际建模操作序列差异不大导致模型学不到“到底要不要打穿”这种细节语义。这个问题直到后来用更细粒度的描述模板重新生成标注再人工抽检校对才明显缓解。数据质量对text-to-cad的影响往往比模型结构本身更大这点怎么强调都不过分。很多论文里展示的惊艳效果背后其实是对数据做了大量清洗和标注工作这部分在论文里通常只是一句话带过。3. 实操复现从文本到可编辑 CAD 模型3.1 方案选型与环境准备如果你现在想自己跑通一个text-to-cad流程我会推荐先走“大语言模型 CadQuery”这条最务实的路线等理解了整个链路再去看Text2CAD这类专门训练的生成模型。选这条路线有几个理由依赖少、不需要GPU训练、结果可控性好、调试方便。更重要的是这条路线走通一次之后你会对“自然语言怎么变成几何操作”建立直觉再去看那些论文里的模型架构会轻松很多。环境准备上推荐用Python 3.10以上版本核心依赖就三个CadQuery负责几何建模、FreeCAD的Python接口用于兼容性检查和显示、以及OpenCASCADE内核CadQuery底层自带。安装非常简单一条命令搞定CadQuerypip install cadqueryFreeCAD按官方安装包装好后在Python里配置一下路径即可。我自己是在Windows环境跑通的Linux和macOS也没有本质差异。这里有个经验CadQuery的版本尽量选2.x以上API稳定性和文档完善度都好了很多。如果只是想快速出模型不涉及复杂装配CadQuery一个库就够了如果后续要和加工软件联动还是建议同时装上FreeCAD做格式转换FreeCAD的STEP导入导出更可靠尤其是批量处理文件的时候。3.2 完整生成流程演示下面演示一个最简单的流程生成一个带中心通孔的法兰盘。先定义需求描述文本然后让大语言模型生成CadQuery代码。以“外径60毫米内径25毫米厚度10毫米中心通孔外带四个均布M6螺纹孔”这样的描述为例。大语言模型给出的CadQuery代码大致长这样import cadquery as cq result ( cq.Workplane(XY) .circle(60 / 2) .extrude(10) .faces(Z) .workplane() .rect(45, 45, forConstructionTrue) .vertices() .hole(6) .faces(Z) .workplane() .circle(25 / 2) .cutBlind(-10) ) cq.exporters.export(result, flange.step)这段代码的逻辑是在XY平面画直径60的圆拉伸10毫米形成圆柱底板在上表面建立新的工作平面画一个45乘45的构造矩形在四个顶点位置打6毫米的孔最后在中心挖一个直径25的通孔。代码执行的产物是一个合法的STEP实体文件直接用FreeCAD或者Fusion 360打开就能看到并继续编辑。我特别想强调“工作平面”这个概念这是CadQuery的灵魂。很多新手第一次生成的模型看起来莫名其妙就是因为在错误的工作平面上做了操作。记得先理解每个操作是在哪个平面、哪个基准上发生的——大语言模型生成的代码自己跑之前务必人工检查一遍坐标关系尤其是第一次用的时候。3.3 提示词调优实战自然语言到CAD提示词的质量直接决定结果质量这一点和AI绘画类似但约束更严格。我的经验可以总结成几条尺寸和单位必须明确。写“直径25”不如写“直径25毫米”写“厚度10”会让模型在英寸和毫米之间乱猜。关键特征要显式列出。想打通孔就写“通孔”只写“孔”它可能给你盲孔也可能给你螺纹孔。几何关系用操作语言描述。“在顶面中心挖一个直径20的沉孔深度5然后在沉孔底面打一个直径10的通孔”比“上面有个台阶孔”可靠得多。特征数量控制在合理范围太复杂的描述生成代码时容易丢特征。一条描述建议聚焦一个主要形状加两三个次要特征复杂零件拆成多次生成再装配。实测过一个案例同样是“法兰盘”这个描述什么都不带生成出来的是一个简单的盘体加上“外径60毫米、内径25毫米、厚度10毫米、四个均布孔直径6毫米”生成结果的几何完全符合预期差异就是这么大。我建议每条提示词都按“主体形状关键尺寸特征位置孔洞细节”四段式来组织这样模型不容易漏信息出问题也方便定位是哪个环节理解偏了。4. 避坑指南常见问题与排查4.1 生成结果形状不符合描述这是我遇到频率最高的问题。原因通常不是模型能力不够而是描述和代码之间存在理解的gap。排查时先把自己当作审核者按顺序核对轮廓对不对、尺寸对不对、特征位置对不对、打孔是否穿透。如果发现尺寸对但位置乱多半是工作平面选错了如果轮廓对但深度不对多半是拉伸方向理解偏了。如果是在用Text2CAD这类专用模型症状会更明显尺寸基本对不上比例失调。这些模型在语义层面学得还可以但数值精确度并不好因为它们的目标函数是形状相似度不是尺寸误差。产品设计阶段可以接受“大概像个法兰”但要出图纸就完全不行。所以专用生成模型的输出我的建议是永远当作“概念草图”对待进入工程阶段前还是要参数化重建一次。这点说起来简单实际做的时候很多人会偷懒直接拿去加工结果废件率感人。4.2 模型无效或不可编辑CadQuery/OpenCASCADE路线里最常见的坑是“模型看起来对但布尔运算报错”或者“导出的STEP在其他软件里显示为破面”。这类问题的根源多数是布尔操作对象之间出现了零厚度间隙、重合面或者退化边。调试技巧是先简化特征把倒角、螺纹这类后处理特征去掉验证基础实体是否合法再逐个加特征定位到具体出错的操作。这个过程虽然枯燥但非常有效。另外一个典型问题是“不可编辑”。Text2CAD生成的模型如果是以网格形式交付那就基本告别参数化编辑了。就算是以操作序列生成的模型很多模型输出的特征树也非常混乱草图约束缺失改一个尺寸可能连锁报错。我自己的习惯是收到生成的模型后先检查特征树是否干净有没有大量“布尔差集”和“固定位置基准面”这类不可维护操作如果有宁可重新生成一次或者手动重建也别在垃圾特征树上硬改。经验告诉我留着问题特征树继续改最后的时间成本往往比重建还高。4.3 精度与工程可用性差距必须坦诚讲一句目前所有text-to-cad方案距离直接进机加工车间都还有距离。原因不在于生成模型让零件“好看不好看”而在于工程图需要的公差、表面粗糙度、螺纹规格、热处理要求这些制造语义文本生成模型基本不会主动处理。我们现在能做到的极限是“概念设计和快速示意”层面零障碍以及“标准件参数化生成”层面比较可靠。尺寸精度方面LLM加代码生成的方案误差反而更小因为代码里写多少毫米就是多少毫米只要代码正确专用生成模型则容易在毫米级甚至百分之几的比例上出错。这也是我在实际项目里更倾向“LLM生成代码、代码驱动建模”方案的原因对制造环节更友好。如果你只是拿来做渲染图或者手板示意那专用模型的多样性更有价值但凡是后面要出工程图代码生成路线的优势会越往后越明显。4.4 部署与性能调优记录在实际部署使用中环境与性能问题同样值得说几句。如果用的开源大模型在本地跑显存占用会非常高建议优先考虑API方式调用或者使用量化后的本地小模型。如果是在企业内部用还要考虑数据保密私有化部署一个小尺寸代码模型7B或14B级别其实够用因为CadQuery代码生成任务的复杂度远低于通用编程小模型完全能顶住。我在内网部署过一个7B模型推理速度明显比调用云端大模型API慢但单条文本生成一段代码通常也在几秒内完全在可接受范围。性能调优上最简单的收益点是控制输出长度提示词里明确“只输出Python代码不要解释”可以省掉大量无用的token不仅加快推理还减少格式解析报错实测推理速度能提升两到三成。另一个是批量生成时把重复的库导入语句和导出语句写在模板里让模型每次只生成核心几何操作段效果很显著。这种小技巧不算什么高深技术但能实打实影响你在生产环境里的使用体验。最后分享一个我自己正在做的扩展尝试把text-to-cad和参数化族表结合。思路是先让LLM根据文本描述生成一个基准模型和一组参数方程再让同一个对话上下文批量生成规格变形。比如“法兰盘外径随压力等级变化螺栓孔数随外径变化”LLM先给出参数关系再按系列生成十几个STEP文件。实测下来效率比手工建模高一到两个数量级但前提是在第一阶段就把参数规则约束清楚否则后期调整很痛苦。另外一个小技巧生成的STEP文件建议必做一次“导入-导出”循环再发给加工方。也就是用FreeCAD或者CAD软件打开什么都不改再重新导出一次STEP。这样能清理掉生成器留下的一些非标准结构很多CAM软件对这类文件的兼容性会好很多。这个习惯帮我避免过多次加工端报错。说句实在话text-to-cad现在已经是够用的起步工具但真正要让它好用靠的还是你自己在工程环节加的约束和检查。多试几个方案找到适合你业务的那条链路比纠结“哪个模型最强”重要得多。
阅读完成 · 觉得有帮助？
