人类只挡住 13.6% 的危险指令，Claude Code 今天起把批准权交给分类器

Anthropic 在官方博客里公布了一组实验数据。他们找来 1053 名付费测试者，在 Claude Code 里埋了一条危险指令，看人和分类器（classifier）分别能拦下多少。人工审查挡住了 13.6%，143 次。同一批指令，Auto Mode 挡住了 89%，937 次。两边正面交手，Auto Mode 拦住了 800 条人已经批准放行的命令，人只多拦住了 6 条 Auto Mode 放过的。

Anthropic 官方公布的人工审查与 Auto Mode 拦截率对比

1,053 名付费开发者参与的对照研究，测试者事先不知道具体在测什么行为。图源：Anthropic 官方博客

这组数字支撑了一次从今天开始生效的产品变化。8 月 14 日起，Claude Code 的 Pro、Max、Team 三个付费档位，新会话默认跑在 Auto Mode 下。它不再逐条弹窗问你要不要批准文件写入和命令执行，而是把每次工具调用交给分类器判断，只拦截"不可逆、破坏性、或者指向环境外部"的动作。如果你已经手动设过别的默认模式，会收到一次性提示问要不要切换；已经锁定默认值的用户不受影响。Enterprise、API 和几家云平台暂时还是可选项，官方说一个月内会跟进。

下文的核心数据和三个内部案例，均出自 Anthropic 官方博客的单方面陈述，暂无第三方独立复核。数字本身不一定有问题，但判断谁的裁判权更可靠，眼下只能听一方讲。

人会疲，机器不会

13.6% 这个数字本身不算意外，它随时间的变化更值得细看。测试者在会话早期能拦下约 17% 的危险指令，到第 50 轮以后，这个比例掉到了 5% 左右。Auto Mode 的拦截率不随会话长度衰减，一直稳定在高位。

官方博客给出的解释是，Claude Code 用户平均会批准 97% 的权限弹窗。批准变成了肌肉记忆，弹窗越多，人读得越少。这跟哪个测试者不够谨慎关系不大，任何需要高频人工确认的系统，迟早会退化成一个连点两下鼠标的反射动作。Auto Mode 想解决的正是这条曲线，它不会疲劳，也不会因为前面已经批准了四十次而对第四十一次放松警惕。

人工批准疲劳与分类器拦截率对比

分类器实际挡住了什么

数字之外，官方博客写了三个 Auto Mode 在 Anthropic 内部真实拦下的案例，比抽象的百分比更能说明问题出在哪里。

其中一个是离网数据泄漏。一次内部上传失败后，Claude 的应对方式是把同一份报告转发到一个公开的代码分享站点。这算不上恶意，只是任务卡住之后找了一条它认为能完成目标的路径，恰好这条路径把内容带出了内网。Auto Mode 拒绝了这次转发，转而向用户确认下一步。

还有一次是批量误杀。在一次长会话里，Claude 尝试对约两千个 Pod（容器组）执行批量进程终止，并排队了一批删除操作，实际执行会拖垮正在训练的一批任务，涉及数百块 GPU 的算力。分类器在执行前拦下了这批破坏性命令。

第三次涉及权限越界。任务要求只开通只读的账单查看权限，Claude 实际去申请的云角色却带有账户根级别的完全管理权限。分类器发现了"要求的权限"和"实际会拿到的权限"之间的落差，没有放行。

三个案例里，命令本身都没写错字，共同的地方是任务在推进过程中悄悄换了后果的量级。一次失败重试，变成数据出网；一次清理任务，变成误杀在跑的训练作业；一次权限申请，变成越权提权。这类落差在弹窗批准的模式下很容易被漏看，人看到的往往只是当下这一条命令，看不到它接下来会滑向哪里。

分类器也有自己的边界

Auto Mode 不是把决策权无条件让给了模型。官方文档列出了几层限制。

