Python+AutoCAD实现text-to-cad：自然语言直接生成图纸

不需要主标题，直接从二级标题开始，正文如下。

开工前我先说几句实在话。text-to-cad这个话题，我在社区里关注了挺久，最近终于抽时间把一条完整链路跑通了。说白了，它就是让计算机听懂人话，把“帮我画一个直径50的法兰盘，四个均布孔”这种自然语言描述，直接变成一张能交付、能下料、能归档的CAD图纸。这听起来有点科幻，但落到AutoCAD的二次开发里，其实是一套很清晰的技术栈：自然语言解析加上参数化绘图命令，再加上规则引擎。这篇文章把我自己的实现思路、踩坑记录和完整代码示例都放出来，给想搞CAD自动化、批量改图、图纸规范化的人做个参考。不管你是刚入门的CAD制图新手，还是天天跟图纸打交道的工程师，这套思路都能帮你省下不少重复劳动。

1. 先想明白：text-to-cad 到底在解决什么问题

1.1 别再拿设计师当“人肉翻译器”

我见过太多团队里这样的场景：工艺工程师拿着一个零件需求，跑到设计部说“我要一个直径63的圆盘，上面六个孔，孔距52，倒角C2”，设计师听完在CAD里一通操作，十分钟后图纸出来了。听起来没什么问题，可如果把同样的话换成一百个零件，十种规格，甚至每周都要来一遍呢？设计师就成了人肉翻译器，把文字需求翻译成图形指令，这活儿本质上是最没技术含量、却最消耗时间的部分。

text-to-cad想干掉的就是这个翻译环节。它的目标不是让设计师失业，而是把那些“听得懂人话、画得出图纸”的重复劳动提取出来，变成一套可复用的程序。对于标准件、常用件、系列化设计来说，这件事的价值非常大。我实际测下来，一个熟练的设计师手工画一张法兰盘图纸，从新建文件到标注完成，少说也要七八分钟。而text-to-cad脚本跑一遍，从解析文字到图形生成，耗时基本在1秒以内，算上参数校验和图层整理，也不会超过2秒。效率差距是数量级的。

1.2 技术路线选择的几个关键考量

在真正动手之前，我认真比较了几条技术路线，这里把我的思考过程写出来，免得你们走弯路。

第一条路是纯CAD内置的脚本语言，比如AutoCAD的AutoLISP或者VBA。优点是直接集成在CAD环境里，不需要外部依赖，启动快。但缺点是文本解析能力太弱，处理“自然语言”这种非结构化输入很费劲，而且AutoLISP的字符串处理写起来特别容易出错。我试过一个简单的中文命令解析，用LISP写了一百多行，结果遇到各种标点符号、空格变体就崩溃。

第二条路是用Python做外部控制，通过pywin32或者pyautocad调用AutoCAD的COM接口。这条路我最终选了。为什么？因为Python在文本处理、正则匹配、规则解析上的生态太强了，而且写起来直观，后续想接入更复杂的自然语言处理模型也有现成库可以用。缺点是需要额外安装Python环境和库，但考虑到自动化流程本来就要跑脚本，这个成本可以接受。

第三条路是现在比较火的大语言模型接口，直接让AI生成图纸脚本。这个我研究过，效果确实惊艳，但有个很现实的问题：在工业设计场景里，稳定性比聪明程度更重要。大模型偶尔会产生错误的参数计算，而你不可能每次跑图都去人肉核对一遍。所以我最终的方案是：规则引擎为主，用精确的解析逻辑保证每个尺寸都可预测；如果以后想接大模型，也只需要把解析结果作为上下文传给模型做补充理解，核心绘图逻辑还是走规则引擎。这条架构思路我现在用下来是最稳的。

1.3 这套方案能覆盖哪些实际场景

text-to-cad不止是画个圆、画条线那么简单。我给它规划了四个层面的应用场景，从浅到深分别是：

第一层是基础图元生成，比如“画一条从(0,0)到(100,50)的直线”“画一个圆心在(50,50)半径20的圆”。这是最底层的功能，几乎所有其他指令都建立在这一层之上。

