WhatsApp筛号接入CRM最危险的动作，是把Excel结果直接覆盖联系人表。筛号结果通常是某一任务、某一时点的观察；CRM中的姓名、主手机号、许可和客户关系则有各自证据。正确接入要允许新增观察、发现冲突、撤销一次导入，而不是把两类数据压成同一行“最终真相”。
先画清三类数据的所有权
CRM拥有客户关系和许可；爱普筛任务处理号码并返回对应字段；暂存区负责连接两者。任何筛号字段都不应自动改写permission_status，也不应仅凭映射差异合并联系人。所有权清楚后，异常才有明确去处。
不同WS任务进入不同结果表
| 任务 | 核心返回字段 | 建议用途 |
|---|---|---|
| WS筛开通 | 手机号、是否开通 | 渠道候选观察 |
| WS高精筛开通 | 手机号、商业号、WhatsApp映射手机号 | 开通与映射复核 |
| WS筛活跃 | 手机号、活跃时间、活跃天数、映射手机号 | 已有关系中的时序辅助 |
| WS筛头像/性别年龄/全格式 | 各任务规定的画像与映射字段 | 受限、经批准的具体用途 |
不要设计一个万能screening表
万能宽表会让不存在于某项服务的字段看起来像“未命中”。按task_type建立版本化结果记录，公共字段只有input_phone、checked_at、batch_id和status；任务专属字段保留在对应结构中。这样能准确区分“本任务没有该字段”和“字段返回为空”。
TXT从不可变快照生成
先冻结source_snapshot，为每条记录分配input_row_id，再导出一行一个号码的TXT。姓名、公司、订单、标签和许可留在CRM。保存TXT哈希、唯一号码数和异常数；任务运行期间即使联系人被编辑，结果仍能回到当时的输入版本。
Excel先生成四类差异
- insert：该联系人和任务尚无观察；
- supersede：有旧观察，本次以新版本替代其使用资格但不删除历史；
- conflict：映射手机号、主键或来源关系不一致；
- no-op：相同批次或相同版本已经处理。
只有insert和经批准的supersede进入提交；conflict停在人工队列。
映射手机号采用关联表
不要把WhatsApp映射手机号直接写进contact.primary_phone。建立phone_relationship，保存input_phone、mapped_phone、observed_at、source_task和resolution_state。只有客户确认、近期订单或其他可靠证据解决关系后，才决定新增联系方式、替换旧号或维持分离。
许可是独立的否决字段
WhatsApp Business消息政策要求企业在用户提供号码并选择接收后续WhatsApp消息后联系，并尊重退出和停止请求。因此CRM查询必须先过permission_status和message_category；是否开通、近期活跃或有头像都不能把deny改成allow。
每次回写都能完整撤销
提交前保存change_set_id及旧值引用。撤销时不是删除联系人，而是将该批观察标为revoked、恢复前一有效版本并重建下游索引。若错误来自输入名单，还应阻止同一source_snapshot再次提交，直到问题修复。
字段生命周期各不相同
开通、活动、头像、商业号和画像字段可能以不同速度失效。为任务设置expires_at和refresh_policy；过期后从排序与细分中排除，但保留最小审计信息。不要用频繁重跑整库来维持“所有字段永远最新”的假象。
重复号码不能只做全局去重
同一号码可能出现在多个联系人、品牌或业务实体中。TXT层可以对号码去重以减少重复处理，但crosswalk必须保存一对多关系。回写时逐个检查许可和用途，不能因为一个联系人允许服务消息，就把结果扩展到所有关联记录。
上线前模拟三次故障
- 同一Excel被导入两次，第二次应全部no-op；
- 映射手机号指向另一个联系人，应进入conflict而不是合并；
- 批次选错任务或数据源，应能用change_set_id整体撤销。
企业看板关注可控风险
展示待处理冲突、过期观察、无许可记录、重复导入、异常回滚和各任务未知率。不要只展示“筛出多少可用号码”，因为一个高数量指标可能掩盖错误关联和未经允许的触达。
TXT和Excel完全可以组成稳定的WhatsApp筛号接入，只要CRM把它当作有来源、有版本、可过期、可撤销的观察层。最重要的不是自动覆盖得多快，而是任何一条变化都能解释并恢复。
