线索表里手机号、微信号和企业名混在一起，怎么整理成客户主表能匹配的字段

教程定位

这篇教程解决什么问题

这篇文章解决一个很常见但容易被低估的问题：线索 Excel、客服登记表和企业微信好友导出里的客户联系方式写法不一致，导致同一个客户被重复建档、不同客户被误合并、回访分配也跟着出错。

你会完成三件事：第一，定义一套客户唯一识别字段，不再只靠“手机号”或“公司名”单点判断；第二，把手机号、微信号、企业名、联系人姓名这些散乱字段整理成可匹配客户主表的标准字段；第三，产出一份清洗后主表模板和去重判断规则，方便后续导入 CRM、客服系统或数据表。

本文不讲销售漏斗分析，不讲客户分层运营，也不判断哪个客户更值得跟。这里的重点只有一个：把客户身份字段整理干净，让后续去重、回访分配和客户主表匹配有可靠基础。AI 可以帮你起草字段标准、归纳异常类型、生成清洗建议，但不能替你确认真实客户身份，也不能把敏感完整联系方式直接拿去公开对话里处理。

使用场景

什么情况下最适合用这一套

你是销售运营或客服主管，最近要把几份客户线索合到一起：市场同事给了一张活动报名 Excel，客服团队有一张登记表，企业微信还能导出好友备注和标签。每张表看起来都有“客户信息”，但字段完全不统一。

活动 Excel 里有的人把手机号写在“联系方式”列，有的人只留了微信号；客服登记表里“客户名称”有时是公司，有时是联系人；企业微信导出里备注名写着“王总-启禾-要报价”，真实姓名、企业名、微信备注混在一个格子里。更麻烦的是，同一个客户可能在不同表里写成“上海启禾科技”“启禾科技”“启禾-王敏”，也可能同一个公司下有多个联系人。

如果直接把这些表导进 CRM，后面会出现几类事故：

所以这篇文章的目标不是“一键去重”，而是先把客户身份字段拆清楚。只有字段层面稳定了，去重规则、主表匹配和回访分配才不会建立在猜测上。

• 同一个客户被重复分配给两个销售或两个客服，回访时互相打架。
• 一个企业总机或客服微信号被误当成自然人手机号，导致不同客户被合并。
• 公司简称和全称没有统一，客户主表匹配不上已有客户。
• 微信号、手机号、企业名混在同一列，系统无法按字段查重。
• 客服回访表里只剩“张总”“王姐”这类称呼，后续无法稳定关联客户。

材料准备

开始前先把材料和边界备齐

先准备四类输入材料。真实操作时，完整手机号、微信号、邮箱等个人信息应留在本地表格、公司批准的系统或受控环境里；给 AI 的样例可以使用脱敏值和内部临时编号。

| 材料 | 建议包含 | 用途 | | --- | --- | --- | | 线索 Excel | 线索 ID、姓名、联系方式、公司、来源、备注、提交时间 | 找出原始字段混乱情况 | | 客服登记表 | 登记 ID、称呼、电话、微信、企业名、回访人、问题摘要 | 识别客服口径里的客户身份 | | 企业微信好友导出 | 好友 ID、昵称、备注名、手机号脱敏、企业、标签、添加时间 | 拆分微信备注和好友身份 | | 重复客户样例 | 已知重复组、误合并案例、无法判断案例 | 训练规则边界，不让 AI 乱合并 |

开始前还要定好三个概念。

第一，客户主表不是联系人表。客户主表通常代表一个可被业务识别的客户对象，B2B 场景里常常是企业或门店；联系人表代表企业下的具体人。手机号和微信号更适合识别联系人，统一社会信用代码、标准企业名、客户编号更适合识别客户主体。很多混乱来自把这两层混成一张表。

第二，唯一识别字段不一定只有一个。对于 B2B 客户，可以设置 `customer_key` 作为客户主体键，设置 `contact_key` 作为联系人键，再用 `customer_contact_key` 表示某个联系人在某个客户下的关系。这样可以处理“同一公司多个联系人”和“同一联系人换公司”的情况。

