text-to-cad 实战：从自然语言到三维几何的完整技术链路

1. 从一句话到三维模型：text-to-cad 到底在解决什么问题

第一次听到“text-to-cad”这个说法，很多人脑子里冒出来的画面是：对着电脑说一句“给我画个带四个安装孔的方形法兰盘”，屏幕上就自动生成一个可以导出加工的 STEP 文件。这个想象方向没错，但真正落地的时候，它解决的问题比“省几下鼠标”要深得多。

传统 CAD 建模的流程是这样的：你先在脑子里把零件想清楚，然后打开软件，选基准面、画草图、标尺寸、加约束、拉伸、倒角、打孔、做阵列。一个中等复杂度的零件，熟练工也得折腾二三十分钟，新手可能一上午就搭进去了。问题在于，大量零件其实是高度重复的——支架、法兰、垫片、外壳、连接件，它们的拓扑结构大同小异，变的只是几个关键尺寸。每次重新画一遍，本质上是在做机械劳动，而不是在设计。

text-to-cad 的核心价值，就是把这层“机械劳动”用自然语言描述替代掉。你用一句话或者一段结构化描述，把零件的关键特征和尺寸讲清楚，系统去负责生成对应的几何体。它适合谁？我梳理了三类人：

• 机械/结构工程师：手上有大量标准件、系列件要出图，想批量生成而不是一个个画。
• 产品经理和硬件创业者：需要快速把想法变成可视化的三维模型，用于沟通和验证，但不一定会用专业 CAD。
• 做自动化、脚本化建模的开发者：想把建模能力嵌到自己的工具链里，用代码或文本驱动几何生成。

这里必须先把一个预期管理讲清楚：text-to-cad 不是“你说人话，它给你一个能直接开模的完美零件”。它更像是一个“把结构化描述翻译成几何操作序列”的中间层。你描述得越接近工程语言，出来的结果越靠谱；你描述得越模糊，它就越容易给你一个“看起来像那么回事、但尺寸完全不能用”的东西。理解这一点，后面的所有实操你才不会跑偏。

我见过太多人第一次试用就丢一句“做一个好看的手机支架”，然后抱怨生成结果没法用。这不是工具的问题，是输入的问题。text-to-cad 的输入质量，直接决定了输出质量，这一点和写提示词做图像生成是一个道理，但三维几何对精度的要求比图像高一个数量级——图像差几个像素没人看得出来，模型差 0.5 毫米可能就装不进去。

所以这篇文章我会围绕几个核心问题展开：text-to-cad 背后的技术链路是怎么走的，自然语言描述要怎么组织才能被正确解析，从描述到几何体中间有哪些关键的转换环节，实际跑起来会遇到哪些坑，以及怎么把它接进自己的建模工作流里。全程按一个真正动手做过的人的角度来讲，不讲空话。

2. 拆解 text-to-cad 的技术链路：一句话是怎么变成几何体的

2.1 从自然语言到结构化参数：解析层在做什么

text-to-cad 的第一道关卡，是把“人话”变成“机器能算的参数”。这一步看起来简单，实际上是最容易出问题的地方。

假设你输入：“一个长 80 毫米、宽 60 毫米、厚 5 毫米的矩形板，四个角各有一个直径 6 毫米的圆孔，孔中心距离边缘 10 毫米。”

一个合格的解析层需要提取出这些信息：

这张表里的每一行，背后都对应 CAD 里一个具体的操作。解析层要做的，就是把这些自然语言片段映射成结构化的参数对象。常见的技术路线有两种：

一种是基于规则和正则的解析。工程师提前定义好一套语法模板，比如“长 X 宽 Y 厚 Z”对应外形尺寸，“直径 D”对应孔径。这种方案可控性强，但灵活性差，用户换个说法就可能解析失败。

另一种是基于大语言模型的语义解析。把用户输入丢给模型，让它输出一个 JSON 或者类似的结构化描述，再由后面的几何引擎去消费。这种方案灵活，能处理各种口语化表达，但稳定性依赖模型能力，而且需要做大量的输出校验——模型可能会“脑补”出你没说的尺寸。

实际项目里，靠谱的做法是两者结合：用模型做初步的语义理解，再用规则做参数校验和补全。比如用户没说厚度，规则层可以给一个默认值并明确提示“厚度未指定，已按 5 毫米处理”，而不是让模型随便编一个。

