绘图窗口里密密麻麻的特征树、复制的草图、翻来覆去的约束报错这是每个CAD使用者都绕不开的日常。尤其是做机械结构或者产品前期方案的时候从脑海里一个模糊的想法到屏幕上出现一个能编辑、能出图的模型中间隔着大量重复操作。所以当我第一次接触 text-to-cad 这个概念时第一反应是这玩意儿终于有人认真做了。text-to-cad直白说就是输入一段自然语言描述让模型自动生成对应的CAD模型或者更准确一点自动生成一段能还原出这个模型的建模操作序列。它想解决的不是“画得快一点”的问题而是把“设计意图从人脑传递到模型”这条链路直接压缩掉。这篇文章我会围绕这个方向聊一聊它背后的技术难点、主流实现思路、我在实际复现中踩过的坑以及我对后续落地形态的一些判断。如果你是做CAD二次开发、AIGC应用落地或者单纯好奇“AI建模到底走到哪一步了”的工程师这篇内容应该能给你一些参考。1. 为什么 text-to-cad 值得花时间研究1.1 建模的最后一公里不是工具问题而是意图传输问题我先说一个反直觉的观察CAD软件本身的功能早就足够强大了强大到很多用户只用了不到百分之十。真正的瓶颈在于用户要把自己脑子里的三维结构“翻译”成软件能理解的操作步骤——画哪个平面、拉多长、切多深、倒多大的角。这个过程高度依赖经验而且每一步操作都会固化到特征树里改一处往往牵动全局。text-to-cad 做的事情本质上是把这段“翻译”交给模型来完成。人只需要说“一个直径40mm、高度60mm的圆柱体顶部开一个直径10mm的贯穿孔底部带一个宽度8mm的键槽”模型拿到这句话之后直接生成对应模型或者生成一段参数化建模脚本。这就把建模门槛从“会操作软件”降到了“能描述清楚需求”。这里要强调一下它跟现在很火的文本生成3D模型完全不是一回事。文生3D模型追求的是视觉合理、风格匹配多数产出是网格或者隐式场拉进看可能一塌糊涂更没法做工程修改。text-to-cad 的目标是生成边界表示B-rep或特征历史树尺寸精确、约束完整、可以进CAM、可以出工程图甚至可以直接拿去加工。1.2 一句话需求背后的粒度差异“帮我画一个杯子”和“直径85mm、壁厚4mm、高度120mm、底部圆角3mm的圆柱杯杯口带一个向外翻边”这两句话对模型来说难度天差地别。前者需要模型脑补大量信息后者其实是把参数直接映射到特征上。当前 text-to-cad 方向更务实的做法是先吃后一种偏结构化、带完整参数的描述再逐步放开自由度。另外还有一个容易被忽视的点这个方向在不同行业里的“CAD”含义不一样。机械行业要的是参数化实体和特征树建筑行业要的是楼层、墙厚、开间这些构件逻辑电子行业更关心外壳、卡扣、散热孔这类薄壁结构。所以研究 text-to-cad 的时候得先明确你在为哪个领域做不同领域的描述词汇和建模习惯都有明显差异通用模型听起来很美实际效果往往两头不讨好。2. 一条完整的技术路径是怎么设计出来的2.1 直接生成几何的路子适合快速出形但不适合工程落地最早期的实现思路很直接用类似文生图的技术框架把文本编码成向量再通过生成模型输出体素、点云或者网格。这样做的好处是技术栈成熟拿现成的扩散模型改一改就能跑坏处也很明显——生成的网格噪声大、拓扑不稳定想要转成可编辑的B-rep模型需要额外的曲面拟合和特征识别精度损失严重。我曾经试过用这类方案做一个简单支架远看外形是对的一旦放大检查孔的位置偏差零点几毫米面与面之间出现微小的间隙根本过不了装配检查。所以我的结论是直接生成几何的路线适合做概念预览、灵感草图或者作为后续参数化重建的初始条件但把它当成 text-to-cad 的终点在工程上走不通。2.2 把建模操作序列当语言来生成是目前最接近实用的路线第二代思路发生了一个关键转变不再生成模型本身而是生成“建模过程”。每一段CAD建模都可以表示成一系列操作——新建草图、画线、标注尺寸、拉伸、切除、倒角、阵列。这些操作天然带有参数和先后顺序很像一种结构化语言。于是 text-to-cad 就变成了一个序列生成问题输入文本输出建模指令序列再由CAD内核按顺序执行。这个路线的核心是基于Transformer的序列模型。输入侧是自然语言描述输出侧是操作token序列。为了让模型学会这个映射需要大量“文本-建模操作序列”配对数据。数据来源通常是把现有模型库中的每个模型逆向解析成特征树再通过规则或人工方式生成对应的文本描述。训练完成后模型在推理时会逐步预测下一个操作token就像写代码一样把整个建模流程“写”出来。这种方案最大的优点是可解释性和可编辑性。输出的每个操作都能对应到特征树里的一个节点用户不满意可以直接改参数或者删掉某一步重新生成而不是面对一个不可拆解的网格。我几乎可以断言未来两三年内能真正落地的 text-to-cad 产品大概率是这种形态。2.3 大语言模型做规划几何内核做执行组合拳更省力在第二种路线之上还有一条更取巧的路径让大语言模型充当“建模规划师”负责把用户文本拆解成建模步骤然后调用CAD内核的API或脚本接口来执行。这里的LLM不直接生成token化的操作序列而是生成一段带参数的建模代码比如调用内核接口创建草图、添加约束、执行拉伸。这条路的好处在于可以利用LLM强大的代码生成和常识推理能力。模型不需要从零学习“拉伸是什么”因为它会写代码调用现成函数。实际上我在复现时就采用了这种思路用LLM把一个描述结构化为中间表示再翻译成几何内核的Python脚本。效果比从零训练专用模型稳定得多尤其适合快速验证想法。难点也有LLM经常生成“看起来合理但参数对不上”的代码比如把拉伸方向搞反或者引用了一个不存在的草图平面。所以必须在外围加一层校验逻辑——每次执行后检查结果是否满足尺寸约束不满足就带着错误信息让模型重新生成。这个“生成-检查-重试”的闭环是工程化落地中最关键的一环。2.4 数据和评估指标决定模型的上限无论走哪条路线数据都是最大的成本项。建模操作序列的数据不像图片文本那样满大街都是必须从现有模型库中解析特征历史来构造。这里有一个现实问题很多模型导入导出时会丢失特征树只剩一个光秃秃的B-rep实体无法反推操作顺序。所以做这个方向第一步往往是先解决“如何从几何反推特征历史”的问题这个前置工作比训练模型本身还花时间。评估指标也是个老大难。BLEU之类的文本指标只能衡量“生成的序列和参考序列有多像”但同一句话完全可以对应多种建模顺序序列不同、模型却可能同样正确。更合理的做法是执行生成的序列得到实体模型再去比较实体形状和文本描述的语义匹配度比如尺寸是否符合、拓扑是否一致、关键特征是否齐全。我在自己的项目里同时保留了网格距离和特征级指标两套评估体系前者看形状后者看工程正确性两个都要过才算合格。3. 我实际跑通的最小复现方案以及每个环节卡在哪3.1 意图解析不是通用NLP是“实体识别加动作映射”很多第一次做这个方向的人会直接上一个预训练语言模型去“理解”文本结果效果一塌糊涂。原因在于建模文本里的关键信息是高度结构化的槽位比如“直径40mm”是尺寸“顶部开孔”是位置和特征类型“贯穿”是成型方式。通用语言模型擅长语义理解但做不到稳定抽出这些精确参数。我自己跑通的做法是先做一层规则加模型的混合解析先用正则表达式和命名实体识别把数值、单位、特征关键词都抽出来再通过一个小的文本分类模型判断这句话属于“回转体”“拉伸体”“板类件”里的哪一类最后填充到一个预设的结构化模板里。模板长这样{ feature_type: hole, position: [top_face, center], diameter: 10.0, depth: through_all, pattern: null }这一步看起来不性感但它是整个链路上最影响最终成功率的一环。我踩过的坑是文本里出现“直径10mm的孔”和“10mm通孔”两种表达前者包含了特征类型后者隐藏了“孔”这个语义。所以解析模块里必须维护一张同义表达表并且对缺失槽位设置默认值而不是让模型自己猜。3.2 草图轮廓生成与约束求解是返工最多的地方拿到结构化意图之后下一步是在目标平面上生成草图轮廓。这个过程远比想象中复杂因为很多特征并不是简单的矩形或圆而是需要计算轮廓相交、圆角过渡、局部切除等操作。我的做法是先把轮廓看成参数化几何图元集合——圆、直线、圆弧——逐个计算出来再交给约束求解器去加尺寸和几何约束。这里最容易翻车的是约束冲突。比如你既指定了直径40mm又指定了圆心到边界的距离为30mm而实际草图宽度只有55mm时约束就会过定义导致求解失败。后来我在约束求解前加了一步可行性预检先算一遍所有约束的数值区间发现冲突就自动放宽次要约束而不是直接把错误抛给用户。这个预检模块帮我省掉了至少一半的重试次数。还有一个细节草图平面的选取不能只靠“顶部”这种语义词。同一个圆柱顶部可能是平面也可能带倒角或者台阶。我的方案是先做面类型分类挑出所有平面再按法向量和面积排序把最符合描述的那个面作为草图平面。如果描述里没明确位置就默认取最大平面这个规则在大多数简单零件上够用。3.3 特征构建和特征树组织决定模型能不能“改得动”同样一个零件特征的拆分粒度不同后续的可编辑性天差地别。我习惯把一次文本生成对应建模操作拆成三段基础体特征、减材特征、修饰特征。基础体负责先长出一块大形减材负责孔、槽、腔这些掏空部分修饰负责倒角、圆角、阵列这些细节。每段内部再按依赖顺序排好。实际执行中我遇到一个棘手问题阵列特征的顺序。如果你先做孔再阵列特征树里是一个孔特征加一个阵列特征如果你先生成多个孔再分别倒角特征树会变得非常臃肿。最合理的做法是在生成序列时就把“阵列”作为一个高阶操作下发给内核而不是循环执行多次单孔建模。这样生成的模型用户想在阵列里改数量、改间距时只需要动一个参数。3.4 模型验证不能只看“生成了没有”要看“能不能用”生成完模型别急着欢呼我这边的经验是至少做三类验证。第一类是几何验证检查体是否存在、有没有零厚度面、有没有干涉第二类是参数验证关键尺寸跟文本描述对比偏差在0.01mm以内算过第三类是特征验证特征树里是否有用户后续可能要改的关键特征节点比如通孔是不是真的贯穿、倒角是不是加在了正确棱边上。我把这些验证打包成了一个自动化脚本每轮生成之后自动跑一遍输出一份包含尺寸偏差、拓扑检查、特征完整度的报告。这一步投入不大但可以说是整个链路里性价比最高的一环。没有这套验证你就永远只能靠肉眼在屏幕前转来转去效率极低而且很容易漏掉细微但致命的问题。4. 实测里翻车的高发点我列成一份排错清单4.1 文本歧义比想象中更普遍“在底部开个孔”这句话你以为是朝下打孔模型可能理解成在底面所在平面上画个草图再拉伸切除更麻烦的是“底部”到底指底面外表面还是底面内侧。这类位置歧义在机械描述里随处都是。我的处理方式是强制在中间表示里把空间位置显式化——包括基准面、放置面法向、偏移方向、深度类型。宁可多问一句“这个孔是从下表面往内打还是贯穿到底面”也不要让模型瞎猜。4.2 坐标系和放置面错位这是我最开始复现时翻车最狠的地方。模型的输出坐标是基于自身姿态预估的但实际CAD内核里同一个零件旋转一下所有面编号和法向量全变了。后来我学乖了绝对不在模型输出里直接用全局坐标而是全部换成“相对当前实体的面引用”——先选中某个面再基于这个面的本地坐标系做后续操作。这相当于把坐标系的锚点从世界系改成实体系鲁棒性一下子提高了很多。4.3 约束失效导致整个特征静默失败CAD里有一种很隐蔽的错误某个约束求解失败时内核不一定报错它可能只是把这个特征标记为“悬空”然后在视图里不显示。生成结束一看零件缺了一块但整个流程完全没有报错提示。排查了半天才发现是之前某个尺寸约束因为参数更新失联了。现在我在生成流程里加了一道强制检查——每完成一个特征立刻查询特征树的激活状态发现悬空特征就回滚到上一步重新生成绝不往后走。4.4 对称和重复特征被重复建模描述“六个均布螺栓孔”时有些模型真的会循环生成六个孔特征而不是一个阵列。这在视觉上没问题但工程上就是灾难用户要改螺栓孔直径得手动改六次。我在后处理里专门做一个模式识别检测相同参数、规则分布的多个同类型特征自动合并成阵列。这一步对提升模型实用性帮助巨大也是从“能看”到“能用”的一个关键分水岭。4.5 评估指标自欺欺人的陷阱如果你只用一个整体形状相似度指标来评估生成结果很容易被骗。比如“缸体”和“实心圆柱”的整体距离偏差可能很小但对一个需要安装活塞的缸体来说中间那个孔没打通就是废品。所以我的评估表里每一项都必须能追溯到具体功能语义直径对不对、深度对不对、位置对不对、有没有这个特征。宁可评估严格一点导致通过率偏低也不能用一个模糊的“整体相似度”糊弄自己。下表是我实际用的精简版评估维度检查项通过条件失败时的典型原因尺寸偏差关键尺寸误差 ≤ 0.01mm参数解析丢失单位或小数位特征完整性描述中的每个特征都有对应节点生成了形状但没建对应特征贯穿状态通孔必须完全贯穿实体深度值不够或拉伸方向选错阵列合并重复特征被识别为阵列位置偏差导致特征参数不完全一致约束有效性全部特征处于激活状态前序约束求解失败导致悬空实体合法性无零厚度面、无内部干涉布尔运算存在临界相交情况5. 后续要怎么演进我的一点判断5.1 多轮交互式建模会比一次性生成更早落地一次性给一段话生成完整模型听起来很酷但用户真实的建模过程从来不是一锤子买卖——先定轮廓再改尺寸然后加特征不满意再推翻其中两步。所以我认为 text-to-cad 的实用形态不会是“文本进、模型出”而是“边聊边改”。用户先说“做一个底座”模型给个初版用户再说“高度改成30mm”“把四个角切掉”模型在原有特征树上增量修改。这个交互闭环对模型的要求比一次性生成更高因为它需要随时感知当前模型状态但对用户的实用价值也大得多。从工程角度看这也才真正配得上“参数化设计”这四个字。5.2 草图加文本的多模态输入会更早成熟纯文本描述几何细节其实很吃力。你说“中间凸起一圈”我到底怎么理解这个“圈”的宽度、高度和截面形状但如果配一张手绘草图把轮廓画出来再用文字补充尺寸和位置信息就完整多了。我试过用“文本结构槽位加草图轮廓”的组合输入方式效果对比纯文本有明显提升尤其在异形轮廓和复杂曲线这些纯语言很难表达清楚的场景里。这不需要等什么新技术现有的视觉语言模型加轮廓提取就能搭出来。5.3 从“能生成”到“能交付”缺的是约束体系和回归测试很多人会忽略一个事实CAD建模里最值钱的不是“生成了模型”而是“这个模型可以被稳定地修改和复用”。一个生成出来的支架如果用户改了一处尺寸整个模型就因为约束断裂而崩溃那它仍然不可用。所以接下来这个方向真正的护城河不是生成模型本身的参数量而是你沉淀了多少建模规则、约束模板和回归测试用例。我自己的做法是每处理一类新零件就把它固化成一套测试集跑通之后纳入日常回归防止模型迭代后把以前能做的又搞坏。这套东西虽然不起眼但时间越长价值越大。从实际体验来看text-to-cad 这个方向给我的最大感受是它不像文生图那样追求“惊艳”而是追求“可交付”。每一次输出都必须能放进工程流程里去检验这逼迫你把注意力从花哨的模型结构转移到数据质量、约束鲁棒性和验证体系上。如果你也想在这个方向动手试试我建议从小而具体的零件类别起步先打通“文本解析-特征生成-几何验证”这条最小闭环再慢慢扩展零件类型。先把一个类型的成功率做到百分之九十以上比做一个“什么都会但都差一点”的通用模型有价值得多。
