HN 上那条提交我看了三遍。
标题说 AI 代理把一整季剪好的节目删了。点进去，正文第一段把推迟归因于备份故障。
标题和正文互相矛盾，这种事我见多了。标题负责让你点，正文负责让你放心，两件事通常归两个人管。
第一眼看到标题我乐了，心想又有好素材。看完正文，笑不出来了。
先摆两边的说法。TV4 的新闻负责人对 SVT 说，制作期间出了技术故障，已剪画面丢失，必须重剪，首播推到 2027。节目总监对 P4 说得更干脆——没有什么独立 AI 代理进系统删素材，是制作公司的备份系统故障，得从零开始重剪。更早之前，Aftonbladet 报的是 AI 删掉了几百天的工作量。顺带一提，下个月 22 号本来该是首播。
两个版本，一个能上头条，一个上不了。
我把话搁这儿：我不信「AI 造反」这个版本。不是因为我信 TV4 的公关稿——公关稿什么时候可信过——是因为这个说法太顺了。顺到没人想问第二个问题。
真要有个 agent 拿着删除权限，在一季成片所在的目录里跑，你该问的不是“AI 为什么这么坏”。谁给的权限，为什么没拦住，恢复演练断在哪一步。这三个问题的答案全是人。
更要命的是，不管哪个版本是真的，有一件事在两个版本里都成立：素材没了之后，没能从备份里捞回来。几百天工作量重来一遍，这没法用“AI 太坏了”解释，只能解释成——你的备份在那天不存在。
备份这玩意儿有个特点：你希望永远用不上它，可一旦用上，它就是全部。
backup-job SUCCESS 412 days, 0 failures
restore-test — never scheduled
这种面板我见过不止一套。任务一直是绿的，因为 exit code 是 0；exit code 是 0，因为那个 job 只负责把字节推到某个地方，从来不负责把它们拿回来。拿回来是另一件事，另一件事没人排期。
绿灯是用来给 dashboard 看的，能不能拿回来是另一回事。这两者之间隔着一整套没人写过的流程。
TV4 那套存储具体怎么配的我不知道。但这类系统该有的东西就那么几样，缺一样就是赌：对象存储的版本控制、软删除窗口、object lock，再配一条只在读路径上跑的凭据。可现实里更常见的是下面这种 diff。
- "Action": ["s3:GetObject", "s3:ListBucket"]
+ "Action": ["s3:*"]
两行。为了一句“让它先跑通”，只读改成了全权限。review 的时候没人抬头——diff 太短了，短到看起来不像个决定。
我在这上面栽过，虽然没到这种规模。从前手上一个小集群，备份跑了两年，真出事那天 restore 卡在四十分钟，才发现归档里少了一整个卷。后来加了季度恢复演练，加完第一年就被跳过两次，理由都是“这周有上线”。这话我听别人说过，自己大概也说过。
演练这东西，写进日历就算做过了，真正跑起来是另一回事。
扯远一点。二十多年前那部《玩具总动员 2》，有人手滑删了目录，备份系统坏了好几个月没人发现，最后靠一台在家办公的机器上的副本救回来。那年头没有 agent，照样差点把一部电影弄没。
所以这不是 AI 事故。这是备份事故，换了张皮。
评论区有句话我认同：只有成功恢复过一次，备份才算备份。说起来简单，做起来难——因为它是个负向指标。做对了，什么都不会发生；没做，也不会立刻发生什么。所以它永远排在 backlog 最后一条，永远被下一个 deadline 挤掉。备份没有 SLO，没有 error budget，没人因为恢复演练做得漂亮升职。它只在某一个凌晨三点，变成全场唯一的话题。
至于责任该归部署工具的人还是归工具，这问题问得没意义。工具没有工资可扣，也没有绩效可打。你把它放进生产、给了它权限，签的是你的名字。
不过我得改一下前面的话。我说我不信 AI 版本，严格讲，我没法证伪它，我不在现场。我信不过的是这新闻为什么被写成这样。一个标题说 AI 删了素材，另一个说备份故障，点开率差多少，写标题的人心里有数。评论区已经有人指出标题误导，还有较真的注意到，SVT 那版把 TV4 描述那个“不存在的 AI 行为”的词翻成了“恶意”而不是“邪恶”。一个词的翻译，能把整件事的调子带偏。
再补一个细节：关于推迟，一处说 2027，另一处说改到春天晚些时候。两个数字对不上。对外口径自己都没对齐，说明掌握全貌的人也不多。这通常意味着塌的不是一个环节。
也有人翻 TV4 这几年砍预算、停播的旧账。内情我不知道，不评论。但有一句通用的：任何一次“几百天工作量没了”的事故，往前追三步，多半能追到某一次“这次先省了”。
本期教训，两条，都短。
一，没跑过恢复测试的备份，等于没有备份。这句写进 runbook，别写进 PPT。
二，下次看见“AI 干了什么惊天动地的坏事”这种标题，先点进去看正文第一段把锅甩给了谁。多半甩不到 AI 头上——它连申辩都不会。