上个月接手了一批历史遗留的EMC报告整整30份横跨三个实验室的格式覆盖电源、工控屏和车载配件好几类产品。按以前的习惯这种批量“抽不合格项”的活儿至少得占用一个工程师大半天时间而且越翻到后面越容易漏。这次我决定不跟自己的眼睛较劲直接把WorkBuddy的批量处理能力拉出来从报告目录扔进去到拿到不合格项清单10分钟出头全部跑完。这篇是WorkBuddy项目连载的第2篇重点记一下这个“EMC报告自动抽检”工作流的完整思路和踩坑记录给同样被报告淹没的测试工程师、认证工程师和硬件研发做个参考。1. 先拆问题批量抽EMC报告不合格项难在哪1.1 EMC报告的信息结构EMC报告本质上是一份“证据链”很强的检测文件但它的排版结构在不同实验室之间差异很大。常规情况下一份完整的EMC测试报告会包含这样几层信息封面页的报告编号、样品名称和型号紧接着是测试环境、仪器清单和测试依据标准中间最核心的部分是逐项测试记录最后才是附件里的频谱图、波形图、布置照片和整改记录。对抽取不合格项来说真正有价值的信息集中在“逐项测试记录”这一块。每个测试项都会包含测试项目名称、测试端口或频段、标准限值、实测值、结论判定有的报告还会附上“余量”或“备注”。比如辐射发射RE会列出30MHz-1GHz频段的QP限值和AV限值传导发射CE会按L/N线分别给数据ESD会记录不同接触放电和空气放电电压下的现象描述。这些内容表现形式五花八门有的实验室喜欢用表格有的喜欢用段落有的甚至把限值和实测值塞在同一行里用斜杠分隔。我在动手之前先把30份报告按“是否有文本层”“表格是否规整”做过一轮分类。这个步骤非常重要因为后面所有自动化流程的稳定性都建立在对报告结构的准确理解上。如果一开始就把所有报告当成同一种格式处理后面必然会在解析阶段连环踩坑。1.2 人工抽检的3个真实痛点第一个痛点是重复劳动。30份报告每份平均20多页去掉模板化的声明页、波形图附件真正需要仔细看的测试记录页其实只有5到8页但偏偏这5到8页又是信息密度最高的部分。人工翻报告时大脑需要在“限值多少、实测多少、结论是否合理”之间来回切换判断标准还要根据产品类别和测试标准动态调整非常消耗注意力。第二个痛点是判定规则不统一。不同实验室在结论栏里的写法五花八门有写“Pass”和“Fail”的有写“合格”和“不合格”的还有只给数据不给结论的。更麻烦的是边缘超标的情况有些报告测试项标注“Pass”但实测值与限值之间只剩不到1dB余量这在实际工程判断里是需要提示风险的“准不合格项”。人工快速浏览时很容易被“Pass”两个字带过去直接漏掉。第三个痛点是漏检风险。人在连续浏览重复结构的文档时注意力会随着时间快速衰减。实测下来连续翻到第15份报告以后漏检率会明显上升尤其是那些藏在大量波形图后面的异常结论。这个问题靠“细心”很难解决因为它本质上是认知疲劳最好的办法就是让机器先把明显异常筛出来人只做复核而不是从零开始找。1.3 WorkBuddy处理这类任务的边界在哪WorkBuddy这类AI工作台工具优势在于它能把“读文档、抽字段、做判断、出结果”这一连串动作串成一个可复用流程不用每次重新写代码。使用者可以自定义指令和Skill把专业知识沉淀成一套规则下次遇到同类报告直接套用。30份EMC报告批量抽取不合格项正好是它的舒适区任务明确、输出结构固定、单份处理复杂度不高但总量大。不过也得说清楚它的边界。WorkBuddy不是一个能完全替代人工判断的合规系统它更擅长做“初筛”和“汇总”而不是替工程师承担最终责任。如果报告里有模糊表述、扫描错位、或者产品规格书里的特殊豁免条款这些事仍然需要人去做最终裁决。我在设计流程时就把“自动抽取”和“人工复核”做了明确切分这也是整个方案能落地而不是停留在演示层面的关键。自动化负责“快”人负责“准”。2. 核心设计把“抽不合格项”拆成可执行的流水线2.1 报告解析层的搭建思路拿到一批报告第一步不是急着让模型读而是要先把“报告怎么变成可读文本”这一层想清楚。我的做法是分三级优先级处理第一级是直接读取PDF原生文本层这个最简单也最准确大多数电子签章生成的报告都有完整文本层第二级是针对扫描版PDF调用OCR识别把图片转成文字第三级是对那些表格结构严重错乱的页面做单独清洗用正则把碎片字段拼回原样。这一层的核心原则是“先保底再优化”。WorkBuddy的文档解析能力能处理大部分常规PDF但我在实践中发现它对“分栏排版”和“表头跨页”的报告特别容易出问题。比如有些实验室的报告表格会跨页显示表头在第一页底部数据行在第二页顶部如果不对跨页做预处理表格结构会被硬生生拆成两段后续字段抽取就会出现串行。解决办法是在解析层增加一步“表格合并”规则对相邻页面内结构相似的连续表格做拼接。还有一点值得提醒OCR识别出的文本天然带噪声最典型的是数字“0”和字母“O”混淆、小数点丢失、单位“dBμV”被拆成“dB uV”。这些噪声单看一处不致命但累计起来会让最终判定出现系统性偏差。我在这一步额外加了一个单位归一化规则把所有测试数据统一换算到标准单位后再进判断效果立竿见影。2.2 字段抽取与判定规则设计报告解析成文本后接下来就是定义“抽什么字段”和“怎么判不合格”。我把目标字段分为三个小组第一组是报告身份信息包括报告编号、样品名称、产品型号、测试标准第二组是单条测试记录信息包括测试项目、端口/通道、频段、限值、实测值、结论、备注第三组是附加风险信息包括余量是否小于3dB、是否有“边缘超标”描述、是否有“整改后复测”等关键词。判定规则是整个流程里最需要费心的地方。很多报告自带明确结论这个直接读取就好难的是那些只给数据不给结论的条目以及结论与实际数据互相矛盾的条目。我的处理逻辑是“数据和结论双通道判断”先读取报告自带的结论字段再根据限值和实测值的关系做二次验算两者一致才判定为可信不一致就标记为“结论存疑”。这个设计帮我抓住了不少专员的录入错误比如报告结论写“Pass”但实测值明明超出限值6dB这种低级但致命的错误。判定时还要注意不同测试项目的特殊规则。ESD和浪涌这类抗扰度测试结论有时不是简单的数值比较而是看“现象描述”比如是否出现复位、死机、永久性损坏这些需要用关键词匹配辅助判断。而辐射发射、传导发射这类骚扰测试又分准峰值、平均值、峰值多个限值线必须把限值和实测值按“频率点限值类型”一一对应错误对应会导致大量误判。我在Skill配置里专门给这些测试项目写了独立的判定分支而不是只靠一个通用Prompt硬撑。2.3 自定义Skill的提示词与参数设计WorkBuddy之所以能沉淀成可复用项目靠的是自定义Skill。我这次的Skill名字就叫“EMC报告不合格项抽检员”它的核心是一个严格强调输出结构的Prompt。这类任务最怕模型自由发挥所以我在Prompt里规定了两点第一所有输出必须是JSON格式字段固定不允许自行增删第二判定不明确的必须标注“NEEDS_REVIEW”而不是强行给出Pass或Fail。我贴一下这个Skill里Prompt的核心结构供参考你是EMC报告审核助理。请根据用户提供的报告文本完成以下任务 1. 抽取报告身份信息report_id, product_name, product_model, test_standard 2. 抽取每条测试记录test_item, test_port, frequency, limit, measured_value, unit, conclusion 3. 按规则判定 - 若报告自带conclusion为Fail标记为FAIL - 若measured_value超过limit标记为FAIL - 若measured_value与limit的余量小于3dB标记为MARGINAL - 其他情况标记为PASS 4. 输出JSON数组每条失败记录必须包含reason字段 5. 无法判断的内容字段值填null禁止编造这里有个细节值得展开说余量和判定阈值为什么定在3dB而不是1dB或5dB。从EMC工程经验来看1dB的余量在实验室复测时很容易因为环境噪声、布局微调而翻车属于“看起来合格但风险极高”5dB又过于保守会筛出大量实际可放行的条目增加复核成本。3dB是一个相对平衡的经验值既能筛出大部分需要重点关注的项目又不至于让复核工作量爆炸。参数方面我除了指定模型温度设为偏低的随机度还在输出格式里要求模型返回“定位关键词”比如具体哪一页哪一行出现了异常数据。这个设计是为了让后续人工复核不用在几十页PDF里大海捞针直接靠关键词跳转到对应位置。实测下来这个定位信息对提升复核效率帮助极大。3. 实操实录从单份试验到30份批量跑完3.1 第一批样本小样本验证跑通再放大拿到30份报告后我没有直接全部塞进流程。先挑了三份最有代表性的报告做小样本验证一份是排版规整的电子版PDF一份是扫描后带歪斜的版本还有一份是表格跨页断裂很严重的老报告。选这三份的目的是覆盖解析难度梯度验证流程的鲁棒性。小样本跑完后我会拿抽取结果跟人工核对过的事实做比对重点看五项指标报告编号是否准确、测试项目数量是否齐全、限值实测值是否对应正确、判定结果是否合理、JSON结构是否完整。第一次跑下来发现的问题主要在表格错位上扫描版的辐射发射数据被错误归到了传导发射条目下。发现问题后我调整了解析层的规则增加了一个“条目上下文校验”如果一个页面里同时出现多个测试项目表格优先根据表头关键词来确定当前段落归属而不是按照阅读顺序机械分段。这一改后面的准确率立刻上来了。小样本验证的验收标准我卡在95%以上的字段一致率。这不是随口定的数因为后续所有批量的结论都要建立在字段抽取的准确性上如果小样本连95%都达不到批量输出反而会产生大量需要返工的脏数据得不偿失。第一轮验证通过后我才把全部30份报告纳入批量执行队列。3.2 批量执行配置、跑批与进度观测批量执行阶段流程本身已经跑通剩下的主要工作是把30份报告按顺序喂进去再做好过程监控。我在WorkBuddy里建立了一个批处理任务把PDF放在指定输入目录Skill只负责处理新出现的文件每完成一份就在输出目录生成一个对应的JSON结果文件和一个简短的状态摘要。这里有个很实在的经验批量任务不要一次性把30份全部丢进去建议分成3批每批10份。原因有两个。第一中间停下来检查输出能及时发现问题避免错误模式贯穿全部30份第二WorkBuddy跑长任务时如果中间遇到异常文件单批内排查比全量排查省事得多。我实际执行时第一批10份大概用了3分多钟第二批顺畅跑完约3分钟第三批因为有一份报告是纯扫描且清晰度太差OCR阶段多花了一点时间最终全部30份稳定在10分钟出头完成和预期基本一致。进度观测方面我习惯每跑完一份就瞄一眼状态摘要里面包含了“是否成功解析、抽到几条失败记录、有没有定位异常”。这个过程不是可有可无的仪式感而是为了在污染数据扩散前及时煞车。整个跑批过程中我只介入过两次一次是扫描版识别率低一次是某份报告的标准号缺失整体体验下来已经比人工过一遍轻松太多。3.3 结果输出不合格项明细与汇总统计批量跑完只是第一步真正让结果“能用”的是输出表格的设计。我让Skill在完成单份报告判定后额外生成两份汇总文件一份是“不合格项明细表”列出所有FAIL和MARGINAL条目按报告编号分组另一份是“统计汇总表”按测试项类型、不合格原因、风险等级做多维统计。直接看一个输出模板的示意报告编号测试项目端口/通道频率限值实测值判定备注EMC-2024-017辐射发射REAC电源端口74.58MHz40dBμV/m46.2dBμV/mFAIL超出限值6.2dBEMC-2024-021传导发射CEL线0.562MHz46dBμV44.8dBμVMARGINAL余量1.2dB建议关注统计汇总表则是在明细表基础上再聚合一轮按“FAIL数量前五的测试项目”“MARGINAL数量”“出现频次最高的不合格原因”三块展开。这份统计的价值在于它能在10分钟内给到管理者一个全局视角这批产品如果整体送测最薄弱的环节是辐射发射还是ESD是电源端口还是信号端口整改优先级一下就清楚了。有一点必须强调输出模板里的字段不是随便定义的它直接影响下游使用。如果这份表最终要进ERP或报告管理系统字段名最好提前对齐系统要求如果只是给人看也要让结论列足够醒目。我在设计时特意把FAIL、MARGINAL这类关键词放在判定列最前面方便筛选和排序。3.4 复核闭环机器初筛人工终判自动抽检跑得再快最终签字确认的责任人还是工程师本人。所以这套工作流的最后一步是让工程师基于“不合格项明细表”做定向复核而不是从头翻完整份报告。复核的对象集中在两类条目上一类是判定为FAIL和MARGINAL的项另一类是标记为NEEDS_REVIEW的存疑项。复核时靠之前提到的“定位关键词”直接跳转到报告原始页面快速核对数据是否一致、判定是否合理。我再补充一个小习惯所有MARGINAL项我会要求工程师写一句备注说明“放行”还是“列为高风险”。这句备注会成为后续产品放行评审的依据同时也能反过来校验Skill的判定阈值是否需要调整。比如如果连续10份报告里MARGINAL项实际全部放行说明3dB的阈值可能定得偏保守了可以收窄到2dB。整个复核闭环跑下来我的实际体验是10分钟左右的自动抽检加上半小时左右的人工复核就能把30份报告处理到一个“可以放心拿去做决策”的状态。对比以前大半天起步的纯人工模式效率提升了一个量级而且漏检风险显著降低。4. 常见问题与排查技巧实录4.1 表格错位和字段串行最常见的翻车现场是不同测试项目的表格被合并或串行。比如一份报告里“辐射发射”和“传导发射”两个表格紧挨着模型识别时把“L线”的限值套到了“垂直极化”的实测值上。这个问题的排查思路很简单先定位输出结果中哪一条记录的规律特别反常再回到原始页面看表格结构。解决这个问题的关键是解析层要保留“块级上下文”。我的做法是在进入Prompt前先把每个表头关键词如“Radiated Emission”“Conducted Emission”“ESD”与表格数据块做绑定再把“频段/端口”这类维度字段拆出来形成“块内自治”的数据片段。这样即使模型读乱了顺序也很难跨块污染。4.2 判定标准里的歧义报告里有时会出现“Class A”“Class B”这样的等级字样如果不加约束模型很容易把它当成“合格等级A”来做判断导致误判。尤其是Class A限值比Class B宽松同样是30dBμV的实测值在Class A标准下合格在Class B标准下可能就不合格一旦识别错等级结论整个翻转。处理办法是在Skill的参数配置里强制要求抽取“标准等级”作为单独的字段并让判定逻辑先读标准等级再读数限值。我还会在小样本验证阶段加入几个“故意混淆”的样本来测试模型是否踩坑比如在同一份报告里同时出现Class A和Class B两个等级的情况。这种预防式测试比事后修数据省心得多。4.3 模型幻觉和编造数据AI读取文档最大的风险不是读不准而是“读不准之后还强行补全”。比如某份扫描报告里限值字段模糊不清模型没有标null反而根据前几份报告的风格“脑补”了一个合理数值。这在批量任务里非常危险因为如果没有人去核对编造的数据会直接进入系统甚至影响最终结论。应对的方式是双管齐下。第一Prompt里明确要求“无法判断的字段填null禁止编造”这条约束在大部分主流模型上都有效第二在输出处理层增加一个校验脚本检查必填字段是否存在缺值如果发现null就自动把该条记录标记为NEEDS_REVIEW确保它绝不会静默进入统计结果。我在实际跑批中30份报告大概触发过4次NEEDS_REVIEW均在人工复核时快速解决。4.4 问题排查速查表现象可能原因排查方法解决办法多条记录串行表格跨页或表头丢失核对原始页面表格结构增加跨页表格合并规则限值/实测值对不上标准等级识别错误检查Class A/B字段强制抽取等级并校验字段被编造填充模型幻觉检查null字段分布强制null策略NEEDS_REVIEW标记OCR数字错乱扫描件清晰度不足对比原始图片数据提升分辨率后重试结论与数据矛盾报告本身录入错误交叉核对限值实测值数据与结论双通道判断这张速查表是我在跑批过程中一点点攒出来的基本都是“现场踩坑、当场处理、事后记录”的产物。每次遇到新问题我都会先定位到具体解析环节再决定是调Prompt、加规则还是改输出校验尽量避免头痛医头。这套“30份EMC报告10分钟抽不合格项”的流程跑通之后我最大的感受是自动化能帮人从重复劳动里解脱出来但它真正值钱的地方不是“省了3小时”而是让工程师可以把省下来的精力放到“为什么会超标”和“怎么整改有效”这两个更有价值的问题上。目前这个Skill已经沉淀下来后续再收到新的EMC报告我只需要扔进输入目录几分钟后就能拿到一份清晰的不合格项清单。下一步我打算再扩展一个“整改建议生成”的环节让输出结果不只停留在“哪里有问题”还能直接给出“怎么改”的参考方向。