第 9 章：模式切换

在前四章中，我们掌握了 Claude Code 的四大核心能力：对话、编辑、终端命令和 Git 集成。这些是"术"——你知道 Claude 能做什么。本章要解决的是"度"——你让 Claude 做到什么程度、以多大的思考投入度来执行任务。

Claude Code 提供了三组可调节的"行为旋钮"：权限模式控制它是否需要你确认、Effort 等级控制它投入多少脑力、思考模式控制它是否向你展示推理过程。三者配合使用，才能让 Claude 在不同的任务场景中发挥最佳效能。

本章目标：掌握五种权限模式的差异与选择策略，理解 Effort 和思考模式的作用，能根据任务类型灵活配置 Claude 的行为。

9.1 五种权限模式详解

权限模式决定了 Claude Code 在执行操作前是否需要你的明确确认。Claude Code 提供了五种模式，从"每步都要确认"到"完全不确认"，覆盖了从初学者到资深用户的全部需求。

Ask before edit（默认）

行为：Claude 每次修改文件前，都会弹出确认对话框，展示即将修改的内容，等待你选择 Allow 或 Deny。

这是 Claude Code 的出厂默认模式，也是最安全的模式。

确认对话框的交互流程：

Claude 分析你的需求，决定要修改哪些文件
侧边栏弹出权限确认窗口，列出：操作类型（Edit/Write/Bash）、文件路径、修改前后的内容对比
你有三种选择：
- Allow：批准本次操作，Claude 继续执行
- Deny：拒绝本次操作，Claude 调整方案或停止
- Allow All：本次对话后续同类型操作不再询问

适用场景：

使用 Claude Code 的第一周：你还在学习它如何理解指令、如何修改代码，每次确认是最好的学习方式
不确定 Claude 会做什么的时候：新语言、新框架、不熟悉的项目
查看 Claude 的思路：通过观察它的修改计划，你其实在了解一个 AI 如何处理编程问题
脆弱代码区域：涉及核心业务逻辑、支付、认证等不能出错的模块

个人建议：如果你是第一次接触 AI 编程工具，至少用 Ask 模式完整做完一个小需求。这个过程会帮你建立对 Claude Code 行为的直觉——它会先读哪些文件、怎么规划修改、一次改动多少个地方。

Edit automatically

行为：Claude 直接修改文件，不再弹出文件编辑确认。但对于危险命令（如 rm -rf、sudo、git push --force 等），仍然会要求你确认。

适用场景：

信任基础已建立：你已经用过一段时间的 Ask 模式，对 Claude 的行为有合理预期
简单、明确的重构：比如"把所有 var 改成 let"、"把这个组件的 Prop 类型提取成 interface"
创建新文件：新建文件的风险远低于修改已有文件，Edit 模式可以加速这类操作
工作量大但风险低的任务：如生成单元测试、补充 JSDoc 注释

风险提示：

Claude 可能会修改你没预料到的文件。比如说"把这个验证逻辑改一下"，它可能同时动了三个相关的 utility 函数——而你认为只会改一个文件
当你给的口头描述不够精确时，Edit 模式下的 Claude 可能基于自己的理解做出你并不期望的改动
缓解策略：使用 Edit 模式时，养成在 Diff 审查区逐文件检查的习惯。即使 Claude 改对了，你也应该过一遍

何时从 Ask 升级到 Edit：当你发现自己在 Ask 模式下，对 90% 的确认弹窗都直接点了 Allow，说明你对 Claude 的行为已经有足够的信任，可以升级到 Edit 模式了。

Plan mode

行为：Claude 先输出一份完整的修改方案（计划），等待你审阅和调整，确认后才开始实际执行。整个流程分为三个阶段：

Plan（规划）：Claude 分析你的需求，列出将要修改的文件、每处修改的内容和原因、执行的顺序
Review（审阅）：你阅读计划，提出修改意见。比如"第二步不要改 A 文件，改 B 文件"或者"第三步的方案太复杂，用更简单的方式"
Execute（执行）：确认后，Claude 按照最终方案逐步执行

适用场景：

大规模重构：涉及 5 个以上文件、改变架构层次的改动
影响范围不确定的任务：比如"把这个工具函数升级一下，支持异步调用"——你不知道哪些调用方会受影响
多方案选择：当你不确定最佳实现路径时，让 Claude 在 Plan 阶段列出备选方案
团队协作场景：Plan 的输出可以作为技术方案的雏形，分享给同事讨论

