# 人类审核只拦住 13.6%：Claude Code 要默认帮你点"允许"了 > 8 月 14 日起 Claude Code 默认进 auto mode。1053 名测试员里只有 13.6% 拦住了被换成危险命令的弹窗，auto mode 是 89%。我翻了自己的配置，正好落在那 43% 里。附四个今天就该动的设置。 - 原文链接: https://laojin.blog/blog/20260811_auto_mode_default - 作者: 老金 - 发布日期: 2026-08-11 - 标签: Claude Code, auto mode, 权限管理, AI 安全, 提示注入 --- ![人类审核只拦住 13.6%：Claude Code 要默认帮你点"允许"了](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260811/00_cover.png) 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 mode | 89%（937 / 1053） | 正面对刚更难看：auto mode 拦下了 800 条人类点过的命令，而人类只拦下 6 条 auto mode 放过的。 这个数字量化的不是模型有多强，是我们根本没在看。 旁证是另外两个数字。Claude Code 里，用户批准了 97% 的权限弹窗；而当 Claude 递上一份计划请你审批时，拒绝率是 39%。同一批人，同一天，同一个项目。 差别在那个界面要你做的事。计划是一段需要读的文本，权限弹窗是一个挡在你和进度之间的路障。 --- ## 会话越长，你越瞎 更值得警惕的是衰减曲线。 同一个实验里，测试员在会话早期能拦住约 17% 的危险命令；当身后已经积累了 50 次以上的弹窗之后，这个数字掉到约 5%。 auto mode 的拦截率在整条曲线上是平的。 ![人类拦截率随会话变长而衰减，auto mode 保持水平](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260811/01_fatigue_curve.png) 这就是"审核疲劳"（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 在分类器之前生效，分类器内部再分四级](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260811/02_gate_order.png) 最后那条有个很实用的边界：泛泛的请求不算明确意图。让 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`，是这样的： ```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）先看清楚你现在到底在什么规则下跑 ```bash claude auto-mode config # 你的有效配置（含 $defaults 展开） claude auto-mode defaults # 内置的四组规则原文 claude auto-mode critique # 让 AI 审你自己写的规则，标出模糊/冗余/易误报的 ``` 别凭感觉猜分类器会拦什么。`defaults` 打出来的是一条条散文规则，读一遍你就知道边界在哪。（我这台是 v2.1.227，这三个子命令都在。） ### 2）给"发出去"的动作加人工检查点 这是最实用的一条配方。内容级的 `ask` 规则在分类器之前评估，在 auto mode 里也一定会弹窗： ```json { "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`，现在得挪到用户级。） 一份个人开发者能直接改的起手式： ```json { "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。 ```json { "autoMode": { "classifyAllShell": true } } ``` 代价是延迟：本来被 allow 规则秒批的命令，现在要等分类器决策，而且每条 shell 命令都算一次分类器调用。看你的 allow 列表有多脏——像我上面那份，值得打开。 最后，被拦之后别急着改配置：`/permissions` 里有 Recently denied 标签，在某条上按 `r` 标记重试，退出对话框后 Claude Code 会告诉模型可以重试并继续会话。反复被拦同一个目标，才是该往 `autoMode.environment` 里加东西的信号。 --- ## 该留在手里的那部分 这篇很容易被读成"官方说了自动比你靠谱，那就全交出去"。不是。 官方自己在文末踩了刹车，原话是：auto mode 依赖分类系统，因此并不消除风险；对生产基础设施的高风险变更，他们仍然建议你自己审。Gusto 的 Chad 那句"出了事还是你负责"，和 Garner 的 Evan 不让 Claude 代表自己给人发消息，是同一件事的两个说法。 我自己从这些数据里提取出来的判据是这一条： > **凡是"错了能通过一次 git reset 或一次重跑挽回"的，交给分类器；凡是"错了要发一封道歉邮件"的，留在自己手里。** ![能回滚的交给分类器，一次性出网的留给人](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260811/03_reversible_boundary.png) 不可逆的东西分成两类，而人们通常只防住了第一类。删数据是不可逆的，说出去的话也是不可逆的。Slack 消息、邮件、公开仓库的一次 push、给别人的 PR 上留的 review——这些的技术风险等级都不高，分类器未必会拦，但它们的社会成本没法回滚。Kai 替别人 review PR 时切回交互模式，Evan 把对外沟通排除在自动之外，两个人在完全不同的公司，防的是同一样东西。 13.6% 那个数字真正的含义也不是"人类不行"。我们把人放在了一个人根本干不好的岗位上：连续两百次、每次三秒、在别人的进度条中间，做一个安全判断。这活儿本来就不该这么设计。分类器不会疲劳，不会因为这是第 51 个弹窗就松手，这就够了。 人该待的岗位是另一个：定义边界、划出不可逆的清单、以及在事后为结果负责。