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 做