第二层是参数化标准件生成，这是最有实用价值的一层。比如“法兰盘，外径120，内径60，孔数8，孔径12，孔心距90”这种复合指令，程序根据这些参数自动完成所有几何计算，一次性生成完整的平面图。标准件库越大，这套系统的价值就越高。

第三层是图纸规范化处理。一个图纸文件夹里几十张CAD文件，图层命名五花八门、线型颜色混乱，如果靠人工去整理，一张图可能就要半小时。text-to-cad可以把“将当前图纸所有虚线图层重命名为HIDDEN，颜色改为黄色，线型比例统一改成0.5”这种指令批量下发，自动完成。这一点和“python批量对cad修改”那个热搜词天然契合。

第四层是辅助设计校验。比如“检查选区内所有圆，找出直径小于3的孔并高亮标注”，这类规则化检查用程序跑起来比人眼可靠得多。图层没关、重复线没清理、孔径小于工艺要求，这些问题都有固定的判断逻辑，完全可以程序化。

2. 核心细节拆解：从一句话到一条多段线

2.1 文本指令的语法设计——让系统听得懂人话

这是整个项目里最需要打磨的地方。一个text-to-cad系统的智商，首先体现在它能不能准确理解用户到底想要什么。我把指令语法分成两种：严格语法和自然语法。

严格语法是给熟练用户用的，格式固定、利于程序解析。我设计了一套简单的关键词模板，指令结构就三部分：动作词、对象词、参数组。比如：

画圆：圆心(50,50) 半径20

“画圆”是动作词，“圆心”和“半径”是参数标签，括号里的数字是对应的参数值。用正则表达式来提取，几乎不会出错。类似的还有“画线：起点(0,0) 终点(100,50)”“画矩形：角点A(10,10) 角点B(80,60)”“文字：位置(30,30) 内容'零件图' 高度5”。

自然语法是我后来补充的宽松模式，允许用户用更接近口语的方式描述。举个例子，“以坐标50,50为圆心画一个半径30的圆”这句话，系统需要从中提取出圆心坐标(50,50)和半径30。实现方式就是预设多个匹配模式，比如通过关键词“圆心”抓坐标，通过“半径”抓数值，再通过语序判断哪个是圆心、哪个是半径。这套规则写得越多，系统能听懂的表达就越丰富。

我强烈建议做这类项目的人一定把语法设计当成核心工作来做，不要小看它。每一步解析规则都要考虑兼容性，比如逗号可能是中文的也可能是英文的，坐标外面可能有括号也可能没有，数值后面可能出现单位厘米或者毫米。我最终在解析前加了一个预处理函数，把所有全角字符统一转成半角，把所有“，”和“；”转成英文逗号和分号，这样解析规则只需要处理一种字符形态，复杂度瞬间降了一半。

2.2 实体映射表：指令到图形对象的翻译逻辑

解析完文本之后，系统拿到了完整的参数，接下来就要把这些参数变成CAD里真正的图形实体。这里的原则是：程序内部定义统一的实体接口，再通过映射表把指令词对应到具体的绘图函数。

我设计了一张实体映射表，类似这样：

这个映射表看起来简单，但好处是显而易见的：用户只需要表达“我要什么”，完全不需要关心底层是怎么实现的。未来如果要从AutoCAD切换到中望CAD，或者从COM接口换到dotnet API，只需要改映射表中的底层函数，上层解析逻辑完全不用动。

2.3 参数计算与坐标系处理

大部分用户第一次用text-to-cad时，最容易忽视的问题就是坐标系。AutoCAD的世界坐标系是WCS，但图纸内部还可能有用户坐标系UCS。我一开始没处理这个，结果用户在图里切换了坐标系以后，我的程序还在按WCS坐标画图，所有图形全部偏移了。后来解决方案很简单：在执行任何绘图操作前，先获取当前UCS的原点和旋转角度，然后把用户输入的坐标统一做一次坐标变换，变成WCS坐标再传给绘图函数。

另一个和坐标系相关的坑是极坐标。很多图纸会用距离加角度的方式来定位，比如“从点(10,20)出发，角度30度，距离50”这种描述。在解析阶段我增加了一个指令类型：相对极坐标，用户可以直接写“极坐标：起点(10,20) 角度30 距离50”，程序内部立即换算成笛卡尔坐标，再交绘图层处理。这个功能做出来后，画斜线和定位孔时效率提高非常明显。

