在机械设计和数字制造这个圈子里text-to-CAD 大概是这两年最值得跟的方向。回头看我最早的建模方式画一个法兰盘要在 CAD 软件里点十几下草图、约束、拉伸、打孔、再倒角步骤不复杂但架不住每个新零件都要重复一遍。text-to-CAD 的思路就不一样——它把“从图纸到特征”这层人肉翻译交给机器让人只负责说需求比如“外径 60 的盘体中间一个通孔四角四个 M4 沉头孔”然后直接得到可以继续编辑的模型文件。这篇文章会把它的原理、主流实现路线和一套真实可跑的工作流讲清楚适合做三维建模工具开发的工程师、长期被参数化建模折磨的机械设计师以及玩 3D 打印但每次建模都要查半天文档的朋友。读完之后你至少能自己搭一个“会建模的助手”而不是停留在看论文听概念。1. text-to-CAD 的思路拆解把“看图建模”变成“听写建模”1.1 传统 CAD 建模到底卡在哪传统 CAD 建模的整个操作路径本质上是“人把头脑里的三维意图翻译成二维输入序列”从草图开始画线、加约束、拉伸、旋转、扫描每一步都在告诉软件“我现在要做什么”。这个过程有两个痛点。第一操作和思维之间隔了一层。设计一个支架脑子里想的是“这个板要多厚、哪里该受力、哪里要避让”但手在软件里做的是另一件事画矩形、删线、标尺寸、切特征。每一层操作都在消耗注意力建模速度完全取决于熟练度。熟练工能把手上的动作练成肌肉记忆但代价是大量时间耗在重复劳动上不熟练的人则卡在“知道要什么但不知道点哪里”的困境里。第二知识门槛高。参数化建模不只是会用软件还要理解约束是否过定义、草图是否闭合、特征顺序是否合理。对机械工程师还好对创客、3D 打印玩家、甚至非标设备采购来说想快速拿一个可打印的零件第一步建模就能把你劝退。市面上的建模软件界面越来越复杂功能按钮几百个真正常用的其实就十来个但新用户根本分不清哪些该点、哪些不该点。text-to-CAD 想做的是把这两道坎都挪走。核心思路是用自然语言直接描述需求再由模型把这句话翻译成 CAD 特征序列。注意这里用的词是“翻译”不是“渲染”——它输出的不是一张图而是一组合法的建模步骤这些步骤能驱动 CAD 内核一步步构造出实体模型。1.2 两条实现路线端到端生成 vs 程序化参数建模把“语言”变成“模型”听起来简单但实现方式差别很大。市面上现在基本分成两条路线我分别说一下它们的思路和适用场景。第一条是端到端生成。这类系统直接训练一个神经网络输入文本输出几何体——可能是点云、网格或者更高级一点的 B-Rep 边界表示。它的优点是想象力强能生成一些没有明显参数规则的自由形状比如有机形态的壳体、雕塑类造型。目前这类工作多出现在学术论文里离工程落地还有明显距离。第二条是程序化参数建模。这种路线不直接生成几何而是让语言模型输出一段建模脚本比如 CadQuery、OpenSCAD、FreeCAD Python 脚本然后由脚本引擎执行生成实体。好处是输出的是可读的代码和特征序列改一个尺寸能重新生成而且天然兼容 STEP/STL 的导出链路。对比维度端到端生成程序化参数建模输出形式几何体网格/B-Rep建模脚本/特征序列可编辑性弱强与传统 CAD 兼容低高生成自由形状强弱可验证性较难可通过执行脚本验证当前成熟度研究为主可落地1.3 为什么我推荐先做程序化路线个人观点现阶段做 text-to-CAD 的实际落地程序化参数建模是性价比最高的选择。原因不复杂CAD 模型的核心价值不在“长得像”而在“能制造、能修改、能追溯”。一个生成出来不可编辑的面片在工程师眼里约等于一张效果图而一段能重新执行的 CadQuery 脚本才真正进入了产品迭代的闭环。这不是说端到端生成没有意义。自由曲面、概念造型这类场景端到端确实更有优势。但如果你要做的是非标零件、标准件、机械结构件脚本路线的确定性和可复现性是无价的。所以下面整篇文章的实操部分我会沿着“自然语言 → CAD 脚本 → 实体模型”这条路展开这也是我实测下来最快能跑通的方案。至于端到端生成后面讲原理时也会提到但不会作为主打路径。2. 从表示到模型text-to-CAD 背后的核心技术细节2.1 几何表示为什么 B-Rep 比网格更接近“制造”要理解 text-to-CAD必须先理解 CAD 自己怎么表示几何。市面上的 CAD 文件内部主要用两类表示。网格模型由三角面片拼接而成适合渲染和 3D 打印切片但缺乏面与面的拓扑关系无法精确表示圆柱面、球面这些二次曲面。STL 文件就是典型的网格拿到转换工具里往往会有精度损失。实体的边缘会被拆成无数小三角圆孔变成多边形孔这对注塑模具和精密加工来说不可接受。B-Rep 则不同。它用顶点、边、面、环和它们之间的拓扑关系来描述一个实体曲面可以是精确的解析曲面。SolidWorks、Fusion 360、FreeCAD 等主流 CAD 内核的核心都是 B-Rep 数据结构这也是 STEP 文件能跨软件交换的根本原因。一个在某个软件里建出来的圆柱面导到另一个软件里仍然是精确圆柱面而不是近似的多面体。对 text-to-CAD 来说直接生成 B-Rep 很难因为模型不仅要预测几何位置还要保证所有边、面严格闭合、拓扑一致。这就是为什么多数研究型工作选择生成“命令序列”而不是直接生成面CAD 软件本身也是通过特征命令一步步构造出 B-Rep 的。命令序列天然能保证实体合法只要命令参数没写错生成的实体就是一个可用的实体。2.2 训练数据从哪来十万级“模型-文本”对的背后深度学习的规律就是这样模型能力大概率取决于数据。text-to-CAD 的训练数据不是天上掉下来的公开数据集主要靠三种渠道构建。第一种是逆向标注。从已有的参数化 CAD 模型库出发把模型的特征树翻译成自然语言比如“一个长方体长 40宽 20通孔直径 8 位于中心位置”然后按模板生成描述文本。这种方式能快速得到大量配对数据但描述往往偏模板化缺乏真实人类表达的变化。第二种是合成指令。用规则模板或者另一组语言模型生成多样化的自然语言表达方式覆盖同一个模型的不同说法比如“中间开一个 8 毫米的孔”和“在中心打一个直径为 8 的通孔”其实是同一个意思但文本形态完全不同。提高多样性是为了让模型在推理时能扛住用户千奇百怪的说法。第三种是人工精修。在自动生成的基础上做筛选、纠错补充那些模板表达不了的自由描述。人工精修的成本高但质量也最高往往是数据集中最宝贵的部分。目前公开的 text-to-CAD 数据集规模普遍在十万级“模型-描述”对以上。相比通用自然语言语料这个规模仍然算小所以模型在这种任务上更容易过拟合模板这也是实操中常见“换个说法就翻车”的根源。2.3 模型架构从自回归生成到扩散模型现有模型架构主要沿着两个方向发展。自回归方向最直观把建模脚本当成一段“程序语言”按 token 顺序预测下一个命令。这种思路和代码生成一脉相承许多实现直接基于 Transformer 解码器配合语法约束做采样。优点是可以直接借用代码大模型的预训练知识缺点是生成较长脚本时容易累积误差后面命令对不上前面的状态。扩散模型是另一个方向。扩散在图像生成领域已经是主流现在有人尝试把它引入 CAD但 CAD 的难点在于输出必须是离散、结构化的特征树而不是连续像素。目前能看到的效果更多集中在简单零件上离复杂装配体和自由曲面还有距离。几何生成这类结构化输出本质上比像素生成更难建模。我实测下来对于普通机械零件自回归式的 LLM 配合脚本输出效果远比端到端网络稳定。原因很简单通用代码大模型已经见过大量参数化建模代码它有足够的世界知识去理解“法兰盘”“沉头孔”这些概念只是需要我们去规范它的输出格式。2.4 命令序列可编辑性的源头命令序列这个表示还有一个常被忽略的优点可追溯和可参数化。一段 CadQuery 脚本里“外径 60”对应清晰的一行代码后续要改成 80改一个数字就可以重新生成。这在制造业里太重要了。工程师拿到一个模型第一件事往往不是看它外形对不对而是看特征树——拉伸在哪步、打孔在哪步、倒角参数是多少。能编辑意味着零件可以复用、可以出工程图、可以对接后续 CAM 编程。我在多个项目里都体会过“不可编辑几何”的局限预览阶段看不出问题一进装配就发现干涉没法调只能推倒重来。这也就是为什么我强调做 text-to-CAD 不要跳过“脚本”这一层。直接生成网格也许演示效果好但到车间就会被毙掉。反过来说一旦脚本这条路跑顺后面接参数化设计、批量改型、自动出图都非常自然。3. 从零搭一套可用的 text-to-CAD 工作流CadQuery LLM 实测组合3.1 工具选型CadQuery、OpenSCAD、FreeCAD 脚本怎么选程序化建模的脚本有很多种不是随便选一个都能做好 text-to-CAD。我按自己的实测体验排个序把三个常用工具说清楚。OpenSCAD 的语法偏向 CSG用 union、difference、translate 组合基本体。上手简单但描述方式离“建模思维”比较远。你很难用自然语言流畅地对应到它的函数嵌套让大模型翻译时也容易绕晕。适合纯几何爱好者不太适合做文本到特征的映射。FreeCAD Python 脚本功能最强但 API 太庞杂同一个操作有好几种写法LLM 生成时很容易选择困难导致生成代码错误率高。而且 FreeCAD 的依赖环境偏重脚本运行速度和稳定性也不算理想。CadQuery 反而是最平衡的选择。它用 Workplane 的概念模拟“在哪个平面上画草图、拉伸多高、在哪个面上打孔”代码嵌套深度小读起来几乎和自然语言一一对应。它是基于 Python OCC 内核构建的导出的 STEP 文件精度和兼容性都过关且支持常见的布尔运算、圆角、阵列、扫掠等操作。所以我的建议是pip install cadquery 就能开始没有任何 CAD 软件依赖非常适合做 text-to-CAD 的验证环境。命令行里跑通脚本再可视化看一眼整个闭环很干净。3.2 让大模型“好好听话”提示词里的六个关键约束把 LLM 用作建模引擎最大的坑是它“自由发挥”过头。要让输出稳定可控提示词不能只写一句“帮我建模”必须把边界条件写死。下面这个模板我已经实际跑过可以直接抄走你是一名 CadQuery 建模专家。请根据用户的自然语言描述生成完整可运行的 CadQuery 脚本。 约束 1. 只输出 Python 代码不要任何解释文字。 2. 统一从 cq.Workplane(XY) 开始。 3. 所有尺寸单位是毫米。 4. circle() 传的是半径参数hole() 传的是直径参数不要混用。 5. 每个新特征必须显式指定基准面或面选择例如 faces(Z)。 6. 不要添加用户描述中不存在的倒角、圆角、螺纹或装饰特征。 7. 参数不足时输出一行注释 # MISSING_PARAM 并给出默认值而不是停止。 8. 最终变量命名为 result。 用户描述{用户输入}六个约束分别对应六个实际问题。约束 1 保证输出干净省掉解析成本约束 2 统一坐标系习惯避免每个模型一个方向约束 3 消除单位歧义这是制造业的红线约束 4 专门防半径/直径这个高频错误约束 5 避免特征挂错平面约束 6 杜绝“过设计”。3.3 完整实测案例从一句话到 STEP 文件拿最典型的法兰盘来跑一遍。用户输入是“一个圆形法兰盘外径 60 毫米厚度 8 毫米中心有一个直径 25 毫米的通孔四周均匀分布 6 个直径 5.5 毫米的安装孔孔心所在圆直径为 48 毫米。”按照上面的提示词约束大模型输出的 CadQuery 代码大致如下import cadquery as cq result ( cq.Workplane(XY) .circle(30) # 外径 60circle 使用半径 .extrude(8) # 厚度 8mm .faces(Z) # 选择顶面 .workplane() .hole(25) # 中心通孔hole 使用直径 ) result ( result.faces(Z) .workplane() .polarArray(24, 0, 360, 6) .hole(5.5) )这里有几个关键点要解释清楚。circle(30) 而不是 circle(60)因为 CadQuery 的 circle 接收半径hole(25) 而不是 hole(12.5)因为 hole 接收直径。这两个就是最经典的语义陷阱大模型在没有明确约束时几乎一定会搞混。polarArray(24, 0, 360, 6) 的参数语义是第一个参数是分布圆的半径 24mm第二个是起始角度 0 度第三个是结束角度 360 度第四个是要生成的孔数量 6。这一句等同于数学上的“在半径 24 的圆周上均匀取 6 个点”比手写三角函数可靠得多也不容易出现角度累积误差。执行这段代码后再用一行导出cq.exporters.export(result, flange.step)就能在当前目录拿到一个 flange.step 文件可以直接丢进 FreeCAD、Fusion 360 或者其他支持 STEP 的查看器里检查。到这里一句自然语言已经完成了到工程文件的闭环。整个过程不到十秒。3.4 自动校验闭环别让生成代码直接跑进产线代码能跑和代码“正确地建出了想要的模型”是两回事。我在实操里会加一个三层校验成本很低但能拦掉大部分问题。第一层是语法检查。用 Python 的 ast 模块解析生成的代码语法都过不了直接打回重试。这一步能拦掉漏括号、错误缩进这些低级问题。大模型偶尔会在代码块里夹带解释性文字ast.parse 也会直接报错。import ast def check_syntax(code: str): try: ast.parse(code) return True, 语法 OK except SyntaxError as e: return False, f语法错误: {e}第二层是执行检查。在一个受限的命名空间里执行脚本然后对 result 做合法性检查比如实体是否非空、是否包含有效体积、faces 数量是否合理。CadQuery 的 solid 对象提供了 check() 方法可以返回几何错误列表比肉眼靠谱得多。import math try: ns {cq: cq, math: math} exec(code, ns) solid ns[result].val() errors solid.check() if errors: print(几何检查发现错误:, errors) else: print(几何检查通过) except Exception as e: print(执行失败:, e)第三层是人工或者可视化复审。把生成的 STEP 丢到查看器里或者导出渲染缩略图对照自然语言描述快速核对。自动检查能保证“是个合法实体”但“是不是用户要的那个实体”最终还是要人看一眼。这一步千万别省实测中 LLM 偶尔会生成一个完全合法但和你描述南辕北辙的零件比如把梯形板做成了矩形板因为描述里没说清楚而模型脑补了一个。4. 实测踩坑记录text-to-CAD 最常见的 5 类翻车现场4.1 半径和直径的“宿命之战”这是我在实际测试中遇到最多的问题。CadQuery 的 circle() 接收半径hole() 却接收直径而用户的自然语言习惯几乎都是说直径。“外径 60 的圆”对应 circle(30)“直径 25 的孔”对应 hole(25)。有一次我测试模型生成的代码把中心孔写成了 hole(12.5)理由是“25 除以 2”——这明显是被 circle 的语义带偏了。类似的错误还发生在沉头孔、键槽这些带两个尺寸的特征上。对策只有一个在提示词里把这条规则明确写进去并且在校验脚本里对关键尺寸做一次 boundBox 抽查发现孔的实际尺寸和描述对不上就重新生成。4.2 特征挂错了面拉伸方向与面选择的歧义生成代码第二大类问题出在平面选择上。比如要把通孔打在顶面正确写法是先 faces(Z) 再 workplane()但 LLM 有时候会省略这一步直接把 hole 挂到最初的工作平面上结果孔打在了底面或者侧面甚至跟预想完全不一样。拉伸方向也比较隐蔽。extrude(8) 是沿着当前平面法向挤出如果工作平面选成了 Z 或者 XZ整个零件方向就会乱。我建议在提示词里固定基准面为 XY并且让所有跨越实体表面的特征都显式带 faces(Z)这样至少方向是可控的。4.3 过设计模型自己加的倒角和螺纹通用 LLM 有一个非常固执的习惯觉得“好看”就要加细节。一段描述里明明只说了“一个矩形板四个孔”生成结果却多出 2mm 的圆角和一个螺纹孔。这种自动追加的特征在工程上是致命的倒角会影响装配干涉螺纹会影响后续攻丝工序。我在提示词的约束 6 里专门写了“不要添加不存在的特征”实测能明显降低这种情况但不会完全消失。最好的兜底是人工复审时扫一眼特征树看到多余的特征直接删掉。另一个技巧是让模型先写特征列表再生成代码相当于给它一个“施工计划”计划里没出现的东西就不会被加进代码。4.4 尺寸约束的“自由发挥”把毫米当英寸是灾难另一类高发问题是单位理解。描述里写“板厚 10”模型生成 extrude(10)这没问题但如果用户说“1 英寸厚的板”LLM 可能直接写 extrude(1)也可能写成 25.4 之后又在别处用 1。最危险的是混用上面用毫米下面又用英寸的近似值。我目前的处理方式是在提示词里强制“所有尺寸单位是毫米”同时要求模型在参数不足时输出默认值而不是自行猜测。单位问题一旦流到制造端就是批量报废级别的灾难这条不能妥协。4.5 布尔运算失败与非流形几何CadQuery 里有不少操作依赖布尔运算比如 cut、union、intersect。当两个实体刚好共面、相切或者存在微小间隙时布尔运算会报错或生成非流形几何。这类问题属于几何引擎的常见坑不完全是模型生成的锅。遇到这类问题最有效的排查手段是用 solid.check() 拿到具体的拓扑错误列表或者尝试把切割体偏移一个极小值比如 0.001mm再执行布尔。如果是阵列产生的孔位重叠也容易触发类似问题可以先把孔心距检查一遍再执行。用 polarArray 做阵列时尤其要注意分布圆半径太小导致孔之间打架就会触发这种问题。下面整理成一个速查表方便直接对照现象大概率原因排查/解决手段孔径偏小一半hole 当成半径用了检查 hole 签名改为直径圆盘外径偏大circle 当成直径用了circle() 传半径特征方向错乱基准面选择错误固定 XY 起始面 faces(Z)多出倒角/螺纹LLM 过设计提示词限制特征白名单尺寸整体偏小 25.4 倍英寸/毫米混用强制毫米单位布尔操作异常共面/相切/重叠check() 微小偏移脚本语法报错漏括号/错误缩进ast.parse 预检5. 怎样评估一个 text-to-CAD 结果才算合格质量指标与下一步扩展5.1 别只看“长得像”几何正确与可制造性才是硬指标判断一个 text-to-CAD 结果好不好我建议按两层来。第一层是几何正确性尺寸是否符合描述、特征数量是否对、有没有非流形实体。这一层现在依靠自动校验加人工复核基本能兜住。第二层是可制造性这一层才是真门槛。一个模型几何完全正确但最小壁厚只有 0.3mm注塑直接废一个法兰盘的安装孔离边缘太近压铆时会开裂。当前绝大多数 text-to-CAD 系统都不考虑这些因为训练数据里根本没有制造约束。我给做这个方向的朋友一个很实际的建议在生成流程后面挂一个规则检查器对最小壁厚、孔径、孔边距这些常见制造规则做硬性校验不满足就回炉重试。这比让模型自己“领悟”制造工艺要可靠得多。规则检查器写起来不复杂本质是一组 if 判断加数值比较但能挡住大量流到线下的废品。5.2 从单个零件到参数化族和装配体现在多数 text-to-CAD 演示都停留在单个零件的层面但这个方向真正的价值在参数化族和装配体。比如“一个 M6 的内六角螺栓”只是一个信息而“一个符合 GB/T 5783 的 M6 全螺纹螺栓”才是有生产意义的描述。参数化族一旦建立起来标准件库就有了雏形。进一步一旦模型能生成带参数关系的脚本族改一个主参数相关尺寸自动联动那 text-to-CAD 就不再是建模辅助工具而是整个非标自动化设计的前端入口。再往前一步装配体层面的描述会涉及配合约束像“轴套孔与轴颈间隙 0.05”这对模型的空间推理能力要求更高但也是更值得投入的方向。5.3 我个人实操里的三点体会最后分享几个我自己跑下来的体会不展开太多但都是真金白银换的。第一别指望一个模型解决所有问题。当前最稳的组合是“强约束提示词 CadQuery 自动校验”本质上是用工程手段兜住模型的随机性。等端到端生成真正成熟之前这条路线够用且能落地。第二提示词迭代比换模型重要。我试过不同规模的模型发现把提示词的约束写清楚小模型的可用性提升比直接换大模型带来的提升还明显。花时间打磨提示词模板性价比极高。第三数据闭环比模型结构更值钱。如果是在企业内部做把每一次用户提问、生成结果、人工修正都记录下来形成自己的 text-to-CAD 数据集这个资产的价值会随时间增长比反复调参更持久。我自己现在的做法就是每个翻车案例都归档攒得多了模型会越来越懂你们那一行的黑话。