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，讀清匹配規則和停止條件，再用脫敏副本執行。第一輪目標不是讓名單變短，而是讓每一個疑似重複都有依據、有反證、有可以說“不合並”的人。