第三，清洗不是删除原始信息。原始手机号、微信备注、公司原名、客服备注都要保留在原始字段或审计字段里。标准化字段用于匹配，原始字段用于追溯。不要为了表面整齐，把来源信息覆盖掉。

建议最终字段分成四组：

| 字段组 | 示例字段 | 说明 | | --- | --- | --- | | 原始字段 | raw_contact_text、raw_company_name、raw_wechat_remark | 保留原表里怎么写 | | 标准字段 | mobile_norm、wechat_id_norm、company_name_norm | 用于查重和匹配 | | 识别字段 | customer_key、contact_key、match_level、match_reason | 表示匹配结论和理由 | | 处理字段 | clean_status、review_reason、owner_suggestion | 表示可自动匹配还是需复核 |

实操流程

按这套步骤把工作跑起来

【第一步：先拆字段，不要直接合并客户】

遇到“联系方式”这种大杂烩列，第一步不是判断重复，而是把它拆成明确字段。比如一个单元格里写着“王敏 138****4521 微信 qh-wang 上海启禾”，需要先拆成联系人姓名、手机号、微信号、企业名、备注片段，而不是直接生成“客户=王敏”。

可以先做一张字段拆分表：

| 原始列 | 标准字段 | 处理口径 | | --- | --- | --- | | 联系方式 | mobile_raw、wechat_raw、other_contact_raw | 按明显格式拆分，无法判断的放 other_contact_raw | | 客户名称 | company_raw 或 contact_name_raw | 如果是企业后缀，优先识别为公司；如果是人名称呼，放联系人 | | 企微备注 | contact_name_raw、company_raw、intent_note_raw | 备注名只作为线索，不直接当标准字段 | | 客服备注 | service_issue_summary、contact_hint | 只提取身份相关信息，业务问题另存 |

AI 在这一步适合做“字段拆分建议”，但不要让它自己脑补。比如备注里只有“王总”，AI 不能补成“王先生”；公司名只有“启禾”，AI 可以标记为“疑似简称，需要查主表”，不能直接改成某个完整公司。

【第二步：定义客户主体和联系人两层唯一字段】

很多团队去重失败，是因为把“手机号相同”和“客户相同”画了等号。实际情况更复杂：同一企业下多个联系人可以有不同手机号；一个联系人跳槽后可能关联两个公司；一个企业总机可能被多个客户记录共用；一个微信号也可能是客服号或门店号。

建议定义两层识别键：

| 识别键 | 推荐组成 | 用途 | | --- | --- | --- | | customer_key | 标准企业名 + 统一社会信用代码或内部客户编号；没有证照时用标准企业名 + 地区 + 来源系统辅助 | 匹配客户主体 | | contact_key | 标准手机号、标准微信号、邮箱之一，加联系人姓名辅助 | 匹配具体联系人 | | customer_contact_key | customer_key + contact_key | 判断某联系人是否属于某客户 |

如果你没有统一社会信用代码，也可以先用“企业名标准化 + 地区 + 已有客户主表 ID”作为过渡方案，但要在字段里标明置信度。比如 `match_level=high` 表示客户主表 ID 已命中，`match_level=medium` 表示企业名高度相似但需人工确认，`match_level=low` 表示只有备注或简称线索。

【第三步：给手机号、微信号和企业名分别写标准化规则】

联系方式混乱时，不同字段要分开处理。

手机号标准化可以做这些规则：去掉空格、短横线、括号和国家区号；区分手机号、座机、400 电话、分机号；只把符合内部规则的号码写入 `mobile_norm`；无法判断的放入 `other_contact_raw`，不要硬塞进手机号字段。

微信号标准化要注意大小写、前后空格、中文备注和微信昵称。企业微信导出里常见的“备注名”不等于微信号，昵称也不等于客户姓名。可以设置 `wechat_id_norm` 存真正微信号，`wechat_nickname_raw` 存昵称，`wechat_remark_raw` 存备注名。

