先说明一下我的个人体验前阵子想做一个带加强筋的法兰支架手头没有现成模型纯手绘参数又磨了半天。当时就琢磨如果能让模型自己“听懂”一句话需求把文本直接变成可编辑的 CAD 模型省掉那一大堆草图、拉伸、倒角操作那该多省事。后来我花了几周时间专门把 text-to-cad 这条路从原理到落地完整试了一遍也踩了不少坑。这篇文章就把我这段实操里最有价值的东西整理出来包括技术路线取舍、数据难点、可复现的搭建步骤、评测方法和那些文档里不会写的真实教训。1. 为什么“文本生成CAD”不是“AI画图换个领域”1.1 CAD模型的本质是可编辑的工程数据不是像素很多人第一次听说 text-to-cad第一反应是“这不就是 AI 画图嘛给它一句‘画个杯子’它输出个模型就行”。这个理解方向不算错但差得远。文本生成图像输出的是像素矩阵人眼觉得好看就达标了文本生成 CAD输出的必须是一份带拓扑关系、带尺寸约束、带特征历史、甚至带装配关系的工程数据。像素错了可以重画拓扑错了就是废件加工出来根本对不上。举一个最简单的例子。你说“一个直径 40mm 的圆盘中心开直径 10mm 的孔”。AI 画图模型可以给你渲染出一张以假乱真的图但它不会告诉你圆盘的厚度是多少孔是否贯穿孔和圆盘的同心度公差要求这个模型的 B-Rep边界表示里有多少条边、多少个面参数化历史树里是“先拉伸后打孔”还是“先草绘后旋转”这些信息恰恰是制造环节最关心的。CAD 模型本质上是一个“程序化描述”它记录的不只是最终形状还有这个形状是怎么一步步构建出来的。text-to-cad 要做的就是让这种程序化描述能直接从自然语言里长出来。1.2 一句话需求到图纸之间缺的是“决策链”更麻烦的是一句自然语言需求在很多关键位置上是不完备的。你说“给我一个带法兰的支架”这句话在工程师脑子里能补全出一整套设计假设但在模型那里它就是一堆未决问题法兰是圆形还是方形法兰上有几个孔孔位怎么分布支架的臂长多少壁厚多少过渡圆角多大是和别的零件装配还是独立焊件承受的载荷方向是什么有没有强度和刚度要求这些信息不是模型“生成”出来的而是设计决策。一个合格的 text-to-cad 系统不能用“猜”的它得能识别出哪些是明确意图哪些是隐含假设哪些是必须让用户再确认的开放项。所以我一直觉得text-to-cad 的核心难点不在“生成几何”而在“理解工程意图”。几何生成是技术题工程意图理解是业务题。这两件事不分开做出来的东西永远是“好看的废物”。1.3 一个真实需求拆解从“带法兰的支架”到参数化树我把一个典型需求完整拆解给你看你就理解为什么这条路比看起来难得多。输入文本一个 L 型支架底板长 60mm宽 40mm厚 5mm立板高 50mm厚 4mm底板上有两个直径 6.5mm 的安装通孔孔心距底板短边 10mm两孔间距 30mm立板顶部开一个 20mm 宽的卡槽深度 10mm所有外边缘倒圆角 R1。这段描述在人类工程师那里信息量已经相当完整了。但要让模型正确执行它需要把这些信息翻译成一颗参数化特征树底板拉伸矩形 60x40x5立板从底板长边向上拉伸 50x4 的截面布尔叠加L 形主体打孔在底板上做两个直径 6.5 的通孔定位约束距离短边 10孔间距 30卡槽在立板顶部去除材料20 宽、10 深圆角外轮廓累计 22 条边每条半径 1这里面每一个环节都有“坑”底板和立板如果作为两个独立实体直接布尔加生成的模型还能不能保持参数化关联钻孔定位是从底板的哪条边开始算圆角如果加在布尔运算的衔接边上会不会报“几何拓扑错误”这些细节大部分现成的 AI 建模工具都不会替你考虑需要系统的整体设计去兜底。2. 三种主流技术路线的选择与权衡2.1 端到端模型直接吐STEP或网格第一种路线是训练一个端到端的生成模型输入文本直接输出 STEP 文件或某种网格格式。这个方案听起来最“AI 原生”实际做起来问题最多。端到端模型面临的第一个问题是数据量。CAD 模型不像图片和文字那样海量公开能拿到的带文本标注的 STEP 模型规模通常只有公开图像数据的零头。第二个问题是输出模态。STEP 文件是文本格式不假但它的内部结构是基于 B-Rep 的一系列拓扑实体和曲线曲面方程直接让模型“生成文本”式地输出 STEP句法规则和几何一致性双重压迫目前生成出来的东西很容易出现面缺失、自相交、裂缝等拓扑错误。哪怕是生成网格格式也很难保证水密性和可编辑性。第三个问题更致命可编辑性为零。端到端输出的模型往往是一坨“死几何”特征是平的没有参数历史树。用户想改一个孔的位置没法回到“打孔特征”改参数只能删了重做。这在工程师眼里是绝对不可接受的。所以端到端路线目前更适合做“概念胚子”用来快速可视化、做灵感参考离真正进入设计流程还很远。2.2 生成中间表示的路线草图-拉伸-布尔的程序化表达第二种路线也是学术界这两年里比较主流的做法是让模型生成一个“中间程序化表示”通常是某种建模指令序列或参数化脚本然后再用引擎解释执行生成最终几何。这个路线的优势很明确它绕开了直接生成 STEP 的拓扑难题让模型去生成“如何建模”的指令序列而不是“最终长什么样”的几何文件。指令序列天然具备可编辑性因为它本质上是把设计师的操作过程写了下来。而且这种做法比较符合 CAD 本身的工作方式——CAD 里的每个模型本来就是操作序列一步步堆出来的。这个路线我实际试下来最大的感受是模型承担的工作量被大大简化了但解释器的设计难度上来了。你需要定义一套语法稳定、表达能力够用、同时不会让模型产生歧义的指令集。指令多了模型开始胡来指令少了覆盖不了复杂需求。这个平衡要花不少心思去调。2.3 大模型加代码生成接口目前最可控的方案第三种路线可能也是目前工程上最容易落地的是借助大语言模型直接生成参数化建模脚本然后用脚本引擎执行。具体来说就是选一个支持脚本化建三维模型的引擎例如开源脚本化 CAD 工具或某些参数化建模平台的脚本接口然后让大模型直接写这个引擎的代码。大模型在写代码这件事上已经被训练得相当强了而参数化建模脚本本质上也是一种 DSL大模型学习过大量这类范例后生成的稳定性和语义准确度明显高于前两种路线。这背后的逻辑很聪明与其让模型理解“几何拓扑”不如让模型理解“代码语法”把拓扑难题交给底层引擎处理。引擎负责保证每一步操作之后模型仍然是水密的、合法的模型只需要保证它调用引擎 API 的方式是正确的。我测试过不少案例后认为这个路线是目前 text-to-cad 综合性价比最高的选择也是我后面要重点展开的方法。不是因为它完美而是因为它的失败模式最可控脚本错了能看日志形状不对能改代码至少不会给你吐出一堆没法修的死几何。2.4 我为什么把重心放在第三条路线我的选择逻辑其实特别简单三条标准生成结果必须可以编辑特征历史树要保留出错之后必须能定位、能修改我不能接受黑箱对硬件和数据的要求要现实个人开发者也能跑起来对比一圈之后端到端路线第一条就淘汰了中间表示路线第二条做不好代码生成路线三条都占上了。所以这篇文章后面的实操部分我全部围绕“大模型生成脚本引擎执行”这条路来讲。3. “数据”才是text-to-cad真正的命门3.1 通用语料不等于CAD语料很多人忽略一个问题大模型确实会写代码但“会写通用代码”和“会写CAD脚本”是两回事。你让它写个 Python 爬虫、写个排序算法那没问题但让它写一段带公差标注、带装配约束的建模脚本它很可能编一个不存在的 API 出来。原因在于预训练语料里CAD 脚本的占比太少了。通用代码占了绝大多数而参数化建模脚本、几何建模 API 的示例在整个语料里属于小众中的小众。模型没见过足够多的高质量范例自然只能靠“泛化幻觉”硬撑。这一点直接决定了你在搭建 text-to-cad 系统时构建自己的“CAD 语料库”是无法跳过的环节。3.2 文件格式与拓扑缺一不可那什么样的数据才算合格的 CAD 语料我总结过至少得满足三个条件文本形态可得标注信息完整几何合法可重建文本形态容易理解模型只能吃文字所以脚本、伪代码、标注文本必须准备好。标注信息指的是“这个脚本对应的自然语言描述是什么”没有对齐描述的数据没法用来训练或做少样本示例。几何合法是最容易被忽视的网上爬来的模型里有不少经过格式转换后拓扑已经坏了面片朝向不一致、有缝隙、有重叠面这种数据拿去当范例等于教模型生成坏模型。我当时做数据清洗的时候加了一道“重建校验”每个入语料库的脚本都要真正跑一遍得到几何然后做水密性检查、边界检查、特征数量检查。不合格的脚本直接踢掉哪怕它的注释写得再漂亮。3.3 数据清洗的实际操作要点这一部分具体操作里我踩过几次之后总结出来的经验可以列给你按“零件类别”分桶存储。法兰类、支架类、轴套类、箱体类分开避免模型把不同类别的特征混在一起。同名参数必须统一语义。比如“厚度”有的脚本里叫 thick有的叫 wall有的叫 t。不统一的话模型生成时会对参数名产生混淆。每条数据都要有“自然语言标题完整脚本渲染图参数说明”四件套。少一个后面做评测时你就缺一条验证手段。数据量不够就做“程序化生成”。我写了几个标准模板脚本然后用随机参数批量生成变体理论上可以得到无限数据。但实操下来发现模板太像会导致模型过拟合所以程序化生成的数据只能当辅助不能当主力。提示数据清洗这件事没有捷径。如果你的目标是做个能交付的系统至少要把 70% 的时间花在数据上。模型只是把数据里的模式如实反映给你数据脏结果不可能干净。4. 从零搭建一条可用的文本到CAD链路4.1 定义自己的DSL怎么选先明确一件事让大模型“自由发挥”地写 CAD 脚本是不行的你必须给它一个约束性很强的子语言也就是 DSL。DSL 的语法越简单模型的发挥空间越小出错率越低。我当时设计 DSL 时选了这样几个基元box(w, d, h)矩形体cylinder(d, h)圆柱体tube(d_out, d_in, h)管状体extrude(profile, h)拉伸轮廓union(a, b)/difference(a, b)布尔并集、差集hole(body, d, x, y)在体上打孔fillet(body, edges, r)倒圆角translate(body, x, y, z)/rotate(body, axis, angle)变换为什么这样选理由有三个。第一这些基元覆盖了机械零件 90% 以上的常见建模场景。第二参数类型极度统一都是数字和简单的字符串模型不需要理解复杂的对象结构。第三每个基元都对应一个确定性的引擎操作执行结果可预期不会模棱两可。设计 DSL 的时候千万不要贪多。每多一个基元模型就要多学一个用法错误边界就会多一重。能用 8 个基元解决的问题就不要加第 9 个。4.2 搭建“零件库尺寸槽几何基元”结构DSL 只是骨架真正让模型“懂需求”的是零件库和尺寸槽。零件库是一组已经建好的标准件模板比如法兰、轴套、垫片、螺栓头这一类。每个模板里预定义了特征结构和参数槽。模型接到自然语言后不是凭空生成几何而是先去零件库里检索“这段话对应哪个模板”然后把需求里的尺寸填进槽位里再对不适配的地方做几何调整。我举个例子。输入“带四个安装孔的圆形法兰外径 80内径 30厚度 8”模型在零件库里命中“标准圆形法兰”模板模板里已经有“外径、内径、厚度、孔数、孔分布圆直径”这些槽位模型只需要把数字填进去。这个过程比从头生成几何稳定得多。这套设计的本质是把“创造性任务”降级成“检索填空局部修改”任务。模型的自由度被约束在合理范围内生成质量自然大幅提升。4.3 大模型提示词与约束注入DSL 和零件库定好之后提示词工程就是重头戏。我的提示词模板长这样你是一名机械设计助理。请根据用户的需求用给定DSL脚本生成一个参数化CAD模型。 规则 1. 只能使用以下函数... 2. 所有尺寸必须具体数值单位毫米不得使用变量名代替数值。 3. 开孔必须用hole不得用布尔差集直接挖。 4. 如果需求信息不足输出...需要确认...不要编造。 5. 输出格式只输出脚本不要解释。 零件库定义 ... 用户需求...这里每个规则背后都有目的。规则 2 是为了防止模型用变量名偷懒导致引擎拿不到实际尺寸规则 3 是为了保住特征历史树用布尔差集挖的孔在后期改尺寸时非常难受规则 4 是为了让模型在信息不足时主动暴露问题而不是瞎猜一个尺寸硬上。这里我特别要强调规则 4。最初版本里没这条规则模型遇到“一个轴套”这种模糊需求时会自作主张假设一个尺寸。出的模型倒是不报错但尺寸完全不对。加了这条规则之后模型会输出“需要确认轴套的内径、外径和长度”系统再把问题返回给用户体验顺畅了很多。4.4 执行与抽查人要在回路里脚本生成后引擎执行这一步我同样加了“执行后校验三件套”语法检查脚本能不能被引擎正确解析几何检查生成模型是否水密、面数是否合理、有没有退化面需求对齐检查关键尺寸是否满足输入约束孔数、孔距等特征是否一致前两项是自动化的第三项目前我会保留人工抽查。原因是需求对齐这件事在语义层面很难做到百分之百自动判定。比如用户说“厚一点”多厚算厚这需要人对上下文的理解。后来我发现把常见需求分类做约束映射能显著减少人工介入次数。比如“厚一点”默认映射为“壁厚增加 50%”如果用户不满意再人工调整。这是一种很务实的折中方案。注意text-to-cad 目前做不到全自动交付。人必须留在决策回路里尤其是在尺寸定义、装配关系和基础选型这三个环节。做系统设计时不要一开始就追求“无人化”先做好“人在环上的半自动”已经很能打了。5. 怎么看一个text-to-cad生成得好不好5.1 从五个维度打分的做法做评测是我在这个项目里收获最大的一部分。不看评测你根本不知道系统到底进步了还是退步了。我用的打分框架是五维评分每项 1 到 5 分维度含义关键检查项语义一致性生成结果是否满足用户文本里的全部显式要求尺寸、数量、特征名称逐一核对几何合法性模型是否可制造、可导入主流平台水密性、无自交面、无退化边参数可编辑性关键尺寸是否暴露为参数改参数后模型是否稳定重建修改孔距、壁厚后是否报错特征合理性建模过程是否符合机械设计的常规习惯先加材料后减材料圆角放最后可解释性模型能否说明自己做了哪些设计假设是否输出了假设说明假设是否合理这个框架用了一段时间后我发现一个很有意思的现象语义一致性得分高的案例几何合法性不一定高而几何合法性高的案例语义一致性往往也不错。原因可能是因为几何合法的脚本结构更清晰模型在结构清晰的上下文里对语义的理解也更准确。这算是一个意外的相关性发现。5.2 一致性优先于复杂度在测试过程中我一度沉迷于让模型生成“看起来很厉害”的复杂零件——齿轮箱、多腔体、异形壳体。结果项目差点烂尾。后来我把目标降回“基础零件集”也就是法兰、支架、轴承座、轴套、垫块这类生成成功率瞬间从四成飙到八成以上整个系统一下子变得可用了。这个经验对我的触动很大。text-to-cad 的目标不应该是“生成最复杂的模型”而应该是“稳定生成满足需求的正确模型”。一个能稳定生成正确法兰的系统价值远大于一个偶尔能生成漂亮但常常翻车的齿轮箱的系统。所以你做评测时最好把测试集固定下来比如 30 个基础零件需求、10 个中等复杂度需求、5 个复杂需求每次改完系统都拿同一套需求跑一遍看分数变化。这样你才能知道自己到底有没有进步。5.3 你自己的验收基准怎么建外部的统一基准目前还没有完全成型但你可以先建一套自己的验收集。我的做法是从真实项目需求里挑 30 条覆盖 5 个零件大类每条需求标注“关键约束元组”比如(孔数4, 外径80, 壁厚5)把生成结果和关键约束元组逐项比对这个做法特别朴素但特别有效。测试需求集一旦固定系统的任何改动都能直接反映在分数上。反正我现在改一版 prompt都会拿这套验收集跑一遍分数不涨就不上线。6. 当前最常踩的坑和一点实在建议6.1 我实测遇到的四类典型失败我平时会顺手记录项目里的失败案例目前遇到最多的是这四类第一类是“画蛇添足”。用户只要一个简单轴套模型非要加一圈凹槽、再加个倒角导致特征树上多出一堆用户没要的东西。这种问题主要靠提示词约束明确告诉模型“不要添加用户未要求的特征”。第二类是“孔位漂移”。用户说孔心距短边 10mm模型给做到了中心距 12mm。这个问题我查了很久最后发现是模型把“距短边”理解错了它在脚本里用的是相对底面中心坐标。解决办法是在 DSL 里统一采用“绝对原点定位”或明确标注参考基准。第三类是“布尔顺序错误”。先打孔后加圆角通常没事但先加圆角再打孔圆角面上的孔会生成得很奇怪。这个需要在引擎层面加操作序列的规范化约束比如强制“圆角永远在布尔和孔之后”。第四类是“幻觉 API”。这是最初级也最容易翻车的错误模型凭空编出引擎里根本不存在的函数。解决方式是在提示词里用“不允许使用以下格式之外的任何代码”同时把可用函数的签名列表完整贴进上下文。6.2 哪些场景可以先用起来尽管 text-to-cad 目前不算成熟但有几个场景我认为已经可以实际用起来了。一是标准件快速生成。法兰、垫片、轴套这类高度标准化的零件生成成功率已经很高能明显节省点击参数的时间。二是概念验证快速建模。结构工程师在做方案比选时经常要快速出一堆示意模型来讨论布局。用 text-to-cad 先出个能看、能量尺寸的粗模型比手画快很多。三是教学和演示。课堂上让学生用自然语言描述一个零件再看系统怎么把它翻译成建模步骤这个过程本身就是很好的 CAD 教学素材。至于高精度装配体、需要严格按标准制造的零件、对公差有明确要求的场景现阶段还是老老实实手动建模不要让AI碰。6.3 个人体会最后说点个人层面的东西。text-to-cad 做下来我最深的体会是它不是一个纯算法问题而是一个“自然语言几何内核工程知识数据工程”的交叉问题。任何单一技术强项都救不了整体短板的权重非常高。数据脏模型再强也白搭DSL 设计不合理提示词再精致也没用评测集不固定优化就永远是拍脑袋。如果让我给后来者一个最务实的建议那就是先别急着追“一步到位生成复杂零件”的目标把一个能跑的、基于 DSL 约束和零件库的 pipeline 搭出来让它先稳定生成 10 个你最常用的小零件。跑通这 10 个你对这个领域的感觉就会完全不一样。之后你自然会知道该往哪个方向加复杂性。这个方向我也不好说几年后会长成什么样但至少现在把它当作“辅助设计师的智能建模助手”来看已经不是一个概念了是真的能落地、能帮上忙的东西。