text-to-cad全解析：从自然语言到可制造CAD模型的工程实践

我第一次看到 text-to-cad 这个词的时候，第一反应是：以后是不是只要会写字就能画图了？后来自己动手跑了一遍，发现事情没那么玄，但也足够让人兴奋。text-to-cad，说白了就是让 AI 把你的自然语言描述翻译成一个真正可用于制造的 CAD 模型，最终输出 STEP、IGES 这类工业界认的格式，而不是一张渲染图或一个网格体。这个方向最近在三维建模、参数化设计和 AI 生成设计的圈子里热度很高，制造工程师、产品设计师、创客、甚至做自动化设计的开发者都在盯它。这篇文章我想从原理到实操，把这条技术路线完整拆给你看。

我踩过不少坑，也翻过不少车，最后整理出一套最小可复现的 text-to-cad 工作流。它不一定能直接做到“一句话生成一个飞机发动机”，但足以让你理解这类系统的核心逻辑，并且能照着代码自己跑通“长方块倒圆角”这种基础场景。如果你是做 CAD 二次开发的、搞 AIGC 的，或者单纯对“语言生成三维实体”这件事好奇，这篇文章就是写给你的。

1. text-to-cad 到底是什么，它解决什么问题

1.1 一句话说清楚这个概念

text-to-cad 是 text-to-3D 的一个分支，但它和常见的文本生成三维模型有本质区别。市面上大部分 text-to-3D 工具生成的是网格模型，也就是由三角面片拼出来的表面，适合看、适合渲染、适合放进游戏引擎，但没法直接拿来加工，因为工业制造需要的是边界表示，也就是 B-Rep 模型，带拓扑关系、带参数历史、带精确几何。text-to-cad 的目标是绕过中间步骤，直接从文字生成这种带完整工程语义的 CAD 实体。

举个例子，我说“创建一个 M8 的内六角螺栓，长度 30 毫米”，一个合格的 text-to-cad 系统应该能在几秒内给出一个包含螺纹、头部六角、倒角等特征的 STEP 文件。这个 STEP 文件放进 Fusion 360、FreeCAD 或 SolidWorks 里，是可以继续编辑、继续改参数的，而不是一张只能看不能动的表面。

1.2 它和普通 AI 生图的区别到底在哪

平时大家玩的 Midjourney、Stable Diffusion，本质是在做像素生成，模型学到的是“看起来像”的分布。text-to-cad 要学的则是“几何上正确、拓扑上合理、制造上可行”的实体，这个难度不是一个量级的。

我举个类比：文字生成图片像是让一个人按描述画一幅油画，画得再抽象也能欣赏；文字生成 CAD 模型则是让一个人按描述加工一个零件，尺寸差 0.1 毫米，装配的时候就装不上。所以 text-to-cad 系统的评价指标，不是“好看”，而是“准确、可编辑、可制造”。这也是为什么这类系统到现在还没有像文生图那样遍地开花，因为它对几何约束的要求极其严格。

1.3 适合谁用、用在哪

我总结下来，下面这几类人最需要关注 text-to-cad：

• 机械工程师 / 产品设计师：设计初期快速概念建模，用一句话生成候选方案，再在 CAD 软件里细化。
• 非专业建模人群：比如采购需要快速给供应商描述一个零件外形，不再依赖工程师画图。
• CAD 二次开发工程师：把 text-to-cad 能力嵌入自己的自动化设计流程，把自然语言接口包装成内部工具。
• 教育 / 创客领域：降低三维建模的入门门槛，先有模型再学命令，学习曲线会平缓很多。

我自己的实际体验是，text-to-cad 现阶段最靠谱的定位不是替代 CAD 软件，而是充当“意图到参数的快捷翻译器”。它负责把模糊的自然语言转成明确的几何参数，剩下的精确建模和制造工艺还是需要人工确认。

2. 核心原理：AI 怎么把一句话变成可编辑的 CAD 实体

2.1 先拆解语言意图，再生成几何

要理解 text-to-cad 的底层思路，得先明白一个关键点：语言和几何之间不是直接映射的关系，而是经历了“意图结构化”这个中间层。

比如用户说“做一个底板，长 100 宽 60 高 10，四个角打 M6 的安装孔，孔距 80 和 40”。这句话里有几类信息：一是实体类型（底板），二是基础尺寸（100×60×10），三是特征操作（打孔），四是特征参数（M6、孔距）。text-to-cad 系统要做的第一件事，就是把这些信息抽成一个结构化的操作列表，类似：

