Claude Code 安全指南：权限、MCP、沙盒

传统聊天机器人是通过 API 配置的，最糟也就是产生幻觉。但 AI 编码代理直接进入您的代码库、终端，且（往往）接入您的云凭据，这使它与特权开发环境的距离，比以往任何“聊天机器人”都更近。

问题在于，如何在不拖慢效率的情况下安全地使用 Claude Code。通过适当调校的权限、MCP 控制和沙盒，您就能做到。

本文将带您了解 Claude Code 的安全模型到底如何工作、哪些地方需要留意，以及如何在不授予超出预期访问权限的前提下保持其高效可用的实践。

如果您完全是 Claude 和 Claude Code 的新手，欢迎报名我们的免费Claude Code 101课程，一个下午即可打好基础。

理解 Claude Code 的安全模型

在调整任何一条规则之前，您需要先建立 Claude Code 实际控制范围的心智模型。

这里有五个组成部分：用于裁决操作许可的权限系统，用于限定单项能力范围的工具访问控制，用于外部集成的 MCP 权限，用于操作系统级隔离的沙盒，以及用于事后审查的可审计性。每一层解决不同问题，但它们层层叠加。

权限系统

权限系统是静态层。

您在 settings.json 中声明 Claude 可以做什么，使用三个列表：allow、ask 和 deny。规则按 deny、ask、allow 的顺序评估，先匹配者生效。即使存在更宽泛的 allow 规则，deny 规则也会阻止该调用。

如果没有规则匹配，Claude 将回退到会话的 defaultMode（下一节将介绍模式）。

工具访问控制

权限是附加在工具上的，而不是附加在整个代理上的。

Claude Code 有一套内置工具，例如用于 shell 命令的 Bash，用于文件系统操作的 Read、Edit 和 Write，用于 HTTPS 请求的 WebFetch，用于检索的 WebSearch，以及其他一些工具。每条规则会指明工具名，并可选地在括号中指定限定符，如 Bash(git commit:*) 或 Read(./.env)。

这正是最小权限原则得以落地的关键。您可以允许用于测试的 Bash(npm run:*)，而不必授予 Claude 完整的 shell 访问权限。

MCP 权限

MCP 服务器为 Claude Code 扩展了其并非原生设计的工具。

每个服务器带来一组工具（GitHub 服务器提供拉取请求工具，数据库服务器提供查询工具，等等）。权限系统同样覆盖它们，但语法不同——规则使用 mcp__servername__toolname 的形式，而不是括号限定符。

要记住的一点是，MCP 大致让问题翻倍，因为您不仅要决定 Claude 能在您的 shell 中做什么，还要决定它能对您连接的每个外部系统做什么。

沙盒

沙盒是 Bash 工具下方的操作系统级安全层。

权限规则告诉 Claude 应该做什么。沙盒在操作系统层面限制文件系统访问和出站网络调用，从而强制它能做什么。在 macOS 上，它通过 Seatbelt 开箱即用。在 Linux 和 WSL2 上，您需要先安装 bubblewrap 和 socat。

这两层工作方式相似但覆盖的场景不同。权限阻止 Claude 尝试某些操作；而如果提示注入仍诱使 Claude 尝试，沙盒会阻止尝试成功。

可审计性

最后一环是能看清发生了什么。

/permissions 命令会列出每条活动规则及其来源设置文件，帮助回答“为什么 Claude 会运行那个？”挂钩（PreToolUse、PostToolUse 等）可让您将每次工具调用记录到自己的系统。对于团队，OpenTelemetry 导出器会将使用情况和工具调用数据发送到您已有的可观测性栈。

Claude Code 的权限与访问控制

大部分安全性来自权限设置，因此这将是您花最多时间微调的部分。

文件访问

默认情况下，Claude 可以读取并编辑您启动它时所在目录中的文件。

