Text-to-CAD技术解析：从自然语言到可编辑三维模型的生成路线与工程实践

1. 为什么偏偏是 text-to-cad 火了：从“看图说话”到“听指令建模”

生成一张 2D 图片这件事，现在大家已经很熟了。你输入“一只穿宇航服的柴犬”，Stable Diffusion 能给你吐出四张风格完全不同的图，分辨率还很高。但如果你输入“一个带四个安装孔的法兰盘，外径 100mm，厚度 12mm”，你想要的是一个可以直接拿去做数控加工、或者丢进装配体里和其他零件咬合的三维实体模型。

这就是 text-to-cad 这个方向的核心价值：它把自然语言描述直接变成可用于工程的三维模型，而不是一张像素图。

先说清楚 CAD 是什么。CAD（Computer-Aided Design）是计算机辅助设计，工程师用 SolidWorks、Fusion 360、FreeCAD、AutoCAD 这些软件做机械零件、外壳、模具、建筑构件。而 text-to-cad——字面意思就是文本到 CAD 模型——目标是把“我要一个什么样的零件”变成“一个实实在在的 CAD 文件”，这个文件通常涉及 STEP、IGES、STL，或者原生参数化模型文件。

为什么这个事突然在 2023 年底到 2024 年成为热点？三个原因叠加。

第一，2D 生成已经卷到头了，学术界和工业界都需要新的增长点。图像生成模型的问题在于它生成的是“看起来像”的东西，但三维模型要的是“几何上是”的东西。这完全是两回事。图像模型可以画出一个透视正确的椅子，但把那张图交给工厂，工人没法给你造出一把能坐的椅子，因为那只是一堆像素。

第二，三维数据表示和神经网络架构在最近几年真的打通了。点云、体素、SDF（有向距离场）、网格、BREP（边界表示）这些不同的三维表示方式，都有人尝试和深度学习结合。特别是神经辐射场和扩散模型在三维领域的迁移，让从文本生成三维模型变得技术上可行。

第三，工业界的真实需求实在太大了。手板、非标零件、夹具、治具的建模高度重复，工程师大量时间花在画那些结构大同小异的零件上。如果能让 AI 先出一个基础版本，工程师只需要做参数修改，这个效率提升是肉眼可见的。

这个技术适合谁来碰？如果你是做机械设计的，想了解 AI 能不能帮你减轻重复劳动；如果你是做三维视觉研究的，想找一个有工程落地价值的方向；如果你是个创客，想快速把脑子里的想法变成一个能 3D 打印的模型——text-to-cad 都值得你投入时间研究。

2. 被 CT 扫描“骗”了这么多年：CAD 模型和网格模型的本质区别

在深入技术路线之前，必须先搞清楚一个基础问题：我们说的 CAD 模型，到底和日常见到的 3D 模型文件有什么区别？这个问题不弄清楚，后面对技术方案的理解会全是错的。

最常见的三维模型文件是网格（mesh），就是那一堆三角形面片组成的表面。STL 文件就是这个格式，3D 打印行业用它。网格模型的特点是：它描述的是“形状”，但不知道这个形状是怎么设计出来的。一个圆孔在网格模型里变成几十个三角形拼成的洞，精度取决于细分的密度。

但真正的 CAD 模型不是这样的。在 SolidWorks 里打开一个零件，你看到的是特征树：拉伸、旋转、倒角、圆孔、阵列。圆孔是一个参数化特征，你知道它的圆心位置、直径、深度、是否有螺纹。修改直径只需要改一个数字，整个模型自动更新，哪怕这个孔和其他表面有布尔运算关系也不影响。

这个差异是理解 text-to-cad 难度的一条关键分界线。

网格模型本质上是在做“形状模仿”。所以深度学习可以比较容易地生成几何形状，因为形状是连续的数值场，神经网络擅长拟合连续函数。但 CAD 模型在工程软件里的本质是“操作序列和参数”，是一棵树状结构：先画草图，然后拉伸，再打孔，再倒角。这更像一段程序，而不是一张图片。

