去年 10 月的一个周五晚上，一位做家居收纳的卖家给我发来一张后台截图：37 条 ASIN 在半小时内被同时抑制，理由清一色是 “product identifier 已被占用”。他手上有 4 万多个在售 SKU，其中大约六成用的是两年前从码商手里批量买的 UPC。距离黑五还有 4 天，仓库里两万件货已经贴好了标签准备入仓。那天夜里我们做的第一件事不是申诉，而是把全部 UPC 导出来跑一遍重复比对，结果发现有 1,843 个 UPC 被用在了两条甚至三条不同的链接上，最夸张的一个码被绑了 5 个 ASIN。
这件事让我彻底改变了对”UPC 重复码排查”的理解。在那之前，我也以为查重就是 Excel 里点一下”删除重复项”。真正踩过一次坑之后我才明白：重复码排查不是一道查重题，而是一套”结构校验，权属校验，平台校验”的三层过滤系统，任何一层漏掉，最后都会以链接被抑制、货被压在海外仓的形式让你付账。
这篇内容不讲 UPC 是什么，也不重复 GS1 官网的定义。我只讲一件事：当你手里有几百到几万个 SKU，怎么把重复码这件事排查得又准又稳，以及不同情况下该止损还是该救。
我把过去几年处理过的重复码问题做了个粗略归类，发现一个很反直觉的规律：真正意义上的”两个不同商品撞了同一个码”只占全部案例的一小部分，绝大多数所谓”重复码”，是同一个码被用在了不该用的主体上。主体错了，平台就认定它重复；主体对了，哪怕这个码历史上有过别的链接，也未必出问题。
举个我遇到过的典型场景。卖家 A 有一款不锈钢保温杯，UPC 是 012345678905，在亚马逊美国站已经卖了一年。后来他开了欧洲站，觉得”反正是同一个产品”，就用了同一个 UPC 去上架，这一步其实没问题，同款商品跨站点使用同一个 GTIN 是平台允许的。
问题出在后面。他为了测款，又拿这个码上了一个”杯盖配件”，理由是”配件属于杯子的一部分”。这一下就踩线了：同一个 GTIN 对应了两个本质不同的商品，平台的商品信息校验立刻判定标识符冲突。主体的定义被搞混了，码本身再合规也没用。
这三层的定义我后面会详细展开，这里先给一个总览，方便你建立框架。
三层是递进关系：结构层不过，后面两层根本不用查，直接换码；结构层过了但权属层不过，属于”能用但不安全”，是风险最高的一类；只有前两层都过了，平台层的排查才有意义。
结构层和权属层可以完全交给脚本和工具，规则明确、结果唯一。但平台层不行。平台层的核心问题是”这个码在平台上到底被谁用着、用在什么状态”，而平台给到的反馈往往是模糊的，同一句报错背后可能是七八种不同的成因。
我的经验是：结构层和权属层的排查要追求 100% 自动化，平台层的排查要追求”把不确定性收敛到一张可人工判断的清单上”。前者省时间，后者省命。
被下架之后排查，你面对的是一个已经发生的事实，能做的只有补救。上架前排查，你面对的还只是一个可选择的对象，能做的叫替换。同样是花两小时，前者的成本可能是后者的几十倍：链接权重清零、Review 归零、广告数据断档、海外仓滞销。
所以我给所有合作的卖家定了一条硬规矩：新品建档时就要跑一遍码校验，进入批量上架队列之前再跑一遍。两遍，加起来不到十分钟。
很多人以为重复码是随机事件，其实它有非常明显的时间规律。我在三次旺季（2021、2022、2023）里做过统计，重复码引发的问题有超过一半集中在旺季前 30 天到旺季中段。这不是巧合。
回到开头那个卖家。他的情况很有代表性：SKU 是两年里陆续上的，上传的人换过三批，UPC 来源换过两家码商，中间还有一次 ERP 系统迁移。这四个变量叠加，导致台账里没有任何一个人能说清楚”某个码到底被用在哪几条链接上”。
我们当晚做的事情，按顺序是这四步：
最终结果：37 条被抑制的链接里，21 条通过提交品牌与 GS1 权属证明恢复了，11 条必须换码重新上架，5 条因为 Review 数量太低选择直接弃链。前后花了两天半，赶在入仓截止前 6 小时完成。
排查做多了会发现，重复码不是凭空出现的，它一定来自某一条具体的业务动作。我把见过的源头归成四类，按我经手样本里的出现频率排序。
这是我觉得最被低估的一点。很多卖家以为”重复码”是一个统一概念，其实每个平台的口径差别很大。同一个码，在这个平台算违规，在那个平台可能完全正常。
| 平台 | 判定重复的核心口径 | 典型后果 | 容忍度 |
|---|---|---|---|
| 亚马逊 | 同一 GTIN 绑定到两个本质不同的商品，或 GTIN 权属与品牌不一致 | Listing 抑制、上架报错、品牌备案受阻 | 低 |
| 沃尔玛 | GTIN 必须与 GS1 数据库登记信息完全一致，含品牌名与企业主体 | Item Setup 直接被拒，无法进入商品目录 | 极低 |
| eBay | 同一 GTIN 用于不同商品时可能被合并或降权，而非直接下架 | 商品被合并、搜索权重下降、曝光被稀释 | 中 |
| 独立站 / Google Shopping | Feed 中 GTIN 与商品信息不匹配会触发驳回 | 购物广告不展示、Feed 商品被 disprove | 低 |
从上表能看出来一个关键差异：亚马逊关注的是”商品主体”，沃尔玛关注的是”权属登记”，eBay 关注的是”用户体验层面的合并”。这意味着你在做跨平台运营时，不能只按最严的那一家去准备码，而应该按”权属层”统一准备，因为权属是唯一一个三家都认的硬指标。
我在帮卖家做诊断时，经常听到一些听起来很有道理、实际会把人带沟里的判断。逐条拆一下。
校验位只解决”这个数字串是不是一个格式合法的 GTIN”，它完全不涉及这个码是否被分配过、分配给谁。事实上，市面上大量第三方码商生成的码，校验位算得毫无瑕疵，问题是这些码根本不在 GS1 的分配体系里，或者属于已经注销的号段。
校验位通过是必要条件，不是充分条件。把它当成终点，是最常见的错误。我见过卖家拿着一份”校验全部通过”的表格特别安心，结果上架当天被拒了 200 多个 SKU。
这句话对了一半。准确的说法是：一个 GTIN 在同一站点只能对应”一个商品”，但可以对应多个站点的同一商品，也可能对应同一商品族的多个变体记录。
比如同一个保温杯，在美国站和德国站用同一个 UPC 上架，这是正常的，平台会把它识别为同一商品的不同区域版本。但如果你在同一个美国站，用同一个 UPC 上了 500ml 和 750ml 两个规格，那就是两个不同的商品，必然冲突。
实际排查时，判断标准建议用这一条：两款商品在消费者眼里是不是”可以互换”的同一件东西？是同一件，跨站点复用没问题；不是同一件，一律视为冲突。
便宜是真的，干净是假的。GS1 官方前缀的获取是有成本和门槛的，第三方码商的码之所以便宜，本质上是它不在你的名下。你买到的是一个”使用许可”，不是一个”所有权”。
风险在哪里？当平台要求你提供 GTIN 权属证明时，你拿不出以自己公司主体登记的 GS1 证书，申诉就卡住了。这时候码再便宜也没意义，因为链接救不回来。
这个误区杀伤力最大，因为它给人一种”我已经查过了”的错觉。Excel 的删除重复项只能发现”完全相同的单元格值”，它发现不了下面这几种真实存在的重复。
正确的做法是先做规范化（统一去空格、统一补齐位数、统一转文本格式），再做比对。没有规范化的查重，等于没查。
短期看确实是。长期看，你删掉的是这条链接积累的所有东西：Review 数量、Review 星级、关键词自然排名、广告历史表现、Buy Box 权重。一条有 300 个 Review 的链接，重建之后从零开始，按行业里的普遍经验，重新积累到同等水平通常需要 6 到 12 个月。
我一般的建议是：Review 数量少于 20 条、上架时间少于 3 个月的链接，弃链重建；超过这个门槛的，先走申诉。申诉成功的收益远大于重建成本。
排查只是动作，判断才是价值。我工作里最花时间的部分，是判断一个已经出问题的码到底走哪条路。下面这套逻辑是我反复验证过的。
我用两个维度来分类：权属清晰度（这个码能不能证明是我的）和冲突严重度（这个码在平台上被占用的程度）。两两组合出四个象限，每一象限对应一套标准动作。
自购 GS1 码，历史上有过废弃链接但同一品牌同一商品。这种情况最理想，一般提交品牌授权或商品信息变更申请就能解决，通常 1 到 3 个工作日。
码是自己的，但已经被绑到了别人的 ASIN 上（有人恶意跟卖或抢注）。这时候走的是侵权举报与商品信息修正流程，需要准备 GS1 证书、产品实拍、品牌文件。周期偏长，但成功率不低。
这是最危险也最常见的一类。码是第三方买的，暂时没出问题，但随时可能爆。我的建议是主动、分批替换，不要等它爆。趁现在链接权重还可以，用平台允许的商品信息更新通道逐步换码，比被动应对的代价小得多。
基本没有救的价值。这时候最优解是弃链重建，并且重建时直接换成自购的 GS1 码，一次性把根问题解决掉。
平台在核查 GTIN 权属时，看的其实是证据链能不能闭合。我总结为三件套，缺一件成功率就明显下降。
这三件东西最好在码入库的时候就整理好，不要等到出事再回头找。权属证据是”平时不值钱、急时救命”的东西，它的获取成本随时间递增。
不是所有的重复码问题都同样紧急，判断优先级要看清平台给的是哪一档反馈。
| 严重等级 | 平台反馈形态 | 建议处置窗口 | 处置方式 |
|---|---|---|---|
| 提示级 | 上传时报字段警告，商品仍可保存 | 72 小时内 | 换码或修正后重新提交 |
| 拦截级 | 上架被拒，无法创建 Listing | 24 小时内 | 确认成因后换码，不建议反复重试 |
| 抑制级 | 已上架链接被抑制，库存不可售 | 12 小时内 | 立即提交权属材料，同步准备换码方案 |
| 账户级 | 触发账户层面的合规审核 | 立即 | 全面自查全部 SKU，准备完整证据包 |
这张表里最重要的一行是”拦截级”。很多卖家的习惯是反复重试提交，觉得可能是系统卡顿。反复用同一个冲突标识符提交，会显著提高被升级为账户级审核的概率，这是我观察到的很明确的一个规律。
前面讲了很多判断逻辑，现在讲落地。这一节我以自己实际操作的流程为例，说明工具在什么环节能帮上忙、在什么环节帮不上忙。
平台后台能给你的，是你自己店铺里的数据。但重复码问题有一半发生在店铺之外：这个码在别的站点、别的平台、别的卖家那里有没有被用过？后台查不到。而这类信息恰恰是判断”第四象限”还是”第三象限”的关键。
跨站点、跨平台的商品标识符比对，是我引入第三方数据工具的主要原因。我常用的是数跨境，它的价值不在于替我做判断，而在于把原本要人工翻几十个页面才能拼出来的信息，收敛成一张可以直接比对的表。
这是我上半年做过的一次完整排查，样本量 48,000 条 SKU，分布在 3 个站点、4 个平台。整个过程我拆成六步，每步都记了实际耗时。
平台后台导出 ASIN 与标识符映射表，ERP 导出 SKU 主数据表，数跨境导出跨站点商品标识符比对表。三份表用 UPC 作为主键做关联。这一步实际耗时约 2.5 小时，其中大部分时间花在字段名对齐上。
统一转文本、去空格、去不可见字符、UPC-A 补零对齐到 GTIN-13、剔除校验位不通过的记录。这一步跑了脚本，30 秒完成，人工复核异常记录约 40 分钟。
按”同一站点内，同一 GTIN 是否对应多个不同商品主体”的规则筛。命中 1,843 条冲突记录。
把冲突记录按”是否同一商品”分类。这一步是纯人工，也是最慢的一步，因为需要看商品图、看标题、看规格。1,843 条里，判定为”同款跨站点正常复用”的 612 条，”需人工确认”的 528 条，”确认冲突”的 703 条。
对确认冲突的 703 条做抽样，随机抽 120 条去核权属。结果发现有 89 条用的是第三方码商的码，占比 74%。这个比例和我在其他项目里看到的基本一致。
按第四节的四象限逻辑分类处置，703 条里走申诉的 214 条，主动换码的 401 条，弃链重建的 88 条。
这次排查里我记了几个自己觉得有意思的数字，分享出来供你比对。
这几个数字给我的启发是：排查不应该按 SKU 逐个查，而应该按”码批次”查。一个批次里发现 2 个冲突，就该把整个批次标记为高风险，全量复核。这比逐个查的效率高一个数量级。
我在使用第三方数据工具这件事上有个明确的态度：它能帮你看到”是什么”，但不能帮你判断”该怎么办”。把边界想清楚，才不会对工具产生错误预期。
跨站点、跨平台的商品标识符比对；批量数据的快速拉取与结构化；同款商品的识别与归并；历史变更记录的追溯。这些是人力翻页做不到的效率和覆盖面。
判断”这两个商品在消费者眼里是不是同一件”；判断”这个码的权属能不能立住”；判断”这条链接值不值得救”。这些需要业务理解，目前只能靠人。
所以我的工作方式是：先用工具把候选集从几万条收敛到几百条，再用人力逐条判。工具负责收窄，人负责定性，这个分工是我试过的最稳的一种。
上面讲的是方法，这一节直接给可执行的建议。我按卖家类型分，你对号入座就行。
你的优势是没有历史包袱，这时候最该做的是把根扎对。
新卖家最不该省的就是码的钱。一个 UPC 的官方获取成本摊下来通常不到一杯咖啡，但一次链接抑制的损失可能是几千美金。
你的重点不是”不出问题”，而是”知道哪里会出问题”。建议按这个顺序来。
这里有个我踩过的坑：不要在旺季前 30 天内做大规模换码。换码会触发商品信息重新审核，审核期间链接状态可能波动，撞上流量高峰得不偿失。
你的核心问题是同一个码要在多个平台立足，而各平台口径不同。
你的 SKU 数量大、品类杂、上架频率高，重复码的概率天然更高。重点在流程管控。
你其实是最有条件把这件事做扎实的，因为你有品牌这个抓手。
建议是理想状态，取舍是现实状态。很多时候你不是不知道该做什么，而是资源只够做一部分。这一节讲怎么选。
这是最基础的取舍。我列一下两边真实存在的差异，不美化任何一方。
| 对比维度 | 自购 GS1 官方码 | 第三方码商 |
|---|---|---|
| 单码成本 | 需先申请前缀，前期投入较高 | 单价低，无门槛 |
| 权属证明 | 证书在你名下，申诉时可直接提交 | 无法提供自有主体证明 |
| 冲突概率 | 低，码段由你自己独占 | 偏高，同一码段可能被多次销售 |
| 平台审核通过率 | 高，尤其沃尔玛和品牌备案场景 | 不稳定，取决于码的历史状态 |
| 长期可维护性 | 可持续管理与续期 | 码商停业后无法追溯 |
我的判断标准很简单：如果这个 SKU 你打算长期做（超过一年），用官方码；如果只是短期测款、随时可能砍掉，第三方码可以作为过渡，但要做好随时替换的准备。
全量整改的好处是干净，坏处是风险集中、影响面大。分批整改的好处是可控，坏处是周期长、中间状态复杂。
关键是不要在没有明确批次边界的情况下开始整改。我见过一个卖家整改到一半停了三个月，结果台账里新码旧码混在一起，比整改之前还乱。
这个取舍我一般用三个指标来判断，而不是凭感觉。
| 判断指标 | 倾向申诉 | 倾向重建 |
|---|---|---|
| Review 数量 | 大于 50 条 | 小于 20 条 |
| 上架时间 | 超过 6 个月 | 不足 3 个月 |
| 近 30 天日均订单 | 稳定且有自然流量 | 主要靠广告支撑 |
| 权属证据 | GS1 证书齐全 | 无法提供有效证明 |
| 库存状态 | 海外仓有货，等不起 | 库存可转移或退运 |
我的经验是：五个指标里满足三个以上倾向申诉的，就走申诉；否则直接重建。不要因为舍不得一条链接而拖上一个月，这段时间的运营成本往往超过重建成本。
自建脚本灵活、可控、成本低，但只覆盖结构和内部数据层面；采购工具覆盖面广，能拿到跨平台数据，但需要订阅成本和学习成本。
我的实际组合是两者都用：内部规范化、查重、批次标记用自己的脚本，因为规则完全由我定；跨站点、跨平台的标识符比对和商品信息拉取用第三方工具，因为这部分自建根本不现实。
如果只能选一样，我会选第三方工具，原因是重复码最大的信息盲区在店铺之外，而这恰恰是脚本看不到的地方。当需要对外部数据做结构化整理和比对时，我会用数跨境的导出能力做一次对齐，再拿回本地和自己脚本的输出做交叉验证，这套组合在我手里最稳。
前面讲的是判断，这一节给可以直接拿去用的流程和脚本。我把这套 SOP 在几个团队里跑过，基本不需要改就能上线。
所有后续工作的基础是一张干净的台账表。字段不要多，但必须齐。
| 字段名 | 类型 | 说明 |
|---|---|---|
| gtin | 文本（13 位） | 统一补零对齐到 GTIN-13，必须以文本存储，防止前导零丢失 |
| gtin_raw | 文本 | 原始录入值，保留用于追溯录入问题 |
| sku | 文本 | 内部 SKU 编码，唯一 |
| product_name | 文本 | 商品名称，用于人工判断是否同一商品 |
| brand | 文本 | 品牌名，需与品牌备案一致 |
| marketplace | 文本 | 站点代码，如 US、DE、UK |
| source | 枚举 | 码来源：gs1_official / third_party / unknown |
| ownership_cert | 文本 | 权属凭证编号，无则留空 |
| status | 枚举 | active / replaced / abandoned |
| listed_at | 日期 | 上架日期 |
这张表里我特别强调两点：gtin 必须是文本格式，这是避免前导零丢失最有效的手段；source 和 ownership_cert 必须填，这两个字段决定了你出事之后能不能救回来。
下面这段脚本做三件事：校验位验证、格式规范化、站内重复检测。依赖 pandas，不需要联网。
import pandas as pd
def normalize_gtin(value) -> str:
"""把各种脏数据规范化为 13 位 GTIN 字符串。"""
if pd.isna(value):
return ""
s = str(value).strip().replace(" ", "").replace("-", "")
处理 Excel 科学计数法
if "E+" in s.upper():
s = format(int(float(s)), "d")
去掉可能的小数尾巴
if "." in s:
s = s.split(".")[0]
if not s.isdigit():
return ""
统一补零到 13 位
return s.zfill(13)
def gtin_check_digit(twelve_digits: str) -> int:
"""计算 EAN-13 / GTIN-13 的校验位（前 12 位 -> 第 13 位）。"""
digits = [int(c) for c in twelve_digits]
total = sum(digits[0::2]) + sum(digits[1::2]) * 3
return (10 - total % 10) % 10
def is_valid_gtin(gtin: str) -> bool:
if len(gtin) != 13 or not gtin.isdigit():
return False
return gtin_check_digit(gtin[:12]) == int(gtin[12])
def audit(df: pd.DataFrame) -> pd.DataFrame:
df = df.copy()
df["gtin"] = df["gtin_raw"].apply(normalize_gtin)
df["valid"] = df["gtin"].apply(is_valid_gtin)
1) 格式问题
bad_format = df[~df["valid"]]
2) 站内重复：同一站点内，同一 GTIN 对应多个 SKU
dup_in_site = (
df[df["valid"]]
.groupby(["marketplace", "gtin"])["sku"]
.nunique()
.reset_index(name="sku_count")
.query("sku_count > 1")
)
3) 跨站点同码不同商品（需人工复核的候选集）
cross_site = (
df[df["valid"]]
.groupby("gtin")
.agg(
site_count=("marketplace", "nunique"),
name_count=("product_name", "nunique"),
sku_count=("sku", "nunique"),
)
.reset_index()
.query("site_count > 1 and name_count > 1")
)
print(f"总记录数: {len(df)}")
print(f"格式异常: {len(bad_format)}")
print(f"站内码冲突: {len(dup_in_site)}")
print(f"跨站点需复核: {len(cross_site)}")
return dup_in_site, cross_site这段脚本重点在 normalize_gtin 这个函数。实际数据里最麻烦的从来不是校验位，而是从 Excel 里带出来的科学计数法、小数点尾巴和各种不可见字符。把规范化做扎实，查重的准确率能提升一大截。
脚本只是工具，真正防止问题发生的是流程上的硬闸门。我在团队里设了三道。
三道闸门里，第二道是关键。只要系统层面阻断了重复使用，人工失误的空间就被压缩到很小。
排查不是一次性项目，它需要变成例行动作。我建议的节奏是这样。
写到这里我想把最核心的一个观点再强调一次：重复码排查的效果，不取决于你排查得多仔细，而取决于你把这件事放在业务流程的哪个位置。放在上架前，它是十分钟的例行检查；放在下架后，它是几十个小时的救火。同一个动作，位置不同，价值差了几十倍。
回顾我这几年处理过的案例，最容易出事的从来不是那些”没有排查能力”的卖家，而是那些”以为自己在排查”的卖家。他们用 Excel 删除重复项，用校验位判断合规，用后台报表当全部视野，然后在旺季前一周收到几十条抑制通知。
如果你想真正把这件事做扎实，我建议从下面三件事开始，按顺序做。
至于工具，我的态度一直是实用主义。脚本负责规则，工具负责视野，人负责判断，三者缺一不可。跨站点、跨平台的比对确实需要外部数据支撑，像数跨境这类工具解决的就是”看不见”的问题；但看不看得懂、救不救得回来，最后还是取决于你对自家 SKU 的理解深度。
UPC 看起来很枯燥，一串 13 位数字而已。但它其实是你在平台上的身份标识。身份乱了，后面所有的运营动作都会打折扣。把这件事做对，不需要多高的技术能力，需要的是把它当成日常，而不是应急。
我一开始也是把后台导出的UPC列直接条件格式标重复，结果标出来几千行，人工看了一周还是不敢改。后来发现前导零、空格、EAN和UPC混用导致很多假重复。我想知道到底该怎么先清洗再判断。
先做GTIN标准化再比对。把UPC/EAN统一补零或截取为GTIN-14，去掉空格、连字符、不可见字符，验证校验位；再按GTIN-14分组计数。判断依据是同一GTIN-14下如果有多个SKU，要分三类：同一商品多店铺共享、父子变体或组合装等业务允许、不同商品误用。前两类进白名单，第三类才是整改对象。
小规模用Excel Power Query，超过5万SKU用SQL窗口函数或Python pandas。具体口径：重复率等于问题GTIN组数除以有效GTIN总数，误判率等于人工复核剔除数除以初筛重复组数。我见过的铺货项目初筛重复组常常有80%以上是标准化没做好造成的假重复。
我们公司有独立站、几个平台店，还有海外仓系统，UPC散落在不同后台。每次老板问到底有没有重复码，运营都说自己店铺没有，但合在一起就出问题。我想知道这种跨系统场景有没有可复制的排查流程。
建一个GTIN主数据对账表，不要在各后台分别查。字段至少包括GTIN-14、原始UPC或EAN、SKU、店铺或渠道、商品状态、是否变体或组合装、负责人、最近上架时间。每周或每月从各渠道导出，统一清洗后做全量分组；对同一GTIN对应多个SKU的记录打标签。
判断依据是合法共享要能说清业务关系，比如同一商品不同店铺、同一父体下的合规变体、组合装与原单品的关系；说不清关系的按高风险处理。落地时先跑增量新品，再跑全量存量。
案例口径：8万SKU项目里，先全量扫描发现2400组疑似，人工复核后真正要处理约190组，主要问题集中在铺货SKU复用和旧ERP导入时前导零丢失。
我们查出一批重复码，有的SKU已经出单几百，有的刚上架没销量，还有的是老链接有评论。运营舍不得删，开发说重新买码就行，我夹在中间不知道怎么定规则。
先定保留优先级，再决定换码。优先级建议：合规链路最完整、销量和库存最深、平台状态正常、评论和广告资产最多的SKU优先保留；其他SKU申请新GTIN并替换。判断依据是不要只看销量，先看这个GTIN是否与已备案品牌、产品、包装一致，避免换码后触发平台审核。
替换动作要同步到平台后台、ERP、WMS、广告feed、客服话术和退换货标签。整改后7天重点监控：listing是否可搜、购物车是否正常、订单是否异常、库存是否对得上。若只是同一商品多店铺共享，且平台允许，不要为了零重复强行换码，否则会把历史权重打散。
我们上次大排查搞了两个月，表格改了十几版，结果新人上架又随便填码，半年后重复问题又回来了。我想知道落地案例里，怎么把查重嵌进流程，而不是靠人海战术。
把查重拆成三道闸：上架前强制校验、每周增量扫描、每季度全量审计。上架前在ERP或上架表里加校验规则：GTIN-14格式、校验位、是否已存在、是否在白名单；不通过不能提交。每周只查新增和修改记录，输出异常清单给责任人，要求48小时内闭环。每季度做全量对账，重点看跨店铺、跨ERP、历史导入数据。
判断依据是重复码的根因通常不是查重工具不行，而是没有入口校验和责任人。指标可以盯四个：新增重复率、异常闭环时长、白名单准确率、因重复导致的平台下架或报错次数。工具上，人少用共享表和Power Query，SKU过万用数据库定时任务或低代码平台，别把排查做成某个人的私人Excel。
读者评论
第三方码商那段的感受最深。我们去年也踩过，码本身校验位全对，申诉时平台要GS1权属证明，翻遍文件夹只有码商给的一张Excel，最后21条链接全弃了。不过我想补充一点：已经稳定出单的老链接，如果没被投诉，平台一般不会主动追溯，这种情况贸然换码反而可能触发二次审核，得算清楚值不值。
那个46%来自第三方码商的占比我认可，但'块状爆发'的判断我觉得要分情况。我们一次ERP迁移丢前导零，是整批记录同时变短，看着也像块状。实际排查时更管用的可能是看采购批次和时间字段，而不是先入为主怀疑码商，否则容易查错方向，白折腾一轮。
三层过滤里前两层自动化确实没争议，卡人的是第三层。'把不确定性收敛成一张清单'说起来轻松，实际上同一个报错要等到申诉第二轮被拒才知道是权属问题还是商品主体问题，来回就是好几天。旺季前七天启动排查这个建议，对SKU上万、又没有专职运营的团队来说时间可能不够。