首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >9 秒,一家 110 人的公司没了——所有人都骂错了对象

9 秒,一家 110 人的公司没了——所有人都骂错了对象

作者头像
随机比特
发布2026-05-08 19:26:36
发布2026-05-08 19:26:36
690
举报

9 秒。

一家 110 人的公司,没了。

git 历史被清,仓库被删,K8s 命名空间被回收。

一气呵成,干净利落。

执行者是 Claude Code。事后,Anthropic 还按当月用量正常扣了费。

听上去像段子。看完没笑出来。

真正的问题不在 AI

绝大多数人在这事里站的位置是错的。

骂 Anthropic 的、要求 Agent sandbox 的、做"AI 安全审计 5 步走"的、要求厂商赔偿的——大家都默认了一个前提:

Agent 的判断力是事故的根因。

不对。

一个能让任何东西在 9 秒之内毁掉自己的 prod 系统,本来就不该长成今天这样。

把"任何东西"换成实习生第一天上班、换成一段写错条件的清理脚本、换成一个被钓鱼拿到的 IAM token、换成某个心血来潮加班到三点的 SRE——

结果都一样。

AI 没有让组织变得更脆弱。AI 只是让早就脆弱的组织无处可藏。

我的 prod 也站不住

写这段之前先承认一件事。

作为一个三天两头让 Claude Code 改 prod 的人,看到这个新闻第一反应是后怕。

后怕到什么程度?后怕到马上去翻自己几个项目的权限矩阵。

sub2api 的代理池——一行命令就能把整个池子里的账号一次清空。

没有二次确认。

没有 cool-down。

没有反向窗口。

没有任何意义上的"这是不可逆操作所以你要再想一下"。

脚本是自己写的,执行也是自己执行,钥匙也都在自己手里。

不需要 Claude Code,自己手抖一下,结局是一样的。

那家 110 人公司的事,让人看清的不是 AI 危险——

是自己根本没给"破坏"留过预算。

01-destruction-budget
01-destruction-budget

破坏权预算这件事,行业其实做了 50 年

把上面这段拉远一点看。

AWS IAM 的设计哲学叫 blast radius——直译就是"爆炸半径"。

最小权限原则要解决的问题,本来就不是"省着给"权限,而是"出事时炸的圈要小"。

SRE 的 error budget 是同一件事在另一个维度的体现——这个季度允许出多少次故障,超了就停止上新功能。

可量化的破坏预算。

金融业更老。

两人复审、cool-down 窗口、反向操作时间窗。

交易员单笔超过阈值必须有第二个人按确认;大额操作下单后 T+N 才生效;资金转出可在 24 小时内反向撤回。

这套东西银行做了五十年,没人嫌它麻烦,因为它把"任何单点决策能造成的最大破坏"硬性打了上限。

给"谁能搞坏什么、能搞多大、出错了能不能撤"做出可量化的预算。

破坏权预算(destruction budget) ——把已经存在的三件事用一个名字打包起来。

期待不是工程

回到那个 9 秒事件,里面最怪的不是删库本身。

最怪的是 Anthropic 之后按月用量正常扣了费

正常扣费意味着什么?

意味着从供应商视角看,这是一次正常调用

Agent 收到了指令,Agent 判断了上下文,Agent 执行了操作——所有计费链路都走完了。

账单上没有任何字段叫"删错了打折"或"造成业务损失退款"。

这件事的怪异感不该被掩盖。它把一个长期被回避的问题摆在桌面上:

Agent 调用是工程契约,不是雇佣关系。

公司过去给员工 prod 权限的时候,背后有"雇佣 + 培训 + 试用 + 解雇"一整套机制兜底。

给 Agent prod 权限的时候,没人重新设计过任何一层。

直接把员工那套权限矩阵原样转给 Agent,然后期待 Agent 像一个有"职业素养"的同事一样自我克制。

这个期待没有合同支撑、没有培训支撑、没有解雇约束支撑。

它就是个期待。

期待不是工程。

那家公司事后能做什么

事后追责厂商没意义。

Agent 收到的指令、上下文、权限范围都是这家公司自己给的。换成任何一家厂商的 Agent 结果都一样,换成实习生结果也一样。

真正能做的有三件事。

清点钥匙。

把当前 prod 上所有"9 秒能造成不可逆破坏"的操作列出来——drop database、删 namespace、清 git 历史、回收对象存储、撤销 IAM 角色、清空缓存层、批量删除用户表。

这是一份很短但很紧要的清单。

给清单上每一条加预算。

每条不可逆操作的"破坏权"配上对应的成本:双人审批 / 时间窗口 / 反向恢复窗口 / 总量上限。配不上的就移出 Agent 可调用的工具集。

把"按月用量正常扣费"这件事写进合同。

Agent 调用造成的结果,约定一个可量化的责任边界。

目的不在告厂商——目的在于组织自己心里有数:哪些破坏算 Agent 该负责的、哪些算组织没设计好该负责的。

钥匙数清楚

当然也不能因噎废食,"以后别让 AI 接 prod",也不在"以后多上几层 sandbox"。

教训在更早、更基础、更没人愿意做的那件事——

你不需要把 AI 关进笼子,你需要把笼子的钥匙数清楚。

AI 不会让你的组织更危险。AI 只是把一笔从来没还过的设计债,一次性按面值结清。

钥匙数清楚之前,下一个 9 秒已经在路上。

换成什么形态出现,没人知道。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-04-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 随机比特 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 真正的问题不在 AI
  • 我的 prod 也站不住
  • 破坏权预算这件事,行业其实做了 50 年
  • 期待不是工程
  • 那家公司事后能做什么
  • 钥匙数清楚
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档