简介这份资源面向工程技术人员、软件开发人员及需批量处理图纸的企业管理者聚焦PDF工程图纸信息的自动化提取。内容围绕两条主线展开一是从图纸标题栏抓取信息并统计单重、数量、总重等参数输出至Excel表格二是依据上传的模板定位尺寸标识符匹配名义尺寸与单位汇总成可进一步加工的数据表。方案强调本地化部署自定义AI模型结合OCR、PDF解析与机器学习用户可自行采集标注数据集训练优化兼顾数据安全与业务适配。资源包为1个PDF文件约393KB内含需求说明与实现思路便于理解整体流程与功能边界。目前已有102人学习下载。读者可借此掌握标题栏抓取、模板化尺寸提取、批量图纸处理等关键环节的设计逻辑为搭建同类自动化系统提供参考。1. 工程图纸 PDF 信息提取从“能看”到“能算”的那道坎很多做工程数字化的朋友都遇到过这个场景甲方甩过来一个压缩包里面是几百张 PDF 格式的工程图纸要求把标题栏里的图号、材料、比例、设计人以及明细表里的零件清单全部录入系统。人工一张张看、一个个敲几百张图就是好几天还容易敲错。基于 PDF 的工程图纸信息自动化提取系统要解决的就是这件事——让机器把图纸里结构化的信息自动读出来输出成电子表格或直接入库。这个方向适合三类人一是做工程管理系统的后端或全栈工程师需要把图纸信息接入现有业务流二是设计院、制造企业的数字化岗日常被图纸录入折磨三是想用 AI 模型做文档理解落地的开发者工程图纸是一个边界清晰、验证方便的场景。它不要求你把整张图纸的每个像素都理解透只需要把标题栏、明细表、图签这几个固定区域的信息稳定抽出来就能省掉大量重复劳动。下面按“先搞清楚图纸 PDF 里到底有什么 → 怎么定位和提取 → 怎么用 AI 模型兜底 → 怎么避坑 → 怎么验证效果”的顺序讲透。2. 工程图纸 PDF 的三种形态与提取路线选型动手之前必须先判断手里的 PDF 属于哪一类因为不同形态对应的提取路线完全不同选错了后面全是白干。工程图纸 PDF 大致分三种原生矢量 PDF、扫描件 PDF、以及混合型 PDF。原生矢量 PDF 是 CAD 软件直接导出或虚拟打印生成的文字以文本对象存在可以直接用解析库读取扫描件 PDF 本质是图片文字是像素必须走 OCR 或视觉模型混合型则是部分页面矢量、部分页面扫描或者同一页里标题栏是矢量文字、图形区域是嵌入图片。2.1 用 pdfplumber 判断 PDF 是否含可提取文本第一步不是急着写提取逻辑而是先探测 PDF 的文本层情况。我一般用 pdfplumber 快速扫一遍看每页能提取出多少字符、字符的坐标分布是否集中在标题栏区域。import pdfplumber def probe_pdf(pdf_path): 探测 PDF 每页的文本层情况判断提取路线 with pdfplumber.open(pdf_path) as pdf: for i, page in enumerate(pdf.pages): text page.extract_text() or # 统计字符数和文本行数 char_count len(text.strip()) # 提取所有字符对象看坐标分布 chars page.chars # 如果字符数极少但页面尺寸正常大概率是扫描件 print(f第{i1}页: 字符数{char_count}, 字符对象数{len(chars)}, f页面尺寸{page.width:.0f}x{page.height:.0f}) if char_count 20 and len(chars) 20: print(f - 第{i1}页疑似扫描件需要 OCR 或视觉模型) else: # 看文本主要落在哪个区域 if chars: xs [c[x0] for c in chars] ys [c[top] for c in chars] print(f - 文本 X 范围: {min(xs):.0f}-{max(xs):.0f}, fY 范围: {min(ys):.0f}-{max(ys):.0f}) probe_pdf(sample_drawing.pdf)这段代码的逻辑很直接extract_text()拿到的是 pdfplumber 按阅读顺序拼出来的文本如果字符数很少说明这一页没有可用的文本层。page.chars是更底层的字符对象列表每个字符带x0、top等坐标通过坐标范围能判断文字是集中在右下角标题栏还是散落全图。参数上字符数阈值我一般设 20低于这个值基本可以判定为扫描件坐标范围用来辅助判断标题栏位置工程图纸的标题栏通常在右下角X 范围偏右、Y 范围偏下。注意有些 CAD 导出的 PDF 文字虽然可选但字符被拆成了单个字母或乱序extract_text()出来的结果可能是乱码。这种情况要看chars里每个字符的text属性是否正常如果单个字符正常但拼接顺序乱需要按坐标重新排序。2.2 原生矢量 PDF 的表格与文本块提取确认是原生矢量 PDF 后优先走解析路线因为速度快、成本低、结果稳定。工程图纸里最需要提取的是标题栏和明细表标题栏通常是键值对形式明细表是规整的表格。pdfplumber 提供了extract_tables()和extract_words()两个利器。import pdfplumber import re def extract_title_block(page, bbox): 从指定区域提取标题栏键值对 bbox: (x0, top, x1, bottom) 标题栏的裁剪区域 # 裁剪出标题栏区域 cropped page.crop(bbox) words cropped.extract_words(keep_blank_charsFalse, use_text_flowTrue) # 按行分组top 坐标相近的归为一行 lines {} for w in words: key round(w[top] / 5) * 5 # 5pt 容差归并 lines.setdefault(key, []).append(w) result {} for top in sorted(lines.keys()): row sorted(lines[top], keylambda x: x[x0]) # 简单策略一行里第一个词当键后面拼接当值 if len(row) 2: k row[0][text].strip(:) v .join(w[text] for w in row[1:]) result[k] v return result def extract_detail_table(page, table_bbox): 提取明细表返回二维列表 cropped page.crop(table_bbox) tables cropped.extract_tables({ vertical_strategy: lines, horizontal_strategy: lines, snap_tolerance: 3, }) return tables[0] if tables else [] with pdfplumber.open(sample_drawing.pdf) as pdf: page pdf.pages[0] # 标题栏区域需要根据实际图纸调整这里给的是常见右下角范围 tb extract_title_block(page, (page.width*0.6, page.height*0.75, page.width, page.height)) print(标题栏:, tb) dt extract_detail_table(page, (page.width*0.05, page.height*0.05, page.width*0.95, page.height*0.5)) print(明细表行数:, len(dt))extract_words()会把文本拆成词每个词带坐标。按top坐标归并成行是处理标题栏的关键因为标题栏里“图号”和它的值通常在同一水平线上。round(w[top] / 5) * 5这个 5pt 容差是经验值太小会把同一行拆开太大会把相邻行合并。extract_tables()的参数里vertical_strategy和horizontal_strategy设为lines表示按表格线来切分工程图纸的明细表一般都有完整边框线这个策略最稳。如果表格线不完整可以改成text策略按文字对齐来推断但准确率会下降。2.3 扫描件与混合型 PDF 的预处理扫描件没有文本层必须先转成图片再做 OCR 或送视觉模型。混合型 PDF 则要逐页判断矢量页走解析、扫描页走 OCR。转图片用 pdf2image 或 PyMuPDF 都可以我倾向 PyMuPDF因为它不依赖外部 poppler 环境部署更省心。import fitz # PyMuPDF def pdf_page_to_image(pdf_path, page_num, dpi300): 将指定页转为图片返回 PIL Image 或字节 doc fitz.open(pdf_path) page doc[page_num] # 按 DPI 计算缩放矩阵 zoom dpi / 72.0 mat fitz.Matrix(zoom, zoom) pix page.get_pixmap(matrixmat, alphaFalse) img_bytes pix.tobytes(png) doc.close() return img_bytes # 300 DPI 是工程图纸 OCR 的常用起点 img pdf_page_to_image(scanned_drawing.pdf, 0, dpi300) with open(page0.png, wb) as f: f.write(img)DPI 的选择直接影响 OCR 效果和速度。工程图纸线条细、字号小150 DPI 经常丢字300 DPI 是平衡点如果图纸特别大或字特别小可以上 400 DPI但处理时间会明显增加。alphaFalse去掉透明通道避免后续 OCR 引擎把透明背景当黑色处理。转出来的图片如果对比度低可以先做二值化或自适应阈值OpenCV 的adaptiveThreshold对工程图纸效果不错。提示混合型 PDF 不要整本统一处理先按 2.1 的方法逐页探测给每页打上“矢量/扫描”标签再分流到不同管线。统一处理会导致矢量页被无谓地 OCR既慢又可能引入识别错误。3. 标题栏与明细表的定位从固定坐标到自适应锚点提取的准确率很大程度上取决于区域定位准不准。工程图纸的标题栏位置虽然大体在右下角但不同设计院、不同图幅的模板差异很大硬编码坐标只能应付一种模板。实际落地时我一般用“锚点定位 相对偏移”的策略先找到标题栏里的固定关键词再以它为基准推算其他字段的位置。3.1 基于关键词锚点的标题栏定位标题栏里总有几个词是稳定的比如“图号”“比例”“材料”“设计”“审核”。这些词就是锚点。先用全文搜索找到锚点词的坐标再根据锚点之间的相对位置关系确定整个标题栏的边界。import pdfplumber ANCHOR_WORDS [图号, 图样代号, 比例, 材料, 设计, 审核, 重量] def locate_title_block(page): 通过锚点词定位标题栏边界 words page.extract_words() anchors [] for w in words: for aw in ANCHOR_WORDS: if aw in w[text]: anchors.append(w) break if not anchors: return None # 以所有锚点的包围盒为基础向外扩展 x0 min(a[x0] for a in anchors) - 20 top min(a[top] for a in anchors) - 10 x1 max(a[x1] for a in anchors) 150 # 右侧留出值的空间 bottom max(a[bottom] for a in anchors) 10 # 限制在页面范围内 x0 max(0, x0); top max(0, top) x1 min(page.width, x1); bottom min(page.height, bottom) return (x0, top, x1, bottom) with pdfplumber.open(sample_drawing.pdf) as pdf: page pdf.pages[0] bbox locate_title_block(page) print(标题栏区域:, bbox)这段代码的核心思路是不假设标题栏在哪个固定坐标而是让锚点词自己“长”出边界。x1加 150 是给右侧的值留空间因为锚点词本身只是键值在它右边。如果图纸标题栏是竖向排列的锚点的 X 坐标会接近而 Y 坐标分散这时候包围盒策略依然有效。找不到任何锚点词时返回None上层逻辑应该回退到固定区域或人工确认。3.2 明细表结构识别与行列对齐明细表比标题栏复杂因为它有表头、多行数据、可能还有合并单元格。工程图纸明细表的常见列有序号、代号、名称、数量、材料、重量、备注。识别时先定位表头行再逐行读取。def parse_detail_table(page, table_bbox): 解析明细表返回字典列表 cropped page.crop(table_bbox) tables cropped.extract_tables({ vertical_strategy: lines, horizontal_strategy: lines, snap_tolerance: 3, join_tolerance: 3, }) if not tables: return [] raw tables[0] # 找到表头行包含“序号”或“代号”的行 header_idx None for i, row in enumerate(raw): row_text .join(c or for c in row) if 序号 in row_text or 代号 in row_text: header_idx i break if header_idx is None: return [] headers [c.strip() if c else fcol{j} for j, c in enumerate(raw[header_idx])] records [] for row in raw[header_idx1:]: if not any(row): continue rec {} for j, cell in enumerate(row): if j len(headers): rec[headers[j]] cell.strip() if cell else records.append(rec) return recordsextract_tables返回的是二维列表每个单元格是字符串或None。找表头行是为了给列命名这样后续按列名取值比按索引取值稳定得多。join_tolerance控制相邻表格线的合并容差工程图纸里有些线画得比较近容差太小会把一列拆成两列。如果表格没有完整边框线lines策略会失败这时候要改用text策略但需要额外处理列对齐准确率会打折扣。注意明细表里经常出现跨行合并的单元格比如一个零件名称占两行。pdfplumber 对合并单元格的处理是把值放在第一行第二行对应位置为None。解析时要判断None并继承上一行的值否则会丢数据。3.3 多模板适配的配置化思路一个系统要处理多家设计院的图纸模板适配是绕不开的。我的做法是把锚点词、区域扩展量、表头关键词这些做成配置文件每种模板一个配置运行时先匹配模板再提取。import json TEMPLATE_CONFIG { template_a: { anchors: [图号, 比例, 材料], expand_right: 150, header_keywords: [序号, 代号, 名称], table_region: [0.05, 0.05, 0.95, 0.5] }, template_b: { anchors: [图样代号, 比例, 重量], expand_right: 180, header_keywords: [件号, 代号, 名称], table_region: [0.05, 0.1, 0.95, 0.55] } } def match_template(page): 根据锚点词匹配模板 words [w[text] for w in page.extract_words()] full_text .join(words) best None best_score 0 for name, cfg in TEMPLATE_CONFIG.items(): score sum(1 for a in cfg[anchors] if a in full_text) if score best_score: best_score score best name return best if best_score 2 else None配置化的好处是新增模板不用改代码加一段 JSON 就行。match_template用锚点词命中数来打分命中 2 个以上才认为匹配成功避免误判。table_region用相对比例而不是绝对坐标这样不同图幅A0、A1、A2都能用同一套配置。实际运行中如果匹配不到模板应该把这张图标记为“待人工确认”而不是硬套一个默认模板否则错误会静默传播。4. AI 模型兜底什么时候该上视觉模型怎么上解析路线能覆盖大部分原生矢量 PDF但遇到扫描件、文字乱序、表格线缺失的情况规则方法就力不从心了。这时候需要 AI 模型兜底。但“上模型”不是无脑把所有图都送进去那样成本高、速度慢而且模型也可能出错。合理的策略是分层规则能搞定的走规则规则置信度低的才送模型。4.1 规则提取的置信度评估在决定是否调用模型之前先给规则提取的结果打个分。评分维度包括关键字段是否齐全、字段值是否符合格式、表格行数是否合理。import re def score_extraction(title_block, detail_table): 给规则提取结果打分0-1低于阈值走模型 score 1.0 # 关键字段缺失扣分 required [图号, 比例, 材料] for k in required: if k not in title_block or not title_block[k]: score - 0.2 # 图号格式校验通常是字母数字组合 if 图号 in title_block: if not re.match(r^[A-Za-z0-9\-\.]$, title_block[图号]): score - 0.15 # 明细表行数异常扣分 if len(detail_table) 0: score - 0.3 elif len(detail_table) 200: score - 0.1 # 行数过多可能是解析错误 return max(0.0, score) # 使用示例 tb {图号: ABC-001, 比例: 1:1, 材料: Q235} dt [{序号: 1, 名称: 支架}] print(置信度:, score_extraction(tb, dt))评分逻辑是经验性的required列表里的字段根据业务重要性调整。图号格式校验用正则工程图号一般由字母、数字、连字符、点组成如果提取出来的是乱码或空值正则匹配会失败并扣分。明细表行数为 0 说明表格定位失败扣分最重。阈值我一般设 0.6低于这个值就触发模型兜底。这个分数不是绝对准确的但能有效筛出明显有问题的结果避免把错误数据直接入库。4.2 用视觉模型提取图纸关键字段视觉模型如基于 ViT 架构的文档理解模型可以直接看图纸图片输出结构化字段。部署方式有两种调用云端 API 或本地部署。本地部署用开源模型更可控但需要 GPU 资源。下面是一个调用本地视觉模型服务的示例假设模型服务已经按标准接口部署好。import base64 import requests import json def call_vision_model(image_bytes, fields): 调用本地视觉模型服务提取字段 image_bytes: 图纸图片字节 fields: 需要提取的字段列表 img_b64 base64.b64encode(image_bytes).decode(utf-8) prompt f请从这张工程图纸中提取以下字段以JSON返回{, .join(fields)} payload { model: doc-vision, messages: [ { role: user, content: [ {type: text, text: prompt}, {type: image_url, image_url: {url: fdata:image/png;base64,{img_b64}}} ] } ], temperature: 0.1, # 低温度保证输出稳定 max_tokens: 1024 } resp requests.post(http://localhost:8000/v1/chat/completions, jsonpayload, timeout60) resp.raise_for_status() content resp.json()[choices][0][message][content] # 从返回文本中解析 JSON try: return json.loads(content) except json.JSONDecodeError: # 模型可能返回带 markdown 代码块的 JSON import re m re.search(r\{.*\}, content, re.DOTALL) return json.loads(m.group()) if m else {} # 使用只对置信度低的页面调用 result call_vision_model(img_bytes, [图号, 比例, 材料, 设计, 审核]) print(result)temperature设为 0.1 是为了让模型输出尽量确定工程数据不需要创造性。max_tokens根据字段数量调整字段多就调大。返回内容可能带 markdown 代码块标记所以解析时要先尝试直接json.loads失败再用正则提取花括号内容。这个接口格式是常见的兼容 OpenAI 风格的本地服务具体地址和模型名按实际部署改。提示视觉模型对图片分辨率敏感送进去之前确保 DPI 在 200-300 之间。太低看不清小字太高会超出模型输入限制。如果图纸很大可以先裁剪出标题栏和明细表区域再送模型既提高准确率又减少 token 消耗。4.3 规则与模型的融合策略规则和模型不是二选一而是互补。我的融合策略是规则先跑输出字段和置信度置信度高的字段直接用置信度低的字段用模型结果覆盖如果模型结果和规则结果冲突且都不可信标记为待人工确认。def merge_results(rule_result, model_result, rule_score): 融合规则和模型结果 merged {} conflicts [] all_keys set(rule_result.keys()) | set(model_result.keys()) for k in all_keys: rv rule_result.get(k, ) mv model_result.get(k, ) if rv and mv: if rv mv: merged[k] rv else: # 冲突时规则置信度高用规则否则用模型 if rule_score 0.8: merged[k] rv else: merged[k] mv conflicts.append((k, rv, mv)) elif rv: merged[k] rv elif mv: merged[k] mv return merged, conflictsrule_score是 4.1 算出来的整体置信度。冲突记录conflicts要保留方便后续人工复核和模型调优。如果某个字段频繁冲突说明规则或模型在这个字段上有系统性问题需要针对性改进。融合后的结果写入电子表格或数据库冲突项单独存一张表供人工处理。5. 避坑与排查那些让提取准确率掉到 60% 的细节这一章记录的是我在实际项目里踩过的坑每一条都对应过真实的准确率下降。现象、原因、解决三件套照着排查能省不少时间。5.1 现象矢量 PDF 提取出来全是乱码字符顺序颠倒原因部分 CAD 软件导出的 PDF 使用了自定义字体编码字符的text属性正常但extract_text()按内部顺序拼接导致顺序错乱。解决不要用extract_text()改用extract_words()按坐标排序后自行拼接。如果chars里的text本身就是乱码说明字体没有正确嵌入需要让源头重新导出 PDF或在提取前用 OCR 兜底。5.2 现象明细表提取行数正确但列错位数量列跑到了名称列原因表格线不完整或存在合并单元格extract_tables的lines策略把两列合并成了一列。解决先检查表格区域是否有完整边框线没有的话改用text策略并手动指定列边界。对于合并单元格解析后要做空值继承把None替换为上一行的值。5.3 现象扫描件 OCR 把“0”识别成“O”图号入库后查不到原因OCR 引擎对工程字体的数字和字母区分度不够尤其是 0/O、1/I/l、5/S。解决在 OCR 后加一层正则校正图号字段只允许数字和大写字母把常见混淆字符按上下文替换。更稳的做法是维护一个图号白名单或格式模板不符合模板的标记为待确认。5.4 现象视觉模型返回的 JSON 解析失败程序抛异常中断原因模型输出不稳定有时带 markdown 代码块有时在 JSON 前后加解释文字有时字段名和预期不一致。解决解析时做多层容错——先直接json.loads失败则正则提取花括号内容再失败则记录原始输出并返回空字典。字段名不一致时用模糊匹配比如“图号”和“图样代号”都映射到同一个内部字段。5.5 现象批量处理几百张图跑到一半内存溢出原因pdfplumber 和 PyMuPDF 打开 PDF 后如果不显式关闭页面对象和图片数据会累积在内存里。解决用with语句管理 PDF 打开和关闭图片处理完立即释放批量任务分批处理每批 50 张左右批间手动触发垃圾回收。如果单张图特别大转图片时降低 DPI 或只裁剪需要的区域。6. 验证提取效果用 20 张图跑出一份可信的准确率报告系统搭起来之后怎么知道它到底行不行不能靠感觉要有可量化的验证。我的做法是挑 20 张有代表性的图纸——覆盖不同模板、不同图幅、矢量与扫描混合——人工标注一份标准答案然后跑自动提取逐字段对比。6.1 构建小规模标注集与对比脚本标注集不用大20 张足够暴露主要问题。每张图标注标题栏字段和明细表行数、关键列的值。对比脚本按字段计算准确率。import json def evaluate(ground_truth, predictions): 对比标注和预测结果输出各字段准确率 field_stats {} for gt, pred in zip(ground_truth, predictions): for k, v in gt.items(): if k not in field_stats: field_stats[k] {total: 0, correct: 0} field_stats[k][total] 1 pv pred.get(k, ) # 去除空白后比较 if str(v).strip() str(pv).strip(): field_stats[k][correct] 1 report {} for k, s in field_stats.items(): acc s[correct] / s[total] if s[total] else 0 report[k] {准确率: f{acc:.1%}, 样本数: s[total]} return report # 加载标注和预测 with open(ground_truth.json, encodingutf-8) as f: gt json.load(f) with open(predictions.json, encodingutf-8) as f: pred json.load(f) report evaluate(gt, pred) for k, v in report.items(): print(f{k}: 准确率{v[准确率]}, 样本数{v[样本数]})对比时要注意字段值的归一化比如“1:1”和“11”全角半角差异、空格差异比较前统一处理。准确率低于 90% 的字段要重点排查看是定位问题还是识别问题。明细表的评估要按行匹配行数对但内容错位也算错。6.2 从准确率报告定位瓶颈拿到报告后按字段看如果“图号”准确率高但“材料”低说明材料字段的锚点或区域有问题如果所有字段都低说明模板匹配失败或 PDF 形态判断错了。我一般会做一张表把每个字段的准确率、失败样例、失败原因列出来然后按影响面排序逐个解决。字段准确率主要失败原因改进措施图号95%扫描件 0/O 混淆加正则校正比例88%锚点词“比例”在部分模板中写作“比列”扩充锚点词表材料72%材料值跨行规则只取第一行合并单元格继承逻辑明细表行数90%无边框表格漏行切换 text 策略这张表是迭代的依据每改一轮重新跑评估看准确率是否提升。不要一次改太多否则分不清是哪个改动起了作用。6.3 一个让我少走弯路的习惯我现在做任何图纸提取项目第一件事永远是拿 5 张图跑探测脚本确认 PDF 形态和文本层情况而不是先写提取逻辑。这个习惯帮我避免了很多次“写了一堆代码结果发现全是扫描件”的翻车。另外标注集一定要在项目初期就建哪怕只有 10 张它能让你在每次改动后快速知道是变好了还是变差了。工程图纸提取没有一步到位的方案都是靠“探测 → 提取 → 评估 → 修正”这个循环磨出来的。希望帮到你。本文还有配套的精品资源点击获取