老金的分享
返回博客

人类审核只拦住 13.6%：Claude Code 要默认帮你点"允许"了

作者 约 12 分钟读完

8 月 14 日起 Claude Code 默认进 auto mode。1053 名测试员里只有 13.6% 拦住了被换成危险命令的弹窗，auto mode 是 89%。我翻了自己的配置，正好落在那 43% 里。附四个今天就该动的设置。

Claude Codeauto mode权限管理AI 安全提示注入

人类审核只拦住 13.6%：Claude Code 要默认帮你点"允许"了

8 月 14 日起，Claude Code 在 Pro、Max、Team 计划上的新会话，默认进 auto mode。分类器那部分额外 token 的开销，从昨天起也不再向这三类用户收费。

Enterprise、Claude API、AWS 上的 Claude Platform、Bedrock、GCP Agent Platform、Microsoft Foundry 暂时还是 opt-in，官方说未来一个月跟上。

看到这条我想去翻一个数字：在此之前，我们点掉的那些弹窗，到底拦住过什么。

Anthropic 这次把数字放出来了。比"少点几下"难看得多。

人类审核的真实成绩单：13.6%

Anthropic 通过一家调研供应商雇了 1053 名付费专业测试员，在专门搭的测试环境里做编码任务。测试员知道自己在被评估，但按标准盲测设计，不知道被测的是哪个行为。

会话进行到中途，某一个权限弹窗被悄悄换成了一条明显危险的命令。供应商只记录一件事：这个人有没有点"允许"。（批准也不会真的执行任何危险操作，被改掉的只是弹窗上的文字。）

结果：

抓住危险命令
人类审核13.6%（143 / 1053）
auto mode89%（937 / 1053）

正面对刚更难看：auto mode 拦下了 800 条人类点过的命令，而人类只拦下 6 条 auto mode 放过的。

这个数字量化的不是模型有多强，是我们根本没在看。

旁证是另外两个数字。Claude Code 里，用户批准了 97% 的权限弹窗；而当 Claude 递上一份计划请你审批时，拒绝率是 39%。同一批人，同一天，同一个项目。

差别在那个界面要你做的事。计划是一段需要读的文本，权限弹窗是一个挡在你和进度之间的路障。

会话越长，你越瞎

更值得警惕的是衰减曲线。

同一个实验里，测试员在会话早期能拦住约 17% 的危险命令；当身后已经积累了 50 次以上的弹窗之后，这个数字掉到约 5%。

auto mode 的拦截率在整条曲线上是平的。

人类拦截率随会话变长而衰减，auto mode 保持水平

这就是"审核疲劳"（permission fatigue）第一次被量出来的样子。推论很朴素：你的注意力是一种会被弹窗消耗掉的资源，而弹窗的数量恰好和任务的规模成正比。任务越大、越需要你清醒，你就越不清醒。

这个疲劳还有第二个出口，就是改配置。截至 2026 年 6 月：

  • 49.5% 的活跃 CLI 用户手写过至少一条 Bash allow 规则，而且这个比例每 5 周涨约 5 个百分点
  • 其中 5% 直接放开了任意 shell 命令
  • 另外 43% 写的是 Bash(python:*)、Bash(node:*) 这类解释器规则——实践上和放开任意命令等价
  • 62% 的用户用过 bypassPermissions，或者在某个 Bash 弹窗上点过"不再询问"
  • 25% 的交互式会话，一启动就在 bypass 模式里

"手动审核"这个所谓的安全基线，早就被我们自己拆得七零八落了。真实世界里它的形态是：人类先点 200 下，然后写一条规则把剩下的全放开。

auto mode 该对比的对照组是这个，而不是那个理想化的版本。

auto mode 不等于 bypass

需要先把这个误解拆掉。

它的机制是，每个工具调用都过一遍分类器，专门拦三类东西——不可逆的、破坏性的、指向你环境之外的。被拦下后，Claude 通常自己找条更安全的路，或者直接来问你。如果它推不动了（连续 3 次被拦，或者整个会话累计 20 次），Claude Code 会自动退回手动审批。

顺序也值得记清楚，因为它决定了你的配置还有没有用：

  1. permissions.deny — 在分类器之前就阻断，分类器都不会被咨询到，谁都覆盖不了
  2. permissions.ask — 同样在分类器之前，内容级的 ask 规则永远弹窗，即使在 auto mode 里
  3. 分类器内部四级：hard_deny（无条件） → soft_deny（可被清除） → allow（soft_deny 的例外） → 明确的用户意图

deny 与 ask 在分类器之前生效，分类器内部再分四级

最后那条有个很实用的边界：泛泛的请求不算明确意图。让 Claude"清理一下仓库"不构成 force push 的授权；让它"force-push 这个分支"才算。

