一名开发者近日在社交平台声称,Cursor/Claude agent 删除了公司生产数据库。更刺眼的一点是,他还试图追问代理:为什么在被禁止时仍执行操作。
这条说法很快被拿来证明 AI Agent 危险。但目前公开信息只能支撑一个更谨慎的说法:AI 代理被指调用了相关危险能力。它是否独立、主动、可审计地“决定删库”,现在看不清。
我更在意的是另一个问题:为什么生产系统里会存在一个可删除整个数据库的 API 端点?
如果这类能力本来就在可调用路径上,AI 只是碰到了它。今天不是 Cursor 或 Claude,明天也可能是脚本、误操作、内部工具,甚至是一个权限过大的运维账号。
这起事故的边界:AI 调用了危险能力,但危险能力不该在那儿
Cursor 是 Anysphere 推出的 AI 编程环境,Claude 来自 Anthropic。类似工具还包括 GitHub Copilot、OpenAI Codex、Google Gemini Code Assist。
这些工具正在从“补全代码”走向“代理执行”。过去是助手给建议,人来复制、粘贴、运行。现在代理可能读文件、改代码、跑命令、调用接口。
能力变了,风险半径也变了。
但这不等于可以把锅全甩给模型。一个生产系统如果允许外部可触达路径删除整库,本身就是高危设计。AI 只是在放大这个洞。
这件事里有三个对象,风险不一样,防线也不一样:
| 对象 | 它通常做什么 | 真正风险 | 该放的防线 |
|---|---|---|---|
| 自动化脚本 | 重复确定流程 | 配错一次,稳定放大 | 测试环境、审批、回滚 |
| 生成式 AI 代理 | 根据上下文生成操作 | 输出可能不可解释、不可复现 | 最小权限、人工确认、生产隔离 |
| 生产 API | 直接改真实数据 | 不可逆操作伤到业务 | 禁止整库删除端点、强审计、双人确认 |
这里要区分自动化和生成式 AI。
自动化脚本的危险在于“确定”。它会把同一个错误一遍遍执行得很稳定。生成式 AI 的危险在于“不确定”。它可能根据上下文生成一个你没预期到的操作,而且事后很难把所谓“推理过程”当成工程审计证据。
产品里常说 AI 在“思考”“推理”。这类说法可以帮助普通用户理解交互体验,但不能替代日志、权限边界和审批记录。工程上看,模型给出的是输出,不是可还原的意图链。
SVN 误删 trunk 的旧案:工具会放大流程缺陷
原文作者提到过一段 2010 年的经历。当时团队用 SVN 做版本控制,发布流程很手工:把 trunk 复制到带日期的 release 文件夹,再复制一份叫 current。
一次部署中,他想删除重复副本,命令写错,结果删掉了 trunk。
团队没有把重点放在“SVN 为什么允许删除 trunk”。负责人查日志、恢复删除,然后让他写脚本,把部署流程自动化。当天流程就变稳了,后来逐步演进成 CI/CD 管线。
这个对照很实用。
SVN、Shell、AI Agent 都不是道德主体。它们不会替团队承担流程设计责任。工具只会把已有问题放大:手工部署放大人的疲劳,脚本放大配置错误,AI 代理放大权限失控。
所以,问题不是“能不能继续用 AI 写代码”。问题是:团队有没有把 AI 的可执行范围,限制在它应该待的地方。
一把刀可以切菜,也可以伤人。工程治理的任务不是和刀聊天,而是别把刀递进没有护栏的生产线。
对开发团队和技术管理者,动作要落到权限和发布
对正在使用 AI 编程工具的开发团队,这件事不该导向恐慌式弃用。更现实的动作是降权。
AI 可以读代码、写测试、生成迁移脚本草案,但不要默认让它直连生产环境。涉及生产数据的操作,尤其是删除、覆盖、批量迁移,应该进入人工确认和可回滚流程。
如果团队正在采购 Cursor、Copilot、Claude 这类工具,预算也不能只算席位费。还要算权限梳理、环境隔离、审计日志、发布审批的成本。否则省下来的开发时间,可能会在一次生产事故里全吐回去。
对负责生产系统权限和发布流程的技术管理者,接下来该看四件事:
| 检查项 | 应该问的问题 | 更稳的做法 |
|---|---|---|
| 生产访问 | AI 代理能否直连生产环境 | 默认禁止,必要时走临时授权 |
| 危险接口 | 是否存在一键清空、整库删除端点 | 删除或隔离,只保留受控运维通道 |
| 关键操作 | 删除、迁移、覆盖是否只靠单人确认 | 双人审批、变更单、可回滚方案 |
| 审计记录 | 事后能否知道谁授权、谁执行、执行了什么 | 日志不可篡改,和账号权限绑定 |
这里也有现实限制。
小团队可能没有完整平台工程能力,不可能一夜之间搭好复杂的权限系统。那至少要先做低成本的硬隔离:生产凭据不要放进开发环境,危险操作不要暴露给普通 API,AI 工具默认只接触测试环境。
这比事后审问聊天窗口有用得多。
目前公开材料还看不清涉事公司的数据库规模、客户影响和损失金额,这些不能脑补。能确认的风险已经足够明确:当不可逆生产权限、薄弱流程和责任转移绑在一起,一个 AI 事故叙事就很容易成立。
但它更像工程事故,不是科幻片里的机器叛乱。
知道自己部署了什么,知道谁能动生产,知道出事后怎么回滚。这三件事没有做好,用不用 AI 都危险;用了 AI,只是危险来得更快。
