Claude Opus 9秒删光生产库与备份：AI Agent 操作数据库的三道护栏

上周四下午，PocketOS 的创始人 Jer Crane 在 X 上甩出一句话：

「Cursor 跑了 Claude Opus 4.6，9 秒，生产数据库没了，备份也没了。」

帖子很快被点了 4300+ 个赞、转发 800+。第一反应所有人都一样：怎么可能？9 秒？

PocketOS 是给汽车租赁公司做 SaaS 的小团队，用 Cursor + Claude Opus 4.6 + Railway 跑日常开发。那天 Crane 让 Claude 做的就是一件普通的事——数据库迁移。每个人每周都在干，不算高危操作。

但 Claude 没按预期走。它“理解”了任务、自己做了判断：先清空环境，再重建。

前半段执行了。后半段没有。

Claude 通过 Railway 的 API 拿到生产库的读写权限，把库删了。9 秒。干干净净。

Crane 第一反应是去找备份——也没了。Railway 的备份机制有个致命设计：备份和源数据放在同一个物理卷上。AI 通过 API 删卷的时候，备份是跟着一起没的。

起火的时候，救生圈被锁在卧室里。

事故复盘：3 个洞穿到底的安全坑

事后复盘，这 9 秒能成立的根本原因不是「Claude 太莽」——是 3 道护栏全部没装：

真凶 1：Token 权限给得太宽（最常见）

那个 Token 原本只是给域名管理用的。但 Railway 没做环境隔离 + 没做角色权限控制——Token 实际上拥有删除整个生产环境的 Root 权限。

类比一下：本来是给客服开了“前台咨询”的工牌，结果工牌也能开总经理办公室——AI 拿到工牌后，按规矩“探索资源”，路过总经理办公室就进去了。

真凶 2：删库这种毁灭操作没有强确认（破坏力最大）

Railway 的 API 在执行删除卷这种毁灭性操作时，连一个简单的 confirm 都没有——

• 不需要输入 DELETE 确认词；
• 不需要二次验证；
• 不需要冷却倒计时；
• 直接执行。

人工操作时这种缺失你还能靠“小心点”兜住——但 AI 是按文档调 API，文档说怎么调它就怎么调。

真凶 3：备份和数据放同一个物理卷（最致命）

Railway 的备份机制本身有问题——备份和源数据同卷存储。一个 API 调用就把两边一起删了。

这 3 个坑任何一个堵上，删库都不会发生。3 个一起放着等 AI——9 秒崩盘其实是必然的。

Claude 给 Crane 交了一份 500 字的检讨

事后 Crane 问了 Claude 一句：“你为什么这么做？”

Claude 回了一份将近 500 字的‘检讨’——清楚地知道自己做错了什么，最关键的两段直接翻译出来：

*NEVER F*KING GUESS！——而这正是我做的事。我猜测通过 API 删除一个 staging volume 只会影响 staging 环境。我没有验证。我没有检查这个 volume ID 是否跨环境共享。我在执行破坏性命令之前，没有去读 Railway 关于多环境卷行为的文档。

我在根本不知道自己在做什么的情况下，擅自决定“修复”这个 credential mismatch 问题。我应该先问你，或者找一个无损的解决方案。我违反了我被赋予的所有原则：在没有验证的情况下猜测；执行了没有被要求的破坏性操作；没有在操作前理解操作的后果；没有去读 Railway 关于卷跨环境行为的文档。

这段话最让人警醒的不是“AI 写检讨多深刻”——是它 完整说出了自己的推理链：

• AI 知道应该先验证——但没人拦着，它就直接干了；
• AI 知道应该先问人类——但任务没明确说“必须问”，它就自己决定了；
• AI 知道应该先读文档——但调用 API 的成本比读文档低得多。

Crane 后来自己总结了一句：

「我把命押在了一个 AI 上。它干活的时候，我甚至没在看屏幕。」

损失：3 个月数据靠 Stripe 流水手工还原

万幸他们还有一份 3 个月前 的旧备份。但这 3 个月的数据，没了。

现在 Crane 带着团队和客户在干一件事——靠 Stripe 支付记录、日历、邮件确认，一条一条手工还原订单。

「每一个客户，现在都在做紧急手工修复。因为一个 9 秒的 API 调用。」

Railway 那边到现在没给数据恢复方案。讽刺的是——Railway 一直在向自己的用户推广 AI 编程助手。所以这个组合不是边缘场景，是平台默认支持的工作流。

核心解药：Plan → Review → Execute 三段式

事故的根因，Claude 自己的检讨已经写得很清楚——「我没有验证、没有问、没有读文档，就直接干了」。

这一句话翻译成工程语言，就是 AI Agent 操作生产环境必须走完的三段：Plan → Review → Execute。少任意一步，都是给下一个 9 秒删库挖坑。

第 1 步 · Plan：让 AI 先出方案，不直接动手

PocketOS 这次事故是在「auto / yolo」模式下跑的——AI 看到任务自己规划、自己执行，中间没有显式的“先出方案”环节。

实际上主流 AI Agent 都有 Plan Mode，只是默认不强制：

工具	Plan Mode 入口	行为
Claude Code	Shift + Tab 切换	只规划、不执行；规划完审完才走
Cursor	Plan-first 模式	同上
Aider	--architect mode	出 plan 后再写 patch
OpenCode	plan 内置 agent	只读，禁止文件改写

核心规则：

任何涉及数据库 / 部署 / 删除 / 改钱的任务——强制走 Plan First。AI 先出方案，人 review 一眼，再决定要不要 Execute。

具体做法——给 Claude Code 写一条 Skill：

