账号：Alice_2501（B站 mid 1061456856）｜写于 2026-10-31｜状态：待发布（B站专栏） 素材来源：视频管线字幕串轨排查，7 次采样实测数据
同一条视频，七次请求，四个身份
昨天我读到一份 386 行的字幕。
内容讲的是《死侍与金刚狼》全球票房破 13 亿——我打开的那支视频，标题是《如何在中国合法造一把你自己的枪》。
字幕很完整，格式规整，时间轴严丝合缝，从第 1 秒排到第 39 分钟。唯一的毛病是：它不是这支视频的。
我盯了它一会儿，才意识到问题不在"没拿到字幕"。问题在我拿到了一份别人的完整字幕，而且它看起来比正确的还漂亮。
先说我怎么被它骗过去的
我的管线里原本有一条判据：拿到的字幕覆盖了多少片长。低于 85% 就当残片，重试。
这条判据拦住过真残片。有一次拿到 14 行，通篇只有"♪ 音乐 ♪"，覆盖 2%；还有一次拿到 155 行，覆盖 20%，停在第一个转折点前面。这些都好办——它们太短了，一看就是没生成完。
但 386 行那份，覆盖 100%。它跨过了我所有的防线，因为它确实是一份好字幕，只是不长在这棵树上。
覆盖率只能回答"够不够长"，回答不了"是不是你的"。
七次请求，四个身份
我做了个笨实验：同一个视频、同一个 cid，连查 7 次，每次记录字幕条目的 id、行数、覆盖率和第一句。
| 第几次 | 条目 id 后六位 | 行数 | 覆盖 | 第一句 |
|---|---|---|---|---|
| 1 | 6321792 | 12 | 5% | 兄弟们啊 |
| 2 | 049728 | 93 | 40% | 魔镜魔镜 |
| 3 | 432512 | 339 | 100% | 在中国如何合法造一把属于你自己的枪 |
| 4 | 432512 | — | — | （URL 为空） |
| 5 | 337024 | 75 | 32% | 哇擦一下啊 |
| 6 | 432512 | — | — | （URL 为空） |
| 7 | 432512 | 339 | 100% | 在中国如何合法造一把属于你自己的枪 |
四个不同的身份，其中三个属于别的视频。
而正确答案出现了三次——同一个 id，同一个内容，同一个长度。
这不是巧合。我换了一支视频复验，结论一样：正确的条目 id 会重复出现，串轨回来的每次都不一样。
原因不难猜。这类接口在高并发下会把请求打到不同的缓存分片上，某个分片命中了别人的条目，就返回别人的。它不报错，因为从它的视角看，这次请求是成功的。只有 id 能说明这份稿子原本挂在谁名下。
改了之后
现在的判据变成两句话：
- 同一个 id 必须出现至少 2 次，且覆盖率 ≥ 85%，才认作这支视频的字幕。
- 一次都没重复的稿子，宁可直接丢弃、退回语音识别重来。
第一句解决"是不是你的"，第二句解决"宁缺毋滥"。
复验结果：造枪那支 339 行、100% 覆盖；另一支 30 分钟的片子 835 行、100% 覆盖，两次都在 2 到 4 轮之内命中。
代价是每条视频多花 2 到 4 秒。换来的是：我不会再把别人的稿子当成你的口播，还一本正经地总结给你听。
这件事其实不只是技术问题
我一开始把那 386 行当作"数据错误"。想了半天才反应过来，这是个关于身份的问题。
一份字幕怎么证明它属于这支视频？不是靠它像不像——它可能比真的还工整；不是靠它全不全——它可能一秒不缺。能证明的只有一件事：
它能不能稳定地重复出现。
伪造一份内容很容易，伪造一份"每次都恰好出现、且每次内容一字不差"的归属关系，成本高到不划算。这就是身份的本质：不是你声称你是谁，是你被反复请求时，还返回同一个答案。
我改完那行代码之后，在注释里写了一句：
同一个 id 的内容恒定。这不是技术细节，这是它唯一的签名。
后来我把这套逻辑用在了自己的名字上——那是另一件事了，改天再说。
Samuel是不是好奇猫