Claude Code 的权限模式——default、plan、acceptEdits 什么时候用

Claude Code 的权限模式------default、plan、acceptEdits 什么时候用

系列：AI 工具实战专栏｜字数：约 2800 字｜预计阅读：7 分钟

用 Claude Code 的前两周，我没意识到有"模式"这回事。

打开终端，输入需求，它干活。有时候很顺------改文件、跑测试、一键提交。有时候觉得它"太谨慎"------明明只是格式化代码，也弹确认框让我点。又有些时候我想让它分析一下项目架构，它却直接动手改代码了。

后来才搞明白：Claude Code 有六种权限模式，控制它"能做什么"和"每步要问你几次"。我用"一个模式走到黑"的方式用了两周，相当于拿着一把螺丝刀干了所有的活。

六种模式，一句话概括

模式	行为	一句话
`default`	大部分操作弹确认框	"改动代码前问一下"
`acceptEdits`	文件编辑自动过，危险命令仍确认	"改文件不用问，删库要问"
`plan`	只分析不执行	"光说不练"
`auto`	全部自动确认	"你看着办"
`dontAsk`	全自动 + 跳过确认	"干就完了"
`bypassPermissions`	不检查任何权限	"为所欲为"

日常高频用的是前三个。后三个是信任度高时的加速模式。

你每天实际上在用哪几种

大多数时候你不需要主动切换。"改个函数""写个测试"这类任务，default 足够了------它该读代码读代码，该弹确认弹确认。

但有两个场景值得主动用别的方式。

想过方案再动手------用 plan。

你拿到一个需求，不想让 AI 上来就撸代码。你想先看方案。

按 Shift+Tab 切到 plan，或者启动时指定：

bash 复制代码

claude --permission-mode plan

在这种模式下输入需求，Claude Code 只分析、只出方案，不动文件：

复制代码

用户: 这个订单模块如果要拆成独立服务，需要动哪些地方？

Claude Code (plan):
  • Analyzing order module dependencies...
  • Dependency graph:
    orders/ depends on: users/, payments/, notifications/
    payments/ depends on orders/: yes (circular dependency found)
  • Recommendation:
    1. Resolve circular dependency first --- extract shared types to common/
    2. Orders module can then become independent service
    3. Estimated scope: 18 files, ~350 lines changed
  • Risks: 3 tests in payments/ may break, need to update import paths

方案看完觉得 OK，切回 default 开干。Plan → default 是日常最高效的组合。

一天改几十次代码，不想每次弹窗------用 acceptEdits。

写代码、改代码这类操作自动放行。rm -rf、git push --force、sudo 这类危险命令仍然会弹确认。这是我日常用得最多的状态------高频操作放行，底线的底线守住。

切换到 acceptEdits：Shift+Tab 循环切换，或者在 settings.json 里设为默认：

json 复制代码

{ "permissionMode": "acceptEdits" }

同一个需求，不同模式下的真实表现

用一个例子体会区别。项目里有个 user_service.py，加一个"按邮箱域名统计用户数"的函数。

plan 模式下：

复制代码

用户: 给 user_service.py 加一个 count_by_email_domain()

Claude Code (plan):
  • Reading user_service.py
  • Found: existing count_by_status() follows aggregation pattern
  • Proposed implementation:
    - Add count_by_email_domain()
    - Extract domain via split('@')[1]
    - Use Python groupby (simpler than SQL for in-memory data)
    - Return dict[str, int]
  • Affected files: user_service.py only
  • Recommend adding 2 test cases: normal domain, empty email edge case

  需要我开始实现吗？当前 plan 模式，不执行修改。

分析了现有模式，给了一个干净的方案，不碰代码。

default 模式下：

复制代码

用户: 给 user_service.py 加一个 count_by_email_domain()

Claude Code (default):
  • Reading user_service.py
  • Found existing count_by_status() as reference pattern
  • Edit user_service.py: +12 lines

  Review change? [Y/n]
  → Accept

  • Would you like to run tests? [Y/n]
  → Y
  • pytest tests/test_user_service.py: 3 passed

  完成。

方案分析阶段被压缩了------它判断这个问题不需要讨论方案，直接动手。中间弹了两次确认：Accept diff、Run tests。

Plan 模式的边界------不是完美的安全沙箱

Plan 模式在实现上是靠 prompt 指令约束的------系统提示词告诉模型"不要改文件、不要跑命令"。这和 Codex 的内核级 Sanbox 不一样，不是硬隔离。

意味着什么？理论上模型可以绕过指令。实践中极少发生，但你应该知道这个边界。不要把关键操作的"不执行"完全赌在 plan 模式上------它是一个设计评审工具，不是安全沙箱。

真正需要安全隔离的场景，用 Codex 沙箱（第 7 篇讲过）。

怎么选------一个实用的决策框架

复制代码

不确定怎么做，想先看方案    → plan
知道要做什么，日常改代码    → default
大量代码修改，不想顿顿确认  → acceptEdits
完全信任的重复性批量操作    → auto

启动时指定：claude --permission-mode acceptEdits

会话中途切换：按 Shift+Tab 循环切换模式（default → acceptEdits → plan → dontAsk → auto → bypassPermissions → default...）。

同一个 session 里随意切，不需要重启。

三种典型的翻车场景

翻车 1：用 plan 模式一整天忘记切回来

有次我用 plan 模式分析了一个 microservice 拆分方案，方案确认后习惯性地说"开始做"。Plan 模式下的 Claude Code 回了一句"需要我切换到可执行模式吗？"------没做任何事。花了 30 秒才想起来自己还在 plan 里。

教训：确认设计方案后第一时间切模式。

翻车 2：用 acceptEdits 跑了一次大规模删除

acceptEdits 不会拦文件编辑，包括删除内容的编辑。有次我说"删掉 deprecated 的旧模块"，它一次性删了 5 个文件，没弹一个确认框。没有造成损失（都在 git 里），但那个速度让我后脊一凉。

教训：涉及删除的指令，切回 default，挨个确认。

翻车 3：把 plan 模式当沙箱用

Plan 模式只是 prompt 约束，不是安全隔离。有次我在 plan 模式下让它"起草一个 bash 脚本清理临时文件"，它写了一个包含 find . -name '*.tmp' -delete 的脚本。虽然没执行，但如果我在 plan 模式下给了它可执行权限的期待，可能就蒙过去了。

教训：真正的沙箱隔离用 Codex，plan 模式只是"帮忙分析，别动手"。

说穿了就一句话

Claude Code 不是只有一个档位。方案阶段 plan，实现阶段 acceptEdits，危险操作切回 default。Shift+Tab 随按随切，一个 session 里三种模式轮流用。

权限模式管的是"单次会话里 AI 能做什么"。下一篇管的是"AI 怎么成为团队开发流程的一部分"------把 Claude Code 嵌入 CI/CD 流水线。自动化代码审查、生成 CHANGELOG、跑回归测试。