1. 从一句话到三维模型：text-to-cad 到底在解决什么问题
第一次听到 “text-to-cad” 这个说法，是在一个做机械设计的朋友那里。他当时正对着屏幕上一堆拉伸、旋转、倒角特征发愁，嘴里念叨着：“要是能直接打一行字就出模型，谁还愿意天天跟草图约束较劲。” 这句话其实点到了 text-to-cad 的核心——把自然语言描述直接转换成计算机辅助设计模型。它不是简单的“语音输入命令”，而是让机器理解“一个直径 50 毫米、壁厚 3 毫米、带四个安装孔的圆盘”这种描述，然后自动生成对应的三维实体。
这个方向最近一年热度上升得很快，原因也很直接：传统 CAD 建模的门槛太高。一个没有系统学过参数化建模的人，哪怕脑子里有清晰的结构，也很难在软件里把它准确表达出来。而 text-to-cad 试图把“表达”和“建模”这两件事拆开，让描述归描述，几何归几何。它适合谁呢？我观察下来有三类人最受益：一是产品经理或工业设计前期人员，需要快速把想法变成可讨论的模型；二是机械、建筑、土木等专业的学生，做课程设计时可以用它快速验证尺寸方案；三是自动化脚本开发者，想把批量建模任务用文本指令串起来。
但这里必须先把预期说清楚。text-to-cad 目前并不是“你说什么它就完美生成什么”，它更像一个理解能力不错但经验不足的建模助手。你给它的描述越结构化、越接近工程语言，它返回的结果就越靠谱。如果只是丢一句“做个好看的支架”，那大概率会得到一个四不像。所以这篇文章我会从整体设计思路、核心细节、实操流程、常见问题四个层面，把 text-to-cad 这件事拆开讲透，尽量让你看完就能自己动手试。
2. 整体设计思路与方案选型：为什么不是“直接生成”那么简单
2.1 自然语言到几何的中间层设计
很多人以为 text-to-cad 就是一个大模型直接输出 STL 文件，实际上中间至少隔着两层转换。第一层是语义解析，把“直径 50 毫米、厚 10 毫米的圆盘”解析成结构化参数：形状类型是圆柱，半径 25，高度 10。第二层是几何构建，把这些参数翻译成 CAD 内核能执行的建模操作，比如拉伸一个圆草图，或者直接创建一个圆柱体特征。
为什么要有中间层？因为自然语言是模糊的，而几何是精确的。如果让模型直接从文本跳到网格顶点，误差会非常大，而且没法修改。中间层的作用就是留出“可编辑”的空间。我试过几种不同的实现路径，目前比较稳的是“文本 → 结构化 JSON → 参数化建模脚本 → 实体模型”这条链路。JSON 里存的是尺寸、位置、特征类型，脚本负责调用 CAD 内核，这样哪怕后面发现某个孔位偏了，改 JSON 里的数值就行，不用重新生成整个模型。
2.2 为什么选择参数化建模而不是直接网格生成
这里涉及一个关键取舍。直接生成三角网格（比如用某些三维生成模型）看起来更“AI”，但实际用起来很痛苦。网格模型没有特征历史，你想把直径从 50 改成 55，整个网格都得重新算，而且孔位、倒角这些细节很容易糊掉。参数化建模则保留了特征树，改一个尺寸，相关的圆角、阵列会自动更新。
我个人的经验是，text-to-cad 如果面向工程用途，必须走参数化路线。哪怕初期生成的模型简单一点，只要特征树是干净的，后面手动微调的成本就低很多。反过来，如果只是做视觉展示，网格生成也能凑合，但那就偏离了 CAD 的本意。所以我在方案设计时，优先保证输出的模型带有可编辑的特征历史，而不是一个死网格。
2.3 工具链选型：解析、建模、导出各用什么
解析层我试过两种方案。一种是直接用通用大语言模型做 few-shot 提示，让它输出 JSON；另一种是训练一个小型序列标注模型，专门抽尺寸和形状词。前者上手快，但稳定性一般，尤其是遇到“四个孔均匀分布”这种需要推理的描述时容易漏。后者需要标注数据，但一旦训好，解析准确率会高很多。对于个人开发者，我建议先用通用模型加规则校验，等场景固定了再考虑专用模型。
建模层选择比较多。如果追求轻量，可以用 OpenSCAD 这类脚本化建模工具，它的语法简单，适合做快速验证。如果要求工程级精度和特征树，那就得用支持 API 的 CAD 内核，比如一些开源几何内核或者商业软件的二次开发接口。导出层相对简单，STL 用于 3D 打印，STEP 用于后续装配，OBJ 用于渲染，按需选择就行。
注意：不要一上来就追求“全自动”。我见过不少项目卡在解析层，就是因为想一步到位处理所有描述。先把范围收窄到“轴、盘、板、支架”这几类常见零件，跑通闭环再扩展，成功率会高很多。
3. 核心细节解析与实操要点：描述怎么写、参数怎么定
3.1 文本描述的结构化模板
如果你想让 text-to-cad 稳定输出，描述就不能太随意。我总结了一个四段式模板：形状主体 + 关键尺寸 + 附加特征 + 位置关系。举个例子：“一个圆柱体，直径 60 毫米，高度 20 毫米，中心有一个直径 10 毫米的通孔，外缘倒角 2 毫米。” 这句话里，形状主体是圆柱，关键尺寸是直径和高度，附加特征是通孔和倒角，位置关系是“中心”和“外缘”。
为什么这个顺序有效？因为解析模型在处理时，会先确定基础几何，再往上叠加特征。如果顺序乱了，比如先说孔再说圆柱，模型可能先创建一个孔特征，再试图把它合并到还不存在的圆柱上，结果就报错。我实测下来，按“先主体后细节”的顺序写，解析成功率能提高不少。
3.2 尺寸与公差的表达方式
工程描述里经常出现“大约”“差不多”这种词，但在 text-to-cad 里，模糊词是灾难。模型不知道“大约 50”是 48 还是 52。所以描述尺寸时，尽量给确定值。如果确实需要公差，可以写成“直径 50 毫米，公差正负 0.1 毫米”，让解析层把公差单独存成一个字段，而不是混在尺寸里。
另外，单位要统一。我遇到过有人写“直径 2 英寸，高度 50 毫米”，结果模型按默认单位混算，出来的比例完全不对。建议在描述开头就声明单位制，比如“以下尺寸均为毫米”，或者在 JSON 里给每个数值带上单位字段。这个细节看起来小，但实际项目中因为单位问题返工的情况非常多。
3.3 特征叠加的顺序与依赖关系
一个零件往往有多个特征：拉伸、切除、阵列、倒角、抽壳。这些特征之间有依赖关系。比如你要在板上打四个孔，必须先有板，才能打孔；你要给孔加倒角，必须先有孔。解析层如果能把特征按依赖关系排成有序列表，建模脚本就能按顺序执行。
我在实现时用了一个简单办法：给每个特征打上“依赖标签”。比如“板”是基础特征，依赖为空；“孔”依赖“板”；“倒角”依赖“孔”。然后做一个拓扑排序，确保执行顺序正确。这个逻辑不复杂，但能避免很多“特征找不到父级”的错误。
3.4 常见形状的参数量化对照
为了让你更直观地理解描述和参数之间的对应关系，我整理了一个常用形状的对照表。这张表是我在实际解析中反复验证过的，可以直接作为模板参考。
| 描述关键词 | 形状类型 | 核心参数 | 常见附加特征 |
|---|---|---|---|
| 圆盘、圆柱 | 圆柱体 | 直径、高度 | 中心孔、外缘倒角 |
| 板、方块 | 长方体 | 长、宽、高 | 安装孔、圆角 |
| 支架、L 形 | 拉伸体 | 轮廓尺寸、厚度 | 加强筋、螺栓孔 |
| 轴、阶梯轴 | 旋转体 | 各段直径、长度 | 键槽、退刀槽 |
| 法兰 | 圆柱+孔阵列 | 外径、内径、厚度 | 均布孔、密封槽 |
这张表的价值在于，它把自然语言里最常见的几个词和几何参数直接挂上了钩。你写描述时对着表检查一遍，基本不会漏掉关键尺寸。
4. 实操过程与核心环节实现：从零跑通一个 text-to-cad 流程
4.1 环境准备与依赖安装
假设你是一个开发者，想自己搭一个最小可用的 text-to-cad 流程。我建议从 Python 环境开始，因为解析和脚本生成用 Python 最顺手。需要装的东西不多：一个 HTTP 请求库用来调用解析模型，一个几何内核的 Python 绑定用来建模，再加一个 JSON 处理库。
具体来说，几何内核我选的是支持脚本化建模的开源方案，安装方式通常是 pip 安装对应的包。如果你用的是 OpenSCAD 路线，那就装它的 Python 封装，或者直接生成 .scad 文件再调用命令行渲染。两条路我都走过，OpenSCAD 路线更轻，适合快速验证；内核路线更重，但特征树更规范。
提示：安装几何内核时注意版本兼容性。我踩过一次坑，新版本改了 API 名称，旧脚本直接报错。建议锁定版本号，别用 latest。
4.2 解析层的提示词设计与校验
解析层是整个流程里最不确定的一环。我的做法是给通用大模型一个明确的系统提示，要求它只输出 JSON，并且 JSON 的 schema 固定。schema 里包含：shape_type、dimensions、features 数组、units。features 数组里每个元素有 type、params、depends_on。
提示词里我会放两到三个示例，覆盖圆柱和板两类。示例的作用是让模型知道“直径”对应 diameter，“通孔”对应 hole。然后加一条规则：如果描述里缺少必要尺寸，就在 JSON 里把该字段设为 null，并附加一个 warning 字段。这样后续脚本可以检查 null 并提示用户补充，而不是瞎猜一个值。
校验环节我写了几个断言：直径必须大于 0，高度必须大于 0，孔的数量必须是整数。这些简单校验能拦掉大部分明显错误。实测下来，加了校验之后，下游建模脚本的报错率下降了一半以上。
4.3 建模脚本的生成与执行
拿到 JSON 之后，下一步是生成建模脚本。以圆柱体为例，脚本逻辑大概是：先创建一个圆草图，直径取自 JSON 的 diameter；然后拉伸，高度取自 height；如果有中心孔，就在同一草图上再画一个圆，直径取自 hole diameter，然后切除；如果有倒角，就选外缘边，执行倒角操作，半径取自 chamfer。
这里的关键是特征顺序。我一般按“基础体 → 切除特征 → 修饰特征”来排。基础体是拉伸或旋转，切除特征是孔、槽，修饰特征是倒角、圆角。这个顺序符合大多数 CAD 软件的建模习惯，也容易调试。
执行脚本时，我会把中间结果保存成 STEP 文件，方便后续用其他软件打开检查。如果只是快速预览，就导出 STL 丢进切片软件看一眼。两种导出我都保留，因为 STEP 能看特征树，STL 能看实际形状。
4.4 一个完整案例：带法兰的轴套
为了让你看到全流程，我拿一个实际例子走一遍。描述是：“一个轴套，外径 40 毫米，内径 20 毫米，长度 60 毫米，一端有一个法兰，法兰外径 80 毫米，厚度 10 毫米，法兰上均匀分布 6 个直径 8 毫米的孔，孔中心圆直径 65 毫米。”
解析层输出的 JSON 大致是：shape_type 为 revolve，主体轮廓是外径 40、内径 20、长 60 的圆筒；features 里第一个是法兰，依赖主体，参数是外径 80、厚度 10；第二个是孔阵列，依赖法兰，参数是孔径 8、数量 6、分布圆直径 65。
建模脚本按顺序执行：先旋转生成圆筒，再在端面拉伸法兰，然后在法兰上打第一个孔，再绕中心轴阵列 6 个。最后导出 STEP。整个过程如果解析准确，脚本执行不到两秒。我实测过十几次，只要描述里尺寸齐全，成功率在八成以上。失败的两次都是因为“均匀分布”被解析成了角度参数而不是数量参数，后来我在提示词里明确“均匀分布”对应 count 字段，问题就解决了。
5. 常见问题与排查技巧实录：那些文档里不会写的坑
5.1 解析结果与预期不符怎么排查
最常见的问题是解析出来的尺寸对不上。比如你写“直径 50”，结果 JSON 里是 25。这种情况多半是模型把直径当成了半径。排查方法很简单：在解析层输出 JSON 后，先打印出来看一眼，别急着往下走。如果发现半径直径混淆，就在提示词里加一句“diameter 表示直径，不是半径”，并给一个示例。
另一个高频问题是特征丢失。比如你写了“带四个孔”，结果 JSON 里 features 是空的。这通常是因为描述里孔的信息不够明确，模型不确定是通孔还是盲孔，干脆就不输出了。解决办法是把孔的描述写完整：“四个直径 6 毫米的通孔，中心距 40 毫米，呈矩形分布。” 信息越全，解析越稳。
5.2 建模脚本报错的典型原因
脚本报错里，最常见的是“特征依赖不存在”。比如倒角特征依赖的边，在前面的步骤里根本没生成。这往往是因为解析层把特征顺序排错了，或者某个特征被跳过了。我的排查习惯是：在脚本里每个特征执行前打印一行日志，标明当前特征类型和依赖对象。一旦报错，看日志就能定位到是哪个特征的前置条件没满足。
还有一种报错是单位不一致导致的尺寸溢出。比如把英寸当毫米，模型尺寸直接放大 25 倍，几何内核可能因为数值过大而报错。预防办法是在解析层强制统一单位，所有尺寸在进入建模脚本前都转换成毫米。
5.3 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决技巧 |
|---|---|---|---|
| 尺寸偏差一倍 | 半径直径混淆 | 检查 JSON 字段名 | 提示词明确 diameter 含义 |
| 特征丢失 | 描述信息不全 | 查看 features 数组 | 补全孔类型、分布方式 |
| 脚本报依赖错误 | 特征顺序错乱 | 打印特征执行日志 | 加依赖标签并拓扑排序 |
| 模型比例异常 | 单位不统一 | 检查 units 字段 | 强制转换为毫米 |
| 倒角失败 | 边选择不明确 | 确认边 ID 或选择规则 | 用外缘/内缘等明确描述 |
这张表是我在实际调试中一点点攒出来的，基本上覆盖了八成以上的常见故障。你遇到新问题时，也可以按这个思路往表里加行，慢慢就形成自己的排查手册了。
5.4 提升成功率的三个实操心得
第一个心得是“先简后繁”。别一上来就描述复杂装配体，先从单个零件开始，把解析和建模链路跑顺。等单零件稳定了，再尝试多零件和装配关系。我见过有人直接写“一个减速箱”，结果解析层直接懵了，因为减速箱涉及几十个零件和配合关系，远超当前 text-to-cad 的能力边界。
第二个心得是“描述里带尺寸基准”。比如“以底面中心为原点”，这样解析层能确定位置关系的参考点。没有基准，孔位、凸台位置就只能靠猜，结果往往偏得离谱。
第三个心得是“保留中间 JSON”。每次解析完，把 JSON 存下来。这样即使建模失败，你也能手动改 JSON 再重跑，不用重新调模型。时间长了，这些 JSON 还能当训练数据，用来微调解析模型。
6. 影响范围与扩展方向：text-to-cad 能走多远
6.1 对个人开发者的效率提升
从我自己的使用体验来看，text-to-cad 最大的价值是缩短了“想法到模型”的路径。以前做一个简单支架，画草图、标尺寸、拉伸、打孔、倒角，熟练工也得十分钟。现在写一段描述，解析加建模不到半分钟，剩下的时间可以花在检查尺寸和优化结构上。对于需要批量生成相似零件的场景，比如一系列不同直径的法兰，text-to-cad 的优势更明显——改几个数字就能生成新模型，不用重复劳动。
但也要清醒认识到，它目前替代不了熟练的 CAD 工程师。复杂曲面、自由造型、装配配合这些，还是得靠人工。text-to-cad 更适合做前期概念验证和标准化零件生成，把设计师从重复劳动里解放出来。
6.2 与现有 CAD 工作流的衔接
text-to-cad 生成的模型，最终还是要回到常规 CAD 软件里做后续处理。所以导出格式很关键。STEP 是首选，因为它保留了实体和特征信息，大部分 CAD 软件都能导入并继续编辑。如果只是 3D 打印，STL 就够了。我一般会同时导出 STEP 和 STL，STEP 存档，STL 预览。
另外，生成的模型最好带上命名规范。比如“法兰_外径80_厚10”，这样在装配体里容易识别。解析层可以在 JSON 里加一个 name 字段，建模脚本把它写到模型属性里。这个习惯能省掉后期大量重命名的时间。
6.3 后续可以扩展的能力
如果想把 text-to-cad 做得更实用，有几个方向值得尝试。一是支持尺寸链和约束，比如“孔 A 到孔 B 的距离是 30，孔 B 到边缘是 15”，让解析层能处理相对尺寸。二是接入标准件库，描述里写“M6 螺栓孔”，直接调用标准孔特征，不用每次指定孔径和深度。三是做批量生成，读一个 CSV 文件，每行一组参数，自动生成一系列模型。
这些扩展不需要推翻现有架构，只要在解析层和建模层之间加对应的处理模块就行。我目前正在试尺寸链这个方向，初步想法是在 JSON 里加一个 constraints 数组，记录尺寸之间的依赖关系，建模脚本按约束求解后再执行。等跑通了再单独写一篇分享。
6.4 一个值得注意的边界
最后说一个我踩过的坑。text-to-cad 生成的模型，尺寸精度取决于解析层的准确性。如果描述里写“直径 50”，解析层输出 50.0，建模脚本按 50.0 执行，那没问题。但如果解析层因为浮点处理输出 49.999999，虽然肉眼看不出来，但在后续装配时可能出问题。所以我在建模脚本里加了一步数值规整，把所有尺寸四舍五入到小数点后三位。这个细节不起眼，但能避免很多“明明尺寸对却装不上”的尴尬。
这个方向还在快速变化，工具和方案每隔几个月就有新的出来。我的建议是别追新，先把一条链路跑通，理解每个环节的原理，后面换工具也就是换个接口的事。真正值钱的是你对“描述到几何”这个转换过程的理解，而不是某个具体工具的使用方法。
