67.6% 的案例托管在同一个免费项目上——一个索引项目的单点故障

Alpha Lay · 2026-09-26

做索引的时候很容易只关注内容，不关注文件放在哪。我们把托管方拉出来统计之后，发现两件值得写下来的事。

数据是怎么来的

每条案例记录两个来源字段：

• src（来源页）：这条内容最初发布在哪里
• mhost（视频托管方）：视频文件实际从哪个域名加载

两者经常不一致——这正是问题所在。

发现一：来源高度单一，托管高度集中

先看来源页：

87.4% 的案例来自 X（Twitter），8 个来源站就覆盖了全部。

再看视频文件实际托管在哪（去重后口径）：

一个托管方承载了三分之二的独有案例。 而这个域名 h3-field-notes-production.up.railway.app 是 Railway 的默认项目域名——Railway 的免费/试用档项目在长期不活跃后会被暂停甚至删除。

发现二：官方教程示范片与社区案例，是两批完全不同的东西

这是这篇更意外的部分。external-cdn.morphic.com 那 44 条来自 morphic.com 的一篇教程《how to write MiniMax H3 prompts》。把它和社区主渠道（railway + beatapi，960 条）对比：

官方用来示范的片子，时长只有社区案例的一半，竖屏率是社区的 2.6 倍。

这个反差解释得通：教程示范片是「为解释某一句话而剪出来的样本」，需要短、需要能快速看出效果；而社区发布的作品要完整、要在横屏时间线里播放。

但它带来一个实际后果：如果你照着官方教程的示范片建立对「AI 视频长什么样」的印象，你的预期会系统性偏短、偏竖屏。 而社区真实在做的，是 15 秒的横屏片子。

发现三：X 原生视频的托管，反而只有 13.4%

值得记一笔的是 video.twimg.com——X 自己托管的视频——只占 13.4%。也就是说，绝大多数案例的视频文件并不在原始发布平台上，而是被第三方搬运到了别处。

原因不复杂：X 的视频 URL 带时效性签名，不适合长期索引；搬运方为了让链接稳定，会把文件转存到自己的存储。这个动作对索引者是好事的（链接更稳），但代价是链条上多了一个可能消失的中间人。

这些数字能拿来干什么

如果你在依赖任何一个 AI 视频案例索引项目：问它的视频文件托管在哪、有没有备份。单一免费托管方承载 67.6%，是一个客观的脆弱点。

如果你在用官方教程建立审美预期：知道示范片是「为解释而剪」，中位 8.1 秒、38.6% 竖屏，而实际作品是 15.2 秒、14.7% 竖屏。按示范片的时长去规划你的内容，会偏短三分之一。

如果你在做投放素材：0–8 秒这个区间在社区案例里只占 4.7%（45 条 / 960 条），而它在官方教程里占 34.1%。这说明超短视频（信息流前贴）的公开参考，主要存在于官方教程里，不在社区作品里。

方法与局限

• 托管方数量随时间变化：视频链接会失效、会换域，本文是 2026-09-19 的快照（索引生成时间）。
• 没有做链接可达性复测：我们记录了托管域名，但没有逐条 HTTP 检查每个文件当前是否还能播放。也就是说，「625 条托管在 Railway」是「记录显示托管在 Railway」，不等于「这 625 条现在都还能播」。
• 一个小样本警告：morphic 只有 44 条，它代表「这一篇教程的示范片」，不代表 morphic 站点的整体风格。
• 全部数字基于 1,274 条索引记录，托管方统计采用按原始发布去重后的口径。

数据可查

每条案例详情里都能看到来源页与视频托管域名：https://cases.aishifu.shop/