WorkMan AI 审图界面示意(方案设计稿)
本页依据 WorkMan 现有文档与视觉处理能力、公开的设计文件格式和制造企业审图流程整理,属于方案案例,记录设计思路与落地路径。文中的周期、效率提升均为方案口径,不是交付后的实测数据;具体支持格式与审查深度,以现场 POC 用真实图纸验证的结果为准。
项目概况
| 应用场景 | 机械结构件、装配图、电气原理图与 PCB 设计文件的初审 |
|---|---|
| 方案形态 | WorkMan 本地部署 + 审图技能包 + 企业规则库 |
| 接入格式 | SolidWorks(零件 / 装配体 / 工程图)、DWG / DXF、PDF 矢量图、EDA 设计文件与 DRC / ERC 报告 |
| 审查内容 | 规范一致性、BOM 一致性、版本与变更、标准引用、标注完整性、跨专业接口 |
| 输出物 | 审图意见单:定位到图幅 / 视图 / 尺寸 / 位号,带分级、依据条款与修改建议 |
| 部署方式 | 本地 / 私有化,图纸不出内网;可对接 PDM / PLM 与 ERP |
| 当前阶段 | 方案验证,待首个研发团队试点 |
| 方案日期 | 2026 年 10 月 |
| 实施方 | 深圳市奇点大数据科技有限公司 |
一、审图到底卡在哪
把设计主管、审图老师和一线工程师的抱怨放在一起,会发现重复率很高:
- 经验在脑子里。「这个件要加退刀槽」「这个公差标法车间做不出来」——老师傅知道,但没写成可执行的条目。
- 同样的问题反复出现。漏标粗糙度、漏写热处理、明细栏数量和 BOM 不一致,每次都要重新抓一遍。
- 跨专业靠开会。结构说电气没留走线空间,电气说结构没给开孔位置,最后在评审会上对图纸。
- 版本满天飞。微信里传一版、邮件里传一版、PDM 里还有一版,加工拿错版本是常见事故。
- 审图记录留不下来。意见在聊天记录和口头里,下次换个人审,同样的问题再来一遍。
| 对比项 | 人工审图 | AI 初审 |
|---|---|---|
| 覆盖方式 | 抽查,忙的时候只看关键尺寸 | 每张图全量跑一遍规则 |
| 重复性问题 | 靠记性和责任心 | 规则库固定拦截,不疲劳 |
| 单张耗时 | 30 分钟到数小时 | 分钟级出初审意见 |
| 依据与留痕 | 口头、聊天记录 | 每条意见带条款、定位、修改建议 |
| 判断责任 | 工程师签字 | 仍然由工程师签字 |
最后一行是前提:AI 只做初审,不做签审。把责任边界说清楚,这套东西才有可能被研发团队接受。
二、AI 审图不是「让大模型看图猜」
如果直接把图纸截图丢给多模态模型问「有没有问题」,得到的往往是看起来很像、但没法验证的一段话。工程审图不能这么干。方案把工作拆成三层,各干各擅长的事:
| 解析层 | 把设计文件拆成结构化数据:标题栏字段、明细栏 / BOM、尺寸与公差、粗糙度与形位公差、图层与图框、文本技术要求、器件位号与网络名。这一层不靠模型,靠格式解析与 CAD / EDA 接口。 |
|---|---|
| 规则层 | 把企业审图 checklist 写成可执行规则:必填项、取值范围、交叉引用、数量一致性、版本比对、标准有效性。规则命中就是命中,可复现、可解释。 |
| 模型层 | 只处理规则表达不了的部分:技术要求里的前后矛盾、设计意图描述不清、相似件复用建议、DRC 报告归因。输出必须引用原文片段,不允许自由发挥。 |
一句话概括分工:能算的不要猜,能查的不要生成,必须猜的要说清楚是建议。
| 该做 | 不该做 |
|---|---|
| 把图纸里的字段读准、对齐、比对 | 用模型「估算」尺寸或材料 |
| 把企业标准变成可执行规则 | 让模型凭常识判断合不合规 |
| 给每条意见标定位和依据 | 输出没有出处的结论 |
| 把误判回流成规则或样本 | 假装识别率是 100% |
三、一张图纸进来,经过哪五步
| 步骤 | 做什么 | 产物 |
|---|---|---|
| 1 接入 | 从 PDM 目录、邮件附件或上传入口拿到文件,识别格式与版本 | 待审文件、格式与版本记录 |
| 2 解析 | 读取标题栏、明细栏、视图、标注、图层、文本;EDA 另读网表与报告 | 结构化图纸对象 |
| 3 规则匹配 | 跑企业规则库:必填、范围、交叉引用、数量、版本、标准有效性 | 规则命中清单 |
| 4 模型复核 | 对技术要求、矛盾描述、跨专业接口做语义检查,并给出原文引用 | 语义问题清单 |
| 5 出单 | 合并、去重、分级,生成可定位的审图意见单,回写 PDM 或邮件 | 意见单与统计 |
这五步里,最容易被低估的是第 2 步。图纸解析的质量决定后面所有结论的上限;解析不出来,模型再强也只能猜。
四、四类审查,按「能不能被证明」排序
方案把审查项按可信度分成四类。越靠前,越适合自动拦截;越靠后,越应该标注为「建议,需人工确认」。
| 类型 | 检查项举例 | 判定方式 | 可信度 |
|---|---|---|---|
| A 一致性 | 明细栏数量与 BOM 是否一致;图号 / 版本与 PDM 最新版是否一致;材料与表面处理是否冲突;同一零件在不同视图的标注是否一致 | 字段比对、交叉引用 | 高,可直接拦截 |
| B 规范性 | 标题栏必填项;未注公差与未注粗糙度;基准与形位公差写法;图层、线宽、字体;标准件引用格式 | 规则枚举、模板比对 | 高,按企业标准执行 |
| C 完整性 | 视图数量是否够;剖视 / 局部放大是否缺;技术要求条目是否齐全;检验与包装要求是否缺失 | 清单比对、同类件基线 | 中,需按件型配置 |
| D 语义 | 技术要求前后矛盾;设计意图描述不清;相似件可复用;DRC 报告问题归因 | 模型阅读 + 原文引用 | 中低,只作建议 |
把 D 类当 A 类用,是这类项目最常见的失败原因:意见很多、准确率不稳、工程师很快就关掉通知。方案的做法是默认只自动拦截 A、B,C 类提示,D 类只做参考,由企业在试点中逐条放开。
五、三种设计软件,接法不一样
| 格式 | 能读到什么 | 典型审查 | 限制 |
|---|---|---|---|
| SolidWorks | 模型树、配置、自定义属性、工程图视图与标注、明细栏、材料 | 属性与标题栏一致性、BOM 与明细栏、配置与版本、工程图标注完整性 | 需正版 API / Document Manager;版本要匹配;不做几何仿真 |
| DWG / DXF | 图层、块、文字、标注、图框、外部参照 | 图层规范、标题栏字段、尺寸与公差、文字与标准引用 | 外部参照缺失、自制字体、加密文件会降级 |
| PDF 图纸 | 矢量文字、线条、图框;扫描件只能 OCR | 作为兜底格式做字段与文本审查 | 扫描件精度明显下降,需人工复核 |
| EDA | 原理图网表、PCB 网络、位号与封装、BOM、层叠说明、DRC / ERC 报告 | 网表与 PCB 一致性、位号封装匹配、BOM 与替代料、层叠与阻抗标注缺失、DRC 归因 | 不做信号完整性、EMC、热仿真 |
工程前提:SolidWorks、AutoCAD、EDA 工具都需要相应的正版授权与接口权限;不同版本的文件可能需要对应版本或转换服务打开。方案不绕过任何软件的授权机制。
六、审图意见长什么样
意见单不是一段总结,而是一张能直接派活的表。下面是一张支架图纸的示例(数据为演示用):
| # | 级别 | 问题 | 定位 | 依据 | 建议 |
|---|---|---|---|---|---|
| 1 | 致命 | 明细栏 12 件,BOM 导出 11 件 | 明细栏第 3 行 / BOM 第 18 行 | 规则 BOM-02 数量一致性 | 核对是否漏装垫片,或明细栏多计 |
| 2 | 严重 | 标题栏材料 Q235-A,技术要求写「重要受力件采用 Q355B」 | 标题栏 / 技术要求第 2 条 | 规则 MAT-01 材料冲突 | 确认设计意图,统一材料与牌号 |
| 3 | 严重 | 图号 QD-2026-0317 Rev.B,PDM 最新为 Rev.C | 标题栏版本栏 | 规则 VER-01 版本一致性 | 确认是否基于旧版修改,避免覆盖变更 |
| 4 | 严重 | 标注 32H7,但未注配合件图号 | 视图 A / 尺寸 32 | 规则 DIM-07 配合标注完整性 | 补充配合件图号与配合性质 |
| 5 | 一般 | 视图 B、C 共 3 处粗糙度符号缺失 | 视图 B / C | 规则 SURF-03 未注粗糙度 | 补符号或在技术要求统一说明 |
| 6 | 一般 | 引用标准未注年号 | 技术要求第 4 条 | 规则 STD-02 标准引用格式 | 补现行版本年号,确认未被替代 |
| 7 | 建议 | 与库内相似件 QD-2025-1187 重复度较高 | 整图 | 模型相似件检索 | 评估是否复用,减少新料号 |
这份意见单的价值不在「7 条」这个数字,而在每一行都能被追溯:工程师可以不同意,但知道该去哪里核对。
七、人机怎么分工
| 角色 | 负责什么 | 不负责什么 |
|---|---|---|
| AI | 全量跑规则、生成初审意见、标定位与依据、统计重复问题 | 签字、让步接收、设计变更决策 |
| 设计工程师 | 确认问题、修改图纸、回复意见 | 把 AI 意见直接当结论 |
| 审图 / 工艺 | 判断可制造性、装配性、检验方案 | 被规则库替代 |
| 系统管理员 | 维护规则库、标准库、误判回流 | 修改模型底层 |
衡量这套系统好不好,不该看「替代了几个人」,而该看三个数:初审覆盖率、重复问题拦截率、意见采纳率。第三个尤其重要——采纳率长期低于 50%,说明规则写错了,不是工程师不配合。
八、部署与接入:图纸不出内网
研发图纸是企业的核心资产,部署方式比功能清单更重要:
- 本地部署:WorkMan 装在企业内网,文件解析、规则匹配、意见生成都在本地完成。
- 只读接入:以只读方式挂载 PDM 发布目录或项目目录,不改变现有审批流。
- 权限继承:谁能看哪张图,沿用 PDM 的项目权限,不另建一套。
- 可关闭云端:如果启用云端模型,只发送脱敏后的文本片段;安全要求高的团队可以完全禁用。
- 全量留痕:谁审的、什么时候审的、哪条意见被驳回,都记录下来,方便回溯。
| 阶段 | 范围 | 周期(方案口径) | 验证目标 |
|---|---|---|---|
| 阶段 1 | 单专业规则包(机加件 / 装配图) | 2–4 周 | 解析准确率、意见采纳率 |
| 阶段 2 | 跨专业(机械 + 电气 / EDA) | 6–10 周 | 跨专业接口问题拦截率 |
| 阶段 3 | 接 PDM / PLM 与变更流程 | 3–6 个月 | 版本事故下降、审图周期 |
顺序同样不能倒。先把一个专业的规则跑准,再谈跨专业;先证明工程师愿意用,再谈流程改造。
九、这个方案的边界
- 不做强度、干涉、热与流体仿真。那需要 CAD / CAE 内核,不是语言模型能替代的。
- 不做工艺可行性的最终判断。能不能铣、要不要开模、装不装得进去,仍需工艺工程师拍板。
- 不做电子设计的功能仿真。信号完整性、EMC、电源完整性不在范围内。
- 识别率受图纸质量影响。扫描件、手写批注、非标准图层、外部参照缺失,都会让结果变差。
- 模型会「很有道理地错」。所以每条意见必须带依据;没有依据的意见,不允许进意见单。
- 不替代签审责任。AI 出的是初审意见,签字负责的仍然是人。
十、适合什么样的研发团队
- 研发或工程团队 20 人以上,每月出图量大,审图是瓶颈;
- 已经有企业标准、审图 checklist 或设计规范,只是没被系统化;
- 在用 PDM / PLM,图号、版本、BOM 有基本秩序;
- 愿意指定一个人维护规则库,把「老师傅的经验」一条条写下来。
反过来说,如果一年只出几十张图、图纸格式很随意、也没有任何成文标准,那这套方案的收益有限——先把模板和 checklist 建起来,比上 AI 更划算。