企业名标准化更需要保守。可以去掉多余空格、统一中英文括号、补齐明显的“有限公司”断行，但不要把“上海启禾科技有限公司”和“上海启禾智能科技有限公司”自动合并。简称、品牌名、门店名可以先进入 `company_alias_raw`，再通过客户主表或人工维护的别名表确认。

字段标准可以写成这样：

| 标准字段 | 来源 | 清洗规则 | 不能做什么 | | --- | --- | --- | --- | | mobile_norm | 手机、联系方式、客服电话 | 只保留本地校验通过的号码标准值 | 不根据脱敏号猜完整号码 | | wechat_id_norm | 微信号、企微外部联系人 ID | 去空格，保留真实 ID 或系统外部联系人 ID | 不把微信昵称当微信号 | | company_name_norm | 公司、客户名称、企微备注拆分 | 使用客户主表或别名表确认后的标准名 | 不把简称自动改成未知全称 | | contact_name_norm | 姓名、称呼、备注拆分 | 去掉职务称呼，保留可确认姓名 | 不把“王总”补成具体姓名 | | customer_key | 主表客户 ID 或标准企业识别组合 | 优先使用已有客户主表 ID | 不用单一手机号代表客户 | | contact_key | 手机号或微信号等联系人识别字段 | 多字段组合判断联系人 | 不把公共电话当个人联系人 |

【第四步：把匹配结果分成三档】

不要让 AI 输出“已合并”。它应该输出匹配建议和复核理由。建议把结果分成三档：

| 匹配档位 | 判断条件 | 处理方式 | | --- | --- | --- | | 可自动匹配候选 | 客户主表 ID 命中，或标准企业名完全一致且联系人字段一致，无冲突字段 | 进入主表更新候选，批量前抽样 | | 需人工复核 | 企业名相似、简称命中、同手机号不同公司、同公司不同联系人、微信备注含糊 | 由销售运营或客服主管确认 | | 暂不匹配 | 只有称呼、公共电话、测试数据、供应商/同行、身份字段不足 | 不进主表，保留原始记录和原因 |

判断顺序建议从强到弱：

这里的重点是：联系方式可以帮助找到联系人，但不应单独决定客户主体。尤其在客服场景里，一个手机号可能是门店公用号，一个企业微信好友可能是代理商员工，一个公司简称也可能对应多家主体。

【第五步：设计清洗后主表模板】

清洗后的主表不需要一开始就很复杂，但字段要能支撑后续匹配和追溯。可以先做成下面这种模板。

| 字段名 | 示例 | 说明 | | --- | --- | --- | | source_record_id | LEAD-001 / CS-088 | 原始记录编号 | | source_system | 线索Excel / 客服登记 / 企业微信 | 来源系统 | | raw_contact_text | 王敏 138****4521 微信 qh-wang | 原始联系方式文本 | | raw_company_name | 启禾科技 | 原始企业名 | | contact_name_norm | 王敏 | 标准联系人姓名，无法确认则留空 | | mobile_norm_masked | 138****4521 | 脱敏展示，完整值留本地受控表 | | wechat_id_norm_masked | qh-***ang | 脱敏展示或企微外部联系人 ID | | company_name_norm | 上海启禾科技有限公司 | 标准企业名 | | customer_key | CUST-202606-018 | 客户主体键 | | contact_key | CONT-9F21 | 联系人键 | | match_level | high / medium / low / none | 匹配置信度 | | match_reason | 标准企业名和手机号均命中 | 为什么这样匹配 | | clean_status | 可匹配候选 / 需复核 / 暂不匹配 | 后续处理状态 | | review_reason | 同手机号出现两个公司 | 复核原因 |

这张表可以作为客户主表匹配前的“清洗中间表”。它不是最终 CRM 导入文件，也不是销售分配结果。它的价值是把每一条原始记录的身份字段、匹配依据和不确定点留下来。

【第六步：用重复客户样例校准规则】

