赞比亚WhatsApp全格式筛选：+260九位号码、57新号段与旧规则修复

赞比亚WhatsApp号码项目中，“长度正确却被系统判错”往往不是号码有问题，而是号码规则停留在旧版本。2024年12月，赞比亚信息与通信技术管理局通过ITU公布57移动资源的引入。这个变化非常适合检验企业的号码清洗器：它究竟读取当前规划，还是把一张多年未更新的前缀表当成真相。

+260后是九位国家有效号码

ZICTA发布在ITU第1309号业务公报中的规划说明，赞比亚国家有效号码最短和最长均为9位。规划同时区分固定、移动、保留和其他资源，因此“+260后有9位”只是第一道门槛，不代表它一定是适合移动平台检查的号码。

57号段揭示了旧规则的系统性偏差

公报记录57为移动服务的非地理号码资源，于2024年12月23日引入并分配给Airtel Zambia。若内部验证库在此之前冻结，新号码会集中落入invalid；这不是随机噪声，而是规则版本导致的系统性误杀。团队应先修正规则，再决定是否删除记录。

用拒绝原因定位清洗器故障

规则版本必须成为批次字段

每次清洗保存rule_source、rule_published_at、rule_version和processed_at。日后出现新范围时，可只重放受影响的号码，而不是重跑整个CRM。若一个历史批次没有规则版本，它的“无效号码”结论就不适合永久沿用。

全格式筛选放在格式分流之后

爱普筛WS全格式可包含手机号、活跃时间、活跃天数、性别、年龄、头像、肤色、头像类型、商业号和WhatsApp映射手机号。先把+260移动候选、固定号码、短码、异常值和其他国家号码分开，再提交适当队列；否则返回中的空值会混合格式错误、未返回和暂时不可见等不同含义。

Excel采用状态列，不采用真假二分

建议在结果旁保留normalization_state、range_state、screening_state、mapping_state与review_reason。一个号码可以“格式符合当前移动范围、但某项字段未知”；也可以“格式待确认、因此未进入检查”。这样的多状态记录比一个总的valid=true更能支持复核。

映射手机号不应静默覆盖CRM

当WhatsApp映射手机号与输入不同，建立mapping_conflict队列，保留两者和检查日期。格式转换、号码变化或其他账号关系都可能造成差异。只有在另有客户确认或可靠业务证据时，才更新主联系方式。

画像列不得替代业务事实

年龄、性别、肤色、头像类型等字段需要未知状态、保留期限和用途限制。它们不能用于推断收入、族群、健康或政治立场，也不应取代用户明确填写的语言、地区和需求。高影响决策更不能依赖此类推断。

TXT批次如何为将来更新留出空间

TXT一行一个号码，保留country_hint和contact_id在内部crosswalk中。批次命名带上来源和日期，例如crm_legacy_2026q3。若下次ITU或ZICTA新增资源，可以定位旧批次中的对应前缀重新评估，而不用重新上传姓名、订单或其他上下文。

上线前做一次“新号段挑战”

测试集应包含57新资源、已知移动范围、固定号码、保留范围、少位、多位和其他国家码。目标不是让所有样本通过，而是让每一类进入正确队列，并且错误原因可解释。这个挑战比只拿几个老号码测试成功更能证明规则可维护。

赞比亚案例的核心教训很具体：号码规划会更新，旧验证器会把合法的新资源误作坏数据。把来源日期、用途范围和例外队列纳入流程，才能让全格式筛选建立在可追溯的号码集合上。