做EMC认证和硬件测试的朋友应该都体会过这种状态项目总结前打开文件夹30份测试报告在硬盘里堆了一个月每一份都要翻PDF找Fail项、抄限值、对比实测值再整理成汇总表。我以前处理这一批报告怎么也得小半天遇到扫描版报告还要一边骂一边放大看页码。这是WorkBuddy项目系列的第二篇上一篇搭好了运行环境这一篇直接上实战用 WorkBuddy 的 Skill 机制做了一个“EMC报告抽检”技能把30份电磁兼容测试报告从丢进对话框到拿到不合格项汇总清单稳定压在10分钟以内。如果你手里也有一堆实验室报告要整理或者正在琢磨怎么把 WorkBuddy 用到真实工作里这篇内容可以直接当作业抄。1. 先说实话这个任务为什么不自己翻非要交给 WorkBuddy先说清楚我这里说的“抽不合格项”是“抽取”不是“抽样检查”。30份 EMC 报告里的不合格项通常不会老老实实集中在一页它们可能藏在某一频点的测试表格里可能写在扫描附页的总结里也可能只在结论栏留下一个“NG”或“超出限值”。人工做这件事的真正时间黑洞不是读不懂报告而是反复打开、搜索、对照、抄录。而 WorkBuddy 的价值在于把“打开PDF—找结论—摘字段—成表”这四个动作合并成一次对话。1.1 真正的难点是表述不统一不是文件多如果30份报告都来自同一家实验室、同一个模板那用脚本加正则表达式也能处理。但现实是EMC 报告来自不同实验室字段名称完全不同同样的超标结论可以有下面几种写法测试结果表里判定列直接写“FAIL”文字总结段写“0.5MHz频点超出B级限值”备注栏写“辐射发射垂直极化123.5MHz超限5.2dB”结论页写“不符合CISPR 32标准要求”。传统脚本要用关键词去匹配“不合格”“FAIL”“NG”“超限”这些词一旦遇到“不符合要求”或者“超出参考限值”正则表达式就得再补一条规则补到后面逻辑越来越绕。WorkBuddy 这类基于大模型的工具强在语义理解它能把上面四种说法统一识别成同一个意思然后按我们指定的表格结构输出。这是用规则脚本很难做到的事情。1.2 WorkBuddy 在这里的角色是语义解析器不是数据库我也得泼一句冷水不要让 WorkBuddy 凭记忆去判断“这个产品型符不符合某个EMC标准”它只应该负责“从报告原文里抽取哪些测试项不合格”。原始数据必须来自 PDF 本身而不是模型的常识。比如限值是多少、频点是多少、实测值是多少这些都要以报告原文为准。WorkBuddy 的任务是定位这些字段、统一语义、整理成结构化表格最终判定权还是留在人手里。这次项目里我把 WorkBuddy 定位成一台“报告拆解机”30份PDF进去一张不合格项汇总表出来。它不帮我做整改决策也不替代实验室出证但能把原本需要人通读全文的时间省掉90%以上。2. 喂报告之前我先把30份PDF整理成模型能处理的样子很多人用 AI 工具处理文档第一步就把原始 PDF 直接拖进对话框结果输出来乱七八糟。问题不在模型在输入准备。这一批 EMC 报告我先做了三步预处理后面跑起来才顺。2.1 第一步先给报告统一命名后面才知道每条结果对应哪份文件我的习惯是建一个干净的工作目录把30份报告全部改成“报告编号_产品型号_日期.pdf”这样的命名格式目录结构大概是下面这样emc_reports/ 01_待处理/ RPT-2025-001_智能插座_20250412.pdf RPT-2025-002_智能插座_20250412.pdf ... 02_已完成/这一步不是形式主义。后面的不合格项汇总表里每一行都要能对应到具体文件。如果文件名是“扫描件1.pdf”“测试报告最终版(2).pdf”AI 即使抽出了结果你也很难回去翻原始报告验证。命名规则统一后WorkBuddy 在处理文件时能把文件名里的报告编号一起带进输出省掉人工对应环节。2.2 第二步扫描版 PDF 必须先在外部完成 OCR这一批30份报告里有11个页面是扫描件。直接用这类 PDF 做解析会出现两个问题一是文字层为空模型读不到内容二是即使模型能读图扫描件里数字错位、串行的情况也明显更多。我的处理办法是在把 PDF 交给 WorkBuddy 之前先用本机 OCR 工具把扫描页识别一遍重新生成带文本层的 PDF。我用过 PaddleOCR也用过 FineReader关键不是哪一款而是看最终文件能不能在阅读器里直接选中文字。如果 PDF 是电子签章直接生成的文本层完整就可以跳过这一步。检查文本层有个笨办法用 PDF 阅读器打开按 CtrlA如果能选中全部文字说明有文本层选中的是一片空白就老老实实先做 OCR。2.3 第三步给 WorkBuddy 配一张“判定口径对照表”不同实验室在报告里写“合格”的方式千奇百怪为了让模型不要看到“不符合”就以为是 Pass我提前整理了一张判定口径对照表放进 Skill 的参考知识库报告里的原文出现字样归一化判定PASS / P / 合格 / 符合 / OKPassFAIL / F / 不合格 / 不符合 / NGFailN/A / - / 不适用不判定接近限值 / 请确认 / 疑似超限待确认超出限值 / 超限 / 超过限值Fail按数值判断这张表的重要性在我后面跑批量时体现得非常明显。“不符合”和“不符合项”是两个意思很多模型容易搞混给出口径表之后它就知道该看的是“测试项目判定”而不是“结论页摘要”。这也是 WorkBuddy 里 Skill 比普通对话好用的原因参考知识库可以挂载固定词表不用每次重复解释。3. 把“抽不合格项”写成可复用的 Skill 指令准备完输入文件接下来是最核心的部分把任务要求翻译成一段模型能照做的指令。3.1 第一版指令翻车的过程第一次我偷懒只写了一句“请找出报告中的不合格项并汇总”。结果 WorkBuddy 输出了两页表格里面既有 Fail 项也有 Pass 项甚至还有一栏“不合格品处理流程适用性判断”。不是说模型弱而是我没给它划清边界。“报告中的不合格项”不等于“报告正文里出现‘不合格’这个词的所有内容”。有些扫描件里附了质量体系文件也提到了“不合格”三个字模型不知道应该忽略。所以第二版指令我把任务边界、输出列、判定规则、特殊情况处理全都写死了。3.2 最终指令模板可直接复制我在 WorkBuddy 里新建了一个 Skill命名为emc-report-reviewer系统指令用的是下面这段角色你是EMC测试报告审核员。 任务从用户上传的EMC测试报告中抽取所有判定为“不合格/不通过/FAIL/NG/不符合”的测试项。 要求 1. 只输出表格不输出分析过程和客套话。 2. 表格列报告编号、产品型号、测试项目、测试条件/频点、限值、实测值、判定、原始结论位置、备注。 3. 一个频点、一个端口、一个测试模式的不合格项单独成行。 4. 判定以报告原文为准。原文明确写FAIL、不合格、NG、不符合才输出为FailPASS、合格、符合、N/A均不输出。 5. 如果原文写“超限”“超标”“超过限值”并且有实测值和限值可对比按Fail输出并在备注中写明“根据数值判断”。 6. 如果缺少限值或实测值不要猜在备注里写“信息缺失”。 7. 每条Fail项必须给出原始结论位置格式为“P页码表格名/字段名原文片段”。 8. 处理多份报告时先逐份输出最后给一张汇总清单。这段指令的核心点在第4、5、6、7条。第4条锁死判定边界第5条处理“没有写Fail但数值明显超限”的坑第6条防止模型瞎编数据第7条保证每一条结果都有据可查。把这四条规定住输出质量会明显提升。3.3 没有 Skill 功能也能用如果你用的 WorkBuddy 版本暂时没有自定义 Skill也可以把这段指令直接粘贴在对话开头再把 PDF 拖进去。实测下来能用只是每次新建对话都要重新粘一遍而且上下文里没有固定的参考口径表遇到生僻表述时稳定性会差一些。还是建议用 Skill 方式挂载把指令和判定口径表一起固化下来后续每个项目都能复用。4. 30份报告分批跑参数、耗时和实测结果准备工作和指令都到位后就进入真正的批量运行环节。这一节我把自己的批次策略和实测数据列出来给后面想复现的同学一个参考。4.1 全量丢进去会截断5~6份一批最稳第一轮我贪快30份 PDF 一次性全部拖进 WorkBuddy。前几份输出还算正常到第12份左右表格开始变短后来甚至出现“继续”两个字就不动了。原因是单份报告少的6页、多的24页30份累在一起的文本量太大超出了当前模型一次能稳定处理的范围。后面我改成每批5到6份分6批跑。这个数量下模型有足够上下文处理每一份报告里的长表格又不会因为批次太小导致人工操作频繁。如果你手里的报告页数偏多建议从5份一批开始调页数少的可以放到8份一批但超过8份我这边出现过漏项不太建议。4.2 10分钟的构成先解释一下这10分钟怎么算的。OCR和改文件名属于一次性准备不算在10分钟里10分钟指的是从第一批 PDF 开始交给 WorkBuddy到最后一批跑完、得到完整不合格项汇总表为止。实测数据如下环节耗时说明第1批5份约95秒输出不合格项5条第2批5份约100秒输出不合格项4条第3批5份约110秒包含11页扫描件耗时略高第4批5份约90秒输出不合格项6条第5批5份约100秒输出不合格项4条第6批5份约85秒输出不合格项3条合计约9分40秒30份报告全部处理完成这个时间不是极限是连续跑了两轮都很稳定的水平。如果把批次调成8份一批总耗时还能压缩到7分钟左右但漏项风险上升我宁可用多两分钟换可靠性。4.3 实测抽检结果这一批30份报告总共316页WorkBuddy 第一轮抽出的“不合格项”原始记录是27条人工去过重、合并同频点重复项之后剩下有效不合格项23条再对照原文复核发现有2条漏项。也就是说自动抽检的覆盖率大约是92%剩余部分靠人工复核补上。27条里有几条是误报一份报告在测试数据表里写了“NG”但旁边又写“备注参考值不作判定”模型按规则输出了Fail实际应该排除。这种问题不是模型逻辑出错而是报告本身的信息层级比较乱。所以我才特别强调自动抽取的结果一定要做人工复核而且复核不是通篇重看而是带着表格定位回原文效率会高很多。5. 我怎么确认它抽出来的是对的校验链路WorkBuddy 给出结果后不能直接拿去写项目总结。我给自己定了一条硬规矩AI 负责“缩小范围”人负责“确认结论”。要让这条规矩成立抽检结果必须带足够的证据信息。5.1 每条不合格项必须带“证据定位”所谓证据定位就是我在指令第7条里要求的“原始结论位置”。最终输出的不合格项表大概是这样的报告编号产品型号测试项目测试条件/频点限值实测值判定原始结论位置备注RPT-2025-007Model-A辐射发射30MHz-1GHz垂直极化123.5MHzQP40 dBuV/m46.8 dBuV/mFailP10测试结果表判定列原文“FAIL”超限6.8dBRPT-2025-011Model-B传导发射0.15MHz-30MHzL线0.5MHzQP46 dBuV/m51.2 dBuV/mFailP8测试结果表判定列原文“NG”超限5.2dB有了“原始结论位置”这一列人工复核就不需要翻完整份报告直接翻到指定页码、找到指定字段看原文是不是这么写的。我一般会随机抽3份报告每份抽查2条 Fail 项如果这6个点全部对得上就默认这一批的抽检结果可信。5.2 四步人工复核法具体复核时我会按下面四步走数总数先把 WorkBuddy 汇总的 Fail 项目总数和报告封面或结论页的“不合格项数量”对照一遍数字对不上就先找原因。看数值方向Fail 项的实测值是否大于限值方向不能反。有些免疫类测试看“实测值低于判定线”才是 Pass方向反了就会误导整改。标出边界值实测值离限值在0.5dB以内的项即使报告原文写的是 Pass我也会单独标“接近限值”留给硬件工程师判断稳定性风险。回翻原文按“原始结论位置”抽查几个点确认模型引用的原文真实存在。这一套人工复核下来大约20到30分钟。虽然比“完全人工逐份读”快不了太多但它避免了漏项——重点不是“快”而是“知道该看哪里”。AI 的价值是你不需要再花两小时去定位问题在哪一页。6. 这次批量抽检踩到的三个坑以及对应的处理办法最后把这一轮踩过的坑集中说一下。这三个坑都不是 WorkBuddy 本身运行故障而是输入准备和指令边界导致的具有一定的代表性。6.1 扫描页不预处理报告编号直接读错第一轮里有3份报告是扫描件我没有提前 OCR 就丢给了 WorkBuddy。结果是最搞笑的部分第11份报告被读成了“RPT-2025-017”第23份报告被读成了“RPT-2025-028”。数字串行的问题在扫描件里非常严重尤其报告编号这种密集数字串。处理办法就是我前面说的批量任务开始前先检查 PDF 文本层扫描页统一先 OCR。判断标准很简单CtrlA 能选中文字就继续选不中就先去处理。6.2 不同实验室的“判定”叫法五花八门这一批30份报告来自6家实验室判定列的列名有“结论”“评价”“结果”“判定”值域写法包括“合格/不合格”“符合/不符合”“P/F”“OK/NG”“Pass/Fail”。刚开始我只在指令里写了“不合格/FAIL/NG”结果把“不符合”这一列漏掉了一部分。后面我把判定口径对照表补全并把“不符合”和“不符合项”这两个语义做区分漏项才降下来。这个坑的解法不是靠模型聪明而是要靠维护一份持续更新的口径表。每遇到一种新写法就追加一行对照关系放回 Skill 的参考知识库里。下次再见到同样写法模型就不会再犯。6.3 表格跨页导致漏项第三类坑是报告里的测试项目表格跨页。很多 EMC 报告的测试数据表是连续好几页的一个测试项在页尾断掉下一页接着显示后半截。WorkBuddy 在处理时如果按页切分就容易把后半截当成另一项或者干脆丢掉。这次补漏发现的2条无效项里有1条就是因为跨页丢的。处理办法有两层一是在指令里加了一条“遇到跨页表格行在备注中标‘跨页’”让模型保留线索二是人工复核时对带“跨页”标记的记录多翻一页确认。相比让模型自己去“脑补”跨页数据我更倾向于它如实标记出来由人来做最终拼接。最后给个我自己的实战建议像这种批量抽检任务不要指望 AI 第一次就给你完美结果。第一遍跑完先看漏了什么类型再回头改指令和口径表。WorkBuddy 这类技能真正的价值不是“一次答对”而是“把一次踩坑变成以后不用再踩”。我把这次的判定口径表和指令模板存成了标准技能下回换新实验室的报告只需要补新说法跑第二遍基本就干净了。