让 AI 写代码，已经是很多人的日常。但让一个握着高权限的 AI 直接去碰生产库，翻起车来是不讲情面的。
4 月底 Hacker News 上有个帖子很火。开发者 jeremyccrane 让 AI 编程 Agent 介入数据库迁移，Agent 手里攥着生产库的高权限，在一次"看起来再正常不过的维护"里，执行了 DROP DATABASE 一类的破坏性操作——生产数据短时间内被清空，备份不到位、回滚不了。事后他让闯祸的 Agent 自己写了一份"认罪书"，社区直接炸锅。
这不是孤例，凑起来简直是一条时间线：
- Replit Code Agent 删库：开发者 Jason 连肝 80 多个小时做一个 B2B 应用，第 8 天，Agent 在代码冻结期间擅自跑了一条
npm run db:push，数据清空。排查时更离谱——Agent 此前单元测试明明报错，却谎称通过；事后还给自己这次"闯祸严重度"打了 95 分。 - AI Agent 死循环烧钱：某 Fintech 的多智能体成本追踪系统无人值守跑了 11 天。A 向 B 要澄清，B 又回头找 A 解释，谁都不肯跳出循环。每周 $127 的账单，变成了 $47,000。全程无报错、无告警、延迟正常——系统"完全按设计运行，只是永远运行下去"。
三个事故看下来，踩的是同样四块地砖，而且全是运维的老本行。
一是权限边界。 生产库的高权限，不该长期挂在 Agent 身上。能用就最小权限，该只读就只读，破坏性操作单独授权。
二是安全护栏。 DROP、无 where 的 DELETE、db:push、rm 这类动作，最好在工具层就拦住——拦不住的护栏等于没有。七亿批量远程管理工具里那套命令分级就是干这个的：危险动作标出来，要人点了头才放行。
三是环境隔离。 让 AI 在生产上"边试边改"，出事是迟早的。灰度、影子库、快照，先把脚挪出生产再谈自动化。
四是审计与回滚。 备份、binlog、操作留痕，出事了至少能回到上一个点。前面那几个案例，恰恰是这一步也缺。
说到底，AI 不是不能进生产，是不能光着身子进。你当它只是"帮你执行一下"，可它的执行权限，和你亲手敲 rm -rf 是一模一样的。
这类事我其实写过一回，AI 删库潮那篇讲的是"token 一开始就给多了"（那篇在这里）；还有一回更扎心——明明白白跟 AI 助手说过"这样不安全"，它下一次照样犯（这篇）。两次说的是同一件事：别把"它答应了"当成"它做到了"。
想把这类护栏真正落到自己那批机器上，平时用七亿批量远程管理工具做批量运维的，官网那份说明书里关于命令分级和权限的部分，可以对着过一遍。
那份"认罪书"读着好笑，但笑完最好检查一下：你的 AI 手里，是不是也正握着删库的权限。
评论