业务员站在便利店门口，手机地图里却搜出三个名字几乎一样的门店——这种现场，我在每个渠道数字化项目里都撞见过。它通常不会被当成技术问题反馈上来，业务侧的说法是"系统里的店太乱"，然后这件事就被搁置了。

直到某一季盘账，DMS 显示这家店进了两笔货、费用系统给它核了两笔陈列费，而街上其实只有一家店。

这类脏数据的正式名字叫 一店多档：同一家真实门店，在系统里被录成多条互不关联的档案。本文从 IT 侧的角度，把它的成因、技术解法、集成边界和验收口径理一遍，供评估这类项目时参考。

一店多档不是录入粗心，是多系统并行的必然

很多渠道经理把它归到"业代不负责任"。真去翻数据你会发现，四类成因里至少三类跟责任心无关：

多系统各自建档。 SFA、DMS、订货、车销这几套系统早期往往是独立立项、独立建档的，字段标准各定各的。同一家门店在两条线上各留一份档案，属于架构层面的默认结果。

地址写法不统一。 人工录入会把"XX 路 18 号""18 号 1 层""XX 路临街"写成三家店。城乡结合部门牌缺失，只能写"附近"，对齐难度更大。

定位漂移与招牌更换。 GPS 在密集街区漂出几十米是常态；门店换招牌、老板易主之后旧名没清、新名又建，旧档案就悬空了。

人员流动。 业代离职交接遗漏，新人搜不到就按习惯重开，重复记录一层层累加。

还有一层常被忽略：终端本身是动态的。每天有店开张、关门、改名、搬址。用一套静态标准去管理一群会动的对象，重复档案几乎是必然产物，关键只在于能否被快速识别与合并。

一条脏档案会顺着哪条链路放大

重复档案的危害不在于"表里多了几行"，而在于以门店为统计单元的所有指标都会跟着失真。我们做过的项目里，放大路径基本是固定的：

这也是为什么门店主数据治理很难只交给 IT 或只交给业务：它处在 RTM 链路的数据源头，动一下，下游全动。

实体对齐的技术选型：从规则匹配到多模态

判断两条记录是不是同一家店，本质是一个实体对齐（entity resolution）问题。工程上大致有四档做法，成本和准确率递增，误判代价各不相同：

精确字段匹配。 用统一社会信用代码、门店编码做连接。准确率极高，但覆盖率很低——大部分小b门店根本没有这些字段。

名称编辑距离。 把店名做分词归一（去掉"便利店/超市/商行"等同义后缀，统一半角全角），再算编辑距离。能抓住"利民便利店 / 利民超市"这类变体，但同名异地店会造成误合并。

地址地理编码 + 坐标距离。 把地址归一后做地理编码，配合经纬度阈值过滤。这一档能挡掉大部分同名异地店，代价是地址质量差时地理编码本身就不可靠。

多模态加权聚合。 名称、地址、坐标之外，再引入现场拍摄的招牌照片，提取视觉特征参与比对。对"换了招牌但门头未变"的门店特别有效；当门店名称和地址都变了，它是仍然有效的判定维度。

选型时有一点必须提前定： 误合并的代价远高于漏合并。漏掉一条重复档案，最多是数据继续脏；把两家不同的店合并成一家，订单、费用、账期会一起串，修复成本极高。所以阈值设置宁可保守，中相似度区间一律交人工复核，不要追求"一次自动清干净"。

为什么后台聚类和现场匹配必须双轨

只做一头都会留缺口，这个结论我们绕了两年才确认：

只做后台跑批。 能清存量，但新业代明天还会建重复档，治理成果一两周就回到原点；而且纯算法聚类存在误合并风险，没有人在现场确认。

只做现场匹配。 增量可控，但历史堆积的存量档案靠人工逐条认，成本高、进度慢，业务侧两轮就失去耐心。

可行的做法是双轨闭环：

1. 后台批量对齐清存量。 用相似度聚类把疑似重复档案成组推送，按分级策略处理——高相似自动建议合并、中相似转人工复核、低相似放行。
2. 拜访现场即时匹配控增量。 业代在地图上选不到门店时手动输入店名，系统即时返回候选门店列表，附相似度与地址，现场确认合并或新建。每次拜访都顺带完成一次治理动作。
3. 合并结果回流下游。 归档结果同步回 SFA、DMS、订货、车销，订单与费用自动归集到统一门店编码，避免二次分裂。

把治理嵌进拜访动线，数据质量才不再是季度项目，而是每天每访的自然产出。

集成边界：谁持有主数据，谁说了算

这一节是项目里最容易扯皮的地方，也是我认为 IT 侧必须提前拍板的三件事。

主数据落在哪个系统。 常见做法是新建一个主数据服务，SFA、DMS 等系统只持有引用。如果短期内做不到，退而求其次也要指定一个"权威源"，其余系统按同步处理，绝不能几个系统都允许自主新建门店。

合并操作是否可逆。 合并必须留下可回溯记录：谁在什么时间合并了哪几条档案、依据的相似度是多少。误合并之后能不能拆回来，直接决定业务侧敢不敢用自动建议。

接口的幂等性。 拜访现场的网络环境不稳定，合并请求重复提交是常态。上游必须用业务幂等键去重，否则一次网络重试就会制造新的脏数据。

上线顺序与验收口径

不建议一上来就全量治理。我们试过的顺序是：先把门店档案的字段标准与必填规则定死，再选一个区域做试点跑通"识别—确认—合并—回流"的完整链路，然后才谈全量聚类和系统打通。

验收指标建议抓三个，比"重复率下降多少"更有诊断价值：

• 误合并率——分母是人工复核过的合并操作，这个是红线指标，应当压到极低；
• 现场确认耗时——业代从输入店名到完成合并的秒数，超过一个量级就会没人用；
• 新增重复率——治理后新产生的重复档案占比，它反映的是双轨闭环有没有真正落地。

收尾一句

门店主数据治理的技术含量，不在于相似度算法有多复杂，而在于把"识别重复"和"确认重复"这两件事分别放在正确的环节上：后台负责找出可能重复，现场负责确认是否重复。

对 IT 决策者来说，真正要提前想清楚的是三件事——权威源是谁、合并能不能拆、接口是否幂等。这三条定了，剩下的才是模型选型问题。三条没定，模型再准也会在业务侧被弃用。