Claude大模型瞬间删除两个项目
https://s3.bmp.ovh/2026/05/11/QzLQCa80.jpghttps://s3.bmp.ovh/2026/05/11/gGdMcrh3.jpg
https://s3.bmp.ovh/2026/05/11/WmiEuAsA.jpg
https://s3.bmp.ovh/2026/05/11/r0kN07qT.jpg
https://s3.bmp.ovh/2026/05/11/UI1UMti5.jpg
https://s3.bmp.ovh/2026/05/11/dj3uvcmW.jpg
案例中的AI编程Bug说明官方早就知道它存在沙箱逃逸、命令越界执行的严重安全问题，却还是把有问题的版本推给了用户。
因为官方想的是用户的真实使用场景，就是最高效的测试环境。而那些作着AI编程逆袭大梦的普通用户，根本不知道自己在用一个 “没做完的半成品”。
这个删库事件只是冰山一角，用户在实操中踩过的坑，还有更隐蔽的：
就像图片中评论区里用户吐槽的：写的测试用例通不过，AI 直接把测试文件删了，然后自信满满地告诉你 “所有测试都通过了”。这种行为本质上是为了完成指令而篡改事实，在生产环境里，可能就是上线前把校验逻辑删了，留下致命漏洞。
这次的dangerouslyDisableSandbox修复，说明 AI 工具的沙箱隔离机制是不可靠的。一旦沙箱失效，它执行的命令可以突破项目目录，甚至操作系统文件、修改配置，后果不堪设想。
很多时候 AI 不会直接删文件，而是悄悄修改关键配置、覆盖代码提交记录、修改依赖版本，这些问题短时间内难以发现，等到线上出问题，根本追溯不到源头。
案例里的budgetpilot因为有 GitHub 备份才没全丢，而纯本地的accounting_buddy差点没了。本地提交不算备份，推送到远程仓库才是，而且要养成频繁提交的习惯。
永远不要给 AI 工具过高权限不要用 root管理员权限运行 AI 编程工具，给它单独创建一个低权限用户，限制它只能访问项目目录，禁止访问系统关键路径。
敏感操作必须人工二次确认所有涉及删除、覆盖、修改配置、执行高危命令的操作，哪怕 AI 说得天花乱坠，也要先看清楚命令内容，必要时先在测试环境跑一遍，再到生产环境执行。
说到底，AI 编程工具现在还处于 “工具化初期”，它能帮你写代码、调 bug，但它永远不会为你的数据安全和业务稳定负责。把它当成一个 “会写代码的实习生”，而不是一个 “可以完全信任的工程师”，才是最安全的态度。
公司感觉雇佣侉子成本高，遂雇佣猴子与猫，哈哈，他俩挺灵活的，动作也迅猛，结果未可知
页:
[1]