如何高效 Review Plan：

看计划时问自己三个问题：
1. 改动的文件范围合理吗？（多了少了？）
2. 每个文件的修改思路对吗？（不是具体代码，而是改的"什么"）
3. 有没有遗漏的边界情况？（错误处理、空值检查、向后兼容性）

Plan mode 的核心价值不是"安全"——Ask 模式也安全——而是让你在 Claude 投入大量 token 执行之前，先用很少的代价（几句对话）校准方向。一次大规模重构如果方向错了，回滚的代价远大于 Plan 阶段的几分钟审阅。

Auto mode

行为：Claude 根据任务的风险评估，自动决定是直接执行还是请你确认。低风险操作（读取文件、搜索代码）直接执行，高风险操作（修改核心文件、执行危险命令）仍然会询问。

这是"信任 Claude 判断力"的模式，也是大多数有经验用户在日常开发中的选择。

Claude 如何评估风险：

Claude 的风险评估并非公开的详细算法，但根据实际使用观察，主要考量以下几个维度：

操作类型：Read << Edit < Write < Bash < Bash(rm/sudo)
文件重要性：配置文件 > 核心业务代码 > 工具函数 > 测试文件 > 文档
改动规模：单文件小改 < 多文件中改 < 跨模块大改
项目上下文：CLAUDE.md 中标记的"注意区域"会影响 Claude 的风险判断

注意：Auto mode 的风险评估不是完美的。Claude 可能低估某个操作的后果（尤其是在它不完全理解业务逻辑的情况下）。使用 Auto mode 的前提是——你会在 Diff 审查区过一遍修改，而不是闭着眼睛 Accept All。

适用场景：

日常开发主力模式：当你已经熟练使用 Claude Code，大多数任务不需要手把手确认
节奏感最好的模式：既不像 Ask 那样频繁打断，也不像 Bypass 那样完全放手

Bypass permissions

行为：Claude 执行一切操作都不需要你的确认——包括修改文件、执行 Shell 命令、删除文件等。

⚠️ 警告：Bypass 模式下，Claude 拥有完全操作权限。一旦你的指令有歧义或 Claude 产生误解，后果会直接生效，没有二次确认的机会。不要在包含生产环境配置、数据库连接、敏感数据的项目中使用此模式。

适用场景（仅限以下条件全部满足时）：

完全信任的隔离环境：测试项目、实验性分支、本地沙箱
你已经深度使用 Claude Code 数月，对它的行为模式有精确的预期
项目有健全的 Git 保护：任何改动都可以通过 git diff 审查，并通过 git reset 回滚
你的指令足够精确：不是说"改进一下代码"，而是"把 src/utils/validator.ts 中的 validateEmail 函数的正则替换为 RFC 5322 标准"

关于"用得最多"：从源材料可以看到，资深用户在熟悉之后会大量使用 Bypass 模式。这不是鲁莽，而是因为：

Git 是最终安全网：Bypass 下改错了，git diff 一看便知，git checkout -- . 一键回滚
时间效率的巨大差异：一次确认 3 秒，一天 50 次操作就是 2.5 分钟被打断。Bypass 让你的思维不被打断
你从"批准者"变成了"审查者"：不再是每步盯着看，而是改完之后统一审查 Diff。这个工作流在很多场景下更高效

但是，如果你还处于以下阶段，请继续使用 Ask 或 Auto：

使用 Claude Code 不足一个月
经常遇到 Claude 做出"出乎意料"的修改
在包含敏感数据的项目中工作
对 Git 的回滚操作还不够熟练

9.2 模式选择策略

五种模式不是平级的选项，而是一条从保守到激进的信任梯度。选择哪种模式，取决于你对 Claude 的信任程度和任务的复杂程度。

场景决策表

场景	推荐模式	原因
第一天使用 Claude Code	Ask	学习 Claude 的行为模式，观察它是如何理解指令和修改代码的
前两周使用	Ask / Plan	Ask 处理常规操作，Plan 处理复杂需求，建立信任
简单重构（单文件、明确目标）	Edit	任务边界清晰，Claude 不太可能做出意外操作，效率优先
批量操作（重命名、格式化、生成测试）	Edit	改动量大但机械，风险低
大规模改动（5+ 文件、架构变化）	Plan	先审方案再执行，避免方向性错误造成大量返工
日常开发（使用一个月以上）	Auto	信任 Claude 的判断力，同时保留对高风险操作的确认
陌生项目 / 陌生语言	Ask	不确定 Claude 会做什么，每次确认是学习过程
快速原型开发	Bypass	速度优先，代码变动频繁，随时可以推翻重来
修复紧急 Bug	Auto / Bypass	根据紧急程度和代码区域的重要性选择
终态（使用三个月以上，完全信任）	Bypass	思维不被打断，改为事后审查 Diff