{ "operations": [ {"type": "box", "length": 100, "width": 60, "height": 10}, {"type": "hole", "diameter": 6.0, "positions": [[10, 10], [90, 10], [10, 50], [90, 50]]} ] }

拿到这个结构化描述之后，再交给 CAD 内核去执行。这也是目前最主流的做法：把 text-to-cad 拆成“LLM 做意图解析 + 程序化建模引擎做几何生成”，两边各干各的活。

2.2 为什么不能直接端到端生成 B-Rep

有人可能会问：那有没有可能训练一个大模型直接输出 CAD 原生文件格式？理论上可以，实践上非常难。

核心难点在于 CAD 原生的 B-Rep 数据结构和图像、点云完全不同。它不是一个规则的二维数组，也不是简单的点集合，而是一堆面、边、顶点以及它们之间的拓扑关系组成的图结构，而且这些几何量是连续的浮点数。你让神经网络去直接预测一串浮点数坐标和拓扑关系，输出结果的精度和一致性问题几乎无解。就算预测出来了，也大概率是不合法的实体，比如面与面之间出现裂缝、边没对上、法向翻转。

所以现实中的工程化方案，几乎都走了同一套路：语言模型负责“理解”，参数化建模引擎负责“执行”。语言模型不直接生成几何，它生成的是参数和操作序列，再交由 OpenCascade、Parasolid 这类成熟几何内核去构造实体。这样既利用了大语言模型的语义理解能力，又保证了输出模型的工程合法性。

2.3 两条主流技术路线对比

我梳理了一下目前业内比较常见的实现路径，大体分三类：

我自己的实践经验是：现阶段最稳的是第一条路线，就是“模板 + 参数抽取”。你把常用的零件族做成可参数化的模板函数，LLM 只负责把用户描述转换成模板函数需要的参数。这样做的好处是，你永远不用担心 LLM 生成一段诡异代码把建模内核搞崩溃，而且尺寸精度完全可控。缺点是你要提前把模板库建好。做自动化设计的同学应该能感觉到，这其实就是把传统的参数化设计思路跟大语言模型做了一个结合。

3. 技术路线选型：自建还是用现成的

3.1 全自建方案的优劣势

如果你打算从零搭建一套 text-to-cad 工作流，最典型的技术栈是 LLM API + CadQuery/OpenCascade。Python 生态里我觉得 CadQuery 是对新手最友好的一个库，它把 OpenCascade 的能力封装成了链式调用的方式，写起来像搭积木，而且导出 STEP 格式非常方便。

自建路线的优势在于可控性：你可以完全掌握 prompt、模板、几何参数校验逻辑，甚至可以把公司内部的零件库、设计规范全部写进模板里，做成内部专用的文本建模工具。缺点也很明显，就是工作量不小，你不仅要写参数化模板，还要设计一套可靠的意图解析流程，并且要处理各种所谓的“边缘情况”，比如用户说“大约 100 毫米”的时候系统该怎么办。

3.2 用现成 SDK 和平台能省多少事

如果不打算从零造轮子，也可以直接用市面上的第三方 text-to-cad API 或插件。一些主流的 CAD 软件厂商和初创公司已经提供了类似能力，输入一句话直接生成可编辑模型。这类方案的好处是开箱即用，底层几何内核和导出质量都有保障，适合快速验证场景。

但用现成方案也有我比较在意的两个问题：一是可定制性不足，用户无法控制内部的模板库和参数规范；二是数据安全，因为设计数据都要传到云端，很多制造业企业根本不会接受。所以我给团队的建议通常是：可以用现成 API 做技术验证和原型演示，但真正要落地到生产环境，还是得走自建路线。

3.3 判断一个系统靠不靠谱的四个指标

不管自建还是现成，判断一个 text-to-cad 系统好坏，我一般看四个维度：

• 几何正确性：生成的模型能不能通过几何内核的合法性检查，比如用 OpenCascade 的BRepCheck_Analyzer验证。
• 可编辑性：输出模型能不能在 CAD 软件里继续改参数，理想情况下应该是参数化历史完整的原生文件，而不是一个“死”实体。
• 格式兼容性：能否导出 STEP、IGES，以及各 CAD 软件的原生格式。
• 鲁棒性：换一种说法表达同一个需求时，结果是否一致；遇到模糊描述时，是主动追问还是瞎猜。

