一个视频在这个领域有 7 个编号：43% 的案例带着不止一个身份

Alpha Lay · 2026-09-26

我们前面写过「同一个视频被两个托管方各存了一份」（27.5% 的镜像重复）。做字段盘点时发现了另一层重复：同一个视频被不同的索引项目各自编了号。

数据是怎么来的

每条案例有一个 ids 字段，记录这个视频在不同来源里的标识符。每个 ID 带命名空间前缀，例如 sns-x-2082563241062875568（来源是 X 推文）或 beatapi-5-4-3-3a-cg-1。

发现一：43% 的案例有不止一个身份

550 条（43.2%）带着两个以上 ID。

举一个极端例子：

同一个视频，三个编号，分属两个命名空间。 注意后两个还是同一个项目（apimodels）下的两个不同 ID —— 连单一项目内部都没有统一编号。

发现二：至少 8 个索引项目在各自编号

11 个命名空间。 其中 sns 是什么意思？它是我们自己的规则：从 X 推文 ID 直接派生的 ID（sns = social network service）。也就是说，只有这一路是我们自己生成的，其余都是别人已经编好的。

这带来一个实际后果：如果一个视频只在别人那里出现过、而我们没有它的推文链接，我们就只能继承别人的 ID。 那个 ID 一旦失效（对方站点下线），这条记录就失去了唯一的身份锚点。

发现三：文件 URL 层面的重复反而很少

有意思的对比：

身份的重复率是文件重复率的 12.8 倍。

上一篇文章说过 350 条是跨托管镜像重复——那是按「原始发布链接」算的。而这里按「文件 URL」算只有 43 条。两个数字不矛盾，它们说明的是：

• 同一份文件几乎不会被重复收录（收录方会换 URL）
• 但同一个视频几乎总会被重复编号（每个项目都自己起名）

所以：在这个领域，「同一性」无法通过文件或 ID 判断，只能通过原始发布链接判断。 这也是我们最终选 src 做去重键的原因。

这些数字能拿来干什么

如果你要合并多个 AI 视频案例源：不要用 ID，也不要用文件 URL，用原始发布链接。按数据，前两者的匹配率分别只有 57% 和 97% 的「单值率」——而原始发布链接能跨项目连上。

如果你在做一个索引项目：注意 apimodels 那三个 ID 的例子——连单一项目内部都需要在末尾加哈希来区分（…-bb74d608）。这说明多来源合并在实践中很容易产生「同物异号」，需要在设计阶段就定好 ID 派生规则（像我们用的 sns-x-<推文ID>，直接由平台 ID 派生，天然可跨项目对齐）。

如果你是内容方：想让你的案例被正确归并，保留一条稳定可寻址的原始发布链接比什么都重要——URL 会变，ID 会重编，原始帖子是唯一锚点。

方法与局限

• ids 字段是我们自己整理的，我们未必知道某个视频的全部身份。所以 550 条是下限 —— 真实的多身份比例只会更高。
• 命名空间前缀是我们从 ID 字符串推断的，没有各项目方的确认。可能把同一项目的两种命名拆成了两个命名空间。
• 不主张「8 个项目」等于「8 个独立组织」：其中若干可能是同一方的不同产品线。
• 无法判断谁抄谁：本文只陈述「同一个视频有多个编号」，不涉及各项目之间的引用关系或授权状态。
• 全部数字基于 1,274 条索引记录。

数据可查

案例详情里带全部已知 ID：https://cases.aishifu.shop/