用生活类比来说：网格模型是你捏出来的泥巴雕塑的最终外形，CAD 模型则是那份菜谱——先放多少面粉，加多少水，揉多久，烤多少分钟。

现在的 text-to-cad 领域，实际上有两条完全不同的赛道：

• 生成网格/点云/SDF：适合出概念设计、做视觉预览、生成 3D 打印模型的原始形状。学术上场景非常热闹，因为可以用类似图像生成的扩散模型来处理。
• 生成参数化 CAD 操作序列：适合真正的工程制造场景，生成的是带特征树的可编辑模型。这条赛道难度远超前者，因为模型不再用张量表示，而是需要神经网络去推理离散的程序化操作序列。

很多初学者一上来就看各种 demo 展示，“哇，文字直接变模型”，结果自己拿来一用，发现下载下来是个 STL 网格模型，放进 SolidWorks 里根本没法编辑——它不是 CAD，只是一个长得像的雕塑。

所以你在看任何 text-to-cad 项目的时候，第一个要问的问题不是“效果好不好”，而是“它输出的是什么格式”。输出 STL/OBJ 的，那是“文本到网格”；输出 STEP/Fusion 360 原生格式/CadQuery 脚本的，那才是“文本到 CAD”。

3. 技术路线的三条岔路：检索式、生成式、程序合成式

目前 text-to-cad 的所有主流方案，可以归成三条技术路线。没有哪一条是完美的，但各自适用的场景完全不同。

3.1 检索式：从模型库里“淘宝”

检索式方案的逻辑很简单：你输入一段文字，系统从三百万个已经存在的三维模型里找到最匹配的一个，直接给你。代表工作有基于 CLIP 特征的三维模型检索、Point-E 的那套编码检索逻辑，以及各种跨模态检索系统。

优点：结果绝对可靠，因为所有候选模型都是人工建模的，几何质量没得说。速度快，不需要实时生成，只需要做一次向量相似度检索。工业上确实可用，因为很多标准件、常用零件本来就是重复使用的。

缺点：你永远只能得到数据库里有的东西，无法生成新设计。你输入“一个带六角凹槽的特殊法兰”，如果数据库里没有，系统只能在形状相近的模型里矮子里拔高个，结果往往让人哭笑不得。

这条路线适合标准化程度高的场景，比如标准件库、五金件库的智能搜索。不适合做创新设计。

3.2 生成式：让扩散模型“捏”出几何体

这是学术界最热闹的一条路线。思路是：把三维几何也用扩散模型的框架来做，只不过把 2D 像素换成三维表示。

具体来说，有几种做法：

• 体素扩散：把三维空间划分成网格，每个格子有占用值，生成过程就是在体素网格上做扩散。代表工作有 3D Shape Generation 系列。缺点是分辨率做不高，通常 64 到 128 的体素分辨率已经是极限，再往上算力和内存都扛不住。
• SDF 扩散：用神经网络隐式表示 SDF 场，然后在这个场上做扩散。代表工作有 3D-LDM、SDF-StyleGAN 等。好处是可以得到连续光滑的表面，缺点是提取网格的时候需要跑 marching cubes，而且模型难以处理锐边和平面。
• 三平面/多视图扩散：用多个正交视角的 2D 图像来表示 3D 模型，在 2D 图像上做扩散，再重建到 3D。代表工作有 Zero-1-to-3、SyncDreamer 等。好处是能比较自然地利用 2D 预训练模型的先验知识，缺点是重建出来的一般是带纹理网格，精度有限，丢失了工程几何精度。

这条路线生成的产物基本都是网格模型，适合做概念设计、游戏资产、3D 打印粗模。做不了工程精密件，因为生成的面片数有限，曲面的几何精度、平面度、垂直度都不能满足机械设计要求。

3.3 程序合成式：生成可编辑的“建模操作流水线”

