★ FEATURED ARTICLE 去年年底我在整理工具链清单的时候注意到一个明显的变化AI生成三维模型的工具终于从“生成一张炫酷的图片”进化到了“生成一个能编辑、能出图纸、能进产线的实体”。text-to-cad这个方向就是其中最典型的代表。简单说它就是让你用一句大白话比如“做一个直径40mm、高度60mm、底部带四个通孔的圆柱座”直接得到对应的CAD模型文件而不是一张渲染图。这篇文章我想从原理、路线、实操、踩坑、数据、评估六个角度把这个方向讲透。适合两类人一类是想评估“要不要在公司里搭一套AI辅助设计流程”的工程师另一类是正在做相关工具、卡在生成质量上不去这个阶段的开发者。1. 为什么text-to-cad突然从一个“测试demo”变成了能落地的方向1.1 从“生成图片”到“生成实体”的关键转变过去几年AI生成内容的热度主要集中在图像和文本上原因是这两个领域的数据极其丰富而且评估“好不好看”“通不通顺”相对容易。但CAD模型不一样它是一个严密、精确、带约束的几何表达差0.1毫米在装配时就是装不进去。所以早期没有人认为大语言模型能直接参与建模——因为它连“直径”和“半径”都经常分不清。这个局面从2023年底开始松动。业界逐渐确认了一条可行路径LLM本身不直接生成几何而是生成能构造几何的程序。也就是说让模型写CadQuery、OpenSCAD、FreeCAD脚本再在本地执行脚本得到真正的B-rep实体模型。模型的“语文水平”虽然不足以理解拓扑但足以生成结构规整的代码CAD软件负责把代码变成精确的几何。这一层分工正好避开了LLM在数值精度上的短板。我拿自己最近一个实际测试举例。输入是“M8螺栓长度40mm头部直径13mm六角头对边10mm”一个中等水平的CadQuery脚本大约150行。如果让GPT-4级别的模型直接输出STEP文件里的几何数据基本不可能但让它输出CadQuery代码第一次就有较高的概率能跑通。这类结果放在两年前是做不到的。1.2 为什么是“代码派”而不是“图像派”胜出还有一种路线是用扩散模型直接生成体素场或者三角网格看起来更“AI”但实际落地时问题很多。最大问题是网格模型不能参数化——你生成一个法兰盘想改螺栓孔的中心距就得重新生成一次而不是拖一下尺寸标注。工业场景里没有参数化约束的模型基本是废纸。代码生成派还有一个隐形优势它的中间产物是人可读、可改、可审查的代码。如果模型生成的几何不对工程师可以打开脚本检查是尺寸算错了还是坐标方向搞反了三分钟就能定位。这种“可解释性”在工程环境里极其重要因为没有人敢把产线上的模型直接交给一个不可解释的黑盒。当然“代码派”的思路也不是没有门槛最大的门槛在后面会详细说LLM生成的代码经常是语法正确但几何错误需要一套校验和反馈机制来兜底。1.3 这一个方向的实用价值到底在哪text-to-cad对普通工程师的实际价值不是“替代设计师”而是把重复性标准化零件的建模时间从半小时压缩到一分钟。比如非标自动化里大量使用的垫片、法兰、支架、轴承座它们结构相似但尺寸各异过去要重新建模或者拉伸改图现在可以直接用文字描述生成初版再在CAD里做细节修改。它更像一个熟练的“建模助理”而不是“设计大脑”。对软件开发者的价值则是另一个维度text-to-cad提供了一个把自然语言转换成“可执行工业操作”的新接口。它不再是娱乐级的prompt工程而是直接对接制造数据流的起点后续可以连仿真、连CAM编程、连3D打印切片。2. 两条实现路线我为什么先选“代码生成派”2.1 路线ALLM直接写程序化建模脚本程序化建模脚本的代表是CadQuery和OpenSCAD。CadQuery基于OpenCASCADE几何内核生成的模型是精确的边界表示实体可以直接导出STEP、STL、SVG也能在FreeCAD里继续编辑。OpenSCAD更像纯代码建模擅长布尔运算但不太适合倒角、放样这类复杂操作。这条路线的核心流程是用户输入自然语言描述 → LLM生成脚本 → 脚本在本地或云端执行 → 失败则报错信息回传给LLM再次生成 → 成功则渲染多视角预览图。它的优点是精度高、可参数化、可审查。缺点是生成成功率不够稳定尤其当描述里包含多个特征组合时容易漏掉细节。2.2 路线B扩散模型直接生成本体网格这条路线的代表是点云扩散和网格扩散模型比如从文本生成点云、再从点云重建网格的两段式方案。我看到的一些demo确实能在几秒内产生一个看起来形状很对的零件比如齿轮、轮毂、瓶体。但它的致命伤是几何精度差。扩散模型的生成空间是连续的数值场天生偏向“大概齐”而不是“精确到0.1毫米”。另外它生成的是离散网格没有特征树、没有约束、没有参数导入CAD软件后必须做逆向建模才能继续使用。对于工业场景这一步的时间成本往往比从头建模还高。2.3 两条路线的对比到底差在哪维度代码生成派CadQuery等网格生成派扩散模型输出格式参数化脚本可导出精确B-rep实体三角网格需要逆向建模精度完全受脚本控制可精确到微米级受网络分辨率限制网格粗糙可编辑性强改参数即可再生弱生成后基本锁死可解释性高代码可审查可调试低黑盒输出失败模式执行报错或几何错乱可反馈修复生成形状不合法不可修复落地成本需要写校验逻辑需要大量算力训练和推理这个表不是想说明网格生成一无是处而是说在“拿到能用的CAD模型”这个目标下代码生成派目前的性价比明显更高。网格生成更适合做概念造型、游戏资产这类对精度不敏感的领域。2.4 我选CadQuery而不是OpenSCAD的原因CadQuery的文档里有一句话我很认同它让CAD建模像写代码一样可以“版本管理”。实际上选择CadQuery还有一个更实际的理由——它生成的实体可以直接用cq.exporters.export导出成STEP文件而STEP是工业交换的标准格式任何主流CAD软件都能打开。OpenSCAD虽然语法更简单但它在处理圆角、倒角、放样这些工业设计高频操作时非常吃力。你要做一个带圆角过渡的支架CadQuery几行就搞定OpenSCAD可能得折腾半天CSG。text-to-cad的面向对象是“能直接用的零件”不是“抽象雕塑”所以我选CadQuery。3. 从零搭一版可用的text-to-cadLLM CadQuery 渲染校验3.1 整体pipeline设计不是“一次性生成”而是“反馈循环”很多人第一次做text-to-cad以为就是把用户的话丢给LLM、把返回的代码拿去跑就完了。实际跑过之后会发现一次成功率可能只有一半不到。所以真正可用的系统必须是一个闭环大致分四步意图解析把用户描述拆解成结构化的建模参数比如主体形状、尺寸、特征列表、阵列方式。代码生成把结构化参数组装成CadQuery脚本。静态校验检查脚本能否执行几何是否合法比如布尔运算是否产生非流形实体。视觉反馈渲染多视角图片让用户确认或者用另一个视觉模型对比描述与渲染图是否一致不一致则把原因反馈给生成器重试。后两步是关键。没有反馈机制的text-to-cad体验就像“掷骰子”——你不知道这次生成的模型对不对只能自己打开CAD目检。3.2 Prompt怎么设计才不“翻车”我在反复测试中沉淀了一套提示词结构分享出来供参考。不要在提示词里只写一句“生成一个法兰”而是给出分层的结构化指令角色设定明确告诉模型“你是一个精通CadQuery的机械设计工程师”。单位说明“所有尺寸默认毫米如未指定按公制默认值处理”。规则约束“使用box、cylinder、hole等基本操作优先使用Workplane的faces选择器而不是全局坐标必须处理切穿与盲孔的区别”。输出要求“只输出CadQuery代码不要解释不要用markdown代码块包裹”。兜底要求“如果描述中有歧义选择最保守的工业默认值并在代码注释中标记”。为什么不厌其烦地写这些因为模型对“语言歧义”极其敏感。“在顶面开四个孔”这句话不同模型会理解成“孔间距均布”或“集中在中心附近”差别巨大。只有把规则提前注入生成质量才会稳定。我还试过更激进的方案把CadQuery的官方文档前几十页作为上下文塞进prompt效果有提升但token开销太大。性价比最高的方案是总结出二十条“常见建模规则”每次固定附在提示词末尾。3.3 校验层让程序先“跑起来”再“看形状”校验分两个层面。第一层是程序层面的校验用subprocess执行生成的脚本如果退出码非0捕获stderr截取报错信息直接拼回prompt让模型修正。这一层能解决80%的问题因为LLM写代码最常见的错误就是语法小错、变量名拼写错、API调用参数不对。第二层是几何层面的校验。脚本跑通不代表几何正确模型完全可能生成一个flange但漏了螺栓孔。这时候需要用CadQuery的内置工具做包围盒检查尺寸是否合理、实体体积检查是否为零、面数检查是否符合特征的预期数量。我甚至试过用cq.occ_impl.shapes的BoundingBox来判断模型长宽高是否落在预期范围内。如果几何参数和描述不一致就把差值反馈给LLM比如“描述直径应为50生成实体包围盒最大边为38请检查缩放与单位”。实测下来这种数值级反馈特别有效模型通常能立刻意识到自己算错了。3.4 一个最小可复现的流程示例不需要搭建复杂平台只要你有Python环境和OpenAI兼容接口就能复现这个流程。核心逻辑不依赖具体的模型厂商import subprocess import json import openai def generate_cad(description: str) - str: # 1. 组装prompt prompt build_prompt(description) # 2. 调LLM生成CadQuery代码 response openai.chat.completions.create( modelyour-llm-model, messages[{role: system, content: SYSTEM_PROMPT}, {role: user, content: prompt}], temperature0.2 ) code response.choices[0].message.content # 3. 写文件并执行 with open(temp_cad.py, w) as f: f.write(code) result subprocess.run([python, temp_cad.py], capture_outputTrue, textTrue) # 4. 反馈循环如果有报错就回传修 retries 0 while result.returncode ! 0 and retries 3: fix_prompt f脚本报错{result.stderr[:2000]}请修正后重新生成完整代码 response openai.chat.completions.create(...) code response.choices[0].message.content ... retries 1 return code这个例子把关键流程压到了十几个方法调用实际工程里还要加并发、缓存、日志、安全沙箱但骨架就是这个。注意temperature一定要调低0.2以下因为建模不是创意写作不需要随机性。温度太高会出现“同一个描述两次生成完全不同的结构”的情况定位问题时会让你怀疑人生。4. 跑通demo后我实际踩过的坑你可能也会踩4.1 尺寸幻觉说好40mm出来是40英寸这是文本生成CAD最典型的坑而且非常隐蔽。脚本能跑通、渲染图看着也对但导出STEP后用测量工具一看尺寸差25倍以上。原因有两层一是模型在训练数据里见过大量Mixed Units的代码英寸和毫米混用的场景太多它分不清默认值二是自然语言里的数字本身没有单位感“40mm”和“40”对它来说差别不大。解决办法不要指望模型自己判断单位而是设计一层“单位归一化”。在prompt里强制要求“所有数值必须显式包含单位并在脚本开头设置cq.Workplane(XY).units(mm)”同时在后处理中用BoundingBox校验长宽高如果最大尺寸与预期偏差超过2%直接判定为失败并反馈。这个简单的后验检查能拦截掉大部分尺寸幻觉。4.2 特征顺序与拓扑命名先倒角还是先打孔结果完全不同CAD建模和写文章一样有严格的“先后逻辑”。同一个零件是先倒角再打孔还是先打孔再倒角得到的特征顺序和面编号完全不同后续编辑时极易出错。CadQuery底层用OpenCASCADE有一个著名的“拓扑命名问题”对实体做一次布尔运算后面的ID会变如果你在代码里写死了“选择faces(Z)这个面”下一轮操作可能会选到完全不同的面。LLM并不理解这种底层机制它经常生成这样的代码先倒角然后按名字引用一个已经被倒角改变的面执行时报错或生成错误几何。我让模型遵守一条铁律先参考面上的主要特征再处理边上的细节倒角、圆角涉及引用面时尽量用方位选择器如faces(Z[1])而不是整表索引。这个规则写进prompt后生成成功率有明显提升。4.3 自然语言的“模糊地带”盲孔、通孔、居中、等距人类语言在描述空间关系时极其模糊。你让同事“开四个孔”他大概率会按均布来做但让LLM理解“均布”两个字它是真不知道自己省略了什么。我遇到过一个真实案例用户要求“在底面钻两个Φ6孔”但没说通孔还是盲孔也没说孔间距。模型默认生成了两个通孔位置随意放在了底面中心附近。原因不是模型笨而是它有“最省事倾向”——通孔比盲孔代码更简单中心摆放比算边距简单。模糊输入时它自动选择了低成本实现。解决办法不要给模型模糊权限而是让它“必须问”。在prompt里加一条规则如果描述中缺少影响几何的关键参数孔深、孔距、是否穿透、基准位置生成代码前先在注释里列出你的默认假设。这样即使假设错了用户也能一眼发现而不是对着渲染图迷惑。4.4 几何自相交与“看起来对、实际坏掉”的实体还有一种失败模式是脚本成功执行、渲染也正常但导出的实体是“破”的——存在自相交面、非流形边、内嵌实体。这类问题肉眼很难发现但后续做有限元或者切片时会直接爆炸。CadQuery本身不会阻止你生成退化几何但OpenCASCADE的检查器可以发现它。我在校验层里加了一行from OCP.GProp import GProp_GProps from OCP.BRepGProp import BRepGProp用BRepGProp计算体积和质心再用BRepCheck_Analyzer做合法性检查。如果体积异常小或者检查器返回错误就判定生成失败。这一步在初期可以不做但凡是打算用于制造的流程必须加。5. 数据是真正的护城河合成数据管线怎么搭5.1 为什么数据比模型更重要很多人以为text-to-cad的核心是找到一个大模型实测下来不是。大模型本身已经具备不错的代码生成能力真正的瓶颈在于它不了解CAD构造序列的语义。你让GPT-4写“一个CadQuery脚本生成轴承座”它可能写得出来但如果你需要它理解“构造历史序列”——先拉伸基座、再在基座上切槽、再阵列孔并把这个序列和自然语言对应起来零样本表现就不稳定了。要让模型稳定输出结构正确的CAD代码需要大量“文本-代码”配对数据。这种数据在互联网上极少因为机械工程师很少会把自己的CAD脚本配上详细的自然语言注释发到GitHub上。这就催生了合成数据管线。5.2 Text2CAD的思路用“构造历史”而不是“最终形状”当标签我参考了公开研究里的一种做法核心是把CAD模型的组织方式从“结果文件”换成“构造历史”。一个STEP文件只记录最终实体而一个构造历史文件记录了“先画草图→拉伸→打孔→阵列”的每一步。让模型学习后者它才能真正理解特征之间的关系。具体操作是写一批参数化模板比如法兰盘、支撑脚、齿轮座每个模板包含几何代码和参数范围随机撒参数生成大量具体实例同时用规则模板生成对应的自然语言描述。比如“直径80mm的法兰盘外圈6个Φ10孔呈60度分布”这种句子可以通过参数填充自动产出。这样生成的数据有一个好处文本和代码严格对齐不会出现“描述了4个孔但代码只画了3个”的问题。这种可控合成数据比海量爬虫数据更适合训练text-to-cad模型。5.3 对普通团队的建议先别训练先“检索增强”如果你不是专门做算法的团队我建议不要直接跳到模型训练这一步。先用合成数据搭一个“检索增强生成”管线把常见的参数化CadQuery脚本入库用户输入描述时先做语义检索找到最相近的模板再用LLM填充参数、修改特征。这样做的好处是模板控制了代码结构LLM被限制在“填参数微调”的范围内出错概率大幅降低。质量可控每次生成的结果都基于一个已验证可用的模板。沉淀快库里的模板每增加一个系统能力就提升一块。我目前内部测试的版本就是这么做的。等于说不是让LLM“无中生有”而是让它当一个“在模板库中搜索并微调”的中间层效果稳定得多。5.4 数据加工中的几个小细节合成数据不是“生成越多越好”而是要注意几个细节一是描述方式的多样性。同一个零件可以描述成“做一个50x50x10的方板”也可以描述成“底部是10mm厚的方形底座”还可以描述成“一个边长50的正方形板子厚度1厘米”。如果语料里只有一种表达方式模型在实际使用时遇到近义说法就会懵。二是负样本的收集。不要只放“正确的”代码也要存一些“常见的错误写法及其修正过程”。比如“如果用户说Φ8孔但没写穿还是不穿默认生成穿通孔”这种决策规则可以作为上下文示例放进prompt让模型学会处理模糊需求。三是尺寸范围的覆盖率。合成数据要保证长尾分布。不要只生成整数尺寸要为3mm和100mm两个极端尺寸都生成样本否则模型在极端尺寸上的表现会明显退化。6. 怎么评估“好不好”几何正确性之外还要看什么6.1 可执行率不是一切第一版评估指标我用的“脚本可执行率”就是看生成的代码能不能跑通。结果发现这个指标虚高得离谱——脚本跑通很容易但很多跑通的代码生成的是完全错误的形状。比如描述说“L形支架”脚本跑了输出却是一个平板。所以我又加了两层评估指标。第一层是几何属性对齐度从生成的实体上提取包围盒尺寸、孔数量、特征数量与文本中提到的属性进行比对。第二层是视觉印象对齐度渲染多视角图让标注员或者视觉语言模型判断“这个形状像不像描述里的东西”。三层指标叠起来才能勉强反映系统真实质量。6.2 一套可以执行的评估维度我建议团队在搭建text-to-cad系统时从这六个维度建立评测集维度评测方式通过标准可执行性脚本执行是否成功成功率≥95%尺寸正确性包围盒与关键尺寸匹配比例误差≤5%特征完整性孔、槽、倒角等特征数量是否一致完全一致空间关系正确性孔是否位于规定位置位置偏差≤2mm参数可修改性修改代码数值是否按预期变化每次正确用户主观可用性工程师是否愿意用该模型作为起点可用率≥70%这个评测集最难的其实是“空间关系正确性”因为涉及相对位置判断单靠LLM文本很难评估必须依赖实体的几何分析。我目前的做法是解析CadQuery的特征树提取特征位置再和用户意图做映射比较。6.3 现阶段的上限与边界整个方向虽然在进步但必须说清楚它的上限它现在还做不到“从一句话生成精密装配体或自由曲面造型”。复杂曲面设计或者涉及大量装配关系的机构设计目前的表现都不行。真正适合的区间是标准化零件、简单结构件、工装夹具的快速生成。另外安全与合规也值得关注。生成的CAD模型如果直接用于制造必须有尺寸合法性和材质可行性检查。不要让一个存在自相交的实体直接进CNC加工那既浪费材料又可能损坏刀具。6.4 我看到的下一阶段演进再往后走我判断有三个方向会快速成熟。第一个是多模态输入不只有文字还能用草图辅助描述——这其实是“草图文本模型”的特征交叉第二个是与传统约束求解器深度融合LLM负责解析意图、分配参数真正的几何生成交给成熟的DCM几何约束引擎第三个是“生成-仿真-迭代”闭环生成模型后马上跑一轮静力分析不达标就自动调整参数那时text-to-cad就不是建模工具了而是一个小型设计工程师。我自己的下一步计划是在现有管线里接入拓扑优化让用户在文本里写“重量减轻30%”系统生成形态后直接做减材优化。这才是text-to-cad的深水区但很值得做。最后分享一个实战小技巧我在所有prompt末尾都会加一句“生成代码后在脚本最后用注释写出一段Markdown表格列出所有关键参数名和数值”。这个习惯看起来无关紧要实际帮了我大忙——因为后续无论是人工检查还是写反馈循环都需要快速定位一个参数在代码里的位置。没有这个表你会在20行代码里翻半天“那个孔直径到底对应哪个变量”。有了它调试效率提升一个量级。按这个思路去搭你很快就能跑出一版能用的text-to-cad系统然后你就会发现真正的挑战不是模型而是你对自己的需求描述得够不够清楚——这一点AI替你解决不了。
阅读完成 · 觉得有帮助？
