有一个情况我遇到过不止一次。
我让 Claude Code 帮我重构一个功能，直接说「把这个模块改成支持多租户」。Claude 立刻开始动——读文件、修改、生成新代码。过了十分钟，它告诉我改完了，一共动了八个文件。
我开始 review。看到第三个文件的时候，我意识到它理解的「多租户」和我想的不是一回事。它走了一个我不打算走的方向，八个文件的改动，要么全撤，要么花同样多的时间修正。
这不是 Claude 不够聪明。是我没有在它动手之前，确认它理解的方向对不对。
你以为直接动手最快，其实它改了一堆，方向是错的。
什么是 Plan Mode
Plan Mode 是 Claude Code 的一个工作模式，让 Claude 在执行之前先输出一份完整的实现计划，等你确认之后再开始动手。
进入 Plan Mode 有两种方式：
方式一：使用 /plan 命令
在 Claude Code 里输入 /plan，之后描述你的任务。Claude 会切换到规划模式，输出一份实现计划，但不执行任何操作，直到你明确说「开始执行」或「继续」。
方式二：在提示词里直接要求
不用命令，直接说「先给我一个实现方案，不要动代码，等我确认再做」。效果类似，但没有 /plan 模式那么结构化。
Plan Mode 里，Claude 会输出：
- 它对任务的理解（你可以在这里发现误解）
- 需要修改的文件列表（你可以在这里发现遗漏或多余）
- 具体的实现步骤（你可以在这里发现方向问题）
- 潜在的风险和权衡（你可以在这里发现你没想到的问题）
全部确认没问题，再让它执行。
为什么「先规划」反而更快
很多人觉得加一步规划是在浪费时间。
实际上刚好相反。
直接动手的风险是：Claude 可能理解偏了你的需求，或者选了一个你不打算走的实现路径。发现问题之前，它可能已经改了十个文件。这时候你有两个选择：全部撤销重来，或者花时间修正它走偏的部分。两个都贵。
先规划的成本是：多花两分钟看它的计划。发现方向问题，在零行代码被改动的时候就纠正，代价极低。
在任务开始之前纠正方向，永远比在任务进行到一半时纠正便宜。
什么时候用 Plan Mode
不是所有任务都需要 Plan Mode。
适合用的场景：
- 涉及多个文件的改动（超过 3 个文件）
- 架构级别的变更（改数据结构、改接口、改模块边界）
- 你对实现方式有明确偏好，但没有详细描述的任务
- 你不确定 Claude 是否理解了你的意图
- 改动风险高、回滚成本高的场景
不需要用的场景：
- 单文件的小改动（修一个 bug、改一个函数）
- 你已经把实现步骤描述得很详细
- 低风险、容易撤销的任务
粗略判断：改动文件超过三个，先 /plan。其他情况直接做。
规划阶段怎么审
Plan Mode 输出计划之后，不要直接说「开始」。花两分钟检查这三个地方：
一：它对任务的理解是否和你一致
让它在计划开头复述一遍它理解的任务目标。如果复述和你想的不一样，在这里纠正，比在执行到一半时纠正便宜得多。
二：文件列表是否合理
会动哪些文件，不会动哪些文件。有没有它漏掉的文件，有没有它不应该动但打算动的文件。
三：有没有你不想走的实现路径
它选的方案和你心里预期的一致吗？如果你有偏好，在计划阶段说，比在代码写完了再说省事。
一个进阶用法：让 Claude 给多个方案
对于架构决策类任务，可以在 Plan Mode 里让 Claude 给你两到三个实现方案，并说明每个方案的权衡。
/plan
我需要给这个 API 加缓存。给我两到三个方案，说明各自的优缺点和适用场景，不要直接选，让我来决定。
Claude 会输出多个方案的对比，你选定一个，再让它执行那个方案。
这个用法特别适合：你知道要做什么，但不确定怎么做最合适的情况。让 Claude 帮你把选项摆出来，你做决策，它执行。
下次遇到需要改多个文件的任务，试一次 /plan。就一次。
看它输出的计划，你大概率会发现至少一个「如果它直接做，我可能要花时间修正」的地方。
你用 Claude Code 遇到过「改完了发现方向不对」的情况吗？欢迎评论区说说，这种情况比大多数人承认的要常见。
这是「Claude Code 那些没人告诉你的用法」第六篇。关注不迷路。
更多深度内容与完整文章，欢迎关注我的微信公众号：SamLai 效率研习社
主要分享：
AI 编程与开发效率
技术趋势与工程思考
实用工具与工作流