这是我最看好的一条路线，也是真正意义上的 text-to-cad。思路是：模型输出的不是网格，而是一系列 CAD 操作指令和参数——比如“画一个草图，矩形 100x80，拉伸 20mm，然后在中心打一个直径 10mm 的通孔，四周导圆角 R5”。

输出形式可能是 DSL（领域特定语言），比如 CadQuery 脚本、OpenSCAD 代码、或者直接输出 STEP 文件。代表工作包括 Text2CAD 系列、CAD-Coder、以及一些基于大语言模型的参数化建模方法。

为什么说这条路最接近“真正的 CAD 生成”？因为输出的模型自带特征树，在任何主流 CAD 软件里打开都是可编辑的。你改一个拉伸高度，倒角会自动跟着变。这在工程上是质的区别：有了可编辑模型，工程师就能在 AI 基础上做二次修改，AI 生成的不是终点，而是起点。

难点也很实在。程序合成是离散的、结构化的，需要模型理解一个操作的先后顺序：你必须在拉伸之前先把草图画出来，必须在布尔之前先有两个实体。序列一错，整个模型就废了。目前的办法主要是用大语言模型做自回归生成，把建模步骤当成 token 序列来预测，和生成代码的方式类似。

3.4 三条路线怎么选：场景和产物的匹配关系

我见过太多人在这上面踩坑。想搞工程零件设计，结果用了一条生成网格的路线，导出模型后发现尺寸不对、锐边变圆角、插进装配体完全不合牙。反过来，只想快速出个概念模型做汇报，却折腾一套参数化程序合成方案，半天没调通。

4. 想亲手试一下？一套完整的开箱实测流程与参数踩坑实录

理论说完了，讲讲我实际跑过的几个项目。重点说两个有代表性的：一个是生成网格路线的代表，拿来做快速概念验证；一个是程序合成路线的开源项目，拿来做真正的参数化建模。

4.1 前置准备：跑 text-to-cad 之前你最好先知道自己缺什么

先说环境。这个领域的模型和纯 2D 的图像生成不同，它涉及三维数据，显存和内存是两大瓶颈。我实测下来：

• 推理单条文本描述：8GB 显存勉强能跑，12GB 比较舒服，24GB 非常稳。
• 微调/训练：哪怕只是微调一个轻量模型，也建议至少 24GB 显存。遇到过用 16GB 跑训练直接 OOM 的情况。
• 内存：处理点云采样、SDF 体素化、网格重建这些步骤，32GB 内存是起步，64GB 更从容。有几次卡在 16GB 内存上，数据加载到一半就崩了。
• 操作系统：Linux 是主流，Ubuntu 22.04 实测最省心。Windows 也能跑，但编译一些 CUDA 扩展的麻烦程度会高不少。

数据集方面，如果想做微调，常用的公开数据集有 ABC 数据集（100 万个 CAD 模型的参数化表示）、DeepCAD 数据集（从 Fusion 360 里导出的真实建模操作序列）、Fusion 360 Gallery 数据集。下载的时候注意，ABC 数据集完整版非常大，如果你只是想跑通流程，先用 subset 后缀的版本，不要一上来就全量下载。

4.2 实操一：用生成式路线跑通一个“文本到网格”流程

我选择的开源项目是 3D-LDM 的简化版本，这是一个基于潜在扩散模型的 3D 生成框架。流程不长，但每步都有门槛。

第一步：搭建环境。用 conda 建虚拟环境，Python 3.9，torch 2.0.1，CUDA 11.8。这一步问题不大，照着 README 走就行。我遇到的坑是 torch 版本和项目要求的版本不一致，导致后面加载预训练权重的时候 key 不匹配，直接报错。老老实实按 README 指定的版本装，一步都别自作聪明。

第二步：下载预训练权重。检查了一下，模型权重大约 2GB，下载速度看网络。下载完成后做一次 SHA 校验，我当时跳过了这一步，结果模型加载了一堆乱权重，生成出来的模型全是噪声点云，排查了整整一个晚上才意识到是下载损坏。

