CRM里出现两个“Alex Chen”，都来自同一家公司。Agent把它们合并后，两个销售的活动记录连到了一起。名单更短了，客户关系却被弄乱了。
姓名相同不等于身份相同，字段相同也不一定能证明是一个人。 AI CRM去重更适合先产出带匹配理由、反证和待确认事项的审核队列，把合并决定留给掌握客户上下文的人。
Buda的CRM自动化工作流可以从重复与缺失检测开始。实体识别需要独立规则：防止重建同一任务的业务键，并不能判断两个联系人是不是同一个人。
先保留八条记录，不急着变成四条
以下八行全部虚构，用于说明方法；邮箱使用保留的 .example 域，不是联系地址，也没有运行生产CRM测试。示例来源时间统一为2026年10月18日，实际导出应保存每行的来源系统与更新时间。
| 来源:record-id | 姓名 | 原邮箱 | 公司或备注 |
|---|---|---|---|
| A:101 | Alex Chen | alex@north.example | North；销售联系人 |
| B:101 | Alex Chen | alex.chen@north.example | North；技术联系人，身份待核 |
| A:102 | Priya Rao | priya@harbor.example | Harbor |
| B:202 | Priya Rao | priya@HARBOR.example | Harbor；部门字段不同 |
| A:103 | Mei Lin | team@cedar.example | Cedar；共用邮箱，负责订单 |
| B:203 | Kai Lin | team@cedar.example | Cedar；共用邮箱，负责技术 |
| A:104 | Jordan Lee | jordan@old.example | Old；历史记录 |
| B:204 | Jordan Lee | j.lee@new.example | New；本人确认换公司并关联旧邮箱的记录S04 |
A:101与B:101的数字相同，但来自两个来源namespace，不是同一记录ID。引用必须包含来源和ID。不要先把它们当重复主键删掉一条。
这批样本也不是要求强行输出四对。候选生成、身份核实和合并是三个阶段；没有足够线索的配对，可以不进入审核队列。
标准化只用于比较，原值不覆盖
给邮箱保留 email_raw，另建比较值。先在副本中去掉字段外围空白、将域名部分统一为小写，保留本地部分；邮箱本地部分是否能忽略大小写，需按来源与团队规则确认。上述Priya两条在这种规则下相同，但仍只是强候选。
不要擅自去掉 +tag 或Gmail点号，不把不同服务商的别名习惯通用化。看起来格式正确不代表邮箱有效、可收信或属于同一个人。也不要通过给客户发验证邮件来偷偷扩张任务。
电话同样保留原值与来源。国家码未知时，不凭公司地址补一个国家码；本地号码的相同尾号不是全球唯一身份。名字拼写、公司域名和职位可以帮助检索，但单独都不够作身份结论。
输出三类候选，而不是一个“重复概率”
| 配对 | 分类 | 支持与反证 | 审核动作 |
|---|---|---|---|
| A:102 ↔ B:202 | 强候选 | 姓名一致，按声明规则比较的邮箱相同；部门冲突 | 交当前客户owner核身份与部门时效 |
| A:104 ↔ B:204 | 可能相关 | S04把本人新旧邮箱关联；公司与邮箱已变 | 核S04原文、时间和允许的关联方式，不自动并入旧公司 |
| A:101 ↔ B:101 | 不合并 | 只有同名同公司，岗位线索不同、无身份佐证 | 保留两条；有业务需要再核实 |
| A:103 ↔ B:203 | 不合并 | 共用邮箱相同，但对应两个人和不同职责 | 保留两位联系人与共用邮箱关系 |
“强候选”不等于批准合并。换公司但邮箱不同，也不意味着一定是两个人：这里S04是虚构的显式确认材料，实际任务没有这样的证据就保留未知。公司归属与人的身份还可能需要不同对象关系。
不输出“92%同一人”之类未经校准的概率。审核人需要知道命中哪条规则、有哪些反证、还缺哪一条确认，而不是一个精确外观的猜测。
一对候选，要带上哪些证据？
candidate-pairs.csv至少包括pair-id、双方namespace和record-id、命中规则版本、原值、比较值、来源时间、支持材料、反证、缺口、分类和建议核实角色。
pair-id可以用双方带namespace的标识按固定顺序排序，并加规则版本，例如 v1|A:102|B:202。这是一种可复算的命名约定，不是Buda原生幂等锁。两次读取同一脱敏输入和规则，预期生成相同pair-id；这是建议验收，尚未执行。
别把配对当自动传递关系：A与B有线索、B与C有线索，不代表A与C必然同人。把三条一口气合并前，仍需逐条查证不同联系人、历史变更和共享地址。
conflicting-fields.md保留冲突字段、每个来源的原值与更新时间。Priya的两个部门值可能是岗位变动，也可能是导出时间不同或录入错误。业务owner选保留值；最新更新时间不自动赢，Agent也不替销售改owner、stage或amount。
review-decisions.csv记录人工确认的同人/不同人/证据不足、核实者、依据、时间和后续决定。建议和人工决定分栏，未审核不能被计作已确认重复。
就算确认同人，合并仍是另一件事
CRM记录可能关联活动历史、机会、工单、订阅和权限。系统的主记录选择、活动归属、关联迁移、撤销机制如果没有核实，就不能承诺“合错再恢复”。
先保留导出与候选，不连接生产写权限、不删除、不合并、不转移owner。身份确认后，把关联影响与保留字段交CRM管理员核对原生行为；管理员获得明确授权后，才安排系统中的操作。这条审核清单不替代CRM，也不宣称已测试特定CRM集成。
在Buda里先做只读的一轮
在Drive放入获准使用的脱敏导出、字段字典、规则版本和必要确认材料。Agent Drive与Space Drive共享范围不同；新Session用于分开对话，不是新的文件权限边界。
只读取指定脱敏副本和匹配规则。保留原namespace、record-id及原值，标准化仅用于比较。交付候选配对、字段冲突和人工决定模板，逐项带来源、反证与缺口。不输出未经校准的身份概率，不写生产CRM、不删除、合并、发送或改业务字段。
打开实际文件抽查四类反例：同名不同人、共享邮箱、换公司、同人多邮箱。检查候选是否能回到源行，未确认字段是否仍空着。不要用输出文件存在证明匹配正确。
RevOps工作流涉及更广的数据治理；这里先把一个明确风险做小：让管理员看清哪两条值得查、为什么查、查完由谁决定。
如何衡量，而不把候选数当成果
人工核实后，可以计算候选准确率：确认同人的候选对数 ÷ 已完成身份核实的候选对数。证据不足另列，不塞进“已核实”分母。保留分类和规则版本，才能看出哪条规则带来误报。
这个数只衡量送审候选的准确性，不能说明漏掉多少重复。要评估漏报，需要另有代表性的人工标注集合；没有就直说尚不可测。不要把八行教学样本的分类当业务准确率或效率收益。
多人共用一个邮箱怎么办？
把共享地址当联系方式，不当唯一的人。保留不同联系人及职责，核实CRM是否支持相应关系。共用邮箱相同本身不触发合并。
人离职换了公司，还能是同一联系人吗？
可以，但需要获准的本人确认或其他明确身份材料。把旧公司、历史活动和新公司关系分别处理；确认同一人不等于把历史机会转到新公司。
谁来确认，怎么留下结论？
由了解关系的业务owner核身份，CRM管理员核关联与系统操作。记录确认材料、角色、时间、保留字段和待办；没有明确依据时保持证据不足。
先让错误匹配变得容易被发现
在Buda AI的Marketplace搜索并安装合适的数据处理Skill，读清匹配规则和停止条件，再用脱敏副本运行。第一轮目标不是让名单变短，而是让每一个疑似重复都有依据、有反证、有可以说“不合并”的人。