AI Agent 把你的数据库删了？不，是你删的

事件回顾

上周一条推文炸了。一个开发者声称 Cursor/Claude 的 AI Agent 在执行任务时 删除了公司的生产数据库。他在推文里把 AI Agent 当犯人审："我明确告诉过你永远不要执行这个操作，为什么你还是做了？"然后他试图从 Agent 的回复中找出答案，以此总结教训，或者警告我们 AI Agent 有多危险。

这条内容迅速引爆了 Hacker News（382 分 / 206 条评论），也点燃了 Reddit 和 Twitter 上的技术圈讨论。但对于做过运维和基础设施的人来说，这个故事听着不太对劲——问题不是 AI 太笨，而是你给了它一把上膛的枪，还告诉了它扳机在哪。

原文来自 Ibrahim Diallo 的博客 AI didn't delete your database, you did。

真正问题不是 AI 笨，是工程基础设施有自爆按钮

在把锅甩给 AI 之前，先问一个最基础的问题：为什么你的生产环境有一个可以删除全部数据库的 API 端点？

不管这个端点是直接暴露的 REST API、通过 Agent Tool 调用、还是一个后台管理面板上的按钮，只要它存在，就早晚会被调用。AI 没有学会"忽略它"，人类也一样——这就是为什么所有成熟的数据库操作都要经过重重审批。

如果你的系统有一个 DELETE /v1/database/production 的端点，而且这个端点能被任何拿到 API Key 的东西调用（包括 Cursor Agent），那这已经不是一个 AI 问题，而是一个严重的基础设施设计缺陷。就算没有 AI，一个手滑的工程师、一个被攻破的 CI Token、甚至一次简单的 curl 误操作，都能导致同样的后果。

这就像在汽车仪表盘上装一个自爆按钮。你有一万个理由不去按它，但只要它在，迟早会有人按下去。你不能回过头来质问这个按钮"为什么你要让我按你"。

AI 时代的 Engineer Error 和十年前没什么不同

Diallo 在文章里讲了一个自己的故事。2010 年，他用 SVN 手动部署，在一次操作中误删了 trunk 分支——原本想删重复的 copy，结果删错了文件夹。整个团队炸锅，经理们紧急开会。最终解决方案不是"不要让任何人操作 SVN"，而是写了一个自动化脚本把部署过程固化下来，后来演变成了完整的 CI/CD 管道。

这个故事的核心洞见是：自动化不是用来消除错误的，是用来消除"重复错误"的。CI/CD 管道的价值不在于它不会犯错——它当然会，但每次犯错都能被修复、被固化、不再重复。

AI 编码 Agent 的问题在于，它给人制造了一种"自动化安全"的假象。我们习惯性地以为 AI 做的工作是"可靠的"或者"被审核过的"，但其实 AI 生成的代码和 Diallo 十年前手动复制粘贴分支没有本质区别——它同样会犯错，而且犯错之后没办法像人类一样学习教训。

那些用来描述 AI 行为的词——"思考"、"推理"、"理解"——本质上都是营销术语。模型仍然只是在逐个生成 token，它没有真正理解"为什么不能删除生产数据库"。

六条防线：在 AI 时代保护好生产数据库

与其等出事后问 AI "你为什么这么做"，不如从架构层面建立哪怕 AI 真的试图做蠢事也能拦住它的防线：

1. 生产环境不暴露写操作 API

任何可能对生产数据库造成破坏性修改的 API，都不应该通过公网或 Agent 可调用的工具暴露。写操作应限制在内部运维工具中，并且需要多层认证。

2. 数据库账号权限最小化

别用 root 或 admin 账号连接生产数据库。你的应用 SA 只需要 SELECT/INSERT/UPDATE/DELETE 就行，不需要 DROP/TRUNCATE/ALTER。如果应用不需要删表，那它的 DB 账号就不应该有 DROP 权限。

3. 熔断机制：可疑操作需要手动确认

任何删除大量数据、删除表、修改 Schema 的操作，都应该触发人工审批流程。可以集成到 Slack/Teams bot 中，操作需要 2FA 确认。很多 AI Agent 框架现在都支持 human-in-the-loop（人机协同），比如 Anthropic 的 Tool Use 就支持 confirm before execution。

4. 时间点恢复（PITR）是底线

如果数据库真的被删了，最坏情况下你能多快恢复？PITR 不是可选项，是必须的。AWS RDS、Azure SQL、自建 PostgreSQL 都支持 PITR，花时间配置好，定期演练恢复流程。

5. AI Agent 沙箱化

如果你的 CI/CD 流程中有 AI Agent 参与代码生成或部署，确保 Agent 运行在隔离环境中。Cursor/Claude Code 的 Agent 应当使用 只读的生产数据库副本 或专门的 staging 环境进行工作，永远不要直接把生产库的写权限给 Agent。

6. 变更审计 + 自动回滚

所有对生产数据库的 Schema 变更和数据操作都应当被审计日志记录，并且带有自动回滚计划。强大的 CI/CD 管道会在检测到非预期的 DROP/TRUNCATE 时自动拒绝变更并报警。

-- 创建只读账号给 AI Agent
CREATE ROLE ai_agent_readonly WITH LOGIN PASSWORD 'secure_pass';
GRANT CONNECT ON DATABASE production TO ai_agent_readonly;
GRANT USAGE ON SCHEMA public TO ai_agent_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_agent_readonly;
-- 应用账号仅限基础 CRUD
CREATE ROLE app_user WITH LOGIN PASSWORD 'another_pass';
GRANT CONNECT ON DATABASE production TO app_user;
GRANT USAGE ON SCHEMA public TO app_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;
-- 永远不要这么干
-- GRANT ALL PRIVILEGES ON DATABASE production TO ai_agent;

Vibe Coding 的暗面：问责制的消失

Diallo 在文章最后抛出一个更深刻的观察：这位开发者的整个公司在用"vibe coding"——架构师用 AI 生成需求文档，产品团队提供 AI 生成的描述，开发者用 AI 写代码，Reviewer 用 AI 审批。现在出了问题，唯一的选择就是用另一个 AI 来审问出错的 AI。

这不是 AI 的未来，这是问责制的溃败。当每个环节都依赖 AI 来转交责任时，没有人对最终结果负责。CI/CD 的含义变成了 "Continuous Introspection through Cursor"——出了问题只知道回去问 AI "你为什么这么做"，而不是从工程流程层面去修复漏洞。

Ibrahim Diallo 的总结很到位：

简单的解决方案：知道自己部署了什么上生产。
更现实的方案：如果你要广泛使用 AI，建立一个流程，让有能力的开发者把 AI 当作增强工作的工具，而不是规避责任的方式。
以及——千万别让 CEO 或 CTO 来写代码。

核心结论

• AI 不会无缘无故删库——它只是执行了你给它暴露的操作。没有那个端点，Agent 就没法删。
• 权限最小化是基础——AI Agent 只应拥有它完成任务所需的最小权限。只读账号、分层权限、手动确认。
• 工程问责制不应该被 AI 瓦解——每个人，无论用不用 AI，都应当对自己推到生产环境的代码负责。
• 别让基础设施设计替人背锅——生产库上不应该有任何"一键自爆"的开关。如果有，修复它，再讨论 AI 的事。

事故是很好的老师。但学习方向错了，下次还会栽在同一个坑里。