从“一句话”到CAD模型：text-to-cad实现原理与落地路线

说实话，我第一次听到text-to-cad这个概念时，第一反应是怀疑。

画图这事儿，在CAD里干了这么多年的人都知道，最难的从来不是"画一条线"，而是"知道自己要什么线、在哪个图层、跟谁对齐、用什么线型、后面怎么改"。一个命令敲下去只需要几秒钟，但前面的设计意图梳理、约束关系确认、图层规范执行，才是真正消耗人的地方。所以当有人告诉我"用一句自然语言就能生成CAD模型"时，我脑子里冒出来的第一个问题是：这句话到底怎么变成几何？它真的能替代那些反复的微调吗？

这篇文章想聊透的，就是text-to-cad这件事的本质、实现路线和真实落地情况。整个项目的输入只有"text-to-cad"这个标题和一大串近期CAD相关的热词——里面既有"cad如何彻底卸载不影响二次安装"这种环境层面的痛点，也有"python批量对cad修改"“cad图纸合并"这种批量操作的诉求。我恰恰觉得这些热词本身就说明了text-to-cad该往哪个方向走：不是让AI凭空设计一台机器，而是把大量重复、机械、规则明确的图纸操作，转换成人说得出口、机器算得动的指令。下面的内容全部基于我实际跑过的管线，适合做设计、做制造、搞数字化的人参考，也适合刚接触CAD自动化的人用来建立整体认知。

1. 我理解的text-to-cad：不是自动设计，而是把“画图命令”翻译成几何结果

先说清楚一个很容易被误解的边界。text-to-cad的火爆，很容易让人联想到"跟AI说句话，它就把整台设备设计出来"。现实差得很远。就我目前看到、也实际动手验证过的实现来说，靠谱的text-to-cad系统解决的是**"从描述到几何"的翻译问题**，而不是**"从需求到方案"的创造问题**。

举一个最直白的例子。普通设计师在CAD里的操作路径是这样的：先想清楚"我要一个外径60毫米、厚3毫米、中心孔直径8毫米的垫片"，然后进入草图环境，画两个同心圆，标注尺寸，拉伸，打孔，最后保存成模型文件。整个过程并不复杂，但它绑定了大量界面操作和规范约束。text-to-cad尝试做的，就是让前面那句"我要一个外径60毫米、厚3毫米、中心孔直径8毫米的垫片"直接变成最终的几何结果，同时保留可编辑的参数关系。

这意味着整套系统至少要拆成四个层次：

• 文本理解层：从自然语言里抽出尺寸、特征、空间关系，比如"外径60""同心""厚3""孔8"。
• 几何构建层：把抽出来的参数映射成具体的建模操作，比如拉伸、旋转、打孔、倒角。
• 约束维护层：把"同心""垂直""相切"这类关系转成几何约束，保证后续改尺寸时不乱。
• 输出适配层：把内存里的模型输出成STEP、DXF、DWG等具体格式，交给下游的CAD软件继续处理。

这四层里，前三层是text-to-cad的核心，第四层反而是坑最多的地方。很多人在实践时发现，模型在Python环境里生成得好好的，一导入AutoCAD就丢颜色、丢线型、图层全跑偏，就是这个适配层没做好。

这里还要强调一个观点：近期的CAD热词里出现了大量"图纸合并""批量修改""bl命令在cass里用不了"这类条目，恰恰说明绝大多数从业者的日常工作不是从零设计，而是对既有图纸做增删改。text-to-cad真正能立刻产生价值的场景，也集中在这些规则明确的改动上。比如用自然语言描述"把3号图纸里所有直径大于10的圆孔标注改成红色"，本质上就是把原来需要写Python脚本、录宏、手动批量选择的工作，压缩成一句话加一个可靠的执行通道。这种应用，比"让AI发明一个新零件"现实得多，也稳得多。

2. 主流的三条技术路线：从文本到几何，各走各的门

把"一句话变成CAD模型"这件事拆开看，当前能跑通的路子大致有三条。每条路的代价、输出格式、可控性差异很大，选择哪条完全取决于你要解决什么场景的问题。

2.1 路线一：参数化脚本身，先有代码再有模型

第一条路线最朴素，也最容易被低估。它的核心是让文本理解层输出的不是几何，而是一段参数化建模脚本，然后由CadQuery、OpenSCAD这类程序化建模工具去执行脚本，最终生成模型文件。