不要只给 AI 一张干净样例。最好同时准备三类重复客户样例：确定同一客户、确定不同客户、无法判断。

例如：

让 AI 根据这些样例先输出规则，再由你修改。这样它更容易理解边界：什么时候可以给出高置信匹配，什么时候必须停下来等人确认。

【第七步：先做标记，不要直接覆盖主表】

第一轮清洗建议只写入 `clean_status`、`match_level`、`match_reason` 和 `review_reason`，不要直接改 CRM 主表。尤其不要批量覆盖客户名、负责人、联系方式和客户 ID。

推荐流程是：

这样做虽然比“一键去重”慢一点，但更适合销售和客服都要使用的客户资料。身份字段一旦错了，后面的回访、归属和客户体验都会受影响。

1. 已有客户主表 ID 或系统客户编号命中，优先使用。
2. 统一社会信用代码或可信工商主体 ID 命中，匹配客户主体。
3. 标准企业名完全一致，并且地区或来源系统没有冲突。
4. 联系人手机号或企业微信外部联系人 ID 命中，再检查是否属于同一客户主体。
5. 只有简称、昵称、称呼、备注时，一律进入人工复核或暂不匹配。
6. 原始表保留不动，复制一份做清洗工作表。
7. AI 只处理脱敏样例和字段规则，输出清洗建议。
8. 人工抽样检查高置信匹配和全部冲突组。
9. 本地脚本或 CRM 导入工具按确认后的规则生成更新文件。
10. 更新后保留日志：原记录 ID、命中的客户主表 ID、确认人、更新时间、未处理原因。

• 确定同一客户：公司全称相同，联系人姓名和手机号一致，只是来源不同。
• 确定不同客户：手机号是 400 电话或门店电话，公司和联系人都不同。
• 无法判断：同手机号、同姓名，但企业名不同，可能是跳槽，也可能是录入错误。

输入示例

可以直接参考的输入材料

下面是一段可以粘给 AI 的脱敏样例。注意，样例使用了脱敏手机号、脱敏微信号和临时记录 ID；完整联系方式应留在本地受控表里。

背景：
我们要把线索 Excel、客服登记表、企业微信好友导出整理成一张可匹配客户主表的清洗中间表。请只处理客户身份字段，不要分析销售漏斗、客户价值或运营分层。

目标：
1. 定义客户主体和联系人字段。
2. 把混合联系方式拆成标准字段。
3. 给每条记录输出匹配建议、置信度和复核原因。
4. 输出清洗后主表模板。

已有口径：
- 客户主体优先用已有 customer_id；没有 customer_id 时，用标准企业名 + 地区辅助判断。
- 联系人优先用 mobile_norm 或 wechat_external_id；手机号、微信号只能识别联系人，不能单独代表客户主体。
- 企业简称必须通过客户主表或别名表确认，不能让 AI 自动补全。
- 公共电话、400 电话、前台电话不能作为个人联系人自动匹配。
- 只输出建议，不执行合并，不覆盖 CRM 主表。

样例数据：
| source_record_id | source_system | raw_name | raw_contact_text | raw_company_name | wechat_remark | source_note | known_duplicate_group |
| --- | --- | --- | --- | --- | --- | --- | --- |
| LEAD-001 | 线索Excel | 王敏 | 138****4521 / 微信 qh-***ang | 启禾科技 |  | 官网试用申请，想看客户回访分配 | G1 |
| CS-088 | 客服登记 | 王敏 | 手机 138****4521 | 上海启禾科技有限公司 |  | 咨询账号开通，备注同官网线索 | G1 |
| WE-204 | 企业微信 |  | 企微外部联系人ID wxext-A12 |  | 王敏-启禾-报价 | 好友标签：试用客户 | G1 |
| LEAD-019 | 线索Excel | 刘伟 | 400****1138 | 杭州景航贸易 |  | 展会扫码，写了公司总机 | G2 |
| CS-117 | 客服登记 | 赵晨 | 400****1138 转 802 | 北京明岚集团 |  | 前台转接，不确定具体联系人 | G2 |
| WE-311 | 企业微信 | 孙洁 | 微信 sj-***80 | 禾木智能 | 孙洁-深圳禾木 | 企微备注里公司疑似简称 | G3 |
| LEAD-042 | 线索Excel | 孙洁 | 186****7780 | 深圳禾木智能有限公司 |  | 已有客服记录，需确认是否同一联系人 | G3 |
| CS-140 | 客服登记 | 张总 |  | 北辰 | 张总-北辰 | 只说要回访，缺少手机号和微信号 | G4 |

