1. 30份EMC报告摆在面前我先算了笔人工账这事得从月初的例行工作说起。手里压着30份EMC检测报告来自三个不同实验室覆盖辐射发射、传导发射、静电放电、浪涌、电压暂降等项目每份三四十页起步加起来上千页。按老办法我得逐份核对测试条件、判定标准、测量值、结论页一份报告摸一遍至少15分钟30份就是七八个小时脑子还容易在第三份之后进入“看啥都像合格”的麻木状态。做硬件的朋友都懂EMC报告里最容易藏问题的不是明晃晃的“Fail”而是那些卡在限值边缘的“Pass”以及测试条件与产品实际使用场景不匹配的“隐性不合格”。举个典型例子辐射发射项限值是准峰值40dBμV/m报告中某频点实测39.5dBμV/m结论写“合格”但细看天线极化、扫频范围、产品工作模式可能压根没覆盖到最恶劣工况。这种问题靠肉眼扫页漏检率相当可观。当时我正好在搭WorkBuddy的Agent工作台就想验证一件事——把“读报告找不合格项”这件高度套路化的事情交给AI Agent流水线处理到底能不能顶住真实业务场景的压力。于是有了这个项目用WorkBuddy批量处理30份EMC报告目标是把“逐份人工审核”压缩到10分钟内的自动抽取与标注。先说结论最终跑通后的实测数据是30份报告从投喂到输出汇总表用时不到9分钟识别出12个需要人工重点复核的疑似项其中7个经我复核确认是真实问题点包括两个实验室结论页与正文数据不一致的低级错误。这个结果已经足够说明问题——EMC报告的初级审核完全可以交给Agent人工只需要做终审判断。这篇把整个项目的设计思路、踩坑过程、任务编排逻辑和判定规则的移植方法拆开讲给同样在处理批量检测报告、认证文档的朋友一个可复用的参考。2. 为什么这事用脚本很别扭用Agent才顺手2.1 传统脚本在非标文档面前有多无力先说说为什么我不直接写个Python脚本搞定。EMC报告看起来是标准文档实际杂乱程度超出预期。不同实验室的排版习惯差异极大有的用表格有的混排文本有的把测试数据嵌在曲线图下方的图注里还有的干脆是扫描件加OCR图层。三份不同来源的报告摆在一起字段名都未必一致——同一项辐射发射有的写“RE”有的写“Radiated Emission”有的写“电磁辐射骚扰”。脚本处理这种非标文档通常要做大量正则表达式和模板匹配每适配一种新格式就要写一堆规则。更麻烦的是报告的“语义信息”远比“格式信息”重要。比如“Pass”这个判定词出现在限值表里和出现在结论页里含义完全不同一个数值到底是对应水平极化还是垂直极化需要结合上下文理解。这些对规则脚本来说非常脆弱一旦遇到表达方式变化规则就失效了。2.2 Agent模式的核心优势不是“看懂”而是“能干完”WorkBuddy这类Agent工作台解决这个问题的思路完全不同。它不强求用固定模板解析每一份文档而是依靠模型的语义理解能力配合任务编排和工具调用把“理解文档—提取数据—执行判定—汇总输出”拆成一条流水线。每个环节的产出物都是结构化的交给下一个环节继续处理。当时选择WorkBuddy而不是直接调模型API主要考虑三点任务编排能力多步骤任务可以分成独立单元执行每步有明确的输入输出便于调试和复用。上下文窗口管理30份报告全部塞进一个上下文显然不现实Agent可以分批加载、逐份处理、最后汇总结论天然适配批量场景。技能与指令封装审核规则、判定逻辑、输出格式这些可以沉淀成固定指令下次遇到新报告直接套用不用每次重新描述需求。提示Agent不是万能钥匙。它擅长的是“按规则办事但规则表达方式多变”的场景如果报告格式完全统一、字段高度标准化传统脚本反而更快更省。选型前先评估文档的“混乱程度”。3. 拆解EMC报告审核判定逻辑到底分几步3.1 人工审核时的四个检查维度要把人工审核动作转成Agent指令首先得把自己脑子里的经验写出来。我对EMC报告进行抽检时的动作可以拆成四个维度覆盖性检查报告里的测试项目是否覆盖了产品对应标准要求的所有必测项。常见坑是产品按GB/T 9254.1适用辐射发射和传导发射但报告里只测了辐射发射传导发射标注为“Not Applicable”理由还不充分。限值核查各频段的限值线是否正确测试距离3米还是10米与限值是否匹配QP、AV、PK三种检波器的限值是否搞混。数据一致性正文测试数据、数据汇总表、结论页三者之间的判定结果是否互相矛盾。实验室回传的报告经常出现正文测量值显示超标但结论页写“合格”的情况。余量分析即使全部“Pass”也要关注测量值与限值之间的余量。余量小于3dB的在认证评审时属于高风险项因为实验室间的复测差异就可能在3dB左右浮动。3.2 把判定规则翻译成Agent能执行的“话”这四类规则用自然语言描述起来简单但要Agent稳定执行必须往细了写。比如余量不足3dB这个规则我最终的提示词是这样表达对每一测试频点计算测量值与对应限值的差值限值-测量值。当差值小于3dB时标记状态为“PASS_LOW_MARGIN”并在评估意见中说明该频点余量不足建议复核或增加设计裕量。差值为负时状态标记为“FAIL”并标注超限频点与超限幅度。这种描述方式好在哪它同时给出了触发条件、输出标签、后续动作Agent拿到后不需要自行揣测“到底算合格还是不合格”。写提示词的时候最忌讳的就是“请判断是否合格”这种模糊指令——模型会按照自己的理解随意发挥结果就是每份报告的标记口径都不一样后面根本没法统一复核。经验之谈判定规则写完后先拿两份已知结论的报告做回归测试一份历史上被判不合格一份是临界余量合格。如果这两份的输出和预期一致再往30份全量数据上跑。4. WorkBuddy跑批实战任务编排、提示词与执行过程4.1 任务链设计一次报告审核拆成五个阶段WorkBuddy里跑批量任务不是简单把30份报告丢进去说一句“帮我查不合格项”就完事。我给这次项目设计的执行链分成五个阶段预扫描读取每份报告的目录、首页、结论页建立文件的“身份信息”——报告编号、送检产品、标准依据、测试项目清单。正文解析针对每个测试项目抽取测试条件距离、限值、模式、测试数据表格、曲线图中的关键数值、判定结果。逐项判定按第二章里的四个维度逐项执行判定规则输出每份报告的标记列表。交叉比对将正文数据、数据汇总表、结论页三个位置的判定结果进行一致性核对标记冲突项。汇总输出生成一份“30份报告审核汇总表”包含报告编号、发现问题类型、风险等级、需要人工复核的详细说明。执行链的每一步都有明确的“输入—处理—输出”好处是中间任何一步出现异常能快速定位是解析问题还是判定规则问题。这比一个长提示词从头跑到尾要可控得多。4.2 提示词里的几个关键设计阶段任务确定后提示词的设计是这次项目效果好坏的核心变量。我前后迭代了四轮几个比较关键的设计点角色与目标前置每个Agent单元开头明确写清楚“你是EMC报告审核助手你的任务是从检测报告中抽取XX信息并执行XX判定”而不是含糊地说“帮我看报告”。判定规则显式枚举不合格、临界合格、数据冲突、覆盖缺失这四类情况的判定条件全都显式列出来不依赖模型“常识”。输出格式强约束每个阶段的输出都定义好JSON结构或表格字段样例先行。比如逐项判定阶段每个测试项输出格式固定为项目名称|测试条件|测量值|限值|余量|状态|备注。异常情况处理指令明确告诉Agent“如果遇到无法提取的数据标记为EXTRACT_ERROR并说明原因禁止猜测填充”。尤其最后一条刚开始跑的时候漏写了结果Agent在解析某份扫描件时对几处OCR模糊的数字自行“脑补”出了合理但错误的值差点造成误判。补上“无法提取就明说”这条约束后问题才解决。4.3 30份报告的跑批实录整个跑批过程是这样第一阶段网络上有部分报告是扫描件WorkBuddy走OCR解析链路30份报告全部预处理完成大约用了3分钟正文解析和判定阶段是耗时大头大约5分钟最后的汇总和交叉比对不到1分钟。全程不到9分钟出结果。输出汇总表里最扎眼的是12个标记项。逐个过了一遍4个是“PAES_LOW_MARGIN”余量不足3dB集中出现在某款电源产品的辐射发射项目上频点在120MHz附近余量只有2dB左右。这批是真实风险点产品内部设计余量不足后续批量生产温漂后很容易超限。3个是“数据冲突”类报告中正文测量数据与结论页判定结果不一致明显是实验室出报告时的疏漏。以前人工核对这些位置要一页一页翻很容易放过去。3个是“覆盖性存疑”报告未包含某标准条款中的必测项需要人工确认是否适用豁免。剩余几个是低频段的“FAIL”项但仔细核实后发现是实验室在测试时使用了错误的限值线把Class A限值当Class B用了产品本身实际是达标的。这类属于报告本身的准确性瑕疵同样需要退回实验室修改。说实话12个标记项里真正算“产品不合格”的其实不多但作为抽检流程目标本来就不是替代人工判断而是把“哪些报告、哪些位置需要花时间看”这个问题从依赖经验变成依赖数据。这一点达成得很彻底。5. 复盘踩过的坑输出一致性、单位与限值、批量稳定性5.1 最大的坑格式漂移导致汇总表没法看第一轮跑批发现一个典型问题相同含义的内容不同批次的输出里结构对不上。比如限值一栏有的输出是“40dBμV/mQP3m”有的是“40”还有的是“准峰值 40”。汇总表一合并同一列里三种格式并存后续过滤和排序全乱套。解决方法是把输出格式约束里的“字段细化”做到极致。不只是规定字段名还给出每个字段的取值样例和枚举范围。比如“限值”字段明确要求输出数值部分和单位部分分开单位统一格式为“dBμV/m”“dBμA”“V/m”“kV”等标准写法判定状态字段只允许输出“PASS”“FAIL”“PASS_LOW_MARGIN”“EXTRACT_ERROR”“NEED_REVIEW”五种值。没有第六种。5.2 单位换算看似简单错起来要命EMC报告里的量纲五花八门辐射发射用dBμV/m传导发射用dBμV静电放电用kV和A浪涌用V和kV电压暂降用周期百分比。最坑的是同一份报告里正文用了dBμV/m图表纵轴却标了dBV/m差了120dB如果Agent直接抓数值来做限值比较结果必然离谱。这个坑我在提示词里做了双重保险第一解析阶段每个数值字段必须带上“原始表达原文”和“规整后的标准单位数值”第二判定阶段明确要求“仅使用标准单位数值进行限值比较禁止混用不同单位的数据参与计算”。跑批结束后抽查了5份报告的手工对照数值抓取整体准确率没问题零星几处误差集中在扫描件图表区人工复查能兜住。5.3 批量跑批的稳定性不是跑完就完了30份报告一次性跑完Agent的表现不是均匀的。前10份输出质量最好到后面偶尔出现“标签漏标”“判定理由空白”的情况。虽然比例不高但批量场景下这种偶发错误会被放大。我的对策是坚决不过度信任单次输出。汇总表生成后增加了一个“全量复核”环节让Agent重新扫描每一份报告的被标记项核对标签是否与实际报告内容对应。虽然跑批时间会增加一两分钟但换来的是批量结果的可信度值得。后续如果再加大规模可以按20份一批拆分每批独立跑完再合表。注意批量跑出来的结论使用前务必做抽检复核。我的经验是第一批全量人工复核第二批抽检50%跑顺之后可以压到20%但“抽检”这个动作本身不能省。它不是为了防AI出错而是为了防批量场景下的“系统化偏差”——一旦出错往往是一错一整批。6. 从一次跑批到一套流程复用才是这事的价值6.1 沉淀成报告审核Skill这次项目结束我把跑批链路封装成WorkBuddy的Skill指令集包含四个指令报告预处理、数据抽取与判定、交叉核验、汇总输出。以后来新的EMC报告不用再重新设计任务链直接调用指令集跑就行。这么做的意义在于Agent跑批这件事从“一次性做一个项目”变成了“沉淀一个可复用的能力”。下次来的是50份报告、100份报告只是数量的变化跑批流程本身不再需要重复设计。判定规则也能随着经验的积累持续迭代——比如后续发现“余量阈值从3dB改到2.5dB更合理”只需修改指令集里对应的阈值参数所有历史报告都能用新口径重新跑一遍。6.2 同样的思路还能迁移到其他文档审校做完EMC报告我仔细想了下这套方法论的适用范围。本质上它是在处理一类“半结构化专业文档的批量抽检”安规认证报告结构类似限值项占比高审核逻辑同样可以拆成覆盖性、数据一致性、余量分析。环境可靠性试验报告温循、振动、盐雾试验报告里的试验条件、判据、数据记录也可以套用同样的抽取与判定框架。供应商质量文件来料检测报告、材质证明、出厂检验单字段更多但套路更固定。研发自测报告内部测试报告的规范度和格式一致性反而比第三方实验室更乱Agent抽取的价值更大。6.3 对质量工程师岗位的启示顺带说一句题外话。身边不少同行担心AI批量审核报告会挤掉工作岗位我的实际感受恰恰相反——它把质量人从“看报告看到眼瞎”的初级劳动里解放出来变成了“定义审核规则、复核AI标记项、处理异常项”的更高价值工作。真正的审核经验比如某个频段的超标暗示着电源的哪一级设计出了问题这类知识反而是越加稀缺的。工具替代的是耐力和眼力替代不了判断力。10分钟处理30份报告本身不是多炫酷的指标但对我来说它验证了一件事AI Agent处理专业文档批量的场景已经跨过了“能用”的线走到了“可用”的阶段。最后分享一个实际使用中的小习惯跑批用的判定规则每次调整完都会留一个版本备注标明改了什么、为什么改。跑到第三个月回头看这些备注就是最宝贵的经验沉淀——比报告结论本身值钱得多。