现场的问题常常藏在“明明一样”里
假设销售从外部表格复制一家公司名称，AI 整理后的结果在屏幕上几乎一样，系统却没有匹配到已有客户。有人准备换模型，有人建议删除所有空格。真正应先问的是：比较发生在哪一层，两个字段的字符表示是否相同，业务是否允许把它们归为同一主体。
这类问题与文件乱码不同。字符能正确解码，不代表不同系统使用完全相同的表示方式。本文基于 Unicode 文本规范化附录作实用解读，讨论 FDE 如何在现场明确规则。它不是某家模型今日推出的新能力，也不意味着所有匹配失败都能用规范化解决。
规范化解决表示问题，不代替身份判断
Unicode 规范区分规范等价与兼容等价，并定义相应的规范化形式。企业落地时可以记住一个核心差别：有些转换整理等价字符的表示，有些还会折叠兼容差异。选用哪一种，必须结合字段用途，不能把所有名称、型号和编号无差别转换后当主键。
例如，人类觉得两个名称很接近，仍可能属于不同客户；同一客户也可能有正式名称、简称和历史名称。前者涉及防止误合并，后者需要业务别名表。文本规范化只是比较链路中的一个步骤，无法替代主体确认。FDE 应把这条边界向业务负责人解释清楚，再决定哪些字段可以自动匹配。
原文与比较值分别保留
一个小而实用的方案，是保留收到的原始文本，另生成按明确规则处理的比较值。原文用于回看来源和向业务人员展示，比较值用于指定范围的搜索或查重。不要把规范化后的字符串覆盖掉唯一的原始记录，否则发生争议时，很难解释系统为什么认为两条资料相同。
比较规则也应有版本。今天只统一某种表示，明天又加入全角半角或标点处理，历史匹配结果可能变化。记录规则版本并不需要新建复杂平台，一个配置标识加一份变更说明就能起步。重点是让重跑结果可以解释，而不是给每一个字段增加抽象层。
先确定不能丢的业务差异
客户名称、产品型号、设备序列号和合同编号承担的任务不同。对搜索框可以接受的宽松处理，未必适合写回业务系统。某些标点或字符差异可能就是型号区别。上线前应请业务方给出反例：哪些看起来相近的字符串绝不能视为同一个对象。
拿到反例后，再做正例：哪些来自不同系统的写法确实指向同一对象。若正例需要额外证据，例如统一社会信用代码或内部客户编号，就把这些证据写进匹配流程，不要为了追求“自动命中”把字符规则调得越来越宽。误合并会把后续记录挂到错误对象上，比暂时不匹配更难发现。
迁移已有数据前先做碰撞检查
规则确定后，先在副本上生成比较值，并按比较值分组。若多个原始对象落到同一个值，标记为碰撞交给业务复核，不直接合并。输出可以只含脱敏标识、数量和来源位置，让负责人回到授权系统查看完整资料，避免把客户名单扩散到测试报告里。
对于已经有下游关联的客户记录，更应保守。先弄清订单、工单和权限是按哪个稳定标识关联，再讨论名称匹配。名称比较改进不应同时更换业务主键。若确实需要迁移标识，应单独制定迁移与回退步骤，不能借一次清洗把关联关系一起改掉。
验收要同时看到命中和误命中
测试样本至少应覆盖允许等价的表示、必须区分的型号、带业务标点的编号，以及规则执行多次后的结果。除了看该匹配的是否匹配，也要检查不该匹配的是否保持分离。对于无法确认身份的条目，应进入待核实状态，而不是让 AI 自己补一个“应该是同一家”。
还要验证输入与输出之间的追溯链：原文从哪里来，经过哪版规则，命中了哪个稳定标识，是否有人工修正。这里的验收建议来自本文的工程分析；Unicode 文档只定义文本层面的形式与性质，并没有替企业规定客户匹配流程或业务主体判定标准。
别把所有未命中都交给模糊匹配
未匹配条目中可能包含新客户、录入错误和系统表示差异，处理方式不应相同。可以先按原因分类，能依据规则修正的自动处理，需要身份确认的交给负责人。模糊搜索可以帮助找候选，但候选列表与正式合并之间仍应保留业务判断。
导出与再导入也是值得检查的环节。内部比较正确，外部工具却改写了字段，下一次导入仍会失配。用同一组边界样本走完整个往返流程，确认原文和稳定标识没有被重写，才能判断规则是否真正覆盖了使用场景。
对于不能规范化的标识，直接写明禁止变换，并在输入校验处给出可理解的提示。不要默默替用户修正成另一个有效编号。能解释为什么不匹配，往往比勉强提高命中数量更有交付价值。
在现场把规则交给能维护的人
FDE 不能只交付一段字符串处理代码。业务管理员需要知道新名称如何加入别名表，工程同事需要知道哪些字段不能套用宽松规则，维护人员需要知道改规则前运行哪组样本。让这三个角色各自能做正确的事，才能避免下一次表格导入又把问题带回来。
如果系统规模还小，先从一个确实出错的字段和一个明确任务做起。把原始值、比较值与匹配依据保留下来，验证现有客户不会被误合并，再扩大范围。不要宣称“所有文本已统一”，因为文本规范化、相似度搜索与业务实体识别承担的是不同责任。
上线之后可以定期抽查新出现的未匹配与碰撞条目，判断是新业务写法还是规则缺陷。只有证据足够时才更新规则，并重新跑过边界样本。这样的持续修正比一次性删掉所有特殊字符更稳妥，也更容易把现场经验沉淀成可解释的交付。
要点总结
- 不能。业务身份仍需稳定标识或其他可靠证据确认。
- 保留原文有助于回查来源、解释匹配和恢复处理规则变更前的状态。
- 不同原始对象可能映射到同一比较值，需要先复核，不能自动合并业务主体。
参考来源说明
本文为实用解读。来源时间：2026-08-12，修订58。2026-10-25核验。官方事实与本站建议分开表述；示例为假设场景，不代表客户案例、效果或实际账号测试。