告警狂响某交付群「不在群停止播报」。打开手机一看——号还好好地在群里。重要通知停了一上午锅却甩给「客户把机器人踢了」。列表类能力的边界见 GeWe 开放文档。假阴性从哪来你用「通讯录/联系人列表里有没有这个群」当唯一判据。但现实里会漏分页只拉了第一页刚入群列表还没同步完用 A 设备的列表去找 B 设备的群列表覆盖范围本就不是「全部群关系」列表缺席 ≠ 退群。用缺席直接statusinvalid停发是典型误伤。怎么判定才算数给群关系做多源证据不要单票否决证据源 A. 入群/群变更回调写过的 xxxchatroom B. 群详情/成员查询还能查到 C. 实际发一条「在群探针」人眼可见 规则 - A/B 任一为真 → 保持 active 或降为 suspect继续观察 - C 失败 A/B 都假 → 才标 invalid 停发 - 仅列表没有 → 最多标 suspect禁止停发映射表怎么改字段用途to_wxid必须带chatroomstatusactive / suspect / invalidevidencecallback / probe / listchecked_at上次多源校准时间停发是重操作后台要点两下确认并写明证据链。值班怎么查手机确认还在群吗在 → 先解除停发业务库to_wxid是否还带着chatroom列表是否翻页翻完、是否用对了设备打探针看得到就修状态别跟客户解释「系统以为退群了」假退群的成本是业务停摆。宁可多一次探针不要一次误杀。