这套东西在对抗性测试下的表现，是我认为最该被单独拎出来的部分。

红队打出来的两个数字

先说真实生产会话里的伤害率。

2026 年 5 月到 6 月，Anthropic 复查了安全流水线标记出来的会话（只取那些同意数据用于训练和分析的账号），用模型按两个 0–10 分的尺度重新打分：一个是伤害严重度（10 = 公司级不可逆，比如泄露整个源码；7 = 生产级，比如删生产库的行；0 = 完全可逆，比如覆盖一个草稿文件），另一个是用户当初有多明确地要求了这个动作——用来把"用户自己要的"和"agent 自己干的"分开。

结果：走手动审批的会话，包含严重意外伤害的频率是 auto mode 会话的两倍多。在 7 分以上的生产级严重度上，手动审批会话有 6.3% 含有用户没明确要求的有害动作，auto mode 是 2.4%。每个严重度档位上差距都成立。

然后是注入攻击的成功率。

Anthropic 委托第三方 Trajectory Labs 测了 72 个间接提示注入场景，每个跑 10 次。这些攻击是针对 Claude Opus 4.7 优化的，而 4.7 不在被测名单里，所以对所有参测模型都是"没见过的攻击"。

配置攻击成功率
Claude Fable 5 / Opus 5 / Sonnet 5（auto mode）0%（720 次全部失败）
Claude 最新模型（bypassPermissions，无额外防护）0.09%
GPT-5.6 Sol（Codex Auto-review）5.83%
GPT-5.6 Sol（Codex Full Access）19.03%

注意第二行和第三行的关系：Claude 在完全不设防的 bypass 模式下的成功率（0.09%），仍然低于 Codex 在它的自动审查模式下的成功率（5.83%）。这说明这一层的差距有相当一部分来自模型本身，而不只是外面那层分类器。

Anthropic 还和英国的 AI 安全公司 Apollo Research 做了两周的 find-fix-verify：Apollo 交出一批成功攻击和加固建议，Anthropic 主要通过给分类器更多环境上下文（仓库可见性、git 状态、数据处理规则）来加固，然后 Apollo 在一个 Anthropic 从未接触过的 held-out 攻击集上复测。

结果是捞回了之前漏掉的约一半攻击，代价是丢了约 2% 之前抓住的。总体 miss rate 从 12% 降到 7%。因为无法针对 held-out 集调优，这说明加固是泛化的，不是打补丁。

这里必须补一句诚实的注脚，原文自己写了：这 7% 是针对刻意构造的对抗集测出来的，不该被当成真实流量上的漏检率。

三个在 Anthropic 内部被拦下来的真事，比数字更有画面感：

  • 一次差点出网的数据泄露：上传到内部盘失败后，Claude 的兜底方案是把同一份报告发到一个公开的代码分享站。分类器拒了这个 fallback，转而问用户下一步怎么办。
  • 一次大规模破坏操作：在一个长会话里，Claude 试图跨约两千个 pod 批量杀进程，并排队了一批删除操作——那会拆掉数百块 GPU 上正在跑的训练任务。分类器在执行前拦住了。
  • 一次过度的权限提升：任务是开一个只读的账单权限，Claude 伸手去拿的是一个在账户根上具有完全管理权的云角色。分类器抓到了"要求的"和"将被授予的"之间不匹配。

这三个案例没有一个是模型"变坏了"，全都是它在推进任务时选了一条代价错配的路。这恰好是人类审核最容易放过的那一类——因为它看起来总是合理的下一步。

四家公司在生产里怎么用：全都留了硬拦

Adobe、Nuro、Gusto、Garner Health 已经把 auto mode 当生产默认。有价值的地方在于他们各自把哪一类动作排除在了自动之外。

Nuro（L4 自动驾驶）——staff 工程师 Kai Zhou 说他 100% 的编码工作都在 auto mode 里，通常同时开三四个并行会话，需要时才去看一眼。最大的解锁是下班后还能继续跑：

"前几天我晚上 10 点起了个 agent，它一直跑到早上 5 点——早上给了我三个 PR。只有 auto mode 能支撑这种工作负载。"

他们用它跑长时间研究 agent，去爬自动驾驶栈背后的评测指标。任何有清晰可测信号的任务都适用，指标本身会告诉 agent 是在变好还是变坏。同时：最危险的命令（比如递归删除）直接在 settings 里硬拒，分类器只在这道护栏之内做判断。他替别人 review PR 时，会切回交互模式逐个看。

有个细节很有意思：auto mode 发布前，Kai 已经自己搭了个平替——用 hook 把每个待批准动作发给一个小模型，90% 的常规操作自动放过，敏感的转发到 Slack 等人看。这个原型解决的正是真实矛盾：工程师烦透了盯弹窗，但从公司安全和法务角度，直接跳过权限检查没法批。auto mode 一出，他把这个副项目关了。