提示：解析层最怕的是“歧义”。比如“打一个孔”和“打一排孔”，数量完全不同；“圆角”和“倒角”是两个不同的特征。描述时尽量用工程术语，避免“弄圆一点”“搞个洞”这种模糊表达。

2.2 参数到几何：几何引擎的选型与调用逻辑

解析出参数之后，下一步是真正生成几何体。这一步离不开几何内核。目前主流的开源和商业几何内核有几类，选型直接决定了你的 text-to-cad 能做到什么程度。

第一类是 B-Rep（边界表示）内核，代表是 OpenCASCADE。它用精确的数学曲面来描述几何体，生成的模型精度高，能直接导出 STEP、IGES 这类工程格式，适合做真正要加工的零件。缺点是 API 复杂，学习曲线陡，布尔运算偶尔会失败。

第二类是网格内核，比如基于三角网格的方案。它生成的是 STL 那种由小三角形拼出来的模型，适合 3D 打印和可视化，但精度有限，不适合做需要精确尺寸标注的工程图。

第三类是参数化建模库，比如 CadQuery、build123d 这类基于 Python 的库。它们把 B-Rep 内核包装成更友好的 API，让你用代码描述几何。text-to-cad 的几何生成层，很多就是建立在这类库之上的。

我个人的选型建议是这样的：

• 如果目标是出工程图、做加工，必须选 B-Rep 路线，OpenCASCADE 或其封装库。
• 如果目标是快速可视化、3D 打印预览，网格路线够用，而且速度快。
• 如果目标是做自动化脚本建模，CadQuery 这类参数化库是首选，它的代码即模型的思路和 text-to-cad 天然契合。

调用逻辑上，解析层输出的参数对象会被翻译成几何库的 API 调用序列。比如“矩形板 + 四角打孔”会被翻译成：创建矩形草图 -> 拉伸成体 -> 在四个角位置创建圆草图 -> 切除 -> 返回实体。这个翻译过程，本质上是一个“参数到操作序列”的映射，通常用一个模板引擎或者规则引擎来实现。

2.3 为什么“描述顺序”会影响生成结果

这一点很多人没意识到：在 text-to-cad 里，你描述特征的顺序，会影响几何操作的执行顺序，而执行顺序会影响最终结果。

举个真实的例子。你要做一个“带凸台的底板”，凸台在底板上面。如果你先描述底板再描述凸台，系统会先拉伸底板，再在底板上叠加凸台，结果正确。但如果你先描述凸台再描述底板，有些实现会先建凸台，再建底板，然后做布尔并集——结果虽然也是对的，但如果底板和凸台有重叠区域，布尔运算的处理方式可能导致多余的边或者面。

更典型的是孔和倒角的关系。如果你先打孔再对孔的边缘倒角，和先对板边倒角再打孔，结果可能完全不同。前者会在孔口形成倒角环，后者不会。所以描述顺序不是随便写的，它对应着建模的特征树顺序。

我的经验是：按照“基体 -> 大特征 -> 小特征 -> 修饰特征”的顺序来描述。先讲整体形状和主要尺寸，再讲上面的凸台、凹槽，然后讲孔、螺纹，最后讲倒角、圆角这些修饰。这个顺序和大多数 CAD 软件里特征树的自然生长顺序是一致的，解析和生成都会更稳。

3. 把话说清楚：text-to-cad 的输入描述该怎么组织

3.1 一套可复用的描述模板

踩过几次坑之后，我总结出一个描述模板，基本上覆盖了大部分规则零件。你按这个结构去写，解析成功率会高很多：

1. 基体：形状 + 外形尺寸 + 厚度/高度。例如“矩形板，长 100 宽 80 厚 6”。
2. 主要特征：凸台、凹槽、台阶等。说明位置、尺寸、高度。
3. 孔特征：孔径、数量、排列方式、定位尺寸。
4. 修饰特征：圆角、倒角，说明位置和半径/尺寸。
5. 材料与单位：如果系统支持，补一句材料和单位，避免默认值不对。

用这个模板改写一下前面的例子：“矩形板，长 80 毫米，宽 60 毫米，厚 5 毫米。四个角各一个圆孔，直径 6 毫米，孔中心距相邻两边各 10 毫米。所有外角倒圆角 R3。”

这样一段描述，解析层几乎不需要猜，直接映射成参数就行。对比一下“做个板子，四角打孔，边弄圆”，后者的生成结果基本靠运气。

3.2 尺寸、公差、单位的表达陷阱

