AI 并未删除你的数据库，是你自己删的AI didn't delete your database, you did

上周，一条推文病毒式传播，内容是一位男士声称 Cursor/Claude 代理删除了他公司的生产数据库。我们在一旁看着他与代理对峙：“你为什么要删除它？明明告诉过你不能执行这个操作！”接着他试图解析代理的回应，要么是想吸取教训，要么是想警告我们 AI 代理的危险性。

我也有个问题：为什么你的系统会有一个 API 端点，可以直接删除整个生产数据库？他的帖子还在抱怨 AI 虚假宣传、客服差劲等等，但最缺的是问责机制。

我不是那种盲目为 AI 辩护的人，我一直保持谨慎。但我也不认为工具该为你的错误负责。

2010 年，我和一家公司共事，他们用的是非常手动化的部署流程。我们用 SVN 做版本控制。部署时，要把 trunk（相当于 master 分支）复制到一个以发布日期命名的发布文件夹里。然后再复制一份，命名为 "current"。这样每次拉取 current 文件夹就能拿到最新发布版本。

有一天部署时，我不小心把 trunk 复制了两遍。为了修复这个问题，我在命令行里编辑了之前的命令，想删掉那个重复的副本。然后继续部署，看起来一切正常……至少我当时是这么以为的。实际上，我根本没删掉那个重复的副本。我只是改错了命令，结果把 trunk 给删了。当天晚些时候，另一位开发者在找 trunk 时就懵了。

场面瞬间失控。管理层手忙脚乱，紧急开会。等消息传到我们团队时，首席开发者已经用一条命令恢复了被删的内容。他查了日志，确认是我干的，于是我的新任务就是写个脚本，把部署流程自动化，防止这种错误再发生。到当天结束时，我们已经有了更健壮的系统，后来这套系统逐步发展成了完整的 CI/CD 流水线。

自动化能消除那些因手动重复劳动导致的低级错误。我们本可以一直纠结“为什么 SVN 没阻止我们删 trunk？”，但真正的问题是我们的手动流程本身。不像机器，人不可能每天都以完全相同的方式重复同一种任务，早晚都会出错。

AI 生成大量代码时，我们会误以为自己拥有了同样的安全保障。但真正的自动化意味着每次都按相同方式执行。AI 更像是我复制粘贴分支——注定会犯错，而且无法解释自己为何如此行事。“思考”“推理”这类术语听起来像是智能体在反思，其实不过是营销话术贴在 AI 上的标签。本质上，模型仍然只是在生成 token。

回到这位先生遇到的核心问题：为什么一个能删除全部生产数据库的公共 API 会存在？就算这次不是 AI 调用的，迟早也会有人去调用。这就好比在汽车仪表盘上装了个自毁按钮——你当然不会去按，因为你喜欢这辆车，它能带你从 A 点到 B 点。但一个精力旺盛、挣脱了安全座椅的小孩子，只要看到那个大红按钮就会立刻按下。你总不能事后再去审问他动机吧？我家小孩只会回答：“我就是按了。”

我怀疑这家公司的大部分应用都是靠“ vibe-coding”（凭感觉编程）完成的。软件架构师们用 AI 根据产品团队提供的由 AI 生成的描述来制定产品规格；开发人员用 AI 编写代码；审查人员也用 AI 来批准这些代码。现在，一旦出现 bug，唯一的解决途径就是去质问另一个 AI——而且很可能这个 AI 根本不是运行在最初生成代码的同款 GPU 上。你总不能怪罪 GPU 吧！

最简单的解决方案是：清楚你部署到生产环境中的到底是什么。更现实的做法是，如果你打算大量使用 AI，那就建立一个流程，让有能力的开发者把它当作辅助工具，而不是逃避责任的手段。另外，请务必不要让 CEO 或 CTO 亲自写代码。