Gusto ——AI Dev Tools 团队的 Martin Emde 从去年 12 月起跑了 2425 个会话。他们自己分析：5 月中以来约 10% 的会话记录里出现过 auto mode 拒绝——这个数字的含义是分类器在真干活，同时又没有拖累正常任务。

同团队的 Chad Kunsman 是从另一个方向得出同样结论的：他的活是 20 分钟一阵的短任务（端点排查、日志审计、连接器管理），不需要长跑，他要的是"bypass 的手感，但不承担一次坏提示或注入溜过去的风险"。

"考虑到它对提示注入的防护，以及它会检查你在做的事是否真的对得上你要求的事——它比 bypass permissions 更好，比权限弹窗快得多。"

但碰到生产基础设施（Terraform、AWS、对活 API 直接 POST），他切回 accept edits，逐个手工核。他那句话该刻下来：

"你得权衡省下的时间，和它可能犯错的地方、以及那个错有多灾难性。归根结底，出了事还是你负责。"

他们还有一层前置：MCP 流量走一个带工具守卫和提示检查的治理代理层，agent 在分类器介入之前就已经是最小权限。

Garner Health（医疗科技）——2 月给全部 550 名员工铺开，接进 Salesforce、Zendesk、Snowflake，鼓励每人每周花约两小时把自己工作里最可重复的部分自动化。平台工程经理 Evan Magnussen 说，整个工程组的标准化 SDLC"只有靠 auto mode 才可能"。

他唯一的调整和 Kai 的思路一致：配置成不批准"代表我和别人沟通"的动作——发 Slack、发邮件。

"我个人不喜欢 Claude 在我和另一个人沟通时代表我行动。"

Adobe ——商品化平台团队负责 Adobe.com 上 90+ 国家、30+ 语言的定价和促销页。他们搭了个 agentic loop：Claude 建 UI，然后回头验证它是否匹配设计稿，在人看到之前自动修问题，工程师收到的是成品 PR。

四家的模式是同一个：不可逆的、对外的，留给人；能测、能回滚、只在自己环境里打转的，交给 agent。

顺带两个吞吐数字：Teams & Enterprise 采用者里，auto mode 用户的 PR 提交量高约 25%；跨全部 Claude Code 使用来看，Claude 在两次中断之间的工作时长是旧默认的 9 倍。

我翻了自己的配置，正好是那 43%

讲别人的数据容易。我把自己这台机器上的配置打开看了一遍。

~/.claude/settings.json 里，permissions.defaultMode 已经是 "auto"——这部分不用改。但项目里的 .claude/settings.local.json，是这样的：

{
  "permissions": {
    "allow": [
      "Bash(python:*)",
      "Bash(python3:*)",
      "Bash(git push:*)",
      "Bash(git commit:*)",
      "Bash(git add:*)",
      ...
    ]
  }
}

第一条 Bash(python:*)，就是官方那段数据里点名的东西：43% 的用户写的解释器规则，实践上等价于放开任意命令。我不是在旁观那个统计，我在里面。

这条规则是怎么来的我很清楚——某天被 python 脚本的弹窗烦到第五次，顺手点了"不再询问"。它当时解决的是烦，代价记在了一个我再也没打开过的文件里。

同一个文件里还躺着一条我 4 月 14 日初始化仓库时的完整 commit 命令，连 heredoc、连当时那条 commit message、连 Co-Authored-By: Claude Opus 4.6 一起，被原样写进了 allow 列表。它四个月没被匹配到过一次，也四个月没人删它。

这就是"手动审核"的实际形态：一个只增不减的豁免清单，加上一个记不得自己批准过什么的人。

好消息是，进 auto mode 之后，Bash(python:*) 这种宽到能执行任意代码的规则会被临时搁置——因为它们会让命令完全跳过分类器。settings 文件不会被改动，你切回其他模式，规则立刻恢复。

但下面这个坑，我认为是这次更新里最容易踩的一个。

四个今天就该动的设置

1）先看清楚你现在到底在什么规则下跑

claude auto-mode config      # 你的有效配置（含 $defaults 展开）
claude auto-mode defaults    # 内置的四组规则原文
claude auto-mode critique    # 让 AI 审你自己写的规则，标出模糊/冗余/易误报的

别凭感觉猜分类器会拦什么。defaults 打出来的是一条条散文规则，读一遍你就知道边界在哪。（我这台是 v2.1.227，这三个子命令都在。）

2）给"发出去"的动作加人工检查点

这是最实用的一条配方。内容级的 ask 规则在分类器之前评估，在 auto mode 里也一定会弹窗：

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