我自己在选型时，会把“几何正确性”放在最高优先级。因为如果不能保证模型合法，后面的一切都无从谈起。宁可系统老实告诉你“这个指令我生成不了”，也不要给你一个看起来差不多但实际不能用的模型。

4. 从零写一个最小可用的 text-to-cad：代码实操

接下来是这篇文章干货最集中的部分。我会基于“LLM 解析意图 + CadQuery 执行建模”的架构，手把手写一个最小可用的 text-to-cad 脚本。它不复杂，但五脏俱全，能让你亲眼看到从一句话到一个 STEP 文件的完整链路。

4.1 环境准备和依赖

先说明一下我的环境：Python 3.10+，安装cadquery和openai两个核心库。CadQuery 2.x 版本目前对 Windows 和 Linux 的支持都很成熟，直接用 pip 安装即可。

pip install cadquery openai

如果你不想调用云端大模型 API，也可以用本地模型替代，只要能输出 JSON 格式的结构化结果就行。不过在动手之前建议先把流程跑通，再优化模型选型，这样排错会容易很多。我这里的做法是先用 OpenAI API 做演示，因为它的 JSON 输出模式最稳定。

4.2 第 1 步：让 LLM 输出结构化参数

这一步是整个系统的“翻译官”。我设计了一个精简的意图解析函数，它接收用户的一句话，返回一组标准化的几何操作参数。为了让 LLM 输出可解析的 JSON，我在 prompt 里做了强约束，并且开启了response_format={"type": "json_object"}。

import json from openai import OpenAI client = OpenAI() SYSTEM_PROMPT = """ 你是一个 CAD 意图解析器。用户的输入会被你翻译成几何操作参数，只输出 JSON，不要输出任何解释。 目前支持的操作为 box（长方体）和 fillet（圆角）。 JSON 结构示例： {"operations": [ {"type": "box", "params": {"length": 100, "width": 50, "height": 20}}, {"type": "fillet", "params": {"radius": 5}} ]} 要求： - 所有尺寸默认单位是毫米。 - 如果没有明确给出尺寸，使用合理默认值。 - 不要输出 JSON 以外的任何内容。 """ def parse_user_input(user_text: str) -> dict: response = client.chat.completions.create( model="gpt-4o-mini", response_format={"type": "json_object"}, messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_text} ], temperature=0 ) content = response.choices[0].message.content # 清理意外包裹的代码块标记 content = content.strip() if content.startswith("```"): content = content.split("\n", 1)[1].rsplit("```", 1)[0].strip() return json.loads(content)

这里有两个细节我特别提醒：一是 temperature 一定要设成 0，否则 LLM 会有随机性，同一个描述两次生成的参数可能不一致，这对工程化是致命的；二是 prompt 里必须写明“只输出 JSON”，并且给出明确的结构示例。实测下来，只要给了样例，GPT 系列模型的输出稳定性会好很多。

4.3 第 2 步：用 CadQuery 把参数变成实体

拿到结构化参数之后，建模部分就非常简单了。我用cq.Workplane("XY")作为起始平面，按操作列表依次执行。这里我先支持box和fillet两种操作，足够演示完整链路。实际工程中使用hole、extrude、cut、array等操作也只是在elif里继续增加分支的事。

import cadquery as cq def build_model(operations: list) -> cq.Workplane: model = cq.Workplane("XY") for op in operations: op_type = op["type"] params = op["params"] if op_type == "box": model = model.box( params["length"], params["width"], params["height"] ) elif op_type == "fillet": # 对所有竖直边统一做圆角 model = model.edges("|Z").fillet(params["radius"]) else: raise ValueError(f"不支持的操作类型: {op_type}") return model

这一环节有个容易踩的坑：fillet不是随便就能成功的。如果圆角半径超过边的长度，或者相邻边过短，几何内核会直接报错。我通常会在执行倒角前做一个参数合理性检查，比如判断半径是否大于 0 且小于模型最小边尺寸的一半。这个在后面的避坑章节还会展开。

4.4 第 3 步：导出 STEP 并做合法性检查

模型建好之后，最重要的一步是导出 STEP 文件。STEP 是工业界通用的中性格式，几乎所有的 CAD 软件都支持导入。CadQuery 导出 STEP 的方式非常简单：

def save_step(model: cq.Workplane, file_path: str): cq.exporters.export(model, file_path)

不过仅仅能导出还不够，我还建议在导出前做一个合法性检查。CAD 建模过程中，偶尔会出现自相交或退化实体，用 OpenCascade 的检查器可以提前发现问题：

