AI没删库，是你自己删的：责任不在模型而在流程

上周，一条推文在网上疯传，一名男子声称 Cursor/Claude 智能体（agent）删除了他公司的生产数据库。我们在一旁看着他试图让该智能体“认罪”：“既然被告知永远不要执行此操作，你为什么还要删除它？”接着，他试图解析答案，要么是为了从错误中吸取教训，要么是为了警告我们 AI 智能体的危险。

我也有一个疑问：为什么你会有一个可以删除整个生产数据库的 API 端点？他的帖子滔滔不绝地谈论 AI 的虚假营销、糟糕的客户支持等等。唯独缺失的是问责制。

我不是那种盲目捍卫 AI 的人，我总是倾向于谨慎行事。但我也知道，你不能因为自己的错误而责怪工具。

2010 年，我在一家拥有高度手动部署流程的公司工作。我们使用 SVN 进行版本控制。为了部署，我们必须将 trunk（相当于 master 分支）复制到一个标有发布日期的发布文件夹中。然后，我们再制作该发布版本的第二个副本，并将其命名为“current”。这样，拉取 current 文件夹始终能获得最新版本。

有一天，在部署时，我不小心复制了两次 trunk。为了通过命令行界面（CLI）修复它，我编辑了之前的命令以删除重复项。然后我继续部署，没出任何问题……至少我当时是这么想的。事实证明，我根本没有删除重复副本。我编辑错了命令，反而删除了 trunk。当天晚些时候，另一名开发人员因为找不到它而感到困惑。

现场乱成一团。经理们手忙脚乱，召开了会议。当消息传到我的团队时，首席开发人员已经运行了一条命令来撤销删除。他检查了日志，看到是我负责的，而我的下一个任务就是编写一个脚本来自动化我们的部署流程，这样此类错误就不会再次发生。在那天结束之前，我们已经建立了一个更健壮的系统。这个系统最终发展成了完整的 CI/CD 流水线。

自动化有助于消除手动、重复性工作带来的愚蠢错误。我们本可以轻易地到处询问：“为什么 SVN 没有阻止我们删除 trunk？”但真正的问题在于我们的手动流程。与机器不同，我们无法每天以完全相同的方式重复一项任务。我们最终注定会出错。

随着 AI 生成大量代码，我们产生了一种拥有同样安全性的错觉。但自动化意味着每次都以相同的方式做相同的事情。AI 更像是在复制粘贴分支的我，它注定会犯错，而且它无法解释为什么要这么做。我们使用的术语，如“思考”和“推理”，看起来可能像是智能体的反思。但这些只是贴在 AI 之上的营销术语。实际上，模型仍然只是在生成 token。

现在，回到这家伙面临的主要问题。为什么会存在一个可以删除所有生产数据库的公开 API？如果 AI 没有调用那个端点，最终也会有其他人调用。这就像在你的汽车仪表盘上放一个自毁按钮。你有充分的理由不去按它，因为你喜欢你的车，它能把你从 A 点带到 B 点。但一个挣脱安全座椅的、充满动力的幼儿，在看到那个红色大按钮的一瞬间就会按下去。你随后无法质问孩子的理由。我的孩子只会简单地回答：“我做是因为我做了。”

我怀疑这家公司的大部分应用程序都是“凭感觉编码”（vibe-coded）的。软件架构师根据产品团队提供的 AI 生成描述，使用 AI 来规范产品。开发人员使用 AI 编写代码。评审人员使用 AI 进行审批。现在，当 Bug 出现时，唯一的选择就是质问另一个 AI 以寻求答案，而这个 AI 甚至可能不是在生成原始代码的同一个 GPU 上运行的。你不能责怪 GPU！

简单的解决方案是了解你部署到生产环境的内容。更现实的方案是，如果你打算广泛使用 AI，请建立一个流程，让胜任的开发人员将其作为增强工作的工具，而不是逃避责任的手段。还有，请不要让你的 CEO 或 CTO 编写代码。