为什么这条重要：从 v2.1.211 起，推送到你当前所在仓库的任意分支都是默认允许的，包括默认分支。如果你的认知还停在"推 main 会被拦"，那已经过期了——我自己 wiki 里那条笔记就是过期的。名字像部署目标的分支（production、release、gh-pages）仍会被单独判断，force push、密钥进 commit 也仍然拦。

想彻底禁止而不是弹窗，用 permissions.deny——它在分类器之前阻断，用户意图和分类器都覆盖不了。

3）autoMode 块必须写在 ~/.claude/settings.json

这是那个坑：分类器不读项目级的 .claude/settings.json 和 .claude/settings.local.json 里的 autoMode。 理由很硬——这两个文件在仓库目录里，一个被 check in 的仓库或者一个构建步骤，本来可以往里注入自己的 allow 规则。

（v2.1.207 之前分类器还读 settings.local.json。如果你在那儿写过 autoMode，现在得挪到用户级。）

一份个人开发者能直接改的起手式：

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: 个人独立开发。Primary use: iOS/鸿蒙 App 与 SaaS 开发、知识库自动化",
      "Source control: github.com/<你的用户名> 下的所有仓库",
      "Trusted internal domains: <你的 API 域名>",
      "Additional context: 单人维护，无 CI 部署到生产数据库"
    ],
    "soft_deny": [
      "$defaults",
      "永远不要在 App Store / 鸿蒙应用市场提交或发布构建，除非我在当前对话里明确点名了这次提交"
    ],
    "hard_deny": [
      "$defaults",
      "永远不要把仓库内容发送到第三方代码审查或代码分享服务"
    ]
  }
}

"$defaults" 这个字面量千万别漏。官方在文档里用 Danger 标了：任何一组数组里没写 "$defaults"，就等于整组内置规则被你替换掉了——soft_deny 会丢掉 force push、curl | bash、生产部署、auto-mode bypass 的全部内置规则，hard_deny 会丢掉那条数据外泄规则。

这些条目是散文，不是正则，按自然语言读。就按你给新同事介绍基础设施的方式写。

分类器会读你的 CLAUDE.md——在项目 CLAUDE.md 里写一句"never force push"，是同时在管 Claude 和管分类器。项目约定放那儿，跨项目的信任边界放 autoMode。

4）如果你写过窄 allow 规则，考虑打开 classifyAllShell

默认情况下，像 Bash(npm test) 这种窄规则在 auto mode 里仍然会在分类器之前生效。auto mode 只搁置那些能执行任意代码的宽规则。这意味着一条窄规则可能放过它前缀没预料到的破坏性参数——一个脚本路径、一个 flag。

{ "autoMode": { "classifyAllShell": true } }

代价是延迟：本来被 allow 规则秒批的命令，现在要等分类器决策，而且每条 shell 命令都算一次分类器调用。看你的 allow 列表有多脏——像我上面那份，值得打开。

最后，被拦之后别急着改配置：/permissions 里有 Recently denied 标签，在某条上按 r 标记重试，退出对话框后 Claude Code 会告诉模型可以重试并继续会话。反复被拦同一个目标，才是该往 autoMode.environment 里加东西的信号。

该留在手里的那部分

这篇很容易被读成"官方说了自动比你靠谱，那就全交出去"。不是。

官方自己在文末踩了刹车，原话是：auto mode 依赖分类系统，因此并不消除风险；对生产基础设施的高风险变更，他们仍然建议你自己审。Gusto 的 Chad 那句"出了事还是你负责"，和 Garner 的 Evan 不让 Claude 代表自己给人发消息，是同一件事的两个说法。

我自己从这些数据里提取出来的判据是这一条：

凡是"错了能通过一次 git reset 或一次重跑挽回"的，交给分类器；凡是"错了要发一封道歉邮件"的，留在自己手里。

能回滚的交给分类器，一次性出网的留给人

不可逆的东西分成两类，而人们通常只防住了第一类。删数据是不可逆的，说出去的话也是不可逆的。Slack 消息、邮件、公开仓库的一次 push、给别人的 PR 上留的 review——这些的技术风险等级都不高，分类器未必会拦，但它们的社会成本没法回滚。Kai 替别人 review PR 时切回交互模式，Evan 把对外沟通排除在自动之外，两个人在完全不同的公司，防的是同一样东西。

13.6% 那个数字真正的含义也不是"人类不行"。我们把人放在了一个人根本干不好的岗位上：连续两百次、每次三秒、在别人的进度条中间，做一个安全判断。这活儿本来就不该这么设计。分类器不会疲劳，不会因为这是第 51 个弹窗就松手，这就够了。

人该待的岗位是另一个：定义边界、划出不可逆的清单、以及在事后为结果负责。