1. 图纸标注复核这件事为什么值得用 VLM 来做先把话说明白这张“vlm 当前图纸是否符合标注要求如果不符合请给出修改步骤”的指令本质上是一道“输入图纸、输出诊断结论和整改动作”的复合任务。它把两件事牢牢焊在了一起——合规性判定和可执行的修改路径而且这两件事都得落在“当前图纸”这个具体对象上不是泛泛而谈的标准条文。干过图纸审核的人都知道标注合规问题一直是个“三高”场景高重复性、高经验依赖、高返工成本。新图纸拿到手先查标注完整性再看标注样式和数值与标准的吻合度最后还要对照装配关系确认标注逻辑没有“自说自话”。这套流程让一个熟练工程师来做单张图纸少说也要十分钟遇到复杂的结构件半小时打底。而且人眼审核最大的问题是疲劳导致的漏判——一张图纸看到第40个尺寸标注时前面那处漏标的粗糙度符号你可能再也想不起来了。VLMVision Language Model视觉语言模型恰恰在“看图理解语义”这件事上展现出了实用价值。它能同时处理图像像素信息和文本语义信息把“图上标了什么”和“标准要求什么”放在同一个推理框架里比较。更关键的是现在的 VLM 已经能够输出结构化结果——不只是说一句“这里有问题”而是指出“哪个区域、哪个标注类型、违反了哪一条、建议怎么改”。这意味着它可以被嵌入到现有的图纸管理流程里做一个“自动初审 人工复核”的辅助角色而不是停留在 Demo 阶段的新鲜玩意儿。这篇内容我就围绕一个实战场景展开如何设计和部署一条“图纸标注合规审查 修改建议生成”的 VLM 工作流包括模型选型思路、提示词怎么写才不容易翻车、结构化输出怎么设计、不同标注问题怎么分类处理以及在真实落地时会遇到的坑。无论你是做机械结构、电气原理图还是建筑制图这套思路都能平移过去用。2. 整体方案设计先搞清楚“合规”到底在比什么2.1 一次合规审查本质上是一个“三段式比较”我见过太多人一上来就 prompt“请检查这张图”然后期望模型输出一个完美报告——这属于把希望寄托在玄学上。图纸标注合规审查底层逻辑不是“看图说话”而是一个标准化程度很高的比较任务第一段图纸里“有什么”。提取所有标注元素——尺寸线、公差、基准符号、粗糙度、焊接符号、标题栏信息、技术要求文本等等。这一步要求模型具备扎实的版面理解能力能区分“这个数字是尺寸还是零件编号”这一类细节。第二段标准里“要什么”。对照当前适用的标准体系机械图纸一般看 GB/T 系列外贸图纸可能涉及 ISO 或 ASME明确每一类标注的强制性要求、推荐样式和允许的简化形式。比如“尺寸标注不能形成封闭尺寸链”“基准符号必须与基准要素对应”“表面结构要求应该标注在轮廓线或延长线上”等等。第三段两边“差多少”。把提取出来的标注事实和标准要求逐项做语义比对输出差异项然后基于差异项生成修改建议。理解了这三段式你就明白为什么通用对话类模型直接拿来审图会漏洞百出——大多数模型在“提取”这一步就丢三落四在“比对”这一步又缺少标准条文的精确锚定。所以真正可落地的方案不是找一个大模型一把梭而是把任务拆解成提取、比对、建议三个环节分别约束最后再合并输出。2.2 为什么不能用纯目标检测的方案也别指望端到端一步到位很多制造企业其实已经有机器视觉的基础设施用的还是 YOLO 这类目标检测模型。这些模型识别“有没有一个尺寸标注框”没问题但面对“这个标注的基准代号和另一个标注的基准要素是不是同一件事”“公差带了小数点后几位才符合工艺要求”这类跨区域语义关联问题就完全无能为力了。标注合规里很大一部分问题恰恰是逻辑层面的不是存在性层面的。端到端 VLM 直接出结论技术上行不行部分行但稳定性很愁人。模型可能第一次审出“缺少基准标注”第二次给同一张图又说出“基准标注齐全”这在工程流程里没法接受。所以我的建议是用 VLM 做高召回率的候选问题提取用规则或者人做最终判定。也就是说VLM 的任务是“尽量把可疑的地方都揪出来并给出初步判据”再由下游的标准化规则引擎负责过滤误报或者直接由审核工程师做终审。这个“VLM 初筛 规则精筛/人工复核”的半自动闭环是目前实用性最高的落地形态。2.3 工具选型和模型能力边界不是所有 VLM 都适合审图当前能扛起“图纸审阅”任务的 VLM认准三类能力高分辨率图像理解、OCR 精度、结构化输出稳定性。高分辨率是为了看清密集的小尺寸标注OCR 精度决定了数字和后缀能不能正确读出结构化输出则保证你能拿到 JSON 而不是散文。具体到选型闭源模型里 GPT-4o、Claude 的视觉版本、Gemini 系列都是强选项各自强项不同。开源这边Qwen2-VL、InternVL 系列是我用得比较多的因为可以本地部署图纸数据不用出内网——这对制造企业来说几乎是刚需图纸是核心资产谁也不放心传公网。如果标注密集程度很高、细节极多建议优先考虑 7B 以上参数量级小模型在密集文本识别上会明显力不从心。注意模型选型不是一劳永逸。图纸类型一变从钣金件变成铸造件、标准版本一换从 GB/T 旧版切到新版同样的流程效果可能大幅波动必须重新跑一轮测试集评估别迷信“上个大模型就完事”。3. 核心细节解析提示词、输出结构和判定逻辑怎么设计3.1 提示词不要写成“请帮我看看”要写成“判定清单”提示词是这套流程里方差最大的模块几乎决定了下限。你给模型的不是一段话而是一份可执行的审核任务书。我的做法是把提示词拆成四个部分角色和上下文锚定告知模型“你是机械图纸标注审核员依据 GB/T 和 ISO 标准体系进行标注合规审查”限定任务范围防止模型自由发挥。标注类别检查清单把要审的标注类型枚举出来——尺寸标注、公差与配合、几何公差形位公差、表面粗糙度、焊接符号、基准符号、技术要求文字、标题栏信息。每一类都列明至少一条检查点。输出格式约束明确要求 JSON 结构每个问题条目必须包含issue_type问题类型、location区域描述或坐标、description问题描述、standard_ref参考标准条款、suggestion修改建议。兜底指令加入“没有问题时该条标记为 compliant”“不确定的信息不要编造标注为 needs_review”。举个可复用的示例这是我实际在用的骨架之一你是资深机械制图审核工程师。请对用户提供的工程图纸进行标注合规性复核。 核查范围 1. 尺寸标注是否存在漏标、过标、封闭尺寸链、标注位置遮挡、数字方向与标准不符 2. 几何公差是否标注了基准公差框格项目符号是否正确被测要素与基准的引用是否一致 3. 表面粗糙度符号是否按标准绘制数值和取样长度是否合理有无漏标关键表面 4. 标题栏图号、材料、比例、日期、签名等必备字段是否完整。 输出要求仅输出 JSON 对象形如 {compliant: true/false, issues: [{issue_type:..., location:..., description:..., standard_ref:..., suggestion:...}], summary:一句话整体结论} 特别注意如果某一区域无法判断请将 issue_type 设为 needs_review不要猜测。这里最容易被忽略的是“兜底指令”。工程场景里“不确定”本身就是一种合法输出它避免了模型一本正经地胡说八道。你宁可让它把可疑区域标出来让人复核也不要让它自信地给出一个错判。3.2 结构化输出的核心是“可机器消费”很多团队拿到了模型的 JSON 输出结果下游解析时报错——多半是没在设计时就约束死结构。我用过失败率最低的几种方式分享出来可以直接抄用 Pydantic 或 JSON Schema 在代码侧预定义结构把模型输出先进行一次严格校验不符合结构则触发重试带上错误信息让模型修正输出。每个 issue 必须有 location 字段且采用“区域 坐标”双轨描述。比如“右上角装配孔坐标约 (850, 420)”。坐标不要求像素级精准但必须有相对方位方便人工快速定位。suggestion 必须具体到动作不要说“请修正”要说“在直径尺寸 φ32 前补充公差代号 H7并标注基准字母 A”。设置输出 token 上限。问题项特别多的图纸输出容易被截断设计 prompt 时就要说明“如果问题超过 10 项优先输出最关键的 10 项”。结构化输出还有一个隐藏价值它让“人机协同审核”成为可能。每个 issue 可以挂到一个任务工单里审核员逐条确认或驳回模型下次可以带着这些“人工确认结果”做微调或者少样本示例越用越准。这个闭环一旦跑起来效率提升会非常明显。3.3 判定逻辑别全靠大模型叠加一个“规则闸门”纯靠 VLM 判定“是否符合标注要求”错误率目前还压不到生产可接受的水平。我的经验是搭一层规则闸门把模型输出做二次把关两层都通过才算通过第一类规则是硬性条款比如标题栏必填字段缺失、闭合尺寸链出现同一基准重复标注、直径符号漏标——这些能用脚本判定规则引擎直接接管不必等模型给结论。第二类规则是一致性校验比如图纸里出现了基准符号 B但几何公差框格里引用的基准在视图中没有对应要素——这类需要跨区域理解VLM 先做初判规则层再做交叉验证。规则闸门还有个附带好处把 VLM 从“背锅侠”的位置上解放出来。模型出现幻觉是概率问题但规则层兜住了最严重的几条整体系统的可信度就能上一个台阶。4. 实操过程还原一套图纸审查工作流的真实落地记录4.1 数据准备图纸渲染和图像质量是第一道生死线用真实图纸做过测试的人都知道模型翻车很多时候不是模型笨是你喂给它的图质量太差。PDF 直接截图、CAD 界面里随便导出的低清图、扫描件带歪斜——丢给 VLM 之前就注定了结果不可靠。我的经验是把图纸先做一步图像预处理哪怕只是最简单的三板斧统一渲染参数。从 CAD 里导出时关闭图层干扰如隐藏不需要的辅助线图层背景设为纯白线宽统一按标准设置字体不要用艺术字。目标是把“版面噪声”降到最低。分辨率下限设死。标注密集的图纸短边至少 1500~2000px长边不一定需要拉到极限但关键标注区域不能糊成一片。必要时分块输入。一张超长的大图比如 0 号图幅直接塞给模型细节基本会丢。按图幅分区域裁剪每个区域单独过一次模型最后合并结果召回率往往比单次输入高很多。分块输入听起来笨实测效果却非常稳。我把一张 A0 装配图切成九个区块单个块分别审查每一块的细节质量明显提升而且输出也更结构化——各区域问题天然归类合并时不用再做交叉切分。4.2 代码链路从图片输入到修改建议输出的完整实现实际跑通的核心链路并不复杂关键在于每一步都做好容错。下面的代码是我在 Python 环境下的一个可运行骨架基于 OpenAI 兼容的视觉接口封装import json import base64 from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, # 本地部署的 VLM 服务地址 api_keyEMPTY ) # 图纸渲染为图像后读取并编码 def encode_image(path): with open(path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) def review_drawing(image_path, project_meta): prompt f 你是资深机械制图审核工程师。请对图纸进行标注合规性复核。 项目信息{project_meta} 核查范围 1. 尺寸标注漏标、过标、封闭尺寸链、标注遮挡、数字方向 2. 几何公差基准标注、公差框格项目符号、被测要素引用 3. 表面粗糙度符号正确性、数值合理性、关键表面漏标 4. 标题栏图号、材料、比例、日期、签名等字段完整性。 输出要求仅输出 JSON包含 compliant(bool)、issues(list)、summary。 issues 中每个条目必须含 issue_type、location、description、standard_ref、suggestion 五个字段。 每项建议必须具体到可执行的动作例如补充标注、修改数值、移动位置、更换符号等。 如果无法判断将 issue_type 设为 needs_review不要猜测。 response client.chat.completions.create( modelqwen2.5-vl-7b, messages[ {role: user, content: [ {type: image_url, image_url: {url: fdata:image/png;base64,{encode_image(image_path)}}}, {type: text, text: prompt} ]}, ], max_tokens1500, temperature0.1, response_format{type: json_object}, ) content response.choices[0].message.content try: parsed json.loads(content) except json.JSONDecodeError: parsed {compliant: None, issues: [{issue_type: parse_error, location: , description: 模型输出非合法 JSON, suggestion: 重试或人工复核}], summary: 解析失败} return parsed def merge_reports(blocks): merged_issues [] for blk in blocks: if blk.get(issues): merged_issues.extend(blk[issues]) # 去重按 locationissue_type 合并 seen set() unique [] for issue in merged_issues: key (issue.get(location), issue.get(issue_type)) if key not in seen: seen.add(key) unique.append(issue) return unique if __name__ __main__: # 示例A0 图纸分 9 块逐一审查 from pathlib import Path block_dir Path(./drawing_blocks) blocks [] for png in sorted(block_dir.glob(*.png)): result review_drawing(str(png), project_meta减速器箱体装配图) blocks.append(result) print(f[完成] {png.name} - compliant{result.get(compliant)}) final_issues merge_reports(blocks) print(最终问题清单) for issue in final_issues: print(f- [{issue[issue_type]}] {issue[location]} | {issue[description]}) print(f 建议{issue[suggestion]})几个细节我要特别强调temperature 务必调低0.1 甚至 0。审图任务是强事实性任务不是创意任务温度高了同一个图两次审查结论不一致的概率会明显上升。response_format 尽量锁定 json_object。凡是支持这个参数的服务端就一定要用。它比你在提示词里说一百遍“只输出 JSON”都管用。max_tokens 不要抠门也不要过量。1500 左右是我用的平衡点图纸问题项很多时容易截断问题较少时浪费 token可以根据测试集的实际分布微调。合并报告时的去重逻辑很重要因为分块审查时跨区块边界的标注可能被两个块各报一次简单按“坐标 问题类型”去重可以把重复项消掉大半。更严格的方案可以在去重时引入坐标邻域判断——两个坐标相距 30px 以内视为同一位置。4.3 修改建议生成从“指出问题”到“给出动作”VLM 输出“这里不符合要求”不难难的是“怎么改是对的”。修改建议的生成质量取决于提示词里你给了模型多少“标准上下文”。我的做法是在提示词里嵌入一个简化版的标准条文对照表比如常见标注问题及对应修改动作参考 - 尺寸漏标补全尺寸注意尺寸线不能与轮廓线重合数字方向遵循水平字头朝上、垂直字头朝左 - 封闭尺寸链保留总尺寸删去中间一个分段尺寸或按设计意图改标参考尺寸带括号 - 几何公差缺基准到被测要素对应视图补充基准符号并确保基准字母与公差框格中引用一致 - 粗糙度漏标根据零件功能表面确定 Ra 值标注在轮廓线或尺寸延长线上符号尖端必须从材料外指向表面 - 标题栏不完整补齐图号和材料两列比例栏按实际绘图比例填写日期栏填写最新更改日期。把这些“标准答案片段”直接放到上下文里模型生成建议时就有了锚点。实测下来提示词里带参考动作表修改建议的可用率远高于不带表的场景。当然这样做的代价是提示词变长、token 消耗变大但对于审图这种单次分析任务投入产出比完全划算。提示如果你用的是开源模型本地部署除了提示词注入更推荐做“少样本微调”选几百张典型问题图纸人工标注好问题项和修改建议用 LoRA 做一轮轻量微调。微调后的模型在自家图纸分布上建议生成质量能再上一个台阶这是我把开源模型用顺手的核心经验。5. 三类典型问题的处理实录与经验沉淀5.1 典型问题一尺寸标注遗漏漏标一张法兰盘图纸模型报了一个“needs_review”类型的问题在左视图的螺栓孔分布圆上只有角度定位的 45° 等分线没有分布圆直径的尺寸标注。这个判断是对的分布圆直径属于装配关键尺寸漏标后工人没法加工。模型给出的修改建议是“在左视图标注分布圆直径如 4-φ12 均布于 φ80 圆周”。这里有个值得一提的处理细节VLM 强项在于发现“该有的东西没有”但这类问题的误报率也不低。原因在于有些标注可能在另一个视图中已经表达过了比如主视图已经标了分布圆直径左视图理所当然不再标。所以对“漏标”类问题规则闸门做一步交叉验证很有必要——先检查同一字段是否在其他视图已出现再决定是否保留这个 issue。5.2 典型问题二基准标注与公差框格引用不一致有一张阀体零件图形位公差框格写的是“⊥ A”但在整个视图里都没有找到基准符号 A。这种问题在人工审核时要靠“前后视图来回翻”才能发现而 VLM 一次性同时看到整张图跨区域比对反而是它的优势。模型报出的问题描述是“几何公差标注引用基准 A但视图中未找到对应基准符号无法判断被测要素的定位基准”修改建议是“补充基准符号 A 到基准平面底面轮廓延长线上或核对该公差应引用的基准是否正确”。这种问题很有代表性它不是简单的“缺不缺标注”问题而是“逻辑引用链断裂”问题。VLM 能抓住这类问题的原理是几何公差的基准引用本质上是一个跨区域的语义关联需要在整张图的范围里建立“被引用的基准符号”和“已标注的基准要素”之间的映射。这也是我为什么强调要用支持长上下文视觉输入的模型区域一多、要素一杂上下文不足就很容易漏。5.3 典型问题三标注样式违反标准规范标注样式问题属于高频问题比如粗糙度符号尖端方向不对、尺寸数字被图线穿越、箭头用了实心块而不是标准斜线箭头等等。这类问题模型抓得比较准因为标准的样式描述相对明确模型见得多。有一张铸件图模型提示“表面粗糙度符号标注在尺寸线上方不在轮廓线或延长线上且符号的尖端没有指向被测表面”建议改成“把粗糙度符号移动到轮廓线的延长线上尖端指向下表面”。这类建议的价值在于它不只是说“不对”而是告诉你“移到哪、尖端朝哪”工人或设计师按建议操作基本不用二次思考。处理样式类问题的心理预期要调好——这类问题数量多、单条修改成本低但最耗费审核时间。我把样式类问题做成了半自动修复如果 VLM 输出的 issue_type 是style且建议文本足够结构化包含“移动到”等动作词就自动转成 CAD 操作指令交给二次开发脚本批量执行剩下的复杂逻辑问题才转给人工。这样一套下来人工要处理的 issue 数量能压缩一半以上。6. 落地中的常见问题与排查实录6.1 模型把数字读错怎么办图纸上的标注数字经常和尺寸界线、剖面线、中心线交叉重叠OCR 出错率不低。比如把 φ68 读成 φ88把 0.02 读成 0.08——这种误差一旦流出后果很严重。我的解法有两层。第一层是置信度标记提示词里增加“对尺寸数字识别没有绝对把握时请在 description 中注明‘数字疑似误读需人工确认’并将 issue_type 设为 needs_review”。这样模型不用纠结遇到看不清的数字如实上报就行。第二层是规则碰撞测试把模型读出的关键尺寸与图纸边界框、装配关系做逻辑比对比如“如果某个孔径大于零件的整体外形尺寸必然是误读”这类规则能拦下大部分明显错误。6.2 模型对同一张图两次审查结论不一致这个问题在审图场景里非常致命。排查方向按顺序来先看 temperature 是否设了高温再看输入图像是否有压缩或随机裁剪最后看有没有开启 beam search 之类的随机采样策略。如果都正常问题多半出在模型自身的对齐稳定性上此时建议换更大的模型或者对同一张图跑三次、取多数结论。我给一个“多数投票”的参考实现思路from collections import Counter def ensemble_review(image_path, n3): # 同一张图运行三次每个 issue 以 (issue_type, location) 为键投票 all_issues [] for _ in range(n): result review_drawing(image_path) all_issues.append(result.get(issues, [])) counter Counter() detail_map {} for issues in all_issues: for issue in issues: key (issue[issue_type], issue[location]) counter[key] 1 detail_map[key] issue # 出现在至少 2 次以上的问题条目才进入最终报告 stable_issues [] for key, count in counter.items(): if count 2: stable_issues.append(detail_map[key]) return stable_issues这个方案会牺牲一些召回率个别只出现一次的问题可能漏掉但换来了稳定性的明显提升。对生产流程而言少报一个需要人工复核的问题远好于多报一个让人失去信任的错误结论。6.3 超大图纸怎么处理效率才高A0、A1 图幅在制造业非常常见直接整图推理速度和精度两头不讨好。工程上的处理流程我推荐三段式预分区根据 CAD 导出的图纸坐标信息按图框分区标题栏区、视图区、技术要求区等自动切割。分级审核视图区高优先级做完整审核标题栏区做表单字段校验这类用 OCR 更快技术要求区做文本语义审核检查是否出现“未注公差按…”等必备声明。合并汇总各区域结果合并后做一次交叉引用检查例如某个视图的基准符号在另一个视图被引用再输出最终报告。这样处理的时间分布大约是预分区和切割 10 秒各区域并行推理 1 到 2 分钟合并汇总 5 秒——比人工动辄 20 分钟的效率提升非常明显。6.4 多语言图纸怎么适配部分企业接外贸订单图纸是英文注释甚至夹杂客户自定义的缩写。VLM 处理英文标注没问题但问题在于客户缩写未必是标准术语模型很可能看不懂。建议在提示词里明确“图纸中出现的非标准缩写请保留原样并标记 needs_review不要猜测其含义”同时在项目元信息project_meta里把客户常用的缩写表放进去给模型做一层知识补充。实测这个做法能显著降低误报率。7. 实战中总结的经验与几个可以抄作业的细节跑这套 VLM 审图流程时间久了有些体会值得记下来。很多人以为“审图”是纯理性任务只要模型够准就万事大吉但真正难的是让流程嵌入现有协作体系中。图纸审核的下游是设计更改、是 BOM 更新、是加工车间的工艺反馈如果你的 VLM 审图结果只是一份好看的报告而不跟工单系统联动价值就只剩一半。我的建议是给每个 issue 生成一行可追踪的标记比如“图纸号_DWG-1042_问题序号_07”修改人只要在 CAD 里按这个标记搜到位置就能定位改完后回填状态。这样整个“系统发现问题 → 人工确认 → 设计师修改 → 系统复查”的链路才能盘活。另一个容易被忽视的细节是审图模型的评估集必须持续更新。图纸风格、标注习惯、标准版本在变模型在新图纸上的表现会逐渐衰减。我习惯每个季度从实际审核记录中挑 30 到 50 张典型图纸包含通过和未通过的样本重新跑一轮全量评估跟踪 precision/recall 的变化。要让这套系统始终保持高可用这件事不能省。最后说个小技巧给模型提示词时不要只给一张图试试把“相邻视图的局部截图”也一起喂进去。比如审左视图上的某个孔位标注时把主视图对应区域的裁剪图附上模型在判断“这个孔是否需要标注分布圆直径”时就有了上下文依据。这种“局部放大 关联视图”的输入方式比单一整图输入的效果要好尤其在装配关系复杂的图纸上提升非常明显。这套流程我已经在实际项目里跑了将近半年最大的感受是它不会取代审核工程师但它能把工程师从 70% 的重复性劳动里解放出来让精力集中到真正需要经验和判断力的复杂问题上。如果你也在考虑用 VLM 处理图纸审核可以从一张不太复杂的零件图跑起把提示词和输出结构先定好再逐步扩大图幅和业务边界。这条路不难但每一步都得踩实。