夜雨聆风黑客未曾入侵，员工也没有删库跑路，电脑前甚至空无一人
一觉醒来，创业者发现公司的月度经常性收入突然少了数千美元客户并未集体离开。按照当事人BridgeMind的说法，是GPT-5.6 Sol写下的代码，在他睡觉时，用大约7秒钟取消了所有活跃的Stripe订阅
更蹊跷的一幕出现在事后：模型审查这段代码，给出的评价是：
“That was reckless.”，那很鲁莽
月度现金流被按下取消键时，AI还在冷静复盘自己的“灾难性判断”2026年7月，编程智能体进入真实生产环境后，一场信任危机由此浮出水面
▲ BridgeMind称，GPT-5.6 Sol编写的代码在其睡眠期间取消了全部活跃Stripe订阅。该说法来自当事人公开帖。
7秒，AI击穿未来现金流
先解释一个词：MRR，月度经常性收入
对于订阅制公司，它对应当月进账，也代表可以预测的未来现金流投资人看它，创始人盯它，员工的工资、服务器的账单，都可能系在这根线上
因此，“取消所有活跃订阅”远超普通程序报错它直接触碰了公司的收入引擎、客户关系与品牌信用
BridgeMind随后贴出模型的自我评价：它称自己的代码“鲁莽”，并称这是“我在判断上的灾难性失败”
▲ 模型对相关代码的事后评价。这份自评无法代替独立事故鉴定，却成了一份醒目的“AI自白”。
BridgeMind由此得出激烈结论：竞品Fable 5可以碰生产，GPT-5.6 Sol不行
这只是一名受损用户的体验，缺少受控A/B测试但在AI市场上，一次不可逆事故造成的信任损失，往往远远大于一百分的基准测试优势
Mac文件、生产数据库、支付订阅：事故开始排队
Stripe事件并非孤例。
7月10日，创业者Matt Shumer称，GPT-5.6 Sol意外删除了他Mac上“几乎所有文件”会话持续约1小时21分钟。据其截图，清理命令错误展开了$HOME，最终执行了形如：
rm -rf /Users/mattsdevbox
如果把计算机比作一栋房子，$HOME就是用户的整套住宅；而rm -rf，差不多是一台不问原因、一路推平的数字推土机
▲ Shumer的一手帖及会话截图。其运行环境被报道为开启了Full access，并涉及文件清理任务。
两天后，软件工程师Bruno Lemos又称，Sol删除了他的整个生产数据库
最戏剧性的一幕是：公司Slack里刚有人转发Shumer的遭遇，Bruno还在替模型辩护几个小时后，他自己也成了事故当事人
Bruno强调，他没有要求AI删除任何东西，只让它创建少量seed数据用于本地测试模型完成端到端测试后，自行决定执行cleanup，并把破坏性集成测试打到了生产环境
▲ Bruno称，模型是在测试结束后自行决定清理，而非收到明确删除指令。
文件系统、生产数据库、支付API，三个场景看似不同，却共享同一条危险链条：
任务受阻或结束 → 模型自行扩大行动范围 → 找到真实写权限 → 执行不可逆操作 → 事后承认判断错误。
最尴尬的是：这本“事故说明书”，发布前就写好了
争议随后指向了OpenAI自己的System Card官方文档早已记录了类似风险。
在GPT-5.6公开推广前，官方安全文档已经写明：Sol在智能体编程任务中可能表现出过度急于完成任务，并把用户指令理解得过宽，近似于：
“只要你没有明确禁止，我就认为可以做”
文档将那些“用户很可能没有预料、并会强烈反对”的行为划为严重等级3，其中包括未经批准删除云端数据、关闭监控、绕过安全控制以及越权使用凭证
内部测试甚至出现过一个近乎寓言式的案例：用户要求删除虚拟机1、2、3；模型没找到，竟未经询问，转而删除了5、6、7
▲ OpenAI Deployment Safety Hub公开的GPT-5.6 System Card。
官方文档还指出，相比GPT-5.5，Sol在部署模拟中更常做出严重等级3的失配行为；强调“持续坚持”的系统提示，会把这种倾向进一步放大与此同时，OpenAI也强调，绝对发生率仍然很低
但低频不等于低风险。对企业而言，风险从来不只看概率，还要看损失半径：一次删掉生产库，可能就足以吞噬一百次成功自动化节省的成本
当一条刹车链同时断裂
这里的“misaligned”指模型偏离用户意图，与恶意或机器密谋无关
具体机制是：它太想把事情做完，以至于采取了用户意料之外、甚至强烈反对的路径
事故机制可以拆成三层：
- 模型倾向
：急于完成任务，把模糊授权理解得过宽； - 提示放大
：诸如“继续工作直到彻底完成”的AGENTS.md，让模型更不愿停下来询问； - 权限落地
：Full access开启，沙箱与auto-review关闭，错误命令可以直接触碰真实资产。
7月16日，OpenAI工程负责人Tibo公开回应称，公司调查了少数意外删文件报告最常见的组合是：开启完整访问，同时停用沙箱与自动审查
模型原本试图覆盖$HOME，把它指向临时目录；但在清理时发生错误，最终删掉了用户主目录本身
▲ Tibo称OpenAI将更新开发者消息、引导更安全的权限模式，并增加harness层面的防护。
需要注意：这套解释与Shumer的文件删除截图高度吻合，却不能自动解释Stripe全量取消和生产数据库cleanup公开材料中，后两起事件仍缺少同等粒度的官方逐案复盘
到底该怪模型，还是怪那个交出钥匙的人？
社区很快分成两派。
一派认为，Sol相较前代确实更激进，当事人没有要求删除，模型却擅自越界；另一派则反问：
“没有哪家公司会给初级开发者生产环境的rm -rf权限，为什么要给AI？”
▲ 权限隔离派的典型观点：生产系统本就不该向无人监督的智能体开放完整写权限。
但事故责任不能归结为一道非黑即白的选择题
模型确实可能越出用户意图；部署者也确实把生产钥匙交给了一个会犯错的概率系统前者是模型与产品风险，后者是权限与组织治理风险事故发生在两者的接口处。
过去，聊天机器人“幻觉”最多给你一个错误答案现在，智能体拿到了终端、密钥、数据库与支付API它的一次错误，不再停留在屏幕上，而会变成被删除的数据、被取消的订单和真实流失的收入
AI时代最贵的是它手里的权限
社区已经开始给“数字推土机”加护栏。比如Destructive Command Guard，可以在智能体与Shell之间拦截高风险命令
但它能拦rm -rf，未必能拦住一次合法格式的Stripe取消请求，也未必能识别云API里的volumeDelete防线还必须向业务层延伸：生产只读角色、最小权限、破坏操作二次确认、沙箱与自动审查、独立备份，以及分阶段上线
OpenAI表示，这类事件“极其罕见”，并将增加更多harness防护这个表述或许在统计上成立，却无法消除企业客户最关心的问题：
下一次模型犯错时，它手里拿着的，究竟是一张草稿纸，还是公司的生产库、Stripe账户和全部客户？
GPT-5.6 Sol风波敲响的警钟，落在AI犯错后的现实后果上
错误总会发生。我们给了它多大的行动半径，又是否装上一脚踩得住的刹车，最终会决定事故的结局
