技能提升网第三方控制台显示事件已投递，订单系统却有几笔没有更新。开发把当天全部事件重新发送，部分客户随后收到两封通知。缺失事件和处理失败没有分开，补发范围扩大了重复执行的风险。
AI可以协助三方记录匹配和回放计划，真正执行需负责人批准。文中使用假设事件，不提供对生产支付或订单直接批量重放的指令。
事件源、投递与业务结果分别建表
源事件表保留事件标识、类型、业务对象、发生时间、版本及允许查询范围。投递表保留每次尝试、接收端、时间、响应与重试。业务表保存入站记录、处理状态和具体副作用结果，不能把接收成功列直接当作订单更新成功。
事件标识相同的多次尝试属于重投，不是多个独立事件；同一订单也可能有多个合法事件，不能只按订单号去重。时区和延迟窗口统一，超过某段时间仍未完成的项目才进入追查范围。第三方源查询有保留期或权限限制时写清覆盖缺口。
XLSX Skill可将开发提供的事件、接收和完成明细整理成对照工作簿，用事件标识匹配并检查重复、缺失与数量勾稽。它不直接连接Webhook平台，原日志由开发导出并脱敏，候选关系保留原记录号供人工复核，不让AI看到真实支付身份或凭据。
先查为什么收到却没有完成
检查签名验证、解析、入站持久化、队列提交和业务事务。接收端返回成功后如果尚未可靠保存事件，进程故障可能留下空白。可靠保存与快速响应的设计需开发确认，不能为了让控制台全部变绿而无条件返回成功。
以Stripe为例，官方Webhook文档说明签名验证需要保留原始请求体，并要求处理重复及不保证的事件顺序。其他平台的签名、重试和回放规则不同，按实际官方资料核对。API请求的幂等键不能自动证明Webhook处理也具备幂等性。
假设源中有一百个独立事件，本地确认收到九十七个，其中九十五个业务完成、两个失败。候选待处理为三个未收到加两个失败，共五个，而不是把全部一百个再执行。还要确认这五个是否已通过别的渠道完成相关业务副作用。
幂等保护落实到业务操作
入站事件去重使用适用的事件标识，业务操作再按业务对象和操作语义建立唯一约束或等效保护。不同事件可能都指向同一笔入账，只有事件级去重仍可能重复入账。去重状态与业务结果应采用可靠的事务或恢复设计，不能先写已处理再让业务失败后永久跳过。
乱序事件到达时核对对象版本或当前状态。旧事件不应覆盖新状态，但某些历史动作仍需要处理，按业务语义决定。AI可列状态冲突，不自行认定最新一条就是全部真相。退款、支付与通知也不是同一种可重放操作。
签名和回放来源需保持安全验证。过期的历史签名能否用于回放取决于平台机制，不为方便全局关闭校验。内部补偿任务由受控服务处理，保留来源证据与权限，不能把伪造请求当正常Webhook塞进公网端点。
回放先做清单和小批试验
候选清单写事件、当前业务状态、待执行动作、潜在副作用及排除理由。授权人员审核后先用测试或极小批验证，再设置限速与暂停条件。失败记录不是一律重试，数据格式错误可能需要修复，未知状态应人工追查。
incident-response可辅助安排恢复任务与操作记录，不能自动触发退款、发货或重复通知。回放过程中同时观察错误、重复、下游压力及业务完成，不只看接收端返回成功数量。
若发现副作用重复，停止相应批次并按业务审批处理，不自动逆向冲销。每次回放保存批次、操作者和原事件索引，断点续跑从已验证状态恢复，避免进程失败后整批再跑。
补发完成后再做一次全量对账
核对源覆盖范围内的事件是否都有解释，业务结果是否唯一。已接收未完成和已完成但状态未更新分别修复，源记录已超保留期的缺口注明，不报告百分之百完整。补发成功还需要业务侧确认。
交付缺失原因、候选范围、回放记录和最终对账。预警增加持久化后待处理年龄、失败积压及业务差异，平台投递成功率只作为其中一项。以后再出现遗漏，可以精确处理哪几条，而不用靠重放全部事件碰运气。
