用好 Claude Code 的 Plan 模式：让 AI 先想清楚再动手

本文是《Claude Code 实战》系列第 3 篇。第 2 篇建立了"喂上下文 → 定目标 → 执行 → 审查"的核心工作流，结尾留了一句——“要让它改得准，关键一步是让它先想清楚”。本篇把这一步讲透。

---

改了 5 个文件，发现一开始方向就错了

重构一个支付模块的错误处理。你直接让 Claude Code 动手，不到两分钟它改完了——路由、中间件、service 层、测试文件全改了。代码看着没问题。

然后你发现一个致命漏洞：Claude 把"支付超时"和"网络错误"归到了同一个错误分支，但业务上这两种情况的处理逻辑完全不同。5 个文件都得回滚，因为架构一开始就走歪了。

这不是 AI 写代码不行，而是"直接写代码"这个姿势本身就错了。

人类工程师面对复杂改动，会先画个图、写设计文档、跟同事讨论方案。不是能力问题，是修改方案的审查成本远低于代码的审查成本。读一份 200 字的实现计划，两分钟；审一堆改动后的代码，二十分钟起步。

Claude Code 的 Plan 模式就是把这种工程习惯内置进了工具里。

---

Plan 模式到底做了什么

Plan 模式下，Claude 被限制在"只读"状态。它能：

• 读文件，不限范围
• 跑只读命令（ls、grep、git log、npm ls 等）
• 分析和推理，产出实施方案

它不能：

• 编辑任何文件
• 执行任何写操作命令
• 在未获你批准的情况下离开只读状态

机制上，它相当于给你和 AI 之间插入了一个强制性的审查点。你不再需要盯着每一次文件编辑，只需要在它出方案时看一眼、调整方向，然后让它放手执行。

进入 Plan 模式有三种方式：

# 从 CLI 启动时指定
claude --permission-mode plan

# 会话中按 Shift+Tab 循环切换（默认 → acceptEdits → plan）

# 在单条提示前加 /plan 前缀——仅本条消息使用 Plan 模式
/plan 重构 src/payment/ 模块的错误处理，先分析现状再出方案

当 AI 产出方案后，它会停下来问你怎么处理。此时你有四个选择：

1. 批准并用 auto 模式开始——放手让 AI 按方案执行，分类器把关
2. 批准并用 acceptEdits 执行——自动通过编辑，遇到非编辑操作弹确认
3. 批准并手动审查每一步——切回 Manual，逐条确认
4. 继续规划——给反馈让 AI 修正方案，不急着动手

方案批准后，Claude Code 自动退出 Plan 模式，进入你选择的权限模式开始干活。同时它还会根据计划内容自动为会话命名，省得你后期翻一堆"Untitled session"找上下文。

还有一个实用细节：如果方案写好了但你想调几个地方，按 Ctrl+G 会在默认文本编辑器里打开方案原文，直接编辑后保存，Claude 会按你改过的版本执行。比打字追加约束快。

---

什么任务该用 Plan、什么不必

该用 Plan	不必用 Plan
跨多个文件的改动	改一行文案、修一个 typo
涉及架构决策（拆模块、改数据流）	明确机械的操作（批量重命名、加一个字段）
你不熟悉的代码区域	你自己写的、结构烂熟于心的模块
有多种实现路径、需要选择	需求一句就能说清、没有歧义

一个实用判断标准：如果改动能用一句话描述清楚 diff，跳过 Plan；如果连描述都需要先"看下代码再定"，必须走 Plan。

Plan 模式有额外开销——多一轮对话、多加一次等待。对于小改动用 Plan 反而啰嗦。官方文档也明确指出：Plan 模式"adds overhead"，应该用在"不确定方案、改动跨文件、对代码不熟悉"的场景。

---

怎么审查 AI 的方案：三个检查点

拿到方案后别全盘接受。快速过三个问题：

1. 它对现状的理解对吗？
看方案的第一部分——AI 会描述它读到了什么、现状是什么。如果这里就歪了，后面的方案没有审查价值。修正方式：指出它遗漏或误读的部分，让它重读再出方案。

2. 有没有遗漏边界情况？
AI 倾向于沿着"正常路径"思考。你作为了解业务的人，要补上异常分支、权限、并发、兼容性等边界。修正方式：直接在方案上追加约束，或告诉 AI"加上 XX 情况的处理"然后让它更新方案。

3. 范围是否过大？
AI 有时候会把"顺便优化"塞进方案——改个错误处理，它可能顺手建议把整个模块的命名规范也统一了。原则：本次改动的范围以外，一律砍掉，另起新任务。修正方式：告诉它"本次只动 XX 和 YY，其他不改"，或按 Ctrl+G 直接删掉方案中的多余部分。

---

一个示例：重构支付模块的错误处理

背景：src/payment/ 模块当前用 throw new Error('xxx') 到处抛，没有分类，上层 middle 靠字符串匹配区分错误类型。

Step 1：进入 Plan，让它分析

/plan 重构 src/payment/ 的错误处理。
先读 src/payment/ 下所有文件，告诉我当前的错误处理模式、
有哪些错误类型、各自在哪些地方抛出。
然后出一个重构方案。我只想读方案，不改代码。

Claude 读完代码，输出：

当前状态：

• 3 个文件涉及错误抛出（checkout.ts、refund.ts、webhook.ts）
• 全部使用 throw new Error('...')，无分类
• 上层 errorHandler.ts 靠 error.message.includes('timeout') 这种字符串匹配做分支
• 已识别 6 种错误类型：超时、余额不足、渠道不可用、重复请求、签名错误、未知

方案：

1. 新建 src/payment/errors.ts，定义 PaymentError 基类和 6 个子类
2. 逐个替换 checkout.ts、refund.ts、webhook.ts 中的 throw new Error
3. 修改 errorHandler.ts，从 includes() 字符串匹配改为 instanceof 判断
4. 不改动任何业务逻辑（金额计算、API 调用参数）
5. 需要补充 6 个错误类型的单测

Step 2：补充约束

你追加：

方案方向对。补充两点：

1. PaymentError 基类要带一个 code 字段（数字），方便日志和监控
2. 只动这 4 个文件：errors.ts（新建）、checkout.ts、refund.ts、errorHandler.ts
   webhook.ts 我后续单独改

更新方案后开始执行。

Claude 更新方案，你确认。它退出 Plan 模式，进入 acceptEdits，按方案逐个文件改完。

整个过程你做了两次决策：审一次方案 + 补一个约束。没有一次是在改完代码后发现方向错了。

---

小结

Plan 模式的本质不是"多一步操作"，而是把审查点前移。用 5 分钟审方案、补充约束，换取省掉 30 分钟的代码返工和不安全感。

这不只适用于 AI。任何需要他人执行的复杂任务，先确认"做什么"再让对方"怎么做"，是工程管理的基本功。Plan 模式只是把这一条内置进了你的终端里。

第 4 篇进入 MCP——Plan 让 AI 想得对，MCP 让 AI 的手够得远。聊聊怎么给 Claude Code 接上你自己的数据库、API 和工具。

---

标签：Claude Code、AI编程、AI Agent、Plan模式、AI辅助编程、开发工具