单位是 text-to-cad 里最隐蔽的坑之一。很多系统默认单位是毫米，但如果你描述里混用了“厘米”“米”“英寸”，解析层可能不会自动换算，而是直接取数字。你说“长 0.1 米”，它可能给你生成一个长 0.1 毫米的板子——差了三个数量级。

我的做法是：全程只用一种单位，并且在描述开头就声明。比如“以下尺寸单位均为毫米”。如果系统支持单位字段，优先用字段而不是在文本里写。

公差的问题更微妙。自然语言里说“直径 6 毫米”，在工程上其实是不完整的——6 毫米是名义尺寸，实际加工需要公差。但 text-to-cad 生成的是理想几何模型，公差通常不在建模阶段体现，而是在出工程图时标注。所以你在描述里不需要写公差，但心里要清楚：生成的模型是名义尺寸，不能直接当作加工依据，后续该标的公差还得标。

还有一个陷阱是尺寸链。你说“孔距边缘 10 毫米”，这个“边缘”指的是哪条边？如果板子有倒角，是倒角前的边还是倒角后的边？严谨的描述应该指明基准。比如“孔中心距板件理论边缘 10 毫米，倒角前”。这种细节在简单零件上无所谓，在复杂零件上就是装配失败的原因。

3.3 复杂特征的拆解策略：分步描述比一句话堆砌更可靠

当你面对一个复杂零件时，试图用一句话把所有特征说完，几乎必然失败。正确的做法是分步描述，逐步构建。

比如一个“带散热齿的安装座”，你可以这样拆：

第一步，描述基座：“矩形基座，长 120 宽 80 厚 10。” 第二步，描述安装孔：“基座四角各一个 M6 沉头孔，孔中心距边缘 12 毫米。” 第三步，描述散热齿：“基座上表面有 8 条平行散热齿，齿高 20 毫米，齿厚 3 毫米，齿间距 8 毫米，沿长度方向排列。” 第四步，描述修饰：“所有外露锐边倒角 C1。”

每一步生成后，你可以检查中间结果，确认无误再继续。这种“增量式建模”的思路，和传统 CAD 里一步步加特征是完全一致的，只是把鼠标操作换成了文字描述。

有些 text-to-cad 工具支持多轮对话，你可以先让它生成基座，看到结果后再说“在上面加散热齿”。这种交互方式比一次性描述一大段要可靠得多，因为每一步都有反馈，错了能及时纠正。

注意：分步描述时，每一步都要指明“在哪个面上操作”。三维空间里没有“上面”“旁边”这种绝对方向，最好用“上表面”“前侧面”“以底面为基准”这类明确的基准描述。

4. 实测中绕不开的坑：从解析失败到几何报错

4.1 解析层的典型失败模式

我在实际测试中遇到过几类高频的解析失败，列出来给你避坑：

第一类：数量词和尺寸词混淆。“四个直径 6 的孔”，解析层可能把“四”当成孔径的一部分，或者把“6”当成数量。解决办法是把数量和尺寸分开写：“孔数量 4，孔径 6 毫米”。

第二类：相对位置描述缺失。“打两个孔”，没说打在哪。有些系统会默认放在中心，有些会报错。必须补上定位信息。

第三类：否定和排除表达。“不要倒角”“除了左下角都打孔”，这类否定逻辑对解析层是难点。能不用就不用，改用正面描述：“仅左下角不打孔，其余三角打孔”。

第四类：复合单位。“长 8 厘米 5 毫米”，这种混合表达解析层基本处理不了。统一换算成“85 毫米”。

4.2 几何内核的布尔运算为什么会失败

即使解析完全正确，几何生成阶段也可能失败。最常见的是布尔运算失败，尤其是切除操作。

原因通常有几个：一是特征完全重合，比如你要在一个直径 6 的孔的位置再打一个直径 6 的孔，两个圆柱面完全贴合，布尔运算无法确定边界。二是特征相切，比如孔的边缘正好和板的边缘相切，切出来的几何体有零厚度区域，内核处理不了。三是数值精度问题，两个面之间的距离小于内核的容差，被当成同一个面。

排查这类问题的思路是：先简化，再定位。把复杂零件拆成最简单的基体，逐个加特征，看哪一步开始报错。报错的那一步，检查它的尺寸和位置是否和其他特征产生了重合、相切或过近的关系。解决办法通常是微调尺寸，比如把相切的孔往里挪 0.1 毫米，或者把重合的特征合并成一个。

4.3 生成结果“看起来对但尺寸不对”的排查链路

这是最让人头疼的一类问题：模型生成了，形状也对，但尺寸就是不对。我总结了一个排查链路，按顺序走：

