核心结论：重复 UPC 不是数据脏，而是协同链条断了
先把结论摆在最前面，因为它决定后面所有动作的方向：UPC 重复码绝大多数不是“数据录入失误”，而是团队协同没有卡点。同一家公司里，运营在表格里建 SKU、采购在供应商那拿码、美工在上架时填码、财务在后台对账，四个环节各自都觉得自己没做错，重复码就长出来了。
我在过去三年里参与过十几次跨境店铺的 UPC/GTIN 数据体检，规模从 300 个 SKU 到 2 万多个 SKU 都有。让我印象最深的一次，是某家居类目卖家 1600 个 SKU 里查出 42 组重复 UPC，其中 7 组导致了实际后果：4 条 listing 被平台合并变体、2 条直接被压制流量、1 条被判“重复刊登”后强制下架。他们内部的第一反应是“赶紧把重复的改掉”，但我坚持先做一件事，把责任环节画出来。
结果发现，42 组重复里只有 5 组来自录入错误，其余 37 组全部来自流程性缺口。
我习惯把重复码分成三类，这个分类方式决定了你后面用什么样的工具去查、用什么样的机制去防。
第一类是源头型重复：供应商或第三方码商把同一个 UPC 卖给了多个买家，或者同一个码在同一个码库里出现了两次。这类重复的特点是“你查自己查不出来”，必须做跨主体核验。第二类是流转型重复：码本身没问题，但在流转过程中被复制、被复用、被错误继承，例如变体关系设置错误、模板批量填充时下拉复制、ERP 导入时字段错位。第三类是回流型重复：已经废弃的码被重新启用，比如老链接下架后码被回收再用，或者 GS1 前缀到期后没有更新证书。
三类的解法完全不同：源头型要靠码源合法性和跨方核验，流转型要靠流程卡点和校验脚本，回流型要靠生命周期台账。把三类混在一起用一个“去重函数”解决，是我见过最普遍的无效努力。
我见过很多团队做重复码排查，方式是“拉一个群，大家一起来对”。这种方式在 200 个 SKU 以内有效，超过 500 个就必然崩。原因很简单：多个人同时改一张表，等于没有人在负责。
我的做法是把排查收敛成两个硬约束。第一个约束是唯一责任人：每一个 UPC 从申请到上架到废弃，全生命周期只有一个责任人字段，谁改谁签名谁写时间戳。第二个约束是可追溯链路：任何一次修改都要能回答“谁在什么时候因为什么原因把哪个码从 A 改成了 B”。
这两个约束听起来像管理问题，实际上是技术问题。因为在没有校验位算法和唯一性约束的前提下，你根本无法判断一次修改是对的还是错的。所以我会把校验位算法直接写进流程卡点里，让系统在写入前就拒绝错误码，而不是靠人事后检查。
这句话是我这几年最核心的判断。团队协同在数据治理里的定义，不是沟通频率，而是“错误在哪个节点被拦住”。你可以每天开一次对齐会，但如果错误码是在上架后三天才被发现，那这次协同就是失败的。
我建议的目标是：重复码必须在上架动作之前被拦截，而不是在上架之后被修复。上架后的修复成本是上架前的 5 到 20 倍，因为它牵扯到已经积累的评论、已经投放的广告、已经建立的变体关系，甚至已经发出去的货。
为了让你对“成本”有体感，我把一个真实案例的时间线完整还原出来。这个卖家做的是家居收纳类目，主站加两个区域站，总共 1600 个活跃 SKU，团队 11 个人，运营 4 个、采购 2 个、美工 2 个、客服 2 个、负责人 1 个。
事件起点很平常：供应商上游工厂更换了一批产品包装，包装上的条码变了，供应商就把新的码表发给了采购。采购拿到码表后，直接在表格里替换了对应 200 多个 SKU 的 UPC 字段。
问题出在这 200 多个码里，有 9 个是和另一个品类共用的，因为供应商在整理码表时，把 A 品类的码复制到了 B 品类行。采购没做校验，运营没做校验，美工上架时照着填。三周后，平台上出现了 9 组“同一 UPC 对应两条不同 listing”的情况。
接下来是连锁反应：平台先合并了其中 4 组变体，导致这 4 条 listing 的评论被错误地挂到了另一个产品上；然后另外 3 条 listing 被判定为“重复刊登”，搜索权重断崖式下跌；最后 2 条直接被下架，需要提交申诉材料。整个处理过程横跨了 19 天，涉及 6 个人，光是申诉资料整理就花了 3 个人天。
我做过一个简单的效率测试：让一位熟练运营用 Excel 手动核对 2000 行 UPC 的唯一性，允许她使用条件格式高亮重复项。结果是：首次核对耗时 47 分钟，漏检 3 组；复核第二遍耗时 31 分钟，又漏检 1 组。漏检的原因不是她不认真，而是重复项分布在不同的工作表里，且存在前后空格、全角半角、以及 11 位与 12 位混排的格式差异。
这个测试说明一件事：人工核对的准确率不是随 SKU 数量线性下降，而是在某个规模点上断崖式下跌。我的经验阈值是 800 到 1200 之间，超过这个区间，人工抽检的漏检率会从个位数跳到 15% 以上。
顺着上面的案例往下挖，我发现重复码的产生总是集中在三个交接点上，这三个点也是我后来做任何排查方案时的固定检查项。
这一节我想说得具体一点，因为下面这五个判断，我在不同团队里反复听到，而且每一个都会直接导致后续动作走偏。
这是最危险的判断。重复码的后果分四个层次，删链接只能解决第一层。
第一层是重复刊登本身，删掉一条就没了。第二层是评价资产错位，平台的变体合并机制可能已经把 A 的评论挂到了 B 上，删链接会把评论一起带走。第三层是库存与财务错配，重复码会让两个 SKU 共用同一批库存映射，导致库存数字虚高或虚低。第四层是合规风险，部分平台对 GS1 合法性有审核机制，如果重复码来自不合法码源，问题会从“运营事故”升级成“账号风险”。
我的判断是：一旦确认重复码已经产生过实际交易，处理动作就不能只考虑链接，必须同步做库存核对和评价核对。
校验位只是防打字错误的，不是防重复的，也不是证明所有权的。一个 12 位数字只要第 12 位符合算法，就能通过校验，但这和它是不是你的、有没有被别人用、前缀是不是你公司注册的，完全没有关系。
更关键的是，很多第三方码商在批量生成码时，会故意生成校验位正确的码，因为它们本来就是按算法批量生成的。所以“校验通过”这个信号的信息量，远低于很多人的预期。真正有信息量的信号是：码的 GS1 前缀是否归属你的公司主体。
我理解成本压力，一个正式 GS1 前缀的年度费用和一次买几千个第三方码的费用差好几倍。但这个账要算全。
第三方码库的核心风险不是“码是假的”，而是“码不是独有的”。你不知道同一批码被卖给了多少买家，也不知道其中有多少已经被用在别的平台、别的类目、别的国家。这种风险在平时完全不显形，一旦触发就是平台层面的合规审核，处理周期通常以周计。
我的经验判断是：如果一个 SKU 的年毛利低于 500 元，用第三方码的风险收益比或许还能接受；一旦单品年毛利超过 2000 元，自购 GS1 前缀的确定性收益就明显更高。因为事故成本是集中释放的，不是分摊的。
这是流转型重复里最隐蔽的一类。很多团队在设置颜色、尺寸变体时，为了图省事，让所有子 SKU 共用父 SKU 的 UPC。在某些平台的某些类目下，这确实能跑通；但一旦平台规则调整，或者你需要拆分变体、单独做广告、单独做库存管理，就会立刻出问题。
我的做法是：子 SKU 必须有独立的、可验证的 UPC 或 GTIN，父 SKU 不占用码。这条规则写进 SOP，比事后补救便宜得多。
这个误区最普遍，也最容易被忽视。负责人说“这件事交给小王”，但没有给小王脚本、没有给模板、没有给固定的时间块。小王只能在主业之外抽时间做，做两轮就停了，因为没有反馈、没有指标、没有闭环。
我的判断是：重复码排查必须是一个有固定节奏的流程，而不是一个项目。项目会结束，流程不会。我通常建议的节奏是：新品上架前全量校验，存量数据每月抽检 20%，季度做一次全量。
发现重复码之后，最忌讳的是“一律按最高优先级处理”。因为资源是有限的，全部拉满等于没有优先级。我用的是一套三层定级模型，从合法性、冲突面、影响面三个维度打分，最后落到处置矩阵里。
合法性看三件事：校验位是否正确、GS1 前缀是否归属本公司主体、是否在有效期内。这三件事我建议每次都按固定顺序查，因为它们的信息层级是递进的。
校验位是入门线，前面说过它信息量有限。前缀归属是核心线，因为前缀决定了这个码在法律和平台规则层面的归属主体。有效期是兜底线，很多公司忘了 GS1 前缀需要续费，一旦断档，历史码在部分平台会进入异常状态。
校验位真正的价值不在于判断合法性，而在于作为一个极低成本的格式守门员，在数据写入的第一秒就拦掉明显错误。下面是 UPC-A 的校验位实现，我通常会把它封装成一个写入前的钩子。
def upc_check_digit(eleven: str) -> str:
"""输入 UPC-A 前 11 位，返回第 12 位校验位。"""
if len(eleven) != 11 or not eleven.isdigit():
raise ValueError("UPC-A 前 11 位必须是纯数字")
odd = sum(int(d) for d in eleven[0::2]) # 第 1,3,5,7,9,11 位
even = sum(int(d) for d in eleven[1::2]) # 第 2,4,6,8,10 位
return str((10 - (odd * 3 + even) % 10) % 10)
def is_valid_upc(code: str) -> bool:
code = code.strip().replace(" ", "")
if len(code) != 12 or not code.isdigit():
return False
return upc_check_digit(code[:11]) == code[11]
示例
print(upc_check_digit("03600029145")) # -> '2'
print(is_valid_upc("036000291452")) # -> True
print(is_valid_upc("036000291453")) # -> False批量查重看起来简单，但真正能用的版本必须处理三件事：格式归一化、跨表比对、以及输出可执行的明细。只输出“有 42 组重复”是没有价值的，必须输出“哪 42 组、分别在哪张表哪一行、责任人是谁”。
import pandas as pd
def normalize(raw) -> str:
s = str(raw).strip().replace(" ", "").replace("-", "")
s = s.translate(str.maketrans("０１２３４５６７８９", "0123456789"))
return s.zfill(12)
def audit(files: dict) -> pd.DataFrame:
rows = []
for name, path in files.items():
df = pd.read_excel(path, dtype=str)
for i, r in df.iterrows():
rows.append({
"source_file": name,
"row": i + 2,
"sku": r.get("SKU", ""),
"upc": normalize(r.get("UPC", "")),
"owner": r.get("责任人", ""),
"updated_at": r.get("更新时间", ""),
})
allc = pd.DataFrame(rows)
allc["valid"] = allc["upc"].map(is_valid_upc)
dup = allc[allc.duplicated("upc", keep=False) & allc["upc"].ne("")]
return dup.sort_values(["upc", "source_file"])这段代码的关键在 normalize 函数：绝大多数“查不出来”的重复，都是因为格式没归一化。全角数字、前后空格、连字符、前导零缺失，这四种情况能解释我遇到过的八成人眼漏检。
同样是重复，冲突范围不同，处置优先级差很多。我按冲突面把重复分成四级：
| 冲突级别 | 定义 | 典型场景 | 处置优先级 |
|---|---|---|---|
| 冲突一 | 同一店铺内重复 | 同一后台里两条 listing 用同一码 | 高，通常 48 小时内处理 |
| 冲突二 | 同一主体多店铺重复 | 公司名下 A 店与 B 店撞码 | 中高，一周内处理 |
| 冲突三 | 跨平台重复 | 主站与区域站撞码，或站内与独立站撞码 | 中，两周内处理，但需同步 |
| 冲突四 | 跨主体重复 | 与外部卖家撞码，对方先占位 | 视情况，需先取证再申诉 |
这里有一个反直觉的判断：冲突四（跨主体）看起来最严重，但处理优先级反而可能最低。因为它不取决于你多快改，而取决于对方的码源是否合法。如果对方用的是第三方码库而你有正式 GS1 前缀，你的申诉胜算很高，急反而容易出错。相反，冲突一（同店重复）看起来最轻，但它是平台算法最容易直接识别并采取措施的，必须最快处理。
影响面我一般看四个指标：该 SKU 近 30 天是否出单、是否有累积评价、是否有在投广告、是否有在途或已入库库存。四个都否的，处置可以放到常规节奏；有两个及以上为是的，必须进入紧急通道。
原因很简单：没有交易记录的 SKU 改码成本接近于零，有交易记录的 SKU 改码成本可能超过它一年的毛利。把这两类放在同一个队列里处理，是对资源的浪费。
把三层的结果合起来，我通常会得到一个 3×3 的处置矩阵。合法性问题（前缀不归属）无论冲突面多小，都要走“换码”路线，不能只做去重。冲突面在“同店”且影响面高的，走“紧急止血”路线，先保链接再改码。冲突面在“跨主体”且影响面低的，走“取证 + 申诉”路线，不急于改码。
这套矩阵的价值在于：它把“重复码怎么办”这个模糊问题，变成了一个有明确输入、明确输出的决策函数。团队不用每次争论，按规则执行即可。
这一节我想讲一个方法论层面的判断：只看自己的 UPC 表格，永远查不出真正的重复问题。原因是重复的本质是“占用冲突”，而占用发生在平台上，不是发生在你的表格里。
内部表格只能回答“我自己的码有没有撞自己”。它回答不了三个更重要的问题：这个码在平台上有没有被别人占用？这个码在平台上对应几条 listing？这个码在平台上对应的 listing 和我台账里的 SKU 是不是同一个产品？
这三个问题必须通过码与 listing 的交叉核对来回答。而做这件事需要一个能把多平台、多店铺数据拉到一起看的地方。
我在这类排查里会用到数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）作为数据聚合和交叉核对的入口。它的价值不在于“帮你查重”，而在于把平台侧的 listing 数据、类目数据和多店铺数据放到同一张视图里，让码和产品能被对齐。这是我用纯脚本做不到的部分。
我的四步流程是这样的：
第 3 步里的“两侧都有但产品名对不上”，是我发现跨主体重复最有效的一条线索。因为当你和别人撞码时，平台上你那条 listing 的标题往往就是对方的标题，产品名根本对不上。很多人只看 UPC 字段是否重复，却忽略了“同一个码对应两个完全不同的产品名”才是最强的重复信号。
我把最近一次完整排查的数据整理出来，涉及 3 个店铺、2 个平台、1600 个活跃 SKU。内部脚本查出的重复是 42 组，交叉核对后又多出了 11 组，这 11 组在内部表里完全不重复，但平台上存在占用冲突。
| 异常类型 | 数量 | 内部脚本能否发现 | 后果等级 |
|---|---|---|---|
| 内部表重复（同店） | 42 组 | 能 | 高 |
| 平台占用冲突（跨主体） | 7 组 | 不能 | 中高 |
| 同码对多 listing（平台侧） | 4 组 | 部分能 | 高 |
| 码有效但产品名不匹配 | 9 组 | 不能 | 中 |
| 格式异常（全角、丢零、空格） | 23 条 | 清洗后能 | 低 |
值得注意的是那 23 条格式异常：它们本身不是重复，但如果不处理，会在下一次比对中制造假重复或漏检真重复。格式问题不是小问题，它是查重系统的信噪比问题。
同一个卖家在上线自动化校验 + 唯一责任人机制之后，我跟踪了 6 个月的数据。变化最明显的不是重复码总量，而是“从发生到被发现”的时长。上线前，平均发现周期是 23 天；上线后，压缩到了 0 天，因为错误在写入时就被拒绝了。
前面讲的是判断逻辑，这一节讲执行。我把团队按规模和复杂度的不同，拆成五种情况，每种给一套可以直接照做的动作。
这个阶段不要上系统，上了也用不起来。核心动作只有三个：
这个阶段最大的敌人不是重复码，是多个副本。我见过太多小团队，同一份码表有 4 个版本在不同人的微信里流传。
这个区间是风险最陡的区间，也是必须开始自动化的起点。动作清单：
这个规模下，靠流程已经不够了，必须有系统级的约束。我会建议做三件事：
在这个规模上，管理的重点从“发现重复”转向“不允许重复发生”。这两件事需要的能力完全不同。
事故处理的顺序很重要，我建议严格按下面的顺序来，不要跳步。
最常见的错误是第一件事就改码，结果把唯一的证据改掉了，后面申诉时无法证明自己是先使用方。
最好的治理时机是新品开发阶段。我的做法是在新品立项表里加一栏“UPC 状态”，只有四种值：未申请、已申请未到、已到待校验、已校验可用。新品上架前，UPC 状态必须是“已校验可用”，否则流程卡住。这一条规则看似简单，但它把重复码的拦截点从“上架后”提前到了“上架前”，成本差几十倍。
所有治理方案都有代价，这一节我讲清楚每一组取舍的边界，方便你按自己的情况做决定。
自购前缀的核心收益是归属确定性，核心成本是年度费用和申请周期。第三方码的核心收益是即时性和低价，核心成本是码源的不可控性。
我的判断标准是看单品毛利和店铺的长期规划。如果你的 SKU 平均年毛利超过 2000 元，或者你有计划做品牌备案、做独立站、做多区域市场，自购前缀的收益远大于成本。反过来，如果你在快速测款阶段，单品生命周期可能只有两三个月，第三方码的风险收益比是可以接受的。
但有一条底线：主推款和高毛利款，不要用第三方码。因为主推款一旦出问题，损失是放大的。
这是一个资源分配的取舍。一次性清洗能快速把存量拉到干净状态，但它会随时间重新变脏。常态化校验能持续保持，但初期看不到明显效果，容易被资源挤压。
我的建议是先做一次性清洗建立基线，同时上线常态化校验，两者不是二选一。因为如果你只做清洗，三个月后你会发现又回到了原点；如果你只做常态化校验，存量问题一直在那里，新机制也跑不出干净的对照数据。
集中管控的优势是标准统一、责任清晰；劣势是响应慢，容易成为瓶颈。分散自助的优势是灵活；劣势是容易各搞一套，最终无法合并。
我的经验判断是：码的申请和作废必须集中管控，码的使用和查询可以分散自助。这两件事分开，既能保证唯一性和可追溯，又不会让运营在等码上卡太久。
这两者的能力边界不同，我前面提过。自建脚本擅长内部数据的格式归一、唯一性校验、批量比对。平台工具擅长平台侧数据的聚合、跨店铺的占用核验、以及码与 listing 的对齐。
我的建议是两者都用，但主次分明：脚本做第一道关（写入前拦截），平台工具做第三道关（上架前交叉核对）。只靠脚本会漏掉跨主体占用；只靠平台工具会漏掉格式和内部结构问题。
这是我最后想强调的一组取舍。零重复是一个理想目标，但绝对的零重复在跨主体场景下是不现实的，因为别人也可能撞你的码，这不是你能控制的。
更现实的目标是“可追溯”：任何一条重复在发生时，你能在 24 小时内说清楚它是哪一类、来自哪个环节、影响哪些 listing、应该由谁处理。能做到这一点，重复码就不再是一个失控的风险，而是一个被管理的常规异常。
回到最开始的那个判断：重复 UPC 不是数据脏，是协同链条断了。我在这篇文章里想传递的独特视角有三个，它们和常见的“记得查重、注意录入”式建议有本质差别。
第一个判断：重复码的归因方向错了，所有治理都会走偏。如果团队认为 90% 的重复来自员工粗心，就会把资源投在培训和考核上；但我观察到的数据是，录入型重复只占约 12%，其余来自流程缺口和外部码源。归因错了，动作就全错了。
第二个判断：查重的技术瓶颈不在算法，在数据清洗的完成度。补前导零、处理全角数字、去连字符这三件看起来最不“高级”的事，决定了你 61% 到 99% 的检出率差距。很多团队花时间研究更复杂的匹配算法，却没做这几步基础清洗。
第三个判断：治理目标应该是“可追溯”，不是“零重复”。零重复在跨主体场景下不可控，但可追溯是可控的。把目标设成可控的那个，团队才能持续做下去。
如果你的团队现在就有重复码隐患，我建议先做这三件最小动作：
7 天动作解决的是“知道现状”，一个月内的机制解决的是“不再复发”。我的建议是按下面的节奏推进。
做完这四步，你会得到一个不需要靠人盯着的系统。它不完美，可能会漏掉少量跨主体占用，但它能把 95% 以上的问题挡在上架之前。
最后说一句我的真实体会：重复码排查这件事，技术难度不高，难的是让整个团队接受“这是流程问题而不是个人问题”。一旦团队完成了这个认知转变，后面所有工具和机制都会顺理成章。而如果认知没转过来，你上再多的工具，也只是把问题从表格挪到了系统里。
我之前做跨境店铺时，运营说后台提示重复，采购又说供应商给的就是这个码，我夹在中间不知道从哪下手。每次靠人工翻 Excel，查到后面自己都不确定哪个码是真的重复。到底有没有一个先后顺序，能半天内锁定问题？
先查内部商品主数据，再查渠道后台，最后回到 GS1 或供应商凭证。做法是：把商品主表、渠道 SKU 绑定表、UPC 采购或申请记录三张表导出，统一清洗 UPC 字段，去掉空格和横线，统一为 12 位，剔除校验位错误的码；
用 Excel 的 COUNTIF 或 SQL 的 group by upc having count(*) > 1 找出重复值，再反向筛选涉及的 SKU、店铺、负责人。判断依据是：内部表能同时看到谁在用、用在哪、是否已上架，渠道后台只能看到平台侧结果，先查内部能避免把平台误报当成根因。
如果内部唯一但平台报重复，再查是否曾被其他店铺或历史 SKU 占用，截图留存后台提示和 UPC 绑定记录。初次排查建议按影响排序：已出单、已合并变体、已触发审核的优先处理。
我们上次遇到重复码，运营第一反应是赶紧改 listing，采购说改 SKU 会影响库存对账，仓库又怕发错货。我当时的困惑是，到底动哪一边才不会把已经卖出去的订单和库存搞乱？如果两边同时改，会不会更糟？
先冻结，再判断，最后单向变更。第一步把重复 UPC 对应的 SKU 在渠道后台和内部系统标记为冻结绑定，暂停新建 listing、暂停补货和新渠道铺货，但已出单订单继续履约。第二步判断谁是主使用方：优先保留历史销量高、评价多、库存深、已形成稳定 listing 的 SKU 继续使用原 UPC；
另一个 SKU 不要直接改掉原 listing 的 UPC，而是申请新 UPC 或按 GS1 规则启用正确 GTIN，重新上架或做正规迁移。判断依据是渠道平台通常把 UPC 作为商品唯一标识，随意改老 listing 的 UPC 可能触发审核、变体拆分或评价丢失。
第三步才是同步内部 SKU、库存、采购和财务字段，所有变更留痕：原 UPC、新 UPC、涉及 SKU、操作人、时间、平台反馈截图。不要同时改 listing 和内部 SKU 且不留记录，否则对账时很难还原。
以前我们查重复码，运营找采购，采购找供应商，供应商说码没问题，最后又回到运营改表格。每次都要拉群、发表格、等回复，问题拖一周还在原地。我想知道怎么用团队都看得懂的方式，把这件事变成固定协同流程？
把重复码排查做成一个标准工单，而不是临时群聊。可以在某项目管理平台里建一个 UPC 重复排查工作项类型，必填字段包括：UPC、涉及 SKU、渠道、发现时间、影响等级、责任人、协作人、截止时间、当前状态、证据附件。
流程按发现、清洗、判定、变更、复核、关闭六步走，运营负责发现和渠道证据，采购或商品主数据负责人负责 GS1 或供应商凭证，仓库或财务负责库存影响确认，负责人只做最终判定。每天用 15 分钟站会只过三类卡点：码的归属不清、平台已出审核、涉及在途库存。
判断协同是否有效，不看群里回复多快，而看三个指标：重复码从发现到关闭的平均时长、超期未关闭数量、同一 UPC 二次重复率。跑顺后，重复码不再是某个人的锅，而是一条可追踪的流程。
我们每次都是出问题才排查，排查完改一遍，过两个月又冒出来。采购从不同供应商拿码，运营从不同渠道建 SKU，谁都觉得自己的表没问题。有没有办法在录入那一刻就拦住重复，而不是等平台下架才救火？
把唯一性校验前移到录入环节，并设置双人复核和月度审计。具体规则：第一，UPC 字段统一为 12 位数字，去空格、去横线，按 GS1 校验位算法验证，错误码不允许入库；第二，在商品主数据表或数据库对 UPC 建唯一索引，同一 UPC 只能绑定一个有效 SKU，变体商品必须使用各自独立 GTIN；
第三，批量导入前先跑预检，输出重复清单和错误码清单，预检不通过不进入正式表；第四，采购新增 UPC 时必须上传 GS1 证书或供应商授权凭证，运营新增 SKU 时必须从主数据选择 UPC，不允许手工输入自由文本；
第五，每周或每月做一次审计，用重复率等于重复 UPC 数除以有效 UPC 总数作为口径，成熟团队可设目标低于 0.5%，新团队先把超过 1% 的重复全部清零。这样做的好处是，排查从事后救火变成事前拦截，团队协同也有明确规则可依。
读者评论
组重复的定性方式我有点疑问。源头型、流转型、回流型在实际排查里边界很模糊，比如供应商码表复制错行，你算源头还是流转？我自己做过类似的体检，最后能证实的往往只有平台报错那几条，剩下的只能靠推断。这会影响后面投入优先级的判断。
唯一责任人这个约束在小团队里挺难落地的。十来个人分工清晰还好，一人兼采购加运营的，签名最后都签在自己头上，等于没有交叉。另外写入前拦截听着理想，但多数 ERP 和平台后台根本不给你这个钩子，现实里还是定时跑批比对，落回事后。
校验位那段的提醒挺实在。我们早期图便宜买过一批第三方码，上架时才发现有几十个已经在别的店铺用了，平台直接报重复。所以我现在更关心的是有没有低成本的跨平台占用核验思路，毕竟普通卖家拿不到别人后台的数据。