第三步：写一条推理命令。基本上是：

python inference.py --text "a cylindrical container with a lid" --output results/ --save_mesh

跑了大概三分钟，显存最高 11GB，加载模型的那一下会冲到峰值，后面生成过程反而平稳。输出是一个 PLY 网格文件加一个渲染预览图。我打开看了一眼，说实话不算惊艳，形状大致对，但细节不行——圆柱体表面有起伏，盖子边缘不整齐，整体像是一个“有点感冒的圆柱杯子”。

第四步：做网格处理。生成出来的网格非常粗糙，顶点数量庞大，但拓扑结构有问题：有洞、有非流形边、有自相交。直接拿去 3D 打印是万万不行的。通常得走一遍 MeshLab 或者 Blender 里的 remesh + repair 流程。我试过用 pyvista 做 taubin smooth，用 open3d 做 poisson 重建，效果稍有改善，但距离工程可用还很远。

第五步：导出第三方格式。这个项目支持导出 STL，可以直接拖进 Cura 或 Bambu Studio 做 3D 打印切片。但如果你要把模型导入 Fusion 360 继续编辑，STL 进去只能当 mesh 参考，没法转成特征树——它会变成一个实体 mesh body，但不可编辑参数。这是生成式路线的天然天花板，不是模型调参能解决的。

实测下来，生成式路线解决“有没有”问题很快，但要达到“能不能用”还差很远。当概念验证、当可视化展示用，可以。当工程交付物，不行。

4.3 实操二：用程序合成式路线跑通“文本到 CAD”流程

这一步才是真正让我 impressed 的体验。我跑的是 Text2CAD 的一个开源实现，核心逻辑是：先把文本描述转成紧凑的 DSL（CadQuery 脚本），再用 CadQuery 在本地生成参数化实体模型。

具体流程是这样：

第一步：准备环境。CadQuery 2.x，pythonocc-core，这是两个大头。安装 pythonocc 的时候，conda 直接安装最稳：

conda install -c conda-forge pythonocc-core pip install cadquery

这里遇到的坑是 pythonocc 版本兼容性问题——某些版本和 cadquery 依赖的 OCC 版本不一致，运行时会出现奇怪的段错误。实测 conda 一起装他们俩，比分开装稳定得多。

第二步：用模型生成 CadQuery 脚本。项目提供了基于 LLaMA-2 微调的权重，推理起来不算慢，7B 模型在 24GB 显存上能跑，量化版在 16GB 也没问题。运行命令大致长这样：

python generate.py --text "bracket with 3 holes for mounting"

输出的结果是一段 CadQuery 风格的 Python 代码，包含 Create Workplane、Rect、Hole、Extrude 调用和一个最终show_object命令。

第三步：执行脚本生成实体。将生成的代码存成generated.py，直接运行：

python generated.py

CadQuery 会渲染出一个三维预览，同时也导出了 STEP 文件。这一步体验特别好的地方在于：整个模型不是三角面片拼成的，而是真正的参数化实体。拿这个 STEP 文件丢进 SolidWorks 或者 Fusion 360，打开之后能看到完整特征树，每个拉伸、圆孔、倒角都能分别编辑。

我实测的文本是“a rectangular base plate 100x50x10mm with four holes at the corners”。生成结果是：

• 对应 100x50x10 的底板主体：正确
• 四个角上的通孔：位置正确，但孔直径给了 5mm，我预期 8mm
• 倒角：没有生成，无所谓
• 脚本运行：一次通过，没报错

这说明系统能理解空间描述和常见机械零件结构，但在尺寸参数上还没有做到精确对齐文本中的具体数值。生成的代码可以手动调整，好在 CadQuery 脚本是纯 Python，改两个数字重新运行，模型立刻更新。这个过程对工程师来说非常舒服，比起“AI 给你一个雕塑你再逆向成建模”，这种“AI 给你草稿你再改参数”的模式要实用得多。