1. 检查单位：导出模型测量一下，看是不是单位换算错了。
2. 检查基准：确认尺寸是从哪个基准算起的，是不是和你的预期一致。
3. 检查特征顺序：某些特征在布尔运算后可能被“吃掉”了一部分尺寸。
4. 检查默认值：你没指定的参数，系统用了什么默认值？是不是默认值不合理？
5. 检查数值精度：导出时的精度设置是否导致了尺寸舍入。

这个链路我走过很多次，大部分问题在前两步就能定位。单位问题占了一半以上，基准问题占了剩下的一半里的大半。

5. 把 text-to-cad 接进自己的工作流：几种落地方式

5.1 作为独立工具使用：适合快速验证想法

最简单的用法，就是把 text-to-cad 当成一个独立的生成工具。你输入描述，它输出模型文件，你拿去预览或者导入其他软件。这种方式适合产品经理快速验证外形，或者工程师在方案阶段快速出几个候选模型。

这种用法下，我建议把生成的模型统一导出成 STEP 格式，因为它的兼容性最好，主流 CAD 软件都能打开。如果只是看外形，STL 也行，但 STL 没有精确的尺寸信息，不能用来做后续的精确建模。

5.2 作为脚本库集成：批量生成系列件

如果你要生成的是系列件——比如同一款支架的五个不同长度版本——用脚本调用 text-to-cad 的几何生成能力会高效得多。

思路是这样的：把零件的描述模板化，尺寸作为变量。然后写一个循环，遍历所有尺寸组合，每次调用几何生成接口，输出对应的模型文件。这样你只需要维护一个模板和一张尺寸表，就能批量产出几十个模型。

用 Python 伪代码示意一下这个流程：

# 定义尺寸表 sizes = [ {"length": 80, "width": 60, "thickness": 5}, {"length": 100, "width": 60, "thickness": 5}, {"length": 120, "width": 80, "thickness": 6}, ] # 遍历生成 for s in sizes: desc = f"矩形板，长{s['length']}宽{s['width']}厚{s['thickness']}，四角打直径6的孔，孔心距边10" model = text_to_cad.generate(desc) model.export(f"plate_{s['length']}x{s['width']}x{s['thickness']}.step")

这种批量生成的能力，是 text-to-cad 相比手动建模最大的效率优势。手动画三个板子可能要半小时，脚本跑一遍几秒钟。

5.3 和现有 CAD 软件的配合方式

text-to-cad 生成的模型，通常不是终点，而是中间产物。你可能需要把它导入到专业 CAD 软件里继续做装配、出工程图、做仿真。

配合方式有两种：一种是文件交换，导出 STEP 再导入；另一种是API 直连，如果 CAD 软件提供了编程接口，可以直接把生成的几何体推送到当前文档里。

文件交换简单通用，但每次都要手动导入导出。API 直连效率高，但需要 CAD 软件支持，而且不同软件的 API 差异很大。我的建议是：原型阶段用文件交换，生产阶段如果量大再考虑 API 直连。

提示：导入 STEP 到 CAD 软件时，注意检查导入的坐标系和单位设置。有些软件默认单位是英寸，导入毫米模型会缩小 25.4 倍，这个坑我踩过不止一次。

6. 我对 text-to-cad 实际使用的一点体会

用了一段时间下来，我最大的感受是：text-to-cad 的价值不在于替代 CAD 工程师，而在于把工程师从重复劳动里解放出来。它擅长的是规则明确、结构重复的零件，不擅长的是需要创造性判断、复杂曲面、自由造型的东西。你让它生成一个标准法兰、一个安装支架、一个简单的外壳，它很快；你让它设计一个符合人机工程学的曲面手柄，它基本无能为力。

另一个体会是，描述能力本身就是一种建模能力。你能把零件描述清楚，说明你脑子里已经把它想清楚了。很多人觉得自己“不会用 text-to-cad”，其实是还没想清楚自己要什么。这时候与其反复调描述，不如先拿张纸把零件草图画出来，标上尺寸，再照着图去描述，成功率会高很多。

最后分享一个小技巧：建立自己的描述片段库。把常用的特征描述存下来，比如“四角打直径 6 的孔，孔心距边 10”“所有外角倒 R3 圆角”“上表面做 2 毫米深的沉台”。下次描述新零件时，直接拼装这些片段，既快又不容易出错。这个习惯我从写代码的时候就养成了，用在 text-to-cad 上同样好使。