★ FEATURED ARTICLE text-to-cad 是最近 CAD 圈子里讨论得最凶的方向之一。说白了就是输入一句类似“一个直径30mm、高50mm的圆柱顶部掏一个直径10mm的通孔”的自然语言系统直接给你吐出一个能下到 SolidWorks 里继续改的可编辑模型。这个方向看起来像“AI 画画”但真正做过的人会告诉你它比文生图难得多——因为 CAD 模型不是像素它必须满足几何约束、拓扑闭合、可制造性还得保留完整的特征历史。这篇文章我想基于自己跑通 text-to-cad 全流程的经验把这个方向从原理到落地拆开讲一遍。不搞玄学只讲实际操作为什么业界普遍选 CSG 或特征树做中间表示训练数据到底怎么洗LLM 抽参数和程序化建模怎么配合以及我在实操中踩过的坑。适合机械工程师、3D 打印玩家、CAD 二次开发人员以及那些想给公司内部做“文字建模型”工具的 LLM 应用工程师。1. 整体设计思路text-to-cad 到底在解决什么1.1 传统建模的痛点与 AI 化机会先聊一个最基础的问题传统 CAD 建模为什么难不是因为画线难而是因为“想清楚怎么画”难。一个稍微正规一点的机械零件建模步骤往往是先建基准面、画草图、加约束、拉伸、再倒角、再打孔、阵列……步骤一多特征树就成了一棵逻辑树哪个特征依赖哪个面、哪个尺寸由哪个公式驱动全都要工程师在脑子里维护。text-to-cad 想做的是把这棵逻辑树从“工程师脑子里”搬到“自然语言里”。用户只需要说出最终要什么系统负责把这棵特征树生成出来。这个思路本身并不新鲜CAD 行业早就有一堆“宏录制 参数修改”的玩法真正的新变量是大语言模型把自然语言到结构化参数的映射能力做到了可用程度。所以我把 text-to-cad 理解成三个子问题第一怎么从文本里准确抽取出几何参数第二用什么中间格式表示一个可编辑的 CAD 模型第三怎么保证生成结果在几何上是合法、可继续编辑的。三个问题缺一个系统就是玩具。1.2 三条技术路线的选择与对比我拆过市面上主流的几类实现方案大致归成三条路线。第一类是 DeepCAD 那套做法用 Seq2Seq 模型直接输出 CSG 操作序列本质是让模型学会“画图的步骤”第二类是最近很多工具在用的 LLM 参数化 API 路线先让大模型把文字抽成结构化 JSON再交给 CadQuery、OpenSCAD 这类程序化建模库去执行第三类是用 3D 扩散模型或者 NeRF 先出体素、点云再逆向成 CAD 曲面。三条路线的差异非常明显。CSG 序列适合训练因为操作序列天然就是 token 序列借鉴 NLP 那套训练方法很顺但生成出来的模型往往是一坨“能看不能用”的布尔结果特征树语义不明显回到传统 CAD 里很难再编辑。LLM API 路线可控性最强参数、约束、命名全在掌握里缺点是上限取决于 API 能表达的特征类型复杂曲面基本没戏。扩散模型路线生成的几何自由度高但转成 B-rep 特征树这一步目前没有稳定解法工业落地还早。我自己的判断是短期内真正能落到生产环境的必然是第二条路线。原因很简单——工程师要的不是“一个像螺栓的网格”而是“一个我还能改直径的螺栓特征树”。这条路线虽然听起来没有端到端模型炫酷但它把不擅长的部分几何生成交给经过验证的程序化方法把擅长的部分语义理解、参数抽取交给 LLM分工合理。1.3 为什么“可编辑性”是 text-to-cad 的核心指标我见过很多 demo 都犯一个毛病只展示了“输入一句话输出一个模型”但那个模型是看着像让你点开特征树就露馅——全是布尔合并没有特征名称没有草图约束。这种模型拿去做 3D 打印可能够用但拿去出工程图、做有限元、上 CAM 加工基本废了。真正的 CAD 工作流要求模型必须能回溯你要把孔直径从 10mm 改成 12mm不能让工程师从头再画一遍。这意味着 text-to-cad 的输出必须携带完整的建模过程而不是最终几何。CSG 树和 B-rep 特征树都能携带这个过程但特征树更接近工业标准因为它对应的是拉伸、旋转、倒角这些真实 CAD 特征而不是抽象几何布尔运算。这个认知会影响整个系统设计。如果你认准了“可编辑”是核心那么你在做中间表示、训练数据、模型评估时都会优先考虑特征语义完整性而不是几何相似度。你评估一个生成结果好不好不应该只看 IoU 或者 Chamfer Distance而应该看特征树回放是否成功、参数覆盖率有多高。2. 核心技术拆解文本到模型的关键环节2.1 文本理解尺寸抽取是第一个拦路虎很多刚接触 text-to-cad 的人以为最难的是几何生成实际跑起来才发现文本理解这块的坑一点不少。自然语言里描述尺寸的方式五花八门“直径30”、“外径30内径20”、“厚5个毫米”、“比前面那个粗一点”、“螺栓孔距中心40”。前几种是绝对尺寸模型抽起来相对容易后面两种是相对关系需要结合上下文才能确定。我自己的做法是给 LLM 设计一套严格的输出 Schema要求它把文本里的信息拆成主题、尺寸、相对约束三个字段。比如“一个直径30mm、高50mm的圆柱顶部带一个直径10mm的通孔”模型要输出一个 JSON里面包括主体尺寸、孔的位置顶部中心、孔轴线方向与圆柱同轴。这中间最关键的坑是单位——LLM 容易“自由发挥”你让它输出尺寸数值它可能不按文本单位走直接给你输出英制或者无单位数。所以我在 prompt 里显式加了规则所有尺寸统一转成毫米且必须落在合理区间内。比如小于 0.1mm 或大于 1000mm 的尺寸一律标记为异常交给后续校验模块处理。另外一个技巧是让模型输出“尺寸来源”也就是把原句里的尺寸文本一起带出来方便出问题时排查是哪一步抽取错了。2.2 中间表示为什么大家都选 CSG 和特征树中间表示是整个 text-to-cad 系统的命门。拿 CSG构造实体几何来说它的核心思想是用布尔运算把简单几何体组合成复杂形状比如“圆柱 A 和方块 B 合并再减去圆柱 C”。CSG 的好处是表达极其简洁一个模型就是一个表达式树序列化之后就是 token 序列非常适合用语言模型来生成。DeepCAD 数据集就是这么干的。他们把模型转成 CSG 操作序列每个操作是一个 token整棵树拍平成一个句子然后用类似机器翻译的模型去训练。这个思路的优点是把三维几何生成变成了文本生成训练框架完全是现成的 NLP 框架缺点也很明显模型倾向于生成“几何好看但参数不可解释”的序列而且 CSG 表达范围和真实 CAD 特征之间存在鸿沟。更贴近工程的是 B-rep 特征树也就是真实 CAD 软件里的特征历史。特征树的节点是拉伸、旋转、倒角、阵列这些语义化特征每条边上带参数和引用关系。用特征树做中间表示下游可编辑性最好但表示复杂度明显上升训练序列也长得多。目前工业界的折中方案是用 LLM 做高层规划——决定先生哪个基体、再挖哪个孔、最后怎么倒角然后把具体参数填入模板特征树。这样既保住了灵活性又把“特征级合法性”交给代码去保证。2.3 训练数据准备干净比多更重要很多做 text-to-cad 的团队一开始都卡在数据上。市面上可用的公开数据集主流是 DeepCAD 的 10 万级模型、Fusion 360 Gallery 的带特征历史模型、以及 ABC 数据集。但直接用原始数据训练效果会非常糟糕。原因是我踩过的坑数据里混了一堆退化模型——零体积实体、缝隙重叠、法向翻转、布尔失败的残留面片。数据清洗至少要过三关。第一关是几何合法性检查用 OCCT 或者 CadQuery 的检查函数把模型重新生成一遍凡是失败的直接删掉第二关是参数合理性检查尺寸太小、太大、比例过于夸张的模型对训练没有帮助反而会教坏模型第三关是相似去重不然模型会死记训练集里的“标准零件”泛化能力极差。数据增强也有讲究。三维模型可以旋转、平移、缩放但不能随便镜像——镜像会改变螺纹旋向、孔位左手右手规则很多机械零件是对称敏感型的。我自己实测下来最有效的数据增强不是几何变换而是“描述增强”同一个模型写 5 种不同的文字描述让模型学会处理同义表达这个对 text-to-cad 语义理解能力的提升比几何变换明显得多。2.4 几何验证生成完必须过一遍合法性检查我见过不少人训练完模型直接输出结果不做任何几何校验然后对着 3D 预览夸效果。这是大忌。CAD 模型不像图片像素多点少点没关系几何模型一旦有破面、反转法向、非流形边后续任何一步——切片、网格、出工程图——都会崩给你看。所以我在系统里固定加了一个几何验证网关所有生成的模型在交付前必须通过三项检查体量检查模型必须是闭合实体体积大于阈值、边界检查所有面是流形边界的子集无非流形边、布尔合法性检查如果结果里有布尔操作必须保证操作对象有正确的相交/相离关系。这些检查用 CadQuery 的is_valid()或者 OCCT 底层 API 都能做不需要自己造轮子。3. 实操过程5 分钟搭一个能跑的简化版 text-to-cad3.1 技术选型与系统骨架如果你也想自己搭一个简化版我建议不要一上来就训练模型先做一个“LLM CadQuery”的压缩版闭环把整个流程跑通再谈优化。技术栈我选的是 Python CadQuery 任意一个支持 function calling 的 LLM API。CadQuery 是 OpenCASCADE 的 Python 封装能创建带特征树语义的 STEP 文件完全符合我们前面说的“可编辑性”原则。系统骨架一共四层输入层接自然语言文本解析层用 LLM 把文本转成结构化 JSON执行层用 CadQuery 按 JSON 参数建模校验层做几何合法性检查。这个架构看起来很朴素但跑通以后你想把中间某层换成模型生成的 CSG 序列甚至扩散模型都不用动其他层。3.2 LLM Prompt 模板与参数抽取解析层是整个链路里最需要调的部分。我试过直接让 LLM 输出 CadQuery 代码效果很差——模型会生成不存在的 API 参数、忘记单位转换、偶尔自己加一些“设计意图”。后来改成让模型先输出 JSON 再程序化执行稳定性上来了一个量级。我的 prompt 里会包含四件事任务说明把描述转成建模参数、输出 Schema用 JSON Schema 严格定义字段、约束规则单位统一、尺寸范围、布尔操作的对象关系、示例few-shot 给 2~3 个典型例子。示例尤其重要我用过没有示例的版本模型经常把“顶部带孔”理解成“侧面带孔”给一个示例后这类错误基本消失。3.3 CadQuery 执行与 STEP 导出拿到结构化 JSON 之后执行层就是一个累加过程。我们以“直径 30mm、高 50mm 的圆柱顶部带一个直径 10mm 通孔”为例CadQuery 代码非常直观。先建圆柱基体再在顶面中心打垂直通孔最后导出 STEP 给下游工具用。这个过程不需要任何“生成式模型”参与参数是对的结果天然合法。整个链路跑起来以后我发现实测效果最不稳定的环节反而不是建模而是 LLM 输出的 JSON 偶尔带额外字段、嵌套层级对不上 Schema。后来我加了个兜底用 JSON Schema 校验器先验一遍不合格就带着校验错误返回给 LLM 让它重新生成实测成功率明显提升。3.4 从单个零件到简单装配体的扩充跑通单个零件之后很自然会想支持装配体。这个坑我建议你谨慎踩单个零件里各个特征共享同一个坐标系位置关系天然一致装配体里每个零件有自己的坐标系LLM 必须正确处理“在另一个零件侧面打孔”这种跨零件引用参数抽取复杂度直接翻倍。我的经验是先做“零件库 放置规则”方案而不是让模型直接生成装配结构。预先建模一批标准件板、轴、座、法兰让模型抽取“放哪个、放哪、怎么对齐”的规则再用代码完成装配约束。这样做的好处是生成结果稳定可控坏处是表达范围有限但作为工具完全够用。4. 常见问题与排查技巧实录4.1 几何生成类问题布尔运算失败是我遇到最多的一个问题典型场景是“圆柱和方块相交想挖出圆孔”结果报错。原因是两个体只是表面相切或者相交深度为 0OCCT 在这种边界条件下布尔运算经常不稳定。解决办法是在关键相交区域加 0.01mm 的余量让布尔操作对象有明确实体内核。这个技巧一开始看起来不优雅但在工程里非常常用。离散步长也是常见问题。CadQuery 默认的圆面离散精度比较低导出 STEP 后转到 SolidWorks 里看圆都不够圆。这不是错误是把 CAM 和仿真前要先处理一下。我一般会统一设置分段数参数保证所有圆弧面在 1mm 弧长下有至少 32 段拟合这样后续加工不会出问题。4.2 LLM 抽取类问题尺寸混淆和幻觉是 LLM 的通病尤其当文本里含有“大约”“左右”这类模糊词时模型会把“50 左右”直接输出成 50丢了不确定性。我后来在 Schema 里加了一个tolerance字段要求模型对模糊尺寸显式输出公差范围没有歧义的输出 0后续建出来的模型质量好很多。另外发现一个规律LLM 在长描述里倾向于“过度设计”。用户只说“一个带孔的板”模型会自作主张开 4 个孔、加倒角、加螺纹。我加了一条 prompt 规则——只生成文本里明确提到的特征未提及的默认不添加。加了这条之后用户预期管理和模型可控性都好了不少这也是我强烈建议你加的一条规则。4.3 数据与验证类问题如果你走到训练模型那一步还有一个隐藏坑训练序列长度。CSG 展开后的 token 序列动辄几百上千个普通 seq2seq 模型在这个长度上效果衰减严重而且训练时间猛增。我当时的做法是把模型按“基体生成”和“特征添加”两段处理先预测先做什么再逐步添加后续特征把长序列切成短序列效果和数据效率都更好。几何校验阶段的另一个经验是不要相信模型自己输出的“validTrue”字段。模型永远不知道自己几何上是不是对的它只是从分布里采样了一个序列。所有合法性判断必须交给独立几何内核去验证这是我踩过几次坑之后得到的硬教训。4.4 一些提效小技巧最后分享几个让我效率提升明显的小技巧。第一给 LLM 喂 2~3 个同类型零件示例作为 few-shot比单独调 prompt 有用得多如果你有“历史上建过的零件是对的”这种数据一定用起来。第二CAD 参数 Schema 要和工程规范绑定螺纹、孔位、倒角尽量引用标准件库防止模型输出一个“非标螺纹规格”让你没法加工。第三生成结果不要直接覆盖源文件我习惯把所有模型导出成带元数据的 STEP 文件原始文本和参数 JSON 作为用户属性嵌入进去以后追溯问题时非常方便。text-to-cad 这个方向现在远没到成熟期但它的路子已经很清楚——把语义理解交给大模型把几何生成交给程序化内核把合法性校验交给几何引擎各干各的脏活。按照这条路走下来哪怕是个简化版本也已经可以实打实地帮人省时间拿它去替代传统建模工作流还早但作为草稿生成器它已经够好用了。
阅读完成 · 觉得有帮助？
