Claude Code Plan Mode 实战：什么时候用、怎么退出、和 Fast Mode 的取舍

Claude Code 用顺了之后，你会发现一个反直觉的现象：最贵的不是模型不会写代码，是它自信满满地写错了。Plan Mode 的存在就是为这件事——在动手之前，让 Claude 先把要做的事完整说一遍，等你确认再开工。但很多人用 Plan Mode 用得很别扭，要么开了等于没开（Plan 本身就是糊弄过去），要么不该开的也开（小修改也跑一轮 Plan，效率反过来低）。

这篇文章不讲”Plan Mode 是什么”——这点官方文档已经够清楚。讲的是实战中怎么判断该不该用、Plan 写出来怎么读、ExitPlanMode 之后还能反悔吗、什么时候应该改用 Fast Mode。

Plan Mode 解决的真问题

直接说结论：Plan Mode 适合实现路径不止一条 + 改动会跨多个文件 + 你不愿事后大改的任务。

反过来，下面这几种任务不应该开 Plan Mode：

单文件 typo 修复
已经讨论清楚的小改动（比如刚跟 Claude 商量完，让它执行）
探索性查问（”这个项目用了什么数据库”——这是研究，不是实现）
你已经写好详细规格说明的任务（Plan 会重复你已经决定的事）

那为什么大家会习惯性”什么都用 Plan Mode”？因为它有个心理安全感——觉得”先看一眼计划”总不会错。但实际上 Plan Mode 有成本：

会话拉长 —— Plan 本身就要 1-3 千 token，加上你审阅时间，整个任务时间至少多 2 倍
Claude 在 Plan 阶段会自我设限 —— Plan 里写的是”我打算做 X”，实际写代码时模型可能发现需要改 Y 才能让 X 成立，这种动态发现在 Plan Mode 里被压抑
Plan 通过后改方案变贵 —— ExitPlanMode 之后再改主意，等于推翻一个已经”批准”的方案，沟通成本大

什么任务真正受益于 Plan Mode

按我的实战经验，下面 4 类任务开 Plan Mode 净收益最大：

1. 跨文件重构

例：把一个组件从 React 类组件改成 hooks，涉及 5+ 个相关 hook 文件、props 类型变化、测试更新。

为什么 Plan 有用：模型容易在第一个文件写得很好，但忘记同步更新依赖它的文件。Plan 阶段强迫它先列出所有受影响的文件，你能在动手前补上”还有 utils/legacy-helper.ts 也用到了这个 prop”。

2. 引入新依赖 / 新模式

例：在一个目前没用过的项目里第一次引入 zod 做 schema 验证。

为什么 Plan 有用：这种任务有路径选择——zod 可以放在 API 层、可以放在数据层、可以贯穿全栈；schema 可以集中放一个 schemas/ 目录、也可以跟随业务模块。Plan 阶段你可以对照 Plan 提的方案，决定”我要哪种”。

3. 修复需要先确认根因的 bug

例：用户报”上传大文件 30 秒后超时”。Claude 第一反应可能是”加大超时配置”——但根因可能是 chunk 上传缺失重试、或者 nginx buffer 不够大。

为什么 Plan 有用：Plan Mode 的 prompt 会让模型先检查代码再下判断。你能看到”它认为根因是什么”，发现判断错了立刻打住，不用等代码写完才发现修错地方。

4. 对外接口变更

例：API endpoint 改字段、共享组件改 props 签名、函数改返回值类型。

为什么 Plan 有用：这类改动会传染到调用方。Plan 强制列出所有调用方，你能确认”是不是真的所有调用方都要跟着改”，避免改了一半留个孤儿调用。

Plan Mode 在做什么

Plan Mode 是 Claude Code 的一个工具状态，触发后：

模型只能用”读”类工具（Read / Glob / Grep / WebFetch 等）
不能用 Bash 写 / Edit / Write
完整看完代码 + 探索完任务后，模型必须调用 ExitPlanMode 输出计划
用户审 Plan，批准后才解锁写工具

注意一个细节：Plan Mode 不是简单的”延迟执行”——它是”用受限工具做完整研究”。模型在 Plan Mode 下看的代码、查的文档、跑的命令，都属于”上下文积累”。批准之后写代码，是带着这些上下文去写的，质量比”直接开干”高。

