【Claude】Claude Code Plan 模式完全指南先规划再执行让 AI 编程不再失控前言你有没有遇到这种情况让 Claude Code 重构一个模块它直接开始修改文件改到一半你发现它的方向完全不对但代码已经被修改得一团糟想回滚也需要费一番功夫或者让 Claude 添加一个新功能它热情高涨地改了 20 个文件但其中有 15 个完全不需要动——而且改错了 3 个关键文件这些问题的根源是让 AI 直接执行而不是先让它规划。Plan 模式计划模式正是 Claude Code 为解决这类问题而专门设计的工作模式。在 Plan 模式下Claude 只读取和分析不做任何修改直到你确认计划后才开始执行。本文从原理到实战带你全面掌握 Plan 模式的使用方法。一、三种工作模式对比1.1 Claude Code 的三种模式Claude Code 有三种核心工作模式通过ShiftTab循环切换模式名称行为适用场景Default默认模式每次文件修改或命令执行都需要你手动确认日常开发需要精确控制Auto-Accept自动接受模式文件修改自动执行Shell 命令仍需确认任务明确、信任 Claude 的场景Plan计划模式只读不执行任何修改先展示计划复杂任务、大规模变更左下角状态栏会显示当前模式◆ Default◆ Auto-Accept◆ Plan1.2 为什么需要 Plan 模式没有 Plan 模式的典型事故你帮我把项目从 JavaScript 迁移到 TypeScript ClaudeDefault 模式 修改 package.json → 你确认 创建 tsconfig.json → 你确认 修改 src/app.js → src/app.ts → 你确认 修改 src/utils.js → src/utils.ts → 你确认 ... 继续修改 50 个文件 你确认了 20 次后发现它用的是 CommonJS 而你想要 ESM 但前面 20 个文件已经按错误的方向改完了有 Plan 模式的正确流程你帮我把项目从 JavaScript 迁移到 TypeScriptPlan 模式 Claude 分析后展示计划 1. 更新 package.json添加 TypeScript 依赖 2. 创建 tsconfig.jsonESM 配置 3. 创建类型声明文件 src/types.d.ts 4. 批量重命名 .js → .ts47 个文件 5. 修复类型错误预计 23 处 方案说明使用 ES Modules不是 CommonJS 迁移顺序工具函数 → 服务层 → API 层 → 入口文件 你发现方向正确好的继续执行 Claude开始执行...二、进入 Plan 模式的三种方式方式 1ShiftTab 切换推荐在 Claude Code 交互界面中按ShiftTab循环切换模式Default → Plan → Auto-Accept → Default...底部状态栏实时显示当前模式。方式 2启动时直接进入 Plan 模式claude --plan # 或 claude -p # 注意这是 --plan 的短参数与 --print 不同方式 3对话中用 /plan 命令# 在交互模式中输入 /plan这会切换到 Plan 模式后续的所有操作只分析不执行直到你再次切换回去。三、Plan 模式的工作流程3.1 标准工作流步骤 1进入 Plan 模式 按 ShiftTab确认左下角显示 Plan 步骤 2描述任务需求 不需要特别说明 请先规划Plan 模式下 Claude 自动只分析 步骤 3等待 Claude 的分析报告 Claude 会 - 读取相关文件 - 分析影响范围 - 识别依赖关系 - 输出详细计划 步骤 4审核计划 确认 - 修改文件的范围是否合理 - 执行顺序是否正确 - 有没有遗漏重要文件 - 方案方向是否符合你的预期 步骤 5反馈或确认 若有问题直接告诉 Claude 修改计划 若满意按 ShiftTab 切回 Default 或 Auto-Accept说执行 步骤 6执行 Claude 按确认的计划执行3.2 计划报告的典型格式一份好的 Plan 模式输出通常包含## 任务分析 **需求理解** [复述你的需求确认理解正确] **影响范围分析** - 需要修改的文件N 个[列表] - 需要新建的文件M 个[列表] - 可能影响的相关模块[列表] **执行步骤** 1. [第一步] - 原因说明 2. [第二步] - 原因说明 3. [第三步] - 原因说明 **潜在风险** - [风险点1] - 处理方案 - [风险点2] - 处理方案 **预估工作量** N 个文件约 M 处修改 是否按此计划执行如有调整建议请指出。四、适合用 Plan 模式的场景场景 1大规模重构适合的原因重构往往涉及多文件联动错误方向的修改成本极高适合用 Plan 模式的重构任务 ✅ 从 JavaScript 迁移到 TypeScript ✅ 更换框架如 Express → Fastify ✅ 数据库层抽象直接查询 → Repository 模式 ✅ 模块化拆分单体 → 微服务准备 ✅ 依赖升级React 17 → React 18API 变更多实际对话示例你Plan 模式把 src/utils/ 目录下的所有工具函数从 CommonJSrequire/module.exports 改为 ES Modulesimport/export保持功能不变 Claude 分析 发现 src/utils/ 下有 12 个文件 其中有 3 个文件被其他模块 require修改后需要同步更新调用方 执行计划 1. 修改 src/utils/ 的 12 个文件改 require/exports 语法 2. 更新调用这些文件的 8 个模块改 require 为 import 3. 更新 package.json添加 type: module 4. 检查是否有动态 require()如有需要改为 import() ⚠️ 风险src/utils/config.js 中有 __dirname 和 __filename 的使用 ES Modules 不支持这两个变量需要改用 import.meta.url 你计划看起来合理但第3步先不做我想分开提交先只改 utils/ 和调用方 Claude好的去掉第3步后执行1 → 2完成后请单独处理 package.json 的修改 你ShiftTab 切回 Default按修改后的计划执行场景 2高风险区域的修改适合用 Plan 模式的高风险区域 ✅ 认证/授权模块出问题影响所有用户 ✅ 数据库 migration 文件不可逆操作 ✅ 支付/金融相关逻辑 ✅ 基础设施配置Dockerfile、k8s manifest ✅ 公共 API 接口影响所有调用方场景 3不熟悉的代码库当你接手别人的代码不清楚修改影响范围时你Plan 模式我需要修改用户登录逻辑添加双因素认证支持 Claude 分析 当前登录流程涉及以下文件 - src/auth/login.py主要认证逻辑 - src/auth/jwt.pytoken 生成 - src/middleware/auth_check.py认证中间件 - src/models/user.py用户模型 发现隐藏依赖 - src/tests/test_auth.py 中有 15 个测试覆盖当前登录流程修改后需要更新 - src/docs/api.yaml 中的登录 API 文档需要同步更新 建议的修改方案...不使用 Plan 模式你可能根本不知道还有测试文件和文档需要同步更新。场景 4需要比较方案你Plan 模式我需要给这个 API 添加缓存有哪些方案 Claude 分析并输出两个方案 方案A内存缓存简单 - 优点不需要外部依赖延迟极低 - 缺点多进程/多机器无法共享进程重启缓存丢失 - 修改文件仅 src/api/users.py 方案BRedis 缓存推荐 - 优点跨进程共享支持持久化功能完整 - 缺点需要 Redis 服务多了一个外部依赖 - 修改文件src/api/users.py docker-compose.yml .env.example 你选方案B执行 Claude切换模式后开始执行方案B五、Plan 模式与任务系统的配合Claude Code 内置了任务跟踪系统Tasks与 Plan 模式完美配合5.1 将计划转换为任务列表你Plan 模式规划一下用户管理模块的开发包括注册、登录、修改资料 Claude 生成任务列表 任务列表用户管理模块 ┌─────────────────────────────────────────────┐ │ ○ 1. 设计用户数据库 Schema │ │ ○ 2. 创建 UserModel依赖任务1 │ │ ○ 3. 实现注册 API依赖任务2 │ │ ○ 4. 实现登录 API依赖任务2 │ │ ○ 5. 实现修改资料 API依赖任务2 │ │ ○ 6. 编写认证中间件依赖任务4 │ │ ○ 7. 补充单元测试依赖任务3,4,5 │ └─────────────────────────────────────────────┘ 按 CtrlT 可查看任务状态5.2 跨会话持久化任务# 设置任务列表 ID下次会话可以恢复 export CLAUDE_CODE_TASK_LIST_IDuser-module-001 # 下次会话中 claude # 输入 /tasks可以看到之前的任务列表并继续六、Plan 模式的进阶技巧6.1 要求 Claude 给出多个方案你Plan 模式为这个查询添加缓存请给出3种方案并比较优劣 Claude 会输出 方案A[详情] 方案B[详情] 方案C[详情] 推荐方案方案B原因是...6.2 要求 Claude 识别风险你Plan 模式帮我分析一下这个重构方案有哪些潜在风险 Claude 输出 高风险...必须处理 中风险...建议处理 低风险...可以接受6.3 分阶段规划大型任务对于非常大的任务先规划阶段再在每个阶段用 Plan 模式细化第一次Plan 模式把整个迁移任务分成几个阶段 Claude 阶段1基础设施准备1天 阶段2核心模块迁移3天 阶段3周边模块迁移2天 阶段4测试与修复1天 第二次Plan 模式详细规划阶段1的具体步骤 Claude详细的第一阶段计划...七、常见问题排查QPlan 模式下 Claude 仍然修改了文件可能原因模式切换不成功底部状态栏仍显示 Default某些版本的 Claude Code 中 Plan 模式行为略有差异解决方案再次按 ShiftTab 确认状态栏显示 Plan或启动时使用claude --plan强制进入QPlan 报告太简单没有详细说明影响范围解决方案在提问时明确要求你请先进行全面的影响范围分析列出所有会被修改的文件 评估潜在风险然后再给出执行计划QPlan 模式下速度很慢解释这是正常的。Plan 模式下 Claude 会主动读取更多文件进行分析比 Default 模式耗时更长。这是深入分析的代价换来的是更准确的计划。优化建议明确指定 Claude 应该分析哪些文件避免无目的地全局扫描你Plan 模式分析 src/auth/ 目录不需要看其他目录 规划添加双因素认证的步骤八、Plan 模式 vs 其他控制手段的比较方法控制粒度适用场景Plan 模式任务级执行前规划不确定方案、高风险变更Default 模式文件级每次操作确认已知方向想逐步审查Hooks/PreToolUse命令级特定命令拦截永久性安全规则/rewind操作级回退已执行操作执行后发现错误最佳实践对于不确定的复杂任务先用 Plan 模式确认方向确认后再切换到 Default 模式逐步审查执行。总结Plan 模式是 Claude Code 从AI 工具升级为AI 协作者的关键能力。核心使用原则大改动必用 Plan 模式任何涉及 5 文件的修改先规划再执行高风险区域必用 Plan 模式认证、支付、数据库 migration 等接手陌生代码库时必用 Plan 模式先让 Claude 梳理影响范围计划有问题时在 Plan 模式内反复调整直到满意再切换执行把控节奏不让 AI 无节制地自由发挥——这是使用 AI 编程工具最重要的心智模型之一。