1. 项目概述当大语言模型遇见CAD最近在琢磨一个挺有意思的事儿怎么让大语言模型LLM去操作CAD软件。这听起来像是把两个不同次元的东西硬凑到一起——一边是擅长理解和生成自然语言的AI大脑另一边是精确到小数点后N位的工程绘图工具。但仔细想想这个需求其实挺实在的。工程师画图很大一部分工作是重复性的改图层、调线型、批量标注、按规则检查图纸。如果能让LLM听懂“把A图层里所有红色的线线宽都改成0.5然后生成一份修改报告”那效率提升可不是一点半点。这个想法的核心是让LLM扮演一个“智能CAD操作员”的角色。它需要理解用户的自然语言指令将其“翻译”成CAD软件能执行的具体命令序列最后驱动CAD软件完成操作。整个过程技术上的挑战在于如何架起这座沟通的桥梁。我梳理了一下目前主要有四条技术路线每一条背后都是不同的技术哲学和取舍。简单来说这四条路是直接调用CAD软件的COM接口、解析和操作DWG/DXF文件本身、通过模拟用户操作UI自动化来控制CAD以及构建一个专为CAD优化的智能体Agent框架。每一条路都能走通但路上的“坑”和看到的风景截然不同。接下来我就结合自己的摸索和踩过的坑把这四条路掰开揉碎了讲清楚。2. 四条技术路线的深度解析与取舍选择哪条路本质上是在开发复杂度、执行效率、功能范围、稳定性以及学习成本这几个维度上做权衡。没有一条路是完美的关键看你的项目最需要什么。2.1 路线一直连核心——利用COM接口这是最“正统”、功能最强大的路线。像AutoCAD、中望CAD这类主流软件都提供了完善的COMComponent Object Model组件对象模型接口。你可以把它想象成软件留给外部程序的一排精密按钮和旋钮通过编程比如用Python的pyautocad或comtypes库按下这些按钮就能以近乎原生的方式控制CAD。它的工作原理是你的程序作为COM客户端启动或连接到一个正在运行的CAD进程作为COM服务器。连接建立后你就获得了CAD应用对象AcadApplication的引用进而可以访问其文档、模型空间、图形对象执行任何菜单或命令栏里能做的操作。# 示例使用pyautocad连接AutoCAD并画一条线 import pyautocad acad pyautocad.Autocad(create_if_not_existsTrue) acad.prompt(Hello, AutoCAD from LLM!\n) # 获取模型空间 model_space acad.ActiveDocument.ModelSpace # 定义起点和终点 start_point pyautocad.APoint(0, 0, 0) end_point pyautocad.APoint(100, 100, 0) # 在模型空间添加一条直线 line model_space.AddLine(start_point, end_point) print(fLine created with ID: {line.ObjectID})这条路线的优势非常明显功能最全只要是CAD软件本身能做的理论上都能通过COM接口实现。从简单的绘图到复杂的参数化设计、图纸集管理、甚至渲染无所不能。执行精准操作直接在CAD内部执行结果与用户手动操作完全一致包括对象捕捉、动态输入等高级特性都能支持。实时交互可以实时获取CAD的状态比如当前图层、视图角度实现动态的、有反馈的控制。但它的“坑”也同样深邃环境依赖极强你的代码严重依赖特定版本、甚至特定发行版如AutoCAD完整版 vs. LT版的CAD软件。用户电脑上没装或者版本不对程序直接瘫痪。这也是网络热词中“cad下载”、“cad安装教程”搜索量高的一个侧面反映——用户环境五花八门。稳定性挑战COM连接本身比较脆弱。CAD软件崩溃、未响应或者那个著名的“文件已在 com surrogate 中打开”错误这通常与文件预览或COM组件注册有关都会导致你的程序失控。这个问题搜索热度很高根本上杜绝需要从系统COM组件配置和文件关联入手非常棘手。性能开销启动和维持一个完整的CAD进程内存和CPU占用不小对于需要高频、批量处理的任务不够经济。跨平台是噩梦COM是Windows的“特产”。如果你的应用需要考虑macOS或Linux这条路基本被堵死。实操心得如果你面向的是企业内部固定的、标准化的工作站环境比如全公司统一使用AutoCAD 2023且需要深度、全面的集成COM接口是王道。但在部署前务必在目标机器上完整测试COM组件的注册状态和权限。2.2 路线二釜底抽薪——直接操作DWG/DXF文件如果不通过CAD软件本身而是直接读写它的“源代码”——也就是DWG或DXF文件会怎样这就是第二条路。DWG是CAD的私有二进制格式而DXF是其开放的文本交换格式。通过像ezdxf这样的Python库我们可以直接解析、创建、修改DXF文件。它的工作原理是将DXF文件视为一个结构化的数据库。文件由“段”SECTION构成如头部HEADER、表TABLES、块BLOCKS、实体ENTITIES等。你的程序直接读写这些段里的数据来改变图形内容。# 示例使用ezdxf打开一个DXF文件修改所有“WALL”图层上圆的半径 import ezdxf doc ezdxf.readfile(input.dxf) msp doc.modelspace() for entity in msp.query(CIRCLE[layerWALL]): # 假设指令是将所有墙层上的圆的半径扩大1.5倍 entity.dxf.radius * 1.5 doc.saveas(output.dxf)这条路线的优势在于零依赖高便携不需要安装任何CAD软件。一个Python环境加一个ezdxf库就能运行非常适合服务器端批量处理、在线转换预览虽然复杂DWG预览如热词提到的kkfileview预览报错内存溢出是另一个难题等场景。处理效率高对于纯粹的批量数据修改如“文件夹内的dwg文件替换文字”直接读写文件比启动GUI软件快几个数量级。跨平台无忧纯Python实现Windows、macOS、Linux通吃。避免GUI不稳定因素彻底绕开了CAD软件UI可能带来的崩溃、卡顿问题。它的局限性也很突出功能有天花板你只能做库支持的操作。ezdxf擅长处理几何图形和基础数据但对于一些高级功能如复杂的尺寸标注样式、动态块、三维实体的某些操作支持可能有限或不直观。CAD软件里一个命令搞定的事在这里可能需要几十行代码来模拟。“所见即所得”的缺失你修改的是文件数据无法实时看到图形效果。对于需要视觉反馈的交互式操作不友好。文件格式的复杂性DWG是闭源二进制格式虽然有一些开源库如libredwg尝试解析但完整度、准确度始终无法与官方SDK相比。直接操作DWG风险更高。DXF虽是文本但版本众多ASCII, Binary结构庞大处理极其复杂的图纸时也可能遇到解析问题。注意事项选择这条路务必进行严格的输出文件验证。用不同版本的CAD软件打开生成的文件检查是否有元素丢失、变形或属性错误。对于生产环境建议始终保留原文件备份。2.3 路线三模拟用户——UI自动化控制如果前两条路一条太“重”依赖软件一条太“底层”操作文件那么第三条路则试图在两者之间取一个平衡像真人用户一样通过自动化脚本去操作CAD软件的图形用户界面GUI。这通常借助像pyautogui、Selenium用于Web版CAD或专业的UI Automation框架来实现。它的工作原理是程序识别屏幕上的控件如按钮、菜单、命令行窗口模拟鼠标点击、键盘输入等事件来驱动CAD软件完成操作。例如让LLM生成指令“点击【绘图】菜单 - 选择【圆】 - 在屏幕上指定圆心和半径”。这条路听起来很“野”但也有其适用场景无API环境下的唯一选择对于一些老旧、没有提供任何API或脚本接口的CAD软件或某些专业插件这是实现自动化的唯一方法。概念验证快速对于快速验证某个LLM指令能否被转化为一系列具体UI动作这种方法搭建Demo最快。操作逻辑直观其步骤与人类操作完全对应易于理解和调试。然而它的缺点几乎是致命的我强烈不推荐用于严肃项目极度脆弱界面布局一变如软件版本更新、用户自定义了工具栏、屏幕分辨率一变、甚至弹出一个意外的对话框比如“文件已在 com surrogate 中打开”整个脚本就会失败。稳定性是灾难级的。执行效率极低模拟鼠标移动和点击非常慢无法用于处理大量任务。开发维护噩梦你需要为每个UI元素定位坐标或图像特征代码冗长且难以维护。任何微小的UI变化都需要调整脚本。无法处理复杂逻辑对于需要根据图形状态做判断的指令如“选中所有长度大于100的线段”仅靠UI操作很难甚至无法实现。个人体会UI自动化只能作为最后的手段或者用于录制一些极其固定的、简单的宏命令。在LLM操作CAD这个追求智能和泛化的场景里这条路基本走不通。2.4 路线四智能体框架——LLM as the Core这是目前最前沿、也最符合“智能”本意的思路。我们不满足于让LLM仅仅生成一段死板的代码或命令序列而是希望它成为一个能感知、决策、执行、反思的智能体Agent。这正是热词中“llm agent”、“llm powered autonomous agents”所指向的方向。它的核心架构通常包含几个模块规划模块PlannerLLM解析用户指令将其分解为一系列可执行的子任务。例如“绘制一个卧室平面图”会被分解为“绘制外墙”、“分割房间”、“布置门窗”、“添加家具”等。工具集Tools为LLM配备一系列可调用的函数这些函数封装了前三条路线的能力。比如draw_line(x1, y1, x2, y2),change_layer(object_id, layer_name),export_to_png(filename)。工具就是LLM的“手”。记忆与状态Memory让LLM能记住当前图纸的状态、已执行的操作历史从而做出连贯的决策。执行与反馈Executor调用工具执行动作并将执行结果成功、失败、返回数据作为反馈再次输入给LLM使其能调整后续计划。# 一个高度简化的Agent思维循环伪代码示例 def cad_agent_loop(user_request: str, cad_tools: dict): system_prompt 你是一个CAD操作专家可以调用工具来修改图纸。请逐步思考。 conversation_history [{role: system, content: system_prompt}] # 第一步规划 planning_response llm_call(conversation_history [{role: user, content: f用户要求{user_request}。请列出需要执行的步骤。}]) steps parse_steps(planning_response) for step in steps: # 第二步决定使用哪个工具及参数 action_response llm_call(conversation_history [{role: user, content: f当前步骤{step}。请告诉我调用哪个工具参数是什么}]) tool_name, params parse_action(action_response) # 第三步执行 if tool_name in cad_tools: result cad_tools[tool_name](**params) # 第四步观察结果纳入历史 observation f执行工具 {tool_name} 结果{result} conversation_history.append({role: user, content: observation}) else: conversation_history.append({role: user, content: f错误工具 {tool_name} 不存在。}) # 最终向用户报告 final_response llm_call(conversation_history [{role: user, content: 所有步骤已尝试执行。请总结完成情况。}]) return final_response这条路线的优势是颠覆性的真正的自然语言交互用户可以说“把左上角那个看起来太挤的尺寸标注挪开一点”LLM能理解意图并自主调用“查询对象”、“移动对象”等工具组合完成。处理复杂、模糊指令能够应对规划、纠错、多轮对话等复杂场景。强大的可扩展性工具集可以不断丰富能力边界持续扩大。但挑战也是巨大的极高的设计与开发成本你需要精心设计提示词Prompt、工具描述、规划与反思机制。这本身就是一个复杂的AI系统工程。对LLM能力要求高需要LLM有很强的逻辑分解、工具调用和上下文理解能力。普通的开源小模型可能力不从心需要GPT-4级别或专门微调的模型。执行延迟与成本每一步都需要调用LLM进行推理速度较慢且如果使用商用API成本需仔细考量。可靠性控制难LLM可能产生“幻觉”调用不存在的工具或参数需要设计严密的校验和异常处理机制。实操心得从简单的“工具调用”模式开始不要一上来就追求完全自主的Agent。先让LLM学会稳定、准确地使用几个核心工具如画线、改属性再逐步增加工具复杂度和引入规划能力。热词中提到的“llm框架”、“llm studio”正是探索这类应用的工具和平台。3. 路线选择与实战架构设计分析了四条路到底该怎么选我的建议是基于你的应用场景做一个混合架构而不是非此即彼。3.1 场景化决策树你可以通过回答下面几个问题来快速定位是否需要与用户实时交互、看到即时图形反馈是 - 优先考虑路线一COM。这是实现交互式CAD助手的基础。否 - 进入问题2。处理任务是否是后台批量、数据驱动的如批量改文字、导出数据是 - 优先考虑路线二文件操作。效率最高部署最简单。否 - 进入问题3。你的指令是否复杂、模糊、需要多步推理****是 - 必须引入路线四Agent框架作为大脑。否 - 指令明确固定可以直接用路线一或二硬编码。绝大多数有实用价值的系统都是路线四大脑 路线一或二手脚的组合。UI自动化路线三仅在极端特殊情况下作为补充工具。3.2 一个推荐的混合架构实践基于以上分析我设计并实践了一个分层架构它平衡了能力、效率和复杂度用户自然语言指令 | v [LLM智能体层 (Agent Layer)] - 指令理解与规划 - 工具调用决策 - 状态管理与反思 | v [工具执行层 (Tool Execution Layer)] | | v v (COM接口工具) (文件操作工具) (其他工具...) | | v v [CAD软件进程] [DXF/DWG文件] | | v v 实时图形结果 生成修改后文件各层详解LLM智能体层这是系统的“指挥官”。我使用类似LangChain或自定义的框架来构建。它的核心是一个工具调用Function Calling能力极强的LLM如GPT-4 Turbo。我为每一个底层操作都定义了一个清晰的工具函数包括函数名、描述和参数格式。例如tools [ { name: draw_rectangle, description: 在指定图层上以给定左下角和右上角坐标绘制一个矩形。, parameters: { layer: {type: string, description: 图层名称}, x1: {type: number, description: 左下角X坐标}, y1: {type: number, description: 左下角Y坐标}, x2: {type: number, description: 右上角X坐标}, y2: {type: number, description: 右上角Y坐标} } }, { name: change_object_layer, description: 将一个或多个图形对象移动到新的图层。, parameters: { object_ids: {type: array, items: {type: string}, description: 要修改的对象的ID列表}, new_layer: {type: string, description: 目标图层名称} } } ]LLM根据用户指令选择并生成调用这些工具的JSON参数。工具执行层这是系统的“手脚”。它接收LLM生成的工具调用请求分发给具体的执行器。对于需要实时交互的操作如交互式绘图、动态修改调用COM接口工具。这部分代码封装了对pyautocad或comtypes的调用并处理连接管理、错误重试。对于纯数据批处理操作如批量替换100张图纸中的公司Logo调用文件操作工具。这部分代码使用ezdxf进行高效的文件读写。工具函数内部会进行严格的参数校验和边界处理防止LLM的“幻觉”导致程序崩溃。反馈与迭代工具执行的结果成功或包含错误信息的失败会被格式化返回给LLM智能体层。LLM可以据此决定下一步动作如重试、调整参数、或向用户请求澄清形成一个闭环。这个架构的好处是职责清晰LLM负责“想”工具层负责“干”。灵活可扩展新增一个功能只需在工具列表里定义并实现它LLM就能学会调用。稳定性增强将不稳定的底层操作封装在工具函数内与LLM的推理过程隔离。兼顾效率与交互后台任务走文件操作实时任务走COM接口。4. 核心工具链搭建与避坑指南无论选择哪条路线一套稳定可靠的工具链是基础。这里分享我在搭建过程中积累的关键经验和踩过的坑。4.1 COM接口的稳定化实践COM连接不稳定是这条路的最大痛点。以下是几个加固措施连接池与超时重试不要每次操作都新建连接。维护一个轻量级的连接池并在调用失败时捕获特定的pywintypes.com_error异常实施指数退避重试。import time import pywintypes import pythoncom def robust_com_call(func, max_retries3): for i in range(max_retries): try: pythoncom.CoInitialize() # 确保线程COM初始化 return func() except pywintypes.com_error as e: if i max_retries - 1: raise time.sleep(2 ** i) # 指数退避等待 # 可以尝试重新获取CAD应用对象 global acad_app acad_app get_acad_application() finally: pythoncom.CoUninitialize()规避“com surrogate”错误这个错误常与系统文件预览处理程序有关。对于需要长时间操作的脚本在操作前尝试通过COM接口执行(command “_.UNDO” “_Control” “_None”)来关闭CAD的合并控制有时能减少冲突。更根本的方法是在系统级别调整DWG文件的预览处理器或者在我们的程序中避免在CAD打开文件的同时用其他程序如文件管理器去访问该文件。状态检查与恢复在执行关键操作前检查CAD应用程序和文档对象是否仍然有效。如果无效触发重新连接流程。4.2 ezdxf文件操作的高阶技巧ezdxf功能强大但用好需要一些技巧处理复杂实体和代理图形对于DXF文件中来自特定插件或版本的复杂实体ezdxf可能将其识别为“代理图形”Proxy Graphic。直接修改可能导致信息丢失。安全的做法是如果不需要修改这些实体就用ezdxf.readfile(‘file.dxf’, ignore_errorsTrue)忽略错误如果需要修改则需深入实体数据结构或考虑转换为简单图形。批量修改的性能优化当处理成千上万个实体时直接遍历modelspace()可能较慢。使用query方法进行过滤是高效的选择它内部进行了优化。# 高效查询所有在“标注”图层上的多行文字MTEXT mtexts_on_annotation_layer msp.query(MTEXT[layer标注]) for mtext in mtexts_on_annotation_layer: mtext.dxf.text mtext.dxf.text.replace(旧项目, 新项目)版本兼容性保存DXF文件时注意指定正确的版本号如doc.saveas(“output.dxf”, version‘R2018’)以确保下游CAD软件能正确打开。通常选择与你目标用户群主流版本兼容的稍早版本。4.3 LLM智能体的提示词工程这是混合架构成功的关键。让LLM准确调用CAD工具提示词设计至关重要。系统提示词System Prompt必须清晰定义角色、约束和目标。你是一个专业的CAD绘图助手。你的任务是将用户的自然语言请求转化为一系列精确的CAD操作工具调用。你只能使用我提供的工具列表。在回复中你必须首先思考用户的请求具体对应哪些CAD操作步骤。然后严格以JSON数组格式输出你要调用的工具每个工具包含name和arguments字段。不要输出任何其他解释性文字。工具描述Tool Description这是LLM认识工具的“说明书”。描述要具体、无歧义、包含单位、格式和边界条件。差的描述“画一个圆。”好的描述“在指定的图层上以给定的圆心坐标(X, Y)和半径绘制一个圆。圆心坐标和半径均为十进制数字单位为毫米。图层必须已存在于图纸中。”在参数中明确类型number,string,array和格式如“color”: “RGB(255,0,0)”或“linetype”: “DASHED”。思维链Chain-of-Thought与示例Few-Shot在系统提示词或初始对话中提供几个从复杂指令到工具调用的转换示例引导LLM学会分解任务。用户帮我在“轴线”图层上从坐标(0,0)到(100,0)画一条红色的中心线。 助手思考这个请求需要两个操作1. 确保“轴线”图层存在并设置其颜色为红色。2. 在该图层上画一条从(0,0)到(100,0)的直线线型为中心线。 助手调用 [ {name: create_or_set_layer, arguments: {layer_name: 轴线, color: RGB(255,0,0)}}, {name: draw_line, arguments: {layer: 轴线, start_x: 0, start_y: 0, end_x: 100, end_y: 0, linetype: CENTER}} ]5. 典型问题排查与效能优化在实际开发和运行中你会遇到各种各样的问题。这里记录了一些常见坑点和优化思路。5.1 连接与执行类问题问题现象可能原因排查与解决思路COM连接失败提示“无效类字符串”或“服务器运行失败”1. CAD软件未安装或未正确注册COM组件。2. 权限不足尤其是以服务运行时。3. 位数不匹配32位Python连接64位CAD或反之。1. 确保目标机器安装了正确版本的CAD并以管理员身份运行一次CAD完成组件注册。2. 使用pyautocad.Autocad(create_if_not_existsTrue)尝试创建实例而非连接已有实例。3. 检查Python和CAD的位数是否一致。执行命令时CAD无响应或卡死1. CAD正在执行一个长时间操作如重生图形。2. 命令序列执行过快CAD来不及处理。3. 弹出模式对话框如保存提示阻塞。1. 在关键命令后添加time.sleep(0.5)等待。2. 使用acad.doc.SendCommand(“(command \\\”._DELAY\\\ 500) “)插入CAD内部延迟。3. 尝试在非图形模式下运行acad.app.SetSystemVariable(“BACKGROUNDPLOT”, 2)或确保执行前关闭所有对话框。ezdxf读取文件报错或保存后CAD打开异常1. DXF文件损坏或版本不兼容。2. 包含了ezdxf不支持的特定实体或数据。3. 修改了只读的或关键的头部变量。1. 使用ezdxf.readfile(‘file.dxf’, ignore_errorsTrue)忽略非致命错误。2. 用CAD软件将原文件另存为较低版本的DXF格式再处理。3. 尽量避免直接修改HEADER段除非你明确知道在做什么。操作实体ENTITIES和表TABLES相对安全。5.2 LLM智能体类问题问题现象可能原因排查与解决思路LLM无法理解指令或调用错误的工具1. 用户指令过于模糊或口语化。2. 工具描述不够清晰。3. LLM本身能力不足。1. 在应用前端引导用户输入更明确的指令或设计一个多轮对话来澄清需求如“您指的‘左上角’具体坐标是多少”。2. 迭代优化工具描述加入更多约束和示例。3. 升级到更强大的模型如从GPT-3.5升级到GPT-4或对领域指令进行微调Fine-tuning。LLM产生“幻觉”调用不存在的工具或参数1. 系统提示词约束不够强。2. 上下文过长导致模型遗忘指令。1. 在系统提示词中强调“只能使用提供的工具”并在每次工具调用后在返回给LLM的反馈中再次列出可用工具。2. 采用更智能的上下文窗口管理保留关键的系统指令和最近的交互历史。工具调用序列冗长低效LLM将简单任务过度分解。1. 提供更粗粒度的复合工具。例如与其让LLM分别调用“画线1”、“画线2”…“画线4”来画矩形不如直接提供一个draw_rectangle工具。2. 在示例中展示高效的任务分解方式。5.3 效能优化建议异步与并行对于文件操作路线二的批量任务可以使用concurrent.futures库进行多进程/多线程并行处理极大提升吞吐量。缓存与预热对于COM连接路线一维护一个持久化的连接池避免频繁创建和销毁进程带来的开销。对于LLM调用路线四可以考虑对常见指令的解析结果进行缓存。操作合并在通过COM接口操作时尽量减少往返。例如如果需要修改100个对象的颜色最好先收集所有对象ID然后通过一个自定义的LISP例程或.NET插件在CAD内部一次性执行而不是通过COM循环100次。兜底策略智能体路线四决策失败时应有降级方案。例如可以设计一个规则引擎当LLM多次尝试失败后尝试匹配预定义的规则模板来生成操作。6. 从原型到产品安全、部署与扩展当你验证了技术可行性准备将其转化为一个可交付的产品或服务时以下几个方面的考量至关重要。6.1 安全性与权限控制让LLM操作CAD尤其是通过COM接口意味着赋予了程序很高的权限。必须建立安全边界最小权限原则运行自动化程序的账户应仅具有完成其任务所需的最低系统权限和文件访问权限。操作沙盒考虑在Docker容器或虚拟机中运行CAD进程和自动化脚本与主机环境隔离。这能防止恶意指令或程序错误对主机系统造成破坏。指令审查与过滤在LLM解析用户指令后、执行具体操作前加入一层安全过滤。例如禁止包含“删除所有图层”、“格式化硬盘”等危险语义的指令或限制其只能操作特定目录下的文件。操作确认与回滚对于高风险操作如删除、覆盖原文件在执行前应向用户二次确认并实现操作日志记录和版本回滚机制例如通过自动备份原文件。6.2 部署模式考量根据用户场景部署方式也不同桌面插件/宏适用于单机用户。可以将你的Python脚本打包成EXE或集成到CAD的.NET/C插件中。用户安装后在CAD内部通过一个命令面板或按钮来调用LLM功能。这种方式依赖本地CAD环境但响应最快。本地服务器适用于小型工作组。在一台性能较好的机器上部署一个本地服务该服务运行CAD和你的智能体程序。组内其他用户的客户端如一个轻量级Web界面向这个服务发送请求。这实现了CAD许可证和计算资源的共享。云端服务适用于大规模或公共应用。在云服务器上部署无头Headless模式的CAD如果许可允许或文件处理服务。用户通过网页或API上传图纸和指令云端处理完成后返回结果文件。这是最复杂的部署模式涉及容器化、负载均衡、许可证管理、文件安全传输等一系列问题但可扩展性最好。6.3 能力扩展方向一个基础的“LLM操作CAD”系统建成后可以从以下几个方向深化多模态输入结合视觉模型VLM让用户可以直接在图纸上圈画、标注然后说“把这里放大”实现更直观的交互。知识增强为LLM接入企业内部的制图规范文档、标准件库、历史图纸数据库使其做出的设计决策更符合特定规范。工作流自动化将单次操作扩展为完整的工作流。例如用户说“出施工图”LLM能自动完成图层整理、标注样式统一、图框插入、批量打印等一系列操作。错误检查与优化建议让LLM不仅会执行还会“检查”。例如“检查这张图中所有线宽小于0.25的打印线”或“这个零件的设计是否符合可制造性DFM原则并提出优化建议”。这条路走下来最深的一点体会是技术路线的选择没有绝对的对错只有是否适合当下的场景。从快速验证原型的文件操作到追求深度集成的COM控制再到构建真正智能的Agent框架每一步都伴随着不同的复杂度与可能性。最关键的是开始动手从一个最小的、可运行的原型做起比如先用ezdxf写个批量改文字的工具或者用pyautocad让CAD自动画个简单的框图。在实操中你会更真切地感受到每条路的沟沟坎坎从而做出最适合自己项目的那个“取舍”。