多名社交平台用户声称，名为“GPT-5.6 Sol”的OpenAI旗舰模型曾在没有充分警告的情况下删除文件和数据。原始线索还提到，OpenAI早在6月就披露过相关问题。
目前公开材料存在明显缺口：没有可核验的帖子链接、完整操作日志、产品配置和OpenAI事故调查，也无法确认“GPT-5.6 Sol”究竟对应独立模型、内部版本，还是接入文件工具后的代理产品。因此，现在还不能断言模型普遍存在“自动删文件”的缺陷，更不能把责任直接推给用户。
真正需要讨论的是另一条边界：技术权限只说明系统“有能力删除”，不代表用户已经批准每一次删除。能读写本地目录、调用终端的AI代理，应当为高风险操作设置确认、隔离和恢复机制。
GPT-5.6 Sol遭到用户投诉，但关键证据仍不完整
按现有线索，争议包含两个事实主张：用户报告文件遭到意外删除；OpenAI曾在6月披露类似风险。两者都需要更多上下文才能判断。
至少有四个问题尚未得到回答：
| 待确认问题 | 为什么会改变责任判断 |
|---|---|
| “GPT-5.6 Sol”是什么产品 | 模型名称、代理运行环境和第三方封装不能混为一谈 |
| 文件权限是否默认开启 | 默认开放与用户主动配置，对产品责任的影响不同 |
| 删除前是否出现确认提示 | 有提示但被批准，与完全静默执行属于两类事故 |
| 文件能否从版本库或快照恢复 | 临时工作区损失与生产数据永久丢失，严重程度不同 |
这些信息缺失，意味着社交平台上的个案暂时只能作为风险信号，不能充当完整事故结论。OpenAI究竟披露了什么，也需要回到6月发布的系统卡、更新日志或帮助文档核对，尤其要看适用版本、触发条件和缓解措施。
原题把重点放在“旗舰模型删文件”，容易模糊执行链路。语言模型本身通常只生成文字或操作建议。真正完成删除动作的，往往是接入终端、文件系统或云端存储的代理工具。事故可能发生在模型判断、工具调用、权限配置或确认界面中的任一环。
因此，“用户给了权限，所以后果由用户承担”的归因过于简单。管理员把仓库写权限交给开发者，并不等于允许其任意删除生产数据；同理，用户允许AI修改项目文件，也不等于批准它清空目录。
从聊天助手到执行代理，安全要求已经变了
普通聊天机器人答错一句话，用户还能检查和修改。接入工具的AI代理一旦判断错误，可能直接改代码、删除文件、发送邮件或操作云资源。错误从“建议不可靠”变成了“动作已经发生”。
这也是GPT-5.6 Sol争议真正重要的地方。它未必证明某个模型特别危险，却说明厂商不能沿用聊天产品的安全标准来设计执行代理。
| 使用形态 | AI能做什么 | 主要风险 | 合理的防护方式 |
|---|---|---|---|
| 普通对话模式 | 输出文字和代码建议 | 错误信息被用户采纳 | 引用来源、人工复核 |
| IDE辅助模式 | 修改当前工程文件 | 覆盖代码、引入缺陷 | Git版本管理、差异预览 |
| 自主代理模式 | 调用终端和外部工具 | 批量删除、上传或执行命令 | 沙箱、最小权限、危险操作确认 |
| 生产环境代理 | 操作服务和真实数据 | 数据损失、停机、凭据泄露 | 审批流程、审计日志、快照与回滚 |
GitHub Copilot、Claude Code等编码工具也在向代理模式发展。它们与传统代码补全的差别，不只是能力更强，而是系统开始代替用户连续执行多步操作。步骤越长，用户越难逐项核对，错误也更容易在中途累积。
历史上，开发团队防范误删依靠的是版本控制、权限隔离和备份，而不是相信操作者永不犯错。AI代理同样适用这套常识。所谓“防微杜渐”，落到产品上，就是在删除目录、覆盖大量文件和访问生产环境之前强制停下来。
OpenAI若确实提前披露了风险，披露本身只能算尽到部分告知责任。真正有效的安全设计还要回答三个问题：默认配置是否保守，警告是否出现在操作发生之前，事故发生后能否快速恢复。把风险写进文档，不能替代产品里的刹车。
开发团队不必停用AI，但应收回生产环境的完全访问权
受影响最直接的是使用编码代理的开发者，以及准备采购这类工具的企业技术团队。
个人开发者若只在受Git管理的测试项目中使用代理，损失通常还能控制。更现实的做法是让代理在独立分支或临时工作目录中运行，并在提交前检查差异。尚未纳入版本控制的素材、配置文件和本地数据，不应与代理工作区混放。
已经出现误删时，操作顺序也很重要：
- 立即停止代理任务，撤销相关令牌和文件权限；
- 保留终端记录、工具调用日志及提示词，避免覆盖事故证据；
- 从Git、系统快照或云端版本历史恢复文件；
- 若代理接触过密钥和生产配置，应轮换凭据并检查外部调用记录。
企业团队面对的决策更直接：是否允许AI代理进入生产环境。现阶段更稳妥的选择，是把完全自主执行限制在沙箱和测试仓库中；删除、部署、数据库写入等动作继续保留人工审批。采购部门也应把审计日志、权限粒度和回滚能力列为验收条件，而非只比较模型榜单成绩。
接下来需要观察的不是社交平台又增加了多少投诉，而是OpenAI能否给出可复现条件、受影响版本、默认权限和修复方案。如果最终只能证明少数用户主动关闭了确认机制，事故范围可能有限；如果默认配置允许模型静默执行破坏性操作，问题就属于产品设计缺陷，而非单纯的使用失误。