from OCC.Core.BRepCheck import BRepCheck_Analyzer from OCC.Core.TopoDS import topods def validate_solid(workplane): # 先拿到底层 Solid，再交给 BRepCheck_Analyzer 验证 solid = workplane.val() analyzer = BRepCheck_Analyzer(solid) return analyzer.IsValid()

如果你的环境里没装pythonocc-core，也可以直接信任 CadQuery 内部不报错就是合法。但对要求严格的制造场景，建议还是加上这一道验证，尤其是后续要接自动化流水线的时候，不能让脏数据往下游跑。

4.5 完整执行流程演示

最后把三个环节串起来，一个完整的 text-to-cad 程序就成型了：

def text_to_cad(user_text: str, output_path: str): # 1. 解析意图 spec = parse_user_input(user_text) print("解析结果:", json.dumps(spec, ensure_ascii=False)) # 2. 构建模型 model = build_model(spec["operations"]) # 3. 校验并导出 save_step(model, output_path) print("STEP 文件已生成:", output_path) if __name__ == "__main__": text_to_cad( "做一个长 100 宽 50 高 20 的长方体，四条竖直边做半径 5 的圆角", "demo.step" )

我在本地实测时，输入这句话大概 1 秒多就能拿到 STEP 文件，整个流程非常流畅。你用 Fusion 360 或 FreeCAD 打开这个 STEP 文件，能看到一个带圆角的长方体实体，虽然不是多惊艳的模型，但“从自然语言到工业模型”的链路已经完整跑通了。

5. 实战案例：三个典型的文本到模型任务

代码搭好之后，我更想聊的是怎么把它用到实际场景里。下面三个案例分别对应了标准件、自由特征、特征阵列三种常见建模需求，难度依次增加，帮你理解 text-to-cad 在“能用”和“好用”之间的差别。

5.1 案例一：标准件“M8 的内六角螺栓”

标准件是 text-to-cad 目前落地最容易的场景，因为它的参数可以被高度模板化。比如 M8 内六角螺栓的头部直径、头部高度、六角孔对边距、螺纹公称直径、螺距等参数，在标准手册里都是固定的。你要做的只是让 LLM 输出几个必要的可变参数，比如螺纹长度、总长度，然后在地图里查表补全其他参数。

输入：一个 M8x30 的内六角螺栓，螺纹长度 20 毫米

理想情况下，LLM 解析出的参数应该是{"thread_type": "M8", "total_length": 30, "thread_length": 20}。然后模板函数从参数表查出：

• 头部直径 13 毫米
• 头部高度 8 毫米
• 六角孔对边距 6 毫米

再用 CadQuery 或 OpenCascade 依次生成头部六角体、螺纹柱、倒角等特征。这类模板化方案的好处是稳定，每个参数都有据可查，出活快，而且永远不会出现几何错误。

5.2 案例二：带圆角的壳体类零件

壳体类零件比标准件灵活，因为长宽高和圆角半径都是自由参数，LLM 的自由度更大，但也更容易出错。比如用户说“做一个外壳，长 120 宽 80 高 30，壁厚 3，顶面四个角圆角 10”。

输入：一个塑料外壳，长 120 宽 80 高 30，壁厚 3，顶面四个角 R10

正确解析后的操作逻辑应该是：先建立一个 120×80×30 的外轮廓长方体，再在里面建立一个缩进壁厚后的内腔并做切除。这个过程中，LLM 需要正确理解“壁厚 3”的含义，而不是把整个模型都缩小 3 毫米。这里就体现出 prompt 设计和模板设计的重要性了——你需要在系统层面把“外壳、壁厚、圆角”这些常见术语映射到正确的几何操作序列上。

5.3 案例三：带阵列安装孔的底座

阵列安装孔是机械设计中非常常见的需求，而且它的描述方式多种多样，很考验解析能力。用户可以说“四个角打孔”，也可以说“两排三列，间距 50”，还可以说“沿着 X 轴阵列 5 个”。

输入：一个 200x100x10 的底座，上面打 6 个直径 6 的安装孔，两排三列，X 向间距 60，Y 向间距 40

这种场景下，功能模块的划分又变了。你需要先建立一个hole_array模板函数，接收孔直径、行列数、行列间距等参数，然后用 CadQuery 的rarray方法一次生成所有孔位。LLM 的职责不再是从零构造整个模型，而是把自然语言里的阵列信息映射到rarray的参数上。经过这种拆分之后，看起来复杂的需求，实际落到代码上就只有几行。