读取由 Read 工具控制，编辑由 Edit 和 Write 控制。每个工具都接受括号内的路径模式，使用 gitignore 风格的语法，例如 Read(**/.env) 匹配任意深度的每个 .env 文件，而 Edit(src/**) 匹配 src/ 下的一切。

对 Read 的 deny 将覆盖 Claude Code 自身的文件工具（Read、Grep、Glob、LS），但这只是尽力而为。通过 Bash 运行的 Python 或 Node 脚本仍能打开该文件，因为读取是通过 shell 完成的，而不是通过 Claude 的 Read 工具。如果秘密很重要，请将 Read 的 deny 与针对这些路径的 Bash 对 cat、head 和 tail 的 deny 结合使用。

若要将访问范围扩展到工作目录之外，请在 settings.json 中使用 additionalDirectories。这样您就可以在不完全打破工作目录边界的情况下，授予 Claude 访问代码库外部共享库或您主目录中配置文件的权限。

命令执行

Bash 工具是您必须最谨慎限定范围的工具。

裸的 Bash 规则允许所有命令。像 Bash(npm run:*) 这样的限定规则只允许匹配的调用。这里需要使用冒号加星号的模式，且 Claude Code 能理解 shell 运算符，因此 Bash(safe-cmd:*) 不会匹配 safe-cmd && rm -rf /。

某些命令在所有模式下无需提示即可运行，因为默认将其视为只读。该列表包括 ls、cat、echo、pwd、head、tail、grep、find、wc、which、diff、stat、du、cd，以及只读形式的 git。您无法手动缩短此列表，但可以为其中任何项添加 ask 或 deny 规则以覆盖默认行为。

对于任何未预先批准的命令，Claude 会在默认模式下提示。提示会显示确切命令，并允许您一次性批准、按模式批准后续所有匹配调用，或拒绝。

权限模式

权限规则是静态的，但权限模式会改变未匹配调用的处理方式。

共有五种：

• default：首次使用每个工具时提示。

• acceptEdits：自动批准工作目录内的文件编辑，同时仍对 shell 命令进行控制。适用于您信任编辑而不信任 shell 的情境。

• plan：Claude 仅可读取和分析，无法编辑文件或运行命令。适合代码评审或规划会议。

• dontAsk：对未在 allow 列表中明确允许的任何操作自动拒绝。

• bypassPermissions：跳过所有提示。仅在容器或虚拟机等完全隔离环境中才安全。

您可以在会话中按 Shift+Tab 在三种主要模式间切换，或在 settings.json 中选择默认模式：

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

对于团队，受管设置为您提供一层用户无法覆盖的配置。该文件遵循相同的 JSON 格式，并位于系统路径：

• /Library/Application Support/ClaudeCode/managed-settings.json（macOS）

• /etc/claude-code/managed-settings.json（Linux）

• C:\ProgramData\ClaudeCode\managed-settings.json（Windows）

受管设置中的 deny 规则在该机器上的所有项目中均生效，这使您可以在整个组织中强制执行“任何人都不得读取 .env 文件”或“任何人都不得运行 bypassPermissions”之类的规则。

这一切背后的原则是最小权限原则，与您对任何服务账号采用的原则一致。

您应当从能够完成工作的最小权限集开始，只有在遇到阻碍时再放宽。Anthropic 的官方建议也是如此——审阅 Claude 所做的更改，使用 /permissions 审核您的规则，并将项目特定的设置纳入版本控制，以便团队就 Claude 可以处理的内容达成一致。

Claude Code 沙盒

您越允许 Claude 自主运行，沙盒就越有意义。

Bash 工具的暴露面最广，因为 shell 命令可以读取您能读取的任何文件，并修改其具备写权限的任何内容。沙盒会为每个 Bash 命令及其子进程强制施加操作系统级边界，这样 Claude 就能在边界内更自由地运行，而无需您批准每次调用。Anthropic 专门为支持更安全的自主运行而内置了此功能。

值得注意的细节是，沙盒只覆盖 Bash 及其子进程。它不会限制 Read、Edit 或 Write 工具，这些仍通过权限系统进行控制。

原生沙盒

原生沙盒内置于 Claude Code，使用 /sandbox 启用。

在 macOS 上，沙盒使用内置的 Seatbelt 框架，无需安装任何组件。在 Linux 和 WSL2 上，需安装用于文件系统隔离的 bubblewrap 和用于网络代理的 socat。原生 Windows 不受支持，因此您需要在 WSL2 发行版中运行 Claude Code。

文件系统边界很好理解。读取在除被拒路径外的所有位置都可用，而写入仅在工作目录和您允许的其他路径中可用。如果您尝试从沙盒内写入 ~/.bashrc，在 Claude 甚至还未得知失败前，您就会收到“Operation not permitted”。

网络边界稍有不同。出站流量会通过沙盒外运行的代理服务器路由，该代理会根据您的 allowedDomains 列表检查每个请求。新的域名会触发权限提示，因此您能准确看到 Claude 正在访问什么。

一个可用的配置如下所示：

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

在 Anthropic 的内部使用中，启用沙盒可将权限提示减少 84%。

开发容器

开发容器是在隔离层面更进一步。

Anthropic 为 Claude Code 提供了参考 devcontainer，它会设置一个 Ubuntu 环境、挂载您的代码库，并为代理提供一个可工作的 shell。与原生沙盒相比，它的优势是可复现性，因为团队中每个人都获得相同的环境、相同的工具和相同的设置。

但缺点是开销。

使用容器会引入容器构建、文件挂载，以及（有时）更慢的反馈循环。对于单个开发者，原生沙盒通常已足够。对于团队或 CI 使用，这套方案值得部署。

基于 Docker 的隔离

对于长时间运行的自主代理会话，Docker 可以进一步扩大沙盒边界。

通常的设置如下：

• 最小化基础镜像：移除任务不需要的软件包管理器和网络工具。
• 非 root 用户：Claude 绝不以 root 身份运行，因此无法修改系统文件或安装全局包。
• 只读根文件系统：将容器根挂载为只读，仅对特定输出目录授予写入权限。
• 出站代理：通过只允许软件包注册表（npm、PyPI）并拒绝其他访问的代理路由出站网络，使 npm install 等命令可用，而任意 curl 命令不可用。
• 资源限制：设置 CPU、内存和 I/O 限制，防止进程拖垮宿主机。

Docker Sandboxes 为每个沙盒提供一个带有私有 Docker 守护进程的微型虚拟机。宿主机守护进程甚至无法在 docker ps 中看到这些沙盒。其边界更接近虚拟机而非容器，从而封堵了大多数开发者担心的容器逃逸路径。

企业级沙盒策略

对组织而言，问题不在于是否使用沙盒技术，而在于如何分层使用它们。

多数组织的做法如下：

• 权限规则写入 managed-settings.json，个人开发者无法覆盖。

• 原生沙盒运行在权限层之下。

• 开发容器或 Docker 运行在其之下。

• 在最高信任场景（生产访问、机密处理）下，最后一层是没有宿主文件系统挂载的专用虚拟机。

网页版 Claude Code 是同一理念的受管版本。每个会话都在 Anthropic 管理的虚拟机中运行，git 令牌等敏感凭据放置在沙盒外的代理中，边界由基础设施强制执行。

Claude Code 中的 MCP 安全

MCP 是 Claude Code 增长最快的部分。

每接入一个 MCP 服务器，Claude 的能力大致就会成倍拓展，但提示注入或被攻陷的依赖能触达的面也随之成倍扩大。

例如：

• GitHub MCP 服务器会授予 Claude 处理拉取请求的权限。
• 数据库 MCP 服务器会授予其访问您的架构和查询的能力。
• Slack 服务器会授予其访问您的频道。

这些本身都不是问题，但意味着 MCP 需要独立的治理。通过 MCP 工具获取的内容（网页或 API 响应）可能包含注入指令，Claude 会像您亲自输入那样执行。此外，每个服务器都会新增凭据和认证路径，且需分别管理。

工具权限

MCP 工具使用与内置工具不同的命名约定。

规则格式为 mcp__servername__toolname，没有括号限定符。例如，mcp__github__create_pull_request 允许 Claude 精确调用该工具，而对 mcp__github__delete_repo 的 deny 则会阻止危险操作。allow、ask 和 deny 列表的工作方式与 Bash 或 Read 相同。

同样的优先级规则也适用——先 deny，再 ask，最后 allow。对 mcp__github__delete_* 的受管设置 deny 将在该机器上的所有项目中生效。

资源权限

MCP 服务器除了工具外，还可暴露资源。

资源是服务器提供给 Claude 读取的数据（如项目管理服务器中的文件或数据库服务器中的一行记录）。资源访问会经过与工具调用相同的信任检查，且首次连接 MCP 服务器时会运行信任验证步骤，之后其任何工具和资源方可访问。

正确的默认做法是将资源视作另一种工具。如果您不会授予该凭据，就不要授予资源访问。

已批准的 MCP 服务器

Anthropic Directory 列出了已通过 Anthropic 上架标准审查的连接器。

对于组织而言，采用内部允许名单是个好思路。以下两个设置可实现该控制：

• allowedMcpServers：开发者可添加到项目中的服务器的通配模式（例如使用 company-* 仅允许内部维护的服务器）。

• deniedMcpServers：禁止添加的服务器模式，即使开发者尝试也不行。

对于每个会话都应存在的强制性服务器，位于受管设置中的 managed-mcp.json 是分发它们的方式。开发者无法移除或修改其中条目。

在共享代码库中应避免使用的一个设置是 enableAllProjectMcpServers，它会自动批准 .mcp.json 中定义的所有 MCP 服务器。这对个人工作很方便，但对任何被纳入版本控制的项目都很危险，因为恶意 PR 可以向 .mcp.json 添加新服务器并在无提示的情况下运行。

最小权限的工具访问

原则与 Bash 权限相同，只是应用于 MCP。

首要问题在于每个服务器所持的凭据。数据库 MCP 服务器应连接到只读的从库，而不是具有写权限的主库。API MCP 服务器应使用限定到最小必要端点集合的令牌，而不是拥有整个组织完全访问权限的个人令牌，等等。

子代理是限定 MCP 访问的另一种方式。位于 .claude/agents/ 的子代理定义可以精确声明其可用工具（使用 mcp:<server>:<tool> 语法），因此“deploy-agent”可获得基础设施服务器，而“review-agent”仅获得 Read、Grep 和 Glob。代理无法调用未被授予的工具。

MCP 治理

对于大规模运行 Claude Code 的团队或组织，MCP 需要与任何其他生产集成相同的治理形态。

这意味着需要一个带有责任人的已批准服务器注册表、工具调用的端到端审计跟踪（调用了哪些 MCP 工具、由谁调用、使用了哪些参数），以及对批准列表的定期审查。Claude Code 中的 OpenTelemetry 导出器会以可直接接入您现有可观测性栈的格式提供审计数据。

对于更大的组织，集中式 MCP 网关是最干净的实现方式。

开发者连接到网关，而不是逐一注册服务器。网关负责认证、在工具级别强制执行基于角色的访问控制，并输出统一的审计轨迹。它还能解决凭据泛滥问题，因为网关的一套凭据可以替代每位开发者各自持有每个 API 密钥副本的做法。

机密管理与敏感数据

Claude Code 可以读取您能读取的任何内容，这也让机密变得可达。

默认情况下，Claude Code 可以读取您用户账号可读取的每个文件。这包括项目中的 .env 文件，~/.aws/ 中的 AWS 凭据，~/.ssh/ 中的 SSH 私钥，shell rc 文件中的 GitHub 令牌，以及 Claude 创建的任何子进程中的环境变量。这完全正常且属于设计使然。

将机密置于工作区之外

第一步是确保机密不在 Claude 可读取的目录中。

.env 文件是最常见的例子。它们位于项目根目录，被每个开发工具加载，并且恰好包含您不希望出现在 Claude 上下文中的值（数据库 URL 和 API 密钥）。

以下是可采用的几种模式：

• 将机密移动到工作树之外的目录，例如 ~/.config/myapp/secrets.env，并通过环境管理器或指向外部文件的 direnv 设置进行加载。

• 对于容器化工作，将 .secrets/ 文件夹置于绑定挂载之外，使该文件在容器内部不可见。

• 将 Read(**/.env) 和 Read(**/.env.*) 添加到 permissions.deny 列表中，并与 Bash(cat:*/.env) 的 deny 搭配，这样 shell 脚本就无法读取 Read 工具无法读取的内容。