请输出：
1. 字段拆分建议表。
2. 客户主体字段和联系人字段标准。
3. 每条样例的 clean_status、match_level、match_reason、review_reason。
4. 去重判断规则。
5. 清洗后主表模板字段。
6. 人工复核清单。

提示词

可复制使用的提示词

你是销售运营和客服数据清洗顾问。请根据我提供的脱敏样例，帮我整理“客户身份字段标准化方案”。

任务范围：
- 只处理客户唯一识别字段、联系方式拆分、客户主表匹配和去重判断规则。
- 不分析销售漏斗，不做客户分层，不判断客户价值，不写回访话术。
- 你只能输出建议，不能声称已经完成合并或覆盖主表。

请按下面结构输出：
1. 字段拆分规则：把手机号、微信号、企业名、联系人姓名、备注分别放到哪些标准字段。
2. 客户主体字段：customer_key、company_name_norm、company_alias_raw、source_record_id 等字段如何定义。
3. 联系人字段：contact_key、mobile_norm、wechat_id_norm、contact_name_norm 如何定义。
4. 去重判断规则：哪些情况是可自动匹配候选，哪些必须人工复核，哪些暂不匹配。
5. 样例处理表：逐条输出 source_record_id、customer_key 建议、contact_key 建议、match_level、clean_status、match_reason、review_reason。
6. 清洗后主表模板：字段名、字段含义、示例值。
7. 人工检查点：列出真实导入或更新主表前必须确认的事项。

重要边界：
- 不要根据脱敏手机号猜完整号码。
- 不要把微信昵称或企业微信备注直接当成微信号。
- 不要把公司简称自动补成完整公司名，除非样例中已有明确对应关系。
- 公共电话、400 电话、前台电话不能作为个人联系人自动匹配。
- 同手机号不同公司、同微信不同公司、同公司不同联系人，都要写明复核原因。
- 原始字段必须保留，标准字段只用于匹配和导入前确认。

输出样例

AI 应该输出到什么程度

这个输出还只是清洗建议。真正更新客户主表前，需要把 `company_name_norm`、`customer_key`、`contact_key` 回到本地系统或 CRM 里确认，再由销售运营或客服主管抽样验收。

### 1. 字段拆分规则

| 原始信息 | 建议标准字段 | 处理说明 |
| --- | --- | --- |
| raw_contact_text 中的手机号 | mobile_norm_masked / mobile_check | 脱敏展示；完整值应在本地受控表标准化 |
| raw_contact_text 中的微信号 | wechat_id_norm_masked | 只接受明确微信号或企微外部联系人 ID |
| raw_company_name | company_raw / company_name_norm | 原值保留；标准名需主表或别名表确认 |
| wechat_remark | contact_name_hint / company_alias_raw / intent_note_raw | 只作为拆分线索，不直接覆盖标准字段 |

### 2. 样例处理表

