计划模式：先规划后动手，避免 Agent 乱改文件

为什么需要计划模式

Agent 最让人心惊的时刻：你说"优化一下这个模块"，它十分钟后给你 34 个文件的 diff。可能改得很好，也可能方向就错了——错的代价是你逐文件审阅的时间。计划模式把这笔风险前置：Claude 先只读探索、产出方案，你批准之后才允许它碰文件。

状态栏显示 ⏸ plan mode on 时就是它在计划。三种进入方式：

# 方式一：启动时就进计划模式
claude --permission-mode plan

# 方式二：会话中 Shift+Tab 循环切换，切到 plan 为止

# 方式三：用 /plan 命令直接带任务进
/plan 把订单模块的回调改成事件驱动

方式三是我的默认用法——连"进入计划模式"这个动作都省了，直接派活。

计划模式的内部机制

计划模式下 Claude 能读文件、跑只读命令（git log、搜索这类），但不能改你的源码。它要执行其他 shell 命令时的处理取决于配置：如果 auto 模式可用且 useAutoModeDuringPlan 开着（默认开），由分类器审查放行或拦截；否则会弹权限询问。

探索完成后它会产出一份计划文件供你审阅。批准选项里有讲究：

• Yes, and auto mode：批准并切到自动模式，接下来基本不再打扰你；
• Yes, and auto-accept edits：批准并自动接受文件编辑；
• 也可以选仅批准、继续留在需要确认的档位。

有个贴心细节：计划文件存在 ~/.claude/plans/ 下，压缩后会被自动重新注入——就算长会话把早期对话压没了，批准过的方案依然在场。这解决了"批准完跑到一半忘了计划"的经典问题。

审阅计划时还有两个实用动作值得知道。一是编辑后批准：批准流程里可以选择用文本编辑器打开计划文件，直接删改不满意的条目再确认，比打字描述"第三条改一下"精确得多。二是分步追问：批准前可以继续和它讨论计划的任何细节，追问的成本几乎为零，而每一条你追问过的内容都会被写进计划——追问本身就是打磨。

计划模式的心理账户

把计划模式想成"花钱买保险"：走流程本身有成本（多一轮对话、多几分钟），换来的是把返工风险转移掉。这笔账在不同任务上划算程度不同，所以关键是别把它当成道德义务，而是当成金融决策——风险大就买保险，风险小就直接干。

还有一个隐藏收益经常被忽略：计划是免费的知识萃取。计划过程要求 Claude 通读相关代码、理清依赖关系，最后产出的那份方案文档本身就是这个模块的设计说明书。批准执行后，这份文档还在 ~/.claude/plans/ 里，三个月后重构的"当初为什么这么改"，答案就在里面。有些团队甚至让 Claude 把批准后的计划归档进 docs/，作为 ADR（架构决策记录）的低配替代。

什么任务该用计划模式

不是所有任务都值得走流程。我的经验按风险和规模分：

打个比方：计划模式像装修前的图纸会审。小刷墙不用图纸，但拆承重墙必须看图纸——而且看图纸的不该只有施工队，还得有住户（你）。

计划模式还有一个隐含价值：它把"描述任务"和"描述方案"分开了。你负责描述任务（要什么、约束是什么），Claude 负责产出方案，你在方案层审批。这比在任务层反复拉扯高效得多——你不用告诉它"先改 A 文件再改 B 文件"，只需要审它提出的路径对不对。层级对了，沟通就省力了。

计划质量怎么提升

计划模式常见的槽点是计划太泛："1. 分析现状 2. 修改实现 3. 验证"——这是废话计划。让计划可审，你需要在派活时给足约束：

/plan 把用户通知从轮询改成 WebSocket 推送。
要求：
1. 计划里列出要动的所有文件和每个文件的改动性质
2. 明确回滚方案：怎么在不停服的情况下切回轮询
3. 标出需要新增的依赖和版本
4. 不要动 src/legacy/ 目录

审计划时重点盯三处：影响面（改动文件清单是否完整，有没有漏）、验证方式（它打算怎么证明改对了）、回滚方案（出事怎么退）。这三样齐了才叫方案，否则只是愿望清单。

