Plan Mode：让 Claude 先想清楚再动手，我的代码再也沒被改崩过

以前让 Claude 改代码，经常出现"我刚改了这个文件，它又去改了那个文件，结果中间状态不一致"的问题。用上 Plan Mode 之后，Claude 先做调研、写方案、给我审，审完再动手。这篇聊聊 Plan Mode 的工作流、怎么用、以及三个让我从不离手的操作习惯。

上次聊 CLAUDE.md 的时候提到，写完那篇文章之后我改了一个习惯——每次纠正 Claude 的错误就会顺手更新配置。但有一个问题 CLAUDE.md 解决不了：Claude 改到一半，我发现方向偏了。

你遇到过这种情况吗？你跟 Claude 说"帮我重构一下用户模块的认证逻辑"，它二话不说就开始改。改完 auth.service.ts，改 auth.controller.ts，改完 controller 发现依赖了 user.service.ts，又去改 user service。等你想看进度的时候，三个文件已经被改了一轮——而且其中两个改法跟你脑子里想的完全不一样。

你说"不对，我不是这个意思"，然后 Claude 开始回滚。但它已经改了三个文件，回滚又改一轮。中间状态反复横跳，最后可能连最初能跑的状态都回不去了。

我在用 Plan Mode 之前，至少翻过三次这种车。最严重的一次，Claude 把整个路由层的中间件逻辑重构了，而我本来只想加一个接口。那天下午我对着 git diff 发呆了半小时。

Plan Mode：先出方案，再动手

Plan Mode 的核心就一句话：Claude 先进入只读调研模式，读完代码、写好方案、等你审核，审核通过才开始动手。

听起来很简单对吧？但实际体验的差距大得惊人。

以前的工作流是这个样子的：

我说需求 → Claude 直接动手 → 改到一半发现不对 → 我喊停 → Claude 回滚 → 再改

用 Plan Mode 之后变成了：

我说需求 → Claude 只读调研 → 输出方案.md → 我审方案（可能修改）→ 我批准 → Claude 按方案执行

区别在于：方案阶段改的是文字，执行阶段改的是代码。 改文字的代价几乎为零，改代码的代价可能是半小时甚至更久。

我第一次试 Plan Mode 是在一个多文件重构的场景。我描述完需求，Claude 花了两分钟读代码、问了我三个问题，然后生成了一份方案。我打开一看——它打算改的文件顺序和我想的不一样，前置条件也没考虑全。我在方案文件里改了改顺序、加了一个缺失的边界条件处理。然后批准，它按方案执行，一次到位。

放在以前，这个"发现方案不对"的节点至少要到改了第一个文件之后才能暴露。而在 Plan Mode 里，改了文字的方案就发现了。

具体怎么用

进入 Plan Mode

两种方式：

按 Shift+Tab 两次       # 键盘快捷操作
或者输入 /plan          # 命令方式

进入之后，Claude 的状态会变成只读。你可以看到它不再写任何代码，而是疯狂读文件、搜代码、问问题。它可能会问你：

"这个重构的范围是只涉及认证模块，还是连授权模块也需要改？"
"新增的这个接口需要兼容现有的 token 格式吗？"
"你预期的测试覆盖率是多少？"

有些问题你可能从没想过——Claude 在探索代码库的时候发现的依赖关系。

写方案

Plan Mode 下 Claude 会按四个阶段推进：

1. 调研阶段：读代码、搜文件、理解你的需求和代码库的现状
2. 设计阶段：生成实现方案，可能同时给出多个选项
3. 审核阶段：读关键文件确认方案可行，再跟你确认
4. 输出方案：写一个 markdown 文件到 ~/.claude/plans/ 目录

方案文件的名字是随机的，比如 dreamy-orbiting-quokka.md。内容大概长这样：

# 用户权限模块重构方案

## 变更范围
- src/auth/service.ts: 新增 checkPermission 方法
- src/auth/controller.ts: 新增权限校验路由
- src/user/service.ts: 新增 role 字段查询

## 执行顺序
1. user/service.ts — 先扩展用户查询接口，不涉及逻辑变更
2. auth/service.ts — 新增权限校验核心逻辑
3. auth/controller.ts — 挂载到路由层

## 每个文件的改动描述
### user/service.ts
- `getUserRoles(userId: string): Role[]` 新增方法
- 依赖现有 Prisma 查询，不改 schema

### auth/service.ts
- `checkPermission(userId: string, resource: string): boolean` 新增方法
- 调用 userService.getUserRoles 获取角色，再查角色权限表

### auth/controller.ts
- 新增 `POST /auth/check-permission` 接口
- body: { userId, resource }，返回 { allowed: boolean }

## 不做的事情
- 不改数据库 schema
- 不改现有接口签名
- 不引入新依赖