我用CadQuery跑过最典型的一个流程。输入文本是"一个外径60、内孔8、厚3的垫片"，系统从文本里抽出参数后，生成下面这样的脚本：

import cadquery as cq result = ( cq.Workplane("XY") .circle(30) # 外径60，半径30 .extrude(3) # 厚度3 .faces(">Z") .workplane() .hole(8) # 中心孔直径8 ) cq.exporters.export(result, "washer.step")

执行这段脚本，几毫秒就能出一个带完整参数历史的实体模型。接下来你可以在CQ-editor里拖动参数，也可以把STEP文件丢进任何主流CAD软件继续编辑。

这条路的优点很突出：输出是真正的参数化模型，不是一堆三角形网格；每一步建模操作都可追溯、可修改；模型精度完全可控。缺点也同样明显——它要求文本理解层能把自然语言准确翻译成建模意图，否则生成的脚本要么语法错误，要么建出来的东西跟需求南辕北辙。说白了，这条路是不是好用，取决于你那个"翻译器"够不够聪明。

2.2 路线二：深度学习端到端生成，研究多、落地少

第二条路线是学术界的热门方向。它的思路是收集大量的"文本描述-CAD模型"配对数据，训练一个神经网络，让模型直接从文本生成三维几何。相关研究里经常能看到Text2CAD这类数据集和Benchmark，核心都是围绕"给定自然语言描述，输出对应的CAD模型"展开。

我跟踪过一些这类项目，也试过把语义理解很强的大模型和网络生成模型拼在一起，但最终放弃了用它走完整流程。原因很实际：

• 神经网络直接输出的多是体素、点云或网格，而CAD工业界真正要的是B-Rep边界表示模型，也就是由面、边、顶点和拓扑关系构成的实体。把网格转成B-Rep在通用场景下至今没有稳定解法。
• 精度达不到制造要求。3D打印看个大概可以，但要车一个直径60.00毫米的配合件，差0.1毫米就废了。
• 模型的参数历史是空的，用户拿到一个"死模型"，没法回到草图里去改一个尺寸再自动更新。

所以我的判断是：端到端生成在概念预览、前期方案汇报、形状灵感探索这几个场景里有价值，但作为生产线上的主力工具还太早。它输出的东西更像"设计参考"，而不是"可交付图纸"。

2.3 路线三：大模型直接调用CAD API，工程上最讨巧

第三条路线是目前我觉得工程上最值得投入的：把CAD软件的操作能力封装成API，然后让大模型根据自然语言决定调用哪些API、以什么参数调用，最终在CAD软件内部生成原生模型。

简单说，就是让大模型当一个"会说话的调度员"，真正干活的是CAD软件自己。比如在AutoCAD或中望CAD这类支持二次开发的环境里，把下面这些能力封装成函数：创建直线、创建圆、生成图层、合并图纸、导入布局、批量修改图元属性。然后大模型拿到用户的一句话，解析出操作序列，按顺序调用这些函数。

这样做的好处是显而易见的。CAD软件自己处理几何核心和约束求解，模型文件是原生的，图层、线型、文字样式全都在。生成结果可以直接进下游的生产流程，不需要任何格式转换。而且，CAD软件本身强大的捕捉、约束和历史记录功能，也能兜住一部分文本歧义带来的错误。我记得业内已经有把这类思路做成"CAD Copilot"的概念Demo，用户说"把这层的墙线全部改成虚线"，系统就能直接在图纸上完成修改。

当然，这条路对CAD软件自身的API完备度要求很高，而且大模型调用API时依然会出错。所以实际落地时，一定要在调度层加入校验和回退机制，这个后面具体讲。

3. 最小可复现管线：一句“垫片”需求，从自然语言到DXF

说再多原理，都不如把一条最小管线完整跑通来得实在。下面是我实际搭过并验证过的流程，所有的代码和步骤都是可以直接照搬复现的。整个管线只用三个组件：一个能理解自然语言的大模型、CadQuery做几何构建、ezdxf做DXF输出。

先看整体结构：

用户输入文本 ↓ 参数抽取（LLM + 规则校验） ↓ 生成CadQuery脚本 ↓ 执行脚本 → STEP模型 → 转DXF ↓ 人工检查或程序校验

3.1 第一步：从文本里抽出参数，不能全指望大模型

输入是一句话："做一个垫片，外径60毫米，厚3毫米，中心孔直径8毫米。"

我第一版是直接把这句话丢给大模型，让它返回JSON参数。后来发现这样不够稳，大模型偶尔会把"外径"和"半径"搞混，或者明明用户说的是毫米，它默认成英寸。所以我加了一层强制规则校验。

要求大模型必须返回这样的结构化结果：

{ "feature_type": "washer", "params": { "outer_diameter": {"value": 60, "unit": "mm"}, "thickness": {"value": 3, "unit": "mm"}, "hole_diameter": {"value": 8, "unit": "mm"} }, "relations": ["concentric"] }

然后在代码里写死一层校验：如果文本里明确写了单位，就以文本为准；如果没有单位，按项目默认单位处理，并在返回结果里把默认单位显式写出来。这一步看起来笨，但能挡掉后面一大半的尺寸错误。

3.2 第二步：让大模型生成CadQuery脚本，并加入编译校验

拿到参数之后，构造一个固定的提示词模板，要求大模型输出CadQuery脚本。我给大模型的约束是：只能输出Python代码，代码里不能有任何交互输入，所有参数必须来自前面抽出的JSON。

这一步最常见的失败是脚本语法错误，或者用错了CadQuery的API。我的做法是把执行脚本时的报错信息回传给大模型，让它自己修。一次不成就两次，实测通常两三轮内能得到可执行脚本。比起人工去改代码，这个循环要快得多。

脚本执行成功后，我会先做一轮几何合理性校验，比如检查实体体积是否大于0、外径是否大于内孔直径、厚度是否在合理范围。这套校验逻辑必须独立于大模型，用纯规则去硬判断，防止模型一本正经地生成一个"外径8、内孔60"的鬼东西。

3.3 第三步：转成DXF，让普通CAD软件能直接打开

CadQuery可以直接导出STEP，但很多工厂和设计师日常用的还是DWG/DXF。CadQuery本身不直接支持DXF导出，所以我在这里接了一个ezdxf的环节。

import ezdxf doc = ezdxf.new("R2010") msp = doc.modelspace() # 外圆 msp.add_circle((0, 0), radius=30) # 内孔 msp.add_circle((0, 0), radius=4) doc.saveas("washer.dxf")

这一步看似多余，实则非常关键。DXF文件里包含图层、线型、颜色这些信息，直接决定了下游AutoCAD打开后的显示效果。我在实际集成时，会把"外轮廓线放哪个图层"“孔标注用什么颜色”也做成可配置项，由自然语言里的描述决定。比如用户说"外圈用粗实线，内孔用细实线"，我的系统就能把这两个圆分别放到不同图层并赋予不同线宽。

这个最小管线跑通之后，你会发现一个特别丝滑的效果：从"一句话"到"能打开的图纸"，整个过程不到十秒，而且所有中间产物都是文本和代码，天然适合版本管理。

4. 真实试跑后踩过的坑：单位、约束映射、环境残留

前三章讲的都是光鲜的一面。下面这些坑，是我把管线接到真实工作流之后踩出来的，每一条都值得记下来。

4.1 单位的坑：文本不写单位，结果就是灾难

有一次我测试用的输入是"做一个直径6的圆柱，高10"。系统默认按毫米解析，生成的模型看起来也对。结果导入客户的AutoCAD里，整个零件放大了25.4倍。原因很简单：客户的CAD模板默认单位是英寸，而我的默认单位是毫米，两者差了25.4倍。

从那以后我定了一条铁律：参数抽取结果里必须显式带单位，没有单位时宁可停下来问一句，也不要猜。因为CAD这个领域里，单位错了不是模型难看的问是零件报废的问题。所有涉及尺寸的文本，我在提示词里都会强制要求大模型把它规范成"数值+单位"的结构，哪怕原文只写了"6"，输出也要补上默认单位。

4.2 特征关系的坑：同心、共线这些词，模型不一定听得懂

大模型能听懂"直径""厚度"这种显式尺寸词，但对"同心""共线""相切"这类几何关系词的处理很不稳定。它可能生成两个位置完全错开的圆柱，然后告诉你"已经同心了"。

我在管线里加了一件事：当抽取到几何关系词时，不在CadQuery脚本层面去硬写，而是把它转成明确的坐标约束。比如"同心"这个词，在脚本里就不再是描述性的，而是直接指定圆心坐标为同一个点。我在校验环节还会做一次拓扑检查，把两个圆的圆心坐标取出来算距离，小于0.001毫米才判定为同心。这类规则校验比任何模型微调都管用，因为它不依赖模型自觉。

4.3 环境残留的坑：生成系统没问题，CAD环境反而反复出问题

热词榜里"cad如何彻底卸载不影响二次安装"“安装cad一直出现c++2005错误"这类问题长期存在，我一开始觉得跟text-to-cad没什么关系，直到我自己在部署自动化管线时被环境问题摆了一道。

事情是这样的：我需要在同一台测试机上反复安装、卸载不同版本的CAD软件来做格式兼容测试，结果连续两次出现装到一半报错、装完打不开的情况。查到最后，问题出在旧版本的运行时库残留和注册表状态上。这给了我一个很重要的启示：text-to-cad要用在真实生产环境，必须先把CAD环境本身变成一个可稳定复现的东西。

我现在推荐的做法是两层。第一层，把公共CAD环境单独放在虚拟机或容器里，image固定，测试完整体重建，不要在一台物理机上反复折腾卸载重装；第二层，把卸载思路反过来，不去追求"彻底卸载"，而是把每次安装所需的运行时库、依赖组件、配置脚本全部版本化，装新版本之前先跑一遍配套的环境初始化脚本，把已知的C++运行时库统一对齐。这样一来，text-to-cad管线要对接的是哪个版本、哪套依赖，都清清楚楚，出问题也能快速重建，不用浪费时间跟"残留"纠缠。

4.4 版本历史的坑：生成模型要放在版本管理里，而不是只存文件

还有一个小教训。一开始我让管线直接把生成的STEP和DXF文件存到共享盘里，文件名后面加时间戳。结果一个星期后，文件多到根本分不清哪个是哪个，更没法回答"上一版的外径是多少"这种问题。

后来我改成把生成模型的源码脚本提交到Git仓库，STEP/DXF等二进制文件作为构建产物按版本发布。这样任何一个模型都能追溯到它是基于哪条文本、哪个参数版本生成的。谁想改尺寸，改的也是源代码，不是那个"死"的CAD文件。这个习惯对团队协作尤其重要，因为text-to-cad生成模型的本质是"程序产物"，那就该用管程序的方式去管它。

5. 它和现实工作流的距离：哪些场景可以马上用，哪些别硬上

聊完原理和坑，最后说点实际的判断，方便你决定自己该不该上这套东西，以及从哪个点切入。

我先把三条路线适合的场景整理成一张表：

基于这张表，我自己的判断是，下面这几类场景可以马上用起来：

• 批量生成标准件：垫片、法兰、螺栓这类规则明确、参数清晰的零件，用参数化脚本路线，几分钟能生成几百个变体。
• 图纸规范整理：把"所有文字标注移到图层TEXT""所有虚线改成红色"这类操作封装成API，让大模型去调度，省掉大量手工选择。
• 格式转换和布局导入："把这几张图纸合成一张""把这套图导入布局并按比例排好"这类需求听起来简单，做起来极其繁琐，但规则很明确，是text-to-cad的理想切入点。
• 给非专业用户提供出图入口：让车间师傅用自然语言描述一个简单零件，系统直接生成DXF给加工，不用逼他们学CAD操作。

反过来，这几类场景暂时别硬上：

• 高精度配合设计：真实机械设计里的大量公差、配合、材料、热处理信息，自然语言很难完整表达，硬压缩成一句话只会丢失信息。
• 复杂装配体设计：几十个零件的装配关系、运动约束、干涉检查，现在的text-to-cad还handle不住。
• 需要强创意判断的设计：AI可以生成形状，但"这个形状好不好看、适不适合加工、成本是否可控"这类判断，目前还是得靠人。

我个人实际操作下来的体会是：text-to-cad现阶段最大的价值，不是取代设计师，而是把那些"已经知道怎么做、但做起来很烦"的操作，变成可以用一句话触发的事。和热词里那些"cad快速看""cad图纸合并""python批量对cad修改"的需求放在一起看，你会发现大家真正想要的不是更聪明的画图工具，而是一个能听懂人话的自动化助手。

如果你打算从零开始试，我给一条最省力的路径：先装好Python环境，把CadQuery和ezdxf跑通，然后用一个成熟的大模型API来生成CadQuery脚本，输入就用你自己工作里最常遇到的零件描述。从最简单的单个特征开始，别一上来就做装配体。等你把"文本→参数→脚本→DXF"这条链路跑顺了，再考虑接到AutoCAD或中望CAD的API上做图纸级操作。这条路径不需要很深的人工智能背景，但需要你对自己领域的图纸规范足够熟悉——因为真正决定生成结果能不能用的，不是模型有多聪明，而是你给它的规则够不够清楚。