周四下午，OneID 规则评审刚开了 8 分钟。
数据工程师在大屏上放出第一条规则：
手机号相同，自动合并为同一客户。
运营同事觉得很合理。手机号总比姓名可靠，系统里叫“张伟”的人太多，号码看起来至少不会重名。
门店负责人却从表格里挑出两笔订单。收货手机号相同，一笔买男鞋，一笔买童装；会员姓名不同，生日也不同。那是一个四口之家，平时都留父亲的电话。按这条规则，系统会把夫妻和孩子安安静静地揉成一个人，再给他算出一种颇有想象力的消费偏好。
会议室里沉默了一会儿。
身份碎片会把一个人拆成几个人，错并则会把几个人压成一个人。前者让复购率偏低，后者会污染标签、推荐、人群包和服务记录。两种错误都麻烦，但错并往往更隐蔽，也更难撤销。
所以，OneID 项目真正需要的不是一句“按手机号去重”，而是一张能回答四件事的规则表：凭什么合、把握多大、什么情况绝对不能合、合错以后怎样拆。
先把“相同”拆成五层证据
身份合并没有一条适合所有公司的万能公式。
零售、电商、银行、内容平台掌握的字段不同，允许承担的风险也不同。下面这五层不是行业标准，更不是一组可以直接复制到生产环境的阈值。它是一套评审顺序：先用最能唯一指向某个人的证据，再逐层处理更模糊的线索。
第一层：经过验证的身份锚点
这一层处理确定性最高的关系，例如：
- 同一身份体系下的已验证账号；
- 同一会员系统中明确保留的账号迁移关系；
- 经本人验证完成的旧账号与新账号绑定；
- 业务流程已经确认的主从账户映射。
关键不在于字段“看起来唯一”，而在于关系经过谁验证、在哪个系统生效、能否追到原始动作。
手机号本身不是身份锚点。“用户登录后，通过短信验证把新手机号绑定到既有会员账号”，才是一条可追溯的账号关系。前者只是一个值，后者包含主体、动作、时间和验证过程。
第一层可以进入自动合并候选，但仍要经过反证检查。若两个账号同时保留互斥的实名信息，或业务明确允许家庭子账户，就不能只因存在一条历史绑定而覆盖现状。
第二层：两个以上的强字段组合
没有统一账号时，可以看经过标准化的强字段组合，例如：
- 已验证手机号 + 姓名；
- 已验证邮箱 + 姓名；
- 会员卡号 + 可核对的注册信息；
- 手机号 + 稳定的订单账号关系。
“组合”两个字很重要。单个手机号可能被一家人共用，单个姓名会重名，单个地址住着很多人。两个或三个彼此独立、长期一致的字段同时命中，误合风险才会下降。
不过，字段并不一定真的独立。收货姓名和手机号可能由同一张订单复制而来，不能因为表里占了两列，就当成两份证据。规则表要记录字段来源，否则“一份信息抄了三遍”很容易被算成“三重确认”。
第三层：稳定的业务关系
这一层关注的不是某个字段是否相等，而是多条记录在一段时间里是否呈现稳定关系。
例如，同一会员账号连续半年使用两个手机号下单；旧手机号停用后，新手机号沿用相同的会员权益、收货人和常用门店；客服记录里也存在本人确认的换号说明。
这些线索合在一起，通常比某一天的地址相同更有说服力。
第三层适合形成“高可信候选”，先进入人工抽样或延迟确认。若团队把它直接做成自动合并，至少要写清观察窗口、最少命中次数和反证条件。
