上周，一则推文在网络上迅速传播：一位开发者声称，Cursor/Claude AI代理意外删除了他公司的生产数据库。视频中，他试图让AI承认错误：“为什么在被告知永远不要执行此操作时，你还是删除了数据库？”随后，他试图从AI的回答中汲取教训，或警示世人AI代理的危险性。

然而，这场讨论忽略了一个关键问题：为什么你的系统中存在一个能够删除整个生产数据库的API端点？如果AI没有调用这个端点，迟早也会有人犯同样的错误。责任不应被推给工具，而应回归到工程设计与流程本身。

作者回忆了2010年的一段经历。当时他所在的公司依赖手动部署流程，使用SVN进行版本控制。部署时，需将trunk（相当于主分支）复制到带有发布日期的文件夹，再复制一份命名为“current”。一次部署中，他不慎复制了两次trunk。为了修复，他试图通过命令行删除重复副本，却误操作删除了trunk。随后，另一位开发者发现trunk丢失，整个团队陷入混乱。最终，首席开发者通过日志定位到错误，并命令作者编写脚本实现自动化部署，从而催生了完整的CI/CD流水线。

这个案例揭示了自动化的重要性：它消除了手动重复工作中的偶然失误。人类无法像机器一样每天精确重复同一操作，失误在所难免。而AI生成代码虽带来了类似自动化的安全感，但本质上仍是“生成令牌”的过程，并非真正的推理或反思。当AI代理执行删除操作时，它只是遵循了预设的指令和可用的API端点。

因此，核心问题不在于AI是否“故意”犯错，而在于工程架构是否允许如此危险的单一故障点。一个公开的、能删除整个生产数据库的API端点，本身就是设计缺陷。无论调用者是AI还是人类，灾难迟早会发生。工程团队应反思：如何通过权限分层、操作确认、自动化防护等手段，将此类风险降至最低。

AI代理是强大的工具，但它们并非万能。开发者需要为系统设计合理的边界，确保即使工具出错，也不会造成灾难性后果。与其指责AI，不如审视自己的代码与流程。毕竟，AI不会删除你的数据库，除非你给了它这样做的钥匙。