设想一家美国餐饮配送公司。网页表单与旧系统导出的同一个客户姓名，看起来相同，精确匹配却失败。这是虚构情景。先检查字符表示，不要让人工智能随意改写姓名。

有的重音字母既可以用一个字符表示，也可以用字母加组合重音表示。把这两种表示都转换成相同的规范形式，可以解决这类差异。但这不代表所有长得像的名字都会相同。

建议分别保留原始姓名、比较键和稳定客户编号。原文用于展示，比较键按规则生成，编号用于关联订单。双方都要遵循相同规则。匹配只能提供候选，不能自动合并同名客户。

选择规范形式时，不要认为变化越多越好。兼容规范化还会折叠某些格式差异。姓名、产品编号和合同原文应分别约定规则，而不是共享一个万能清洗按钮。

规范化不是去重音、翻译或身份验证。视觉相似的字符也可能不同。即使另加宽松搜索，也要展示候选与不确定性，不能直接获得修改或合并记录的权限。

准备三组验收样本：同一重音的两种表示应匹配；有重音和无重音的名字不要因规范化就相等；同名但编号不同的客户不得自动合并。还要检查原文是否保留。这是建议计划，不是已完成的系统测试。

让负责人批准每个字段的比较规则，记录版本，保留原文，列出碰撞候选。先只输出建议。真正的验收，是该找到的能找到，不该合并的没有被误合并。