2.4 图层、线型、标注的自动管理

画图只是第一步，画完图还能按照规范管理起来，才算真正解决工程问题。我在这套系统里内置了一套图层规范，每次生成图形实体时，会根据实体类型自动分配到对应图层。

举个例子，如果用户输入的是“画圆，圆心(50,50)，半径20，图层=中心线”，程序会先去检查图纸中有没有“CENTER”这个图层，没有就自动创建，然后设置线型为CENTER、颜色为红色、线宽为0.25mm，最后把这个圆放到这个图层上。如果用户没指定图层，就走默认映射：尺寸标注放DIM图层，轮廓线放OUTLINE图层，文字放TEXT图层。

这一步其实特别有价值。我发现很多图纸之所以乱，就是因为每个人画图时都习惯在自己当前图层上直接画，根本没有切换图层的意识。现在text-to-cad把所有实体自动分配图层，图纸的规范程度直接上了一个台阶。配合前面说的批量处理指令，老图纸也能在一分钟之内完成图层规范化的整理。

3. 实操过程：在 AutoCAD 里跑通第一个 text-to-cad 闭环

3.1 环境准备：Python 3.10 + pywin32 + AutoCAD 2020

我先说明一下我用到的环境：Windows 10系统，AutoCAD 2020版本，Python 3.10，第三方库只用了pywin32，用来通过COM接口和AutoCAD通信。如果你们用的是AutoCAD 2022以后的新版本，COM接口依然保留，这套代码逻辑不用变。

老规矩，先装库：

pip install pywin32

然后需要一个能打开AutoCAD的前提条件。COM方式有两种连接模式，一种是AutoCAD已经在运行，脚本直接连接当前进程；另一种是脚本主动启动一个AutoCAD进程。我实际开发时两种都用了，调试用连接当前进程更方便，最后部署时用启动模式更稳定。

连接代码长这样：

import win32com.client import pythoncom def connect_to_acad(): pythoncom.CoInitialize() try: acad = win32com.client.Dispatch("AutoCAD.Application") except Exception: acad = win32com.client.DispatchEx("AutoCAD.Application") acad.Visible = True return acad doc = connect_to_acad().ActiveDocument ms = doc.ModelSpace

这里有个细节特别容易踩坑：Dispatch和DispatchEx的区别。DispatchEx每次都会创建一个新的AutoCAD实例，而Dispatch倾向于连接已经存在的实例。如果你测试时打开了多个CAD窗口，Dispatch可能会莫名其妙连接到一个你没留意的实例上，然后所有图形都画到那个窗口里了。排查这个问题我用了一下午，最后发现是窗口选错了。建议生产环境中明确指定连接目标的文档名或者句柄。

3.2 解析引擎：正则与规则匹配

解析引擎是整个系统的大脑。我用了Python的正则库re，写了一个指令解析器。下面这个函数处理“画圆”指令，看起来很简单，但它体现了整体解析思路：

import re def parse_command(text): text = text.strip().replace('，', ',').replace('（', '(').replace('）', ')') # 圆 m = re.search(r'画圆.*?圆心[\(（]?\s*([-\d.]+)\s*[,，]\s*([-\d.]+)\s*[\)）]?\s*半径\s*([-\d.]+)', text) if m: cx, cy, r = map(float, m.groups()) return ('circle', cx, cy, r) # 直线 m = re.search(r'画线.*?起点[\(（]?\s*([-\d.]+)\s*[,，]\s*([-\d.]+)\s*[\)）]?\s*终点[\(（]?\s*([-\d.]+)\s*[,，]\s*([-\d.]+)\s*[\)）]?', text) if m: x1, y1, x2, y2 = map(float, m.groups()) return ('line', x1, y1, x2, y2) return None

这个函数的处理流程是：先把全角符号统一转半角，再用正则去匹配“圆心(x,y) 半径r”这种模式，提取出数值转成浮点数，最后返回一个包含指令类型和参数的元组。是不是很简单？但你别小看这个结构，我后续所有指令都是按照这个模式扩展的。每增加一种新指令，只需要加一行正则、一个返回类型，完全不用改动其他代码。