使用机密管理器

对于演示项目之外的任何场景，机密的正确放置位置是机密管理器。

无论供应商（1Password、AWS Secrets Manager、HashiCorp Vault、Doppler、Infisical）如何，模式都相同。将机密放入管理器。您的 shell 或运行时按需获取，并仅向需要的进程暴露。Claude 永远不会看到实际值。

对于 Claude Code，具体做法是设置 CLAUDE_CODE_SUBPROCESS_ENV_SCRUB 以从子进程中剥离 Anthropic 和云服务商凭据，或使用 sandbox.credentials 取消设置沙盒命令的特定变量。前者可阻止 Claude 将您的 ANTHROPIC_API_KEY 传入构建脚本，后者覆盖更广泛场景，防止任何敏感环境变量流入 shell 命令。

限制代码库访问

第三个选项在代码库层面实施。

如果某位开发者不需要对仅限生产的配置拥有写权限，那么他们的 Claude Code 会话也不需要。听起来显而易见，但对多数团队而言，默认是开发者拥有超出日常所需的更广泛访问权限，而 Claude 会继承这些权限。

您可以采取以下两步：

• 将生产配置拆分到一个访问更严格的独立代码库中，这样 Claude 所在的开发环境一开始就不包含生产机密。

• 为任何与 Claude 交互的服务使用范围限定的令牌。例如，用于代码评审工作的 GitHub 令牌不需要 repo:delete。

