目前的核心问题是HandlePipelineFailureAsync已经拿到了结构化的FailureKind、RecoveryAction、CanRetry、RequiresReset但在 [StationControlViewModel.Workflow.cs]又只把message传给旧重载最终仅通过错误文字中是否包含“易损件寿命到期”决定是否弹窗。这会造成丢失失败类型和恢复策略。通过字符串判断业务后续文字变化就失效。下层已经弹窗的故障可能再次弹出通用“自动流程失败”。可重试的瞬时通讯失败也会频繁打断操作员。NotifyTestFailure会再次写错误日志与前面的失败日志重复。建议按以下规则分类。场景FailureKind / RecoveryAction是否弹窗建议行为操作员停止OperatorStopped否记录日志继续吹扫、下料最终下料完成后提示停止结果。流水线取消、模式切换、软件关闭Cancelled否日志和状态栏提示不弹窗。可重试的瞬时通讯或 PLC 超时Communication/PlcTimeout且CanRetrytrue否记录每次失败重试耗尽后才按最终结果弹窗。EAP Host 拒绝器件业务拒绝通常否执行退料、写协议日志和状态提示除非退料失败。测试 FAIL、测试 ERRORContinueToPurgeAndUnload不立即弹先吹扫、下料在Completed回调中提示“测试完成但结果异常”。易损件寿命到期ManualInterventionRequired或专用类型否下层寿命逻辑已弹专用窗并触发红灯流水线入口不得重复弹。实时 PLC 告警已弹窗已有实时告警来源否只记录流水线关联日志避免实时报警与流程失败双弹窗。安全光幕、机械互锁、安全条件不满足SafetyInterlock是立即提示工站、阶段、未满足条件通常需要人工现场确认。不可恢复 PLC 超时或通讯中断PlcTimeout/Communication且不可重试是提示检查 PLC、电源、网络按RequiresReset显示需复位信息。搬运、上料、下料失败且器件位置不确定Unexpected/ManualInterventionRequired是必须提示避免操作员误以为可以继续生产。程序未预期异常Unexpected是提示异常原因、阶段、是否需要复位。要求复位RequiresResettrue或RecoveryAction.RequireReset是无论错误类别都应提示“当前工站需复位后恢复”。推荐把“是否弹窗”显式建模而不是放在errorMessage.Contains(...)enumPipelineFailureNotificationPolicy{Silent,// 仅日志StatusOnly,// 日志和状态栏AfterSafeUnload,// 完成吹扫、下料后提示ImmediatePopup,// 立即弹窗AlreadyNotified// 下层已有专用弹窗禁止重复}建议决策优先级Cancelled、OperatorStoppedSilent。已被专用模块处理的故障例如易损件、实时 PLC 告警AlreadyNotified。CanRetrytrueStatusOnly仅当最终重试失败后变为ImmediatePopup。ContinueToPurgeAndUnloadAfterSafeUnload避免产品未下料就连续弹窗。SafetyInterlock、不可恢复通讯故障、Unexpected、RequiresResettrueImmediatePopup。其余业务规则错误根据是否阻断现场操作选择StatusOnly或ImmediatePopup。实现上应让结构化重载直接处理AutomaticPipelineStageResult不要再退化为HandlePipelineFailureAsync(context.Product,message,...)否则FailureKind等信息再次丢失。旧字符串重载只保留给尚未迁移的旧调用方。另外建议为弹窗加去重键StationNo RequestId Stage FailureKind同一产品、同一阶段、同一故障只允许弹一次。这样 PLC 轮询反复报同一故障、失败回调和完成回调同时到达时不会卡住界面或产生重复弹窗。