第四步：精度验证。把生成的模型导出成 STEP 后，用 FreeCAD 打开测量了一下关键尺寸。底盘厚度方向 10mm 完全精确，四个孔的孔距在 5 微米误差范围内。边缘的垂直度、面平面度都有保证——因为这不是多边形近似，而是数学精确的实体模型。这个精度对绝大多数机械应用已经绰绰有余。

整体评价：程序合成式路线在做非标零件初稿方面，已经达到了“工程师可以接手继续干活”的水平。它离“一键生成完美图纸”还很远，但作为 a 协助起草的角色，已经能省掉一多半从零画图的时间。

5. 结果怎么评估：别被“看着像”蒙蔽了双眼

text-to-cad 领域有一个很常见但非常危险的评估误区：人眼看渲染图觉得像，就认为模型效果好。这个误区在 2D 图像生成那里问题不大——图片就是给人看的。但在 CAD 领域，“看着像”和“能用”之间隔着一道巨大的鸿沟。

5.1 学术指标和工程指标的脱节

学术论文里常用的几个指标：

• Chamfer Distance：计算生成点云和标准点云之间的平均最近离差。越低越好，但它衡量的是“形状相似度”，完全不衡量功能可用性。两个形状肉眼看起来接近，但一个有内部空腔、一个没有，Chamfer 可能差不多，实际工程意义完全不在一个档次。
• IoU（Intersection over Union）：衡量生成和真实模型重叠体积的比例。对体素化数据比较常用，但它的分辨率限制了精细几何的评价能力。
• FID（Fréchet Inception Distance）：原本是评估图像生成质量用的，把生成的渲染图拿去算特征分布距离。这个指标非常“图学”化，它能反映“渲染出来看着真不真”，但渲染得真不代表几何上能加工得出来。
• 成功率：程序合成路线常用，指生成的 CAD 脚本能成功执行的比例。这个指标很有实际意义——脚本直接报错等于什么都没有。

学术指标不是没用，但你在看论文的时候要清楚每个指标到底在测什么。

5.2 工程上真正要看的五个维度

我自己在实际项目中评估 text-to-cad 的效果，基本只看五个维度：

第一，几何正确性。模型是否闭环？有没有流失、非流形边、自相交？在网格模型里，这种问题很常见；在参数化 CAD 模型里，基本不会出现，因为实体运算本身保证了必有体积和边界。

第二，尺寸准确性。生成的模型尺寸是否符合文本描述？文本说“100mm 长”，实际生成的是 102mm 还是 98mm？针对程序合成路线，一般要手动抽测 5-10 个关键尺寸。

第三，特征可编辑性。你能不能在 CAD 软件里修改这个模型？如果生成的是 STL 网格，这个维度直接不及格；如果是 CadQuery 脚本，修改参数极其方便，分数就高。

第四，语义对齐。文本说“四个孔”，生成的是不是四个孔？“法兰盘”的要求生成了“圆盘”但没孔，意味着语义理解失败。这个维度要看人工判定的准确率，目前程序合成路线在这个维度已经做得不错，生成网格的路线还经常翻车。

第五，制造可行性。模型能不能被实际加工出来？有没有壁厚为零的薄片？有没有超过最小刀具半径的内直角？这需要下游 CAM 软件的模拟配合，属于更严格的要求。

5.3 为什么“图看着像”不等于“工程能用”

举一个我真实遇到的案例。用某个生成式模型给“a small enclosure box with mounting holes on the bottom”生成模型。渲染图看起来完全没问题，有底有盖有孔。但把模型导出成 STL，准备做 3D 打印的时候，切片软件报警，提示内部有非流形结构和孤立面片。用 MeshLab 检查，发现模型的内部有一层残面，是 SDF 场判断错误的产物，导致实体变成了“表面封闭但内部有杂质”的状态。