团队使用 Claude Code 的安全

单个开发者可以随意修改 settings.json。团队却不行，因为整体安全性取决于最弱机器上最弱配置。对于团队和组织部署，Claude Code 提供单独的控制层，由管理员下发，个人用户无法覆盖。

受管设置

受管设置是基础。

该文件位于需要管理员权限才能写入的系统路径：

• /Library/Application Support/ClaudeCode/managed-settings.json（macOS）

• /etc/claude-code/managed-settings.json（Linux）

• C:\ProgramData\ClaudeCode\managed-settings.json（Windows）

该文件中的设置优先于用户级和项目级设置。这里设置的 deny 规则将适用于该机器上的每个项目，开发者无法通过修改自己的 settings.json 来移除它。大多数组织通过 MDM（移动设备管理）或用于其他开发工具的同一配置渠道分发该文件。

以下是受管层面值得了解的一些设置：

• permissions.deny 中针对敏感路径和危险命令的规则

• defaultMode 设为 default 或 plan（绝不设为 bypassPermissions）

• allowManagedPermissionRulesOnly: true 用于锁定权限集

• enableAllProjectMcpServers: false 以强制要求对 MCP 明确批准

• 用于日志记录的 OpenTelemetry 导出器配置

共享的权限策略

团队应将对 Claude 能做什么达成的共识纳入版本控制。