信任进阶路径

Ask ──→ Auto ──→ Bypass
  │        │
  └──→ Edit ──→ Auto ──→ Bypass
        │
        └──→ Plan（特定场景下长期保留）

第一周：Ask，观察 Claude 的行为
第二到四周：日常用 Auto，复杂任务切 Plan
一至三个月：信任建立后日常用 Bypass，复杂任务仍用 Plan
三个月以上：绝大多数任务用 Bypass，你在 Diff 审查区做最后的把关

这个时间线不是绝对的，关键在于你的主观感受：当你对 Claude 的行为不再感到意外时，就是升级模式的时候。

关键原则

不确定时就选更保守的模式。 一次多余的确认只会耽误几秒，一次错误的不确认可能导致数小时的回滚。模式选择没有"最优解"，只有"当前最合适的解"。

9.3 模型 Effort 设置

Effort（投入度）是 Claude Code 中一个容易被忽视但影响深远的配置项。它控制 Claude 在处理你的请求时投入多少"思考力"。

Effort 的本质

把这理解为 AI 的脑力档位：

低 Effort：Claude 快速判断、快速输出，像一位经验丰富的工程师看到简单问题时的直接反应
高 Effort：Claude 深度分析需求、评估多种方案、考虑边界情况，像在做技术方案设计时的深思熟虑

技术上，Effort 影响的是模型内部的推理预算——包括推理步骤的数量、候选方案的评估深度、输出质量的自我检查程度。

五个等级

Effort 等级	标签	描述	典型响应时间	适用任务
1	极速	最小推理，快速输出	最快	简单问答、变量命名、代码格式调整
2	快速	少量推理	较快	简单代码生成、单文件小改
3	平衡（默认）	标准推理	正常	日常开发、代码重构、Bug 修复
4	深度	增强推理	较慢	复杂业务逻辑、跨模块重构、性能优化
5	极致	最大推理深度	最慢	复杂架构设计、疑难 Bug 排查、安全审计

Effort 的代价

更高的 Effort 带来三个代价：

响应时间增加：Level 5 的响应时间可能是 Level 3 的 2-3 倍
Token 消耗增加：更多的推理意味着更多的输出 token，直接转化为成本
上下文占用增加：更长的推理过程占用更多上下文窗口

所以 Effort 不是越高越好——处理"把变量名从 data 改成 userList"这种需求，Level 5 纯属浪费。

何时提升 Effort

以下信号提示你应该提升 Effort：

Claude 的方案缺少边界情况考虑（空值处理、异常路径、并发安全）
Claude 反复修改同一个区域多次才改对
你发现需要主动补充很多上下文，Claude 才会注意到某些约束
任务是架构级别的设计，而非简单的代码编写
你在处理一个之前 Claude 没有正确理解的问题

Effort 与模型的配合

Effort 的效果受模型能力影响：

场景	推荐组合
日常开发	DeepSeek V4 Flash + Effort 3
高质量代码生成	DeepSeek V4 Pro + Effort 4
复杂架构设计	Claude Opus 4.7 / DeepSeek V4 Pro[1m] + Effort 5
简单批量操作	DeepSeek V4 Flash + Effort 1-2

核心原则：任务越复杂、影响面越大、容错率越低，Effort 就应该越高。反之，机械性、重复性、低风险的任务，用低 Effort 反而更高效。

9.4 思考模式

思考模式（Thinking Mode）是 Claude Code 的一个开关选项，控制 Claude 是否在执行操作之前向你展示它的推理过程。

思考模式是什么

默认情况下，Claude 直接执行——你说"改这个函数"，它就开始改。开启思考模式后，Claude 会先输出一段分析：

我需要理解当前函数的逻辑：
1. 先从输入参数入手，看看有哪些可能的输入路径
2. 然后检查现有的错误处理是否覆盖了所有分支
3. 最后确认修改方案不会影响调用方
...

基于以上分析，我的修改方案是：...

然后才开始实际执行。这段思考不是"装饰"——它是 Claude 实际用于决策的推理过程。

什么时候开启

