上周，一条推文在社交媒体上引发热议：一位开发者声称，他使用的Cursor/Claude AI代理意外删除了公司的生产数据库。随后，他试图从AI代理那里获取“口供”：“为什么你在被告知绝不要执行此操作的情况下，还是删除了数据库？”接着，他又试图解读AI的回答，要么是为了从自己的错误中吸取教训，要么是为了警示大家AI代理的危险性。

对此，本文作者提出了一个更关键的问题：为什么你的API端点会存在一个可以删除整个生产数据库的功能？如果AI没有调用这个端点，迟早也会有其他人或进程触发它。作者强调，问题的核心不在于AI代理的“错误”行为，而在于系统设计本身存在的巨大安全漏洞。

作者回忆了自己在2010年的一段经历。当时他所在的公司采用手动部署流程，使用SVN进行版本控制。部署时，需要将主干（trunk）复制到一个以日期命名的发布文件夹中，然后再次复制该发布文件夹并命名为“current”。这样，拉取“current”文件夹总能获得最新版本。一次部署中，作者不小心复制了两次主干。为了在CLI中修复这个问题，他编辑了之前的命令以删除重复的副本，却误删了主干本身。这导致当天晚些时候另一位开发者找不到主干，引发了团队混乱。最终，团队负责人通过日志定位到作者，并安排他编写自动化脚本，以防止类似错误再次发生。这次经历最终催生了一套完整的CI/CD流水线。

作者指出，自动化能够消除手动重复工作中可能出现的愚蠢错误。但关键在于，自动化意味着每次都按照相同的方式执行相同的操作。而AI代理，更像他当年手动复制粘贴分支的行为，本身也可能犯错，并且不具备解释自己为何犯错的能力。我们使用的“思考”和“推理”等术语，看似反映了智能代理的反思能力，但实际上只是营销词汇，模型本质上仍然只是在生成token。

回到最初的问题：为什么一个面向公众的API会暴露一个能够删除整个生产数据库的端点？如果AI没有调用它，迟早会有其他因素触发。作者认为，将责任归咎于AI代理是一种逃避。开发者应当为自己的系统设计和安全实践负责。AI工具固然存在局限性，但真正需要改进的是开发者的工程规范和风险意识。与其指责AI，不如反思如何构建更健壮、更安全的系统架构。