项目级设置位于代码库根目录的 .claude/settings.json。任何在此提交的内容都会对在该代码库中运行 Claude 的所有人生效。此文件是放置项目特定 allow 和 deny 的正确位置。

基于此，您需要了解受管设置与项目设置之间的分工：

• 受管设置包含组织级策略（任何人不得运行 bypassPermissions，任何人不得读取 .env）。

• 项目设置包含工作流约定（此代码库的测试用 npm test 运行；此代码库的部署脚本禁止使用）。

团队治理

对于团队落地，策略层需要负责人。

大规模运行 Claude Code 的团队通常会有一个小组（通常是安全与平台工程）负责受管设置、MCP 允许名单、挂钩脚本和 OpenTelemetry 管道。该小组还会审查例外请求，并在出现新用例时调整策略。

您应将以下内容成文：

• 哪些代码库在范围内、哪些不在，并进行按风险分层的模式设定（处理受监管数据的代码库可能使用 plan 模式运行 Claude，而营销网站代码库可以使用 acceptEdits）。
• 谁可以授予例外，以及如何跟踪这些例外。
• 审查节奏（常见为每季度），团队在此回顾权限规则、MCP 服务器和事件数据。

审计日志

Claude Code 会为每次工具决策、MCP 服务器连接、权限模式变更和 API 请求发出 OpenTelemetry 事件。只有在管理员于受管设置中配置 OTLP 端点后，数据才会开始流动。

以下是最小化的受管遥测设置块：

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