复杂 Bug 调试：你需要理解 Claude 的诊断思路，而不仅仅是最终结论
架构级决策：了解 Claude 为什么在方案 A 和 B 之间选择了 B
学习 Claude 的思维方式：通过观察推理过程，你能更好地掌握如何给 Claude 下指令
验证 Claude 是否真正理解了需求：如果思考过程暴露了理解偏差，你可以在它执行之前纠正

什么时候关闭

简单任务：思考过程增加不必要的延迟和 token 消耗
明确指令：你说"把这个 console.log 删掉"，不需要 Claude 先分析日志输出的重要性
高频交互：每次操作都要等几秒的思考输出，会拖慢节奏
日常开发主力模式：大多数情况下，你更关注结果而非过程

思考模式与 Plan mode 的区别

容易混淆，但它们服务于不同目的：

维度	思考模式	Plan mode
输出内容	Claude 的内部推理过程	具体的修改计划
发生时机	每次操作之前	整个任务开始之前
你的角色	观察者	审批者
适用粒度	单次操作级别	整个任务级别
能否干预	不能直接修改，只能看到	可以修改计划、调整方案

两者可以叠加使用：Plan mode 下开启思考模式，你既能了解 Claude 为什么制定了这样的计划（思考模式），又能对计划做出调整（Plan mode）。

9.5 / 命令面板

Claude Code 的 / 命令面板是操作中心——不需要翻设置页，直接在对话输入框输入 / 即可呼出。

呼出方式

在侧边栏对话输入框中输入 /，VSCode 会弹出下拉菜单，列出所有可用命令。你可以用键盘上下选择并按 Enter 确认，也可以继续输入命令名称来筛选。

关键命令

命令	功能	使用频率
`Switch Model...`	切换当前使用的模型（Haiku / Sonnet / Opus）	中
`Adjust Effort`	调整 Effort 等级（1-5）	中
`Toggle Thinking`	开启/关闭思考模式	低-中
`/clear`	清空当前对话，开始新话题	高
`/compact`	压缩对话上下文，保留关键信息	中（详见第 11 章）
`Manage Plugins`	打开插件管理界面	低（详见第 16 章）

与 cc-switch 的配合

/ 菜单中的模型切换和 cc-switch 的模型切换是两种方式，各有适用场景：

cc-switch：彻底切换模型服务商和模型映射（比如从 DeepSeek 切换到 Anthropic），适合"今天用 DeepSeek 开发，晚上用 Opus Review"
/ 菜单 Switch Model：在 cc-switch 配置的当前模型映射下，快速在 Haiku / Sonnet / Opus 三个档位之间切换

日常使用中，模型映射（大方向）通过 cc-switch 搞定，模型档位（微调）通过 / 菜单搞定。

9.6 个人推荐设置

经过大量实践，以下 VSCode 配置项是我的推荐设置。每一个都有明确的理由。

完整配置

json

{
  "claudeCode.preferredLocation": "sidebar",
  "claudeCode.enableNewConversationShortcut": true,
  "claudeCode.useCtrlEnterToSend": true,
  "claudeCode.allowDangerouslySkipPermissions": true,
  "claudeCode.disableLoginPrompt": true,
  "claudeCode.initialPermissionMode": "bypassPermissions"
}

逐项解释

claudeCode.preferredLocation: "sidebar"

将 Claude Code 面板固定在侧边栏（而非弹出式窗口或终端面板）。侧边栏的好处：

与文件树、源代码在同一视图中，切换文件时对话不中断
对话面板有足够的竖向空间，长对话历史可以滚动查看
Diff 视图可以在对话区展开，不需要跳转到新标签页

claudeCode.enableNewConversationShortcut: true

启用 Cmd+N（macOS）/ Ctrl+N（Windows）快捷键来快速创建新对话。当你同时处理多个独立任务时（比如一边做功能开发，一边临时帮忙排查别人的 Bug），新会话能避免上下文污染。

claudeCode.useCtrlEnterToSend: true

这是初学者最应该开启的选项。默认情况下，Enter 发送消息，Shift+Enter 换行。当你给出多行指令时——比如贴一段代码并要求 Claude 修改——很容易忘记 Shift 而意外发送不完整的消息。

开启此选项后：Enter 换行，Ctrl+Enter 发送。你可能需要一两小时适应，但之后会发现它能防止无数次误发送。就像写邮件时你不会用 Enter 键发送一样——格式复杂的消息需要先组织好，再发送。

