去年大促前两周，一个做家居收纳的卖家半夜给我发消息：主力ASIN被下架，后台提示该商品使用的UPC已被其他ASIN注册。他第一反应是”我买的是正版码”，第二反应是”我去把重复的那个删掉不就行了”。结果三天后，他另一个店铺的五个SKU连着被扫，原因是同一个码池里还有一批码，被另外两个不认识的账号先后注册过。这不是去重能解决的问题，这是一次编码主权事故。
我把这类项目统称为UPC码改造。它听起来像一次数据清洗，实际上一半是数据工程，一半是平台规则博弈，还有一小半是内部流程重建。过去两年我参与了三个店铺群的完整改造，样本覆盖12,400个在售UPC，踩过的坑足够写一本小册子。这篇文章不讲UPC是什么，只讲一件事：当你发现重复码之后，到底应该按什么顺序、什么标准、什么代价去改，以及哪些情况下你根本不该改。
先把结论摆在最前面。如果你的团队现在正在做UPC排查，下面三条判断可以直接决定这个项目是三个月收尾还是拖一年。
绝大多数人把重复码理解成”两个SKU撞了同一个号”，于是解法就是删掉一个。但平台判罚的触发点往往不是重复本身，而是这个GTIN在平台侧登记的主体，和当前售卖主体对不上。平台看三件事：GS1前缀的持有公司、品牌备案后台的品牌归属、以及这个GTIN历史上被哪些账号注册过。
我见过最典型的案例是：一个卖家从第三方渠道买了2000个码，自己内部完全没有重复，但其中37个码曾被另外两个账号注册过同一个类目。这37个码从”重复”角度看毫无问题，从”归属”角度看全是雷。所以排查的第一优先级永远是归属比对，不是内部去重。
顺序错了，项目就永远做不完。冻结是指立刻停用可疑码池中尚未上架的新品建码权限；排查是指全量比对在售、在途、在库、在包装四个状态下的码；替换才是最后一步，按影响面分批执行。
我遇到过一个团队，排查做了六周，期间新品照常建码，照常上架，结果排查结束时可疑码的数量比开始时还多了11%。边放水边排水，是UPC改造最常见的失败模式。
内部系统里没有重复，不等于平台认你。真正的验收口径是：这个GTIN能在GS1数据库、品牌备案后台、平台商品后台三处对上同一个主体，并且这个主体在当前店铺的授权链条内。
我在项目里把这条拆成了五个可量化指标：内部重复率、跨店铺复用率、归属不明率、平台侧冲突率、替换后30天存活率。只盯第一个指标，后面四个会在半年后集中爆发。
把时间线拉长看，UPC问题不是今年才有的。它集中爆发的原因，是上游码源变灰、中游SKU膨胀、下游平台检测升级三件事同时发生。
正规路径是从GS1官方或授权机构申请，按公司主体获得前缀，码的唯一性和归属都是强绑定的。但很多团队早期为了省成本、省时间，走的是第三方批量购码：一次性买几千个码的文本文件，贴上去就用。
问题在于，这类码文件本身可能被卖给多个买家。你在买的时候无法验证它是否已经被出售过，也无法验证它是否已经在某个平台上被注册。更麻烦的是，这类码的前缀通常不属于你的公司，一旦平台要求提供GS1证书，你拿不出来。
第三方码最大的风险不是重复，而是你无法证明它是你的。重复只是这个问题最容易被发现的表象。
一个卖家从500个SKU涨到5000个SKU，通常只用了不到两年，但编码管理制度往往还停留在”运营自己建、自己贴”的阶段。建码的人、贴码的人、上架的人、管库存的人不是同一拨，中间靠一份共享表格传递。
共享表格一旦被多人同时编辑，就会出现典型的时序问题：两个人同时看到空行，同时填入，两个人的码撞在一起，而表格本身不会报警。这类重复在SKU数量低于1000时几乎不会出现，超过3000之后开始指数级上升。
这是很多人忽略的变量。平台对GTIN的校验逻辑这几年一直在加严，从早期只校验格式，到后来校验校验位，再到跨账号比对注册历史，再到和品牌备案体系打通。你五年前埋下的问题，可能今年才被扫出来。
所以当你发现一个ASIN被下架时，要意识到这大概率不是孤立事件。平台的扫描是批量的，你看到的第一个下架通知，通常是整批问题里最先浮出水面的那一个。
我参与的第二个项目是一个三店铺矩阵，主店做家居，两个副店做宠物和户外，三店共用一个码池。最初只有主店的一个ASIN被扫，团队的处理方式是把这个ASIN的UPC换掉重新上架。
两周后，宠物店三个SKU同时被扫，户外店两个。原因是那个码池的重复不是点状的，是批量的，同一个批次的码被拆散了用，主店和副店之间、副店和副店之间都有交叉。你改掉其中一个，只是把这块多米诺骨牌从队列里抽出来，剩下的照样倒。
在码池未做全量体检之前，任何单点替换都是在给下一个下架通知争取时间。这一点我后面讲行动建议时会再展开。
这几个误区我在项目复盘里反复见到，每一个都直接导致改造周期被拉长或成本被放大。
重复只是归属问题的一种表现形式。一个码不重复，仍然可能因为前缀不属于本公司、已被他人注册、或与品牌备案主体不一致而被判违规。
我在项目里做过一次交叉验证：312个最终确认必须替换的码中，只有186个是内部意义上的重复码，剩下126个在内部系统里干干净净，但在平台侧存在归属冲突。如果只做内部去重，会漏掉四成真正的风险。
全量替换的问题不在成本，在于它对在售Listing的杀伤。一个已经积累了评价、排名、广告历史、A+内容的ASIN，换UPC之后大概率需要重建，等于把这个链接的全部历史资产清零。
我见过一个团队在大促前两个月做了全量替换，涉及640个在售ASIN。结果是替换完成后三个月内，店铺整体自然流量下降了约37%，广告ACOS从22%升到41%，因为大量新链接需要重新积累权重。合规上确实干净了，但代价是把当年利润打平。
GTIN豁免是例外通道，不是常规解法。平台设置它的初衷是给品牌方自营商品或特殊品类留口子，申请需要提供品牌资质、商品图片、包装证明等材料，且通过率与品类、账号历史表现强相关。
更关键的是，豁免码在平台规则收紧时属于优先被回收的对象。我跟踪过一批靠豁免上架的商品，在平台一次规则调整后，其中约三成被要求补交GTIN。把豁免当长期方案，等于把一个随时会失效的临时通行证当成护照。
Excel能做的只有字面比对。它查不出前后空格、全角半角、大小写差异造成的”假不重复”，也查不出跨店铺、跨站点、跨主体的语义重复，更查不出外部归属冲突。
我接手过一个案例，团队用Excel做了一轮去重，报告显示重复率为0.3%，看起来很健康。换成系统化比对之后，跨店铺复用率实际是4.7%，外部归属存疑率是3.9%。Excel不是没用，是它的能力边界只覆盖了第一层。
UPC从来不是孤立字段。它联动着FBA入仓标签、外箱标签、产品包装印刷、清关申报信息、库存管理系统主键、广告投放的商品ID映射、以及财务侧的SKU成本核算。
我在第三个项目里犯过一个错误：只改了系统里的UPC和平台后台，忘了同步在途库存的外箱标签。结果1800件货到了海外仓，因为标签与系统登记不一致，被要求重新贴标，光人工和延误损失就吃掉了这个项目四分之一的预算。
排查清单出来之后，最大的问题不是”哪些码有问题”，而是”哪些码现在就得改”。全部改不现实，全都不改风险敞口太大。我用的是一套五步判定树，每一步输出一个明确结论，五步走完，这个码的处置方式就确定了。
真重复指同一个GTIN被多个SKU、多个店铺或多个站点实际使用；假重复指格式差异造成的系统误判，比如前后空格、全角数字、大小写、或者前导零被省略。
先做规范化：去空格、转半角、补前导零、统一大小写，再重新比对。规范化之后仍然撞号的，才是真重复。
假重复直接批量修正数据，不涉及平台操作，成本近乎为零。这一步能消掉大约三成的告警量，先做这一步能让后面的工作量立刻降下来。
这一步决定的是”你有没有资格用这个码”，比重复本身重要得多。我按四个问题依次问：这个GTIN的GS1前缀属于哪个公司？这个公司和我当前的品牌备案主体是什么关系？这个GTIN在平台侧有没有被其他账号注册过？我能不能拿出对应的授权或申请凭证？
四个问题里只要有一个答不上来，这个码就进入”归属存疑池”，优先级直接提到最高。归属存疑的码，不管有没有重复，都应该优先替换。
影响面看三个维度：这个SKU贡献多少GMV、当前库存有多少、是否在大促窗口内。紧迫度看两个信号：平台是否已经发出过警告、同类目其他卖家是否已经出现批量下架。
我的经验口径是：单SKU月GMV占比超过5%、且平台已有过警告的，属于最高优先级，48小时内启动处置；单SKU月GMV占比低于0.5%且无任何平台信号的，可以排到下一个改造批次。
代价不只算钱，要算四块：新码采购成本、平台侧重建Listing带来的流量损失、库存标签重贴的人工与物流成本、以及内部系统与财务口径的调整成本。
我通常用一个粗略比值做初筛：改造总代价除以这个SKU未来12个月的预期毛利。比值超过0.6的，说明这个SKU本身不值得大动干戈，可以考虑直接清库存退场，用释放出来的资源去做新链接。
在动手之前就要把验收标准写死，否则项目永远收不了尾。我在项目里固定用五个指标：内部重复率归零、跨店铺复用率归零、归属不明率归零、平台侧冲突清零、替换后30天Listing存活率不低于95%。
| 重复类型 | 归属状态 | 影响面 | 建议处置 | 优先级 |
|---|---|---|---|---|
| 真重复 | 归属清晰 | 高GMV | 保留高价值SKU的码，替换低价值SKU | P1 |
| 真重复 | 归属清晰 | 低GMV | 排入常规批次，淡季执行 | P3 |
| 真重复 | 归属存疑 | 任意 | 全部替换，优先于其他任何工作 | P0 |
| 假重复 | 归属清晰 | 任意 | 批量修正数据，不动平台 | P2 |
| 无重复 | 归属存疑 | 高GMV | 立即替换，同步准备平台举证材料 | P0 |
| 无重复 | 归属清晰 | 任意 | 不动，纳入季度例行复查 | P4 |
这张矩阵是我在项目里贴在墙上的那张表。它的价值在于把”要不要改”这个模糊讨论，变成了一次查表动作。团队不需要每次开会重新辩论，只要把码的三个属性填进去，结论就出来了。
讲完方法论，说一个完整跑通的案例。这是我在2024年参与的一个三店铺群改造项目，主店家居收纳，副店宠物用品和户外装备，覆盖亚马逊北美、欧洲两个站点，加上沃尔玛和eBay的少量在售商品。
项目起点是主店两个ASIN被下架，触发全面排查。全量样本12,400个在售GTIN，其中亚马逊体系占78%，其余为其他平台。
排查的第一难点不在内部数据，在于要拿到”这个GTIN在平台侧被谁注册过、挂在哪个ASIN上、属于哪个品牌”这类外部信息。内部ERP里只有自己的数据，看不到冲突的另一面。
这一步我用的是数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）做跨平台商品数据的拉取和比对。它的价值在于能把多个平台、多个站点的商品数据按GTIN维度归集起来，让你看到同一个码在不同店铺、不同站点上的挂载情况，而不是只盯着自己系统里那份名单。
具体做法是：先把内部SKU-码-店铺的映射表导出来，再按GTIN去比对平台侧数据，输出三张表，跨店铺复用表、外部归属冲突表、平台注册历史表。这三张表合起来，就是改造的作业底稿。
外部比对之前，内部数据先要规范化并且做一轮自查。我用的是下面这段查询逻辑，跑完大概能覆盖八成以上的内部问题。
-- UPC 重复与跨主体复用检测（示意）
-- 前提：product_catalog 表已完成规范化（去空格、转半角、补前导零）
SELECT
upc,
COUNT(DISTINCT sku_code) AS sku_cnt, -- 一码多SKU
COUNT(DISTINCT shop_id) AS shop_cnt, -- 跨店铺复用
COUNT(DISTINCT site) AS site_cnt, -- 跨站点复用
COUNT(DISTINCT asin) AS asin_cnt, -- 挂载的ASIN数量
COUNT(DISTINCT brand_owner) AS brand_cnt, -- 归属主体数量
GROUP_CONCAT(DISTINCT shop_name) AS shop_list
FROM product_catalog
WHERE upc IS NOT NULL
AND upc <> ''
AND listing_status IN ('on_sale', 'in_transit', 'in_stock')
GROUP BY upc
HAVING sku_cnt > 1
OR shop_cnt > 1
OR asin_cnt > 1
OR brand_cnt > 1
ORDER BY shop_cnt DESC, sku_cnt DESC;跑完的结果超出预期。全量12,400个码里，内部判定重复的1,240个，占10%；跨店铺复用的583个，占4.7%；而通过外部比对发现的归属存疑码486个，占3.9%。如果只跑内部SQL，会漏掉近四成的风险。
按前面那张矩阵把486个归属存疑码加1,240个内部重复码做交叉筛选，最终确认必须替换的是312个，涉及在售ASIN 218个。
312个不可能一次改完。我们按四批排期：第一批48个，选的是低代价高风险类目，用来跑通流程；第二批96个，集中在副店，验证跨店铺协同；第三批112个，主店中等价值链接；第四批56个，是主店核心链接，留到淡季单独处理。
每一批都有一个止损点：如果替换后30天内，这批ASIN的存活率低于90%，或者店铺整体自然流量周环比下降超过8%，就暂停下一批，先复盘。止损点写进项目计划里，比事后补救有用得多。
项目从启动到第四批完成用了112天，之后又观察了90天。五个核心指标的最终结果是：内部重复率从10%降到0；跨店铺复用率从4.7%降到0；归属不明率从3.9%降到0.2%（剩余部分为平台未公开数据的盲区）；平台侧冲突清零，期间没有新增下架通知；替换后30天Listing存活率93.6%，略低于95%的目标线。
存活率没达标的原因很具体：第四批56个核心链接里有4个因为评价数量太少、权重基础薄，替换后重建失败，最终选择合并到新链接。这部分损失在计划时没有被充分预估，是个教训。
第一个没做对的是没有同步在途库存的标签。1800件货到海外仓后发现标签与系统不一致，被迫回仓重贴，直接吃掉预算四分之一。正确做法是在冻结阶段就把在途库存单独拉出来，作为替换批次的硬约束条件。
第二个没做对的是广告账户的商品ID重映射。替换后的新ASIN在广告后台需要重新绑定，团队以为自动继承，结果有两周时间广告投向了已下线链接，白烧了预算。这一步现在被我写进了标准检查清单。
第三个没做对的是没有提前准备平台举证材料。有几个归属存疑的码，其实可以通过品牌授权链条证明是合法使用的，但因为历史授权文件没有归档，只能硬换。UPC改造里，能举证的码就是能保住的码，归档比排查更省钱。
下面按重复率和归属状态分了四种情况，每种情况的处置动作和节奏都不一样。你可以直接对着自己的排查结果找对应行。
这是最轻松的情况。不建议启动专项项目，把它并入常规的数据治理节奏即可。
这种情况下的核心目标是防止问题扩大，不是清理历史。过度投入反而会打乱正常的运营节奏。
这是最常见的情况，也是最需要节奏控制的情况。建议启动专项，但不要一次做完。
情况B的关键判断是：归属不明的那部分，优先级永远高于单纯重复的那部分。因为重复只是数据问题，归属不明是合规问题。
这种情况已经不能叫改造了，应该叫重建。我的建议是停线治理，先止血再手术。
停线治理最难的不是技术，是内部沟通。运营会觉得停新品等于停业绩，这时候需要把风险敞口量化出来：是停三个月新品的损失大，还是整个店铺被封的损失大。这个账算清楚，沟通就顺了。
这是优先级最高的情况，不管重复率是多少，都应该立即启动替换。前缀不属于本公司，意味着你在平台要求举证时拿不出任何有效文件。
这类情况的隐藏风险是，你可能同时得罪两头：原前缀持有方如果发现你在用，可以投诉；平台如果抽查，你无法举证。双重风险叠加，没有拖延空间。
改造项目里真正难的从来不是技术动作，是取舍。下面五组取舍是我在项目里反复遇到的，每组我都会给出自己的判断标准和倾向。
这是最核心的一组取舍。改码意味着可能丢掉这个链接的评价、排名、广告历史；不改意味着风险敞口持续存在。
我的判断标准是看这个链接的”可重建性”。如果它的核心资产是评价数量和排名权重，重建成本高，值得用其他方式保（比如举证材料、平台申诉）；如果它的核心资产是产品和供应链本身，重建成本低，那就果断改。
一个简单的测试：如果这个链接明天归零，从零做起需要多久能回到当前水平？超过6个月的，优先保；低于3个月的，优先改。
全量换的唯一优势是彻底，唯一劣势是代价。局部换的风险是遗漏，但只要排查做扎实，遗漏是可控的。
我倾向局部换，但有个前提：局部换的”局部”必须由归属状态决定，不能由GMV决定。很多团队的做法是先换低价值SKU，把高价值SKU留着观察，这恰恰搞反了，高价值SKU一旦出问题，损失更大，而且它往往是平台重点关注对象。
自购GS1是长期方案，成本高、周期长，但归属清晰、平台认可度高、可扩展性强。平台豁免是短期方案，成本低、上手快，但规则一变就可能失效。
我的倾向是：新品一律走自购GS1；存量商品根据价值和库存周期决定，库存周转快、剩余生命周期短的SKU可以用豁免过渡，但要在系统里标记为”临时状态”，设到期提醒。
大促前改的风险是流量损失叠加在全年最高峰，代价被放大；淡季改的风险是团队注意力分散，执行质量下降。
我的口径是：正常情况下，P0级问题（归属存疑、GS1前缀不属于本公司）不管什么时候都要改；P1及以下的问题，一律排到大促结束后一个月再动。大促前一个月只做冻结和排查，不做替换。
一次改到位的吸引力在于管理成本低，只需要一次沟通、一次排期、一次复盘。分批滚动的吸引力在于风险可控，每一批都能验证流程。
我几乎总是选分批滚动，因为UPC改造有一个绕不开的特性：你永远会在第一批执行时发现排查阶段没考虑到的问题。库存标签、广告映射、财务口径、清关信息，这些联动项在纸面上想不全。分批的价值不是分散风险，是给自己留出纠错窗口。
三个项目做完，我最大的感受是：UPC改造最容易失败的地方不在项目期间，在项目结束之后。项目期间大家注意力集中，规则执行到位；项目一结束，约束放松，半年后新的重复又开始出现。
所以我现在的做法是把治理动作拆成三层，分别放在不同的时间尺度上。
不一定要跑完整的外部比对，但至少要做内部规范化加唯一性核查，并把新增的码纳入归属验证流程。季度复查的样本量小、成本低，能拦住绝大多数新增问题。
抽查的逻辑是随机抽样加高风险优先。高风险指的是新上架商品、新店铺、新类目，这三类场景最容易引入未经校验的码。抽查发现的问题当月处理，不积累到下个季度。
这三道校验做进系统之后，重复码的产生概率会下降一个数量级。剩下的那部分，主要来自外部冲突，属于需要例行复查才能发现的问题。
UPC治理的终局形态不是一次完美的清理，而是一套让问题不再累积的日常机制。把它当成项目做，你会每两年重来一次；把它当成流程做，成本会摊薄到几乎感觉不到。
回到开头那个半夜发消息的卖家。他最后的处理方式是：花了一周做全量排查，冻结了可疑码池，把218个高风险码分了四批替换，用了一个季度收尾。过程中掉了两个链接，但没有被封店。他后来说的一句话我记到现在：早知道会这样，三年前就该花这一周。
UPC改造这件事的反常识之处在于，它的成本和时间不成正比。排查阶段看似最费事，实际是最省钱的环节；替换阶段看起来最简单，实际是风险最集中的环节。很多人把精力放反了。
如果你今天就想动，我给三个立刻可执行的动作。
排查数据的拉取和跨平台比对，我建议借助专业工具来做，比如前面提到的数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys），它的跨平台商品数据归集能力能让你在归属比对这一步省下大量人工。但工具只能给你底稿，真正决定项目成败的，是你有没有在动手之前把验收口径、止损点和分批节奏定下来。
UPC不是一串数字，它是一张所有权凭证。你真正要收回的不是码本身，是在平台侧证明”这是我的商品”的能力。想清楚这一点，后面所有技术动作都会变得简单。
我们做跨境多站点，SKU两万多个，之前一直靠运营在表格里手动筛重复，结果改完一轮上线，还是有一批同码不同款被翻出来，返工非常痛苦。我就想知道，全量排查到底该用什么口径、按什么顺序做，才能一次查干净。
分三步。第一步是归一化，把所有码统一成12位字符串再比对：去掉首尾空格和不可见字符，全角转半角，统一大写，EAN-13去掉首位补零的0还原成UPC-A。第二步分两层判定，归一化后完全相同的叫硬重复，必须处理；码不同但实际指向同一实物（同款、同色、同尺码，只是包装规格改过）的叫软重复，先登记不急着动。
第三步用校验位兜底，按GS1的mod-10规则重算第12位，也就是从左到右奇数位乘3、偶数位乘1，求和取模10后用10减余数，校验位算不过的直接归到脏数据单独一列，这类码往往不是重复问题，而是录入时被截断或串位了。
全量跑完后，用码去反查对应SKU数，得到一张只有码和SKU计数的中间表，计数大于1的就是重复清单。这张表要作为全项目唯一的底表，不要在不同人手里各维护一份，否则后面定标和验收对不上账。
最头疼的不是找出重复，是找出来之后拍不了板。运营说保留自己先建的，采购说保留后面那个正规渠道买的码，谁也说服不了谁，最后往往是谁嗓门大听谁的，改完又后悔。
保留规则建议按四条优先级排，不要凭感觉。第一，有GS1正规授权的自有前缀码，优先于早期渠道零散买来的码；第二，上架时间早、近90天销量高、评论沉淀多的那个优先；第三，库存和在售状态健康的优先；第四，前三条打平的时候，保留主链接所在的那个码。
判断依据是：码本身没有价值，价值挂在这个码背后的listing历史权重上，所以选择标准要跟着历史数据走，而不是跟着谁先录入走。具体操作上，被合并掉的码不要物理删除，只在SKU档案里加一列替代码指向保留码，同时把旧码状态置为冻结。
原因是历史订单、报关资料、平台后台的旧记录都还引用着它，删掉会造成对不上账；冻结既能让新业务不再使用，又保住了可追溯性。
我们上一次改编码，有两条主力链接第二天后台就编辑不了了，当时整个组都慌了，到处找人问是不是被封了。所以这次再动UPC，我最担心的不是查不出来，而是改的过程中把在跑的链接改出事。
风险是真实存在的，主要来自平台对商品编码与listing一致性的校验，所以顺序必须是先做映射表、再动线上。映射表至少包含旧码、新码、SKU、站点、生效时间、操作人六列，它是灰度推进和事后回滚的唯一依据。
第二步按站点灰度，先挑占比最小的站点改，观察7到14天，看有没有出现编辑权限受限、后台报错任务或流量异常，正常再推全量。第三步，如果品牌备案已经完成，尽量走备案后的编码免填通道，把改动落在后台编码字段上，而不是新建链接重建权重。第四步准备回滚路径，包括换回旧码的操作步骤和对应权限，别等到出事才去找。
观察指标盯三个：链接能否正常编辑保存、近7天曝光和订单有没有异常下滑超过10%、后台有没有产生编码相关报错。这三项在灰度站点都正常，再推下一批，永远不要一次性全量。
我们老板问进度的时候，运营汇报的一直是“已经改了多少条”，可我心里没底，因为改完不等于改对，更不等于平台认。我想知道有没有一套能拿出去汇报的验收口径，而不是靠感觉说一句差不多了。
排期上，两万SKU量级通常拆成排查、定标、灰度、全量、归档五个阶段，排查阶段会占到一半以上时间，压缩它基本等于埋雷。验收不要看改了多少条，看三组数：第一是残留重复率，用最终底表算重复码对数除以总码数，目标压到千分之一以内；
第二是校验位通过率，改造后全量重算一次，通过率应该是100%，只要有一个不过，说明中间某个环节又产生了脏数据，要回查；第三是业务侧稳定性，改造完成后的30天内，因编码不一致导致的链接异常、后台报错、报关退单数量应该为零。
做法是项目结束当天记录一次这三个数，30天后再记录一次，两次都达标才叫落地，只有第一次达标那叫改完了，不叫改好了。
读者评论
先冻结再排查说得轻巧，实际排期压着，冻结建码权限运营第一个不同意。我们当时只冻了可疑批次对应的类目，结果分层不彻底，还是有新品混进去。另外第三方码想补GS1证书基本补不了，前缀不是自己的，最后只能整批换，成本比文里估的高不少。
想追问一个数：312个最终替换的码，替换后30天存活率大概多少？文中把它列为验收指标但没给参考阈值。我们做过一百多个的小范围替换，存活率约八成五，掉的那批基本是外包装旧码没清干净，平台扫码又对上了，属于执行问题不是码的问题。
方法论没问题，但对SKU不足千的店铺可能偏重。我们四百多个SKU，码是按公司主体从GS1申请的，两年只出过两次人工录入错误，改一下就行。需要全量体检和外部归属比对的，感觉还是码池来源复杂、多店共用的矩阵卖家。中小卖家照全流程走，容易自己吓自己还耗不起。