营运与维护 · 实作指南
看起来相同的客户名，为什么匹配失败？
用字符规范化处理姓名表示差异，同时保留原文、客户编号与人工合并边界。
AAHouse 原创解说视频，采用 AI 辅助概念画面、合成旁白及原创音乐。
英文逐字稿 · 简体中文普通话逐字稿 · 台湾华语逐字稿 · 香港粤语逐字稿 · 澳门粤语逐字稿
案例备忘：同名，不一定同码
设想一家美国餐饮配送公司的客户导入：网页表单中的 José 与旧系统导出的 José 看起来相同，精确匹配却失败，AI 因而建议建立新客户。这是虚构情景。先别让模型改拼写；请开发者检查字符表示，问题可能来自一个带重音字符与“字母加组合重音”的不同编码。
依已核准文章重绘的解说示意图。
拆开看，再决定怎么比
同一个 é 可以写成 U+00E9，也可以写成 U+0065 加 U+0301。两串原始值不相等；把双方转换为 NFC 后，这对表示可以相等。Unicode 定义了这种规范等价，JavaScript 的 normalize("NFC") 可用于转换。[S1][S2] 这不是把所有看起来像的文字都变成同一个名字。
依已核准文章重绘的解说示意图。
一条记录，保留三个位置
建议把原始姓名、用于比较的键、稳定客户编号分开保存。原文用于展示与核对；比较键由明确规则生成；编号负责关联订单。两边都按同一规则生成键，不要只处理新表单。匹配结果只是一条候选线索，不能据此覆盖客户原名，也不能把两个同名客户自动合并。若多个编号落入同一个比较键，输出碰撞清单，而不是选第一条。原文保留也方便负责人撤销错误规则并重新计算键。
依已核准文章重绘的解说示意图。
规则选择卡：NFC 还是 NFKC？
对本文这类规范等价差异，可评估 NFC。NFKC 还会折叠某些兼容差异，例如圈号数字与普通数字；它不是“更强所以更好”。Unicode 明确提醒，不应对任意文本盲用兼容规范化。[S1] 产品编号、合同原文和姓名字段应分别约定，不能共用一个万能清洗开关。
依已核准文章重绘的解说示意图。
这条线必须留着
规范化不是去重音、转小写、翻译，也不是身份验证。视觉相似的字符仍可能不同；W3C 的字符串匹配工作草案也说明了这一局限。[S3] 如果团队另加忽略大小写或重音的搜索规则，应单独说明，并展示多个候选，不要把宽松搜索直接变成写入或合并权限。
依已核准文章重绘的解说示意图。
桌面演练：应相等，也应不相等
上线前准备三组测试：预组合与组合重音形式应按所选 NFC 规则匹配；Jose 与 José 不应仅因 NFC 就相等；两个姓名完全相同但客户编号不同的记录仍须保留。再检查导入、检索与回写的原文是否保真。这是建议的验收计划，不代表已在你的系统执行。
依已核准文章重绘的解说示意图。
交给负责人的是决定，不是清洗按钮
让业务负责人批准每个字段的比较规则，再由开发者记录规则版本、保留原文并列出碰撞候选。试运行先只输出建议：找到哪个编号、依据是什么、哪些情况无法确定。验收重点不是“重复减少了多少”，而是该找到的能找到，不该合并的没有被误合并。
依已核准文章重绘的解说示意图。