claudeCode.allowDangerouslySkipPermissions + claudeCode.initialPermissionMode: "bypassPermissions"

这两个选项配合使用，启动 Claude Code 时直接进入 Bypass 模式。

⚠️ 这些选项不适合所有人。 仅推荐满足以下条件的用户启用：
使用 Claude Code 超过两个月，对行为模式有充分信任
项目使用 Git 管理，且你熟练使用 git diff / git reset 回滚
工作项目不涉及生产环境直接操作
如果你还在学习阶段，让 initialPermissionMode 保持默认的 "askBeforeEdit"，这是更安全的选择。

claudeCode.disableLoginPrompt: true

如果你通过环境变量（ANTHROPIC_AUTH_TOKEN）或 cc-switch 配置好了认证信息，每次启动时弹出的登录界面纯属多余。这个选项直接跳过它，冷启动更快。

初学者 vs 资深用户推荐对比

配置项	初学者推荐	资深用户推荐
`preferredLocation`	`"sidebar"`	`"sidebar"`
`enableNewConversationShortcut`	`true`	`true`
`useCtrlEnterToSend`	`true`（强烈推荐）	`true`
`allowDangerouslySkipPermissions`	`false`	`true`
`disableLoginPrompt`	`false`	`true`
`initialPermissionMode`	`"askBeforeEdit"`	`"bypassPermissions"`

核心差异只在权限相关配置上——这恰好印证了本章的主题：模式的选择取决于你的信任程度，而信任只能通过时间积累。

9.7 模式切换实战

理解概念是一回事，在日常工作流中灵活切换是另一回事。以下是一个典型一天中的模式切换流程。

早上的日常任务

场景：开启一天的工作，需要处理几个小任务
- 模式：Auto
- Effort：3（默认）
- 思考模式：关闭
- 理由：小任务不需要深度思考，Auto 在安全性和效率之间取得平衡

开始一天时，你通常会浏览待办事项，处理一些简单任务：修个小 Bug、调整样式、更新依赖。这些任务边界清晰，Auto 模式让 Claude 在低风险操作上自动执行，只在必要时询问。

遇到复杂需求时

场景：需要重构一个数据查询模块，涉及 8 个文件，影响前端展示和后端 API
- 模式：切换到 Plan mode
- Effort：4
- 思考模式：开启
- 理由：涉及面广，先审方案。提高 Effort 让 Claude 考虑更多边界情况，
  思考模式帮你理解它的设计决策

典型操作流程：

在 / 菜单中选择 Plan mode
通过 / 菜单将 Effort 调整为 4，开启思考模式
向 Claude 描述需求："重构 src/services/queryService.ts，将当前同步查询改为支持分页和缓存的异步查询，确保不影响现有的 12 个调用方"
审阅 Claude 生成的计划，重点关注：调用方的兼容性方案、缓存失效策略、错误处理
调整计划："第二步中，用乐观更新而不是在缓存失效时阻塞请求"
确认计划，Claude 进入执行阶段

快速原型阶段

场景：快速搭建一个新功能的概念验证，代码随时可能推倒重来
- 模式：Bypass
- Effort：1-2
- 思考模式：关闭
- 理由：速度优先，代码生命周期短，不需要深度推理

这是 Bypass 模式的最佳舞台。冲刺速度，Claude 不断生成代码，你在 Diff 查看区快速扫一眼就 Accept。思路不被打断，节奏流畅。

一天结束时的审查

场景：回顾一天的工作，检查所有改动是否合理
- 模式：Ask（或保持 Auto 但提高警惕）
- Effort：4
- 理由：审查需要深度分析，不能错过潜在问题

在一天结束时，可以用 Claude 帮你做自我审查：

请审查今天的所有 git 改动（git diff HEAD~1），重点关注：
1. 是否有潜在的 bug 或边界情况遗漏
2. 是否引入了性能问题
3. 代码风格是否与项目一致
4. 是否有可以进一步简化的地方

Claude 在 Ask/Auto 模式下会逐文件分析，而你可以在 Diff 视图中对照审查。这个习惯能显著减少"第二天发现昨天写了个 Bug"的情况。

紧急修复

场景：生产环境报告了一个 Bug，需要快速定位和修复
- 模式：Auto 或 Bypass（取决于你对代码区域的熟悉程度）
- Effort：4-5
- 思考模式：开启
- 理由：速度快但不能草率，高 Effort 提升诊断准确性

