CAD这块儿最近有个方向让我挺兴奋的就是text-to-cad。简单说就是输入一句人话比如“一个直径50的圆盘中心开一个直径20的孔周围均布六个直径6的安装孔”系统直接给你生成对应的三维模型。这听起来像科幻但实际上已经有不少模型和工具能跑通了。我自己试过几个也折腾过一些小实验今天这篇就把这个方向的核心技术、实现思路、常见的坑以及怎么把它真正用进工作流里仔仔细细聊一遍。如果你平时要做机械结构、非标件或者经常被业务部门用一句“就那种带孔的板子”搞得头大text-to-cad就是你值得关注的方向。这篇文章适合想了解技术原理的人也适合打算自己动手训一个最小验证模型的工程师。1. text-to-cad本质上是给三维建模装上一个“自然语言编译器”1.1 传统建模方式和自然语言的差距在哪里传统CAD建模是什么是操作序列。你画一个草图拉伸再选一个面打孔再阵列每一步都是在告诉软件“怎么做”。而text-to-cad想解决的是“做什么”这个层面——它直接把设计意图翻译成操作序列。这中间的差距就是自然语言和几何操作之间的鸿沟。举个例子。一句话“底板上开四个对称的圆孔”人很容易理解。但要变成CAD命令你需要知道底板是多厚圆孔直径多少四个孔的中心分布半径是多少“对称”是左右对称还是圆周均布这些信息源文本里可能都没有。所以text-to-cad系统面临的第一问题不是生成几何而是“补全缺失的决策”。它得像一个经验丰富的设计师把没说出口的部分也猜出来。这和文本生成图像的原理很像但有一个根本性差异图像是像素矩阵生成偏差一点点肉眼看不出来CAD模型是参数化实体一个孔位偏了0.5毫米整个零件就废了。这意味着text-to-cad的容错率极低。我在实际测试中看到过很多模型输出的模型看渲染图很像那么回事一测量尺寸全不对。这就是典型的“看起来能用实际上不能用”。1.2 解决的核心问题和实际价值text-to-cad的核心价值在于压缩“从想法到模型”的时间。传统流程里一个熟练工程师画一个中等复杂度的零件可能需要20分钟到1小时用text-to-cad辅助可能几秒钟出一个初版剩下的时间全部用在修改和确认上。对于非标设计频繁的场景这个提升非常可观。另一个价值点是“设计意图的沉淀”。自然语言描述可以被记录、复用、检索。比如“带法兰的圆柱壳体四螺栓孔均布”这句话既是一个历史需求记录又可以作为下次生成类似零件的输入条件。存量设计文档、需求规格书、甚至聊天记录里的需求描述都能变成模型生成的输入源。我实际试过的场景之一是标准件库的扩充。标准件比如螺钉、垫圈、法兰特性很规律非常适合用文本来描述。“M8平垫圈内径8.4外径16厚度1.6”这种描述几乎就是结构化参数模型特别好学生成也稳定。这类场景是最容易落地见效的值得优先切入。2. 从文本到模型中间要跨越的三道门槛2.1 语义理解把一句话拆成完整的参数表这一步和常规NLP任务比较接近但也有自己的特点。CAD描述中的核心信息是“实体特征”和“空间关系”不是情感或主题。我们需要从文本中抽取出类似这样的结构化内容基础实体类型圆柱体、长方体、球体、圆台关键尺寸直径、长度、高度、厚度特征操作切割、打孔、倒角、阵列位置关系中心、同轴、偏移、均布、对称隐含约束对称隐含了镜像关系均布隐含了圆周阵列我自己在处理文本标注时习惯先把一句话拆解成“实体—操作—尺寸—关系”四元组。比如“中心开孔的法兰盘直径120四孔均布在直径90的圆上”拆出来就是实体法兰盘操作开孔尺寸主体直径120孔分布圆直径90关系中心、均布、四个这一步如果拆错了后面模型再强也白搭。所以很多团队在做数据集时都花巨大精力在文本标注上这是整个流程的地基。2.2 几何映射从参数到实体模型的翻译规则有了参数下一步就是把这些参数变成几何体。这里有个关键问题——输出形式怎么选。一种思路是直接输出网格mesh像文本生成3D模型领域的常见做法比如用神经网络生成体素场或者SDF。这种方式视觉效果好但导出的模型没有参数化特征不能编辑不能改尺寸工程上基本没法用。另一种思路是输出参数化特征树或者直接生成CAD命令序列。比如CreateSketch(base_plane) AddRectangle(center(0,0), width100, height60) Extrude(distance10) AddCircle(center(50,30), diameter10) CutThroughAll()这段伪代码式的命令序列可以通过脚本回放直接在软件里重建出实体而且每个特征都是独立可编辑的参数。这是text-to-cad区别于普通文本生成3D的关键——可编辑、可参数化、可追溯。还有少数方案直接生成BREP边界表示数据精度高也不依赖具体软件但实现难度更大目前应用还不算广。我的建议是自己动手做实验优先考虑命令序列方案落地最容易。2.3 约束处理模型生成中最容易翻车的地方参数化设计里有大量约束关系这是文本描述里最容易丢信息的部分。比如“孔心到两条边的距离相等”意味着一个定位约束如果生成时只生成坐标一旦上游尺寸变化这个约束就丢失了模型就废了。目前不少模型倾向于直接生成绝对坐标和尺寸好处是训练简单缺点是无法应对参数驱动。如果想让text-to-cad真正融入现有设计流程模型输出的最好是一套带约束关系的命令流比如“孔心到edge1的距离等于到edge2的距离”这样的约束表达式而不是固定的坐标值。我在自己做小实验时踩过这个坑刚开始让模型直接输出坐标生成的模型在静态测试中完美但一改底板长度或宽度再重新生成孔的位置不会跟着边自动调整。后来换成了相对定位描述——比如“沿底边居中水平偏移30”效果一下子好了很多。这类经验说明生成策略的设计比模型架构本身更影响落地效果。3. 拆解一个可落地的text-to-cad流程3.1 数据准备是真正的护城河text-to-cad项目最稀缺的不是模型结构而是数据。文本描述和CAD模型配对的公开数据集非常少而且大多只覆盖很窄的类别比如简单的机械零件、建筑构件。如果你的目标是特定行业或特定产品形态基本得自己造数据。我的做法是自己录制CAD操作宏把操作序列存成JSON然后根据这个JSON写自然语言描述最后用CAD内核重新执行JSON生成实体。这样形成“指令集—文本—实体”的三元组。别小看这个方案它比人工逐条标注的效率高很多而且可以批量生成数据增强样本比如把尺寸随机变化、把位置关系随机表达。文本生成方面我写过一个模板引擎把指令集里的参数和关系转成自然语言比如“RoundHole(diameter6, position(50,30))”转成“直径6的圆孔圆心坐标在(50,30)”。然后还做了同义扩充用“孔”“钻孔”“圆孔”互相替换这样避免模型过拟合到单一表达上。数据量方面我个人的经验是最少几千条才有说服力一万条以上训练出的效果会比较稳。纯粹为Demo的话几百条也能看出模型能不能学到基本语法但要实际用数据量必须起得来。3.2 模型选型代码生成模型是当前的性价比之王text-to-cad模型的选型很多人第一反应是要不要搞个专门的几何神经网络。我觉得现阶段没必要。因为如果你把CAD生成定义为“命令序列生成”那这个问题本质上就是一个序列到序列任务跟代码生成、SQL生成非常像。用现成的代码生成模型比如CodeGen、StarCoder、CodeLlama这些开源系列再在自建的CAD指令数据集上微调是性价比最高的路线。有一个点值得说一下——这里的“代码”不要理解成传统意义的程序代码而是CAD软件自己的API脚本。我们微调的目标是让模型学会输出一段能在软件里回放生成实体的脚本。所以数据格式设计非常重要早期我做实验时用了FreeCAD的Python API格式后来也测试过OpenSCAD的描述语言两者都能用但通用性差别不小。如果想让生成结果在不同软件间共用中间加一层“中性指令集”会更合理。模型参数规模上从几亿到几百亿参数的模型我都试过。对于一个专注特定领域的text-to-cad任务小模型微调的效果完全够用几亿参数对几百种零件类别可以应对真正影响效果的是数据质量不是模型大小。3.3 一个最小可跑的流程示例我这里给一个最小可跑的参考流程基于我自己的实验配置帮你理解整体链路输入“一个40x30的长方形底板厚度5中心一个直径8的圆孔四个角落各一个直径4的圆孔”先做语义抽取用正则和规则引擎就能处理这类固定句式import re def parse_simple(text): plate_match re.search(r(\d)x(\d), text) thickness_match re.search(r厚度(\d), text) center_hole re.search(r中心一个直径(\d), text) corner_holes re.search(r四个角落各一个直径(\d), text) return { width: int(plate_match.group(1)), height: int(plate_match.group(2)), thickness: int(thickness_match.group(1)), center_d: int(center_hole.group(1)), corner_d: int(corner_holes.group(1)) }然后把这个参数传给生成脚本的模板def gen_cad_script(params): w, h, t params[width], params[height], params[thickness] cd, kd params[center_d], params[corner_d] # 角孔位置留边距5 margin 5 script f import cadquery as cq result cq.Workplane(XY).box({w}, {h}, {t}) result result.faces(Z).workplane().center(0, 0).hole({cd}) c {w}/2 - {margin} d {h}/2 - {margin} result result.faces(Z).workplane().pushPoints([({c}, {d}), ({-c}, {d}), ({c}, {-d}), ({-c}, {-d})]).hole({kd}) return script最后用cadquery回放输出STEP文件。整套流程跑通只需要几百行代码这是理解text-to-cad的最小骨架。真实场景的模型只是把这个骨架中的规则引擎换成神经网络其他的部分几乎不变。4. 训练与推理中最容易翻车的三个环节4.1 坐标一致性问题训练模型直接生成CAD脚本时最大的坑是绝对坐标。模型在训练数据里看到的坐标是一个值域范围如果训练数据里坐标普遍集中在某个区域模型学到的分布就是偏的。推理时一旦输入文本描述的尺寸超过训练分布模型输出的坐标很可能离谱比如跑到负值区造成特征反转。我自己的解决方法是把所有坐标从绝对坐标改成相对坐标比如“孔心相对于底座中心偏移(20, 15)”让模型学的是相对关系而不是绝对位置。相对位置模式下的泛化能力会显著提升实测效果稳定很多。4.2 命令序列未闭合问题文本生成代码有个经典问题——代码不完整比如截面没有完全闭合、轮廓线没有首尾相接直接导致实体生成失败。这在text-to-cad里的表现是模型生成的脚本语法看起来都对但实际执行时CAD内核直接报错或者生成一个破碎的几何体。排查思路很简单设计两个规则做约束每个草图必须有闭合的轮廓线不允许自由端点每个拉伸、切割操作必须有对应的布尔运算结果检查这类结构化约束不靠模型自己领悟靠脚本后处理规则就能兜底。我在推理阶段接了一段自动修复逻辑发现脚本生成失败时自动把开放线端点连接起来再重试成功率能提升不少。4.3 评估指标的选择陷阱很多text-to-cad项目都陷入一个评估误区——只看生成模型的视觉相似度。用SDF或者点云距离衡量两个三维模型的距离看起来科学但实际工程上没用。因为视觉相似不代表尺寸正确、也不代表特征可编辑。我的建议是分三层评估语法正确率脚本能否被CAD内核回放并生成有效实体几何准确率关键尺寸、孔心位置是否存在误差误差是否在容许范围内约束保持率修改上游参数后下游约束是否仍然维持这三个指标能比较好地反映“能不能真正投入使用”。我自己的模型迭代过程中也主要盯着这三个指标做优化。很多论文里展示的漂亮图片拿到这三个指标下测立刻就见真章。5. 从玩具到工具text-to-cad真正融入工作流的三个方向5.1 作为“设计意图捕获器”而不是“全自动建模工具”以我目前的使用经验不要指望text-to-cad完全替代CAD建模——现阶段它的定位更像是“设计意图的捕获器和草稿生成器”。它能在你脑子还没想清楚细节时先把大概的几何形状生成出来你再在CAD里调整参数、加约束、做优化。这个模式比全自动生成靠谱得多。实际项目中我习惯把text-to-cad作为一个插件集成在软件里使用者输入一句话系统生成一个带参数的预置模型接下来所有修改都在参数面板里完成。这样既保留了CAD的优势又把前期的繁琐操作去掉了。5.2 从单零件到装配体的挑战和应对目前的text-to-cad基本都局限在单零件也就是“一个实体”的范畴。但真实设计里装配体才是常态比如“底板上面放一个电机支座用四颗螺钉固定”。这个目标对模型的理解能力要求高了很多——不但要描述每个零件的几何还要表达零件之间的贴合面、定位关系、安装顺序。我实验中尝试过将装配体分解成多个零件描述再额外输出装配关系比如“face1贴合到face2中心对齐”。这个思路可行但数据获取的难度又上一个台阶。目前距离直接成品化还有距离但值得关注。5.3 未来会走向“设计意图对话式生成”的模式text-to-cad未来发展大概率不是“一句话生成最终模型”这样一锤子买卖而是“对话式逐轮细化”先给定一个粗略需求生成初版用户说“孔太小了孔距再大一点”系统在参数空间上做局部修改。这比一次生成更符合真实设计习惯因为它允许渐进式探索。从技术角度看这需要模型具备多轮对话能力和修改记忆能力——记住上一轮生成的模型参数理解本轮修改意图更新相应参数而不是重新生成全部内容。目前这个方向的实验还不多但我觉得这是text-to-cad产品化的必经之路。我自己在实际使用中发现最管用的做法是把text-to-cad的输出当成“设计的第一个版本”后面的决策完全交由人来控制。模型负责把模糊的表达变成可讨论的几何人负责判断“这是不是我要的感觉”。踩过几次坑之后我更加坚信一点——真正能落地的AI工具不是替你做决定而是让你更高效地做决定。text-to-cad是这个思路的绝佳实践而且它才刚刚开始。如果你也想试试这个方向建议从最小流程跑通开始别一上来就追最复杂的模型先把数据链路和评估体系搭好你的每一步优化都会踩在实处。