| source_record_id | customer_key 建议 | contact_key 建议 | match_level | clean_status | match_reason | review_reason |
| --- | --- | --- | --- | --- | --- | --- |
| LEAD-001 | 待命中：上海启禾科技有限公司 | 由 138****4521 生成 | medium | 需复核 | 与 CS-088 手机号和姓名一致，企业名为简称，需要确认简称对应 | 公司简称需与客户主表别名表确认 |
| CS-088 | 待命中：上海启禾科技有限公司 | 由 138****4521 生成 | high | 可匹配候选 | 企业名完整，姓名和手机号与 LEAD-001 一致 | 批量更新前抽样确认 |
| WE-204 | 待命中：上海启禾科技有限公司 | 由 wxext-A12 生成 | medium | 需复核 | 企微备注显示“王敏-启禾”，与 G1 有身份线索 | 备注不是标准字段，需要人工确认企微好友对应联系人 |
| LEAD-019 | 不建议自动生成 | 不建议生成个人 contact_key | low | 暂不匹配 | 400 电话疑似公共号码 | 公共电话不能作为个人联系人匹配依据 |
| CS-117 | 不建议自动生成 | 不建议生成个人 contact_key | low | 暂不匹配 | 400 电话加分机，且公司与 LEAD-019 不同 | 同号不同公司，应保留多条并人工核实 |
| WE-311 | 待命中：深圳禾木智能有限公司 | 由 sj-***80 生成 | medium | 需复核 | 企微备注和企业简称指向“禾木智能” | 需确认“禾木智能”是否等于深圳禾木智能有限公司 |
| LEAD-042 | 待命中：深圳禾木智能有限公司 | 由 186****7780 生成 | medium | 需复核 | 与 WE-311 姓名和公司线索一致，但识别字段不同 | 手机号与微信号需要在本地或系统中确认同一人 |
| CS-140 | 不建议生成 | 不建议生成 | none | 暂不匹配 | 只有“张总”和“北辰”简称，缺少稳定联系方式 | 身份字段不足，不能匹配客户主表 |

### 3. 去重判断规则

| 规则 | 条件 | 动作 |
| --- | --- | --- |
| R1 | 已有 customer_id 命中，且联系人手机号或企微外部联系人 ID 无冲突 | 可匹配候选 |
| R2 | 标准企业名完全一致，联系人姓名和手机号一致 | 可匹配候选，导入前抽样 |
| R3 | 企业名为简称或备注拆分结果 | 需人工复核，先查别名表 |
| R4 | 同手机号出现在不同企业名下 | 需人工复核或保留多条 |
| R5 | 400 电话、总机、前台电话、分机号 | 暂不作为个人联系人匹配 |
| R6 | 只有称呼、昵称、备注，没有手机号或微信号 | 暂不匹配 |

### 4. 清洗后主表模板

| 字段名 | 示例值 | 字段含义 |
| --- | --- | --- |
| source_record_id | CS-088 | 原始记录 ID |
| source_system | 客服登记 | 来源系统 |
| raw_contact_text | 手机 138****4521 | 原始联系方式文本 |
| company_raw | 上海启禾科技有限公司 | 原始企业名 |
| company_name_norm | 上海启禾科技有限公司 | 确认后的标准企业名 |
| contact_name_norm | 王敏 | 标准联系人姓名 |
| mobile_norm_masked | 138****4521 | 脱敏手机号展示 |
| wechat_id_norm_masked | wxext-A12 | 脱敏微信或企微 ID |
| customer_key | CUST-待确认 | 客户主体识别键 |
| contact_key | CONT-待确认 | 联系人识别键 |
| match_level | high | 匹配置信度 |
| clean_status | 可匹配候选 | 清洗处理状态 |
| match_reason | 企业名、姓名、手机号一致 | 匹配依据 |
| review_reason | 批量前抽样确认 | 人工复核点 |

### 5. 人工检查点

1. 用客户主表或别名表确认“启禾科技”“禾木智能”“北辰”等简称。
2. 在本地受控表中校验完整手机号和企微外部联系人 ID，不能用脱敏值做最终匹配。
3. 将 400 电话、总机、前台电话从个人 contact_key 规则中排除。
4. 检查同一联系人是否可能换公司，避免把历史客户关系直接覆盖。
5. 导入 CRM 前保留原始记录 ID、来源系统和匹配理由，方便回滚和追溯。

人工验收

人要怎么检查和改到可用

AI 生成结果后，人工至少要检查七件事。

