2021年我接手过一个亚马逊美国站的编码治理项目。卖家当时有3200个SKU、6个店铺、3个类目，UPC全部来自某第三方批量购买的码包。第一次做重复码排查，我把后台全部UPC导出做去重，结果发现41个UPC被挂到了两个以上SKU上，其中9个UPC甚至同时绑定了不同类目的Listing。这些Listing当时正在跑广告，部分已经稳定出单。
这件事最反常识的地方在于：卖家的第一反应是”我买的是一批全新的码，怎么会重复”。但重复码从来不是随机事件，它是采购方式、分配流程、记录工具三者共同失效的必然结果。UPC码优化这件事，90%的人一上手就想去做”换码””重刷”甚至”重新注册品牌”，而我的一贯判断是，先把重复码排查做扎实，再谈优化，否则你所有的动作都是在把错误复制一遍。
这篇文章我会完整讲清三件事：重复码为什么必须排在优化的第一位、一套能真正落地的标准化管理长什么样、以及在SKU规模不同的情况下你该做哪些取舍。文中会用到我在”数跨境”（官网 https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys ）上搭建UPC台账的实际操作路径，也会给出可以照着跑的校验脚本和排查步骤。
很多人把UPC优化理解成一个技术问题：怎么让系统不报错、怎么让Listing顺利上架。但在我做过的十几个编码治理项目里，真正的分水岭从来不是技术手段，而是有没有把UPC当成资产来管理。
结论一：重复码是UPC所有问题里唯一会”传染”的问题。格式错误、校验位算错、前缀不合规，这些问题只影响单个SKU，改掉就结束。但重复码一旦存在，会让两个原本无关的SKU在平台的商品目录里相互干扰，A的库存波动会影响B的Buy Box，A的差评可能出现在B的详情页，处理成本随时间指数上升。
结论二：重复码排查不能依赖平台报错。平台的重复校验主要发生在上架和变体绑定环节，对于历史遗留、跨店铺、跨站点、以及”先删后建”造成的隐性重复，平台往往不会主动提示。我见过最极端的情况是，一个UPC重复了14个月才被偶然发现。
结论三：标准化管理的核心不是工具，而是”分配权”。只要一个组织里存在”谁都能去申请/购买UPC”的情况，重复码就一定会出现。标准化管理的第一步，是把UPC的申请权、分配权、回收权收敛到单一责任人手上。
判断一个问题该不该优先处理，我一般看三个维度：影响面、不可逆性、修复成本增速。
影响面上，重复码天然是”一对多”的。一个UPC重复，至少牵动两个SKU、两个Listing、两套库存记录和两笔广告预算。如果这个UPC还被用在了变体关系里，影响面会沿父子结构继续放大。
不可逆性上，重复码最麻烦的产物是评价和排名的错误归属。当两个不同商品被平台识别为同一商品时，它们会共享详情页、共享评论池。等到你发现并解绑时，那些评论已经沉淀在错误的ASIN上，迁移不回来。
修复成本增速上，重复码属于典型的”晚一天处理，成本翻一档”。第1周你只需要在后台改个字段，第1个月你要走开Case流程，第3个月你可能要面对整个变体家族重建，第1年以后，很多卖家的选择是直接放弃这个SKU。
我用的标准框架是四个字：唯一、合法、可追、可校。唯一指一码一SKU的强绑定；合法指GTIN来源可验证；可追指从申请到退役的全生命周期有记录；可校指格式和校验位可以机器批量验证。
这四个维度不需要一次性全做完。我的建议顺序是：先做”可校”，再做”唯一”，然后补”可追”，最后治理”合法”。原因很实际，可校是脚本能自动跑的，成本最低、见效最快，而且它能直接帮你找到重复码，天然带出唯一性问题的清单。
重复码的成因看起来五花八门，但落到具体案例上，绝大部分可以归到三类。这三类我都在项目里遇到过，处理路径完全不同，不能混用一套方案。
这是最常见也最隐蔽的一类。卖家有两个或三个店铺，为了省成本，UPC码包只买一份，然后按”这个店铺用前一半、那个店铺用后一半”手动分。听起来没问题，但执行中会出现两种偏差。
第一种偏差是分完之后没有记录边界。运营人员换了一批之后，新来的人不知道前一半已经被用掉，从中间开始分，于是重叠出现。第二种偏差是同一个产品在不同店铺上架时，运营为了”省事”直接复制了另一个店铺的UPC，理由是”反正是同一个产品”。
第二类偏差的杀伤力最大。因为平台会认为这两个Listing是同一商品，商品目录会自动关联，一个店铺的价格、库存、促销活动会影响另一个店铺的展示。我处理过的一个案例里，A店铺在做秒杀，导致B店铺的购物车占有率在同一时段从70%掉到12%，运营查了两周才定位到原因。
这类问题的技术成因非常简单，就是批量填表时下拉填充或复制粘贴没有更新。但它的隐蔽性在于，同一个UPC挂到三个SKU上之后，如果这三个SKU分属不同类目、不同价格带，平台通常不会在上架时全部拦截，只有部分会触发冲突提示。
我印象最深的一次，是一个服装卖家在新品批量上架的表格里，一个UPC被填到了三个尺码变体上。上架成功了，两周后才发现其中一个变体的评价开始出现在另一个变体下面。这种问题从”录入”到”被发现”平均拖了3到6周，中间产生的广告浪费和退货纠纷很难追回。
这类问题在铺货型卖家里极常见。供应商提供了现成的UPC，卖家直接拿来上架，没做任何验证。问题在于，供应商的码可能来自三种来源：自己早期申请的、从其他卖家手里回收的、或者干脆是从历史下架商品上扒下来的。
如果这个UPC曾经被某个ASIN使用过并且有历史销售记录，你上架后可能会”继承”那个ASIN的部分属性，包括类目节点、变体关系，甚至旧评论。这不是好事，旧评论往往与你的实际产品不匹配，退货率和差评率会明显走高。
我复盘过手上17个重复码案例，记录从”重复实际发生”到”被发现”的时间间隔。这个分布很说明问题：一周内被发现的只有不到两成，绝大多数集中在两到八周之间，还有一部分超过三个月。
更重要的是，发现的渠道同样集中：通过平台报错发现的不到三分之一，剩下的大部分是通过销量异常、评价错位、广告数据异常这些”间接信号”反推出来的。这意味着被动等待系统提示，等于默认接受长期损失。
在讲方法之前，我必须先清理几个反复出现的错误认知。这些误区不解决，后面所有流程都会被绕过。
UPC本质是GS1体系下的商品标识，它承载的是”厂商标识+商品标识+校验位”三层信息。当你从一个非GS1渠道购买UPC时，你买到的是别人名下前缀的一段数字使用权，而不是所有权。这个区别在你需要向平台提供来源证明的时候会变得非常致命。
品牌备案解决的是品牌名称使用权限和A+内容权限，它不解决编码来源问题。即使你拿到了GTIN豁免，那些历史遗留的重复UPC仍然存在于你的商品目录里，仍然可能造成ASIN冲突。豁免只是让你可以不用新码上架，不等于帮你清理旧账。
这是一个非常危险的误解。当你把一个已有销售历史的ASIN的UPC改掉，平台上会出现新旧两套标识指向同一个商品的情况，历史上已经沉淀的评论、排名和变体关系不会自动迁移。更糟的是，如果新UPC也存在重复，你会把问题从旧SKU复制到新SKU。
“删掉重发”在铺货模式下看着省事，但在精品和半精品模式下几乎必然带来更大损失。删除Listing会丢失该ASIN累积的评价数量和排名权重，重建后需要重新经历冷启动。如果这个SKU有过稳定出单，重置的代价通常远高于走申诉流程。
UPC-A是12位，EAN-13是13位，GTIN-14是14位，它们在GS1体系里是同一标识的不同层级表现形式，可以互相转换（在UPC前补0得到EAN-13，再补指示符得到GTIN-14）。但”可以转换”不等于”可以随意填”。不同站点要求的标识类型不同，把EAN直接填进要求UPC的字段，可能触发格式校验失败或语义错误。
Excel的问题不在功能，而在协作。只要有多人接触这个文件，版本冲突、覆盖保存、筛选后误删、格式被自动转成科学计数法这些问题就会反复出现。我见过最典型的一次事故：UPC列被Excel自动识别为数字，前导零被吞掉，导致整批码在导出后全部失效，但因为位数看起来”差不多”，没人立刻发现。
讲完误区，进入方法层。我把UPC标准化管理拆成五个支点，顺序很重要，因为它们之间存在依赖关系：没有可校验，唯一性就是人工判断；没有唯一性，追溯记录全是脏数据。
第一步是让每个UPC的格式和校验位可以被程序自动验证。UPC-A的校验位算法是固定的：取前11位数据位，从左数奇数位乘3、偶数位乘1，求和后取10的补数。这个算法十几行代码就能实现。
def upc_check_digit(data11: str) -> int:
"""输入11位数据位，返回UPC-A第12位校验位"""
if len(data11) != 11 or not data11.isdigit():
raise ValueError("UPC-A 数据位必须是 11 位数字")
total = 0
for idx, ch in enumerate(data11):
weight = 3 if idx % 2 == 0 else 1
total += int(ch) * weight
return (10 – total % 10) % 10
示例：DataBar 经典样例 03600029145 的校验位应为 2
print(upc_check_digit("03600029145")) # 输出 2
有了这个函数，你可以在任何一次导出后跑一遍全量校验。凡是校验位对不上的，说明这个码在录入或导出环节被改过，必须单独核查。这一步能过滤掉大约一成的”看起来正常但实际无效”的码。
“一码一SKU”这句话人人会说，但真正落地需要三个附加条件。
平台后台的UPC字段是可以被修改的，一旦有人改了，历史绑定关系就没了。所以你必须有一份独立于平台的映射表，记录”UPC → 内部SKU → 所属店铺 → 上架时间 → 当前状态”。
这是我见过最多人踩的坑。SKU下架后，运营觉得”这个码空出来了”，直接分配给新品。但平台的商品目录可能仍保留着旧ASIN与该UPC的关联记录，新上架的商品可能触发冲突。我的做法是设置一个冷却期，退役UPC至少保留12个月不重新分配。
如果业务上确实需要同一商品在多个店铺上架，正确做法不是”复制UPC”，而是明确这个UPC对应的是一个跨店铺的主SKU，并在映射表里记录所有店铺的关联关系。这样你才能提前知道：改价格、调库存、做促销会互相影响。
可追溯的目标不是记录所有细节，而是回答四个问题：这个码从哪来、分配给了谁、现在在哪、什么时候退役。
我在数跨境上搭的台账只保留了必要字段：UPC、来源类型（自申请/供应商提供/历史遗留）、来源凭证编号、内部SKU、所属店铺、上架日期、当前状态、退役日期、复核人。字段不多，但足以支撑一次完整的追溯。
合法性的判断标准很直接：这个UPC能否在GS1的公开查询体系里追溯到归属企业。如果你通过正规渠道申请了厂商前缀，你的码天然满足这个条件；如果是第三方提供的码，你需要向供应方索取前缀归属证明。
需要提醒的是，很多转售码确实能在公开数据库里查到归属，但归属的是一家与你无关的公司。这种情况在平台核查时会被质疑，因为标识持有方和商品销售方不一致。
最后一个支点最容易被忽视，但它决定了前四个支点能不能维持。具体是三件事：申请权收归一人、分配必须走审批、每季度做一次全量查重。
申请权收归一人，是为了避免多来源混入。分配走审批，是为了让每次分配都留痕。季度全量查重，是为了在问题扩散前发现它。这三件事没有任何技术难度，难的是坚持。
前面讲的是框架，这一节讲具体怎么做。我会用数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys ）上的实际操作路径来说明，因为它解决了Excel最核心的两个问题：协作冲突和结构化查询。
先回答一个常见质疑：”我的SKU不到200个，用Excel完全够。”这个判断在单一责任人、单一店铺的情况下成立。但只要有第二个人接触这张表，风险就开始上升。
我做过一个粗略统计：在SKU规模200到2000之间、多人协作的团队里，Excel台账平均每季度会出现1.7次数据异常，其中约四成是重复或覆盖类问题。这个比例听起来不高，但一旦命中，处理成本往往是台账维护成本的几十倍。
工具化的真正价值不是”更高级”，而是把”唯一性约束”变成系统强制，而不是靠人的自觉。当系统层面不允许同一个UPC被分配给两个活跃SKU时，重复码的入口就被物理堵住了。
在数跨境上搭建时，我一般把台账拆成四组字段，对应前文的四个支点。
字段看似不少，但录入时大部分是下拉选择，实际工作量比想象中小。真正花时间的是历史数据补录，这部分我的建议是不要追求一次性补全，先补”在用”状态的SKU，历史退役的码单独建档即可。
这是本文最核心的操作部分。四步的顺序不能颠倒，每一步都为下一步缩小范围。
从平台后台导出全部在售和已下架Listing的UPC字段，加上内部台账的数据，合并后做一次精确去重。这一步找出的”同一个UPC出现两次以上”就是硬重复，处理优先级最高。
import pandas as pd
合并平台导出与内部台账，统一字段名
platform = pd.read_excel("listing_export.xlsx", dtype={"upc": str})
ledger = pd.read_excel("upc_ledger.xlsx", dtype={"upc": str})
merged = pd.concat([platform[["upc", "sku", "shop"]],
ledger[["upc", "sku", "shop"]]], ignore_index=True)
补齐到12位，防止前导零丢失造成的假性不重复
merged["upc"] = merged["upc"].str.zfill(12)
找出所有出现次数大于1的UPC
hard_dupes = merged[merged.duplicated(subset=["upc"], keep=False)]
hard_dupes = hard_dupes.sort_values(["upc", "shop"])
hard_dupes.to_excel("hard_duplicates.xlsx", index=False)
print(f"硬重复UPC数量：{hard_dupes['upc'].nunique()}")注意代码里那句 str.zfill(12)。这是我踩过的一个大坑：如果UPC以0开头，Excel和部分导出工具会把它当数字处理，前导零被吞掉，导致原本重复的两个码在字符串层面看起来不同，去重直接漏判。
对全量UPC跑一遍校验位验证，把校验失败的单独列出来。这一步能同时发现录入错误、位数错误和被篡改过的码。
这一步最容易被跳过，但价值很高。语义重复指的是”码不重复，但绑定的商品实质相同”。典型表现是同一个商品在两个店铺用了两个不同UPC，导致同一个实物对应两个ASIN。排查方法是按”商品名称+规格”做分组，看是否存在多个UPC。
对仍在使用、且来源为”供应商提供”或”历史遗留”的UPC，抽样去公开数据库核查归属企业。如果发现归属与你无关，标记为高风险，列入后续替换计划。
拿我做过的一个案例来说，卖家在售SKU约900个，累计UPC记录3800条。按上面的四步跑完，结果和前后变化如下。
处理前，硬重复96个，其中31个是跨店铺重复，19个涉及变体关系。完成解绑、重建映射和广告结构调整后，30天内观察到几个明显变化：因商品目录冲突导致的下架提示从每月平均7次降到0次，跨店铺价格串扰的投诉从每月5起降到1起，运营在上架环节花费的编码核对时间从平均每人每周3.5小时降到0.8小时。
最有价值的观察是关于变体关系。处理前的19个涉及变体的重复码，有11个已经造成了评价错位。解绑后，这11个SKU中有7个的退货率在两周内出现下降，平均降幅1.8个百分点。这个变化说明评价错位对转化的实际影响比多数人估计的要大。
方法讲完了，但不同阶段的卖家需要做的事情差别很大。我按SKU规模和组织复杂度分成四种情况，分别给出建议。
这个阶段的建议是不要过度建设。你需要的只是一张结构化表格加一个校验脚本。
这个阶段最容易犯的错误是”为了省几百块钱去买转售码”。以我处理的案例看，转售码节省的采购成本通常不到总运营成本的千分之一，但它可能带来的Listing重建成本是采购成本的几十倍。这笔账不值得算。
这个阶段必须工具化。核心动作是三条。
第一，把UPC台账从Excel迁移到结构化工具，让唯一性约束成为系统级规则。第二，明确申请权和分配权的唯一责任人，其他角色只有查看权限。第三，建立季度全量查重机制，把查重结果作为例会固定议题。
多站点的情况需要额外注意：同一个商品在美国站和欧洲站可能需要不同类型的标识，台账里应该增加”站点”字段，避免把美国站的UPC直接复制到欧洲站。
这种情况要分轻重缓急，不要一次性处理所有问题。
优先处理”正在产生销售且涉及变体”的重复码，因为它们的影响在持续放大。其次是”跨店铺重复”，处理它需要协调两个店铺的运营节奏，周期较长。最后处理”已下架SKU的重复码”，它们的影响已经停止，可以放在常规清理里。
处理过程中有一个重要原则：先解绑，再决定是保留还是重建。不要一发现问题就删Listing，先把标识关系理清，再根据销售历史决定哪个SKU应该保留、哪个应该迁移。
GTIN豁免解决的是”新上架商品不需要UPC”的问题，它不解决历史库存的标识问题。我的建议是两条线并行。
新商品走豁免路径，减少新增的编码风险；历史商品仍然要做一次完整的重复码排查，因为豁免不改变已经存在的商品目录关联。如果历史重复问题严重，可以在豁免生效后，按类目分批重建Listing，用豁免规避新码引入的风险。
策略选择从来不是”哪个更好”，而是”在什么条件下哪个更合适”。这一节我讲四个需要明确取舍的地方。
从纯成本看，第三方购买有明显优势。但要做这个取舍，你需要先算清楚三个隐藏成本：平台来源核查的应对成本、重复码造成重建的概率成本、以及跨店铺分配时的边界管理成本。
我的经验判断是：单店铺、铺货模式、SKU生命周期短且不追求评价沉淀的情况，第三方码的风险敞口相对可控；一旦涉及品牌建设、多店铺、变体关系或者长期运营，正规申请几乎是唯一合理选择。
这个取舍的关键变量不是SKU数量，而是协作人数。单人操作时Excel完全够用；一旦有第二个人需要录入或查询，工具化的收益就会快速超过它的使用成本。
还有一个容易被忽略的变量是查询频率。如果团队每天需要查询UPC状态超过10次，Excel的筛选和查找操作会消耗大量时间，工具化的价值会更明显。
全面清洗看着干净，但风险高：一次性改动大量Listing，可能触发平台的批量审核，而且很难定位问题来源。分批清洗更稳，但周期长。
我的建议是按”影响面”分批：先处理影响在售商品的，再处理影响已下架商品的；先处理单店铺内部的，再处理跨店铺的。每批处理完留出观察期，确认没有引发新问题再开始下一批。
这不是一个二选一的问题。合理的做法是分商品线处理：品牌线商品走豁免，用品牌自身的标识体系管理；非品牌线的长尾商品保留UPC，但加强台账管理。
需要提醒的是，豁免不是免费的午餐。豁免后你不能在平台上用UPC做跨平台商品匹配，如果你同时在多个渠道销售，需要考虑每个渠道的标识策略是否一致。
最后给一份具体可执行的清单。这份清单我按周拆开，前三周做排查和建档，最后一周建立长效机制。
这一周的产出应该是一份”硬重复清单”，包含重复的UPC、涉及的SKU、所属店铺、上架时间和当前销售状态。清单不需要完美，但必须完整覆盖在售商品。
30天结束后，不要只看”处理了多少个重复码”，那只是一个过程指标。我更建议盯四个结果指标。
我自己的经验是，如果一个团队能把”新增重复码数量”连续两个季度保持在零，那么它的UPC管理基本就进入稳定状态了。剩下的工作只是常规维护和定期核查。
写到这里，我想把整篇文章的判断浓缩成几句话。
第一，UPC优化的正确顺序是”先排查重复、再谈优化”。跳过排查直接去换码、重建Listing、申请豁免，等于在一个有裂缝的地基上盖房子。重复码是所有编码问题里唯一会相互传染、并且随时间快速放大成本的那一类，它必须第一个解决。
第二，重复码的本质是管理问题，不是技术问题。所有我见过的重复码事故，追到根上都是”谁都能申请、谁都能分配、没有人复核”这三个条件同时成立。工具能帮你更快发现问题，但只有权限收敛能阻止问题发生。
第三，标准化管理的最小可行版本比想象中简单。一个校验脚本、一张带唯一性约束的台账、一份明确的权限划分、一个季度查重的日程，这四样东西就构成了完整的闭环。它们都不复杂，难的是坚持执行。
如果你现在就要动手，我的建议是从今天开始做三件事：把全部UPC补齐到12位字符串并跑一次精确去重；用校验位脚本筛出所有格式异常的码；把这份清单当作起点，按本文第五节的四步流程走一遍。
做完这三件事，你会对自家编码资产的真实状况有一个完全不同的认识。而这，才是UPC优化的真正起点。
我们店铺有400多个SKU，UPC是不同时期从不同渠道买的，Excel台账换过三任运营，我接手的时候根本不知道有没有重复。上次一个新品上传报错说条码已被使用，我才意识到这个问题可能是一大片，不是单独一条。
按三步走，顺序不能反：先查库内重复，再验码本身有效性，最后查码在平台的占用情况。第一步把各平台后台或ERP里的SKU明细导成表，至少保留UPC、SKU、品名、变体属性四列，用COUNTIF对UPC列计数，大于1的全部标红；
这一步的坑是要先把单元格格式设成文本、清掉前后空格和不可见字符，否则000123456789和123456789会被当成两个不同的值，查重结果不可信。
第二步验校验位：UPC-A是12位，前11位从左边数，奇数位乘3、偶数位乘1，求和后取个位数，用10减这个个位数（结果为10时取0）就是第12位，对不上的码基本可以判定是编的或抄错的。
第三步把剩下的码拿去GS1官方数据库查前缀归属，中国大陆注册的前缀在690到699之间，如果查到归属厂商不是你公司，就说明这个码的来源本身有问题，即使不重复也不能放心用。整套流程300到500个SKU用Excel加人工核对，一个下午能跑完。
我有一条卖得还不错的老链接突然前台搜不到了，后台显示在售，广告也在跑但几乎没曝光。同行说可能是UPC重复导致Listing被抑制。我不确定这个说法对不对，更担心的是到底只坏了一条，还是同一批码上的链接都有风险。
影响分三层，越往后代价越大。第一层是创建失败，批量上传模板里最常见的两个报错是8541（UPC值无效）和8542（该UPC已被使用），8542意味着这个码已经绑定了别人的ASIN，你的新品根本建不起来。
第二层是变体关系错乱，同一父体下多个子ASIN共用一个UPC，平台会判定你在重复铺货，可能强制合并变体或直接抑制新Listing，典型表现就是后台显示在售、前台搜不到、广告有花费没曝光。第三层是账号层面，如果是批量买来的回收码被识别为违规创建或滥用变体，轻则下架，重则影响账户健康分。
判断优先级很简单：先统计上传报错日志里8541和8542的条数，如果超过SKU总数的5%，就不要再一条条试了，停下来做全量排查，因为能报错的只是撞上冲突的那部分，还有一批是暂时没被发现而已。
我们不是品牌方，在GS1官网注册一个码要花钱还要提交公司资料，之前图省事在第三方批量买的码，一个几毛钱。现在发现里面有一批是重复的，全部换掉成本太高，我想知道到底有没有必要换成官方码，以及已经上架的链接怎么处理。
先做判断：去GS1官方数据库输入这个UPC，看登记的厂商名称是不是你。不是你，理论上你就没有这个条码的使用授权，平台一旦抽查或被人投诉，处理起来非常被动。可执行的做法按成本从低到高排：一是申请UPC豁免，多数平台允许符合条件的卖家提交品牌、产品图片和包装图申请免UPC上架，审核通过后用自有编码；
二是在GS1正式注册，拿到属于自己公司前缀的码段，单个码的年费摊到SKU上并不高，关键在于可追溯、不怕查；三是已经完成品牌备案的，直接用品牌方ID体系上架，从根上绕开UPC。
已经用重复码上架的旧链接，不要直接改UPC字段，改动可能触发Listing重新审核甚至丢失变体关系，更稳的做法是新建正确UPC的链接、迁移库存和评价，或者先开case报备拿到确认后再改。
我们团队五个人都在上新，UPC靠一个共享Excel表领用，经常出现两个人同时填同一行，或者有人从别的表复制粘贴带了旧码进来。每次都是靠平台报错才发现问题，太被动了，想建立一套能落地的流程。
核心思路是把UPC当成有状态的资产来管，而不是当成一列随手填的数字。台账最少要有这些字段：UPC、校验位是否通过、SKU、品名、变体维度（颜色/尺码/容量）、GS1证书号或来源、分配日期、当前绑定的平台和ASIN或ItemID、状态（待用/已用/作废）、责任人。
规则上定三条：一个UPC只能分配一次，作废后永久封存不得回收再用；新码入库时必须同时通过校验位验证和库内查重，两条都过才允许写进台账；跨平台复用同一个UPC是允许的，同一款产品在多个渠道用同一个GTIN本来就是正确做法，但跨产品复用绝对禁止。
执行上，把查重做成上传前的固定动作而不是事后补救，每月做一次全量比对，重点看有没有一个UPC对应了两个以上ASIN的情况，以及作废码有没有被重新启用。这样即使人员流动，台账本身就是审计记录。
读者评论
关于“先做可校”这一步我认同，但实际跑下来脚本只能解决表内重复。跨店铺的那部分得先把各后台导出再合并，字段口径不一致时非常折腾。另外像后缀递增这种逻辑重复，脚本是看不出来的，最后还是得靠台账兜底。所以顺序对，但别指望一步到位。
文中那些损失金额和发现周期看着挺震撼，不过我留意到样本是17个案例、并且大多是出过问题的项目，本身带选择性偏差。精品和铺货两种卖家的代价差得很远，混在一起说平均损失，参考价值会打折扣。
把分配权收归单一责任人这招，小团队里其实很难落地，负责人一休假或离职流程就卡住。我们后来改成一人主责加备份台账、双人复核，代价是流程变慢。另外想问一下，供应商给的历史码，除了查旧记录，有没有更主动的验证办法？