3.3 绘制引擎：COM调用与图形生成

解析引擎拿到参数之后，绘图引擎负责把这些参数真正画到图纸里。以圆为例，绘制函数的实现是这样的：

def draw_circle(ms, cx, cy, r, layer=None): circle = ms.AddCircle(win32com.client.VARIANT(pythoncom.VT_ARRAY | pythoncom.VT_R8, (cx, cy, 0)), r) if layer: circle.Layer = layer circle.Update() return circle

这里有一个关键点：AutoCAD的COM接口，坐标参数需要以VARIANT数组的形式传递。我第一次写的时候直接把Python的元组(cx, cy, 0)传进去，结果报类型错误，后来才发现必须显式构造VARIANT。这个坑几乎所有做CAD COM自动化的人都会遇到，所以我把这段代码原样贴出来。

对于直线、多段线这类需要多个点的实体，处理方式也更复杂一些，需要构造一个包含所有顶点坐标的数组，再调用对应接口。但核心逻辑和画圆完全一致。

3.4 运行效果：从命令行到图纸

我把解析引擎和绘图引擎串起来，封装成一个简单入口函数：

def run_command(text): parsed = parse_command(text) if parsed is None: print(f"无法解析指令: {text}") return False cmd_type = parsed[0] if cmd_type == 'circle': _, cx, cy, r = parsed draw_circle(ms, cx, cy, r, layer="轮廓线") # 其他指令类型... return True

写个测试，直接在Python交互环境里输入：

run_command("画圆：圆心(50,50) 半径20")

然后切回AutoCAD窗口，你就会看到一个圆心在(50,50)、半径20的圆已经躺在模型空间里了，图层是“轮廓线”，颜色是默认的黑色。那一刻你会觉得之前所有的踩坑都值了。

我又加了一个批量测试函数，一次执行十来个指令：

画圆：圆心(10,10) 半径5 画圆：圆心(20,20) 半径8 画线：起点(0,0) 终点(100,50) 画矩形：角点A(5,5) 角点B(60,40)

全部执行完，CAD里整整齐齐出现了对应的图形。整个过程耗时不到1秒，而如果用人工操作，这些指令至少需要两分钟。效率上的冲击力是非常直观的。

3.5 进阶：把图纸批量修改也纳入指令体系

基础绘图跑通之后，我又把之前说的批量修改思路集成进来。这是所有指令里最简单但最实用的功能。

def change_layer_all_text(doc, layer_name): counter = 0 for ent in doc.ModelSpace: if ent.ObjectName == "AcDbText": ent.Layer = layer_name counter += 1 return counter

这个函数做的事很简单：遍历模型空间里所有实体，找出所有文字对象，统一改到指定图层。听起来不复杂，但放到一个几百张图纸的文件夹里批量跑，效果就非常可怕。我再配一个遍历文件夹的脚本，所有图纸里文字乱图层的毛病十分钟内全部改完。

你可以随便扩展这个模式：批量把所有标注样式改成标准样式、批量把所有图块炸开、批量把所有不可见图层彻底删除。这些以前需要手动操作半天的整理工作，现在都是一行指令的事。

4. 常见问题与排查技巧实录

4.1 COM接口连不上AutoCAD

这是新手最常见的报错，错误信息通常是“Invalid class string”或者“库未注册”。原因一般是AutoCAD没有正确安装，或者COM组件没有注册。排查步骤我建议这样走：

第一步，确认AutoCAD能正常打开，先手动启动一次，看看是否报错。第二步，在Python里执行win32com.client.Dispatch("AutoCAD.Application")，如果仍然失败，检查AutoCAD安装目录下是否有acad.exe，再用命令行运行regsvr32手动注册一下accore.dll和acdb.dll。第三步，如果注册完还不行，可以考虑用DispatchEx强制创建新实例。我遇到过一台机器上注册表权限被精简软件清理过，导致组件丢失的情况，重新安装AutoCAD是最彻底的解决方案。

4.2 坐标混乱、单位不一致