第一，检查字段是否被拆错。比如“王敏-启禾-报价”可以拆出联系人线索和公司简称，但“报价”不是身份字段，不应该进入公司名或联系人名。

第二，检查手机号和微信号是否被过度使用。手机号、微信号可以识别联系人，却不能单独证明客户主体。看到同手机号不同公司时，要优先考虑公共号码、跳槽、代理商代填或录入错误。

第三，检查公司简称是否有依据。AI 很容易把简称补成看起来合理的全称，但这一步必须依赖客户主表、工商信息、别名表或人工确认。没有依据时，只能写“需复核”。

第四，检查公共联系方式是否被排除。400 电话、企业总机、门店电话、前台转接号、客服微信号，都不适合生成个人联系人键。

第五，检查原始字段是否保留。清洗表里必须能追溯到原始来源、原始文本和原始记录 ID，否则后续发现误匹配时很难回查。

第六，检查 `match_level` 是否过高。只有备注相似或简称相似，不应标成 high；至少要有主表 ID、标准企业名、稳定联系方式中的强证据组合。

第七，检查清洗结果是否越界。它只能服务客户主表匹配，不应该顺手给客户打价值分、决定销售跟进优先级，或者改写客服回访策略。

失败反例

这些失败反例要提前避开

**反例 1：把“联系方式”列整体当成手机号字段**

有些表里“联系方式”写的是“微信同手机号”“王总企微”“400 电话转 806”“138****4521 张经理”。如果直接把整列导入手机号字段，系统查重会失效，还可能把文字和分机号当成号码。正确做法是先拆分：手机号归手机号，微信号归微信号，无法判断的留在原始联系方式字段。

**反例 2：用手机号直接生成客户唯一 ID**

手机号适合识别联系人，不适合单独识别客户主体。B2B 场景里，一个企业有多个联系人，一个联系人可能换公司，一个公共电话也可能服务多个客户。如果用手机号当 `customer_key`，很容易把不同公司合成一个客户，或者把同一公司的多个联系人拆成多个客户。

**反例 3：把企业微信备注当标准公司名**

企微备注经常是销售自己写的工作记号，例如“张总-北辰-先别打扰”“刘伟-景航-渠道”。这些备注有价值，但它们不是标准字段。把备注里的“北辰”直接改成某个公司全称，会制造不可追溯的误匹配。备注拆出的公司名只能进 `company_alias_raw` 或复核字段。

**反例 4：为了追求干净，把原始字段覆盖掉**

清洗不是把原表改得看起来整齐，而是建立标准字段和匹配依据。如果把原始企业名、原始备注、来源表 ID 都覆盖掉，后续有人问“为什么这条被匹配到这个客户”，你就没有证据可查。

**反例 5：让 AI 直接输出最终合并名单**

AI 可以基于脱敏样例提出“可匹配候选”，但不能替你执行合并。最终更新客户主表前，还要回到 CRM、客服系统或本地受控表里校验完整字段，并保留确认人和更新日志。

主题边界

它和相邻主题的区别

这篇文章只处理“客户身份字段整理”：手机号、微信号、企业名、联系人姓名如何拆分，客户主体键和联系人键如何定义，散乱记录如何整理成可匹配客户主表的中间表。

它不是“重复手机号线索合并规则”。重复手机号那类主题重点是同一号码下多条线索怎么选择主记录、负责人和来源如何保留；本文更靠前，解决的是字段本身还没标准化、客户主体和联系人层级还没分清的问题。

它也不是“展会线索导入前清洗”。展会导入关注一批活动名单能不能进 CRM，包含来源、意向、跟进人和导入状态；本文不关心线索意向，也不决定是否导入销售池，只关心客户主表匹配所需的身份字段。

它更不是销售漏斗或客户分层运营。本文不会判断客户阶段、客户价值、成交概率、回访优先级。只要主表字段还不稳，后面的漏斗、分层和分配都会被脏数据拖偏；所以这里先把“谁是谁”整理清楚。