## 风险点
- userService.getUserRoles 如果已有缓存策略，注意不要重复缓存

这个方案就是你和 Claude 之间的"合同"。Claude 不能做方案里没写的事。

审方案

方案写完之后，Claude 会等你审核。最实用的操作是这个：

Ctrl+G      # 在默认编辑器中打开方案文件

或者：

/plan open  # 打开当前方案

我会在编辑器里直接改方案。比如我审到第三项，觉得 Claude 把 controller 和 service 的拆分粒度搞错了——我希望权限校验逻辑独立出来，而不是挂在 auth service 下面。我直接在文件里改，改完保存。

回到终端，Claude 会发现方案被改了，它会说"我注意到你修改了方案，我来确认一下新的方案是否符合你的预期"，然后按新方案调整。

批准执行

审完觉得没问题，告诉 Claude "方案没问题，开始做"。Claude 退出 Plan Mode，读取方案文件，按步骤执行。

Tricks

Trick 1：执行过程中也能回 Plan Mode

这是我最常用的技巧。

Claude 执行到第二步的时候，我发现"等等，这个接口的返回格式跟团队之前约定的不一致"。不用等它做完，直接按 Shift+Tab 两次——Claude 会回到 Plan Mode，重新读取当前文件状态（因为文件已经被改了部分了），更新方案中剩下未执行的步骤。

更新完方案再批准，它接着改。这个"中场调整"避免了要么硬着头皮改完、要么全盘回滚的两难选择。

Trick 2：方案文件是跨 session 的

~/.claude/plans/ 下的方案文件不会被 /clear 清理。这意味着你可以在一个 session 里做调研出方案，然后关掉终端，明天再继续执行。

我实际上更常用的场景是：早上通勤时让 Claude 做调研出方案，下午到了工位审方案。方案文件安安稳稳躺在磁盘上，中间 session 关了多少次都不影响。

不过有个细节要注意——Claude 在 /clear 或 context compaction 之后可能会忘记方案文件的存在。所以恢复 session 之后最好说一句"读取我的方案文件继续"。

Trick 3：用 /plan open 手动改方案

有时候 Claude 写的方案跟我想要的不完全一致，但 Claude 又觉得自己写得挺好。与其在对话里来回拉扯，我直接 /plan open，在编辑器里手动改完，保存。

Claude 发现方案文件被改了之后，会自动读取并确认新的内容。这比在对话框里纠正它高效多了。

注意事项 / 踩坑

坑一：方案阶段的 token 消耗比想象中大

Claude 在 Plan Mode 下读文件比执行阶段更激进——它不知道哪些文件真正有用，所以会多读很多。一个涉及三个文件的重构，方案阶段可能消耗 1.5 万到 4 万 token 的输入。如果涉及架构变更，10 万 token 都有可能。

这不是 bug，是特性。但如果你用按量计费的 API，建议先有个心理准备。对我来说，花几万 token 读代码出一份靠谱的方案，远比改崩了回滚省 token。

坑二：方案越具体，执行越准

Claude 写的方案如果太模糊，执行阶段就会出现"自由发挥"。

比较这两个方案描述：

模糊的：

修复用户模块的认证逻辑

具体的：

将 auth/service.ts 中 validateToken 函数的 JWT 过期处理逻辑从 "直接抛异常" 改为 "返回特定的 ExpiredTokenError，由 controller 层决定是刷新 token 还是要求重新登录"

具体的方案里已经包含了"在哪里改"、"怎么改"、"错误类型是什么"。Claude 执行的时候不需要做决策，只需要翻译方案为代码。决策越少，偏离的风险越低。

坑三：方案文件在 context compaction 后可能被遗忘

方案文件本身存在磁盘上，不会丢。但 Claude 在 context compaction 之后可能忘了还有一份方案文件。

所以如果 session 中间做了 /compact 或者 /clear，记得加上一句"读取 ~/.claude/plans/ 下的方案文件"。Claude 会重新 grep 到它。

一个反直觉的事实

我以前觉得"先出方案再动手"是浪费时间——既然 Claude 能直接改，为什么要多一步？这不是多此一举吗？

实际用下来发现：方案的 token 成本几乎是零，改崩了回滚的 token 成本是天价。

方案阶段花 2 万 token 读代码，发现并修正了三个设计缺陷。执行阶段一次到位，总花费可能 5 万 token。不用 Plan Mode，直接上手改——第一次改完发现不对，回滚重新理解再改——可能 15 万 token 花出去，代码还在一团浆糊。

算一笔经济账的话，Plan Mode 反而是最省钱的模式。

下次聊 Skills，那个让我写大段知识文档时不用塞爆 CLAUDE.md 的东西。