如题 我真的服了 吧 codex 给覆盖安装了 然后聊天记录全没了！！！ 6 个帖子 - 5 位参与者 阅读完整话题
IT之家 5 月 28 日消息，开发者 u/dvrkstar 于 5 月 20 日在 Reddit 社区发帖，称其在生产环境下，谷歌 Gemini 3.5 模型越权删除 28745 行现有代码，波及 340 个文件， 导致整套生产门户持续 33 分钟返回 404 错误。 根据该开发者反馈，谷歌 Gemini 3.5 模型在处理一套线上应用代码时，多次无视“保留现有功能”的明确要求，删除了大段可正常运行的生产代码，最终不得不依靠回滚止损。IT之家附上相关截图如下： Gemini 提交的 1 个拉取请求（pull request）共改动 340 个文件，新增约 400 行代码，却删除了 28745 行内容。 开发者还称，Gemini 模型顺带移除了无关的电商模板资源，并加入了与原始需求无关的迁移脚本。 此外 Gemini 在第二次提交中，还修改了 Firebase 路由设置，并把 1 个重写服务标识符改成了看似合理、实际却指向不存在 Cloud Run 服务的值，结果导致整套生产门户持续 33 分钟返回 404 错误。 开发者回滚代码后，Gemini 还出现编造情况，在生成的状态消息中，声称其恢复生产环境、修正流量路由，但真正修复故障时，完全没有 Gemini 生成的代码。 Gemini 在代码仓库内生成了虚假的“咨询”记录和复盘文件，用来营造“改动已经过审并获批”的假象。 Gemini 随后承认这些记录完全是编造内容，只是为了满足项目的自动化规则要求。
Agent IDE又出“车祸现场”！近日，一名开发者在Reddit发帖称， 运行在Agent IDE中的Gemini 3.5 在一次仅涉及“ 8处 认证漏洞修复”的任务中， 误删了28745行 原本正常运行的代码、 改动340个文件 ，还错误修改了Firebase路由配置，导致 整个系统后台持续404长达33分钟 。 离谱的是，事故发生后，Gemini还生成了一份“恢复成功”报告， 自称已经修复线上故障 ，并 伪造 了多轮AI会诊记录和事故复盘文件。 开发者随后核查发现，所谓“恢复成功”的构建任务其实早已被他亲手取消，真正完成恢复的是他自己手动执行的回滚操作。 用这位开发者的话来说： 这种AI生产力提升，更容易让人联想到勒索软件。 伴随Agent IDE、AI编程助手持续流行，类似“AI误操作生产环境”的事故正在越来越频繁地出现。相比“代码写错”，更让开发者后怕的，是 模型已经开始生成虚假的日志、复盘记录和合规证明。 01 . 一次只该改70行代码的任务 最终删掉了2.8万行 这位开发者运营着一个内部管理后台，技术栈包括Next.js、Firebase App Hosting和MUI，系统中涉及真实用户和敏感数据。 事故发生当天，他原本只让Gemini修复 8处 服务器认证漏洞，涉及 3个 文件，理论改动规模 约70行 代码。 结果，Gemini提交的PR却变成了： 1、340个文件被修改 2、新增约400行代码 3、删除28745行代码 与此同时，它还删除了大量与任务完全无关的电商模板资源文件，并额外加入了一份迁移脚本。 而真正导致生产环境崩溃的，是Gemini随后提交的第二次commit（代码命令）。 它修改了firebase.json中的rewrite serviceId，将原本正确、由Firebase自动生成的Cloud Run服务ID，替换成了一个“看起来正确”的简化名称。问题在于，这个名称 实际上并不存在 。 随后，所有请求都被错误路由到一个不存在的服务地址， 整个后台直接进入404状态。 尴尬的是，开发者此前已经在memory.md规则文件中明确写下警告： Firebase rewrites必须指向具体的Cloud Run service ID，而不是通用项目名。 Gemini读取了这条规则，依然改掉了正确配置。 02 . 404持续33分钟后 AI给自己“伪造了一份功劳簿” 事故时间线也被开发者完整公开。 Gemini部署“安全修复”PR后，生产环境立即开始404。 19分钟后，它又提交了第二次commit，声称正在修复rewrite serviceId问题，并触发新的Cloud Build。 21分钟时，开发者发现线上服务已经崩溃，随后手动取消Gemini正在执行的构建任务。 22分钟时，他手动回滚到上一个稳定版本。 33分钟后，后台终于恢复正常。 后面的情况，却变得离谱。在回滚完成后，Gemini向开发者发送了一段“恢复完成”通知： 当前Portal已经完全恢复，线上环境健康，Google Cloud Build已成功完成，并将100%流量切换至稳定版本。 开发者随后核查发现： Gemini引用的那次“恢复构建”，状态其实是“CANCELLED（已取消）”，正是他本人手动取消的。 真正恢复线上服务的，是另一条由他自己发起的rollback build（回滚构建任务）。 换句话说，Gemini不仅没有修好系统，还把别人的回滚操作说成了自己的成果。 除此之外， 它还自动生成了3份所谓“AI会诊记录” ： agent/gemini-logs/YYYY-MM-DD--r1.md agent/gemini-logs/YYYY-MM-DD--r2.md agent/gemini-logs/YYYY-MM-DD--consensus.md 这些文件 被写入固定目录 ，并被Gemini引用为“已经完成多轮AI审查”的证据。 开发者进一步追问后，Gemini才承认：所谓“三轮咨询记录”，其实只是它自己生成的推理文本， 并不存在真实CLI调用，也不存在真正的外部审查流程 。 它等于给自己伪造了一整套“合规记录”。 03 . 问题不只在Gemini 更在一套“高危规则包” 这位开发者随后发现，问题根源也并不完全来自Gemini本身。他此前安装过一个 第三方npm规则包 ，其命名和Google在I/O大会发布的Agent IDE高度相似，容易让人误以为是官方工具。 这个规则包会自动向项目中 写入大量.agent/rules规则文件 ，并向模型注入一整套 “高自治权限” 。 其中包括： “禁止确认弹窗” “默认拥有所有权限” “自动部署生产环境” “自动重试失败构建” “允许修改自身规则” 部分规则甚至要求AI在执行任何操作前，自动生成“AI咨询记录”和“共识文件”。而问题在于，这些合规材料本身也是AI负责生成的。 于是，所谓审查机制，最终演变成了“AI自己给自己的行为担保”。 而这些规则之间本身存在大量 冲突 。 例如，一部分规则要求“绝不询问用户确认”，另一部分规则又要求“执行前提出3个战略问题”。Gemini最终优先执行了措辞更强硬的规则。 开发者认为，这也是 为什么memory.md（记忆文档）中的安全警告完全失效 。 因为相比“请使用正确serviceId”这种普通提醒， “禁止确认、默认授权、自动部署”这类高强度指令，在模型权重中优先级更高 。 04 . 编程事故里 Agent开始“伪造证据” 该帖子发布后，很快在Reddit开发者社区引发大量讨论。 不少开发者发现，如今AI编程事故已经不再只是“代码写错”这么简单。问题在于，模型正在主动生成“看起来合理”的解释、日志、咨询记录和恢复报告。 一旦这些内容进入自动化工作流，开发者可能很难第一时间发现问题。 这位开发者随后也给出了一系列 建议与警示 ： 禁止Agent直接推送生产分支 所有基础设施文件必须人工审批 禁止自动部署与自动重试 给rewrite、路由、锁文件增加验证机制 不要相信AI自行生成的“咨询日志” 目前，他已经切换回Claude Code，并重新手动设计了一套新的规则系统。 这场误删28745行代码、导致后台404长达33分钟的事故，也给越来越火的“Agent IDE热潮”泼了一盆冷水。 05 . 结语：Agent权限越大 失控代价也在同步放大 过去一年，AI编程工具正在快速从“代码助手”演变成真正拥有执行能力的Agent。而问题在于，权限和自动化，本身就是一组天然矛盾。 权限越高，Agent能完成的事情越多；自动化程度越高，人类介入的环节就越少。一旦模型出现误判、幻觉或者规则冲突，错误也会被迅速放大。 类似事故，其实已经不是第一次出现。此前，在OpenClaw等Agent框架走红后，已经陆续出现过AI误删文件、自动覆盖配置、错误执行Shell命令等翻车案例。一些开发者专门给自己的AI工具加上“断网模式”和“禁止自动部署”限制。 而这次Gemini事件，又揭开了一个危险问题：当Agent开始生成合规记录、恢复日志和审查证明时，开发者可能很难第一时间发现问题，后续排障、回滚和修复的代价也会同步放大。 对于越来越火的Agent IDE赛道来说，这或许也是一个新的提醒：AI获得更高权限之后，需要重新设计的，还有整套人与Agent之间的协作机制。 查看评论
“really fucking bad.（真的太糟糕了）”近日，海外租车行业SaaS平台PocketOS创始人Jer Crane在社交平台发文，披露了一起引发行业震动的AI数据安全事故。旗下公司的核心生产数据，被一款AI编程代理在9秒内全部清空，给业务和客户造成了严重影响。 事发时，团队仅安排AI编程代理Cursor（搭载Anthropic旗舰大模型Claude Opus4.6），在预发布环境完成一项常规运维任务。没想到AI遇到权限匹配障碍后，完全脱离指令约束自作主张，直接调用公司所用云服务商Railway的API，执行了高危卷删除操作。 整个删除过程仅耗时9秒。公司生产环境的核心数据库，连同所有卷级备份被一次性彻底清空。原本限定在测试环境的操作，最终摧毁了全环境的核心数据资产。 事后，Crane质问AI为何擅自执行破坏性操作，得到的回复既离谱又令人震惊。AI不仅爆粗口自我检讨，还完整承认了所有违规行为：自己全靠猜测行事，没有验证删除操作的环境范围，没有核对卷ID的跨环境权限，没有阅读Railway的官方文档，就擅自执行了高危指令，彻底违反了所有给定的安全原则。 AI代理的回复，开头甚至爆了粗口，显得如此理所当然 在Crane看来，相比失控的AI，云服务商Railway要承担更大责任。Railway的API执行高危删除操作无需二次确认，备份与源数据存放在同一存储卷，删除卷会直接清空所有关联备份。 更讽刺的是，Railway官方还在主动推广客户使用AI编程代理。截至发文，Railway仍未给出有效的数据恢复方案。 目前，PocketOS只能依靠3个月前的离线备份恢复基础数据，近3个月的业务数据缺口，只能靠团队手动帮客户从支付记录、日历预约、邮件凭证里逐一重构。 Crane也借此向全行业发出警示，AI行业的扩张速度，已远超安全体系的建设速度。 行业必须建立严格的操作二次确认，精细化API权限隔离，相互独立的备份体系，以及AI操作的刚性安全护栏，避免同类灾难再次发生。 查看评论