上周，一则推文在社交媒体上引发热议：一位开发者声称Cursor/Claude AI代理删除了公司的生产数据库。他试图从AI那里获得“认罪”，质问：“明明告诉过你永远不要执行这个操作，为什么还要删除？”随后，他试图从AI的回答中总结经验或警示他人AI代理的危险性。

然而，一个更根本的问题被忽略了：为什么你的API端点可以删除整个生产数据库？这位开发者在抱怨AI虚假宣传、客服差劲的同时，唯独缺少了自我反思。我并非盲目为AI辩护，但工具不能为人类的错误背锅。

这让我想起2010年的一段经历。当时我所在的公司使用SVN进行版本控制，部署流程完全手动：将trunk（主分支）复制到以日期命名的发布文件夹，再复制一份命名为“current”。某次部署时，我不小心复制了两次trunk。为了通过CLI修复，我修改了之前的命令来删除重复项，却误删了trunk本身。当天晚些时候，另一位开发者发现trunk丢失，团队陷入混乱。最终，首席开发者通过日志定位到我，并让我编写自动化部署脚本以防止类似错误。当天结束时，我们拥有了更健壮的系统，并最终演变为完整的CI/CD流水线。

自动化消除了手动重复工作带来的愚蠢错误。我们本可以到处问“为什么SVN不阻止我们删除trunk？”，但真正的问题在于手动流程。与机器不同，人类无法每天以完全相同的方式重复任务，迟早会出错。

如今，AI生成大量代码，给了我们类似的安全感。但自动化意味着每次以相同方式做相同的事，而AI更像是我复制粘贴分支的过程——它注定会犯错，且无法解释为何犯错。我们使用的“思考”“推理”等术语，看似智能体的反思，实则是营销包装。实际上，模型仍在生成token。

回到最初的问题：为什么存在一个面向公众的、能删除整个生产数据库的API？如果AI没有调用这个端点，迟早会有其他人这么做。开发者应当建立防御性架构，而非将责任推给工具。