前两年我刚开始接触 text-to-cad 这个概念时，第一反应其实是“怀疑”。把一句自然语言变成能拿去加工、装配的三维模型，听起来更像科幻演示，不像工程现实。后来我自己搭了一套完整流程，从一句话生成法兰盘、支架、外壳，到导入商业 CAD 里做装配和出图，跑通之后我的判断彻底变了——这件事是能落地的，而且它解决的痛点非常具体。它并不是要取代传统 CAD 操作，而是把“语言理解”和“参数化建模”这两件本身就可靠的事，用工程化的方式串在一起，让三维建模的门槛和效率同时发生质变。
这篇文章我想从方案设计的角度完整拆一遍：text-to-cad 到底在解决什么问题、整套系统应该怎么搭、关键环节有哪些坑，以及什么场景真正值得用。
1. text-to-cad 到底在解决什么问题
1.1 传统 CAD 建模的痛点
传统 CAD 建模最大的问题不是“功能不够”，而是“操作和学习成本太高”。一个熟练工程师用鼠标键盘在界面里点选、拉伸、切除、打孔，完成一个中等复杂度的零件可能只需要十几分钟；但对于一个只做过简单三维设计的人来说，光是搞懂草图约束、基准面、特征树就够头疼的。哪怕是资深工程师，面对重复性很强的标准化零件——比如各种规格的法兰、垫片、支架——也得一次次重复同样的操作流程，只是尺寸不同而已。
更深层的问题在于“设计意图的传递”。很多非标设备的工程师手里有一张手写草图或者一段口头描述：“这里有个安装板，200 长 150 宽，四个角上打 6 个的孔”，但到了建模软件里，这些信息需要被翻译成一系列精确的几何操作。翻译过程中一旦理解偏差，做出来的模型和实际需求对不上，来回改模型的时间往往比新建一个还长。text-to-cad 就是从“翻译”这一环切入的：让机器直接理解自然语言里的尺寸、特征和约束，再自动生成对应的几何模型。
1.2 文本驱动建模的核心价值
核心价值可以归结为三句话：让小白能建模，让老手能提速，让设计意图有据可查。
对小白来说，输入“一个外径 60、内径 25、厚度 8 的法兰盘，带 6 个均布的安装孔，孔径 6，孔中心距 44”，远比打开软件学习怎么画圆、怎么拉伸、怎么阵列要直观得多。对老手来说，批量生成几十个不同规格的同类零件时，不需要再手动改特征参数，直接改文字描述重新生成即可。更重要的是，自然语言描述本身就是一种“参数化记录”，它比特征树更接近人类的表达习惯，后续做设计变更时，直接改一句话比在特征树里找参数可读性好太多了。
不过这里要强调一点：text-to-cad 的目标不是完全替代传统 CAD，而是填补“从需求到模型”之间的空白。最终的生产级模型仍然需要经过 CAD 软件的校验和加工工艺验证，这个边界我想清楚之后，整套方案的定位就明确了。
2. 从文字到模型：整体方案如何搭
2.1 方案选型：为什么是“大模型 + 脚本化建模”组合
我见过很多团队尝试直接让大模型输出三维网格文件（比如直接生成 STL 或 OBJ），目前这条路基本走不通。原因是三维网格数据量大、拓扑关系复杂，现有大模型在这类数据上的生成质量远不够稳定，而且生成的模型往往是不可编辑的“死模型”，没法继续做参数化修改。真正靠谱的路线是：让大模型理解自然语言，输出一段结构化的建模脚本，再由脚本化 CAD 内核执行这段脚本生成精确模型。
这个组合的本质是大模型擅长“语义到结构化信息的映射”，而脚本化建模内核擅长“精确的几何计算”。两者互补，彼此做自己最擅长的事。我用的大致分层是这样的：
- 语义层：大模型负责把自然语言意图解析成参数表，比如尺寸、数量、位置关系、特征类型。
- 表达层：根据参数表生成一段建模脚本，脚本调用内核提供的建模原语（圆柱、立方体、孔、阵列、布尔运算等）。
- 执行层：脚本化内核运行脚本，执行布尔运算和特征操作，输出带参数特征的模型文件。
为什么不用传统 CAD 的宏录制？宏录制确实也能生成脚本，但它需要你先在界面里手动操作一遍，操作过程无法回溯成自然语言。而大模型直接生成脚本，不需要任何前置操作，从零开始就能建模，灵活度完全不是一个级别。
2.2 数据流与模块拆解
我实际跑通的完整数据流大概是这样的：
- 用户输入一个描述语句，比如“生成一个 L 型支架，两个安装面分别长 80 和 60，宽 40，厚度 5，每个安装面上有两个直径 6 的安装孔，孔距 45 和 25”。
- 大模型对语句做意图解析，输出结构化 JSON 参数表，里面包含类型、尺寸、特征列表。
- 后端服务把 JSON 参数表映射到建模脚本模板上，填充参数并执行。
- 建模内核生成几何模型，导出为 STEP、STL 或原生脚本文件。
- 对模型做校验：检查体积、质量、特征数量、是否存在干涉。
这个流程里最关键的一环是第 2 步和第 3 步之间的“参数规范化”。大模型直接生成的 JSON 往往会出现字段名不一致、单位不统一、特征重复等问题。我在这两层之间加了一个“参数清洗”模块，做三件事：单位归一化（所有长度统一到毫米）、字段名映射（把“孔径”“直径”“打孔尺寸”这类同义表达映射到同一个字段）、范围校验（孔距不能大于板长，孔径不能大于外径）。
2.3 提示词设计技巧
提示词在这里不是写一段话就完事的。我试过几种模式，比较稳定的做法是给大模型定义一个输出模板，让它按模板填空。例如要求它“将用户的建模需求解析为 JSON，严格按照以下结构输出：part_type、length、width、height、features[]”。然后在系统提示里明确单位规则：“如果用户未说明单位，默认按毫米处理，并在直径类专业字段中保留一位小数”。
另外要特别处理“隐含特征”。用户说“四个角上打孔”时，实际上隐含了“孔到边距离相同”“对称分布”这些约束。我在提示词里要求模型把这类隐含信息显式化输出为约束字段，否则后续建模时孔的位置会完全随机。
3. 实操全流程：从一句话到可装配的零件
3.1 意图解析与参数抽取
以我之前做的一个模拟项目“某安装法兰 Demo”为例，用户输入的是：
“做一个圆形法兰，外径 60，内径 25，厚度 8，有 6 个均布安装孔，孔径 6，孔中心距 44，外圈倒角 1。”
这句话里包含了几个关键信息：零件类型是圆形法兰，核心尺寸有五个（外径、内径、厚度、孔径、孔中心距），还有一个隐含特征“倒角”，以及阵列信息“6 个均布”。解析成 JSON 大概是：
{ "part_type": "circular_flange", "outer_diameter": 60.0, "inner_diameter": 25.0, "thickness": 8.0, "features": [ { "type": "hole", "diameter": 6.0, "pattern": "circular", "count": 6, "pitch_circle_diameter": 44.0 }, { "type": "chamfer", "edge": "outer_periphery", "size": 1.0 } ] }这里最值得注意的坑是：大模型很容易把“孔中心距 44”理解成“孔分布在半径 44 的圆上”，但实际工程语义是“中心距直径 44”。我在后处理里对这类字段做了语义修正，如果同时出现 pitch_circle_diameter 和 outer_diameter，就校验一下逻辑关系：孔中心距直径必须小于外径减去孔径的一半，否则提示错误。
3.2 代码生成与几何构建
拿到结构化参数后，下一步是把 JSON 翻译成建模脚本。我用的是脚本化建模内核的编程接口，生成的脚本大致长这样：
import cadquery as cad # 半径计算 outer_r = 60.0 / 2 inner_r = 25.0 / 2 pcd_r = 44.0 / 2 hole_r = 6.0 / 2 # 构建法兰主体：外圆柱减去内圆柱 flange = cad.Workplane("XY").circle(outer_r).extrude(8.0) \ .faces(">Z").circle(inner_r).cutBlind(-8.0) # 在外表面上创建 6 个均布安装孔 flange = flange.faces(">Z").workplane() \ .pushPoints([(pcd_r, 0), (pcd_r * 0.5, pcd_r * 0.866), (-pcd_r * 0.5, pcd_r * 0.866), (-pcd_r, 0), (-pcd_r * 0.5, -pcd_r * 0.866), (pcd_r * 0.5, -pcd_r * 0.866)]) \ .circle(hole_r).cutBlind(-8.0) # 外圈倒角 flange = flange.edges("%CIRCLE").fillet(1.0) # 导出 flange.export("flange.step")这段脚本里有几个工程细节需要解释。首先是阵列点的计算：6 个孔均匀分布在圆周上，角度间隔是 60 度，坐标用三角函数算出来。这里如果用“极坐标阵列”内核原语会更简洁，但我故意展示手动计算点的写法，是因为实际生产中对孔位的相位角有特殊要求时，手动推点更可靠。其次是切割方向：cutBlind(-8.0)表示沿 Z 轴负方向切穿整个厚度，如果写成正方向，孔就会落在错误的一侧。最后是倒角：edges("%CIRCLE")会选中所有圆形边，包括外圈、内圈和孔边，这时候必须加额外的过滤条件只选中外圈边，否则所有圆边都会被倒角，内孔和安装孔边缘也会被错误倒掉。
3.3 后处理、校验与导出
脚本执行成功并不代表模型是对的。我见过脚本不报错但零件彻底加工不了的情况：孔没有切穿、倒角把安装面破坏了、布尔运算留下一堆碎面。所以后处理校验是必需环节，我一般做三步：
- 几何检查：用内核自带的检查工具确认模型是实体（solid）而非壳体（shell），检查有没有非流形边。
- 参数检查：回到 JSON 参数表，逐一核对最终模型的实体体积与理论体积的误差。法兰的理论体积公式是 π × (外径² − 内径²) / 4 × 厚度，如果是铸铁材质还能估算质量，偏差过大说明建模逻辑有错。
- 干涉检查：如果生成的零件要用于装配，我会用 STEP 文件在商业 CAD 里做一次装配干涉检查，确认孔位和配合尺寸没有问题。
导出格式的选择也值得说几句。我通常同时导出两种格式：STEP 用于后续 CAD 编辑和装配，STL 用于 3D 打印或快速渲染。STEP 保留的是 B-Rep 实体信息，能继续编辑；STL 是三角网格，只能看不能改。
4. 常见问题与排查技巧
4.1 单位、缺省与语义歧义
text-to-cad 最常见的翻车点就是单位问题。英文用户说“a 1-inch bolt”，中文用户说“一个 1 寸的法兰”，模型如果默认按毫米解析，结果会差 25.4 倍。我的方案是提示词里强制要求模型在参数表里附带单位字段，如果原文没写单位，默认毫米，同时在界面上向用户展示解析结果，让用户确认单位。
还有一个高频坑是“厚度”和“高度”的歧义。法兰盘的厚度 8 毫米，用户可能说成“高 8”，支架的“高 40”指的是立板高度而不是厚度。大模型经常混淆这两个语义。我在后处理里增加了一个规则：对圆形回转体类零件，“高度”默认映射到厚度，对方形支架类零件，“高度”映射到垂直于底面的尺寸。这个基于零件类型的语义映射，能大幅减少歧义错误。
4.2 几何约束冲突与特征失败
几何约束冲突基本上是建模失败的元凶。典型情况包括：孔径大于板宽、孔中心距大于板长、倒角尺寸大于板厚、阵列孔的分布圆大于零件外径。这些矛盾在自然语言描述里很容易被忽略，用户说“做一个 40 宽的板，打个直径 60 的孔”，这明显不现实，但大模型可能照样生成脚本，然后内核报错或者生成一个被切穿的残缺实体。
我的处理方法是建立一套“尺寸关系校验表”，在脚本执行之前先做逻辑判断。比如孔径必须小于板宽的一半，孔中心距直径必须小于外径减去孔径，倒角半径必须小于壁厚。一旦校验失败，直接返回错误提示给用户，而不是继续生成一个坏模型。这个前置校验让失败率显著下降。
4.3 脚本稳定性与异常数据
大模型生成的脚本还有一个问题：非确定性。同样一句话，每次生成的代码可能都不一样，有时候能用，有时候不能。我踩过一次坑，生成的脚本里多了一个无用的空操作，导致后续的特征顺序错乱，模型出来多了一个莫名其妙的凸台。后来我给脚本生成加了一道“模板约束”：所有常见零件类型都维护一套经过验证的脚本模板，大模型只负责填写参数变量，而不是自由编写整个脚本。这样一来，代码路径是固定的，大模型出错的范围被限制在参数层面，稳定性高了很多。
4.4 排查流程速查表
我把常见问题整理成一张表，方便排查：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 模型尺寸是需求的几十倍 | 单位解析错误，英制被当公制 | 检查单位字段，强制默认毫米并确认 |
| 孔没有穿透 | 切割深度正负号写反或深度不足 | 校验 cutBlind 方向与深度符号 |
| 倒角出现在所有圆边上 | 过滤器选择范围太宽 | 精确指定边类型或面拓扑 |
| 阵列孔位置不对 | 相位角计算错误或中心距直径半径混淆 | 重点检查 pitch circle 是直径还是半径 |
| 模型是一个壳体而非实体 | 布尔运算后未合并实体 | 运行实体修复工具重建闭环 |
| 脚本有时成功有时失败 | 大模型自由代码不稳定 | 切换为固定模板，只填参数不生成逻辑 |
| 某些特征完全缺失 | 自然语言中的隐含信息未被解析 | 调整提示词，要求显式输出特征列表 |
这张表不是全量清单，但覆盖了我在实际项目里遇到的最主要的几类问题。
5. 应用场景与能力边界
5.1 现在做得好、做得值的地方
目前 text-to-cad 最有实用价值的场景是标准化零件的批量生成。一个设备上往往有几十种规格不同的法兰、垫片、支架、过渡板，如果让工程师一个个画，要花一整天；用 text-to-cad 自动生成，配合参数表批量处理，几十分钟就能把模型全部产出来。虽然是模拟项目，但这个方法在非标设备设计的前期方案阶段非常好用。
第二个值得关注的场景是“跨软件协同”。我生成 STEP 之后，会在多个不同的 CAD 软件里打开检查，发现只要参数解析正确，STEP 文件在不同软件之间的兼容性相当稳定。这意味着 text-to-cad 可以作为一个前置模块嵌入现有设计流程，而不是替代设计流程本身。
教育场景也很有趣。给刚入门三维建模的学生展示“一句话建模”，能帮他们快速理解特征参数化思维。学生不需要花大量时间泡在菜单里，可以直接看到语义和几何之间的关系。
5.2 还做不好的事与改进方向
说句实话，text-to-cad 目前做不好的事情也很明显。
复杂自由曲面依旧是软肋。类似飞机机翼、汽车外饰这类 A 级曲面，用自然语言描述根本说不清楚，大模型也无从生成。现在只能做规则几何体组合，带一点圆角、倒角、放样已经是上限了。
多零件装配和配合关系也很难。描述里说“轴和孔过盈配合”，模型能生成两个零件，但配合公差、装配顺序、约束关系很难一次性表达完整。我实验过生成一个由 5 个零件组成的小装配体，结果是每个零件单独看都还行，放到一起就出现干涉和间隙不均。目前这个问题没有完美的解法，更可行的路线是让 text-to-cad 生成单件模型，再由装配模块用传统方式定义约束关系。
还有一个方向值得关注：把加工工艺知识纳入系统。比如同一个零件，用 3D 打印还是 CNC 加工，对倒角、壁厚、孔公差的要求完全不同。目前的系统不具备这个判断能力，生成出来的模型虽然几何正确，但不一定加工友好。让大模型在生成的同时附带“加工建议”标注，是后续非常值得做的扩展。
最后分享一个我从实践中得到的技巧：不要追求“一步到位”。text-to-cad 目前最合适的用法是先让它生成一个“接近正确”的初版模型，然后在 CAD 里做精细调整。设计师与其从零画图，不如在一个已经 80% 正确的模型上改尺寸和特征，效率会高非常多。整套流程跑下来，我认为 text-to-cad 不是要取代 CAD 的精确与严谨，而是把“需求到模型”这条路上最耗时的前期工作承担下来，让设计者把精力真正花在判断和优化上。
