当我决定认真跑一轮 Claude Fable 5 × MecAgent 的 CAD 工程实测时，预期和现在跑完之后的理解完全不同。当时我以为重点会是“AI 自动画图”，结果真正有价值的是另一件事。先从一个常见场景说起：一批图纸要改版本号，一共 47 张，下班前必须发出去。以前我第一反应是写脚本，后来装了一堆 CAD 插件，而现在更多人在讨论的，是让大模型和代理工具直接参与 CAD 工程流程。
但我跑完一圈之后最大的感受是：这类组合短期内很难替代设计师“画图”，却真的能把工程流程里那些规则明确、上下文固定、反复出现的工作，变成可验证、可复用、可追溯的自动化任务。它改变的不是画图速度，而是工程琐事的处理方式。
1. 为什么这次实测没有把重点放在“自动画图”上
1.1 先用一个四方格看待 CAD 任务
开始实测之前，我先给 CAD 工程任务做了一个简单分类。判断标准有两个：规则是否明确，出错风险是否高。这个分类决定了哪些任务值得交给 AI 代理，哪些任务暂时不要碰。
- 规则明确、风险可控：信息提取、格式统一、批量修订、参数化示意图生成。
- 规则明确、风险较高：涉及公差链、装配干涉、结构承重相关的改动，即使规则清楚，也需要逐级人工确认。
- 规则模糊、风险可控：前期方案探索、概念布局草图，可以让模型提供参考，但不能直接作为交付物。
- 规则模糊、风险较高：复杂系统设计、多方约束权衡、需要大量现场经验的位置决策。
Claude Fable 5 和 MecAgent 这套组合最合适的切入区间，是第一类。我的核心判断是：它们的定位不是替代设计师做决策，而是把“决策确定之后”的执行工序批量化和标准化。
1.2 Claude Fable 5 与 MecAgent 的分工
在我这次实测的流程里，任务被拆成两层。Claude Fable 5 更像一个“会读需求、会写代码、会拆流程”的规划层，它负责把自然语言描述转化成具体的脚本、参数和检查逻辑；MecAgent 则更接近执行层，负责接入 CAD 环境、调用脚本、捕获运行输出、把结果回传给规划层。
这个分工非常重要。因为 CAD 场景不是“把提示词发给模型就出图”，它需要处理文件路径、版本、图层、块、文字样式、坐标单位这些非常具体的东西。没有执行层，模型生成再多的脚本也落不到图纸上；没有规划层，执行层只是把一堆命令串起来，遇到异常不知道怎么调整。
1.3 为什么不建议一上来就追求“全自动出图”
我见过不少团队把目标定成“输入一段话，AI 直接生成一套施工图”。从实测经验看，这个目标在很长一段时间里都不现实。
第一，工程图纸是大量约束和妥协的结果，这些约束很难全部写进提示词；第二，图纸质量需要人工判断，模型很难理解“这个位置看起来合理但实际干涉”这类经验性知识；第三，一旦自动生成出了问题，很难追溯是哪一步决策导致的。
所以，更稳妥的目标是先做工程信息处理：读图、取数、改格式、批量更新。这些任务边界清楚，验收标准也清楚：信息提取出来了没有，图层改对了没有，版本号更新了没有。把这一类任务跑稳之后，再逐步往生成方向推进。
2. 实测前的准备：环境、数据与任务切片
2.1 环境准备清单
在开始任何真实图纸处理之前，需要先确认环境可以支撑“执行层”连续运行。下面是我这次实测中整理的环境清单，具体版本可以根据你本地的 CAD 版本和团队要求调整。
| 准备项 | 用途 | 备注 |
|---|---|---|
| CAD 2018 或更高版本 | 支持新版图纸格式，旧版打开新版文件会丢特性 | 也要确认正版授权 |
| Python 3.10+ | 运行数据处理和脚本生成 | 建议使用虚拟环境 |
| ezdxf | 读写 DXF 文件，处理块、图层、文字 | 不直接依赖 CAD 软件，适合批量处理 |
| pandas / openpyxl | 汇总信息输出为 Excel | 输出给非技术同事复核 |
| pyautocad（可选） | 通过 COM 操作 Windows 版 CAD | 仅限 Windows，且需要 CAD 已运行 |
| MecAgent 或等价编排层 | 执行命令、捕获日志、判断重试 | 重点是能记录每一步执行结果 |
有一点要提醒：如果原始图纸都是 DWG，而自动化脚本用的是 ezdxf，需要先统一转成 DXF，或者直接用 CAD 提供的批处理能力。转换过程中可能会出现字体、代理实体、块定义的丢失，所以最好保留原始 DWG 作为备份，转换出来的 DXF 只作为中间文件。
2.2 数据准备：先用一张“坏图纸”测试
很多人会犯一个错误：用一张干净的样例图纸测试，脚本跑通了就直接上全部文件。真实工程图里几乎没有完完全全的标准文件。我建议准备数据时做三件事：
- 整理 5 到 10 张代表性图纸，尽量覆盖不同绘制习惯、不同版本、不同图层命名。
- 把其中 1 张明显“畸形”的图纸单独拿出来，作为压力测试。
- 全部测试文件放在一个目录中，路径不要有特殊字符，先用英文字段命名。
先跑通一张干净图纸，再跑通一张异常图纸，最后才轮到批量目录。这个过程看起来慢，但能省掉后面大量排查时间。
2.3 把任务切片：先不要提“帮我处理一下图纸”
这次实测里，我发现最大的瓶颈其实不是模型能力，而是需求本身太模糊。比如“帮我把图纸处理一下”这种描述，模型根本没法执行，因为它缺少太多工程上下文。
更合理的做法，是把大任务拆成更小的可验证切片：
- 先确认图纸能不能读：文件是否存在、能否解析、是否需要转换版本。
- 再确认信息在哪儿：图层名、块名、文字样式是否符合预期。
- 再做一次单文件提取：把图框、标题栏、明细表字段取出来。
- 再设计输出格式：CSV、Excel、JSON，按团队习惯决定。
- 最后做批量遍历：单文件验证通过后，再增加文件数量。
这套切片方法看起来繁琐，但正是它决定了后续流程能不能稳定复用。AI 代理最大的优势是能快速生成脚本和处理逻辑，但任务边界必须由人来定义。
2.4 最小可用流程示例
下面是一个非常通用的“读取 DXF 图框块属性”的代码结构。它并不绑定某个具体大模型，而是说明执行层通常要做什么：
import ezdxf import pandas as pd files = ["sample1.dxf", "sample2.dxf"] # 先放小批量测试 records = [] for f in files: doc = ezdxf.readfile(f) msp = doc.modelspace() # 遍历块引用，找到图框，读取属性 for block_ref in msp.query("INSERT"): # 这里的 block 名称要按真实图纸确认 if block_ref.dxf.name == "TITLE_BLOCK": atts = {a.tag: a.text for a in block_ref.attribs} records.append({"file": f, **atts}) df = pd.DataFrame(records) df.to_excel("output/title_info.xlsx", index=False) print(df)这个例子只是展示结构，真实使用时一定要先打印 block 名称，确认属性和字段名，再写提取逻辑。
3. 三个实测场景：从信息提取到批量修改再到参数化生成
这一部分我会按三个场景分开说。每个场景都会描述：任务是什么，实测中怎么拆解，最常遇到什么问题，以及最终怎么处理。
3.1 场景 A：从批量图纸里提取标题栏信息
第一个实测场景是信息提取：给定一批 DXF 文件，把每个图框标题栏里的“图号、图名、版本、日期”提取出来，汇总到一张 Excel 表格里。
这个任务的流程比较直接：
- 遍历目录下所有 DXF 文件；
- 在模型空间里查找块引用；
- 过滤出图框图块；
- 读取属性；
- 输出到 Excel。
但从实测来看，直接让模型生成这段脚本往往会出错。最常见的问题是块名不一致。A 图纸里的图框块叫 TITLE_BLOCK，B 图纸里叫 TB1，C 图纸里干脆没有块，标题栏是一堆散落的 TEXT 图元。遇到这样的情况，模型写出来的规则只能处理一部分文件。
我的处理方式是：先让模型生成一个扫描脚本，把每个文件的块名、图层名、文本内容全部统计出来，生成一个分布报告。然后再根据报告决定提取规则。这一步看起来多花了一点时间，但能让模型更好地理解图纸的“实际形态”，而不是只依赖一般性假设。
信息提取的验收标准最好量化：哪些文件成功提取，哪些文件匹配失败，失败的文件集中是什么原因。能拿到这三个数字，整个流程才算有价值。
3.2 场景 B：批量修改图层与字体
第二个场景是批量修改：把一批图纸里的图层统一到公司规范，把缺少的字体替换成默认字体。
这个任务与信息提取不同，它的风险更高，因为修改的结果会直接影响到图纸的可用性。实测中我建议先做一个小的子集，而不是直接跑全量。
具体步骤大致是：
- 选定 5 个文件作为验证集；
- 用脚本扫描所有图层和文字样式；
- 先生成一份“修改前报告”，记录每个文件里使用了哪些样式；
- 执行批量修改；
- 用 CAD 打开修改后的文件，抽查 2 到 3 张；
- 确认没问题后再跑剩余文件。
注意：批量修改前，先对验证集做完整备份，并记录修改前的样式清单，否则出现问题后很难判断是哪一步造成的。
实测中我发现两个高频问题。第一，字体替换后文字宽度可能发生变化，导致文本框溢出或重叠；第二，不同文件的坐标单位不一致，有的是毫米，有的是英寸，如果把同一套缩放规则套上去，图形位置就会错乱。所以，在执行任何几何或样式修改前，先统一确认单位，再确认字体度量方式，最后再修改。
3.3 场景 C：按参数生成简单示意图
第三个场景是参数化生成：根据输入的一些设备编号和坐标，在模板图上生成对应的端口示意、设备位置标识或简单管线示意图。
这类任务看起来很酷，但也是三个场景中最容易产生“幻觉”的场景。模型可以很快地生成代码来创建圆、矩形、文字和标注，但生成的坐标、比例、方向是否符合真实工程需求，必须有人把关。
我实测时遇到一个问题：模型生成的文字框大小是按逻辑单位计算的，但实际图纸里不同视口比例不同，文字放进去要么太小看不见，要么直接把原有图元盖住。后来我的处理方式是：所有尺寸和坐标都先归一化到毫米，让它输出一个 JSON 配置文件，再由执行层读取配置写入 DXF。这个“模型生成数据，代码负责绘图”的分工，比让模型直接生成绘图参数要稳定得多。
| 场景 | 模型代写脚本的可用率 | 真正耗时点 | 人工介入点 |
|---|---|---|---|
| 信息提取 | 较高，但需要先扫描结构 | 块名不一致、文本打散 | 确认字段映射、检查失败清单 |
| 批量修改 | 中等，风险集中在单位与样式 | 字体溢出、单位错乱 | 抽查修改前后文件、确认影响范围 |
| 参数化生成 | 中等，几何逻辑容易出错 | 比例、视口、坐标方向 | 用 CAD 打开核查图形效果 |
4. 最容易翻车的地方：边界、单位与异常处理
4.1 输入边界：图纸永远不会完全标准
工程图纸的“标准”更多时候是理想状态。图框有块、图框是散线、图层有中英文混用、文字出现乱码，这些都可能在同一个目录里出现。AI 代理只能处理它读到的信息，如果输入本身就没有稳定结构，输出就不会稳定。
因此，在任务开始前先做一次输入体检非常关键。体检内容包括：文件是否能被解析、是否包含图框块、图层列表是什么、文字样式有哪些、是否存在代理实体。先得到这些信息，再决定流程能不能自动化。
4.2 环境边界：路径、版本和单位
中文路径在自动化脚本里是个高频坑点。Windows 下部分库对中文路径支持不一致，轻则警告，重则直接读不出来。建议在处理流程中统一使用英文字段路径，或者在脚本里显式处理编码。
CAD 版本也需要关注。高版本 CAD 打开旧版图纸一般没问题，但旧版打不开新版。如果团队里有人还在用老版本，批量修改后的图纸要导出一份兼容格式。
单位问题更需要警惕。同样的“宽度 10”，在毫米和英寸两个单位下含义完全不同。如果脚本里的比例因子设置错了，可能整个图都错位。每次执行前，先打印当前文件的单位设置，再执行几何修改。
4.3 参数边界：不要一上来就拉满
在批量处理或调用 CAD 执行时，最不建议做的就是把并发数和批量数直接拉满。原因很简单：模型生成的脚本没有经过长时间稳定性测试，遇到异常文件时可能会卡住、崩溃或者输出一堆误导性日志。更好的做法是：
- 第一步：1 个文件，确认整条链路通。
- 第二步：5 个文件，确认边界条件下也能处理。
- 第三步：50 个文件，观察执行时间和失败率。
- 第四步：排查失败文件，再决定是否全量。
注意：不要让 AI 代理在无人看管的情况下直接处理所有正式图纸。自动化流程再稳定，也需要一个人来确认“处理结果没有引入新问题”。
4.4 一条可复用的排查链路
如果实测中出了问题，我建议按下面的顺序排查，而不是直接怀疑模型能力。
- 看现象：是报错、卡住、无输出、输出乱码，还是结果不完整？
- 看输入：文件格式、图层命名、块定义、字体、路径编码是否超出预期？
- 看环境：依赖库版本、CAD 版本、单位、系统权限是否匹配？
- 看参数：批量数、并发数、超时设置、过滤规则是否过于激进？
- 看工具边界：当前模型版本或代理工具是否支持这个特性？是不是把能力边界当成了 bug？
这个顺序可以避免很多无效排查。大部分问题都不是“AI 不够聪明”，而是输入数据不符合脚本假设、环境变量不一致，或者参数设置不合理。
5. 从一次实测到可复用流程：工程化三件事
5.1 日志与留痕
只输出一个结果文件是不够的。长期使用 AI 代理处理图纸时，必须记录下每一次执行的时间、输入文件、脚本版本、输出文件、失败原因和人工复核结果。这样当某张图纸出现问题时，你能快速回退到对应的环节，而不是重新跑一遍全流程。
我在实测中会用 JSON 记录每次批量任务的元信息：文件列表、脚本 hash、输出摘要、异常清单。这些记录看起来不起眼，但它是流程可以复盘、可以优化、可以交接的基础。
5.2 人机复核点
完全自动化在 CAD 工程场景里不是一个好目标。更合理的设计是定义好人机复核点。复核点不宜太多，否则流程又变回手工操作；但也不能没有。
我的建议是在三个位置放复核点：
- 执行前：确认任务切片和字段映射；
- 执行中：抽查小批量输出结果；
- 执行后：让专业工程师复核关键图纸。
5.3 备份与回滚
任何批量修改都有风险。正式执行前，一定要保留一份原始文件备份。这个备份可以放在独立目录，也可以做成压缩包。不要在原始文件上原地修改，除非你确认脚本已经被验证过非常多次。
5.4 沉淀任务模板
当同一个流程跑通三到五次之后，就可以把它沉淀成模板。模板不只包括代码脚本，还包括：任务输入格式、异常清单、验收标准、人工复核点和已知坑位。这样下次再遇到类似任务时，就不需要从零开始跟模型描述需求，直接把模板丢给执行层即可。
5.5 适用边界再强调
这套方法适合：图纸信息提取、格式统一、批量修订、参数化示意的生成与验证。
不适合：复杂机械结构决策、公差与装配干涉判断、需要多方协商的空间布置、对错判零容忍的极端安全场景。
如果团队打算引入类似方案，我的建议是先选一个足够小的任务，跑通并沉淀模板，再逐步扩大范围。不要一开始就追求“所有图纸都能自动处理”。
6. 回到最开始的那个问题：AI 代理到底改变了什么
让我回到开头那个场景：47 张图纸，下班前要改完版本号并导出。在以前，这是要加班到深夜的体力活。现在，如果信息提取、批量修订这套流程已经跑通，它可能就是一条命令的事，剩下的是人工抽检和确认。
但这不是“AI 替代了设计师”的故事。真正发生的事情是：设计师终于不用把时间花在 47 张图纸重复改版本号上，可以留出精力去处理更值得判断的工程问题。Claude Fable 5 × MecAgent 这类组合，在 CAD 工程里最大的价值，是让规则的执行变得可控、可复用、可追溯，而不是让设计决策消失。
如果只做一件事，我建议你先选择信息提取这类边界清楚、收益可量化的任务开始。先把一条流程从“模型生成脚本”走到“批量处理、输出报表、人工复核”，再考虑扩展到更多场景。工程自动化的地基是规则梳理和验收标准，大模型和代理工具只是把这条地基上的楼盖得更快而已。