紧急修复中，你需要速度也需要准确性。先用高 Effort 快速定位问题（思考模式帮你验证 Claude 的诊断逻辑是否正确），然后用 Bypass 快速应用修复，最后切回 Auto 确认修复不引入新问题。

9.8 本章小结

本章覆盖了影响 Claude Code 行为的三个核心机制：

五种权限模式（Ask → Edit → Auto → Plan → Bypass）：从步步确认到完全自主，是信任的梯度。选择保守的模式不是因为"不信任 Claude"，而是因为"你还在了解它"
Effort 等级（1-5）：控制 Claude 投入的思考深度。不是越高越好——简单任务用高 Effort 就是浪费
思考模式：决定你是否能看到 Claude 的推理过程。对学习有用，对速度有损

这三者不是独立开关，而是协同工作的。一个典型的组合：日常开发用 Auto + Effort 3 + 思考关闭，复杂重构用 Plan + Effort 4/5 + 思考开启，快速原型用 Bypass + Effort 1/2 + 思考关闭。

核心要点

模式选择没有标准答案：取决于你的经验、任务的复杂度和项目的风险等级
信任是逐步建立的：Ask → Auto → Bypass 这个路径不是形式，而是你在实践中积累对 Claude 行为的直观理解
Git 是终极安全网：无论用什么模式，git diff 在操作后过一遍，这是不可省略的习惯
Effort 按需调整：默认 3 对 80% 的任务足够，剩下的 20% 才需要 4 或 5
useCtrlEnterToSend 是新人必备：这个设置能防止无数次误发送

从基础到进阶

恭喜你完成了基础篇的学习。在第二篇的五个章节中，你掌握了 Claude Code 的四大核心能力（对话、编辑、终端、Git）和行为控制机制（模式、Effort、思考模式）。这些是你每天都会用到的"基本功"——它们是 Claude Code 使用的 80%。

从下一章开始，我们将进入第三篇：进阶篇。进阶篇不再关注"怎么用"，而是关注"为什么这样用"和"怎么用得更好"。你将深入理解 Claude Code 的内部运作机制（Agent Loop 完整流程、工具系统详解）、掌握上下文管理的技巧、学习编写和优化 CLAUDE.md、以及精通配置体系——这些是区分"会用 Claude Code"和"用好 Claude Code"的关键。

准备好迎接更深层的理解了——第 10 章将带你走进 Claude Code 的工作原理，拆解你每次对话背后发生的完整故事。

第 9 章：模式切换 ​

9.1 五种权限模式详解 ​

Ask before edit（默认） ​

Edit automatically ​

Plan mode ​

Auto mode ​

Bypass permissions ​

9.2 模式选择策略 ​

场景决策表 ​

信任进阶路径 ​

关键原则 ​

9.3 模型 Effort 设置 ​

Effort 的本质 ​

五个等级 ​

Effort 的代价 ​

何时提升 Effort ​

Effort 与模型的配合 ​

9.4 思考模式 ​

思考模式是什么 ​

什么时候开启 ​

什么时候关闭 ​

思考模式与 Plan mode 的区别 ​

9.5 / 命令面板 ​

呼出方式 ​

关键命令 ​

与 cc-switch 的配合 ​

9.6 个人推荐设置 ​

完整配置 ​

逐项解释 ​

初学者 vs 资深用户推荐对比 ​

9.7 模式切换实战 ​

早上的日常任务 ​

遇到复杂需求时 ​

快速原型阶段 ​

一天结束时的审查 ​

紧急修复 ​

9.8 本章小结 ​

核心要点 ​

从基础到进阶 ​

第 9 章：模式切换

9.1 五种权限模式详解

Ask before edit（默认）

Edit automatically

Plan mode

Auto mode

Bypass permissions

9.2 模式选择策略

场景决策表

信任进阶路径

关键原则

9.3 模型 Effort 设置

Effort 的本质

五个等级

Effort 的代价

何时提升 Effort

Effort 与模型的配合

9.4 思考模式

思考模式是什么

什么时候开启

什么时候关闭

思考模式与 Plan mode 的区别

9.5 / 命令面板

呼出方式

关键命令

与 cc-switch 的配合

9.6 个人推荐设置

完整配置

逐项解释

初学者 vs 资深用户推荐对比

9.7 模式切换实战

早上的日常任务

遇到复杂需求时

快速原型阶段

一天结束时的审查

紧急修复

9.8 本章小结

核心要点

从基础到进阶