微博客户分群名单更新，应先固定同一规则，再按稳定客户标识比较前后两轮的保留、新增与不再命中对象。CodeBuddy可用AI查询授权客户并整理差异；人数相同不代表名单没变，查询尚未完整时，也不能将暂未看到的客户判断为退出。
运营定期为一类客户准备说明，上一轮留下四位，这轮也查到四位，就直接沿用旧表。实际上，原来两位已不符合本轮条件，新出现的两位却没有被接上。只看总数，既看不到变化，也不知道要重新核谁。
维护先写清具体渠道、准确标签或时间条件、查询截点与用途。前轮材料必须有来源和条件；只有几个人名的截图，不足以确认它与本轮属于同一口径。涉及客户意愿或业务资格时，另外核实，候选条件不能替代实际服务判断。
如果规则已经调整，先说明这是新旧规则的结果比较，不把差异全部解释为客户自身发生改变。授权范围变了也同样需要单列，避免把看不到误认为不再存在。
知你AI助手支持按授权渠道、明确标签和时间等条件查询客户。先解析真实渠道与准确标签；业务说的重点客户不是天然存在的标签，若必须根据聊天判断，就读取相关原话后由人员确认条件。
CodeBuddy支持通用远程HTTP MCP。按双方当前认证配置后，可以提出：“这是前轮获准保留的候选及条件。按相同定义查询本轮客户，记录截点与分页覆盖，再按稳定UID分出两轮都有、仅本轮、仅前轮。条件或授权不一致时停止做退出结论，不发送、不改资料。”
前轮名单由团队从既有受控记录提供，本流程不假设服务端保存了任意日期的客户快照。查询有明确筛选，不空条件拉全量；分页未完成、读取失败或实际覆盖变化，先列资料缺口。
下图为MCP连接后台布局示意。名单差异在AI客户端比较，不是后台自动增减或历史快照页面。
以下客户、集合和结果全部虚拟。假定前轮与本轮均按同一个微博渠道、同一已核标签规则完整查询，授权覆盖相同，每轮已按UID去重。前轮为示例客户甲、乙、丙、丁，本轮为甲、丙、戊、己。
| 比较结果 | 虚拟对象 | 本轮维护动作 |
|---|---|---|
| 两轮都有 | 甲、丙，共两位 | 保留候选，继续核实际安排 |
| 仅本轮有 | 戊、己，共两位 | 新命中，核是否需要本次服务 |
| 仅前轮有 | 乙、丁，共两位 | 从本轮候选移出，变化原因另核 |
数量可以复查：前轮四减去不再命中的二，加上本轮新增的二，仍为四。这里的新增是新进入本次条件集合，不表示这两位刚成为客户；不再命中也不等于取关、流失、删除资料或拒绝所有联系。
完整交接可写：“本轮候选四位，甲、丙保留，戊、己为本条件新命中，乙、丁不在本轮完整结果。请核本次服务安排后维护工作名单，标签变化原因不从集合差异推断。”内部保留获准定位标识，对外协作只分享必要内容。
反过来，假定本轮只读到第一页，暂见甲、丙、戊，就只能报告已读范围看到这些对象。丁可能在未读页，己也可能尚未出现；此时不能报新增一位、退出两位，更不能据此删除旧工作记录。
下图为AI客户端辅助比较流程，数据全部虚拟，不展示真实账号或个人资料。
知你AI助手负责授权查询，CodeBuddy辅助对照。运营先核新命中对象的需要，再更新本轮工作名单；不再命中的保留差异原因与必要历史，不擅自删客户、改标签或取消仍在进行的售后。
下轮沿用同一字段定义并记录新截点，避免几份没有日期的表相互覆盖。比较结果先用于准确维护，再评估是否减少漏接，不能把新命中人数宣传成新增销售成果。
需要，同样人数可能换了具体客户，按稳定标识核对对象。
不是，它只表示本次新命中条件，添加时间需另按对应字段查。
不能，先核查询完整性、条件和实际业务变化，不从差集推断流失。
不可以，未完整读取时保留资料缺口，不作退出结论。
本文只查询与比较，本轮维护和实际触达分别确认。
名单更新先看规则是否一致、读取是否完整，再比较具体对象。用AI整理同一客群的保留、新命中与不再命中，让运营清楚本轮到底变了谁。从一组明确条件开始，减少复制旧表带来的遗漏。
希望让AI协助按实际条件查询客户并维护每轮候选，可以了解知你AI助手官网，先用一个已定义客群核对前后差异，再决定本轮实际服务安排。
也可以扫码交流你的客服数据整理需求：
全渠道智能客服系统，聚合微信、小红书、抖音等平台咨询，支持自动回复与多客服协同。
知你AI助手官网 >AI 驱动的智能接待助手，基于知识库生成可确认的推荐回复，提升响应效率。
知你快回官网 >浏览器插件，为小红书、抖音、网页客服场景提供快捷话术库与 AI 自动回复。