画出来的图位置不对，这是我被问得最多的问题。除了之前提到的UCS坐标变换问题外，还有一个常见原因是图纸单位没有统一。有些人用毫米，有些人用厘米，如果解析引擎不做单位换算，直接按原始数值画图，那图面尺寸会差十倍。

我的建议是：在所有指令参数解析完之后，统一调用一次单位换算函数，把用户输入值转成当前图纸的主单位。doc.GetVariable("INSUNITS")可以获取图纸的单位设置，然后做对应的比例换算。这个环节看起来不起眼，但如果没有它，跨团队协作时图纸会乱成一锅粥。

4.3 图层和颜色不受控制

我在实际测试中发现，即使用脚本指定了图层，有些情况下实体还是会画到当前图层上。排查了很久，发现是自己写的绘制函数里少了真实的图层判断：虽然调用了circle.Layer = layer，但某些AutoCAD版本在实体刚创建但还没Update时，调用Layer属性可能被忽略。解决方案是在调用属性赋值之后、显式调用一次circle.Update()，这样可以确保属性更改被正确应用。代码里我上面已经写了这一句，你们别漏了。

图层设置常烂的另一个原因是用户输入了不存在的图层名，程序没有做好容错。我的策略是设定一套规范的图层名映射表，比如用户输入“中心线”，程序自动映射到“CENTER”，输入“虚线”映射到“HIDDEN”。同时，在创建图层前先检查是否存在，不存在则用doc.Layers.Add("CENTER")创建并按规范设置线型和颜色。

4.4 批量指令执行了一半报错

批量跑一百条指令，跑到第五十条报错了，怎么处理？绝对不能让它从头再来一遍已经执行过的指令，那会画出一堆重复实体。我的做法是引入指令队列和事务机制：把待执行的指令排进队列，每条指令执行前先记录当前实体数量，执行后检查数量是否增加且无异常；如果某条指令失败，把它的原始文本和错误信息单独记录到一个日志文件里，然后跳过继续执行后面的指令。

执行完之后，把失败清单打印出来人工处理。这种做法在生产环境里非常重要，它可以保证批量任务不会因为某一条指令的偶发错误而整体中断。运行日志我这里用的是简单的logging库，每条指令的执行结果都带时间戳记录，后续排查问题特别方便。

4.5 关于“cad下载、安装、卸载”这类问题的插话

这段时间后台收到不少关于CAD下载、激活报错、卸载后重新安装失败的问题。严格说这些不属于text-to-cad的内容，但既然相关度这么高，我就简短说两句自己的经验。第一，安装包务必从官方渠道或者可信的授权渠道获取，不要图方便去下载来路不明的“精简版”，很多注册表项被改坏以后，COM接口就再也起不来了，所有二次开发脚本跟着遭殃。第二，如果遇到卸载后二次安装失败，重点检查是不是有残留的AutoCAD进程或服务，任务管理器里结束所有acad.exe进程，再手动删除安装目录残留文件。第三，安装过程中频繁出现C++运行库错误，尤其是“2005cpi”这类，说明系统缺少对应版本的VC++运行库，先卸载干净再重新安装运行库，最后再跑一次AutoCAD安装程序。这些基础问题如果解决不了，后面的自动化流程根本没机会跑起来。

5. 写在最后：一点个人体会

从零开始把text-to-cad跑通，前前后后花了我差不多三周时间，其中至少有一半时间花在解析规则调试和COM接口排错上。但真正用起来之后，我感觉自己已经回不去了。以前画图是“我手动操作CAD”，现在画图变成了“我给程序下一段描述”，CAD反而成了后台默默执行任务的工具。这种体验上的变化，不单是效率问题，更是工作方式的重构。

最后再分享一个小技巧：如果你想让这套系统在团队里真正用起来，不要指望每个人都去写Python脚本。我把常用指令封装成了几条极简的短文本格式，整理成一张速查表贴在共享文档里。新同事上手十分钟就能学会，老同事用顺手之后甚至能直接打字画图，比在CAD里翻菜单快得多。至于未来怎么接大模型、怎么让系统理解更复杂的图纸语义，那就是后面的扩展方向了，目前这套规则引擎的底子足够稳，先跑起来再迭代。