11 · 该给 AI 多少权限
很多人第一次用 Claude Code，被各种权限弹窗搞烦了，恨不得全关掉。另一群人正好相反，什么都不敢放行，每个操作都手动确认。翔宇两种都试过，最后发现——两
很多人第一次用 Claude Code，被各种权限弹窗搞烦了，恨不得全关掉。另一群人正好相反，什么都不敢放行，每个操作都手动确认。翔宇两种都试过，最后发现——两种反应都很正常，但都偏了。权限的本质不是「限制」或「放开」，是建立信任的刻度。——翔宇
要点速览
- 你将理解为什么给 AI 设权限不是限制它，而是建立分层的信任关系
- 你将理解五种权限模式各自解决什么问题
- 你将理解沙盒机制如何在安全和效率之间找到平衡点
- 你将理解成本控制为什么也是「边界」的一部分
- 你将理解深度防御（Defense in Depth）的分层思维
1. 一个才华横溢的实习生
Anthropic 官方对 Claude Code 有一个精准的比喻：把它当作一个才华横溢但不可完全信任的实习生。
「才华横溢」——它确实能力很强。写代码、读文件、跑命令、重构模块，大多数时候做得又快又好。
「实习生」——它对你的业务背景、项目历史、安全规范了解有限。它不知道那个 .env 文件里存着你生产数据库的密码。它不知道那个看起来无害的 rm -rf 可能清掉你一周的工作。
「不可完全信任」——不是说它会故意搞破坏，而是它的判断力有边界。它可能被恶意代码注释里的指令误导（提示注入），可能在不理解后果的情况下执行危险操作。
所以你需要给它设边界。但这里有一个认知上的关键转变——
2. 翻转：权限是信任层级，不是限制
你可能会这样想：权限弹窗 = 不信任 AI = 限制它 = 让它更弱。
🧠 底层逻辑 这个想法很自然，但偏了一层。更准确的理解是「信任层级」——你不是不信任它，而是对不同类型的操作给予不同程度的信任。读文件？完全信任，不需要问我。写文件？基本信任，但帮我记个检查点。跑 Shell 命令？看情况，简单的自动通过，复杂的先问我。删除文件？不信任，每次都要我确认。这不是限制，是分级授权。
换一个角度想。你让律师帮你审合同——你信任他的专业能力。但签字之前，你还是要自己看一遍。这是限制律师吗？不是。这是你在「让专家处理专业问题」和「在关键节点保留决策权」之间找到的平衡。
Claude Code 的权限系统做的是同一件事：让 AI 在低风险的地方自由发挥，在高风险的地方征求你的意见。 它不是「限制」，是「分工」——AI 负责执行，你负责在关键节点把关。
3. 五种权限模式
理解了「信任层级」之后，五种权限模式就不是五个开关，而是五种不同的信任姿态。
a. default——标准工作模式
默认状态。读文件、搜索文件不需要确认（低风险操作），编辑文件和执行命令需要你点一下「同意」（高风险操作）。就像一个标准的审批流程：普通事务自动通过，敏感事务需要签字。
b. plan——只读分析模式
Claude Code 可以看但不能动。它能读你的文件、分析代码结构、给出建议，但不能修改任何东西。什么时候用？你想让它看看代码有什么问题，但不希望它动手。
就像让顾问参观你的工厂但不碰任何设备。他可以看生产线、读报表、提建议，但不能按按钮、动机器。
c. acceptEdits——自动接受编辑
编辑文件不再弹确认框，自动通过。但 Shell 命令仍然需要确认。前提是你信任 Claude Code 的代码编辑能力，但不完全信任它的命令执行。很多人在熟悉 Claude Code 之后会切到这个模式——代码编辑有检查点可以回退，但命令执行了就回不来。
d. dontAsk——预批准之外一律拒绝
你提前列好一张白名单，白名单之外的操作全部自动拒绝，不弹框、不询问。适合自动化场景：你知道任务只需要特定的几个操作，其他操作都不应该发生。
e. bypassPermissions——全部放行
跳过所有权限确认。Claude Code 可以做任何事情。
🔑 关键点 这个模式只应该在完全隔离的环境中使用——docker 容器、一次性虚拟机、CI/CD 管道。永远不要在你的日常开发机器上用。如果 AI 误操作了，在隔离环境里最多是这个容器废了；在你的开发机上，可能是你的项目废了。
你可以用 Shift+Tab 在三种常用模式之间快速切换：Normal → Auto-Accept → Plan。dontAsk 和 bypassPermissions 需通过 settings 或命令行参数单独设置。
想一想：你现在的工作方式对应哪种模式？如果你从来没调过权限模式，哪种可能让你更高效？
4. 细粒度的信任：Allow / Ask / Deny
五种模式是粗粒度的信任姿态。但有时候你需要更精细的控制——不是「所有编辑都信任」或「所有命令都要确认」，而是「npm test 信任，rm -rf 绝对不行」。
这就是权限规则做的事。三个关键词：
Allow——自动通过，不弹框。你信任这个操作。
Ask——弹框确认。你需要看一眼再决定。
Deny——直接拒绝，不弹框。你明确禁止这个操作。
优先级顺序：Deny > Ask > Allow。如果一个操作同时匹配了 Allow 和 Deny 规则，Deny 生效。安全规则永远优先于便利规则。
🎨 打个比方 三条规则就像红绿灯。Allow 是绿灯（直接通过），Ask 是黄灯（减速看看），Deny 是红灯（绝对停下）。红灯永远覆盖绿灯——即使前面的路口是绿灯，这个路口亮了红灯你就得停。
一个具体的例子：
| 规则 | 说明 |
|---|---|
| Allow: Bash(npm run:*) | 所有 npm run 开头的命令自动通过 |
| Allow: Bash(git diff:*) | git diff 相关命令自动通过 |
| Ask: Bash(git push:*) | git push 需要确认（推到远程是大事） |
| Deny: Bash(rm -rf:*) | 绝对禁止 rm -rf |
| Deny: Read(./.env) | 禁止读 .env 文件 |
这套规则组合在一起，画出了一个精确的信任边界：日常开发命令放行，推送代码确认一下，危险操作和敏感文件一律禁止。
5. 沙盒——画一个安全区
权限规则是「一个操作一个操作地」控制信任。但有一种更优雅的方式：先画一个安全区，区内自由活动，区外需要审批。
这就是沙盒（Sandbox）。
你带孩子去游乐场。游乐场有围栏，围栏内有滑梯、秋千、沙坑，孩子可以自由玩。你不需要每次他走一步就问你「我能走吗」——围栏内随便。但如果他想走出围栏，你需要知道。
技术上怎么实现的？macOS 用 Seatbelt——Apple 原生的沙盒框架，在操作系统层面限制了进程可以访问的文件和网络。Linux 用 bubblewrap——容器级别的隔离技术。
🔍 深入一步 为什么要在操作系统层面做隔离？因为应用层面的权限检查可以被绕过——一个精心构造的命令可能绕过 Claude Code 的权限规则。但操作系统级别的隔离绕不过去——进程本身就被限制了，不管它执行什么命令。这是深度防御的核心思想：多层防护，每一层独立工作，突破一层还有下一层。
沙盒开启后有一个特别实用的效果：大量低风险操作可以自动放行，权限弹窗会显著减少。因为沙盒内的操作已经被隔离了，风险可控，所以可以自动放行。你不再需要对每个 Shell 命令说「同意」——反正它在围栏内，出不去。
但沙盒不是万能的。有些操作必须在沙盒外执行——比如 docker 命令（它需要访问 docker socket）。沙盒的 excludedCommands 配置就是为这个场景设计的：你明确列出哪些命令需要在沙盒外运行，其他的一律在沙盒内。
6. 再纠一个偏：成本也是边界
到这里，你可能觉得「边界」就是安全和权限。但翔宇想多拆一层。
💬 通俗讲 你可能觉得「安全边界」和「成本控制」是两码事。其实它们在底层是同一件事——给系统行为设定活动范围。安全边界防止 AI 做了不该做的事，成本边界防止 AI 花了不该花的钱。两者都是「信任但验证」的思维方式。
Claude Code 每次交互都消耗 token，token 就是钱。不设限制的话，一个失控的自动化脚本可能在几小时内烧掉几百美元。
三个成本控制工具值得知道：
/cost 命令——随时查看当前会话花了多少钱。像车里的油表。
effort 参数——控制模型的思考深度。同一个模型，low effort 比 high effort 显著节省 token 开销。就像开车，轻踩油门省油，猛踩费油。不是每个任务都需要猛踩。
--max-budget-usd——在无头模式（自动化场景）下设定预算上限。超过这个金额自动停止。防止自动化任务失控。
7. 四层防御——全貌
现在把前面讲的所有东西串在一起。Claude Code 的安全设计不是单层的——它是多层叠加的。每一层独立工作，任何一层被突破，下一层仍然能保护你。
| 层级 | 机制 | 保护什么 |
|---|---|---|
| 第一层 | 权限规则（Allow/Ask/Deny） | 控制每个操作的通过/拒绝/确认 |
| 第二层 | 沙盒隔离（Seatbelt/bubblewrap） | 操作系统级别限制文件和网络访问 |
| 第三层 | 外部隔离（docker/VM） | 整个环境级别的隔离 |
| 第四层 | 人工审查（你的判断） | 最后一道防线 |
就像银行保险库：第一层是门禁卡，第二层是加固的墙壁，第三层是整栋建筑的安保系统，第四层是你本人的判断。攻击者要拿到保险库里的东西，必须连续突破所有四层。
8. 两个常见反模式
a. 批准疲劳
Claude Code 一直弹权限确认，你被弹烦了，开始无脑点「同意」。这和 Windows Vista 当年 UAC 弹窗的经典问题一模一样——弹窗太频繁，用户养成了「无脑点同意」的习惯，弹窗完全失去了保护作用。
解决方案不是关掉弹窗，而是减少不必要的弹窗。开沙盒（显著减少弹窗），配白名单（信任的命令自动通过），把真正需要你关注的操作留在弹窗里。弹窗少了，每个弹窗你才会认真看。
b. 过度防御
另一个极端。有人把 Claude Code 配得什么都要确认，甚至读文件都弹窗。
问题不是安全性太高。问题是它让你的工作效率降到了和手动操作差不多的水平。你雇了一个搭档，然后搭档每做一步都要找你签字——这个搭档还不如没有。
信任是要分级的。读文件是低风险操作（它不改变任何东西），应该给完全信任。写文件中等风险，可以给条件信任（配合检查点回退）。只有真正不可逆的操作才需要每次确认。
9. 设置优先级
权限配置可以从五个地方来，它们之间有明确的优先级：
| 优先级 | 来源 | 谁控制 |
|---|---|---|
| 最高 | 企业策略（managed-settings.json） | 公司管理员 |
| 高 | 命令行参数 | 你自己，这次启动 |
| 中 | 本地项目设置（.claude/settings.local.json） | 你自己，这个项目 |
| 中低 | 共享项目设置（.claude/settings.json） | 团队，这个项目 |
| 最低 | 用户设置（~/.claude/settings.json） | 你自己，所有项目 |
高优先级的覆盖低优先级的。企业策略最高——管理员说了不让用 bypassPermissions，你在本地怎么设都不管用。越具体的配置覆盖越通用的，越有权威的来源覆盖越没权威的。
10. 把边界设计当成日常习惯
理解了安全、权限、成本这三个维度的边界之后，关键是把它们变成习惯。
第一天——默认模式就好。感受一下哪些弹窗你每次都点同意（这些可以加到白名单），哪些你会仔细看（这些留着）。
第二天——开沙盒，配白名单。把 .env 和密钥文件加到 Deny 列表。
第三天——审视你的配置。用 /permissions 看看你都放行了什么，有没有该禁止但忘了的。
之后——每次项目开始时花两分钟看一眼权限配置。不同项目的信任边界不一样。一个个人练手项目和一个连着生产数据库的项目，应该有完全不同的权限配置。
⚡ 速记 权限 = 信任层级（Allow/Ask/Deny + 五种模式）。沙盒 = 操作系统级隔离（显著减少弹窗）。成本 = 预算边界（/cost + effort + --max-budget-usd）。四层防御：权限 → 沙盒 → 外部隔离 → 人工审查。
11. 你真的懂了吗
这篇拆了一个概念：边界。
- 有人说「AI 这么强了还要设权限，不是脱裤子放屁吗」。你能用「才华横溢的实习生」类比解释为什么需要权限吗？
- 五种权限模式，你的日常工作适合哪种？为什么不是其他几种？
- 沙盒为什么能显著减少权限弹窗？它和权限规则的区别在哪里？
- 深度防御有四层。如果有人说「我开了沙盒就够了，不需要权限规则了」，你怎么反驳？
- 成本控制为什么也是「边界」的一部分？它和安全边界的共同逻辑是什么？