还有人拿生成式模型的输出去做 CNC 加工，结果更惨——模型的表面是自由曲面，过渡不够光顺，刀具路径出来之后表面质量非常差。对机械加工来说，平面就是平面，圆柱面就是圆柱面，不能全是贝塞尔面片的近似。

这些案例说到底是一个道理：网格模型的视觉呈现只要“看起来像”就过关，但工程制造要的是数学上精确的几何描述——平面度、垂直度、圆柱度、厚度均匀性。SDF 场抽取出来的网格，表面上三角形的密度不均匀，重新拟合的特征边界必然有误差。而参数化模型是数学表述，每一个面、每一条边都有精确的几何定义，这才配得上“CAD”这三个字母。

6. 踩坑清单与排查实录：我在跑 text-to-cad 时踩过的一串坑

实操部分最后，把我在折腾过程中遇到的高频问题整理出来。这些不是论文里写的，是真正跑代码、调模型、导文件时踩过的坑。

6.1 显存爆掉的两个节点

第一个爆点发生在模型加载阶段。推理时先加载预训练权重，再加载文本编码器，两个模型加起来显存瞬间被占满。看起来是“只用十几 GB 显存”，实际上峰值跑到 20GB 以上。对策是分批加载，先加载完主干模型并做 warm-up，再加载文本编码器，用完之后释放。实测峰值显存降低了大约 30%。

第二个爆点发生在网格重建阶段（marching cubes）。生成 SDF 场的时候，要在一个 128 立方体体素网格上逐点推断 SDF 值，这个阶段需要把所有结果存储在 GPU 上。分辨率稍微一调高就从 128 变成 256，显存需求暴涨 8 倍，直接爆。对策是把 SDF 场分块计算，每块 32 立方体做完就落盘，用时间换空间。损失是速度会慢一半左右，但至少不会被 OOM 卡死。

6.2 文本编码器和几何生成的“两张皮”

很多生成式模型用的是 CLIP 文本编码器，这个词表偏向自然图像描述，对机械工程术语的理解非常贫乏。你输入“M6 threaded hole”，CLIP 可能完全抓不住“螺纹孔”这个关键语义，生成结果自然没有螺纹特征。

这个问题的根本原因是：CLIP 的训练数据里自然图片多、工程图纸少，文本-图像匹配关系训练充分，文本-工程几何匹配关系基本没训练过。要缓解这个问题，需要额外收集工程领域的图文对做微调，或者换用针对三维领域预训练的文本编码器。实测下来效果最明显的改善是用基于 Sentence-Transformer 扩词表的方式，把“threaded”“bore”“counterbore”“chamfer”这类工艺术语单独拉出来做强特征。

6.3 数据集下载和预处理的两个坑

ABC 数据集的 STEP 文件下载后，默认是纯粹的 B-Rep 几何，没有语义标注。把它转成 CadQuery 脚本需要经过一个反向建模过程（从 B-Rep 推断建模特征序列），这一步误差极大，论文里得出的成功率 8 成左右，我自己复现只有 6 成。DeepCAD 数据集问题不同：它是从 Fusion 360 导出的操作序列，但这个导出的序列有时包含面选、边选等交互上下文，转成纯 DSL 脚本后需要处理历史依赖。

补救的办法只有一个：数据清洗阶段多花时间。不要直接用原始数据训练，先做一轮特征序列合法性校验——有没有未定义的面引用、有没有重叠的布尔操作、有没有超出边界的拉伸。这一步能过滤掉大约 10% 的低质量样本，对模型最终效果提升明显。

6.4 STEP 导入国产 CAD 软件的小概率冲突

在将生成的 STEP 文件导入到常用的 CAD 软件中时，偶尔遇到显示实体缺失或面片撕裂的情况。这大概率是 STEP 文件解析器的兼容性问题——不同软件对 B-Rep 里自由曲面、混合曲面（sweep blend）的解析支持不一致。遇到这种情况，优先把模型重新导出为 STEP AP214 格式，再做一次实体修复（heal），大部分问题能解决。如果还不行，转换到 IGES 格式基本能兜底。

