企业 AI 识别人名和公司名时，应先查来源系统中的稳定标识，再使用已经确认的跨系统映射。姓名、简称和相似地址只能帮助查找候选，不能直接证明两个记录属于同一对象。身份无法确定时，保留候选并补问能够区分对象的信息。
这项设计适用于整合通讯录、业务记录、会议纪要和历史文件。错误身份一旦带入后续整理，可能把不同人员的事项拼在一起，或将关联企业的订单混为一个主体，因此需要同时设计匹配和拆分两条路径。
身份记录与名称记录
身份表为每个人或组织保留独立编号；名称表记录曾用名、简称、别称及其适用期间；来源映射表记录各业务系统中的编号。三类信息分开维护，显示名称变化时无需更换身份编号。
| 观察到的情况 | 应建立的关系 | 不宜执行的操作 |
|---|---|---|
| 同一人员更名 | 同一身份的名称变更 | 新建完全无关的第二个人 |
| 不同人员同名 | 两个独立身份 | 合并待办与工作记录 |
| 公司简称被多人共用 | 一个别名对应多个候选 | 将别名设为唯一标识 |
| 母子公司名称接近 | 独立主体与组织关系 | 共用订单和收款主体 |
| 员工转岗 | 带期间的任职关系 | 用现岗位覆盖历史岗位 |
企业上下文整体建设可参考企业上下文工程。身份匹配需要在其中保留明确的来源编号，不能仅依靠名称之间的语义相似度。
示例：两个同名联系人
示例：业务系统中有两位都叫“联系人甲”的人员，一个负责采购，一个负责设备维护；旧会议纪要只写了姓名，没有部门。新的采购记录包含独立联系人编号，能够对应采购岗位人员，但不能据此把所有旧纪要都归给他。
处理时先绑定带编号的新记录。对于旧纪要，检查会议主题、参会组织及原始签名等证据；仍无法区分的条目保留“待确认”。系统回答“联系人甲承诺了哪些事项”时，应先请求选择具体人员，不能把两人的承诺合并成一份清单。
这个示例中的姓名为占位称谓。真实实施时，界面可展示“姓名＋所属组织＋岗位”供有权限的使用者选择，避免为了消除歧义展示无关的私人信息。
候选匹配的判定顺序
先查来源范围与对象编号的精确组合。来源范围应明确系统实例、所属组织及对象类型，不能只写软件名称；不同范围内都可能存在编号一百。其次查已经人工确认或来自可信主数据的映射。精确匹配都不存在时，才按名称、组织、业务关系查找候选。
候选评分可用于排序，身份确认仍需检查对应证据。例如手机号可能由团队共用或在人员变更后重新分配；邮箱可能是岗位邮箱。辅助信息出现冲突时，应保留冲突及其时间，不以“多数信息一致”强行合并。
匹配记录需要写清采用证据、排除候选的原因、确认方式和生效日期。短期人工确认可以只适用于当前记录，不能悄悄扩展为所有历史资料的永久映射。
集团关系与单据主体
公司简称尤其容易跨越多个主体。一个品牌、一个集团与多个经营公司，可以通过关联关系连接，但发货、开票和收款记录仍要保留原有主体。问集团总量时按明确规则汇总，问某个公司的单据时按实际主体过滤。
关联关系也需要有效期间。某公司加入集团之前的历史数据是否纳入汇总，应由报表口径决定；不能因为今天有关联，就自动重写过去的归属。身份表负责说明对象是谁，统计规则负责决定本次包含谁。
身份确认也应限定可见范围。使用者只能看到自己有权访问的候选，不能通过搜索同名人员获得其他部门或组织的受限资料；缩小权限后的“唯一候选”也不代表全公司只有一个同名对象。
错误合并的拆分与复核
合并时保留每条原始记录的来源标识，避免物理覆盖后失去拆分依据。发现误合并后，先冻结错误映射，再按证据把记录分回对应身份。对确实无法判断的记录保留未决，不能为了让台账完整而平均分配。
随后检查受影响的事项清单、统计结果和摘要。身份映射修好了，旧摘要仍可能引用错误归属，因此需要记录影响范围并逐项更新。原有记录不应无痕消失，审核人员应能看到拆分原因和修复结果。
验收时准备同名不同人、同人不同名、同简称不同主体、转岗及误合并后拆分等样本。输出需要解释对象选择依据，无法判定的样本应准确停留在待确认状态。基础数据准备可参考业务事实源建设；跨系统映射实施可查看定制开发服务。