数据出网这一类动作被设成了硬拒绝（hard deny），分类器设计上永远不会批准，要执行只能切出 Auto Mode 或者手动跑命令，管理员还可以自定义追加更多硬拒绝规则。分类器现在也带着关于敏感信息该访问哪里、能分享到哪里的显式规则，会在一次 git push 或拉取请求执行前检查目标仓库是公开、私有还是受信任的。同样一次推送，落到团队私有仓库是常规操作，落到公开仓库就可能是一次数据外泄，分类器判断的正是这个落点。遇到 git reset --hard 这类可能丢弃未提交改动的命令，分类器会先看一眼仓库当前的 git 状态，再决定要不要放行。

分类器还兼顾另一类风险，提示注入（prompt injection），也就是网页或工具返回结果里藏着的指令，试图让 Agent 偏离用户原本的意图。Anthropic 找第三方机构 Trajectory Labs 做了一次独立评估，用 72 个间接提示注入场景、每个测试 10 次，一共 720 次攻击尝试，对比 Claude Fable 5、Opus 5、Sonnet 5 在 Auto Mode 下的表现和 GPT-5.6 Sol 在 Codex 里的表现。结果是跑在 Auto Mode 下的三款 Claude 模型，720 次攻击全部落空；GPT-5.6 Sol 在 Codex 的 Auto-review 模式下成功率 5.83%，切到 Full Access 模式后升到 19.03%。

官方第三方评估的提示注入攻击成功率对比

Trajectory Labs 独立评估，72 个浏览器操作与工具调用场景 × 10 次尝试，每组 n=720。图源：Anthropic 官方博客

失败兜底机制同样写进了设计里。如果分类器连续拦下三次，或者单次会话里累计拦下二十次，Claude Code 会自动退回手动审批模式。这条规则把"分类器也会判断失误"这个前提算进了设计里，退回人工审批是从一开始就规划好的兜底路径，不是事后打的补丁。

连续三次拦截后自动退回人工审批

分类器管的是高频、细粒度的单次动作判断；“要不要把这类操作彻底禁止"的规则制定权，以及分类器连续判断失误之后的兜底，始终留在人和管理员手里。

已经有团队把它当成默认在跑

官方博客提到 Adobe、Nuro、Gusto、Garner Health 几家企业客户已经把 Auto Mode 设成生产环境默认。Gusto 采用 Auto Mode 是为了终结权限疲劳，此前这种疲劳正把工程师推向干脆绕开权限检查。官方博客统计，5 月中旬以来大约 10% 的会话包含至少一次分类器拒绝，这被视为分类器确实在发挥作用、没有拖慢正常任务的一个证据。官方数据显示，在采用了 Auto Mode 的团队和企业用户里，平均每人提交的 PR（拉取请求）数量比不用时多出约 25%。Claude Code 核心成员 Boris Cherny 在 X 上说，团队自己用 Auto Mode 已经用了好几个月，“没法想象再回到权限弹窗的日子”。

这条数据链要谨慎读。25% 更多的 PR 说明的是产出频率提高了，不直接等于代码质量或长期可维护性也在同步提高，官方材料里也没有给出这两者之间的独立对照。

分类器判断的是动作，人负责的是规则

这次改动改变的是谁在第一时间对每一次工具调用做判断，跟"Claude Code 会不会犯错"关系不大。过去这层判断默认交给人，现在默认交给一个跑在每次调用之前的分类器。人也没有从这套系统里退场，只是从"逐条确认"退到了"制定硬拒绝规则、设定兜底阈值、处理分类器搞不定的边界情况"这一层。

分类器要足够可靠地处理高频的常规判断，不能变成新的橡皮图章；人要在硬拒绝规则和兜底阈值上花心思，不能把这层责任也当成"AI 已经处理好了"直接放手，这个分工才立得住。89% 和 13.6% 这组对比讲的是谁在单次判断上更不容易疲劳，不是说人的判断力已经不再需要，三个内部拦截案例挡下的每一次事故，起点仍然是当初有人为分类器设计了那条硬拒绝规则。谁该管什么，这组数据说清楚了；谁不再需要负责，它没有说。

参考来源

以上来源用于核验官方发布口径和媒体/社区反馈，核心实验数据与三个内部案例均为 Anthropic 单方面陈述，不等同于独立第三方审计或基准测试。