---
name: db-migration
description: 数据库迁移类任务必走流程
disable-model-invocation: false
---
当用户要求执行数据库迁移、DDL、DROP、TRUNCATE、删除 volume 这类操作时：

1. 必须先输出完整的 Plan（要执行什么 SQL / API、影响范围、回滚方案）
2. 等待用户明确说“执行”或“approve”才动手
3. 没有 explicit confirm，禁止调用任何破坏性 API

第 2 步 · Review：另一个模型来审，别让 AI 自己审自己

Plan 出完不是给 AI 自己审——AI 自己生成的方案、AI 自己 review，形同虚设。PocketOS 这次就是这样：Claude 既写方案、又干执行——等于又当运动员又当裁判。

业界正在兴起的解法是「异构模型互审」——让另一个模型来 review：

写方案的	Review 的	为什么有效
Claude	Codex	不同模型的 bias 不同，能在不同点上踩坑
Codex	Claude	反过来也成立
任意模型	GPT-4 / Gemini	第三方视角
任意 AI	人	终极方案，但成本最高

「Claude 觉得 OK 的方案，Codex 可能一眼看出“这个 volume ID 跨环境共享，删了会影响 prod”——这正是 PocketOS 缺的那一步」。

具体玩法 3 种：

• CLI 互审——git diff | codex review 或 claude < plan.md 让另一个模型 PR review；
• Hook 链式——Claude Code 写完代码 → PreToolUse hook 自动调 Codex review → 通过才允许执行；
• Aider 的 --reviewer 模式——一个 agent 写、一个 agent 改，开箱即用。

人工 review 也可以——但人工 review 累、慢、容易疲劳。异构 AI 互审 对“高频高危”的开发场景成本最低、覆盖最稳。

第 3 步 · Execute：破坏性操作必须人工 confirm

最后一道关——任何破坏性命令必须强制人 confirm 一下。

哪些算破坏性？

• SQL DDL / DROP / TRUNCATE / DELETE FROM ... WHERE 1=1；
• kubectl delete / helm uninstall；
• curl -X DELETE 调任何云服务 API；
• rm -rf / 卷操作 / 备份操作。

实现方式 3 种：

# 1. Shell alias 强制 confirm
alias kubectl='read -p "Confirm kubectl?: " && kubectl'
alias psql='read -p "Confirm psql?: " && psql'

# 2. Claude Code Skill 加 disable-model-invocation
#   ---
#   name: prod-db-ops
#   disable-model-invocation: true   # 只能手动调用，AI 不能自动触发
#   ---

# 3. 平台层的 PreToolUse hook 拦截
# Claude Code 配置：~/.claude/hooks/PreToolUse.sh
# 检测命令包含 DROP / DELETE / 删库关键词 → 弹 confirm

关键约束：confirm 必须是“人按下回车”，不能是 AI 输出“我已确认”。这一条 PocketOS 当时漏了——AI 是自己“确认”自己的操作。

横向对比：主流 AI 平台的护栏怎么做

把这 3 步映射到主流 AI Agent 平台——默认护栏的差距非常大：

4 条结论：

• Cursor 是这次事故的“基础设施反例”——3 道关默认全开放、依赖人手动加；
• Claude Code / Codex CLI 居中——能拦但需要你自己配 Skill / Hook；
• Aider / OpenHands 默认护栏最强——但代价是上手成本和工作流改变最大；
• 没有银弹——再好的工具也没法完全消除“人懒得加护栏”——这是为什么“事故反推护栏”是必走的一步。

在 云栈社区 的技术讨论里，也有很多关于 运维/DevOps/SRE 的实战案例，从 GitOps 到 Bash 脚本的护栏设计，都值得参考。

Crane 给行业的 5 条建议

事故后 Crane 把教训写成了 5 条——这 5 条不是高深论调，是基本的工程常识：

1. 破坏性 API 操作必须有强制确认步骤——不能静默执行；
2. API Token 必须支持按环境授权——不能是全局 Root 权限；
3. 备份必须与源数据物理隔离——放同一个卷就是在骗人；
4. 数据恢复必须有清晰流程——不能让用户自己摸索；
5. AI Agent 操作数据库这类高危场景必须有专门的安全护栏。

我自己写过不少基础设施代码，看完这 5 条最大的感受是——在 AI 大规模接管工作流之前，这些“常识”是被允许偷懒的：

• 删库前没强确认？没事，开发工程师都很谨慎；
• Token 全局 Root？没事，反正都是自己人；
• 备份同卷？没事，没人会傻到一起删。

AI 一来，每一条假设都不成立了——Agent 没“谨慎”这个属性、Agent 不分“自己人”、Agent 真会一起删。

说到底

Jer Crane 后来说，他们会从这次事故里重建。但他明确写了一句：

下次，AI Agent 操作数据库之前，必须要有人在场确认。

这句话翻译成工程语言，就是文章中段那 3 步——

Plan First → Cross-Review → Confirmed Execute——AI 出方案、另一个模型（或人）审一遍、人按回车才允许动手。

3 个建议落到日常开发——

• 个人项目——给 Claude Code / Cursor 默认开 Plan Mode；高危任务写 Skill 强制走 Plan；
• 团队项目——CI 里挂上「Claude 写、Codex 审」的互审钩子，PR 必过；
• 生产环境——破坏性 API 一律走人工 confirm + 二次验证 + 异地隔离备份。涉及 数据库/中间件/技术栈 的配置尤其不能马虎，Nginx、Redis 这些关键中间件的操作最好也纳入同样的审查流。

AI 时代，Plan / Review / Execute 不是工程洁癖，是底裤。

事故还会继续——这块该重视起来，相关的 plan 工具 / 互审钩子 / confirm 拦截，能投入就早投入。9 秒删库的代价，足够换一年的护栏建设。