爱普筛RCS筛号目前是文件交换流程：企业上传TXT，完成任务后导出Excel；不是直接提供API接入。因此“接入企业系统”的正确答案，不是虚构一个实时接口，而是在CRM与操作人员之间建立可追踪、可重跑、不会重复写入的批次通道。
把流程拆成四个边界
源系统负责选择允许处理的联系人；导出器只生成号码TXT和批次清单；操作环节提交任务并取得Excel；导入器在暂存区验收后回写。四个边界由batch_id连接，任何一步失败都不直接修改CRM主记录。
先选择RCS有效筛选还是系统筛选
| 爱普筛任务 | 返回字段 | 适用问题 | 不应声称 |
|---|---|---|---|
| RCS有效筛选 | 手机号、是否开通 | 形成RCS渠道候选 | 具体设备功能全部可用 |
| RCS系统筛选 | 手机号、系统、ID | 在允许用途内整理系统结果 | 运营商、机型或永久能力 |
批次清单是文件流程的控制面
manifest至少包含batch_id、task_type、source_snapshot、created_at、row_count、unique_count、file_hash、owner和purpose。TXT本身只是一行一个号码，不应同时塞进姓名、订单或授权记录。清单让下载后的Excel能被确认属于正确任务和正确数据快照。
暂存区先验收，CRM后更新
Excel进入rcs_screening_staging，验证必需列、数据类型、重复行、未知值和批次数量。通过后生成差异预览：多少新增、多少变化、多少冲突、多少保持不动。操作人员批准的是差异集，而不是一个会覆盖整张联系人表的导入按钮。
幂等键防止重复回写
建议以batch_id、input_row_id、task_type和result_version组成唯一键。相同结果文件再次导入时只返回already_processed，不重复创建历史记录；修订版则以新result_version进入。这样网络中断或人工重复点击不会把同一结果写入多次。
Google的RCS能力检查与文件筛号不是一件事
Google的RCS for Business能力检查文档描述其代理、区域端点、E.164号码和能力/可达性语义；批量检查还受单一区域和缓存时效影响。企业不能把爱普筛Excel字段冒充为Google API响应，也不能用一个“开通”列替代消息代理的实际能力判断。
2026年的区域端点变化说明为什么要保留语义
Google发布说明显示，2026年批量能力检查要求使用对应区域端点，混合区域会报400。即使企业不直接调用该API，这也说明RCS结果依赖具体平台、区域、代理上线范围和检查方法。数据表应记录provider、task_type与checked_at，避免只有一个含义模糊的rcs=true。
错误队列要能重新导出TXT
将format_error、missing_result、duplicate_input、unexpected_field、row_count_mismatch和manual_review分开。只有可修复的号码异常重新生成exception TXT；其他错误回到文件或配置层。不要为了补一小部分失败记录重跑全量名单。
回写字段带来源和有效期
除结果值外，保存screening_provider、screening_task、checked_at、expires_at、batch_id和review_state。下游系统读取前先检查是否过期。RCS状态会随设备、配置、运营商和服务环境变化，不应成为永不更新的客户属性。
RCS渠道决策仍需许可与降级规则
可用候选不等于可发送。消息系统还要读取许可、消息类别、停止状态和业务目的。若决定在RCS不可用时降级SMS，必须避免双发，并依据发送/送达记录触发，而不是看到筛选空值就立即重复发送。
最小上线版本包含哪些组件
- 只读源快照与TXT导出器；
- 不可变batch manifest和文件哈希；
- 人工提交/下载的操作记录；
- Excel暂存表与验收规则；
- 差异预览、批准和幂等回写；
- 过期、撤回、审计和删除任务。
这套架构没有假装爱普筛提供RCS API，却仍能实现可靠的企业接入。关键不是实时，而是每个文件、字段、决定和回写都能从CRM追溯到具体批次。