6.5 一个提示词写得不好的典型反面教材

我一开始用非常简短的描述：“a gear”。系统生成出来的东西，其实算不上一根实际可用的齿轮——没有齿廓渐开线、没有中心孔、没有键槽，泛泛地说，这就是一个圆柱上切了几个槽。

换成“a spur gear with 12 teeth, module 2, 20mm thickness, 8mm center hole with keyway”之后，程序合成路线输入理解得还不错，出来的模型有整体参数化的齿形，也不是很完美，但至少放进装配空间里有基本功能结构。这说明 text-to-cad 是非常吃提示词质量的领域，为了让系统理解得更准确，补足参数字段在文本里，意义很大。

提示词书写的经验规律：长度通常在 20-60 词之间效果好；要么明确写尺寸数字，要么写功能结构名称和专业术语；不确定的关键参数，用括号列出范围描述有时比模糊空泛表达更准确；对同一个模型多次生成时，固定格式做模板化提示词比自由口语效果好得多。

7. 这个方向往后会怎么走：三条可以明显看到的演进路径

虽然标题是 text-to-cad，但实际这个方向正在快速和邻域融合，未来两三年的走向有迹可循。

7.1 向多模态输入演进：文字只是入口之一

纯文本描述是有信息瓶颈的。你说“类似这个形状，但要改大一点”——很难用文字表达成精确指令。更好的交互方式是：给一张参考图 + 一段文本描述 + 拖动几个滑轨控制参数。现在已经有项目在做这个方向，把 CLIP 图像编码器和文本编码器拼接，一起作为条件输入到生成模型。这样的优势是：参考图的几何特征和文本的语义约束互补，生成结果既保留了意图的相似性，又能满足新描述的需求。

7.2 与 LLM 深度耦合：从“生成一个模型”到“完成一个设计任务”

现在的大语言模型除了生成文本，还能完成多步推理。把这个能力和 CAD 建模结合，就能构建一个“AI 设计助手”的闭环：用户说“设计一个电机支架，能承受 5kg 负载”，LLM 把它拆解成结构设计步骤——先确定安装孔距、再定底板尺寸、然后设计加强筋——每一个步骤调用底层的程序合成模型或者参数化模板库，最后组装成完整装配体。这种从“单模型生成”到“多步骤设计”的跨越，会大大提升自动化设计的适用范围。

7.3 可微 CAD：让几何优化直接跑在参数化模型上

目前生成 CAD 脚本的痛点是：脚本生成完之后，如果尺寸不对，只能手动改代码。但下一步的技术方向是让 CAD 模型本身变得可微——每一根尺寸参数都作为可导变量，损失函数可以直接从下游仿真结果（比如应力分析、流体分析）反传回来调整参数。这意味着“AI 设计 → 仿真验证 → 自动改尺寸”可以自动化循环，整个设计迭代的时间会大幅缩短。已经有几篇论文在做把 BREP 参数和海伦-肖普混合仿真结合，虽然还在早期，但方向已经很明确了。

我对普通从业者的建议是：不用等到这些方向完全成熟再入局，现在开始理解 text-to-cad 的底层逻辑——文本到三维数据的映射、参数化建模的程序表示、评估指标的真实含义——等下一波工具成熟的时候，你已经有足够经验去判断哪些能直接用、哪些还只是论文里的演示。

最后再说一个我在实际使用中的小心得。无论是哪条路线、哪个项目，先把输出格式和下游需求匹配好，再谈效果好坏。如果你只是要一个工业零件的初稿方案，直接跑程序合成式；如果你是要为数控加工做一套异形夹具设计，评估思路各有侧重，好在都逃不过本章讲的那五个工程维度。这比追着 demo 视频反复调提示词要靠谱得多。