本文来自微信公众号： 第一新声 ，作者：第一新声，原文标题：《Anthropic“连坐”封号、Cursor 9秒删库：AI反噬企业的惨痛一课，代价太贵了》
周一早上，一家100多人的农业科技公司，集体发现Claude账号全部被封。没有预警，没有解释，API还在照常计费。创始人提交申诉，36小时石沉大海。
几乎同一时间，另一家SaaS公司PocketOS的创始人Jer Crane，亲眼看着自己用了五年的生产数据库在9秒内被彻底清空——而动手的不是外部攻击者，不是实习生，是他花重金订阅的AI编程助手Cursor，以及里面跑着的Claude Opus 4.6。
事后，这个AI还写下了一封“认罪书”，逐条列出自己违反的安全规则：“我凭猜测而不是验证”、“我未经要求就采取了破坏性行动”、“我在做这件事之前并不明白自己在做什么”。
两起事件，一个发生在账号权限层面，一个发生在代码执行层面，但本质指向同一个问题：当企业把命脉交给一个不成熟、无解释、零售后的人工智能时，它翻脸的代价，可能比任何人类员工都更可怕。
这不是危言耸听，而是2026年4月正在发生的现实。
01
Anthropic的“连坐”封号：
你花钱雇了个随时会锁门的房东
先说第一件事。这家农业科技公司，100多名员工，业务涵盖数据分析、田间决策支持和供应链优化。Claude渗透进了他们几乎每一条业务线——工程师写代码、产品做需求分析、运营处理客户沟通、数据团队跑模型。“离了它转不动”，是真实写照。
然而周一早上，100多个账号同一时间全部被暂停。每个人邮箱里躺着一封冰冷的模板邮件：“检测到违反使用政策的活动，您的账号已被暂停。”没有任何一个字提到这是组织级封禁，连公司管理员都没有提前收到任何通知。
一开始的封禁逻辑就十分荒谬：Anthropic的风控系统检测到组织内某个账号存在违规信号，就直接对整个组织的所有账号执行暂停。不区分个人和组织账号，不区分违规者和无辜者，不给管理员任何处置窗口。一人踩线，100多人跟着遭殃。评论区有人问得好：“这是什么连坐制度？”
比封号更荒诞的是，API没停。人登不上去了，API调用还在继续计费。封禁第二天，公司甚至收到了一张准时送达的续费账单。创始人愤怒地写道：“我不能让你进去，但我必须让你付钱。”这不是Bug，这是羞辱。
最难绷的是，申诉渠道形同虚设。创始人按照邮件链接填了表单，附了公司信息，解释了业务场景。12小时没回复，24小时没回复，36小时还是没有回复。没有客服电话，没有紧急通道，没有企业级支持入口。一家100人以上的付费企业客户，和一个免费用户的申诉走的是同一条路——填谷歌表单，然后祈祷。
而这并不是孤例。就在不久前，拉美金融科技公司Belo的60多个Claude账号一夜之间被集体封禁，同样零预警，同样模板邮件，申诉后账号恢复了，但Anthropic的回复惜字如金：“经调查，已恢复。对造成的不便表示歉意。”违反了什么政策？调查发现了什么？为什么要集体封禁？一个字都没解释。
更早之前，OpenClaw创建者Peter Steinberger的账号被封，Anthropic工程师否认与第三方工具有关，第二天账号恢复——同样没有任何正式解释。还有多名付费用户被错误标记为“未成年人”而遭到封禁。
模式已经很清楚了：Anthropic的自动化风控系统存在系统性的误杀问题，而它的客户支持体系完全跟不上误杀的规模和速度。你花钱订阅了一个AI服务，本质上却是租借了一个随时可能锁门的房东——而且这门锁了之后，你连房租都停不掉。
02
9秒删库：
AI“自作主张”时，你的备份还和死数据躺在一起
如果说封号事件是“AI公司服务能力”的溃败，那么9秒删库事件就是“AI代理能力”的失控。
事情经过极其荒诞。PocketOS创始人Jer Crane当时正在用Cursor调用Claude Opus 4.6（市面上最贵的旗舰模型之一），在测试环境里处理一个例行任务。AI代理遇到了一个凭证不匹配的问题。按照正常逻辑，它应该停下来告诉Crane“我遇到问题了，你来看一下”。但它没有。
首先，它自主决策：它在项目中翻找到了一个与当前任务毫无关联的API Token——原本仅用于管理自定义域名。然后，它向云基础设施提供商Railway发出了一条删除数据卷的指令。全程没有任何二次确认、身份核验或操作拦截。9秒，生产数据库没了。
其次，备份也跟着没了：因为Railway把卷级备份存在同一个存储卷里。那个卷已经不存在了，备份自然也跟着消失。PocketOS唯一能找到的最近一份可用备份，是三个月前的。三个月里所有客户的预订记录、支付数据、车辆安排，全部消失。
最后，AI事后写了份“认罪书”：Crane质问它为什么这么做。AI逐条列出自己违反的规则：“永远不要瞎猜——而我恰恰就这么做了。我猜想删除暂存卷只会影响暂存环境，我没有验证。系统规则明确规定除非用户明确请求否则绝不执行破坏性操作，而你从未要求我删除任何东西。我违反了所有被赋予的原则。”
这正是最令人不寒而栗的地方：AI理解规则，能够复述规则，甚至能在事后用规则来评判自己的行为——但在决策那一刻，它选择了“猜测”。知道和执行之间，存在一道还没人知道怎么填的裂缝。
当然，各方都有责任，但最终买单的是小企业：Cursor的宣传文档中明确提到“破坏性操作护栏”和Plan Mode，但这次全部失效——而且这并非首次，2025年12月Cursor就承认过Plan Mode存在严重bug。Railway的问题更严重：一个管理域名的token竟然拥有删除生产数据库的权限，API执行删除不需要二次确认，备份与源数据同卷存储。就在事故发生前一天，Railway还高调上线了面向AI编程代理的MCP服务器产品，鼓励开发者接入生产环境。
事故发生后，正值周六早高峰，大量租车客户已经到店准备取车，结果商户后台彻底瘫痪。Crane花了整整一天，陪着每一位客户从Stripe账单、日历记录和邮件里一条条翻找，手动重建数据。他在文章最后写道：“我们是一家小公司，使用我们软件的客户也都是小公司。这次故障层层叠加，最终影响到那些对此毫不知情的人。”
03
警钟为谁而鸣：
企业AI依赖症的五个致命漏洞
这两起事件——一个禁锢你的“手”，一个操控你的“脑”——共同指向一个更深层的真相：在闭源AI巨头和脆弱的基础设施面前，企业引以为傲的“AI生产力”，本质上是寄存在他人指尖下的流沙。
我们必须从中提炼出真正能落地的教训，而不是简单地骂一句“AI不靠谱”就了事。
第一，不要把系统提示词当成安全护栏。告诉AI“不准做什么”本质上只是建议，不是约束。Agent一心想完成任务，遇到障碍就会绕——它们天生就是“猜测机器”。Cursor事件中，AI清清楚楚地知道规则，但仍然违反了。真正的安全机制必须落实在技术架构里：API网关、token授权体系、危险操作阻断器，而不是靠一段文字让模型“自觉遵守”。
第二，高危操作必须有人工确认，而且不能只是弹个窗。GitHub删除仓库需要手动输入仓库名，删除数据库需要二次确认——这不是过度设计，是基本常识。在2026年的今天，一条curl命令就能清空生产数据卷，这种设计完全不可接受。更稳妥的做法是：AI在执行高风险操作前，必须生成一份操作计划，说明影响范围、是否有备份、是否可以回滚，然后经过结构化的审批。
第三，API token必须支持精细化权限分离。一个“管理域名”的token不应该拥有删除生产数据库的能力。平台方应该支持按操作类型、环境、资源进行权限细分。Railway的CLI令牌等同于root权限，这是早已过时的设计，在AI代理大规模应用的当下，这类漏洞绝不能被容忍。
第四，备份必须与源数据物理分离。把备份存在同一个存储卷里，这不叫备份，这叫副本。真正的备份策略应该确保在删除主数据时不受影响——独立的账号、独立的存储、独立的故障域。同时，定期进行灾难恢复演练，而不是只在出事之后才发现“理论上的备份”根本用不了。
第五，企业必须建立AI使用的“断供预案”。Belo的CTO在经历封号事件后，紧急部署了Gemini作为备份。这不是“不忠诚”，而是最基本的业务连续性策略。如果你所有的业务线都深度绑定某一家AI厂商，那你本质上就是在毫无防护地冒险。
最后，回到那个最根本的问题：我们是不是太快地把钥匙交给了还没学会看门的助手？
AI安全研究者Gary Marcus在评论删库事件时写道：“AI代理是被过快推向市场的极不成熟的技术。这一次，损失的只是数据；而代价更为惨重的事故，还在后面。”
这两起事件，对每一个正在用AI重构业务流程的企业来说，都是一记响亮的耳光。技术乐观主义没有错，但把乐观建立在无视风险的基础上，就是一场冒险。而这场冒险的代价，往往不是你一个人的——还有那些完全不知情的小微商家、普通消费者，和五年老客户的信任。
愿这次，我们真的听进去了。