ExitPlanMode 之后怎么办

ExitPlanMode 之后会进入正常工作模式，模型按 Plan 写代码。这时候有 3 个常见问题：

问题 1：Plan 通过了但写到一半发现不对

这种情况比想象中常见。Plan 里说”先改 fileA 再改 fileB”，但写 fileA 时发现 fileB 的改动会让 fileA 的方案不成立——典型的”动态发现”。

正确处理方式：

✅ 让 Claude 直接说出来——“我刚才计划 X，但实际写时发现 Y，我建议改成 Z”
❌ 不要让它”硬着头皮按 Plan 走”——结果是代码能跑但不合理

实战上你可以在 CLAUDE.md 写：

## Plan Mode 偏离
执行 Plan 时如发现 Plan 的某一步在实际代码里不成立或会引入新问题，立刻停下并说明：
- Plan 这一步说要做 X
- 实际上 X 会导致 Y
- 建议改成 Z
等用户确认再继续。

这一段 Claude 会按部就班遵守。

问题 2：Plan 通过后想加新需求

类似”原本只是改 A，看到 Plan 后我想顺便改 B”。

正确处理方式：

如果 B 是同一类改动，告诉 Claude”也加上 B”，它会自己更新心智模型
如果 B 是另一个独立任务，结束当前会话，新开一个——不要让两个任务的上下文互相污染

问题 3：Plan 完整执行后发现要回退

这种情况要么是 Plan 本身判断错（根因诊错），要么是用户中途改了主意。回退到 Plan Mode 之前的状态，最稳的做法是 git 上回退而不是让 Claude 反向修改——AI 反向修改容易把”恢复到原状”做成”改成另一种新状态”。

Plan Mode vs Fast Mode：怎么选

Claude Code 还有个 Fast Mode（/fast），跟 Plan Mode 看起来反向但不是对立：

维度	Plan Mode	Fast Mode	默认
模型	主模型	主模型（更快输出）	主模型
工具限制	仅读	全部	全部
适合任务	高风险 / 大改 / 需审计	已确认方案 / 小改动 / 重复任务	中等任务
节奏	慢深	快连	中

实战决策：

早上接到一个新任务 → Plan Mode（先想清楚再动手）
已经讨论完方案准备执行 → Fast Mode（不要再让模型重思考）
批量做同类小修复（比如全站 typo） → Fast Mode（重复任务不需要每次重新规划）
发现 bug 不知道根因 → Plan Mode（先诊断）
跟用户对话中临时小改 → 默认（保留对话节奏）

很多人误把 Plan Mode 当”严肃任务专用”、Fast Mode 当”敷衍模式”。但 Fast Mode 的真实定位是”我已经付清思考成本了，省时执行”——用对了反而专业。

4 类典型场景对照

下面是我自己最常遇到的 4 类场景，对应做法：

场景 A：用户报 bug，根因不明确

✅ Plan Mode → 让 Claude 先查代码、列假设、按可能性排序
❌ 不要直接开干，bug 修错位置比不修更糟

场景 B：你刚跟 Claude 讨论清楚做法，让它执行

✅ Fast Mode → 已经付了讨论成本，让它快速产出
❌ Plan Mode 会让 Claude 重述讨论结果，浪费时间

场景 C：跨多文件的一次性重构

✅ Plan Mode → 让它先列影响面，你过一遍再批准
❌ 默认模式容易漏文件

场景 D：批量做小修复（比如改 30 个 typo）

✅ Fast Mode → 重复机械工作不要每次 plan
❌ Plan Mode 在这种任务里反而拖累

跟 Skills 的关系

如果你已经在用 Claude Skills 体系，Plan Mode 和 Skill 是互补的：

Skill 解决”任务流程标准化”——同一类任务每次按一样的步骤跑
Plan Mode 解决”任务个性化判断”——这次的任务和上次不同，要先看清

实战上有个组合用法：写一个 commit-readiness skill 用 Fast Mode 跑（流程固定）；用一个 bug-triage skill 在内部强制开 Plan Mode（每个 bug 都要先诊断）。skill description 里加一句 “Always enter plan mode before proposing fixes”，模型就会按这套来。