mirror of
https://github.com/claude-code-best/claude-code.git
synced 2026-06-18 06:15:51 +00:00
ea0d78af5f
移除 TypeScript 代码和源码路径， 聚焦八层优先级的设计考量、三维度匹配的安全关注点、 deny 优先的设计哲学和 Denial Tracking 的死循环防护。 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
107 lines
4.4 KiB
Plaintext
107 lines
4.4 KiB
Plaintext
---
|
||
title: "权限模型"
|
||
description: "AI 执行命令是最危险的能力。Allow/Ask/Deny 三级权限体系如何在安全与效率间取得平衡？理解规则来源、匹配引擎和死循环防护。"
|
||
keywords: ["权限模型", "Allow Ask Deny", "权限规则", "权限模式"]
|
||
---
|
||
|
||
## 核心问题
|
||
|
||
AI 可以读取文件、执行命令、修改代码——这些操作在带来效率的同时也带来风险。权限系统的问题是：**什么时候需要人类确认，什么时候可以自动放行？**
|
||
|
||
## 三种权限行为
|
||
|
||
| 行为 | 含义 | 用户感知 |
|
||
|------|------|---------|
|
||
| **Allow** | 自动放行 | 无感知 |
|
||
| **Ask** | 弹出确认 | 需要批准或拒绝 |
|
||
| **Deny** | 直接拒绝 | 被告知原因 |
|
||
|
||
## 规则来源的八层优先级
|
||
|
||
权限规则从 8 个来源汇聚，后者覆盖前者：
|
||
|
||
```
|
||
用户全局设置 < 项目设置 < 本地覆盖 < 命令行参数 < 企业策略 < CLI 参数 < 技能白名单 < 本次会话授权
|
||
```
|
||
|
||
**设计考量**：
|
||
- **企业策略不可被用户覆盖**——企业管理员可以通过策略强制禁止某些操作
|
||
- **本次会话授权优先级最高**——用户在对话中选择"Always allow"立即生效
|
||
- **项目设置可被 git 追踪**——团队可以通过 `.claude/settings.json` 共享权限规则
|
||
|
||
### 规则结构
|
||
|
||
每条规则指定三个要素：
|
||
- **工具名**：如 `Bash`、`Edit`、`mcp__server1`
|
||
- **匹配内容**：如 `git *`（命令模式）、`src/**`（路径模式）
|
||
- **行为**：allow / ask / deny
|
||
|
||
## 三维度匹配引擎
|
||
|
||
### 1. 工具名匹配
|
||
|
||
最简单的匹配——规则只指定工具名，没有额外内容：
|
||
- `"Bash"` → 匹配所有 Bash 调用
|
||
- `"mcp__server1"` → 匹配该 MCP Server 的所有工具
|
||
|
||
### 2. 命令模式匹配（Bash 专用）
|
||
|
||
Bash 工具的规则可以指定命令模式：
|
||
- `{"tool": "Bash", "content": "git *"}` → 匹配 `git commit -m 'fix'`
|
||
|
||
命令通过 AST 解析提取第一个子命令进行匹配，不受管道或条件表达式干扰。
|
||
|
||
### 3. 路径匹配（文件工具专用）
|
||
|
||
Read/Edit/Write 工具的规则可以指定文件路径 glob：
|
||
- `{"tool": "Edit", "content": "src/**"}` → 匹配 `src/utils/foo.ts`
|
||
|
||
**设计洞察**：三维度匹配对应三种不同的安全关注点：
|
||
- 工具名 → "这个工具允不允许用"
|
||
- 命令模式 → "这条命令安不安全"
|
||
- 路径 → "这个文件能不能碰"
|
||
|
||
## 权限检查流程
|
||
|
||
```
|
||
Blanket deny → 工具名完全匹配 deny 规则？ → 直接拒绝
|
||
Blanket allow → 工具名完全匹配 allow 规则？ → 直接放行
|
||
工具自身检查 → 各工具有自定义逻辑
|
||
Hook 系统 → PreToolUse hook 可以覆盖结果
|
||
Ask 规则 → 匹配则弹出确认
|
||
默认行为 → 由当前权限模式决定
|
||
```
|
||
|
||
**设计哲学**：deny 优先于 allow。如果某条规则说"禁止 Bash"，即使另一条规则说"允许 Bash"，最终结果也是禁止。
|
||
|
||
## 权限模式
|
||
|
||
| 模式 | 适用场景 | 行为 |
|
||
|------|---------|------|
|
||
| **Default** | 日常使用 | 敏感操作逐一确认 |
|
||
| **Plan Mode** | 探索阶段 | 只能读不能写 |
|
||
| **Accept Edits** | 快速迭代 | 文件编辑自动放行 |
|
||
| **Don't Ask** | 减少打断 | 尽量自动决策 |
|
||
| **Auto** | 信任 AI | 自动分类决策 |
|
||
| **Bypass** | 完全信任 | 所有操作自动放行 |
|
||
|
||
**设计考量**：权限模式不是"越宽松越好"。Default 模式下每次确认看似烦人，但它是防止 AI 误操作的最后防线。Bypass 模式需要显式的危险标志才能启用——这不是给日常使用的。
|
||
|
||
## Denial Tracking：死循环防护
|
||
|
||
当 AI 被连续拒绝同一类操作达到 3 次时，系统注入消息迫使其改变策略。
|
||
|
||
**为什么需要这个**？AI 有时会陷入"请求 → 被拒 → 用略有不同的方式请求同一个操作 → 再被拒"的死循环。Denial tracking 检测到这种模式后强制 AI 换思路。
|
||
|
||
这是一个经典的"AI 行为修正"设计——不是通过硬约束阻止特定行为，而是通过反馈引导 AI 自行调整。
|
||
|
||
## 运行时更新
|
||
|
||
权限规则可以在运行时动态更新。当用户在确认对话框中选择"Always allow"，规则被同时写入 settings 文件和内存中的权限上下文，立即生效。
|
||
|
||
## 接下来
|
||
|
||
- **为什么安全很重要** — 理解权限系统的设计动机
|
||
- **Plan Mode** — 理解"先规划再执行"的安全工作流
|
||
- **沙箱** — 理解 Bash 命令的隔离执行环境
|