一块 PCBA 刚完成锡膏印刷，SPI 报出少锡 NG。对产线来说，拦住一块不良板并不难；难的是接下来该怎么做。
工程师要回看检测明细、翻前序板记录、核对钢网和刮刀状态、查锡膏履历、确认印刷参数与设备工况。数据分散在 MES、QMS、SPC、设备和追溯系统中，现场经验又掌握在不同角色手里。等资料逐一找齐，问题往往已经从一块板扩展到更多待排查的产品。
这就是传统制程质量处理的困境：人发现问题以后，再靠经验跨系统找答案。排查不仅响应滞后，先查什么、谁去确认、什么证据可以排除一个方向，也常常依赖老师傅临场组织。
产线制程诊断 Agent 要改变的，不是让系统替工程师宣布根因，而是让问题主动找到该找的人：从一张具体 NG 工单进入，把数据、规则和现场动作组织为同一条可运行的诊断路径。
从一张 NG 工单开始
典型工业平台可以从设备、报警、时序数据或质量记录中帮助团队观察异常。产线制程诊断 Agent 的起点更具体：一张 NG 工单。
条码、产品、工位、检测项、检测值和事件时间构成当前诊断的上下文。系统自动关联与这次异常有关的检测明细、过程能力数据、历史样本、工装状态、物料履历和追溯信息，把原本散落在不同页面的信息收拢到当前工单中。
这不是要替代 MES 的生产履历、QMS 的受控流程，或 SPC 与工业数据平台的专业分析能力。产线制程诊断 Agent 更像连接这些系统的诊断与协同层：以企业级 ontology 统一理解产品、工序、检测项、工装、物料批次、质量事件与专家经验之间的关系，再以故障树把候选排查方向、支持证据、待补信息和现场动作组织起来。
此时，系统不只呈现“发生了什么”，还要组织三个更关键的问题：该查什么？证据在哪？谁来确认？
这意味着，产线诊断并非在异常发生后再生成一份分析报告，而是在异常刚进入流程时，就把排查推进起来：有规则和数据支持的环节自动分析；需要现场观察、测量或试验的环节，明确指派给对应人员。每一步判断都要落到下一项可验证的证据上。
NG 工单 → 自动分流 → 证据分析 → 现场取证 → 工程确认 → 经验回写
从“人找问题”到“问题找人”，改变的是质量团队响应异常的方式：工程师不必先在系统之间无序搜索，而是带着已经收敛过的证据和待办，进入最需要专业判断的现场。
一张少锡工单，如何收敛方向
以 SPI 少锡这一具体场景为例，故障现象相同，并不意味着排查路径相同。
系统先判断影响范围与严重度：若 NG 点数达到大面积失效阈值，优先引导现场沿制程故障树排查；若属于局部失效，则进一步查看体积等关键检测值。对严重局部少锡，诊断 Agent 不会直接给出“钢网问题”或“锡膏问题”，而是并行检索多类证据。
第一类是过程能力与历史复现。当前少锡的体积、面积、高度等检测项，会与对应的 CPK、SPC 控制图和历史数据关联；系统也会检查当前报警位号是否在近期同产品、同设备的少锡板中重复出现。它们用于判断异常是孤立波动，还是存在需要优先关注的过程或位号信号。
第二类是工装与物料履历。系统按报警时刻回溯刮刀、钢网上机状态，观察少锡是否在某把刮刀或某张钢网上呈现集中；同时关联锡膏开封后放置时长、回温后等待时长、有效期等数据，查看是否存在值得继续验证的时序或物料线索。
第三类是未发现共性后的偶发分析。当过程能力、位号复现、工装和物料等维度未命中明确共性时，系统可基于历史测量数据进行 3σ 分布检查，为偶发波动提供补充证据。
Agent 自动完成的，是用过程能力、历史复现、工装和物料履历等证据缩小排查范围；需要看钢网孔是否堵塞、PCB 焊盘是否有异物、人员操作是否符合规范的环节，则明确交给现场。工程师不再面对一张只有“少锡”的工单从头搜索，而是沿着已经收敛的方向完成物理根因确认。
共性信号不是根因结论
自动分析的速度，不能以牺牲工程判断为代价。也正因此，Agent 的交付不应只是一组相关数据或一份统计图，而是一个可审查的排查假设：当前有哪些候选方向，各自得到了哪些数据支持，还缺什么反证或现场验证，下一步由谁完成。
某个刮刀、钢网、位号或锡膏使用时段上出现集中，只能说明这里存在跨板、跨时间或跨工装的共性信号，值得被优先验证；它不是对物理根因的自动宣判。CPK、3σ、位号复现等统计结果同样如此：它们帮助团队判断先查哪里，不能替代现场对堵孔、异物、设备状态或人员操作的确认。
因此，诊断路径中必须同时保留两类节点：自动节点负责取数、计算、关联和呈现证据；人工节点负责现场检查、测量与专业确认。数据缺失时，系统也应明确标识“分析不可用”，而不是把缺少证据误写成“正常”。
这种分工让诊断更快，也让结论保持可复核：自动化负责收敛，工程师负责确认。
让一个工厂的经验帮助更多工厂
一次少锡排查结束后，真正有价值的不只是处理完当前工单，而是把确认过的判断留下来。
当某一工厂发现并确认了可复用的共性问题，工艺与质量专家可以将对应的检查逻辑、证据要求、适用条件和预防措施沉淀进故障树。经过版本治理和现场验证后，这些经验可供相同或相近工艺的其他工厂学习：在类似异常再次出现时，系统能够更早给出排查方向，帮助团队减少同类问题重复发生。
这种共享并不是把一个工厂的结论直接推广，而是把“失效模式—候选原因—证据要求—验证动作—措施效果”的关系沉淀为可治理的知识。企业级 ontology 让这些关系能与不同工厂的产品、设备、物料和工艺数据重新关联；故障树则让专家可以审查哪些条件需要保持一致、哪些环节必须重新验证。
这里复制的不是一组固定参数，也不是把一棵故障树原样搬到另一条线。不同工厂仍需适配检测项、规格阈值、设备与物料数据、现场角色和工艺边界。真正可复制的是一套方法：从异常事件进入，以证据收敛方向，由现场完成确认，再把有效经验回写为下一次诊断的起点。
让质量响应跑在问题扩大之前
产线质量诊断不承诺每一次 NG 都能自动找到唯一根因。它解决的是更现实的问题：当异常发生时，团队能否不再从零开始、不再靠个人记忆在多套系统里无序搜索，而是快速形成一条可执行、可验证、可回溯的排查路径。
对于工艺相对稳定、失效模式已有标准和历史案例的场景，高频、重复、可标准化验证的问题尤其适合优先进入故障树；暂时无法解释的新问题，则保留给专家会诊，并在验证后成为下一轮知识治理的输入。
从一张 SPI 少锡工单开始，产线不必等到问题扩大后再组织人找答案。让数据先收敛方向，让任务先找到人，让每一次现场确认都留下可复用的依据——质量诊断才有机会从事后响应，走向更快的前置处置。
