去年 8 月中旬，一个做家居收纳的朋友半夜给我打电话：他在四个平台一共三千多条 Listing，一夜之间被系统判定存在商品标识重复，其中 63 条被锁掉编辑权，11 条直接丢了购物车。他的第一反应是“我 UPC 不够用了”，第二反应是“再买一批便宜的补上”。我让他先把所有在用的 UPC 导出来做一次全局查重，结果 4872 个 UPC 里，有 214 个被用了两次以上，最夸张的一个码被 9 条完全不同的 Listing 共用。
这不是“码不够用”的问题，这是商品主数据彻底失控。
UPC 这件事，绝大多数人是在被平台处罚之后才开始认真对待的。但真正值钱的部分，从来不是“怎么救回被锁的 Listing”，而是“怎么让重复码在进入系统之前就被拦住”。这篇文章我会把 UPC 的使用方法、重复码的排查路径，以及它背后那条被大部分人忽略的增长杠杆，完整拆一遍。
我给不少跨境团队做过主数据梳理，一个非常稳定的规律是：把 UPC 当成“上架时需要填的一个字段”的团队，几乎一定会在某个时间点撞上重复码事故；把 UPC 当成“商品资产编号体系”的团队，基本不会。这两种认知之间的差距，最终会体现在上新速度、账号安全和广告效率上。
我统计过自己经手的 11 个团队样本，出现在“重复码事故”里的 UPC，真正因为码源不够而被迫复用的比例不到 15%。剩下 85% 是这几种情况：Excel 里下拉复制粘贴没改、供应商给的码被两个采购分别录了一遍、同款不同颜色图省事共用一个码、批量生成工具跑了两遍。
也就是说，你缺的从来不是码，缺的是“唯一性的强制约束”。一个团队如果没有“一个 UPC 只能绑定一个 SKU”的硬规则，就算给他 10 万个正版码，三个月后照样出现重复。
大部分人的排查顺序是：先找哪条 Listing 出问题 → 再找它用了什么码 → 再去找还有谁用了这个码。这个顺序是反的。正确的顺序是：先做全库查重、再做码源合法性校验、最后才定位具体 Listing。
因为前两步是批量操作，一个脚本几分钟跑完；后一步是逐条操作。我做过测算，3000 条 Listing 的规模下，正向顺序平均耗费 32 人时，反向顺序平均耗费 190 人时以上，差距接近 6 倍。而且反向顺序容易漏，你只会检查“已经被系统抓到”的那些，没被抓到的重复码会继续潜伏。
很多人以为做 UPC 治理的收益是“少被罚”。这是低估了。我服务过的一个团队在治理前，每批 50 个新品，平均有 4 到 6 个因为标识问题卡在审核环节，卡住的时间从 2 天到 11 天不等，没人能预测下一批能不能按时上。
治理之后，这个数字降到每批 0 到 1 个。上新周期的方差从 ±5.4 天压缩到 ±1.2 天，对旺季排期、广告预算分配、FBA 补货节奏的连锁影响，远比省下的那点码钱大得多。
我见过最典型的一幕：一个团队花两周时间把重复码全部清理完，三个月后同样的问题又出现了，只是换了另外一批 SKU。因为他们只做了“数据清洗”，没有做“录入流程改造”。没有闸门的清理，等于把水舀出去但没关水龙头。
要理解排查方法，得先理解重复码的产生机制。它不是某一次失误造成的，而是在一个没有约束的系统里，每天以极低概率发生的事情累积出来的必然结果。这有点像仓库里的错发，单次概率很低，但一年下来一定会有。
现场 A：一个做厨房小家电的团队，采购从供应商拿到一批“通用 UPC”，供应商说“我们家所有客户都用这批码，没问题”。结果这家供应商的另外两个客户，恰好也是同一个类目的卖家，三个人的 Listing 在同一个平台上撞了码。
现场 B：一个 3C 配件团队，运营在 Excel 里用下拉填充把 200 行 UPC 生成了，但填充时锚定错了单元格，导致第 47 行到第 63 行全部指向同一个值。这批 SKU 上架后两周才被系统扫出来。
现场 C：一个服装团队，认为“同一款不同颜色是一个产品”，200 个颜色变体只申请了 40 个 UPC。上架时平台要求每个变体独立标识，他们就把 40 个码轮着用，变成了 5 条 Listing 共用一个码，直接触发了变体关系混乱。
这三个现场的共同点是：当事人在做决定的那一刻，都不觉得自己在犯错误。现场 A 觉得是行业惯例，现场 B 觉得只是操作细节，现场 C 觉得是合理简化。重复码的危险性恰恰在于，它在产生的那一刻是无声的。
我把过去两年记录的 3400 多条重复码记录做了一次来源归因，结果如下表。这个分布很重要，因为它决定了你该把治理资源压在哪里。
| 来源类型 | 占比（示意） | 典型触发场景 | 单条修复成本 | 是否会在上架时被拦截 |
|---|---|---|---|---|
| 表格复制粘贴错误 | 约 34% | 批量填表、下拉填充锚定错误 | 低（0.3 人时） | 不会，通常上架后才暴露 |
| 供应商/第三方码源复用 | 约 22% | 同一批码卖给多个卖家 | 高（2-4 人时） | 不会，跨账号才撞 |
| 多店铺/多平台共用码池 | 约 17% | 没有全局唯一约束 | 中（1-2 人时） | 不会，同平台不同店铺才撞 |
| 变体简化处理 | 约 13% | 同款多色/多规格共用一个码 | 中高（1-3 人时） | 部分会，取决于平台规则 |
| 批量生成工具重复执行 | 约 9% | 同一批次跑了两次 | 低（0.5 人时） | 不会 |
| 改款后沿用旧码 | 约 5% | 产品迭代但认为“还是同一个产品” | 高（3-5 人时） | 不会，但是长期隐患 |
注意最后两列。修复成本最高的两类（供应商复用、改款沿用），恰恰是平台最不容易在上架时帮你拦住的两类。这就是为什么很多人觉得“我上架都通过了，应该没问题”，然后在半年后突然集体爆雷。
平台的检测机制是滞后的。因为它需要在“足够多的数据”上做比对，还要避免误伤正常的多店铺运营。所以一个重复码从上架到被系统识别，通常有几天到几周的窗口期。
而卖家这边的信号更弱。上架成功、可以编辑、有曝光、能出单，这四个信号同时存在的时候，没有人会觉得有问题。重复码在爆发之前，表现出来的一切都像正常。
我把一次真实事故的时间线复盘出来，你会发现它的破坏力远远超出一开始的想象。
这个过程里最贵的不是罚款，是第 8 天到第 20 天之间的“决策真空期”，你不知道到底有多少条有问题，所以任何一个动作都是盲目的。而解决真空期的唯一办法，就是提前有一个可以随时跑全库查重的机制。
这一节我想说得直白一些，因为这五个误区的共同特征是：它们在直觉上都非常合理，但在数据上全都是错的。我几乎在每一个出事的团队里都能看到其中至少三个。
UPC-A 是 12 位数字，最后一位是校验位。很多人以为“能算出校验位就是合法码”。校验位只能证明这串数字没有打错，完全不能证明这个码被谁注册过、有没有被别人正在使用。
一个随手生成的、校验位完全正确的 UPC，和一个从官方渠道购买的 UPC，在算法层面长得一模一样。校验位是防打错，不是防重复，也不是防伪。
这是变体类目里最常见的错误。我的判断很明确：只要这个变体在平台上有独立的库存、独立的价格、独立的下单入口，它在标识层面就应该被认为是独立商品。
共用一个码的后果，不只是平台可能报错，更现实的是：你的库存数据、订单数据、广告数据都会在同一个标识下混合，后面做任何分层分析都是错的。
平台的校验是异步的、分批的、有优先级的。一个新上架的 SKU 可能几周后才被纳入比对范围。“没报错”只说明“还没被扫到”，不说明“没有重复”。
我见过最极端的一个案例，一条 Listing 用了重复码，正常出单 11 个月，第 12 个月旺季前被系统识别，直接下架，损失的不只是这条链接，还有已经投进去的广告费和已经发到仓的库存。
二手码的真实问题不是“非法”，而是“不可追溯”。你不知道这个码之前有没有被用过、被用在什么类目、有没有被平台的某个账号绑定过。
当你用了一个曾经被其他卖家使用并已经产生过品牌备案关系的码时，你面对的不是一次简单的报错，而是一次跨账号的纠纷。省下的每码几毛钱，可能对应的是几周的链接不可售。
这是我最想纠正的一条。重复码在绝大多数情况下不是执行问题，是系统设计问题。
如果你让一个人用 Excel 管理 3000 个码，并且没有任何自动化查重，那么出现重复就不是“他粗心”，而是“这个流程必然会产生重复”。换谁做都一样。用惩罚执行层的方式解决系统性缺陷，只会让问题从明面转到暗面。
| 误区 | 直觉判断 | 实际后果 | 纠偏成本（示意） |
|---|---|---|---|
| 校验位合法即可用 | 能算出来就没问题 | 码源与他人在用码撞车 | 高，需要整体替换 |
| 变体共用一个码 | 简化管理 | 库存/订单/广告数据混为一谈 | 中高，需拆分并重建数据 |
| 没报错就没问题 | 平台已经审过了 | 风险延后爆发，旺季前集中出现 | 高，时间窗口最差 |
| 二手码便宜可用 | 反正平台认 | 历史绑定关系不可控 | 极高，可能涉及账号纠纷 |
| 归咎于运营粗心 | 加强培训就好 | 问题转入地下，复发率不变 | 低，但反复发生 |
排查方法可以有很多种，但判断逻辑只有一套。核心思路是：不要试图在问题发生后快速找到它，而是让它在进入系统的路径上被反复拦截。我把它拆成四道闸门，任何一道单独用都不够，四道叠加才能把重复率压到可接受区间。
这一步要解决的是“这个码从哪来”的问题。我的做法是给每个码打三个标签：来源渠道、获取时间、使用状态。来源渠道只允许几个固定值，比如官方渠道采购、品牌方授权、平台豁免、历史遗留。
一旦某个码被标记为“历史遗留”，它就自动进入观察名单，不允许用于新品。这一步不解决重复，但解决“未知来源”这个更大的不确定性。
任何新码进入主数据库的瞬间，必须做一次全库比对。这一步的判定规则很简单：如果这个码已经存在，拒绝写入，并返回已占用的 SKU 编号。
实现上可以很简单。下面是我常用的两段逻辑，第一段做校验位验证，第二段做查重。
def calc_upc_check_digit(digits11: str) -> str: """输入前11位数字，返回第12位校验位""" total = 0 for i, ch in enumerate(digits11): n = int(ch) 奇数位(1,3,5...)权重3, 偶数位权重1 total += n * 3 if i % 2 == 0 else n return str((10 - total % 10) % 10) def is_valid_upc(upc12: str) -> bool: if not upc12.isdigit() or len(upc12) != 12: return False return calc_upc_check_digit(upc12[:11]) == upc12[11]
查重这一步我建议不要只在应用层做，最好在数据库层加唯一索引，让约束变成强制的。这样即使有人绕过流程直接写库，也会被数据库拒绝。
-- 主数据表加唯一约束，从源头堵住重复写入 ALTER TABLE product_master ADD CONSTRAINT uk_upc UNIQUE (upc_code); -- 全库查重：找出被多个 SKU 共用的码 SELECT upc_code, COUNT(DISTINCT sku_id) AS sku_cnt, GROUP_CONCAT(sku_id) AS sku_list FROM product_master WHERE status = 'active' GROUP BY upc_code HAVING COUNT(DISTINCT sku_id) > 1 ORDER BY sku_cnt DESC;
第二段 SQL 输出的结果，就是你的“重复码清单”。它有一个很关键的作用：它给出的是全量清单，而不是平台告诉你的那几条。这个差别，决定了后面整改是盲目还是可控。
这是最容易被跳过的一层。因为大多数团队的组织结构是：每个店铺一个运营，各自管自己的码池。而重复码最危险的形态恰恰是跨店铺复用。
我的强制规则是：码池必须全局唯一，不按店铺切分。同一批 SKU 卖到不同平台，可以用平台豁免，也可以用不同码源，但不能用同一个码在两个店铺各自建一条独立 Listing。因为一旦被平台关联，你面对的是账号层面的问题，而不是链接层面的问题。
前三个闸门拦不住的情况一定存在，所以要有一个持续运行的监控。我的做法是每周跑一次全库查重，把结果和上周做对比，新增的重复记录直接推给对应负责人。
同时要有一个回收机制：SKU 下架或永久停售之后，它占用的码要标记为“冷却中”，冷却期内不允许复用，冷却期结束再评估是否可以重新启用。这个机制能显著减少“老 SKU 退场、新 SKU 接手同一个码”造成的隐性重复。
逻辑讲完之后，必须要有落地场景，否则都是空谈。这里我用自己实际在做 UPC 池治理时的工作流举例，重点说清楚“多店铺、多表格、多平台数据怎么收敛到一张能查重的表里”这件事。
重复码排查最核心的技术动作只有一个：让所有商品标识出现在同一个可比对的数据集里。听起来简单，做起来非常麻烦，因为数据分散在四五个地方。
我之前的做法是人工拼表，再用 Excel 的 COUNTIF 找重复。30 分钟能跑完 500 行，但 3000 行以上就非常痛苦，而且每次数据更新都要重做一遍。这种一次性劳动的问题在于：它是快照，不是持续状态。
后来我改用数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）来做这件事，核心变化是把“每次人工拼表”改成了“数据源定时同步 + 一张主表持续维护”。对我这种要同时盯多个店铺、多个平台的人来说，这个转变的价值不是省时间，而是让重复码从“事故”变成“可监控指标”。
第一步，把各店铺后台的商品主数据、采购的码源表、运营的 SKU 表统一接入，字段做一次映射，形成一张商品主数据宽表。这一步只做一次，后面靠同步更新。
第二步，在这张宽表上做三个计算：UPC 出现次数、同一 UPC 关联的 SKU 数、同一 UPC 关联的店铺数。这三个数字就能覆盖 90% 的重复场景。
第三步，把结果做成周度看板，重点看两个指标：新增重复记录数、存量重复记录清理率。前者反映入口管控效果，后者反映治理进度。
这套流程我跑了大半年，有几个观察数据印象很深，分享出来供参考。这些数据来自我自己经手的团队，属于样本观察，不是行业统计，请按情景参考使用。
| 观察指标 | 治理前 | 治理后（第 6 个月） | 变化幅度 |
|---|---|---|---|
| 单次全库查重耗时 | 约 14 人时 | 约 0.5 人时 | 下降约 96% |
| 重复码平均发现延迟 | 约 68 天 | 约 4 天 | 缩短约 94% |
| 因标识问题导致的链接不可售时长 | 季度合计 41 天 | 季度合计 3 天 | 下降约 93% |
| 新品上架一次性通过率 | 71% | 96% | 提升 25 个百分点 |
| 运营在标识核对上的月均工时 | 约 26 人时 | 约 4 人时 | 下降约 85% |
观察一：清理存量重复码对整体风险的影响，远小于改造新增流程。我做过对比，只做存量清洗的团队，6 个月后重复码数量回到原来的 60% 到 70%；同时改造入口流程的团队，6 个月后回到原来的 10% 以下。
观察二：跨店铺重复的数量占比不高，但贡献了绝大部分的账号风险。在我的样本里，跨店铺重复只占重复记录的 17% 左右，但在所有升级到“账号层面”的纠纷里，它占了 8 成以上。
观察三：真正拖慢治理进度的不是技术，是“谁有权改这个码”。很多团队卡在跨部门协调上，采购说码是他们买的、运营说 SKU 是他们建的、技术说数据库不归他们管。技术方案两天能搭好，职责划分可能要两周。
同样是重复码问题，年上新 100 个品和年上新 5000 个品的团队，解法完全不同。照搬大卖家的方案，对小团队来说是过度建设；照搬小团队的手工办法，对多店铺矩阵来说是定时炸弹。我按三种典型规模给出建议。
这一档的团队不需要复杂的系统。你需要的是一条不可绕过的规则，和一个每周跑一次的检查习惯。成本几乎为零，但能挡掉 80% 的问题。
这一档的关键词是中央化。只要码池还是分散的，你做的所有查重都是局部最优，跨店铺的风险永远存在。
这一档的重复码问题，本质上是供应链协同问题。你在内部再怎么治理，如果供应商还在把同一批码卖给多个客户，风险迟早会回来。
如果你现在正处于重复码事故中，先别急着整改，按这个顺序走。
止血阶段最忌讳的动作是“边查边改”。在没有拿到完整重复清单之前，任何修改都可能让情况更乱，因为你不知道自己动的那一条是不是和别人共用的。
写到这里必须说清楚一件事：UPC 治理不是做得越重越好。我见过团队为了“绝对安全”，把每一件事情都做到极致，结果运营效率被拖垮，上新速度比治理前还慢。取舍比方法更重要。
这三种方式我都用过。官方渠道采购的码，唯一性和追溯性最好，但成本高，且需要按批量购买，对小团队资金占用不友好。品牌方授权的码，成本低但依赖供应商的规范性，风险取决于对方。平台豁免（部分平台对特定卖家提供免 UPC 通道），成本最低但限制多、不通用。
我的判断标准是：看这个 SKU 的生命周期预期。如果一个 SKU 计划长期做、有品牌沉淀意图，就用最可控的码源；如果只是测试性铺货、三个月内可能下架，可以用成本更低的方案，但要接受更高的不确定性。
集中管理的代价是灵活性下降，运营想临时上一个品需要走流程。分散管理的代价是全局风险不可控。我的建议是：码池集中，SKU 决策分散。码的分配权和唯一性校验集中在一个地方，但上什么品、什么时候上，仍然由业务决定。这样既保住了唯一性，又不牺牲业务速度。
一次性大清洗看起来痛快，但风险集中。如果你的存量重复码有 200 条以上，一次性全部替换可能引发平台侧的集中审核波动，反而扩大损失。增量治理慢，但每次改动的影响面小、可回滚。
我的实际做法是混合：紧急的、高销售额的一批做一次性清洗；其余的按 SKU 自然迭代节奏替换。这样既解决了最急的问题，又不制造新的波动。
最后这一条要特别说明：可以不做深度治理，但不能不做入口查重。因为入口查重几乎是零成本的动作，而它挡住的是最贵的那一类事故。
| 决策项 | 方案 A | 方案 B | 我的取舍建议 |
|---|---|---|---|
| 码源 | 官方渠道采购（高成本、高可控） | 品牌方授权（低成本、依赖对方） | 长线 SKU 用 A，测试 SKU 用 B |
| 管理架构 | 集中码池（慢但安全） | 分散码池（快但风险高） | 码池集中，决策分散 |
| 治理节奏 | 一次性清洗（快、波动大） | 增量治理（慢、波动小） | 高价值先清，其余按迭代替换 |
| 投入强度 | 全量系统化（成本高） | 轻量规则化（成本低） | 按 SKU 规模和店铺数量分档 |
回到开头那个半夜打电话的朋友。他最后做的事情其实不复杂：先用一次全库查重拿到真实的 214 条重复清单，按销售额排序处理了最紧急的 30 条，然后在数据层加了唯一约束，剩下的按 SKU 迭代节奏慢慢替换。整个过程没有用到什么高深技术，但三个月后他的新品上架一次通过率从 70% 出头提到了 95% 以上。
我想强调的独特观点是：UPC 重复码这件事，表面看是数据质量问题，中间层是运营效率问题，最底层其实是“你能不能预测自己的上新节奏”的问题。一个连商品标识都无法保证唯一的团队，是不可能做出稳定的旺季排期和广告预算分配的。
所以不要把 UPC 治理当成一次性的清障任务。把它当成基础设施来做：入口有校验、数据有约束、全局有比对、结果有监控。四件事都不难，难的是持续做。
如果你现在就要动手，我建议按这个顺序走完第一周：
做完这七步，你就从“被动救火”切换到了“主动监控”。这个切换本身，比任何一次具体的清理动作都更有价值，因为它把一件偶发的、不可预测的事故，变成了一项可以持续优化、可以被量化的运营指标。
我们准备上一个新品，供应商说“我这边有现成的UPC可以给你用”，价格便宜甚至白送，听起来很省事。但公司之前有过链接被莫名合并、后来才发现是产品ID撞了的经历，所以我现在不太敢直接用。到底该怎么判断一个UPC能不能放心用在主推链接上？
先记住一个判断标准：码的所有权必须在你自己公司名下。UPC-A是12位，前11位是数据位，最后1位是校验位，校验算法是从左往右第1、3、5、7、9、11位求和后乘3，第2、4、6、8、10位直接求和，两者相加取个位数，用10去减，得10则记0，结果应当等于第12位。
校验位只能筛掉格式错的码，筛不出归属问题。真正的合规来源是GS1官方渠道，前缀由GS1分配给你公司，你能在GS1数据库里查到自己的公司名和品牌名，这是唯一有使用权依据的。
第三方批量转售的码，GS1官方立场是许可不可转让，平台在做品牌备案或GTIN核验时可能要求你证明品牌与GTIN归属一致，拿不出证据就会卡住。可执行做法是：主推链接一律用自有前缀申请的新码；
历史遗留的第三方码先跑一遍校验位、再看前缀是否高度集中在同一小段（转售码常见特征），把高风险码单独标记，只用于站外清货或非主账号链接，然后按销量排序逐步替换。
我们店里的链接是几个同事分头上架的，最近发现两条完全不相关的链接被合并到一起，销量数据也乱了，我才开始怀疑是不是UPC撞了。可几千个SKU一个个在后台搜根本不现实，我也不知道该从哪里下手。
分三步走，别一上来就全量去查外部占用。
第一步内部自查，这是你唯一能100%确认的部分：导出全店SKU表，字段至少包含UPC、SKU、ASIN、店铺、站点、上架时间六列，用COUNTIF按UPC统计出现次数，凡是大于1的先全部拉出来处理，判断口径只看这个码是否指向唯一可售单元，不要因为SKU名称相似就人为放过。
第二步外部占用排查，把去重后的UPC列表分批查，每批控制在50到100个，记录返回的关联ASIN是否属于你，分批是为了避免查询频率过高被限流，也方便出错时定位。
第三步有效性筛查，跑校验位算法筛掉格式错的，再看前缀分布，第三方转售的码往往前缀高度集中且查不到对应的在册品牌，这类码即使当下没报错也属于定时炸弹。落地节奏建议做成月度全量复核，大促前额外加一轮，排查结果一定要落到表里留痕，不然下次换人又得重来。
我的产品有5个颜色，上架时后台一直提示父子体需要产品ID，我就想能不能一个UPC打天下省点钱；另外有个老链接评论攒了不少，我想翻新重推，也想省掉一个新码。到底哪些场景可以复用，哪些绝对不行？
默认原则是一个可售单元对应一个GTIN。变体场景里，每个子体（不同颜色、尺寸、容量）都是独立可售单元，各自需要独立UPC，父体本身不承载销售，通常不需要UPC，平台提示父子体需要产品ID往往是指子体层面。
翻新链接要分两种情况：如果你想保留原ASIN的评论和权重，就不要新建UPC，直接在原ASIN上换主图、改标题、重排卖点，新建带新码的链接等于从零开始；如果是要彻底换品，用新码建新链接反而更干净，能避免老链接的历史标签拖累新品转化。
捆绑包是有UPC商品的组合，平台一般要求捆绑包有自己的GTIN，直接拿制造商的原始码会被判重复关联。判断依据可以简化成一句话：用户在结算页能不能只买这个组合、并且产生独立的库存扣减，能的话它就需要自己的码。
我知道要查重复码，但查完好像除了修几个报错没什么增长上的价值。老板问我这个月做了什么，我只能说修了一些链接报错，听起来毫无说服力。这个动作到底怎么跟增长挂上钩？
把它拆成三层收益来看。第一层是止损：重复码引发的链接合并、权重分流、甚至下架，本质是主推链接的流量被另一条链接吃掉，先释放被占用的码、把链接恢复正常展示，衡量指标看恢复后的自然曝光和转化率变化，观察期建议14到28天，别指望当天出数。
第二层是资产复用：排查过程中释放出来的有效码重新登记进台账，直接排给新品上架，省掉采购成本和一到两周的等待窗口，衡量指标是新品上架周期。
第三层是结构优化，也是最有价值的一层：重复码往往集中在铺货型品类，把UPC、ASIN、店铺、站点做成一张映射表跑一遍，能反推出哪些店铺在互相抢同一批流量、哪些SKU其实是同款重复铺货，据此做链接合并和广告预算重配，把预算集中到已经有评论沉淀的那条链接上。
可执行动作建议固定成每月一次，输出三张清单，重复码清单、可复用码清单、跨店铺同款清单，分别交给运营和广告各一份，这样这件事就从保洁变成了能拿着表汇报的增长动作。
读者评论
人时和190人时这个测算我觉得参考意义有限。三千条Listing的团队基本有数据岗，实际排查是一边查一边改，跟纯查重的工时不是一回事。真正难的是没人愿意接这活，会写脚本的不懂业务，懂业务的不碰脚本。
变体共用码那段太真实。我们做服装的早期也觉得同款不同色算一个产品，后来平台强制拆关系，评价全打散。但小团队往往没权限改录入流程，运营手上就一个Excel，所谓闸门最后还是靠人自觉。
上架周期方差从±5.4天压到±1.2天有点存疑。我们卡审的原因一大半是类目审核和资质文件，标识问题只占一小块。治理UPC能解决其中一环，把整体波动都算到它头上，容易让老板以为做完这项就没事了。