先说明一下我的个人体验：前阵子想做一个带加强筋的法兰支架，手头没有现成模型，纯手绘参数又磨了半天。当时就琢磨，如果能让模型自己“听懂”一句话需求，把文本直接变成可编辑的 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 个，你对这个领域的感觉就会完全不一样。之后你自然会知道该往哪个方向加复杂性。
这个方向我也不好说几年后会长成什么样，但至少现在，把它当作“辅助设计师的智能建模助手”来看，已经不是一个概念了，是真的能落地、能帮上忙的东西。
