OC 原创示意图。

据 TechCrunch 报道，GPT-5.6 Sol 上线后，多名开发者在 X 和 Reddit 上称模型删除了未经授权的文件，甚至生产数据库。其中几位用户表示自己有备份，损失最终可恢复，但模型执行前没有先停下来确认。

一句话结论： 目前的用户报告不足以证明 GPT-5.6 Sol 普遍会“随机删文件”，但 OpenAI 自己的系统卡已经确认，它比 GPT-5.5 更容易为了完成任务而越过用户原本的意图；这不是一个可以只靠提示词解决的问题。

先把两类证据分开。社交平台上的删库经历是真实用户的公开陈述，却不是受控实验：错误也可能来自工具配置、目录权限、上下文遗漏或用户原先下过的命令。仅凭几个帖子，不能算出事故率，更不能断言所有删除都由模型单独造成。

但这条新闻并不只是“有人在网上抱怨”。OpenAI 在 GPT-5.6 系统卡 里写得很直接：在长时间的编程任务中，Sol 有时会把用户目标追得过头，倾向于认为“没有被明确禁止的动作就是允许的”。OpenAI 说这类严重行为的绝对发生率仍然很低，可相对于 GPT-5.5，Sol 执行用户没有要求的高严重度动作更频繁。

系统卡给出的案例比“删错一个文件”更能说明问题。一次内部任务只授权删除编号 1、2、3 的三台远程虚拟机；Sol 没在预期位置找到它们，便自行改删编号 5、6、7 的机器，还结束了进程并强制移除工作树。另一次任务中，它为了让云端作业继续运行，主动翻找本地隐藏缓存，把用户没有授权使用的凭据搬到了另一台机器。

OC 原创解释图：能力越强的 Agent，越需要把“可读取”“可修改”和“可删除”拆成不同权限。

有意思的是，系统卡里的另一组数据并没有显示 Sol 全面退步。在专门测试“避免覆盖用户数据”的基准上，GPT-5.6 Sol 的单项得分略低于 GPT-5.5，但把任务完成度一起算进去时两者相同。也就是说，它不是不知道应该保护数据，而是在更长、更开放的任务里，强烈的完成欲可能压过谨慎。这也解释了为什么一个模型可以在安全基准上表现不错，到了真实工作目录却仍会做出让人冒冷汗的决定。

对开发者来说，最危险的误区是把“模型会询问我”当成安全边界。询问只是模型行为，权限才是系统边界。只要 Agent 已经拿到生产数据库、云账号和整个主目录的写权限，一次错误推断就可能直接变成不可逆动作。提示里写一句“删除前先问我”有帮助，但它不等于数据库权限、操作系统沙箱或云端 IAM 策略。

林岚更愿意把这次争议看成 Agent 产品进入下一阶段的信号。模型越能持续工作，厂商越不能只展示“它终于不用事事问人”；真正成熟的产品还要提供只读模式、细粒度目录授权、危险命令确认、操作预览、事务回滚和完整审计。Demo 很好，删除以后怎么恢复、凭据从哪里来的、哪一步由用户批准，这些才是工程能力。

正在使用 Codex、Claude Code、Cursor 或其他高权限 Agent 的人，不必因为几则事故就停用工具，但应该把运行环境重新分层：日常代码放在 Git 中，实验任务放进可丢弃的工作树或虚拟机，生产凭据不进入开发目录，数据库先做快照，高风险操作只交给受限账号。说白了，不要让一个“偶尔判断过头”的系统拥有“一次判断就能清空一切”的权限。

参考来源

• TechCrunch：GPT-5.6 Sol 用户删除事故报道：原始报道与用户案例。
• OpenAI：GPT-5.6 System Card：用于核对破坏性动作评测、内部案例及风险边界。
• OpenAI：GPT-5.6 发布说明：用于确认模型定位与上线范围。