Claude Code 提供了六种权限模式控制你对 AI 操作的审批粒度。选错模式要么被弹窗烦死要么不小心执行了不该执行的命令。本文逐一拆解每种模式能做什么、怎么工作、以及各自的坑。模式速览模式一句话读文件项目内写入Shell网络分类器调用default一切弹窗问你弹窗弹窗弹窗弹窗无acceptEdits文件操作自动批✅ 自动✅ 自动弹窗弹窗无autoAI 帮你看 Shell✅ 自动✅ 自动 AI 判 AI 判每次bypassPermissions大门拆了✅ 自动✅ 自动✅ 自动✅ 自动无dontAsk白名单放行其余拒绝✅ 放行✅ 放行❌ 拒绝❌ 拒绝无plan只能看不能动✅ 放行❌ 禁止❌ 禁止❌ 禁止无1. default —— 最安全最啰嗦表现每次工具调用都弹窗让你审批[Allow] [Deny] [Always allow]。你对 AI 的每一步有完全的掌控权。适用场景初次使用 Claude Code想看看它到底会做什么在生产环境操作不敢有丝毫闪失对 AI 还不信任的阶段优点零意外任何操作都要你点头建立肌肉记忆后你能逐渐了解哪些操作可以信任没有分类器开销没有额外 API 费用缺点极度打断心流写 10 行代码可能弹 15 次窗长时间工作后会「审批疲劳」→ 开始机械点 Allow → 安全意识麻痹不适合长时间无人值守的任务2. acceptEdits —— 日常开发甜点区表现文件读取、写入、编辑自动放行。Shell 命令和网络请求依然弹窗。内部机制它维护了一个「安全 Shell 命令白名单」——纯读操作ls、cat、git status、git log、grep、find等自动放行有副作用的命令仍然弹窗。changelog 显示这个白名单在持续扩充比如lsof、pgrep、tput、ss等都陆续被加入。适用场景日常写代码的主力模式本地开发项目跑在你自己机器上需要 AI 频繁读写文件但不想它随意执行命令优点文件操作零摩擦——写代码不再被打断Shell 层面仍有安全护栏没有额外 API 调用的延迟和费用可以通过permissions.allow按需放行特定命令如Bash(npm test)缺点频繁跑测试、装依赖、启动服务 → 还是会被弹窗轰炸只信任「当前工作目录」内的文件操作——出了这个范围照弹不误白名单之外的安全命令如某些自定义工具每次都要批3. auto —— AI 当保安表现文件操作自动放行。Shell 命令和网络请求交给一个AI 分类器判断安全就放行危险就拦截。内部机制这是六种模式里最复杂的值得展开讲决策管道四层操作请求 ├─ ① 内置白名单 用户 allow 规则 → 直接放行 ├─ ② 项目内文件 Write/Edit → 直接放行不经过分类器省延迟 └─ ③ Transcript ClassifierAI 分类器→ 判断放行还是拦截分类器的两阶段评估阶段做什么性能Stage 1 — 快速过滤单 token yes/no偏保守大部分操作直接过Stage 2 — 深度推理仅 Stage 1 拦截时触发完整推理重判误杀率从 8.5% 降到 0.4%分类器的四级拦截体系优先级规则说明1hard_deny无条件阻止用户意图也不能覆盖2soft_deny默认阻止但用户可以覆盖3allow对 soft_deny 的例外4用户明确意图用户消息中精确描述了该操作 → 覆盖 soft_deny关键安全设计分类器是独立模型Claude Sonnet 4.6跟你的主会话模型无关分类器看不到工具执行结果——只看到用户消息 工具名/参数。恶意文件内容无法操控它还有一个输入层 probe在工具输出进入上下文之前扫描 prompt injection降级保护连续 3 次拦截 → 暂停 auto mode回退到手动审批累计 20 次拦截 → 同上非交互模式claude -p→ 直接中止会话适用场景长时间无人值守的编码任务比如「把这个 PR review 完并修好所有问题」信任 AI 的判断但不想完全裸奔有autoMode.environment配置了信任边界的团队项目优点Shell/网络操作也能自动处理真正解放双手有安全护栏不是无脑放行自定义规则灵活可以写autoMode.allow/soft_deny/hard_deny拦截后有审计记录可在/permissions查看缺点每次 Shell/网络操作增加 API 调用的延迟分类器要跑一次推理额外 token 费用分类器调用也算钱虽然 Stage 2 基本命中缓存分类器不是 100% 准确——实测有 0.4% 误杀 17% 漏过项目内文件写入绕过分类器Tier 2 盲区——恶意文件内容不会被拦截需要 Anthropic API 的 Sonnet 4.6——第三方端点Bedrock/Vertex/DeepSeek 等可能不可用比 bypassPermissions 慢比 acceptEdits 贵4. bypassPermissions —— 全自动零护栏表现一切操作自动放行。不弹窗不走分类器什么都不问。内部机制权限检查在入口处直接短路返回 允许。相当于你永久按住了[Always allow]按钮。适用场景完全隔离的沙箱/容器环境炸了也无所谓你自己写的个人玩具项目确定不会执行任何危险操作的场景优点零摩擦AI 可以火力全开无额外延迟无额外费用适合长任务全自动运行缺点没有任何安全网——AI 执行rm -rf /你连提示都看不到AI 可能被 prompt injection 操控执行恶意命令代码 review 是你唯一的防线事后检查 git diff误操作成本极高5. dontAsk —— 静默拒绝表现allow 列表里的放行不在列表里的直接拒绝不弹窗问你。内部机制类似default但把「未匹配」的默认行为从弹窗改成了拒绝。适用场景只想让 AI 用一组预定义的安全工具比如只读探索代码给 AI 的能力做极窄的约束CI/CD 场景不能有交互弹窗优点行为完全可预测——AI 只能做你白名单里的事零弹窗适合非交互环境安全性最高仅次于 plan缺点白名单之外的操作直接失败AI 无法向你求助容易出现「我想帮你做 X 但我没有权限」的死循环白名单维护成本高——忘加一个常用命令就卡住6. plan —— 只读最严格表现只能读不能写。允许 Read、Glob、Grep、WebSearch 等只读操作禁止一切修改和命令执行。内部机制跟其他模式不同plan 不是简单的权限过滤它还会改变系统 prompt——告诉模型「你现在在 plan mode不能执行修改操作」。适用场景设计方案阶段的探索审查陌生代码库让 AI 帮你分析问题但不能动手改优点完全不会改你的代码零风险AI 知道自己被限制了会调整回答策略适合用来「先看看 AI 会怎么想」再做决定缺点AI 无法执行任何验证操作不能跑测试、不能试运行分析结论可能基于「猜测」而非「实测」如果确实需要改代码得退出 plan mode 重新来决策指南我该用哪个你在干什么 │ ├─ 初次使用 / 在生产环境 / 对 AI 不信任 │ └─ default │ ├─ 日常写代码需要 AI 改文件但要审批命令 │ └─ acceptEdits permissions.allow 放行常用命令 │ ├─ 长时间无人值守任务信任 AI 但想有安全网 │ └─ auto前提你的 API 端点支持 Sonnet 4.6 │ ├─ 隔离沙箱 / 个人玩具项目 / 确定安全 │ └─ bypassPermissions │ ├─ 只让 AI 做预定义操作非交互环境 │ └─ dontAsk │ └─ 设计方案 / 审查代码 / 只看不改 └─ plan进阶组合使用你不是只能选一种模式。Claude Code 支持多层配置叠加{ permissions: { defaultMode: acceptEdits, allow: [ Bash(npm test), Bash(npm run build), Bash(git diff *), Bash(git log *) ], deny: [ Bash(rm -rf *), Bash(git push --force *) ] } }这样你的实际体验是文件读写自动放行acceptEditsnpm test、git log等自动放行allow 规则rm -rf、git push --force直接拒绝deny 规则其他命令弹窗问你常用 allow 规则建议放到acceptEdits模式下allow: [ Bash(npm *), Bash(npx *), Bash(python *), Bash(git status), Bash(git diff *), Bash(git log *), Bash(git branch *), Bash(grep *), Bash(find *) ]总结你关心什么推荐模式绝对安全plan或default日常效率acceptEdits效率 AI 安全网auto极致效率沙箱内bypassPermissions非交互/受限环境dontAsk没有「最好」的模式只有适合你当前场景的组合。大多数日常开发用acceptEdits 精心维护的 allow 列表就足够了——既不会被打断到崩溃也不会裸奔失控。