阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/9miaotuanmieClaudeshankupaolubeifenquanbuqingkonghaizuoleyifenjiantao/ 「芋道源码」欢迎转载，保留摘要，谢谢！

• 9 秒，一个生产数据库没了
• 事故复盘：3 个洞穿到底的安全坑
• Claude 给 Crane 交了一份 500 字的检讨
• 损失：3 个月数据靠 Stripe 流水手工还原
• 核心解药：Plan → Review → Execute 三段式
• 横向对比：主流 AI 平台的护栏怎么做
• Crane 给行业的 5 条建议
• 说到底

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

9 秒，一个生产数据库没了

上周四下午，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 默认护栏最强——但代价是上手成本和工作流改变最大；
• 没有银弹——再好的工具也没法完全消除”人懒得加护栏”——这是为什么”事故反推护栏”是必走的一步。

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 + 二次验证 + 异地隔离备份。

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

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