菜鸟、兔喜、多多怎样统一查取件码：驿站 RPA 的任务编排与字段规约

先重新定义“混查”：它不是把三个网页并排摆放

人工查件时，工作人员往往凭经验判断先开哪个后台；顾客给出手机号后四位，就在菜鸟、兔喜、多多之间来回切换。这个过程之所以慢，不只是窗口多，而是每个窗口都有自己的登录状态、查询规则、字段命名和结果状态。把三个后台同时打开，只是让切换变少，并没有解决判断和核验问题。

更准确地说，混查是一条任务链：接收查询条件、确定已接入平台、检查授权会话、执行必要的页面操作、把结果翻译为统一字段、判断能否展示，最后才是回复顾客。任何一个环节不确定，系统都应该保留人工出口。这样设计的目标不是把全部问题自动化，而是把重复且确定的步骤自动化。

• 查询只在网点拥有权限的系统账号和必要业务范围内执行。
• 验证码、滑块、异常登录等平台安全步骤由工作人员依规则完成。
• 系统不能根据模糊线索猜测取件码，也不能用旧缓存冒充实时结果。

第一层：把顾客输入变成可判断的查询请求

实际输入并不整齐。有人发送完整手机号，有人只发尾号，有人复制运单号，还有人只说“查快递”。浏览器 RPA 不应把所有文字原样提交给每个平台，而应先识别输入类型、格式有效性和匹配强度。完整手机号与已绑定关系的确定性，通常高于手机号后四位；完整运单号又比单号片段更容易完成唯一定位。

这层还承担信息最小化职责。用于执行查询的线索只在当前任务中使用，日志保存脱敏标识、任务时间和结果状态即可。对明显无效的输入，系统应该先给出清楚提示，而不是创建三套无意义的浏览器任务。

• 完整手机号：可进入已验证平台的常规查询流程。
• 手机号后四位：默认视为可能重合，结果必须经过二次判定。
• 运单号或片段：按平台实际支持范围测试，不假定所有后台规则相同。
• 自然语言问题：先识别是否缺少查询线索，再引导补充必要信息。

第二层：每个平台都需要独立适配器，而不是巨型脚本

菜鸟、兔喜和多多的页面组织方式不同，后续还可能发生界面或登录流程变化。若把所有选择器、点击顺序和字段判断写进一段长脚本，一个平台的变化很容易影响其他平台。更适合长期维护的方式，是把每个平台封装为一个独立适配器：它只负责自己平台的会话检查、页面查询、结果读取和字段转换。

适配器不直接生成顾客话术，也不决定是否发送敏感结果。它的输出应是标准化的业务记录和明确状态，例如“会话需人工恢复”“无结果”“出现多个匹配”或“待取件记录已找到”。将技术执行和服务决策拆开，才能在平台变化时局部修复，在服务规则改变时不必改动每一个浏览器流程。

• `healthCheck`：确认授权会话和必要页面是否就绪。
• `search`：在可见页面中执行正常、必要的查询操作。
• `normalize`：把平台字段映射为统一的状态、来源和脱敏线索。
• `classifyFailure`：决定有限重试、暂停平台还是转交工作人员。

第三层：浏览器任务要按平台排队，而不是盲目并发

“批量混查”容易被误解成一次发起尽可能多的页面请求。对驿站而言，批量更合理的含义是：将短时间内的合法查询任务去重、排队并按平台限流处理。不同平台会话、电脑性能和网络质量都有边界，过度并发既不利于稳定，也会使重复任务和异常恢复更难追踪。

一个稳妥的编排器会给每个平台单独设置任务队列；同一顾客短时间的重复消息使用幂等键合并；当前顾客查询优先于非紧急统计任务；连续出现登录失效或页面异常时，自动熔断该平台，而不是让失败请求不断堆积。其他已健康的平台可以继续提供结果，工作人员只需处理明确标出的异常来源。

• 队列按平台隔离，避免一个后台异常拖慢全部查询。
• 同一查询条件在短时间内只执行一次，结果供重复咨询复用。
• 超过预设等待时间即转人工，避免顾客在聊天中长期空等。
• 验证码、风控提醒或页面状态不明时立即暂停自动操作。

第四层：先做结果规约，再决定能否自动回复

三套后台返回的字段不能直接拼接发送。一个平台可能显示“已入库”，另一个显示“待取件”；有的平台带货架信息，有的平台只有取件码；同一手机号还可能同时命中多个包裹。统一结果层需要把这些差异转为顾客和店员都能理解的共同语言。

推荐至少统一来源平台、包裹状态、取件凭证、脱敏运单线索、查询时间和匹配置信度六类字段。重点是置信度：当系统只能依据尾号找到多条记录，或返回数据缺少核验条件时，结果应该从“自动回复”流向“补充信息或人工复核”，而非为了显得智能而选一条发送。

• 高置信度：返回必要取件信息，并标明来源平台。
• 多包裹：分条展示，不把不同平台的记录错误合并。
• 数据同步中：说明状态可能延迟，提供复查或人工入口。
• 低置信度：不展示可能属于他人的取件码。

用一个尾号查询案例看完整链路

假设顾客只发送“1234”。系统首先将它识别为手机号尾号，而不是完整身份凭证；随后向本网点已完成验收的菜鸟、兔喜、多多适配器派发查询任务。每个适配器都先检查会话是否有效，只有页面状态正常才继续执行查询。返回的记录被转为统一结构，再由结果层判断是否存在多名收件人、多件包裹或信息缺失。

若查询只得到一组满足规则的待取件记录，系统可以给出清楚的服务回复；若出现多个可能匹配，正确的动作是提示补充完整手机号或运单片段，并让店员接手。这个流程看起来比“直接查三次”多了一些步骤，却避免了错误取件码、错误隐私信息和无法解释的失败。

驿帮如何把 RPA 变成网点可用的服务能力

从产品角度看，驿帮 AI 查件助手的重点不只是让浏览器代替人点几下，而是将多系统查询、顾客微信入口、结果判断和异常处理串进同一套工作流。顾客不需要先知道自己的包裹属于菜鸟、兔喜还是多多；网点也无需在每次咨询时重新判断从哪个后台开始查。

驿帮当前提供菜鸟、兔喜、多多等在内的 24 类驿站及智能柜系统兼容范围，并把具体可用性留给部署前的真实账号测试。微信侧采用可见界面的 Computer Use 操作路径，不 Hook、不注入、不修改微信通信协议；这并不意味着可以承诺账号绝对不受限制，网点仍要遵守平台规则、控制使用边界。更有价值的是，技术路径、异常停止和人工接管都能向经营者说明白。

上线前的技术验收，不要少于这五项

• 单平台正常件：状态、平台来源和必要取件信息是否一致。
• 跨平台多包裹：是否完整返回，是否发生错误合并。
• 尾号重合与隐私号：是否停止自动展示并要求核验。
• 刚入库的数据：页面结果的时效性和“同步中”提示是否准确。
• 登录过期与网络中断：是否停止错误回复，恢复步骤是否清楚。