批准前还可以用文本编辑器改计划——选项里有编辑入口，把不满意的部分直接改掉再批。

计划模式 + 会话管理的组合拳

一个成熟的大任务流程是把前面几章串起来：

1  claude -n checkout-refactor        # 命名会话
2  /plan <详细的任务描述>              # 带任务进计划模式
3  （审计划、改计划、批准）
4  切到 auto 或 acceptEdits 执行
5  中途 /context 监控上下文水位
6  卡住了就 /rewind 回退到计划批准点重试
7  完成：/diff → /code-review → 提交

如果方向彻底错了，还有一招：/branch 在当前对话点分叉试另一条路，原对话原样保留。计划不是一次定终身的合同，是可迭代的草稿。

一个大任务的全过程复盘

用"结账流程改造"这种真实任务走一遍，你就能感受到每个环节为什么要存在：

派活：
/plan 把结账流程里的同步扣库存改成异步消息队列方案。
约束：不能丢消息；失败要有补偿；计划里列出所有要动的文件；
标注新依赖及版本；给出灰度切换和回滚步骤。

Claude 探索后给出的计划（节选）：
1. 新增 src/mq/order-events.ts，封装发送侧（文件：新增）
2. InventoryService 改为消费方，幂等处理重复消息（文件：修改）
3. 新增补偿任务：扫描超时未确认的扣减（文件：新增）
4. 新增依赖：amqplib ^0.10
5. 灰度：环境变量开关，默认关闭，按租户逐步打开
6. 回滚：关闭开关即回同步路径，无数据迁移

你审的重点：
- 幂等怎么做？追问后计划补充了消息 ID 去重表
- 补偿任务的调度方式？答：复用现有 cron 框架，不引入新调度器

批准：选 "Yes, and use auto mode"，执行开始

注意这个流程里计划模式做了三件事：强制它先想清楚（探索阶段读了大量代码）、把你的经验注入方案（幂等和补偿是你补的要求）、留下可回溯的文档。执行阶段反而成了最不需要你盯的部分。

常见反模式

反模式一：计划当摆设。 5 秒扫完就点批准——那不如直接 acceptEdits，还省一轮对话。计划的阅读时间是花的值得的成本。

反模式二：在计划里漏掉验收标准。 "完成"的定义不在计划里，执行完就会出现"它说做完了你看着不像"的扯皮。派活时就把验收写清楚。

反模式三：巨型任务一个计划走到底。 三天的活不要指望一个计划管到底，拆成"方案设计 → 分阶段实施"的多轮计划，每轮批一次。

反模式四：从不复盘旧计划。 定期翻翻 ~/.claude/plans/，你会发现有些计划从未执行但想法仍然有效——那是你决策库的一部分。

团队场景：让计划变成协作界面

计划文件还有个组织级的妙用：它是人和 Agent 之间的协作合同。我们团队的实践是把"贴出计划链接到 PR 描述"固定成流程——reviewer 不只看代码 diff，还能看到当初批准的方案，审起代码来有"设计意图"可对照。偏离计划的地方一望而知，要么是执行中发现了新问题（该更新计划），要么是实现走样了（该修代码）。

另一个场景是异步协作：主计划在 A 的会话里，B 想接手继续做。B 直接恢复 A 的会话（会话按项目共享在选择器里），计划文件、对话上下文、决策理由全都在——比口头交接或翻聊天记录靠谱得多。计划模式由此从"个人效率工具"升级成了"团队的知识载体"，这大概是它设计者都没预料到的用法。

和权限体系的关系

计划模式本质上是权限体系中最保守的一档（只读），它和 Auto、Manual、acceptEdits、bypassPermissions 构成完整的档位谱系。下一章会讲完整的权限模型——allowlist 怎么配、deny 规则怎么写、沙箱是什么。这里先记住使用心法：档位跟着任务风险走，计划模式是风险未知时的默认起点。所谓"避免 Agent 乱改文件"，靠的不是对 AI 的信任或不信任，而是把审批点放在信息最充分的位置——动手前，而不是动手后。

本章由 WorkBuddy 原创整理，事实性内容参考 Claude Code 官方文档。