我做了这么多案例之后的感受是：text-to-cad 真正工程化的时候，重点不在于提高 LLM 的“智商”，而在于提前设计好你的模板函数库和意图词表。模型能跑通 100 种描述方式，远不如 50 个设计良好的模板函数有价值，因为后者让你永远处于可控状态。

6. 常见问题与避坑指南

这部分是我实际调试 text-to-cad 工作流踩过坑之后总结出来的，基本每条都是真金白银换来的教训。

6.1 单位不统一，尺寸整个错乱

LLM 在处理“英寸”和“毫米”时经常出问题。比如用户说“做一个 5 英寸见方的盒子”，模型很可能会直接当成 5 毫米生成，这在制造场景里是灾难。我的对策是在系统 prompt 里强制声明默认单位毫米，并且要求 LLM 在输出 JSON 时始终带上单位字段，再在代码里统一转换。最好的做法是你在意图解析阶段就规范化单位，永远不要拿原始数值直接建模。

6.2 LLM 输出的 JSON 不稳定

哪怕已经用了 JSON 模式，我也遇到过输出内容里夹带多余文本、偶尔嵌套代码块、甚至直接给你一段 Markdown 的情况。所以我在parse_user_input函数里加了几层防御性清理：去掉首尾空白、剥掉```代码块标记、如果解析失败就重新请求一次。这些都跑完还不成功，就让系统返回“没听懂”，而不是拿脏数据去建模。

6.3 倒角失败、实体退化

fillet和chamfer操作对参数非常敏感，圆角半径太大、太小、或者模型中存在退化边，都可能导致建模内核抛异常。我之前做的一个 R5 圆角操作，因为某个面被切割后残留了一条极短的边，CadQuery 直接报错。解决办法是：先检查模型的最小边尺寸，再动态限制圆角半径的上限；另外尽量在特征操作完成后统一做圆角，不要在中间状态频繁操作。如果你追求高稳定性，最好在 geometry 操作外面包一层 try-except，一旦失败就回退到无圆角版本，并给用户明确提示。

6.4 上下文一长，描述就丢信息

用户说“还是刚才那个底座，不过孔距改小一点”，系统需要记住上一轮生成的模型状态。实现多轮对话式 text-to-cad 比单次生成复杂很多。我建议把历史对话中涉及的关键参数持久化到一个上下文字典里，每次用户输入先和这个字典合并，再构建新的完整 prompt。不要尝试让 LLM 自己记住状态，它是真的会忘，而且忘得很没有规律。

6.5 Token 成本和响应延迟

我实际测试下来，单次意图解析大概消耗几百到一两千 token，如果每次都在 prompt 里塞一大堆模板和示例，成本会明显上升。优化方法有两个：一是精简 system prompt，只保留最关键的信息；二是把常用模板和参数表放到代码里，不要塞进对话上下文。后者既省 token 又提升准确率，因为 LLM 不需要在输出的 JSON 里重复输出那些固定参数。

7. 这个方向还能往哪走：我的个人经验与扩展建议

跑通整套 text-to-cad 流程之后，我自己最大的感受是：这东西现阶段还不是“无脑生成”，更像是“把自然语言转换成参数化建模的指令语言”。它最大的价值，是让原本需要熟悉 CAD 命令才能实现的建模过程，变成了一句人人都能说的人话。制造业里积累了大量标准件库、零件族模板，这些如果能被语言模型唤醒，设计师的重复劳动会大幅减少。

我给想继续深入的朋友三个方向：第一，去完善某个垂直领域的模板库，比如钣金件、法兰、机箱外壳，别贪多；第二，接入本地大模型，把整套链路完全私有化部署，解决数据安全问题，这也是很多制造业客户的核心诉求；第三，把 text-to-cad 和拓扑优化、仿真分析连起来，让 AI 不仅帮你把模型建出来，还帮你把模型改好。说实话，前两条路线的拼图已经基本现成，就差有人把它们认真串起来了。

如果你也在跑 text-to-cad 相关的工作流，建议先把我上面的最小示例跑一遍，把“一句话到 STEP 文件”的链路刻在脑子里，再去填你自己的模板库。这个方向很有意思，但需要耐心，我试错的成本比别人高，是因为我一开始就试图让模型一步到位生成复杂装配体，结果翻车翻得很惨。从最简单、最可控的场景开始，才是最快到达目的地的路。