默认情况下，提示内容和工具参数不会被导出，因此您收集的事件是元数据，而非完整对话。要包含提示文本，请设置 OTEL_LOG_USER_PROMPTS=1。要包含工具参数（通常是审计所需），请设置 OTEL_LOG_TOOL_DETAILS=1。这两项决策都涉及隐私影响，因此多数团队会将其作为审慎的策略选择，并配置其遥测后端在存储前进行过滤或编辑。

使用监控

支撑审计的同一 OpenTelemetry 流也用于使用监控。

Claude Code 会导出令牌用量、每次请求的成本、会话计数和工具决策率等指标。聚合后，您可以了解哪些团队获得的价值最多、哪些工作流产生的拒绝最多，以及哪些模型驱动了成本。Datadog、Honeycomb、SigNoz、Elastic 和 Splunk 等后端都可摄取标准 OTLP 格式。

permission_decision 事件中 decision=deny 的激增，可能意味着 Claude 尝试过多，也可能意味着团队的 allow 规则过于收紧。

常见的 Claude Code 安全错误

大多数 Claude Code 事故都源于少数配置错误。下面我将介绍它们以及应对方法。

权限过于宽泛

让权限系统失去锋芒的最快方式就是放行太多。

逐命令提示会带来摩擦，最简单的“修复”是宽泛的 Bash(*) allow 或将 defaultMode: bypassPermissions。这两者几乎抵消了权限系统的大部分作用。

您应当将 allow 规则限定到实际使用的具体工具和命令（例如 Bash(npm test:*) 和 Bash(git status)），其余交由提示处理。起初您会看到更多提示，但几个会话后，常用命令已被加入允许列表，提示也大多会停止。

不受限制的 MCP 访问

第二个错误是在未检查凭据使用及可触达范围的情况下连接 MCP 服务器。

这通常发生在有人启用 enableAllProjectMcpServers，从公共 MCP 目录连接了几个服务器，却从未回头审查。等到某个使用弱凭据的服务器泄露敏感信息时，该连接早已深埋在配置历史中，无人记得曾批准过它。

修复方法与权限相同。通过 allowedMcpServers 使用明确的允许名单，通过内部的 managed-mcp.json 配置所有人都需要的服务器，并对该列表进行定期审查。

未启用沙盒

如果沙盒关闭，权限系统就是 Claude 与您的文件系统之间仅存的屏障。

这对短时交互式会话尚可，因为您会批准每条命令。但对自主运行、已放宽 allow 规则的会话，或任何涉及外部来源代码的工作都并不合适。

/sandbox 可开启沙盒。如果未安装依赖，菜单会显示各平台需要安装的组件。开启后，权限提示会减少，操作系统会拦截那些您的 allow 规则未覆盖的情况。

盲目接受更改

acceptEdits 既方便也危险。

当 Claude 在重写一个函数而您在旁监控时，自动接受没问题。但当 Claude 在一小时内跨 30 个文件反复迭代时，您往往会不再阅读差异，而开始信任代理。这正是问题可能发生的地方。

请养成以下两个习惯：

• 在让 Claude 自主运行之前务必提交一次，这样回滚只需一条 git reset。

• 在每次由 Claude 发起的提交前审阅差异，而不是在会话结束时一次性审阅累计差异。

忽视审计轨迹

在未启用遥测的情况下运行 Claude Code 的团队，无法回答“是哪次会话做的？”事件只会在每台机器上本地累积并滞留。您第一次需要审计轨迹时，往往也是发现未配置的最糟时刻。

最低限度的基线是将 tool_decision、permission_decision 和 api_request 事件导出到团队现有的可观测性栈。随后，您可根据用例构建仪表板和告警。

结语

对聊天机器人而言，最糟的情况是一条错误答案。但对编码代理来说，则是以您的凭据在生产环境中执行了一条 shell 命令。

这就是三大支柱之所以重要的原因：

• 权限决定 Claude 被允许做什么
• MCP 控制决定它可以触达哪些外部系统
• 沙盒决定当前两者不足时会发生什么

每一层都覆盖了其他层未覆盖的失效模式。它们共同定义了 Claude 实际工作的边界。

如果您希望获得生成式 AI 认证，请参考这篇对比、顶级课程、备考建议与常见问题：2026 年最佳生成式 AI 认证。