去年黑五前 36 小时，一个做家居收纳的卖家朋友给我打电话：平台把他两个 ASIN 合并了，理由是”GTIN 相同”。有 4000 多条评论的老链接，被并到一个上架两周的新品上，广告预算还在往老链接的广告组里烧，但流量已经流到了新品详情页。他问我的第一句话是”为什么平台会认为这是同一个产品”，第二句话是”现在改码还来得及吗”。
这两个问题，恰好是 UPC 重复码排查的全部难点：前半句是判断为什么会重复，后半句是判断重复之后该动哪个东西。大部分团队在前半句栽跟头，更多团队在后半句把一次小事故扩大成一次大事故，因为在没有分级的情况下直接改码，等于把一条已经有历史权重的链接连根拔起。
这篇文章不讲 UPC 是什么、校验位怎么算这类可以随手搜到的东西。我要讲的是一套可以落到脚本和流程里的排查方法：四层过滤、三级冲突分级、以及在什么规模下该用什么手段。文中的样本数据和耗时对比，来自我自己经手的跨境项目以及同行交流的复盘，凡是推演口径我都会明确标注，避免你把示意图当成行业统计。
我见过太多人把这件事理解成一次数据清洗任务：把两张表按 UPC 做一次去重，输出的是一张”重复清单”，然后交给运营去处理。这个做法在 500 个 SKU 以内还能勉强运转，一旦到了多店铺、多站点、多供应商的规模，输出的那张清单本身就是灾难，因为它把”必须马上处理”和”可以先观察”混在了一起。
先说五条我认为最重要的结论，后面的所有内容都是在展开这五条。
UPC-A 是 12 位，EAN-13 是 13 位，GTIN-14 是 14 位，UPC-E 是 8 位压缩形式。同一个物理商品的码，在不同系统里可能以上述四种形态各存一遍。如果你直接按字符串比对，036000291452 和 00036000291452 会被判成两个不同的码。
同理，Excel 会把 12 位以上纯数字自动转成科学计数法，导出的 3.60003E+11 一回流就变成了脏数据；从 PDF 报价单复制的码经常带全角数字；从供应商 Excel 里粘过来的码尾部会带不可见空格。这些都会制造出大量”伪重复”和”伪唯一”。
先把所有码补齐到 14 位再做任何判断，这一步能消掉大部分噪音。
UPC/EAN 的最后一位是模 10 校验位。它的作用不是防重复，而是防录错。一位数录错、两位数字调换位置，校验位都会失败。这意味着你可以用三行代码，把所有”根本不可能存在”的码先挑出来单独处理，而不是让它们混在重复清单里干扰判断。
在我的实际样本里，校验位失效的码通常占全部记录的几个百分点，其中大部分是手工录入错误和供应商报价单里的 OCR 错误，只有少部分是真的被人为改过。
重复码的处置动作有四类：合并 Listing、拆开 Listing、给其中一个改码、下架重建。这四个动作的不可逆程度差别极大。合并容易拆开难，改码会丢掉历史权重，下架重建等于从零开始积累评论。
所以自动化的边界应该停在”生成一张按风险排序的处置建议表”，而不是”自动执行处置”。任何声称能全自动修复重复码的方案，我都建议你先在小批量 SKU 上验证三个月再决定要不要信。
重复码不是一次性问题，它是一个持续产生的问题：新供应商进来会带新码，新品建档会手动填码，历史 SKU 停用后码会被重新分配，多店铺铺货会复制粘贴。你这次排查干净了，下个月又会冒出新的。
真正有效的做法是：做一次全量基线排查，把结果存成基线快照；之后每个月只跑增量比对，只处理新增的冲突。这样每次的人力投入可以从几十人天降到几小时。
如果码是从正规渠道按需申请的，重复率天然就低；如果码是从供应商那里”顺手拿”的，或者是多年前从二手码商批量买的，那再精细的脚本也只能帮你发现问题，不能帮你解决问题。脚本能解决”看不见”，不能解决”没有干净码可用”。
要理解重复码为什么会发生，得先看清一个码从产生到上架要经过多少只手。我梳理过一条典型链路，从供应商报价到商品可售，一个 GTIN 至少要穿过七个环节，每个环节都有独立的输入方式。
回到开头那个卖家的案例。事后我们做了一次完整复盘，把时间线拉出来看，问题其实在三个月前就埋下了。
这条时间线最关键的信息是：从埋下问题到爆发，中间有两个多月的窗口期，只要有一次月度回归就能拦下来。
很多人以为 UPC 都是从 GS1 官网买的，实际在跨境卖家里，码的来源至少有四类，它们的重复风险差了一个数量级。
| 码源类型 | 典型获取方式 | 样本重复率（示意） | 主要风险 |
|---|---|---|---|
| GS1 官方自购 | 以公司主体申请前缀，按需分配 | 约 0.3% | 基本只有内部管理失误 |
| 供应商提供 | 报价单或包装上直接读取 | 约 4.7% | 多供应商供同款，共用同一码 |
| 历史遗留 | 多年前批量采购，无台账 | 约 8.9% | 码被重复分配、停用后回收再用 |
| 二手码商批量购 | 低价批量购买码段 | 约 12.6% | 同一码段可能被卖给多个买家 |
这张表的数字是样本推演口径，不同品类差异会很大，但排序关系在我的经验里是稳定的：二手码商的重复风险是官方自购的几十倍。如果你的重复率居高不下，先看看自己的码是从哪来的，再考虑优化脚本。
即使码源本身是干净的，它在系统之间流转时仍然会变形。我整理过七种最常见的变形，它们几乎覆盖了我在真实数据里遇到的九成伪重复。
这七种变形有一个共同点：它们在肉眼层面看起来都不像”同一个码”，所以人工排查几乎不可能发现。这也是为什么我坚持认为，没有归一化就没有排查，只有制造焦虑。
我在帮团队做数据体检时，发现重复出现的问题不是”没工具”，而是”判断错”。下面六个误区，每一个我都见过有人踩过并且付出过真实代价。
条件格式只能做精确字符串匹配。它既处理不了前导零，也处理不了 UPC-E，更处理不了”同一个码在不同店铺下不同 SKU 名”这种业务级重复。更麻烦的是，条件格式的结果无法沉淀成基线，下个月你得重做一遍。
我把这种做法叫”一次性看见”，你能看见问题，但你既不能度量它，也不能追踪它的变化。
字符串可以有大写小写、可以有空格、可以有不同长度。标识符不行。GTIN 作为一个标准标识符，它的正确形态只有一个：14 位数字，且最后一位满足模 10 校验。
一旦你在数据库里把它当字符串存（VARCHAR 而不是定长数值或专门的标识符字段），等于主动放弃了所有格式约束。很多重复问题的根因不在数据层，在建表那一刻就决定了。
这条规则在大方向上是对的，但存在明确的例外场景，如果不区分会误伤。
最后一条是最容易被误判的。很多团队看到”一个码对应三个店铺的 SKU”就判定为硬冲突，实际上这是正常经营行为，误改码反而会打乱正常的多店铺布局。
改码看起来最直接，但它的隐性成本最高。一个已经在售的 Listing 换 GTIN，会触发平台重新校验，轻则进入审核队列，重则被视为新商品，评论、排名、历史销量权重全部归零。
我见过一个卖家为了避免一个软冲突，给一个日销 200 单的链接改了码，结果链接进入审核两周，损失远超那个冲突本身可能造成的任何影响。改码应该是最后手段，不是第一手段。
SKU 是你内部的库存单元编号，可以随意设计、可以随时修改、可以一个 SKU 对应多个渠道。GTIN 是面向外部流通的标准标识，一旦商品进入市场就基本不可变。
两者混在一个字段里，最常见的结果是：当你要排查重复码时，你实际上在排查重复 SKU，方向从一开始就偏了。
UPC-E 是把 UPC-A 里有连续零的码压缩成 8 位的表示形式，它们描述的是同一个商品。如果你的数据里同时存在这两种形态，不展开就会产生大量伪唯一，你以为是两个商品，其实是同一个。
GTIN-14 同理，它可以表示箱规，也可以只是 UPC-A 补两位前导零后的标准形态。这两种含义必须通过业务字段区分，不能只看数字。
上面把问题讲清楚之后，这一节给出我实际在用的判断框架。它的结构很简单：先用四层过滤把数据洗成可比对的状态，再用三级分级把结果分成”必须处理”和”可以观察”。
目标是把所有形态的码统一成 14 位纯数字字符串。这一步不做任何业务判断，只做机械转换。
用模 10 算法重算校验位。GTIN-14 和 GTIN-12 的权重规则是奇数位权重 3，GTIN-13 和 GTIN-8 相反。这一步的产出是一个布尔标记：这个码在数学上是否成立。
这里有个容易踩的坑：校验位失效不等于这个码是假的。它可能只是录入错了。所以不要直接删除，要单独输出到待纠错队列，让人工去核对原始包装。
import pandas as pd
def normalize_gtin(raw) -> str | None:
"""把任意形态的码统一成 14 位 GTIN-14 字符串"""
if pd.isna(raw):
return None
s = str(raw).strip().replace("-", "").replace(" ", "")
全角数字转半角
s = s.translate(str.maketrans("０１２３４５６７８９", "0123456789"))
剥离科学计数法残留
if s.endswith(".0"):
s = s[:-2]
if not s.isdigit():
return None
return s.zfill(14)
def gtin_check_digit(body13: str) -> str:
"""计算 GTIN-14 的校验位，body13 为去掉校验位后的 13 位"""
digits = [int(c) for c in body13]
total = 0
for i, d in enumerate(digits):
GTIN-14/GTIN-12 规则：从左数奇数位权重 3
total += d * (3 if i % 2 == 0 else 1)
return str((10 - total % 10) % 10)
def is_valid_gtin14(gtin14: str) -> bool:
if not gtin14 or len(gtin14) != 14:
return False
return gtin_check_digit(gtin14[:13]) == gtin14[13]这一层要回答的问题是：同一个 GTIN 下的多个 SKU，在业务上是不是同一个商品。判断依据至少包括品牌、品类、型号、规格、包装数量五个维度。
我的经验是，语义层不需要做得很”智能”，用几个明确的规则字段就够。比如”同品牌 + 同型号 + 同规格 + 同包装数”视为同一商品，”同品牌 + 同型号 + 不同颜色”视为变体冲突。规则越简单越容易解释，也越容易在出问题时定位。
最后一层要看这些 SKU 处在什么状态：在售、停用、待上架、跨平台、跨站点。同样是同码冲突，一个在售链接和一个已停用链接的组合，处理优先级完全不同。
这一层还会补充一个关键信息：这个 GTIN 关联的链接有多少评论、多少历史销量。有历史权重的链接，处置策略必须更保守。
过滤完之后，把结果分成三级。分级的核心不是”重复程度”，而是”处置的不可逆程度”。
| 级别 | 判定条件 | 典型场景 | 建议动作 | 处理时限 |
|---|---|---|---|---|
| 硬冲突 | 跨 SKU 且跨平台，且至少一条在售 | 不同商品共用同一码并都已上架 | 立即评估，优先改码或拆分 | 48 小时内 |
| 软冲突 | 跨 SKU 但同平台同店铺 | 变体共用码、复制建档 | 排期修正，避开大促 | 本季度内 |
| 疑似冲突 | 同 SKU 跨平台，或已停用记录 | 多店铺铺货、历史遗留 | 记录观察，不主动处置 | 无需处理 |
把这张表和前面的漏斗图放在一起看，你会得到一个反直觉的结论：真正需要 48 小时内处理的硬冲突，通常只占原始重复清单的百分之几。剩下九成以上的精力，应该花在建立持续监控上，而不是花在逐个修复上。
四层过滤里，前两层可以完全自动化，第三、四层用规则字段实现。下面是我常用的分组判定骨架，去掉业务字段映射之后大约二十行。
df["gtin14"] = df["upc_raw"].map(normalize_gtin)
df["gtin_valid"] = df["gtin14"].map(lambda x: is_valid_gtin14(x) if x else False)
只对校验位有效的码做分组
dup = (
df[df["gtin_valid"]]
.groupby("gtin14")
.agg(
sku_count=("sku", "nunique"),
platform_count=("platform", "nunique"),
brand_count=("brand", "nunique"),
spec_count=("spec", "nunique"),
live_count=("status", lambda s: (s == "在售").sum()),
)
.reset_index()
)
def grade(row) -> str:
if row["sku_count"] <= 1:
return "正常"
if row["live_count"] == 0:
return "疑似冲突"
if row["platform_count"] > 1 and row["spec_count"] > 1:
return "硬冲突"
if row["platform_count"] > 1:
return "疑似冲突" # 同款跨店铺，正常经营行为
return "软冲突"
dup["level"] = dup.apply(grade, axis=1)
conflict = dup[dup["level"] != "正常"].sort_values(
by=["level", "live_count"], ascending=[True, False]
)
print(conflict[["gtin14", "level", "sku_count", "platform_count", "live_count"]])这个骨架的意义不在于代码本身，而在于它把”判断逻辑”从某个人的脑袋里搬到了代码里。半年后有人问”为什么这个码被判成硬冲突”，你能直接指着规则回答，而不是回答”当时是我看的”。
讲完方法论，这一节讲落地。我最近一次比较完整的排查，是用数跨境把分散在几个店铺后台和 ERP 里的商品数据先收拢，再在统一视图上做冲突判断。
重复码最麻烦的地方在于，冲突的两条记录经常不在同一个系统里。A 记录在店铺后台，B 记录在 ERP，C 记录在供应商的报价 Excel。你不可能在三个系统之间做 join。
过去我的做法是手工导出三份表，用 Excel 做 VLOOKUP，一次排查至少两天。真正卡住效率的不是计算，是数据搬运和字段对齐。
数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）在这类场景里的价值，是把多店铺、多平台的商品数据先聚到一个视图里，让”同一商品在不同系统里的记录”能在同一张表上被看到。这一步做完之后，前面的四层过滤和三级分级才有落地的位置。
我的实际用法是：先在数跨境里把商品主数据按 SKU 维度拉平，导出包含 SKU、平台、店铺、商品名、品牌、规格、状态的宽表，再把这层宽表接到自己的排查脚本上。这样脚本不需要关心数据从哪来，只负责判断。
需要说清楚的是，工具解决的是”数据在不在一个地方”的问题，不解决”该不该改码”的问题。分级规则和处置闸门仍然要你自己定义，这部分外包不出去。
那次排查覆盖了大约 4 万个 SKU，涉及三个店铺和两个站点。最终输出的处置建议表长这样：
| 冲突级别 | 组数 | 涉及在售链接 | 建议动作 | 预估人力 |
|---|---|---|---|---|
| 硬冲突 | 46 组 | 92 条 | 逐个人工评估，优先改码或隔离 | 约 12 人天 |
| 软冲突 | 183 组 | 366 条 | 批量排期修正，避开大促窗口 | 约 9 人天 |
| 疑似冲突 | 1120 组 | 约 2400 条 | 仅记录，纳入月度回归观察 | 约 1 人天 |
| 校验位失效 | ， | 1980 条记录 | 核对原始包装后重新录入 | 约 5 人天 |
这张表最有价值的信息不是组数，而是人力资源的分配比例：46 组硬冲突吃掉了 12 人天，而 1120 组疑似冲突只花了 1 人天。如果没有分级，这 1120 组会以同样的单位人力被处理，整个项目会直接卡死。
第一次做的时候，我把平台内部的商品 ID 和 GTIN 放在同一列做去重，结果产生了一批完全无意义的”重复”。平台 ID 是平台自己生成的，跟 GTIN 没有任何关系，必须分开字段存放。
停用 SKU 的记录看起来没有业务价值，但它占用的 GTIN 是真实存在的。如果不把它纳入判断，你就会在给新品分配码时”意外”撞上一个三个月前已停用的 SKU，然后在两个月后才发现。
我们第一次批量修正软冲突的时间点选在了大促前十天，结果有三条链接因为改码进入审核，错过了整个大促。修正窗口的选择比修正动作本身更影响结果。后来我把规则改成：距离任何大促不足 30 天，只允许处理硬冲突，其余全部延后。
方法论是一样的，但不同规模的卖家该做的事差别很大。下面按 SKU 规模和系统现状分四种情况给建议，你可以直接对号入座。
这个规模不需要任何自动化。你要做的是三件人工能完成的事。
这个规模最大的风险不是效率，是把”同款跨店铺”这种正常情况误判成冲突。逐条人工确认反而是最稳妥的。
这个区间是自动化的最佳切入点。人已经开始做不完了，但数据量还没有大到需要复杂架构。
建议动作是：先把数据收拢到一个统一视图（这一层可以借助数跨境这类工具完成），然后跑第四节的四层过滤脚本，输出三级分级清单。第一轮只处理硬冲突，软冲突排期，疑似冲突只记录。
这个阶段最重要的产出不是”修好了多少”，而是”建立了一份基线快照”。有了基线，从下个月开始的增量比对才有参照物。
这个规模下，重复码已经不只是数据问题，而是流程问题。你需要的不只是一次排查，而是一条常态化的流水线。
这四条里，第三条最容易被忽略，但它往往是硬冲突的最大来源。码被回收再分配，产生的是跨品类的硬冲突，比复制建档难发现得多。
有些卖家的情况是：产品由代工厂生产，包装上的 GTIN 由工厂印刷，你根本不知道这个码从哪来，也不知道有没有被印到别的产品上。
这种情况下，自动化排查只能帮你发现问题，不能根治。我建议的动作顺序是：
这个过程会很慢，可能需要一到两年，但它是唯一能把重复率从两位数降到个位数的路径，脚本做不到这件事。
知道了该做什么，还要知道不做什么。重复码处置涉及的所有动作都有代价，这一节讲四个必须权衡的取舍。
这两个动作看起来对称，代价完全不对称。
| 维度 | 改 GTIN | 改内部 SKU |
|---|---|---|
| 影响范围 | 平台侧，可能触发重新审核 | 内部系统，平台不感知 |
| 历史权重 | 可能丢失评论与排名 | 完全保留 |
| 可逆性 | 基本不可逆 | 可逆 |
| 适用条件 | 码确实错了且链接权重低 | 码正确只是内部编号冲突 |
我的判断原则很简单：如果冲突双方的链接权重都不高，改码；如果有一方是高权重链接，优先改内部 SKU 或调整另一方的码来避让。让权重低的一方承担变动成本。
平台判定同码时，可能会自动合并。合并之后你想拆开，难度远高于合并本身。所以真正要决策的是”要不要在合并发生前主动干预”。
如果两个 SKU 确实是同一商品（比如你主动做的多店铺铺货），合并对你不一定是坏事，评论可以汇总，但要接受流量集中到一个链接。如果两个 SKU 是不同商品，必须在平台动手之前处理，因为合并后的评论归属争议几乎无法申诉成功。
这个取舍经常被简化成”要不要花钱”，其实真正要比较的是维护成本。
我的建议是分工：数据接入和聚合交给工具，判断规则和处置闸门自己掌握。因为判断规则承载的是你的业务经验，这部分外包出去之后就很难再拿回来。
全量排查能给你一份干净的基线，但它的成本随 SKU 数线性增长，而且做完就开始过期。增量监控成本低、可持续，但需要一个准确的基线作为起点。
所以这不是二选一，而是有先后顺序的：先做一次全量拿基线，之后永远只做增量。我见过一些团队每季度做一次全量排查，每次都要重新梳理字段和规则，成本高、结论还不一致，这是典型的把可累积的工作做成了不可累积的。
这个取舍看起来是时间管理，实际上是风险管理。我的规则是：
这条规则的逻辑是：大促期间链接进入审核的损失是确定的，而重复码造成损失的时点是不确定的。用确定损失去对冲不确定风险，永远不划算。
回到最开始那个问题，”为什么平台会认为这是同一个产品”和”现在改码还来得及吗”。前一个问题的答案永远是数据形态问题，后一个问题的答案是业务权衡问题。这两件事必须用两套不同的手段解决，混在一起就是大部分团队卡住的原因。
我在这件事上最反直觉的一个判断是：重复码排查的正确目标不是”找出所有重复”，而是”把真正需要行动的那百分之几从噪音里挑出来”。我在一个 4 万 SKU 的样本里看到的结果是，46 组硬冲突吃掉了 12 人天，而 1120 组疑似冲突只花了 1 人天。如果你把这两者混在一起处理，项目一定会卡死。
另一个我想强调的判断是：自动化的收益不在第一次排查，而在第三次月度回归之后。双轴图里那两条曲线的交叉点大概出现在第二到第三个月，前面两个月的投入基本都在还历史债。很多团队在第一轮排查做完之后没有得到立竿见影的效果就放弃了，其实是放弃在了收益即将出现的前夜。
如果你打算这两天就动手，我建议的下一步是这样四步：
最后留一个自检清单，你可以拿去对一下自己的现状：你的 UPC 字段是定长标识符还是 VARCHAR？你的建档流程有没有强制校验唯一性？你的停用 SKU 占用的码有没有记录冷却期？你的排查结果是可累积的基线，还是每次都要从头做一遍？这四个问题里，如果有一个答不上来，那大概率就是你下一次重复码事故的入口。
我们店铺SKU有八千多个，最近后台一直提示GTIN重复，运营同事说有些是父子变体正常的，有些又真的是两条链接用了同一个码。我自己拿Excel筛了一遍，越看越乱，不知道哪些必须处理、哪些可以放着不管。
判定前必须先做标准化，否则一半以上都是假重复。第一步把所有码统一成GTIN-14口径：左侧补0到14位、去掉空格连字符和全角字符、把被Excel吞掉的前导0还原（用文本格式重新导出，或直接从ERP原始字段取，不要用复制粘贴的结果）。
第二步算校验位，GTIN最后一位是mod10校验位，算不对的多半是历史手工录入错误，这类在报错里通常占相当比例，需要单独归成一类而不是当重复处理。第三步按“标准化码+销售站点”分组，组内SKU数大于1才进入候选重复。
候选重复再分三类：父子变体共用（合规，但要确认变体主题一致、不是拿不同品类硬凑）、跨站点复用（部分站点允许，部分会判重复，要看具体市场规则）、一码多品（必须处理）。
判断依据不要只看SKU数量，还要看是否同品牌同品类、上架时间是否重叠，两条链接品类完全不同却共用一个码，几乎可以确定是历史迁移或批量导入时串了数据。
我们公司不给批采购预算，但SKU量已经涨到三万多，每周还在上新，全靠人工筛根本来不及。我想自己搭一套能重复跑的自动化方案，但不知道该从哪些数据源入手、跑完输出什么才算有用。
能，而且对三万级SKU来说自建方案比买工具更划算。数据源至少取三处：自己ERP或商品中台里的UPC字段、平台后台的GTIN报错清单、以及UPC供应商提供的已分配清单，第三处最容易被忽略，很多重复是历史运营手工改过码，只有跟供应商分配记录比对才能查出来。
处理链路用Power Query或Python pandas都行：读取CSV、统一成GTIN-14、算校验位、按码分组、标出组内成员及各自的上架时间与销量。输出固定三张表：重复组清单（含组内每条链接的关键属性，方便判断谁留谁改）、校验位错误清单、空值或未分配清单。
三万行跑一次在普通笔记本上也就几分钟，每周上新前跑一遍，再挂个定时任务每月全量跑一次。成本口径可以这样算：开发大约一到两天人力，之后每次运行成本接近于零；第三方工具通常按SKU量阶梯收费，三万SKU一年下来往往够覆盖你两三个月的人力，而且规则未必比你自己写的贴合业务。
唯一的坑是别用人工导出的Excel当唯一数据源，手工贴一次就可能再引入一批新的重复。
我们确实查出十几组一码多品的，但每条链接都有一点销量和评论，谁都不敢动。有人说改UPC会把权重清零，有人说只要不换ASIN就没影响，我实在不知道该信哪个。
原则是保住权重更大的那条，改信息最少的那个。具体排序：优先改没有评论、没有销量、上架时间最短的那条；有评论和稳定排名的保留原GTIN不要动。
改UPC本身在合规范围内是允许的，真正会出问题的是在有在途FBA库存或正在跑广告的时候改，容易触发审核甚至短暂停售，所以正确姿势是等库存清零、链接停售、广告暂停之后再改，改前把全量字段导出备份一次。
还有两个更省事的替代路径：如果两条链接本来就是同一个产品的不同规格，走变体合并而不是改码，合并后评论通常能归到一起；如果品牌已经备案，优先申请GTIN豁免，用品牌加型号做唯一标识，以后就不用再买码，也不会再出现买到的码被别人用过这种被动局面。
判断依据很简单，你改码的目的不是让报错消失，而是让每条链接对应唯一一个真实商品，凡是达不到这个目的的改动都是白改。
我们上次做了一次全量排查，结果吐出来一千多条疑似重复，运营看了一天就放弃了，最后一条都没处理。我不想再做一次无效的大扫除，想知道频率和阈值到底怎么设计才跑得动。
频率建议三层：上新前必跑做前置卡点，这是性价比最高的一层，拦住一条错码比事后修十条便宜；每月全量跑一次做体检；大促或换季前再全量跑一次，因为这两个节点前后批量导入操作最多，最容易串码。阈值用两个指标看：重复组占比超过0.5%就先暂停上新，回头查根因，通常集中在某几个运营或某一次批量导入；
校验位错误率超过0.1%说明录入环节有系统性漏洞，要在商品创建页面加前端校验，让错码根本进不来。
人工复核比例必须控制住，你那一千多条的问题不是规则太严，而是没做分级，把结果分成“确定错”（校验位算错、一码跨品类）和“疑似”（同品牌跨站点、父子变体边界情况）两档，确定错的直接批量处理，疑似的每天排两百到三百条人工过，超过这个量说明规则太松，要回头收紧而不是加人。
别追求百分之百自动化，最后一公里的人工判断往往比调规则更快，而且这些判断会反过来变成你下一版的规则。
读者评论
归一化到14位这一步在实际操作里也有坑。如果原始字段没区分单品码和箱码，统一补零会把GTIN-14箱码和UPC-A单品码强行对齐，反而制造出新的伪重复。我遇到过供应商报价单里混着箱规码，补位后和另一个单品码只差包装层级，脚本直接报硬冲突。建议归一化前先加一列包装层级标识，否则漏斗第一层就可能把噪音放大。
校验位复算确实能抓录入错误，但它只能证明码格式合法，不能证明归属唯一。从二手码商买的码段每个码校验位都是对的，照样可能被卖给多个买家。所以把校验位当成最高性价比过滤器要分场景，码源不干净时它更多是筛掉手工录错，对核心的结构性重复帮助有限。真正难的是判断两个SKU是否同一物理商品，这得靠品牌、型号、规格的语义比对。
月度回归的思路我认同，但小团队落地时维护基线快照和增量映射表本身就要成本。如果供应商和SKU变动频繁，每月新增脏数据可能比历史还多。另外平台自动合并前通常只发站内信，卖家未必及时看到，等发现时申诉窗口已经很短。比起事后回归，更实际的是在上架环节加一道码校验闸门，从源头挡住复制建档和供应商随手附码。