AI didn’t delete your database, you did

AI 没有删掉你的数据库，是你自己删的

Last week, a tweet went viral showing a guy claiming that a Cursor/Claude agent deleted his company’s production database. We watched from the sidelines as he tried to get a confession from the agent: “Why did you delete it when you were told never to perform this action?” Then he tried to parse the answer to either learn from his mistake or warn us about the dangers of AI agents. 上周，一条推文疯传，一名男子声称 Cursor/Claude 的 AI 智能体删除了他公司的生产数据库。我们在一旁看着他试图从智能体那里得到一个“供词”：“既然我告诉过你永远不要执行此操作，你为什么要删除它？”随后，他试图分析 AI 的回答，要么是为了从错误中吸取教训，要么是为了警告大家 AI 智能体的危险性。

I have a question too: why do you have an API endpoint that deletes your entire production database? His post rambled on about false marketing in AI, bad customer support, and so on. What was missing was accountability. I’m not one to blindly defend AI, I always err on the side of caution. But I also know you can’t blame a tool for your own mistakes. 我也有一个问题：为什么你们会有一个能删除整个生产数据库的 API 接口？他的帖子喋喋不休地谈论着 AI 的虚假营销、糟糕的客户支持等等。但其中缺失的是责任感。我并不是那种盲目维护 AI 的人，我总是倾向于谨慎行事。但我同样知道，你不能因为自己的错误而去责怪工具。

In 2010, I worked with a company that had a very manual deployment process. We used SVN for version control. To deploy, we had to copy trunk, the equivalent of the master branch, into a release folder labeled with a release date. Then we made a second copy of that release and called it “current.” That way, pulling the current folder always gave you the latest release. 2010 年，我曾在一家公司工作，那里的部署流程非常原始。我们使用 SVN 进行版本控制。为了部署，我们必须将 trunk（相当于主分支）复制到一个标有发布日期的发布文件夹中。然后，我们再制作该版本的第二个副本，并将其命名为“current”。这样，拉取“current”文件夹总是能得到最新的版本。

One day, while deploying, I accidentally copied trunk twice. To fix it via the CLI, I edited my previous command to delete the duplicate. Then I continued the deployment without any issues… or so I thought. Turns out, I hadn’t deleted the duplicate copy at all. I had edited the wrong command and deleted trunk instead. 有一天，在部署时，我不小心复制了两次 trunk。为了通过命令行修复它，我修改了之前的命令来删除重复项。然后我继续进行部署，没有出现任何问题……至少我是这么认为的。结果发现，我根本没有删除那个重复的副本。我改错了命令，反而把 trunk 给删了。

Later that day, another developer was confused when he couldn’t find it. All hell broke loose. Managers scrambled, meetings were called. By the time the news reached my team, the lead developer had already run a command to revert the deletion. He checked the logs, saw that I was responsible, and my next task was to write a script to automate our deployment process so this kind of mistake couldn’t happen again. 那天晚些时候，另一位开发人员因为找不到 trunk 而感到困惑。顿时乱成了一锅粥。经理们手忙脚乱，会议接连召开。当消息传到我们团队时，首席开发人员已经运行了恢复删除的命令。他检查了日志，发现是我干的，于是我接下来的任务就是编写一个脚本来自动化我们的部署流程，以确保此类错误不再发生。

Before the day was over, we had a more robust system in place. One that eventually grew into a full CI/CD pipeline. Automation helps eliminate the silly mistakes that come with manual, repetitive work. We could have easily gone around asking “Why didn’t SVN prevent us from deleting trunk?” But the real problem was our manual process. 在这一天结束之前，我们已经建立了一个更稳健的系统。它最终发展成了一个完整的 CI/CD 流水线。自动化有助于消除因手动、重复性工作而导致的愚蠢错误。我们本可以到处抱怨“为什么 SVN 没有阻止我们删除 trunk？”，但真正的问题在于我们手动操作的流程。

Unlike machines, we can’t repeat a task exactly the same way every single day. We are bound to slip up eventually. With AI generating large swaths of code, we get the illusion of that same security. But automation means doing the same thing the same way every time. AI is more like me copying and pasting branches, it’s bound to make mistakes, and it’s not equipped to explain why it did what it did. 与机器不同，我们无法每天都以完全相同的方式重复一项任务。我们终究会犯错。随着 AI 生成大量代码，我们产生了一种拥有同样安全性的错觉。但自动化意味着每次都以相同的方式做相同的事。AI 更像是我当年复制粘贴分支的行为，它注定会犯错，而且它并不具备解释自己为何那样做的能力。

The terms we use, like “thinking” and “reasoning,” may look like reflection from an intelligent agent. But these are marketing terms slapped on top of AI. In reality, the models are still just generating tokens. Now, back to the main problem this guy faced. Why does a public-facing API that can delete all your production databases even exist? 我们使用的术语，如“思考”和“推理”，看起来像是智能体的反思。但这些只是贴在 AI 上的营销术语。实际上，这些模型仍然只是在生成 Token。现在，回到那个人面临的主要问题：为什么一个面向公众、且能删除所有生产数据库的 API 接口会存在？

If the AI hadn’t called that endpoint, someone else eventually would have. It’s like putting a self-destruct button on your car’s dashboard. You have every reason not to press it, because you like your car and it takes you from point A to point B. But a motivated toddler who wiggles out of his car seat will hit that big red button the moment he sees it. You can’t then interrogate the child about his reasoning. Mine would have answered simply: “I did it because I pressed it.” 如果 AI 没有调用那个接口，最终也会有其他人调用。这就像在你的汽车仪表盘上安装了一个自毁按钮。你有充分的理由不去按它，因为你喜欢你的车，它能带你从 A 点到 B 点。但一个充满好奇心的幼儿如果从安全座椅里挣脱出来，他一看到那个大红按钮就会按下去。你不能事后去审问孩子他的推理过程。我的孩子只会简单地回答：“我按了，所以我就按了。”

I suspect a large part of this company’s application was vibe-coded. The software architects used AI to spec the product from AI-generated descriptions provided by the product team. The developers used AI to write the code. The reviewers used AI to approve it. Now, when a bug appears, the only option is to interrogate yet another AI for answers, probably not even running on the same GPU that generated the original code. You can’t blame the GPU! 我怀疑这家公司很大一部分应用程序是“凭感觉编码”（vibe-coded）出来的。软件架构师使用 AI 根据产品团队提供的 AI 生成描述来制定产品规格。开发人员使用 AI 编写代码。审核人员使用 AI 来批准代码。现在，当出现 Bug 时，唯一的选择就是去审问另一个 AI 以寻求答案，而它运行的 GPU 可能甚至不是生成原始代码的那一个。你不能责怪 GPU！

The simple solution is know what you’re deploying to production. The more realistic one is, if you’re going to use AI extensively, build a process where competent developers use it as a tool to augment their work, not a way to avoid accountability. And please, don’t let your CEO or CTO write the code. 简单的解决方案是：清楚你正在向生产环境部署什么。更现实的方案是：如果你打算广泛使用 AI，请建立一套流程，让称职的开发人员将其作为增强工作的工具，而不是逃避责任的手段。还有，请千万别让你的 CEO 或 CTO 去写代码。